Как быть с сотрудником, который хочет использовать новые фреймворки в программном обеспечении для критических систем, но я не

Заботится ли разработчик только о себе, а не о команде/проекте?

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

Они лучший разработчик, чем я, и говорят, что «новый фреймворк» позволит «ускорить» разработку.

Вы цитируете здесь «быстрее». Я не уверен, что вы не верите разработчику в этом вопросе или сомневаетесь в его ценности.

Но, с моей точки зрения, надежная доставка и ремонтопригодность важнее.

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

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

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

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

Если вы менеджер по персоналу, то вы принимаете решение. Хорошо, если все согласны, важно, чтобы все уважали решение.

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

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

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

И после того, как это будет сделано, вы можете посмотреть на приоритеты. Т.е. для одного проекта или части проекта, возможно, интерфейс должен выглядеть модно, а может быть, это проще сделать с новым фреймворком. А с другой стороны, возможно, более важно, чтобы все было на 100% стабильно, даже если это займет больше времени и т. д.

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

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

Заботится ли разработчик только о себе, а не о команде/проекте?

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

Если они недовольны здесь, должен ли я заставить их уйти?

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

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

У вас есть две проблемы, которые могут противоречить друг другу

1. Управление «техническим стеком»
2. Управление техническим специалистом

Управление «техническим стеком» — это решение о том, какие языки, инструменты, фреймворки и системы тестирования компания будет использовать, особенно для критически важной производственной работы. Ни одному разработчику не должно быть позволено изменять этот стек. Это решение, которое идет вверх по цепочке инстанций, поскольку оно влияет на соблюдение требований и аудит вашей компании. Многие разработчики не осознают всех связанных с этим затрат. Если ваше высшее руководство не участвовало в этом до этого, я рекомендую сделать для них презентацию того, в чем на самом деле заключаются проблемы — почему у вас текущий стек технологий, какова стоимость внесения любых изменений и как вы будете представлять изменения в их в будущем. Короче говоря, вы тянете всю свою управленческую цепочку, чтобы поддержать вас в вашем выборе. «Разработчик, это технический стек корпорации XYZ.

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

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

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

Например: «Мой нынешний работодатель занимается производством диванов более 85 лет». Когда IBM впервые представила System/36 , они ее купили. Когда «RPG» был лучшим языком выбора, они написали горы кода, используя его ... и они до сих пор продают диваны!» (И: «Эти диваны все еще удобны — уверен, вы знаете кого-то, у кого есть такой».)

Таким образом, существует и всегда будет «дихотомия» между технологиями, которые мы решили использовать, и технологиями, которые сегодня мы предпочли бы использовать, если бы они еще были изобретены. Но мы никогда не можем ожидать, что "новые программисты" поймут это... пока. 🤷‍♂️