Портал №1 по управлению цифровыми
и информационными технологиями

Мотивация разработчика В2В продукта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

 

«Трансформация ИТ в традиционных компаниях»
Учебный курс о кратном ускорении за счёт новой организации работы

Комментариев: 4

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

    Это, конечно, очень категоричное утверждение. Понятно, что оно сделано для усиления, но всё же – очень категорично. Жизнь вокруг нас показывает, что случаи бывают разные, в том числе годами программирующие *ничего* разработчики.

    А в остальном, Андрей, согласен. Очень хорошая памятка получилась. И я знаю кому её можно порекомендовать 🙂

    • Олег, спасибо.
      Я закостенелый ретроград, поэтому считаю, что если мы говорим о командах и о продуктовом подходе, как о принципе, то беседа должна вестись в терминах “наилучшего”. Иначе зачем все это? Если компании нужно “просто сделать работу”, то может быть можно просто купить ее, аутсорсить, использовать более дешевые коробочные стандартные решения? Не упираться и не гиперинвестировать там, где это не будет эффективно? Написано действительно жестковато и реальность приземлит “юного натуралиста” (тут ты на 100% прав), но концепт, как мне кажется – верен.

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

    Этот вопрос вечно вызывает холивары. Звать команду “кодеров” на обсуждение важных “стратегических” вопросов? Многие будут аргументированно доказывать, что ни в коем случае.

    Моё мнение базируется на моём опыте: я ещё ни разу не видел негативных эффектов от такого привлечения (неумение планировать время и соблюдать баланс – не в счёт). Так что, да, присоединяюсь к рекомендации.

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


Добавить комментарий для Андрей ТруфановОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM