Зарабатывающие на производстве софта компании можно разделить на две категории: заказные разработки — вы сделали один раз и продали один раз для заказчика, и продуктовые — сделали один раз и продали много раз, а заказчика как такового нет. Отсюда в продуктовых компаниях появляется роль product manager. По сути, это внутренний заказчик в компании. Задача продуктового менеджера — понять, что будет востребовано на рынке, и объяснить программистам задачу. Я работаю как раз продакт-менеджером.
Чаще всего обязанности менеджера проекта — это тоже обязанности продуктового менеджера. То есть сначала вы как продакт придумываете, что нужно сделать в продукте, а потом надеваете шапочку проект-менеджера и обеспечиваете, чтобы это было сделано. А после запуска вас оценивают по результатам. Если они плохие, не важно, что именно было плохим: идея или реализация. Важен только результат.
Раньше считали, что продакт-менеджер — это волшебник. Якобы он должен магическим образом понять, что нужно сделать, чтобы вышло круто. Сидит такой умный, думает и смотрит на тренды с рынком А потом встает и говорит: «А пошли делать айфон». Дальше описывает, как продукт должен выглядеть, делает ТЗ для разработчиков, и начинается разработка.
Проблема в том, что если вы не Стив Джобс, подход не сработает. Самая частая причина закрытия стартапов — невостребованность продукта на рынке. Допустим, появляется человек с гениальной идеей, все ее формализуют, тратят много времени, денег, а потом оказывается, что идея никому не нужна. Та же проблема в больших компаниях: запустили продукт, а он никому не нужен.
Lean Startup
Так как такая проблема была в Кремниевой долине, там возникло такое движение Lean Startup. Его смысл строится на мысли: «никто не может точно сказать, что можно сделать, чтобы было круто, но люди могут высказать неплохие гипотезы». А задача продакт менеджера — найти простой и легкий способ, как проверить эти гипотезы. Потом тот же самый подход распространился в большие компании, и сейчас почти вся новая разработка происходит именно так.
Как выглядит цикл разработки? Появляется идея. Дальше ты выбираешь максимально простой способ, чтобы ее реализовать и показать людям. Идет разработка, и создается простой продукт. Потом мы запускаем на рынок, смотрим, как пользуются продуктом, и у нас появляются количественные и качественные данные. На их основе мы смотрим, как можно модифицировать идею. Дальше цикл повторяется. Причем чем быстрее, тем лучше. Самый крутой результат — если от появления гипотезы до ее проверки проходит неделя. Желательно не месяцы и уж точно не годы.
Способы дешево проверить гипотезы разнятся в зависимости от проекта. Например, в «Яндекс.Недвижимость» ты можешь либо подать объявление для аренды квартиры, либо поискать обновление для покупки или съема. Мы подумали: а давайте сделаем ипотечный калькулятор. Как проверить, крутая ли это идея? Решили сделать кнопку с большой подписью «рассчитать ипотеку». По нажатию уходим на статью в википедии или на сайт банка, куда угодно, на этом этапе не важно. Если пользователи часто на нее нажимают — разрабатываем. Если нет — идея не стоит вложений.
Другой пример: вы хотите сильно улучшить скорость работы вашего сайта и думаете, что так пользователи будут чаще к вам заходить. Но сильно улучшить производительность дорого. В такой ситуации можно сделать «ухудшающий эксперимент»: вы наоборот ухудшаете производительность и проверяете, как это сказалось на использовании продукта. Если метрики продукта не изменились, значит, при улучшении производительности они тоже не изменяться.
Получается, что вся разработка идет через формулирование гипотез, их проверки и быстрые эксперименты.
Что из этого следует для управления проектами? Во-первых, у нас нет долгосрочного плана по фичам из-за основания работы на гипотезах. Наша работа через два месяца зависит от результатов текущего эксперимента. Во-вторых, мы не можем точно оценить разработку — мы попросту не знаем, что будем делать. В-третьих, у продакт-менеджера остается мало времени на управление проектом, так как ему еще приходится формулировать гипотезы, находить способы их проверки и коммуницировать с рынком.
Какой нужен процесс? Во-первых, возможность быстро адаптироваться на ходу. Написать подробное ТЗ и полгода работать по плану — не наш вариант. Во-вторых, команда должна брать на себя часть ответственности за управление проектом. Таким образом у продакт-менеджера останется больше времени на продуктовые активности.
Что такое Agile
Agile — это некая философия по управлению проектами. Еще в конце прошлого века люди заметили, что большинство проектов (около 70%) заканчивается неуспешно. Либо не уложились в сроки, либо в бюджет, возможно, качество продукта не устраивало. А у одних менеджеров все получилось лучше.
Возникла идея: собрать вместе людей, которые успешно управляют проектами, и попросить сделать их методологию. В 2001 году эти люди собрались в горной деревушке в Швейцарии, катались там на лыжах, выпивали, а в перерывах обсуждали, как они управляют проектами. И выяснилось, что в деталях их методы управления проектами различаются, но есть общие принципы. Их назвали Agile.
Принципы Agile выразили в манифесте: люди и их взаимодействие важнее, чем процессы и инструменты, работающий продукт важнее исчерпывающей документации, тесное сотрудничество с заказчиком важнее согласования условий контракта, готовность к изменениям важнее следованию первоначачальному плану.
Что из этого следует для меня, как для продакт менеджера? Меньше планирования и больше возможностей адаптироваться на ходу, что помогает при работе. Командная работа в Agile тоже становится лучше. Люди начинают активно думать, как достичь общую цель. Собственно, поэтому Agile применяют в продуктовой разработке.
Проблема в том, что ценности Agile не предполагают конкретику: как именно управлять проектом? Потому специалисты придумали фреймворки, они описывают схему управления в соответствии с Agile. Существует несколько, но я расскажу про самый популярный — Scrum. Им пользуются больше половины всех Agile-команд.
Scrum из регби
Слово Scrum взялось из игры регби. В этой командной игре у каждого человека есть своя роль, но если игрок вражеской команды пытается прорваться с мячом, задача нашей команды — всеми средствами не дать ему пройти. На поле устраивается настоящая куча мала.
Scrum в разработке софта выглядит так же. Есть команда, у которой есть общая цель. У каждого члена команды может быть своя роль: разработчик, тестировшик, дизайнер. Но в тот момент, когда под угрозой общая цель, уже не важно, у кого какая роль, вся команда совместно «наваливается» и добивается общей цели.
Размер команды в Scrum — от пяти до девяти человек. Команды должны быть полностью функциональными: то есть одна команда в семь человек должна быть в состоянии разработать продукт и поставить его конечному пользователю. Нельзя строить команды только дизайнеров или бэкенд-разработчиков: нужно смешивать и составлять кросс-функциональные команды.
В каждой команде есть три роли. Во-первых, development team. Они руками делают полезную работу для конечного продукта. Во-вторых, product owner, он объясняет команде, над какими задачами работать прямо сейчас для того, чтобы максимизировать ценность, которую приносит команда. То есть, по сути, продакт-менеджер. В-третьих, scrum master. Его задача — обеспечить эффективное применение scrum внутри команды. Он может проводить групповые митинги и заниматься разрешением конфликтов.
Получается, Scrum-роль менеджера проекта делится между всеми тремя ролями. Product owner понимает приоритеты в работе, development team решает, кто что делает, а scrum master обеспечить совместную эффективную работу, а также думает о счастье и профессиональном развитии сотрудников.
Как проходит процесс разработки
Большой проект делится на несколько маленьких, и каждый из них называется спринт. Это короткий промежуток от одной до четырех недель. Каждая команда сама выбирает, с какой длительностью спринта ей комфортнее работать. Главное — получить в конце спринта работающий продукт, которым могут воспользоваться конечные пользователи. Например, мы не можем побить проект на спринты так, что первые два спринта делаем техническое задание, потом еще два спринта рисуем дизайн, и только потом начинаем разработку. Это будет противоречить духу Scrum: после каждого спринта конечные пользователи должны получить что-то ценное для себя, то есть какую-то новую полезную функциональность в продукте.
Как выглядит сам спринт? Начинается все с планирования: вся команда собирается на митинг и договаривается, какую цель и задачи берем в спринт. Если к концу спринта выполнили не все задачи, но цель достигли — молодцы, нормальный результат. Если цель не достигли — плохо, так делать не нужно.
Порядок задач обсуждать бесполезно — он решается на ходу и в ходе daily scrum — ежедневной встречи в начале дня с планированием задач на день.
С организацией задачи еще помогает scrum-доска — физическая доска в комнате с колонками со статусами to do, in progress и done. На доску вывешиваем все задачи, которые взяли в спринт. На daily scrum собираемся перед доской, обновляем статусы задач, и выясняем, есть ли какие-то сложности. Если у кого-то из команды возникли проблемы при выполнении задачи, команда решает, как ему помочь.
Еще стоит заметить, что в философии agile и scrum лучший способ коммуникации — лицом к лицу. Так что для команды лучше найти одну комнату на семерых для непрерывного обмена информации.
В конце спринта команда устраивает два митинга с обсуждением результатов. Спринт ревью — показываем заинтересованным лицам выполненные задачи, получаем обратную связь и в соответствии с ней готовим следующий план. Ретроспектива — последний митинг в Scrum. На ревью обсудили, что сделали за спринт, на ретроспективе делимся мыслями, как поработали. Каждый член команды говорит, что прошло хорошо, а что можно было бы улучшить. К примеру, у нас очень много времени занимает сборка, давайте изменим процесс. Предложения учитываются при формировании задач и хода следующего спринта. То есть идет постоянное улучшение процесса работы.
Требования Scrum
Agile акцентируется на конечных пользователях и их требованиях. Потому в рамках философии получили популярность user story — пользовательские истории. То есть способ описания требований к продукту на языке конечного потребителя. Наши user story строятся так: я как такой-то пользователь; я хочу сделать то-то, чтобы добиться такой-то цели.
Например: как агент по недвижимости (1) я хочу разместить объявление о продаже квартиры (2), чтобы найти конечного покупателя (3). Почем все части важны? В зависимости от того, для кого мы работаем, мы можем сделать разные продукты. Интерфейсы для агентов по недвижимости и владельцев квартир будут абсолютно разными. Конечную цель потребителя также нужно определить и запомнить, чтобы не забыть за всеми идеями по ходу разработки.
Как совмещать Scrum и долгосрочное планирование
Scrum часто обвиняют за то, что он слишком тактический: вы смотрите только на ближайший спринт. Как же стратегия продукта, понимание, куда мы движемся в целом? Часто происходит, что при внедрении методологии компания переходит на два отдельных плана: долгосрочный документ и scrum, в котором варится команда. К счастью, scrum можно совмещать с другими техниками.
С долгосрочным планированием вообще много проблем — люди очень плохо оценивают, сколько времени они могут потратить на решение задачи. В этой области проводили интересные эксперименты. Представим, мы взяли здоровое ТЗ на разработку проекта, дали сотне команд и попросили оценить сроки. Команды сидели, думали и выдали прогноз. Получилась некая средняя оценка. Теперь берем то же самое ТЗ, но увеличиваем шрифт и межстрочный интервал — текст стал больше по объему. Даем ТЗ другой сотне команд. Эксперименты показывают, что вторые команды оценивают сроки сильно в полтора, два раза больше.
Но есть хороший момент. Хоть люди и плохо оценивают абсолютные трудозатраты (сколько часов займет задача), они неплохо оценивают относительные трудозатраты (есть две задачи, какая из них больше). На этом строится техника оценки и планирования в story point — неких условных единицах для оценки user story. Для этого мы берем весь Backlog из задач, и просим команду выбрать самую маленькую задачу. Эту задачу будем называть один story point. Все остальные задачи будем оценивать относительно этой самой легкой задачи — то есть другие задачи будем оценивать не в часах, а в story points, где один story point — размер самой маленькой задачи.
Дальше делаем несколько спринтов и смотрим, сколько в среднем story point'ов наша команда успевает сделать за спринт.
В результате получаем: размер каждой задачи в story point'ах и скорость команды в story point'ах.
По этим данным уже можно оценивать сроки за пределами одного спринта.
Что можно изучить студентам уже сегодня
Когда вы собираетесь устраиваться на работу, очень важно, в какую компанию вы идете. От этого сильно зависит, понравится вам там или не нет. При этом не существует идеального типа компаний, разным людям нравится разное. Когда приходите на интервью, тоже выбирайте, подходят ли вам ценности, культура компании. Полезные вопросы: кто будет ставить передо мной задачу, могу ли я изменить задачу, если мне не нравится, работаете ли вы в Agile.
Если кому-то интересна карьера в менеджменте, помните про профессию продуктового менеджера. Я считаю, что это супер интересно: ты определяешь, как строится продукт, и влияешь на жизни людей.
Высшее образование — это время делать стартапы, потому что у вас еще нет пятерых детей и ипотеки. Пока что вы можете себе позволить два года есть дошираки и пытаться изменить мир. Но я призываю: не пилите гениальную идею два года, а потом пробуйте, летит она или нет. Проверяйте гипотезы, на которых основана идея. Если не знаете, с чего начать — найдите ментора.
