В настоящее время я внедряю Scrum и перехожу на Ruby on Rails в своей организации. У нас есть команда из шести разработчиков, только двое из которых имеют опыт работы с Ruby on Rails. Двое других разработчиков относительно быстро осваивают Rails, а третий неохотно, постоянно жалуется на Rails и на то, как ей не нравится фреймворк.
Я предоставил моральный коучинг, а также несколько ресурсов для них, чтобы они прошли кривую Rails как можно быстрее, но я просто не могу привлечь этого человека к участию в наших целях Sprint и рабочих инструментах (например, Rails). Как только она чем-то расстроена, она впадает в ментальный блок, который раздражает остальную часть команды (включая меня, хотя я спокойно отношусь к событиям). Я думаю, что это скорее истерика или подгонка, чем реальная техническая проблема с точки зрения изучения фреймворка.
Любые идеи или отзывы, которые могут помочь мне стать лучшим менеджером и, надеюсь, привлечь этого человека?
Лучший способ, который я нашел, чтобы помочь всей команде или отдельному члену команды присоединиться к новому проекту/технологии/навыку/необходимому злу, — это «подрывная деятельность». (обратите внимание на ироничные цитаты)
Человек, который категорически против определенной технологии (в данном случае), явно чувствует себя изолированным или игнорируемым, или что его статус в группе подрывается. Таким образом, ваша работа в качестве продакт-менеджера всегда будет включать в себя управление личностями вашей команды, и это не исключение.
Люди хотят чувствовать, что их положение защищено, их вклад и мнение ценятся, их голос услышан. Так что вам придется проанализировать, почему этот человек чувствует то, что он есть.
Итак, как только вы выяснили основную причину (а приведенные выше описания являются лишь некоторыми из них и, вероятно, НАМНОГО упрощены), вы, как менеджер проекта, должны повторно подтвердить ее положение в группе, дав ей работу, которая облегчит ее ум. Так...
Все эти решения, конечно, упрощены, но мы надеемся, что они дадут вам представление о том, как заставить всю вашу команду и одного несогласного разработчика «купиться» на новый фреймворк Rails. Заставьте их владеть им. Ответьте на их возражения, запросив их решение в рамках фреймворка (т. е. отказ от Rails — это не ответ). Если вы сможете сфокусировать разработчика на деталях преодоления его собственных возражений, вы получите необходимую поддержку и более спокойную команду.
Поскольку я слышал только вашу точку зрения, я не хочу предполагать, что проблема в человеке, о котором вы говорите. Хотя я согласен с тем, что проблема существует , проблема связана с людьми, процессами и управлением изменениями. Это потребует от вас признать это, прежде чем проблема может быть решена к чьему-либо удовлетворению.
Скорее всего, вам нужно будет внести некоторые изменения в состав вашей команды. Это не обвинение члена команды; просто эффективное управление изменениями иногда требует кадровых изменений.
Если вы зададите этот вопрос на другом сайте вопросов и ответов, таком как Workplace SE , вы можете получить другой ответ. Однако с точки зрения управления проектами, и особенно с точки зрения Agile, вы не реализовали организационные изменения должным образом.
В программировании вы меняете одну простую вещь за раз, чтобы вы могли ее отлаживать. Вы изменили как минимум две сложные вещи одновременно и изо всех сил пытаетесь их отладить.
Scrum (или любая другая структура управления проектами) требует обучения и времени для эффективного внедрения. Кроме того, agile-фреймворки требуют участия всей команды, а не только руководителя проекта.
Если у вас есть члены команды, которые не заинтересованы в agile-практиках или церемониях Scrum, и вы действительно исчерпали все обучающие моменты и возможности для коучинга, тогда вам нужно взять на себя ответственность за то, что вы прописали структуру, не создав сначала бай-ин. После этого вам нужно сформировать команду, состоящую из самоорганизующихся людей, которые хотят следовать agile-структуре.
Что касается работы, вы внесли множество изменений в должностную инструкцию команды, в том числе изменили:
Если вы изменили все это, вы, вероятно, также изменили продукт, который вы создаете. Это большие изменения в описании работы человека, и не все в ИТ хотят быть кросс-функциональными или изучать новые языки и фреймворки, которые не соответствуют их когнитивным моделям.
Некоторым нравится возможность использовать новые технологии или работать над новым проектом, в то время как другие предпочитают стабильность и оставаться в четко определенной зоне комфорта. Если вы только что сменили чью-то должностную инструкцию с .NET или Java-программиста в магазине водопада на разработчика Ruby on Rails в организации Scrum и/или DevOps, наверняка найдутся люди, которые не смогут или не захотят переключиться.
Если команда не вносила это изменение в стек технологий, тогда руководство должно быть готово взять на себя ответственность за изменение должностной инструкции. Более того, как высшему руководству, так и руководителю проекта следует ожидать переобучения и реформирования команды вокруг нового стека технологий.
Не все изменения являются обязанностью работника. Здорово, что у вас есть пять из шести ваших нынешних членов команды, работающих с новыми проектными и технологическими фреймворками. Теперь ваша задача определить, есть ли роль для тех, кто не соответствует вашей новой ИТ-модели.
Возможно, этот человек может взять на себя другую роль в компании или команде. Может быть, есть другие проекты или другие команды, над которыми может работать этот человек, которые могут представлять для него больший интерес. Если нет, вы, по сути, говорите: «Примите новую парадигму или найдите новую работу».
Как бизнес, это не может быть необоснованной точки зрения. Однако с точки зрения построения команды вы, как правило, добьетесь лучших результатов, если признаете, что не каждый человек подходит для каждой команды или организационной культуры. Имейте это в виду, если и когда вы решите внести изменения в состав своей команды, поскольку ничто так быстро не разрушает сплоченность команды, как обвинение работников в результатах стратегических решений бизнеса.
Относитесь к этому как к изменению требований к работе, а не как к межличностной проблеме. Это не только более конструктивный подход, чем попытки возложить вину, но и с большей вероятностью приведет к объективному решению.
Дело в том, что Rails — устаревший, медленный, глючный фреймворк.
Я предполагаю, что вы были вынуждены взять на себя часть работы над унаследованным проектом, которая обязывает его использовать, но вы должны признать, что работа над этим проектом не пойдет на пользу карьере ваших разработчиков.
Если вы не компенсируете их повышением заработной платы, работой из дома, меньшим количеством часов или чем-то еще, хорошие люди пойдут работать в другое место.
Решение простое. Спросите разработчика: «Если бы вы были фрилансером, сколько бы вы брали за проект на Rails по сравнению с проектом на «любимом языке»?» Затем заплатите им дополнительный процент
нвоигт