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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

 

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

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

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

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

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

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

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

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

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

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

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


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

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

  • Рубрики

  •  
  • Авторы

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

    • Открыта регистрация на вебинар «Какой SLM нам нужен?»
      22 апреля в 11:00 по московскому времени приглашаем вас на бесплатный вебинар «Какой SLM нам нужен?» Управление уровнем услуг — тема далеко не новая, но и …
    • Путешествие заказчика. Примеры. Часть 2
      Новый видеоролик продолжает серию, посвящённую концепции путешествия заказчика (customer journey), рассматриваемой на учебном курсе ITIL® 4 Specialist: Drive Stakeholder Value …
    • Поток создания ценности — поток создания чего?
      Прочитав замечательную статью моего коллеги «Все говорят: «Поток!». А ты построй поток» и возникшую после неё дискуссию, я подумала, что довольно часто сталкиваюсь с вопросом, а …
    • Service science в основе ITIL 4
      В редакцию портала поступил вопрос: Здравствуйте!  Роман Журавлёв в статье «Главное про ITIL 4» "...отнес к важным преимуществам то, что ITIL 4 опирается на такую …
    • Все говорят: «Поток!». А ты построй поток
      «А это была совсем не шляпа. Это был удав, который проглотил слона. Тогда я нарисовал удава изнутри, чтобы взрослым было понятнее.»Антуан де Сент-Экзюпери, Маленький принц Переход …
    • Роль лидера в продуктовой команде
      Довольно много людей полагают, что ключ к развитию потенциала и расширению возможностей продуктовых команд — это вежливо дать понять их руководству, чтобы они перестали …
    • Канбан-метод будет принят в качестве национального стандарта РФ
      Федеральное агентство по техническому регулированию и метрологии Росстандарт совместно с инициативной группой признанных российских экспертов по Канбан-методу объявило о начале …
    • Коммуникации в гибридной команде
      Благодаря неумолимой поступи нашей новой нормальности всё явственнее проявляются контуры будущей организации труда. Всё очевиднее становится понимание, что работа будет …
    • DevDays Moscow пройдут 8-10 июня
      С 8 по 10 июня в Москве пройдёт конференция DevDays Moscow, посвященная разработке программного обеспечения. В программе конференции Актуальные доклады (40+ спикеров) 7 …
    • Инцидент – как много в этом слове…
      Вы когда-нибудь задумывались над смыслом этого слова? Что оно значит для вас? Готов поспорить, что ответ на это вопрос будет на 100% зависеть от контекста! Но этого мало. Вам надо …
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT