Ответственность заказчика

На этой неделе на портале были опубликованы две заметки, вызвавшие внутренние дискуссии в коллективе. Первая о вреде жонглирования приоритетами задач, которые уже были приняты в работу, за авторством Олега Скрынника. Вторая, о роли и месте тимлида в хорошей продуктовой команде Павла Капусткина.

Безопасность vs Эффективность

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

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

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

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

Идеальная картина мира с единорогами и бабочками.

Так не бывает!

Хорошо! С некоторой натяжкой можно убедить себя в правдивость этой идиллии, если каждый член этой команды — ее инвестор или со-основатель и напрямую заинтересован в успехе инициативы, является выгодоприобретателем. Причем, даже в этом случае, найдется место различным шороховатостям.

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

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

В чем же состоит единственная, но от этого не менее принципиальная ответственность заказчика?

В том, чтобы быть недовольным!

Продукт (в максимально широком смысле) который получает от команды заказчик всегда — отвратительный!  Качество — могло было быть выше, стоимость — еще меньше (даже есть прямо сейчас уже бесплатно), продукт предоставляется недостаточно быстро, не приносит ожидаемого удовольствия и выгод, заставляет и принуждает к чему-либо, приносит недостаточно выручки, плохо удерживает пользователей, обладает низкой конверсией, медленно наращивает пользовательскую базу. То, что заказчиком в сторону этой конкретной команды был сделан определенный выбор означает лишь то, что все остальные команды были на тот момент еще хуже! Невыносимо!

Ответственное отношение к роли заказчика — непростая ноша, но только она позволяет сжимать площадь треугольника «Качество-Сроки-Стоимость».

Ответственность заказчика не позволит продуктовой команде работать сколь-либо продолжительное время в условиях наличия безусловной поддержки и отсутствия ограничений. Любой банкет всегда происходит за чей-то счет.

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

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

Если говорить о безопасности и защищенности каждого из участников, то состав участников команды не статичен: коллеги переезжают, переводятся, выгорают, занимаются дауншифтингом, меняют профессию, находят более выгодные предложения. На смену ушедшим приходят новые люди. Все понимают, что каждый может и должен быть заменяемым, что бы ни происходило. Гарантия результата не должна  быть завязана на отдельных персоналиях. Даже если в команде останется 20% от ее состава, то качество ее результатов не должно упасть. Скорость развития незначительно упасть может, а качество сервиса и итогового продукта — нет.

Если вы все еще думаете, что понимание безальтернативной взаимозаменимости улучшает чувство защищенности, то можно вспомнить и про банальные межчеловеческие вещи, которые просто случаются и иногда всплывают в профессиональных спорах. Навроде: «Знаешь, Максим, мы много спорим последнее время по архитектуре, ты перегибаешь. Мы не сработаемся. Команда решила с тобой попрощаться. Успехов.».

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

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

В свою очередь, члены команды, что бы ни случилось, получают три защищенных от посягательств третьих сторон актива:

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

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

Ответственность за принятые в работе решения все равно наступает, даже если это чистый RnD и проверка гипотез — заказчика не волнует путь которым вы идете, ему важен достигнутый результат. 

Это честная сделка.

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

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

Будьте ответственны в своих решениях и поступках!

DevOps Основы DevOps

Популярный трёхдневный учебный курс
 

Проект Феникс — DevOps на практике

Полезная деловая игра для вашей команды
 

Узнайте больше!

Комментарии и мнения

  1. Дмитрий Толоконников

    Андрей,

    а разве фраза «уже после второго цикла отчетности она[продуктовая команда] может готовиться быть разогнанной, с вручением черных меток в профессиональном поле для ее участников» не относится к тому же мифическому миру с единорогами? Можете поделиться, откуда у Вас такое мнение?

    Было же множество мертворожденных продуктов, проваленных внедрений, ошибок маркетинга и PR и т.д. Но это не помешало сотрудникам строить успешные карьеры.

    1. Андрей Труфанов Автор

      Дмитрий, такое мое мнение опирается на следующем принципе: отношения внутри команды и отношения команды с окружающей ее действительностью, позволяющие ей эффективно и продуктивно создавать новое, основываются на доверии. Если команда нарушает взятые на себя обязательства однократно — ок, бывает, случается всякое, но если это начинает происходить системно, то это становится разрушительным.

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

      Если команда начинает системно врать своим заказчикам (а значит и врать самой себе, в итоге), то работать с теми ее членами, которые принимали те или иные решения, будет рискованно. Те, кто лидером не был, вероятнее всего почти не пострадают в части карьерной перспективы.

      К сожалению, или к счастью (не знаю), мир ИТ-профессионалов сейчас очень сильно сегментирован по узким областям компетенций. Ведущие эксперты почти в каждой из этих областей знакомы в той или иной форме, а значит известны и их проекты/результаты. Этому дополнительно способствуют соцмедиа, конференции, экспертные ресурсы и другие способы обмена информацией, знаниями и опытом.

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

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

      Надеюсь, что ответил. Спасибо за вопрос.

  2. Дмитрий Толоконников

    Андрей, спасибо за развернутый ответ.

    Просто при первом прочтении статьи сложилось впечатление, что основной посыл слишком категоричен: «Продукт (в максимально широком смысле) который получает от команды заказчик всегда — отвратительный!», «Ответственность заказчика в том, чтобы быть недовольным!» и т.д. Ведь такое отношение (всегда недовольный) как правило убивает доверие и мотивацию. Зачем стараться, если результат по умолчанию оценивают как отвратительный?

    Я согласен, что команда должна соблюдать взятые на себя обязательства. В этом плане очень полезна упоминаемая в тексте статья Олега о вреде жонглирования приоритетами задач. Ведь изменение приоритетов — это не «искусственные ограничения» эффективности работы команды, а изменение контекста, на основании которого были приняты обязательства. Как правильно написал Олег, это не бесплатное действие. Поэтому наивно предполагать, что ВСЕГДА взятые ранее обязательства могут быть исполнены. На коротких отрезках планирования (например, спринты из фичей) достаточно передоговориться. На длительных отрезках приходится перезакладываться.

    P.S. По поводу Skype вопрос немного спорный. Тех же рядовых QA или разработчиков я бы не стал сразу обходить стороной. Как Вы правильно написали — неизвестно, что там внутри происходило.

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

НОЯ
18
Учебный курс:
Release, Control and Validation (ITIL RCV)