Как приготовить проект: Рецепты для создания успешных продуктов и команд

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

Один подбрасывает блин – но тот падает на пол. Второй тушит вспыхнувшее полотенце, позабыв про бурлящий суп. Третий проливает на плиту молоко, которое тут же пригорает. Где-то в углу двое яростно спорят о количестве чеснока в соусе. Масло брызжет, чайник свистит, ножи стучат, официанты требуют заказы, но их никто не слышит.

Из-за гор грязной посуды раздается раздраженный голос хозяина:

– Соберитесь! Начните работать нормально!

Но шум только нарастает. Надежда получить идеальное блюдо тает – и если что-то и выходит, то скорее чудом.

Вам знакомо это ощущение хаоса – в делах или в целом по жизни? Тогда эта книга для вас.

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

Этот хаос – не случайность. Я сам не раз бывал на такой кухне. Мне довелось запускать, срывать и закрывать проекты разного масштаба: от стартапов до сложных, не имеющих аналогов систем в крупнейших компаниях (Яндекс и Mail.ru Group[1]). Я видел хаос везде, где люди сталкивались с дедлайнами – в IT, маркетинге, образовании, – и научился его укрощать. Не магией заклинаний, а с помощью системной и последовательной работы. Я покажу вам как.

О методологии

Профессия проджект-менеджера ненамного моложе Рунета. Во второй половине 1990-х, когда я начинал, этой специальности даже не существовало. Зато были «веб-мастера». Мы отвечали за все: код, дизайн, контент, аналитику, маркетинг. Отрасль только зарождалась, специалистов почти не было, а стандарты приходилось формулировать на ходу.

Интернет развивался, проекты росли, а вместе с ними и их команды. Со временем веб-мастеров на все руки заменили более узкие профессионалы: разработчики, IT-архитекторы, UX/UI-дизайнеры, аналитики, менеджеры разных направлений. Перед индустрией встал новый вызов: как организовать работу команд?

На тот момент не было ни курсов по управлению проектами, ни опытных экспертов, ни даже четких ожиданий от этой профессии.

Scrum, Kanban, Agile, Waterfall – все эти термины тоже появились в нашем лексиконе не сразу, и их суть не всегда была очевидна. Поэтому тем, кто начинал вместе с Рунетом, приходилось собирать винегрет из зарубежных практик, привычек команды, собственных ошибок и специфики рынка.

Как из этой методологической солянки появилась стройная система?

За время работы я был частью разных проектных и продуктовых команд. В них мы не просто заимствовали чужие инструменты, успешные приемы и привычки – мы изучали проектные и командные проблемы, свои промахи и способы их устранения. Я наблюдал за развитием проектов, менял менеджеров, анализировал и систематизировал решения, совершенствовал методы и адаптировал их к конкретным условиям. Каждый успешный прием я фиксировал и тестировал в новых проектах.

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

Почему это вообще важно?

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

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

● Задачи зависают в воздухе. Все обсудили, но каждый понял по-своему – в итоге ничего не сделано.

● Встречи не приводят к результату. Позади часы обсуждений, но решений нет. Проходят недели – ничего не меняется.

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

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

● Результат разочаровывает. Потрачены ресурсы, но проект бесполезен или сразу забывается.

● Все держится на вас. Стоит отвлечься – работа встает, без контроля все идет не туда.

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

Представленная в книге методология – не случайный набор инструкций, а практичная система, объединяющая проверенные методы и оригинальные решения. Это не книжная теория, а рабочий инструмент, который помог самым разным командам навести порядок, преодолеть хаос и стабильно добиваться результатов. Все, о чем пишу, я применял и для запуска собственных проектов, и в процессе создания первых облачных сервисов в нашей стране.

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

Я изложил здесь свои наблюдения и приемы, но это вовсе не значит, что они – единственно верный путь. Мне интересно, что получится у вас! В конце книги я разместил ссылку на группу в Telegram, где буду рад получить обратную связь. Вышел ли у вас ожидаемый шедевр по предложенным рецептам? Или получилось что-то получше? Какие секретные ингредиенты вы нашли сами?

Для кого эта книга

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

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

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

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

Вы узнаете, как:

● построить эффективную систему принятия решений и избежать паралича от неопределенности;

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

● работать с данными и метриками, чтобы оптимизировать процессы и принимать обоснованные решения;

● управлять проектами с максимальной вовлеченностью каждого участника;

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

Готовы перестать тушить пожары и создать систему, где результат – не случайность, а закономерность?

Тогда скорее переворачивайте страницу – и начнем.

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

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

Проект и продукт

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

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

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

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

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

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

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

Продукт требует выделенной команды. Целевая связь один к одному: одна команда – один продукт. Успех продукта в основном зависит от экспертности, которой обладает и которую накапливает вся команда, и в меньшей степени от опыта менеджера.

Представим, что менеджер проекта – это повар ресторана. Чтобы блюдо было готово вовремя и понравилось гостям, он должен не только знать рецепты, но и понимать, как работает вся кухня: от поставки продуктов до подачи на стол. Такое внимание к деталям позволяет ему избежать ошибок и обеспечить высокое качество блюд. Каждое из них – это отдельный небольшой проект, за который он несет ответственность.

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

Шеф-повар же – это уже менеджер продукта: тот, кто не только следит за всеми процессами на кухне, но и решает, какие блюда войдут в меню ресторана и какой стилистике они будут соответствовать. Он изучает вкусы гостей, анализирует тенденции рынка и создает уникальные предложения, такие как «блюдо сезона» или необычная подача классического рецепта. Его задача – не только обеспечить качество, но и сделать так, чтобы блюда соответствовали запросам клиентов и выделяли ресторан среди конкурентов.

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

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

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

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

