У меня более 13 лет опыта в IT, восемь из них — в менеджменте. Работая в разных проектах и компаниях и в различных управленческих ролях — от Team lead до Senior PM и PM Competence Manager — накопила большой багаж практических знаний. Причем знания эти позволяют ответить на многие вопросы из серии «почему в реальных проектах часто приходится действовать в разрез с теорией».
В статье хочу подробнее остановиться на формировании команды, которая сможет заниматься разработкой продуктов, а не только выполнять жестко поставленные задачи. Возможно, тем, кто и сейчас работает в продуктовых компаниях, многое здесь может показаться очевидным, потому что окружение диктует определенные паттерны поведения и управления. Для тех же, кто занят в аутсорсинге, такого рода знания, скорее всего, окажутся актуальными. Особенно если организация, с которой они сотрудничают, движется в сторону создания продуктов. Да и в сервисных компаниях некоторые партнерские проекты требуют подходов близких к продуктовым.
Подводные камни
Представьте себе ситуацию: вы собрали хорошую команду разработчиков и тестировщиков, полностью соответствующую изначальным требованиям, запустили проект и наладили процесс. Все в команде работает как часы — настолько четко, что в это даже трудно поверить. Но тут в дверях появляется главный стейкхолдер — неважно, внутренний или внешний заказчик — и сообщает, что он frustrated. И находится он в прострации, потому что совершенно не понимает, чем именно занимается ваша команда. В этот момент проджект-менеджер хватается за голову, ведь технологии определены, люди трудятся в соответствии с процессами, что не так? И зачастую поиск ответа на этот простой вопрос занимает очень много времени.
На самом деле, нужно разобраться, чего же хотел главный стейкхолдер.
Иногда можно подумать, что стейкхолдеру нужны люди. В конце концов, он может прямо заявить вам: «Мне нужны два программиста». Но в этом случае у вас уже начинаются проблемы.
Стейкхолдер может назвать вам продукт, который хочет получить. И здесь можно обратиться к классическому примеру с качелями.
Иногда достаточно просто спросить, зачем эти качели ему понадобились, чтобы понять — как раз качели ему точно не подойдут, или подойти ему могут не только качели. Например, чтобы «покачаться», иногда лучше обзавестись креслом-качалкой. Точно так же может выясниться, что для целей, о которых вам говорит заказчик, мобильное приложение подойдет лучше веб-сайта, за которым он к вам пришел.
Готовые решения, озвученные стейкхолдерами, зачастую оборачиваются проблемами для всех.
Чего хочет стейкхолдер?
Существуют различные подходы, позволяющие более детально разобраться в пожеланиях заказчика. Например, value proposition canvasили business model canvas. Только после того, как мы поняли, что в действительности беспокоит стейкхолдера проекта и что он может выиграть по его завершении, можно рассчитывать получить нужный ему продукт или сервис. Еще раз: если он просит у вас блокнот и ручку, получив их, возможно, останется таким же несчастным, как и до встречи с вами. Потому что вы не узнали, зачем они ему, и не предложили ему калькулятор, чтобы быстро совершить все нужные арифметические подсчеты.
Заказчики, которые просят двух программистов для работы — пример из реальной жизни. Правда, в итоге выясняется, что одному нужна команда для создания собственного сервиса, а другому — консультация по экспертизе, которой в его компании просто нет. В нашем случае, согласившись на сотрудничество в предложенном формате с самого начала, мы бы просто трудоустроили двоих разработчиков. Сейчас над этим проектом работает большая команда, при этом сам стейкхолдер счастлив — его идея получила развитие, которое необходимо заказчику. Оказались, что ему нужны не два программиста, а разработка продукта для рынка практически под ключ. Все работает благодаря переходу от парадигмы решений к изначальной парадигме проблем. Только после этого мы возвращаемся к решениям.
Продукты, сервисы, решения
Solutions — комплексное понятие, гораздо более широкое, чем сервис или продукт. Предполагается, что мы не просто создаем код, а консультируем заказчика, меняя что-то в процессах его собственной компании и предлагая новые услуги уже его пользователям.
Недавно я услышала, что украинские IT-компании часто недооценивают уровень собственной экспертизы, при том что многие успели поднять его достаточно высоко. В некоторых направлениях этот уровень сопоставим с крупными международными консалтинговым компаниями, однако продвижению экспертизы мешает привычка к существованию в парадигме «количества предоставленных специалистов». «Копая отсюда и до обеда», часто не удается принести счастья заказчику, хотя это и позволяет заработать на аутсорсинге. Правда, в долгосрочной перспективе этот подход выглядит спорным: если ваш клиент был «несчастлив», он вряд ли станет рекомендовать вас. Даже если вы выполнили свою часть работы четко и в срок.
«Вы меня не поняли», — стандартный ответ недовольного стейкхолдера. Неважно, что именно не сложилось, и как он сам объяснял задачу. Просто сейчас его сервис работает не так, как ему необходимо (причем понять разницу между тем, что хочет заказчик, и тем, что необходимо заказчику, — отдельная достаточно непростая задача).
Недавно на учебном модуле львовской бизнес-школы нам рассказывали, что отношение к процессам различается даже в разных городах Украины. И, например, Одесса — более продуктовый город — но в целом, когда берешь людей с рынка, лучше не рассчитывать, что каждый постарается вникнуть в реальные нужды заказчика. И если вы как проджект-менеджер уже научились дешифровывать его потребности, это еще не гарантирует положительного результата — вам предстоит поработать с командой. Ведь программисты часто уверены, что важнее технологии нет ничего, и только перейдя в роли, связанные с менеджментом, убеждаются, как часто все упирается в человеческое общение и отлаженность рабочих процессов.
Что мешает нам легко прийти к разработке solutions/services?
Для постсоветских стран один из пунктов — образовательная система. В средней школе нас продуктовому подходу никто не учит. Обычно там мы решаем абстрактные и при этом узкие задачи, не пытаясь рассчитать хотя бы площадь квартиры или расходы семьи на месяц. Никто не предлагает школьнику преобразовать полученные на уроке знания в какое-либо решение.
В высшей школе часто можно видеть то же самое: студент не имеет представления, как можно применить знания, полученные в течение семестра. Сейчас, правда, айтишники-практики стали появляться и в сфере IT-образования, но в большинстве вузов лидирует старый академический подход. Я сама окончила отделение автоматизированных систем управления, но пользу того, что мы изучали, в том числе системного подхода в целом, поняла только много лет спустя уже самостоятельно. Наша образовательная система может дать знания, но, к сожалению, как эти знания применять, мало кто говорит.
Следующим камнем преткновения становится недостаток информации. Обычно наибольшим объемом информации владеют менеджеры. Открытым остается вопрос, какую ее часть они готовы донести до остальных членов своей команды, как в целом ставятся задачи разработчикам или QA-инженерам. Если общая картина проекта не является общим достоянием — каждый будет копать свой маленький участок, не обращая внимания на соседей. Кроме того, отсутствие информации всегда дает повод сомневаться в качестве принятых решений и пользе собственной работы в целом.
Работая в больших командах, многие люди не знают о других составляющих продукта, частью которого они занимаются. Поэтому всех действительно необходимо собирать, объясняя общее направление, на забывая о классике аджайла, — груминг и планинг-сессиях. Если программисты знают, что через пару лет у нас планируется 200 тысяч пользователей против нынешних 200, архитектуру решений они будут строить по-другому. Именно так повышается качество решений на всех уровнях.
Все об этом знают, но иногда менеджеры просто забывают прийти к команде и пересказать полученную от заказчика информацию. И легко это звучит только на словах — я сама регулярно наступала на эти же грабли попросту из-за нехватки времени. Но если заказчик говорит, что ему необходимо интегрировать сервис распознавания речи, это может влиять на решения, которые принимают даже те программисты, которые работают над маленькими фичами, не имеющими к этому сервису прямого отношения. Менеджерам необходимо понимать: во время таких обсуждений многие будут сидеть с незаинтересованным видом (действительно, мы же не про код говорим ;), но информация все равно останется в голове у каждого.
Определение целей
Важную роль играет определение целей всех заинтересованных лиц. Для этого стоит найти ответы на вопросы:
- Зачем мы это делаем?
- Куда все движется?
- Каковы наши ожидания?
- Чего ожидает заказчик?
Цели у вашей организации и организации заказчика могут быть разными — для аутсорсеров это валидно. Например, вы можете хотеть заработать, а заказчик — сделать продукт подешевле. А все, кто сталкивался с заказной разработкой внутренних продуктов компании, понимают, что бюджеты на внутренние системы всегда стараются сократить. При этом в любом случае мы все заинтересованы в хорошем продукте, поэтому нужно четко понимать, как цели каждого из нас коррелируют между собой. Замечательно, когда мы зарабатываем, просто помогая заработать заказчику. Еще лучше, если он хочет развивать какие-то новые технологии, и мы развиваемся вместе с ним — это «win-win situation». Но, к сожалению, она возникает не всегда.
Существует классический вопрос ожиданий. Есть ценность, которую мы представляем для заказчика, и если смотреть на проект именно с этой точки зрения, вся картина сразу приходит в движение. То есть, если заказчик понимает, что вы можете принести ему прибыль, он более лояльно отнесется к изменениям срока выполнения проекта. Если он понимает, что это выгодно для бизнеса, могут найтись и дополнительные ресурсы. Но стейкхолдер должен четко знать, что ты не стремишься просто заработать деньги для своей команды или компании, а вместе с ним развиваешь продукт — это гарантирует другой уровень отношений. И, соответственно, делает возможным обсуждение любых технических и финансовых моментов. Никто не отменяет ограничений расходов и времени, но разговор о них ведется уже с партнерских позиций.
Что при таком подходе не работают попытки манипуляции, вы заказчика просто потеряете — учтите, он все равно это почувствует. И ему это не понравится.
Виды мотивации
Все мы помним, что в менеджменте выделяют три уровня мотивации:
- Motivation 1.0 Базовая мотивация, полностью зависящая от биологических процессов.
- Motivation 2.0 Мотивация за счет награды или наказания: кнут и пряник, они же морковь и палка.
- Motivation 3.0 Вид мотивации, который активно пропагандирует Дэниел Пинк в книге «Драйв. Что на самом деле нас мотивирует». Он считает, что наказания и поощрения работали в индустриальную эру, когда объем выполненной работы напрямую зависел от потраченного времени. Сейчас, если программист просидел на работе десять часов вместо восьми, это вовсе не значит, что он сделал больше и при этом на достаточном качественном уровне. И от того, что вы наказали программиста за ошибку, работать лучше он вряд ли будет, как показывает опыт. Новая теория мотивации говорит, что человеку важны автономия, возможность повышать мастерство и цель. Обратите внимание — ни о деньгах, ни об их эквиваленте тут нет ни слова.
Продемонстрировать цель как раз и позволяет рассказ о конечном продукте, который мы создаем вместе с заказчиком, о его планах, предполагаемом выходе продукта на рынок, о том, чего ждут пользователи, и насколько счастлив отдел маркетинга клиента. С отдельными категориями продуктов в этом отношении проще — они имеют очевидные цели. Например, если мы делаем дефибриллятор, то сразу понятно, кому и зачем он нужен. Но с бизнес-приложениями часто такой ясности нет. «Я сделал три формы. Зачем? Кому от этих трех форм стало легче жить?» — нормальная реакция программиста. Но когда мы показываем, что кому-то эти формы и правда облегчат жизнь, это меняет мотивацию человека. Он начинает действовать по-другому, принимает другие решения, люди в команде понимают, что пользователь — это совершенно определенная бабушка или банковский работник, а может быть, человек, которому срочно нужно забронировать номер в отеле. Получается, что объект приложения усилий персонализируется, и никто уже не делает просто кнопки или формы.
Лучше других, в силу особенностей работы, это обычно понимают дизайнеры, а программистам и тестировщикам иногда понимания конечной цели остро не хватает. Иногда виноват в этом менеджер, который, например, подгоняя коллег, не объясняет причины спешки. Прежде всего, их нужно узнать самому, просто спросив у заказчика, почему закончить проект он хочет именно к определенной дате. Может оказаться, что ему просто нужно успеть до начала выставки, на которой он рассчитывает привлечь инвестиции. В дальнейшем разговоре часто выясняется, что на первом этапе будет достаточно прототипов, которые в означенный срок выполнить вполне реально (обычно заказчик приходит как раз за две недели). Ну а дальше ваш клиент выходит на выставку с действительно важным для себя функционалом, все в восторге, инвестиции получены, вы продолжаете работу и т. д. При этом, если ваша команда в курсе, над чем именно она работает и почему работа построена именно таким образом, ее члены сгенерируют решение лучше, чем вы могли себе представить.
На DOU проводили опрос разработчиков, который показал, насколько людям важны реализация своих идей и ощущение причастности к чему-то новому. Причем значение этих факторов выше у тех, кто работает в стартапах, чем у занятых в классическом аутсорсинге. Это легко объяснить: в продукты и стартапы просто перекочевывают люди, которым в больших аутсорсинговых компаниях неуютно — там они слишком остро чувствуют себя только маленькими винтиками малопонятного механизма.
Посмотреть в глаза
Ответственность — как много в этом слове заключено для каждого PM. И насколько туманным остается его содержание для многих команд. Споры о ней могут утихать, но почти никогда не прекращаются полностью. Как только вам кажется, что наконец-то все поняли, насколько важна их часть работы, ждите неприятностей. Избежать их помогает связь с конечным пользователем. Если в вашем случае разработчик может посмотреть в глаза человеку, которому предстоит пользоваться продуктом, часть которого он сейчас пилит, он сам начнет фиксить баги. Поверьте, никому не хочется, чтобы из-за его ошибок пострадали живые люди, которых можно себе представить в подробностях.
Если с самими пользователями пообщаться не получается, хорошо, если заказчик представит своих людей, которые отвечают на вопросы пользователей регулярно. И менеджеру стоит разговаривать с ними не с глазу на глаз, а вместе с командой, которая заметит то, что сам он может упустить.
Ответственно фиксить баг, не понимая, зачем ты это делаешь, почти невозможно. И потом точно не стоит удивляться, если на все претензии вам ответят: «Все соответствует требованиям и с технической точки зрения работает хорошо». Лучшие решения рождаются в команде, где каждый видит перед собой образ того, кому, может быть, предстоит мучиться из-за каждой ошибки.
Экспертиза
Seniority — сложная тема, потому что ее не измерить количеством ромбиков на погонах. На мой взгляд, если человек отработал пять лет, но при этом отказывается говорить с заказчиком и командой, не может выступить в качестве ментора, срок его работы ничего не значит. Если он занимается исключительно выполнением своей узкой задачи, даже через пять лет остается на уровне мидл — обычным инженером. Отличие старшего инженера в том, что он берет на себя ответственность за других людей, может общаться с клиентом и что-то ему советовать.
В нашей стране, к сожалению, с этим есть ряд проблем. Когда мы говорим, что человек «синьорный», это часто означает только то, что у него есть определенные знания. Но seniority включает в себя еще и манеру поведения. То есть HR-часть, те самые софт скиллы.
Есть люди, которые не хотят брать на себя ответственность, прикрываясь образом жертвы: «Я бедный-несчастный, тестировщики на меня напали, а еще дизайнер приходил и все поменял — мне теперь опять нужно код переписывать». Ситуации бывают разными, но очень часто важным в такой истории оказывается вовсе не история про дизайнеров и QA, а сам посыл «я бедный-несчастный». И этот образ мыслей приходится менять — если в команде он не поощряется, люди прибегают к нему все реже. Хотя команде иногда приходится нелегко, поскольку при таком подходе нужно не просто здорово писать код, но и принимать решения в рамках всего продукта.
Мне приходилось заниматься такой трансформацией на уровне команды. Сейчас это происходит более точечно: я смотрю, какие люди ко мне приходят, и исходя из прошлого опыта, понимаю, с кем предстоит поработать персонально. Но в целом, если есть core-команда — бизнес-аналитики и техлиды, которые берут на себя работу с продуктом — остальные идут за ними гораздо легче.
Тем не менее, на то, чтобы перестроить отношение к работе в команде, уйдет от полугода (в случае с опытными инженерами) до года. При правильном подходе после этого вы можете быть уверены, что ваши коллеги не просто пишут патчи, а действительно озабочены развитием продукта.
Перегибы и перекосы
Один из вариантов перекоса — чрезмерная озабоченность удовлетворенностью заказчика. И одна из проблем специалистов на нашем рынке, что многие из нас не умеют говорить «нет». Но эта способность просто необходима тому, кто называет себя экспертом.
Другая ошибка — перекос в сторону собственной компании. Это позиция, при которой нас заботит только то, что написано в спецификации. Если вы подумали, что заказчик сам виноват в том, что недостаточно внимательно ее прочитал, — что-то идет не так.
Перекос в сторону команды — еще одна ошибка. В моей команде все хорошие, и я от всех ее защищаю. Но считать, что кругом и правда враги — опасное заблуждение.
Баланс, как всегда, искать сложно. Но искать его необходимо.
Потеря фокуса
Кто приносит прибыль вам и вашему заказчику: каждый отдельный человек или команда? Иногда мы увлекаемся тем, что работаем с каждым человеком индивидуально, позволяя команде выпадать из фокуса менеджера. Нормально, что когда мы перестраиваемся на команду, иногда приходится делать очень непопулярные изменения (менять людей в команде, вводить непопулярные процессы).
Что делает наша команда: обеспечивает экспертизу, или дает двух программистов, или предлагает сервисы? Заказчик приходит к нам, имея об этом собственное представление. Но мы не должны полностью полагаться на его видение решения. Если он просит добавить в проект программиста, претендуя на экспертизу, мы обязательно должны постараться понять, зачем он ему понадобился. Вполне вероятно, что на самом деле ему нужен специалист по автоматизированному тестированию.
Сохранение прозрачности
Вернемся к ситуации, описанной в начале статьи. У вас все хорошо, технологии определены, и команда трудится, создавая новый продукт. Но тут появляется взволнованный заказчик. Это значит, что ему не хватает visibility, а это — пробел в коммуникации.
Если мы вместе делаем продукт для живых людей, эти люди хотят понять, что происходит в данный момент. Если возникает неопределенность, заказчик начинает нервничать и может совершать странные действия, делая какие-то неожиданные заявления. Поэтому, даже если вам кажется, что отчитываться о проделанной работе, последнее, что вам сейчас нужно, отмахиваться от этого процесса нельзя. Иначе он придет требовать немедленного отчета в самый неподходящий момент. И тут окажется, что на его стороне поменялись некоторые люди, и новые менеджеры даже не знают о ваших инструментах, которые позволяют следить за выполнением отдельных задач.
Проджект-менеджер должен говорить с заказчиком как можно чаще. Если ты даешь ему valueи visibility, все остальные изменения: в людях, технологиях и сроках — перестают вызывать фрустрацию. Значит, вам не придется писать странные отчеты в ответ на вопросы, которые кажутся не вполне понятными. Если у заказчика есть чувство контроля, детали он доверит вам. Вы же не спрашиваете, каким именно шпателем вам ровняли стены, делая ремонт, если мастер вовремя отчитался, что «коридор закончили», и вам этот коридор нравится. Этот принцип работает с заказчиками в любых сферах.
Как со всем этим справляться?
Просто работать.