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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

 

«DevOps: современный подход к организации работы ИТ»
Учебный курс про менеджмент, а не про технические практики

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

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

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

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

    • Олег, спасибо.

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

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

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

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

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


Добавить комментарий

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT