Ни для кого не секрет, что менеджеры могут и часто навязывают язык программирования, который будет использоваться для проекта.
Будучи самим программистом, я никогда не мог этого понять.
Но теперь я думаю, что знаю: у меня только что было откровение, когда Джоэл Спольски сказал на подкасте, что им следует использовать QuickBooks, потому что «это знает каждый бухгалтер в мире». Это показалось мне очень похожим на «выбрал Java, потому что каждый программист в мире знает это».
Теперь, когда я увидел ту же проблему с другой точки зрения, я не знаю много о бухгалтерском учете, но я кое-что знаю о программировании, мне интересно, как программист может помочь убедиться, что для проекта выбран правильный язык программирования ?
language-agnostic
project-management
management
strategy
Мировой инженер
источник
источник
Ответы:
Ошибка многих программистов заключается в том, что они будут спорить (или просто соглашаться или не соглашаться с этим), основываясь исключительно на технических достоинствах. С руководством - и бизнесом в целом - вы должны обсудить экономическое обоснование и преимущества для бизнеса в первую очередь, а технические преимущества - во-вторых.
Это выходит за рамки выбора языка программирования и пронизывает практически каждое техническое решение.
Позвольте привести пример: ПК. Джоэл утверждает (правильно), что у разработчиков должны быть первоклассные машины, потому что время разработки дорого. В этом он совершенно прав. Но как вы спорите об этом? Просто:
Пример: я делаю сборку кода примерно 20 раз в день. Каждый раз это занимает 3 минуты. Если бы у меня был быстрый ПК, я мог бы собрать его за 1,5 минуты. Таким образом, за дополнительные 1000 долларов каждые два года я могу получать дополнительные полчаса в день, что для программиста, зарабатывающего 100 тысяч долларов (с затратами минимум на 50%), что равняется примерно 10000 долларов в год.
Но на другом конце спор о том, что HR решает, что один размер подходит всем, когда речь заходит о политике и ПК, поэтому работник колл-центра зарабатывает 25 тысяч долларов, а программист зарабатывает четыре раза, которые по какой-то причине должны иметь один и тот же компьютер.
Технологическая платформа и языки будут иметь множество факторов, влияющих на принятие решений:
В любом случае вам нужно понять причину (и я гарантирую вам, что будет несколько причин) и аргументировать достоинства в этих терминах. Некоторые программисты довольно наивны в этом отделе и, похоже, считают, что такие решения принимаются из-за невежества или даже мстительности, когда в игру вступают почти все факторы.
источник
Из того, что мне кажется в моей компании: когда менеджеры выбирают язык программирования, они обычно делают это очень консервативно - принимая во внимание, какие навыки программирования в настоящее время доступны в команде (и если легко будет нанять дополнительные ), является ли это хорошо зарекомендовавшим себя языком, пытаясь выбрать что-то, что будет соответствовать текущей инфраструктуре и не заставит больших усилий приспособить его к тому, что уже существует. Когда программисты выбирают язык программирования, вещи часто бывают немного другими - им часто нравится сталкиваться с новыми проблемами, и они хотели бы получить последние горячие тенденции и выбрать что-то, где они могут изучать новые вещи.
В идеале все сводится к обсуждению плюсов и минусов между менеджером и командой разработчиков и поиску решения, которое наилучшим образом соответствует проблеме. Обычно это требует много разговоров и убеждений :-)
источник
Поздний ответ, но так как пока нет принятого ответа, я попробую. Я воспринимаю это как два вопроса и попытаюсь ответить на них отдельно:
Как менеджеры выбирают языки программирования?
Сильно зависит от размера организации и опыта менеджера, но обычно включает оценку текущей ситуации и будущих сценариев и требований. Обычно это делается с помощью PESTLE или аналогичного анализа, и просто для того, чтобы дать несколько образцов в каждой категории:
Затем группа языков, соответствующих критериям, может быть дополнительно оценена с использованием SWOT , анализа затрат и результатов или подобного.
Весь процесс может быть довольно сложным, но в итоге большинство компаний или проектных групп выберут самый безопасный вариант, учитывая их текущие обстоятельства, которые все еще могут предоставить необходимые им возможности. Довольно часто это может означать придерживаться текущей платформы дольше.
Как программист может помочь убедиться, что для проекта выбран правильный язык программирования
Как мы надеемся, было продемонстрировано, что обычный программист обычно получает лишь 1/6 от общего вклада в процесс принятия решений. И, как правило, ее или ее больше всего интересуют только языковые возможности!
Что ж, лучший способ повлиять на решение, по-видимому, иметь более широкую картину процесса отбора, создать союзников внутри и вне команды, составить краткий обзор по технологическим аспектам и попытаться не концентрироваться только на языковых возможностях.
И, конечно же, нужно войти в положение, когда менеджер проекта или развития (или кто-либо еще отвечает) видит преимущества прохождения всего процесса оценки и готов рассмотреть риски и неопределенности перехода на другое язык на первом месте. Для этого нужно продемонстрировать, что:
Однако, если бы вы спросили: «Как лучше всего использовать на работе язык, который мне нравится», ответ, вероятно, был бы «присоединиться к компании, которая уже использует этот язык, или начать свой собственный».
источник
Менеджер А отправляется на летнее отступление, где встречает менеджера Б.
A: Так какой язык вы используете в своей компании? B: О, мы используем CA Visual Objects, это делает дроны намного более производительными, чем COBOL.
И так было принято решение. Конец правдивой истории.
источник
У каждой платформы есть хорошие и плохие стороны. .NET круто и мощно, но вы в значительной степени застряли на серверах Windows. Руби это круто, но медленно. Было бы трудно найти разработчиков для Haskell.
Дело в том, что язык влияет не только на то, как быстро будет выполнен проект и насколько красивым будет код, но и на тех, кто заботится о менеджерах. Так что, если вы хотите повлиять на них, вы должны теперь их предпочтения и найти как можно больше хороших сторон в их перспективе.
источник
Разделяя проблемы. Бизнес должен отвечать за деловые решения, а технологии - за технические решения. Мне нравится термин «Принятая ответственность». Если я принимаю ответственность, я также требую, чтобы я сделал выбор, который касается моей области проблемы. Бизнес дает мне и моим коллегам по технологиям требования бизнеса, и мы отвечаем одним или двумя вариантами того, как мы можем принять на себя ответственность за поставку. Это никогда не должно быть похоже на «мы сделаем это на Python или C #». Скорее;
Тогда бизнес выбирает, но обратите внимание, что бизнес выбирает, основываясь на влиянии на бизнес, а не на технические вещи. И они не могут выбирать между альтернативами, где технология не готова принять на себя ответственность технической части.
источник
Станьте менеджером. (Гринь)
Серьезно, вам просто нужно обсудить этот вопрос с лицом, принимающим решение, и выдвинуть свои аргументы. Если они решат придерживаться действительно неправильного решения, то их общая компетенция, вероятно, не так уж высока, и, возможно, стоит поискать что-то еще, что можно сделать.
источник
Я думаю, что разница между тем, о чем вы говорите, и тем, о чем говорил Джоэл, заключается в том, что программирование является основной компетенцией, а бухгалтерский учет - нет. Смысл использования Quickbooks, по-видимому, заключается в том, что вы не являетесь бухгалтером, и бухгалтеры могут помочь вам в этом. Однако, если программирование является вашей основной компетенцией, и, вероятно, это так, если вы программист, то правила игры немного другие.
источник
Это очень сильно зависит от личности менеджера:
Есть те, которые идут на модные слова. Просто узнайте, какие модные слова им нравятся, и используйте их, когда говорите с ним в сочетании с языком, который вы хотите использовать.
Другие будут доверять только тем вещам, которые они сами знают (например, VB 6.0). Сделайте ваш язык понятным для них («вы знаете, это так же, как в старом добром VB» - даже если вы говорите о Haskell ...)
Но на самом деле большинство менеджеров не так глупы, как нам нравится думать, и их можно аргументировать. Здесь важно то, что вы понимаете их точку зрения: они обычно не заботятся о конкретных технических деталях, они заботятся о результатах. Так что не говорите им, что .net, Java или Delphi, или что-то еще, обладают потрясающей функцией megacool Скажите им, что (введите ваш язык здесь) - хороший выбор, потому что функция A позволяет сократить время разработки в подобном проекте, или эта функция B уменьшает количество ошибок и, следовательно, сокращает время, необходимое для тестирования. Просто убедитесь, что ваш аргумент обоснован, не лгите ему.
Другими словами: относитесь к нему как к разумному существу (он, вероятно, есть).
источник
Подумайте о языке, который вас просят использовать очень и очень усердно. Убедитесь, что вы знаете, что это не очень хороший язык для работы, а затем спросите менеджера, можете ли вы предложить другой более подходящий язык для работы. Предоставьте любую информацию, которую вы можете подтвердить, что этот язык не подходит для работы, и посмотрите, что он говорит. Это не может повредить. :)
источник
Выбор языка программирования часто является бизнес-решением. Клиенты / пользователи не заботятся. Вот короткая цитата (с http://www.ericsink.com/bos/Geeks_Rule.html ):
источник
Во-первых, программирование - это еще одна форма искусства. Очень логичная форма искусства. Если ваш менеджер увлекается своими необычными программными проектами, которые в какой-то степени являются работами шедевра, то попросите этого увлеченного менеджера следующее:
Сколько сил и время это стоили бы Рембрандта дополнительной не рисовать его любимую кисть, а кисть , что после тщательного изучения команды управления, передаются ему, 400 лет назад , и до его работ становится известной. Будет ли его картина более или менее стоит думать?
Точно так же, если вы говорите программисту, какой язык следует использовать, будьте последовательны, а также сообщайте художнику, какие размеры кисти следует использовать! ИЛИ, в качестве альтернативы, просто оставьте этот выбор людям, которые должны работать с ним каждый день и (как большинство шедевров) ночь!
источник
Это разные понятия.
При учете вы делитесь своими результатами: по налогам, законодательству, инвесторам и т. Д. Им нужен инструмент, чтобы увидеть результаты вашего труда, и этот инструмент должен быть хорошо известен.
При программировании вы используете любой инструмент, который вам нужен - до тех пор, пока он выводит
.exe
файл, который вы можете запустить в Windows. Это в точности то же самое, что читаемый документ Quick Books в случае бухгалтерского учета.Итак, если вы разрабатываете тостер, вы можете хранить свою внутреннюю документацию на китайском языке, но вам лучше предоставить руководство на английском языке.
Есть еще одна вещь: если правила вашей компании предполагают, что результатом вашего кода является не сам продукт, а его исходный код, то они наверняка могут решить, как он будет выглядеть (выбрав нужный язык).
То, что они выбирают, зависит от их целей: если они хотят легко заменяемых программистов, они выбирают Java; если они отправят его в другой отдел, это будет требованием этого отдела и т. д.
источник
По моему опыту это всегда зависело от:
Если проекту не нужно что-то, что обеспечивает только конкретный язык / платформа / технология / инфраструктура, это сводится к тому, что мы уже знаем и используем. И нанимать новых людей и обучать существующих программистов довольно дорого для большинства компаний. При приеме на работу мы всегда учитываем язык и следим за тем, чтобы кандидаты знали, какой язык (языки) они будут использовать.
Надеюсь, у вас есть программист, который также является менеджером и может представлять программистов в таких решениях. Если нет, то это опасная ситуация, и вам следует поговорить с вашим менеджером, если вы знаете, что такое решение принимается.
источник