Владимир Завертайлов - Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий

Почему книга сразу и для проджектов, и для продактов? Потому что в небольших проектах эти роли часто выполняет один человек. Project Manager (диджитал-продюсер, PM, менеджер, руководитель проектов – зовите, как хотите) – специалист, который своей шкурой отвечает за проект и несет ответственность за то, чтобы в процессе работы ни одно животное не пострадало. Графики, сроки, команда, бюджеты, релизы, качество – вот что в фокусе. Product Manager – это, скорее, про маркетинг, стратегию, приоритеты, трафик, сегменты, конкурентов.

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

В ней также найдутся ответы на те непростые вопросы, с которыми сталкиваются начинающие и уже опытные менеджеры проектов и продуктов ежедневно:

▶ как общаться с подчиненными, чтобы не быть в их глазах мямлей или деспотом;

▶ как грамотно делегировать и что придется в себе искоренять, чтобы это уметь;

▶ почему Scrum – все еще передовой фреймворк для разработки проектов и продуктов в digital и как его внедрить в свою команду;

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

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

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

▶ как строить команду, чтобы людям хотелось приходить на работу и расти профессионально;

▶ как распределять собственное время менеджера эффективно и при этом не выгореть и не уехать в бессрочный отпуск;

▶ что лучше: собственная команда или аутсорс и как быть с техподдержкой;

▶ как не плодить бюрократию, но при этом четко оформить процесс разработки документально;

▶ как интегрировать сайты и продукты с внешними сервисами и системами без моря слез;

▶ что делать, если все пошло не по плану и случился факап на проекте;

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

Полистайте содержание. Посмотрите главы. Загляните в задания после каждого блока. Если есть сомнения – поставьте, где взяли. Не поможет. Особенно, если не планируете постоянно практиковаться. В книге, конечно, есть забавные истории, примеры, кейсы, чек-листы и шаблоны, которые можно брать и сразу применять. Но это – инструмент, а им нужно пользоваться!

Возьмем такую задачку: довести сайт до ума.

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

Правильно: бежать!

А что нас смущает? Запредельная степень неопределенности? Тухлая перспектива? Неуверенность в команде? Непонятки с оплатой? Неадекватный заказчик? Поехали, потом заведешься? Гарантированный геморрой при негарантированном результате?

Давайте мысленно представим, как выглядит картина мира digital-проекта и сколько возни тут вырисовывается.

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

Заказчик.Бывают два типа заказчиков. Внутренний, когда разработка идет in-house. И внешний, когда проект разрабатывается на заказ.

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

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

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

Различают два ключевых формата работы. Time & Material – оплачивается время, затраченное командой, в таком случае задачи можно менять как угодно. И Fixed Price – цена и задачи оговариваются на берегу. У обоих вариантов есть как плюсы, так и минусы. Time & Material переносит риски на заказчика, но работу можно организовать быстрее и гибче. Fixed Price – заставляет разработчика зашивать риски и подстраховку в смету, лишает гибкости и снижает скорость выпуска функций из-за процедуры согласования бюджета, но яснее воспринимается клиентом. Существуют также гибридные модели.

Условия заказчика регламентируются тремя способами:

Требования. Постановки задач, технические задания (ТЗ), тикеты [1] Расшифровку терминов, выделенных полужирным курсивом, можно найти в «пояснениях» (конец каждой главы). , рисунки на салфетках, бэклоги … Управление требованиями, выявление, уточнение, актуализация, расстановка приоритетов занимают массу времени. Рассмотрим подробно работу с требованиями и способы приоритизации в главе 4.