Плох тот повар, который не мечтает стать шефом.

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

Другие, помимо гастрономии, примеры продуктов и проектов из бизнеса:

● Продукт – бизнес по пошиву штор.

■ Проекты предполагают выполнение заказов по каждому договору, поиск более качественных и дешевых материалов, выстраивание сети продаж.

● Продукт – сервис доставки еды.

■ Проекты: поиск новых поставщиков и курьеров, запуск приложения, создание промо-страницы и обновление транспортного парка.

● Продукт – гостиница.

■ Проекты: ремонт номеров, разработка меню для ресторана при отеле, проведение рекламной фотосессии, урегулирование разногласий с недовольными клиентами.

● Продукт – фермерское хозяйство.

■ Проекты: строительство теплиц, закупка сельхозтехники, внедрение системы автоматического полива, организация фермерского рынка.

● Продукт – музыкальная группа.

■ Проекты: запись альбома, проведение концертного тура, съемка видеоклипа, выпуск мерча.

● Продукт – семья.

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

Менеджер

Неважно, о каком направлении менеджмента идет речь: в общепите, IT, маркетинге, недвижимости, PR, продажах или гостиничном бизнесе, – профессии менеджера не существовало бы, если бы без него все работало. В каждой отрасли есть свои проекты и продукты, и везде есть необходимость их реализовывать. Подходы к управлению проектами универсальны и применяются повсеместно. И требования к тем, кто отвечает за их реализацию, – тоже.

Менеджмент – темная материя, создающая связи между объектами, делая их зависимыми друг от друга и наполняя смыслами.

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

Менеджер должен уметь:

● вникать;

● планировать;

● организовывать;

● информировать;

● считать;

● контролировать.

То есть управлять в самом полном смысле этого слова.

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

Здесь перечислены приобретаемые навыки – привычки, которые в случае их отсутствия можно в себе воспитать.

Владеем данными

Эффективное управление невозможно без знания цифр, относящихся к предметной области проекта.

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

Существуют три вида лжи: ложь, наглая ложь и статистика.

Нежелание, страх и неумение работать с цифрами часто приводят к неверным выводам или к их полному отсутствию, что, по сути, тоже искажает реальность. Если попросить 10 менеджеров проанализировать результаты запуска, минимум восемь из них отправят скриншоты из «Яндекс Метрики» или таблицы с цифрами, не проявляя никаких признаков осознанности.

Правильный отчет содержит краткое описание проекта, задачи, собранные данные, наблюдения, выводы, планы и идеи. Также важны сами цифры (ссылкой или вложением) для проверки выводов. Некачественная работа обычно выглядит как скриншот или прикрепленный файл в Excel, сопровождаемые письмом примерно такого содержания: «Все хорошо тчк Вот цифры тчк Разбирайтесь тчк На этом все!»

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

Проверяем факты

Или демонстрируем наличие критического мышления.

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

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

Данные нужно превращать в факты.

Реакция на это требование всегда одинакова: «Это что, я все должен перепроверять?!» или «А он тогда зачем?».

«Услышать и передать» – не то же самое, что «услышать, понять и передать». Первый подход убивает в нас профессионала и делает распространителем непроверенных данных. Второй – меняет процесс: осознанное отношение приводит к чувству ответственности за цифры и их распространение. Важно, чтобы основанное на них итоговое решение было нашим, т. е. не только принятым нами, но и подкрепленным проверенными нами данными.

Критическое мышление способно остановить большинство идей и проектов из-за их «сырости». Часто задачи формулируются как «нужно сделать то-то», что в слабых командах воспринимается как руководство к действию. Признак плохой задачи – отсутствие текущих и желаемых цифр, а также объяснения, как работы на них повлияют. Такие задачи не достигают цели, потому что они не сформулированы. Чтобы избежать неверных действий, нужно проверять базовые утверждения, лежащие в основе задачи, и анализировать результаты запусков.

Помимо техники «5 почему» (см. здесь), свои и чужие утверждения, предположения и версии можно проверять вопросами «Зачем?», «Как считали?» и «Когда?».

Еще один очень хороший вопрос – «Кто это сказал?». Это вопрос-триггер. Его цель не получить ответ в виде имени и фамилии, а заставить нас рефлексировать: не ссылаясь на чей-либо авторитет, перепроверить и переоценить исходные данные, задачи и утверждения.

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

Чем эксперт лучше, тем он хуже.

Чем экспертнее мнение, тем реже нужны данные для его подтверждения, а значит, экспертиза и каждое следующее решение становятся слабее.

Рис. 1. «Жизненный цикл» проекта

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

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

Даже самая сильная команда, отказавшаяся от привычки проверять идеи, факты и итоги запусков, рано или поздно сначала лишится экспертизы, а затем своими решениями разрушит продукт.

Принимаем решения

«Я подумал, что так будет лучше», «Мне так сказали», «Ты же это видел два месяца назад» и лидеры хит-парада – «Все так делают» и «Так никто не делает» – самые яркие ответы-маркеры, говорящие о том, что у собеседника навык принятия решений проседает.

Нас невозможно сбить с пути. Нам все равно, куда идти.

В нашей профессии необходимо принимать решения. Они могут быть правильными и неправильными, но всегда должны быть обоснованными. Алгоритмы поиска доводов бывают разные – от подбрасывания монетки до SWOT-анализа[2]. Их много, и все они доступны в интернете (см. здесь), а потому в этом разделе мы говорим не столько о системах, сколько о самой необходимости использовать их для принятия решений.

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