Как справиться с боязнью пользовательских Dev

Question

Я имею дело с проблемой с моим нынешним работодателем, который серьезно заставил меня рассмотреть возможность поиска работы в другом месте. У них создается впечатление, что 100% пользовательских разработок следует исключить и заменить продуктами COTS, такими как SharePoint. Хотя я понимаю, что это не реалистичное ожидание, я счел невозможным аргументировать свои моменты с людьми в управлении, которые разделяют эти взгляды. Их аргумент обычно включает в себя что-то вроде функции, уже существующей в SharePoint, которая охватывает функцию X, поэтому риск меньше связан, и тестирование не нужно делать против него.

Дело в том, что ситуация, когда список SharePoint полностью не способен удовлетворения ожиданий и требований клиентов. Однако сохранение этих данных в базе данных SQL легко выполнило бы требования. Однако всякий раз, когда наша команда разработчиков предлагает выйти за пределы SharePoint, руководство продолжает плакать о том, как каждая строка кода добавляет сложности проекта и увеличивает риск. Хотя это, безусловно, верно в некоторых ситуациях, это не всегда так. Однако их аргумент заключается в том, что поскольку SharePoint предоставляет механизм для хранения данных, мы должны использовать его в 100% случаев. Независимо от того, отвечает ли он требованиям клиента или нет.

Я пришел к выводу, что я ненавижу работать на работу, потому что меня постоянно заставляют делать то, что я знаю (со 100% уверенностью), являются неправильными, и это можно сделать правильно, выполняя индивидуальную разработку. Это просто то, что кажется невозможным аргументом, в котором я работаю.

Были ли у вас похожие ситуации? Если да, то что вы сделали для решения этих проблем?

Answer 1

Если вы не разделяете видение компании, и если вы не можете просветить их, то обязательно пришло время начать искать.

Вы указали, что существует риск вызвать «решение» на клиенте, который не помогает им или отсутствует функция или непригодна для использования?

Возможно, возникнут планы по устранению и уменьшению их предполагаемых рисков.

Answer 2

Я делаю то же самое на своей текущей работе, нет простого способа справиться с такой ситуацией. Все, что я смог сделать, - это проглотить мои аргументы, потому что они меня не нашли и делают то, что требуется моему руководству. Этот курс будет идти против вашего основного характера программиста, используя наилучшее решение для этой задачи, и, возможно, получить возможность создать что-то классное в этом процессе, но поскольку они босс, это действительно ваше единственное решение. Вы можете попытаться найти примеры с доказательствами, где имеет смысл использовать пользовательские решения. Но если вы босс - это что-то похожее на мое, оно не пройдет очень далеко до начала кричащего матча. Единственное другое решение - это отмывание этого резюме и поиск новой работы.

Answer 3

Имеет ли кто-то в управлении собственный запас в SharePoint? Была ли система разработана младшим братом генерального директора?

Если они настолько устойчивы к изменению, вы должны выяснить реальную причину, прежде чем пытаться спорить с ними. Они могут утверждать, что добавлена ​​сложность, сложность тестирования и т. Д., Но если вы можете противостоять каждому аргументу тем, который показывает свою позицию, при всем уважении, быть дезинформированным, и они все равно не обсудят, тогда вы можете спорить неправильная точка.

Если они заблокированы в технологии из-за нетехнической причины, например, кто-то однажды прочитал, что SharePoint является конечной в любой технической ситуации (и, конечно же, не имел понятия, что в статье говорилось о других, чем SharePoint = хорошо), тогда вы не должны пытаться спорить и сохранять свою энергию. Для охоты за работой.

Answer 4

Вы документируете свои проблемы и позволяете тем, кто выше вас знать, а затем вы делаете, как они просят. Если это не сработает, у вас есть документация, в которой вы подняли проблемы. Но постарайтесь заставить его работать, поэтому не похоже, что вы пытаетесь подорвать свои планы. Они подвергаются большему риску и, следовательно, получают большую ответственность. Постарайтесь изо всех сил, чтобы он работал, и перестаньте беспокоиться об этом.

Answer 5

Докажите это им. Когда требования запрашивают список, который может обрабатывать 100 000 элементов с сортировкой по нескольким столбцам, напишите сценарий, который добавляет 100 000 тестовых элементов в список sharepoint и позволяет им попробовать его, предпочтительно с «клиентом», запрашивающим просмотр списка. :-)

Answer 6

Я столкнулся с такими же проблемами сразу с первого дня. У руководства есть естественное нежелание добавлять в решение пользовательский код. Однако в большинстве случаев было бы возможно объяснить, что правильное решение для клиента будет включать в себя некоторый код.

Помните, что если вы утверждаете, что вы можете включить пользовательский код в общую кодовую базу, то босс может одобрить эту идею.

Answer 7

Я бы выбрал свое резюме и открыл его, если бы был вами. Не только опыт, который у вас сейчас расстраивает, он может нанести серьезный вред вашей карьере в долгосрочной перспективе. Просто подумай об этом. Пока вы томитесь с вашим нынешним работодателем в своей нынешней должности, другие разработчики принимают новые технологии и расширяют свой опыт.

Существует такая вещь, как идеологические различия между разработчиками и то, что идея компании о роли для разработчика. Если открытая дискуссия и откровенность ни к чему не приведут, вы не будете ошибаться из-за отсутствия усилий. Лояльность к компании - это хорошо, но отношения должны быть двусторонней улицей.

К сожалению, в конце концов, вероятно, вы поймете, что они ошибаются в своих предположениях, но вы не можете дождаться этого дня. Иногда этого никогда не бывает. В частности (и не поймите меня неправильно, я люблю SharePoint, когда он используется для того, для чего он предназначен), SharePoint стал следующим Access, поскольку люди, которые читают журналы управления, видят достаточно, чтобы их называть мессия.

