Выбор языка программирования должен быть командным или управленческим?
Я только что поговорил со своим сотрудником о стандарте языка программирования для отдела. Он чувствовал, что выбор языка программирования должен оставаться за командой проекта. Я считаю, что руководство должно принять общее решение о том, какой язык используется. Если два языка соответствуют критериям проекта, следует ли учитывать желание команды? Я бы хотел услышать, как все это переживают.
24 ответа
Имейте в виду, что руководство может сохранять код, если / когда команда разработчиков движется дальше, также им нужно нанять новых кодеров, чтобы поддерживать его в будущем. Итак, если команда хочет выбрать erlang или haskell, то руководство несет ответственность перед компанией, чтобы сказать "нет". (извините, что выбираю разработчиков Erlang и Haskell, но о вас не так много).
Как правило, в этом и заключается проблема - команда хочет использовать что-то, что в какой-то мере им выгодно, но основное внимание следует уделить будущему кода, который принадлежит компании и оплачивается компанией (то есть вашей заработной платой). Они должны обеспечить его поддержку в будущем.
Они также будут платить за ваше обучение, так что это в значительной степени зависит от руководства.
Команда может вносить предложения и пытаться повлиять на решение, и я уверен, что все, кроме худших компаний, будут внимательно прислушиваться к команде, но решение ее руководства в конце концов.
Я думаю, что командный дух сильно пострадает, если они скажут: "Мы бы хотели использовать этот язык". и руководство говорит: "Нет, вместо этого вы должны использовать этот язык".
Это действительно должно быть совместное решение, и каждый должен подтвердить свои аргументы.
Это на самом деле замаскированный вопрос "доверия".
Когда у руководства есть доверие, выбор не составляет никакого труда (пусть это решают технические специалисты).
Я бы посоветовал любой команде, проходящей через эту ситуацию, взглянуть на основную проблему доверия, а не фокусироваться исключительно на языковой проблеме.
Сосредоточьтесь на основной причине, и результат / симптом сработают сами собой.
Да. Обе группы должны иметь вклад. Многие различные аспекты также должны быть рассмотрены за пределами предпочтения, хотя это может быть важным. Рынок труда (способность нанимать на работу новых людей), языковая поддержка, инструменты и т. Д.
Реальный вопрос заключается в том, в чем преимущество выбора одного языка перед другим:
Функциональность: что может сделать работу лучше как сейчас, так и в будущем? Окажется ли это технологическое решение надежным решением для будущего этого проекта, и меня это вообще волнует (конечно, с позиции менеджмента)?
Затраты: придется ли мне покупать дополнительное оборудование или программное обеспечение для этой технологии? Хочу ли я застрять с этим оборудованием / программным обеспечением? Опытный персонал знаком с предлагаемыми технологиями или мне придется нанимать новую кровь?
- Время: Сколько времени потребуется, чтобы использовать эту технологию? Я собираюсь научить людей пользоваться этим?
В том-то и дело, что руководство должно задавать эти вопросы, а развитие должно быть для них обоснованием.
Ваша первая забота должна быть о том, делает ли язык работу. Марк Твен сказал: "Для человека с молотком все выглядит как гвоздь". То, что команда знакома с языком, вовсе не означает, что это лучший инструмент. С другой стороны, разработчики, которые хорошо владеют языком и являются экспертами в предметной области, будут более продуктивными, работая со своими собственными инструментами.
Второй проблемой является доступность разработчиков. Когда команда движется дальше, кто остался, чтобы поддержать это? Это может быть дорогостоящим, либо нанимать или переучивать на малоизвестный язык. Язык также может быть достаточно новым, чтобы база разработчиков не материализовалась.
Третья проблема - доступность / стабильность инструмента. Вам придется делать постоянные переписывания каждый раз, когда меняется язык (я думаю о VB/.Net). Кроме того, кто поддерживает это? Что происходит с языком, если продавец отказывается от него?
Короткий ответ тогда таков: если у команды есть предпочтения, они должны представить веские аргументы в пользу своего выбора; достаточно убедительным, чтобы убедить босса, что откаты продавца не стоят хлопот. Постарайтесь понять аргументацию руководства, чтобы вы могли принять решение, если не можете опровергнуть его.
На мой взгляд, это очень сильно зависит от ситуации.
Конечно, вы должны принять во внимание их желание, но одна важная вещь, которую стоит учесть, это то, на каком языке команда будет работать наиболее продуктивно. Также большой вопрос, который иногда игнорируется, это то, кто будет поддерживать проект в долгосрочной перспективе и каковы их компетенции?
Последнее для меня довольно большое, слишком часто программист уходит в каком-то странном направлении с какой-то передовой технологией, главным образом потому, что он / она хочет "попробовать" или потому что это ново и горячо. В этих случаях о техобслуживании часто забывают, и он возвращается, чтобы укусить компанию, как только этот программист ушел и кто-то другой должен взять на себя обслуживание проекта.
С другой стороны, если ваша команда очень сильно к этому относится, стоит ли вызывать раскол?
Итак, еще раз, в конце концов, это зависит от вашей ситуации и типа проекта.
Я думаю, что есть опасности с обоих подходов. Программисты могут стремиться использовать крутые и забавные новые технологии, а менеджмент может использовать продвигаемые на рынке или коммерциализированные технологии (но непопулярные в команде разработчиков anti-microsoft;)).
Должен быть кто-то в роли архитектора, который может взаимодействовать с обеими группами и принимать объективные решения, основываясь на бизнес-целях и проблемах разработчиков. Этот человек должен понимать общие цели системы, взвешивать инфраструктуру, необходимую клиентам, надежность и поддержку технологии. и т.д.... конечно, это зависит от размера компании / проекта относительно влияния этих решений.
Конечно вклад команды это важно. Если вы примете решение о главном архитектурном элементе вашего приложения, и команда почувствует, что они не приняли в нем участия, у вас возникнут моральные проблемы. Решение в конечном итоге должно быть принято руководством (при условии, что управление носит технический характер) и ведущими архитекторами и руководителями проектов.
Но при выборе языка важно помнить, что у вас будет больше шансов на успех, когда команда станет более знакомой и довольной вашим выбором. Если вы прислушиваетесь к тому, что они говорят, а затем приходите к ним с конкретными деловыми и техническими причинами, почему вы не выбрали их выбор, то, по крайней мере, они чувствовали ложь, их услышали и стали частью процесса.
В конечном счете, это должен быть выбор руководства только потому, что они несут бремя последствий, если программисты уходят, а также представляют интересы компании в выборе. Выбор языка должен учитывать не только способности / наборы навыков текущей команды программистов, но также всех будущих членов и любого вспомогательного персонала с точки зрения рыночных навыков. Вы не хотите выбирать слишком малопонятный язык, если это означает, что вы не можете найти квалифицированных людей для его поддержки. Кроме того, если язык подходит к концу своей популярной / поддерживаемой жизни, существует риск того, что он устареет до такой степени, что его нужно будет переписать раньше, чем можно было бы надеяться.
Я делаю широкое предположение, что удобство сопровождения, возможности и тип выбора языка не принципиально различаются (т.е. ML против C++).
С учетом всего вышесказанного, если учитывать эти факторы и в противном случае выбор языка будет сделан на равных, то использование языка в команде будет наилучшим для морального духа и приведет к созданию лучшего продукта без ущерба для долгосрочных перспектив развития. приложение.
Выбор языков для проекта должен включать предпочтения команд, не переопределяющие правильные выборы для проекта и его среды.
Команда программистов должна иметь больший опыт работы с языками, включенными в короткий список, чем команда менеджеров, поскольку именно для этого они были наняты, и они должны быть технически более квалифицированными, чтобы судить, какие технологии будут лучше подходить для них для работы.
Только если управленческая команда, по крайней мере, обладает такой же квалификацией и опытом в выборе, они должны пытаться влиять на совместный выбор команды, если только эти решения не связаны с нетехническими последствиями для бизнеса, и они должны быть представлены на рассмотрение.
Хороший менеджмент, давайте сделаем так, чтобы сотрудники делали то, что они наняли, и делали разметку, где могли, поэтому ИМХО выбор должен быть делегирован команде разработчиков.
Удачная команда программистов будет более продуктивной, в итоге получит лучший результат и не будет ворчать, если у них возникнут трудности с выбором.
Руководство должно больше заботиться о том, чтобы окончательный проект был завершен вовремя, в рамках бюджета и с положительным результатом, а не с тем, какие технологии используются, если выбор не оказывает конкретного влияния на бизнес, которое необходимо учитывать.
Члены команды программистов и члены команды управления - все в одной команде, и необходимо учитывать все потребности, включая то, какие технологии члены команды программирования удобнее всего использовать и считают наиболее подходящими для любого проекта, ИМХО, это должно быть главным соображением, только отвергнутым деловыми потребностями или фактическими техническими соображениями.
Просто для того, чтобы определить вескую деловую причину отказа от поддержки команды разработчиков, может оказаться, что технология не была достаточно распространенной, чтобы позволить замену члена команды по разумной цене из пула разумного размера или простого интерфейса с текущими или запланированными ресурсами.
Есть много вопросов к этому вопросу. В конце концов, человек (а), оплачивающий работу, делает выбор. Но:
Если менеджмент не умнее в кодировании, чем люди, которых они наняли, они должны учитывать их вклад. Руководство обычно не объясняет кодировщикам, что с каждым выбором языка связаны расходы, которые могут сделать другие варианты более желательными. Это порождает обиду у кодеров, когда они чувствуют, что их советы игнорируются.
Есть немало людей, которые имеют серьезные недостатки. Они знают только один язык, поэтому рекомендуют только один. Менеджмент, возможно, уже принял решение и будет игнорировать полезные советы своих сотрудников. Кодеры или менеджеры могут быть чрезмерными технофилами и будут принимать технические решения, даже если они не отвечают интересам проекта. У них также могут быть сильные мнения и недостаточная эмоциональная зрелость, чтобы другие не соглашались.
Сотрудники могут также сознательно предлагать вещи, не отвечающие интересам владельца проекта, потому что то, что они предлагают, отвечает их собственным интересам.
В основном я считаю, что выбор сделан по эмоциональным, а не рациональным причинам.
Мой опыт работы на нашем рабочем месте, менеджмент, обсудил с технической командой, где техническая команда дала предложения относительно языка программирования, с которым мы знакомы и с которым лучше всего работать. Затем руководство выбирает язык программирования, который использует отдел. Он должен работать в обоих направлениях, так как техническая группа должна чувствовать себя комфортно в работе с языком программирования (чтобы иметь возможность выполнять его по расписанию), а для руководства они могут планировать среднесрочные и долгосрочные планы в области бизнеса, управления ресурсами и обучения.
Я бы определенно проконсультировался с командой, занимающейся разработкой в то время. Дайте им проектный документ и получите их обратную связь. По крайней мере, это заставляет их чувствовать, что их решение имеет значение.
Менеджеры должны учитывать другие вещи, такие как стоимость обучения персонала на выбранном языке, стоимость покупки IDE (если требуется), стоимость обслуживания базы кода после завершения первоначальной разработки.
После того, как менеджер принял обоснованное решение, разработчики должны почувствовать, что они могут спросить, почему было принято конкретное решение. Оставьте решение руководству, но продвигайте прозрачность решения.
Я извиняюсь - но в какой другой отрасли инженерии это вообще был бы вопрос? Дизайнеры Boeing решили, что было бы круче использовать ракетные двигатели вместо турбовентиляторов?
Интересно, что выбор языка программирования должен быть таким важным вопросом для управления, в то время как в зависимости от сложной библиотеки или среды с открытым исходным кодом часто это делается без особого рассмотрения.
Исторически в этом была некоторая логика, потому что изменение языка программирования означало изменение платформ, но теперь, когда языки программирования стандартизированы для работы на платформах CLR или JVM, совместно используют библиотеки и среды развертывания, стоимость диверсификации для использования разных языков может быть меньше, чем в зависимости от сложных рамок.
Например, если вашему приложению требуется механизм правил, возможно, лучше использовать версию пролога JVM, чем полагаться на какой-то непонятный API механизма правил Java.
Вы должны принять во внимание команду, именно они это сделают. Если они не будут / не могут работать с языком, то это сделает проект очень трудным.
Очевидно, что руководство скажет последнее, это то, для чего руководство, но они должны принять во внимание предпочтения / предложения команды. Я думаю, что у них должна быть действительно веская причина, чтобы не выбирать язык, который предлагает команда
Хороший менеджер проекта позволит своим старшим инженерам принять это решение и выполнить свою работу: управлять проектом, т.е. защищать команду разработчиков от "верхнего уровня-управления-BS". Хороший менеджер проекта также потребует, чтобы его старшие инженеры подробно объяснили, почему они выбрали тот или иной язык программирования (если выбор языка вообще так важен). Если он не удовлетворен оправданием, я думаю, что это его работа - направить команду разработчиков в направлении, в котором каждый может жить и работать. Принудительный язык в команде разработчиков? Не хорошая идея. Проект будет обречен на провал.
Рассмотрим язык. Если это легко заполняемая позиция в программировании (то есть, если вы можете нанять кого-то в течение недели для выполнения работы одного из этих программистов - если они уйдут), то следуйте рекомендациям команды. Вы не поверите, сколько работы они будут выполнять, если вы дадите им хоть что-то сказать. В противном случае вам может потребоваться заполнить несколько позиций. Не ставьте на плохую экономику, удерживая разработчиков программного обеспечения на своих местах. Это на самом деле идеальное время, чтобы ходить по магазинам вокруг. Держите их счастливыми, но убедитесь, что выбор языка не какой-то неясный, мертвый язык.
Если ваши программисты лучше, скажем, на Java, чем на C#, то имеет смысл использовать Java, если любой из них будет работать. Как и в случае любого решения на этом уровне, у руководства могут быть причины для выбора того или другого. Они должны прислушиваться к команде, но окончательное решение должно быть за ними.
Согласитесь с другими постерами, что это должно быть совместное решение. Но - часто руководству приходится принимать более долгосрочные решения, чем просто команда проекта, например, текущее обслуживание. Таким образом, срок службы программного обеспечения может быть фактором. Если команда выбирает что-то, что не является общепринятым, у них всегда будет борьба на руках.
Кроме того, последнее слово обычно принадлежит заказчику. Если проект является внутренним, то заказчиком может быть только местное управление / техник. Для других клиентов команде понадобятся очень обнадеживающие причины, чтобы отбросить их желания.
Я чувствую, что разработчики действительно должны иметь право голоса на выбранном языке. Менеджеры в целом, похоже, имеют привычку использовать "модные слова". (Хорошо) Программисты, я надеюсь, будут знать лучший язык для работы, мнение, основанное на многолетнем опыте, которого может не хватить руководству.
Как и в большинстве вещей в жизни, необходимо достичь равновесия между тем, что хорошо / весело для отдельных лиц (каждого из членов команды) или для организации (что должно быть в центре внимания менеджеров).