Команда создания и развития продукта состоит из разных людей: разработчиков, аналитиков, QA, владельца продукта и, иногда, из иных участников. Основной костяк этой группы обеспечивает непрерывную работу производственной системы (как минимум в части “downstream”) по созданию и поставке фич, на основании содержимого бэклога. Производительность, эффективность этого конвейера – прямая ответственность членов команды. 

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

Разработчики, конечно, любят кодить, любят свою работу (те кто не любят – не работают разработчиками, дураков нет), но в роли роботов живут не долго, и компании приходится с ними прощаться.

Что можно сделать, чтобы избежать этого печального исхода?

Сделайте их соучастниками происходящего!

В особенно запущенных случаях разработчик разрабатывает фичу, кладет ее в мастер ветку и забывает про нее, ведь перед ним в pull листе уже лежат новые задачи.

В ITIL4 есть множество довольно спорных управленческих концепций, но определение ценности, ради которой, как нам казалось, мы все собрались, как результата совместной деятельности/работы (co-creation) поставщика и потребителя, здесь будет как нельзя более кстати.

Задача разработчика не разработать фичу, а совместно с остальными членами команды изменить ею мир, даже если мы говорим о внутрикорпоративном продукте с одним пользователем.

Прозрачность общего результата работы команды

Нужно не только измерять востребованность фичи (“2,5% пользовательской базы открыли меню и сразу закрыли его”), но и делать видимым то, как это повлияло на поведение потребителей: “появились негативные отзывы”, “появились запросы на … в связи с новой опцией”, “презентация фичи на митапе вызвала фурор и бешенный спрос”.

Увеличение показателя конверсии на 0,07% ( на 0,7% и даже на невероятные 7%) никак не мотивирует Java разработчика: для него это просто ничего не говорящая цифра. Даже если фичи оформлены как пользовательские истории в терминах персон, то это всё равно остается абстрактной конструкцией, гипотезой до того момента, как команда не получает обратную связь из реального мира.

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

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

• Инвестируйте время и силы владельца продукта в прозрачность работы команды и ее общих результатов, в совместное принятие решений. Не создавайте новые колодцы, не делите на “мы и они”.
• Привлекайте команду к исследовательским активностям этапа upstream вашего производства, направленного на формирование бэклога, идентификацию и выявление новой ценности, приносимой продуктом.

Тактильность пользовательского опыта

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

Публичность и признание

Одной обратной связи от пользователей может быть, в силу ряда причин, не достаточно, и в этом случае мощной мотивацией может являться публичное и/или профессиональное признание результатов работы команды.

Ваша команда:

• Разрабатывает самый крутой в мире продукт?
• Владеет черными поясами по успешной внутрикомандной работы?
• Является носителем ноу-хау по эффективному использованию инструментов?
• Умеет и любит разговаривать с бизнесом и потребителем, и в ходе бесед стороны прислушиваются и понимают друг друга?

Расскажите об этом: конференции, митапы, стажировки. Вне и внутри компании. Классными результатами и опытом приятно гордиться и вдвойне приятно делиться.

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

Безопасность в основе всего!

• Физическая безопасность
• Безопасность высказываний и обсуждения мнений
• Отсутствие поиска виновников
• Презумция добросовестности и профессионализма

Обратите внимание на то, как ведутся беседы, обсуждения, принятие решений.

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

Экология труда

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

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

Вместо резюме

ИНТЕНСИВ С ТРЕНЕРОМ

Трансформация ИТ в традиционных компаниях

Учебный курс о кратном ускорении за счёт новой организации работы