Answer 8

Я действительно чувствую вашу боль.

Если бы это был я, я бы использовал свое свободное время для сбора информации, которая доказывает мою точку зрения и документирует ее в удобном для понимания способом.

Если они понимают только деньги, говорят деньги, если они только понимают страх (делая это «потому что они боятся« этого »), используйте страх, находя страшную вещь для них в« своем »решении.

Документируйте каждую новую реализацию, время, деньги и проблемы, которые возникают. И документируйте, каким будет ваше решение.

Они, вероятно, не видят проблемы в своем решении, потому что они сосредоточены на отсутствии проблем в «вашем» решении.

Answer 9

Это может звучать плохо и, возможно, не тот ответ, который вы хотите. В моем офисе есть небольшое известное подразделение под названием «The Skunk Works». Люди сами по себе (обычно во время обеденных перерывов или компиляции) решают написать небольшие программы, которые помогают компании. Веселые вещи об этом - результат, который «не стоит» в компании.

Разговор обычно выглядит следующим образом:

«Мы должны купить это программное обеспечение» -Boss

«Но мы имели эту вещь в течение нескольких месяцев Джон, написал, что еще в день.» - Программист

"?" -Boss

Многие разработчики считают, что решение является плохим и просто создает параллельный процесс, который происходит автоматически. Затем, когда материал попадает в вентилятор и клиенты разочарованы, альтернативное решение УЖЕ на месте.

У меня есть пример автовыпуска. Разработчики использовали эти пользовательские отчеты. По мере увеличения наших клиентов рабочая нагрузка разработчика увеличилась. Проблема заключалась в том, что «для того, чтобы клиент мог привлечь разработчика пользовательского отчета, должен был быть задействован». Таким образом, хотя компания занималась наймом кого-либо для составления отчетов в полный рабочий день или для поиска способов, чтобы клиенты делали их, я написал машину автоматического выпуска, которая ищет отчеты об изменениях и выпускает их непосредственно клиенту. Я также написал утилиту, которая позволяет кому-либо вносить изменения в отчеты, которые были проще в использовании, чем то, что имеет разработчик. Когда Босс объявил о попытке найти решение, я сказал ему, что он уже на месте и что он даже может внести изменения в отчеты и освободить их. Теперь каждый может изменять отчеты, обычно это управление и поддержка клиентов, которые вносят эти изменения. Интересная сторона заключается в том, что разработчики больше не участвуют.

Просто сделайте это. Если вы все равно уйдете, можете попробовать.

Answer 10

Я работал в месте, где руководство не было конструктивным в своем подходе, не так плохо, как вы описали, но достаточно плохо.

Есть несколько вариантов. Один из них заключается в том, чтобы идти дальше и делать то, что нужно сделать для клиента с лучшим вариантом «соотношение цены и качества». Вам, вероятно, придется собрать разработчиков вместе в команде, чтобы сделать это «гражданское непослушание».

Более сильный подход, который действительно заставит говна попасть в вентилятор, - это пойти к клиенту (не делайте этого, если это внешний клиент, или если вы хотите сохранить свою работу) и выложите, что происходит чтобы произойти с этим проектом, если X и Y. Это довольно много рассказов из школы и будет плохо, но интересно.

Немного лучший способ подняться по цепи и получить спонсора, который может сделать дерьмо для вас. По существу зайдите за своего босса (обратно). Это может сработать, но оно будет иметь предсказуемые результаты для ваших отношений с вашим руководством.

Последним и самым трудным является идентификация человека, который считает, что какой-либо пользовательский код является плохим, и задействовать их в разговоре, чтобы узнать, где они получили веру, и встретить это с примерами. Акцент на разговоре, поскольку вам придется прислушиваться к их основным проблемам (которые не будут касаться индивидуального кода как такового) и понимать их только после того, как вы доверяете этим людям.

Я не могу сказать вам, какой способ делать все будет лучше, потому что это так сильно зависит от вовлеченных лиц. Все, что я знаю, это то, что вы не можете изменить людей, и по моему опыту лучший способ решить проблему до сих пор заключался в том, чтобы уйти и работать с людьми, которые не так ...

Answer 11

Я нахожу, что обычно нет способа «выигрывать» эти дебаты через разговоры в одиночку. Многие руководители формируют мнение о продукте или решении, ориентируясь на ориентированные на чтение статьи. Посмотрите, сможете ли вы найти контр-статьи.

Если вы можете привести примеры того, что SharePoint неспособна сделать, и показать примеры того, как вы можете экономить эффективно решить эти проблемы с помощью специальной разработки, тогда вы хорошо на своем пути.

Ошибка заключается в том, чтобы попытаться рассказать о технологиях, а не об эффективности, экономической эффективности и ремонтопригодности - это мантры и метрики, которые будут влиять на нестандартных менеджеров на рассмотрение альтернатив.

Если вы можете собрать доказательство концепции для некоторых из этих проблем, тем лучше, глазные конфеты действительно помогают продавать за пределами технических команд.

Наконец, удачи :)

Answer 12

как о не называя его пользовательский код. Если вместо этого вы называете это «ожидаемыми расширениями пользователей SharePoint» или что-то, это может смягчить заблуждение, связанное с определенным термином.

также, как уже было сказано, могут быть другие скрытые от вас причины, по которым руководство продвигает эту повестку дня. Скорее всего, лучше не догадываться об этом слишком быстро, так как многие будут действительны.

Наконец-то есть много мест, которые нуждаются в развитии. это не больно искать лучший матч.

удачи.