Управление проектами в «Медузе» Как придумать утром, нарисовать в обед, выпустить вечером — а в процессе этого не сойти с ума
Рассказывает руководитель проектов «Медузы» Алексей Буцких.
«Медуза». Крупная компания! Огромный отдел разработки, бригада аналитиков, департамент инноваций, ПМ-офис, а помимо этого — огромный IT-отдел, много людей на аутсорсе, четко налаженный пайплайн продуктов и другие составляющие успешной компании. Вероятно, такое представление складывается о компании, которая часто на слуху, да еще и постоянно выпускает новые игры, таблицы, анимированные графики, видео, нативную рекламу и присутствует на множестве платформ.
Какова же реальность? А реальность в том, что все вышеперечисленные задачи выполняет небольшая группа людей: семь разработчиков, включая техдиректора, четыре дизайнера, включая арт-директора, ну и я — руководитель проектов.
Другая важная особенность этой реальности заключается в том, что в медиа ветер меняется очень быстро и необходимо подстраиваться под ситуацию, а неожиданные события могут перечеркнуть большой проект, над которым ты долгое время работал.
У нас просто хаос
«Медуза» запустилась осенью 2014 года, но первые четыре года компания как-то обходилась без руководителя проектов. Какие-то вещи решались внутри техотдела, с какими-то помогал издатель, а какие-то получались просто потому, что их нужно срочно сделать — и редакция, разработчики и дизайнеры просто объединялись и делали. Около года в «Медузе» даже существовал «мостик», человек, который передавал разработчикам пожелания редакции, а затем переводил с разработческого языка на русский, почему что-то будет сделано позже, а что-то — не так, как ожидается. Роль руководителя проектов помимо коммуникации еще подразумевает непосредственно ведение проектов, распределение ресурсов, упорядочивание процессов, а также контроль их соблюдения.
Когда летом 2019 года меня позвали в «Медузу» руководить проектами, я как раз принимал активное участие во внедрении очередного подвида Scrum-методологии в другой компании. Для тех, кто не знает: Scrum — это, если сказать просто, что-то вроде свода правил о том, как должен происходить проект. Сейчас про Agile или Scrum говорят все, но когда я спросил, используются ли в «Медузе» какие-либо формализованные методологии, мне ответили: «У нас просто хаос».
Но даже то, что на первый взгляд кажется хаосом, имеет определенную структуру и подход. Назовем эту методику Chaos.
Бирюзовая организация и ремонт болида
«Бирюзовая организация» — это очередной модный термин, который сейчас популярен в крупных компаниях. Все стремятся стать такими организациями, а «Медуза», на мой взгляд, была такой с самого начала, хотя этого термина у нас никто, возможно, и не знает. Одна из ключевых особенностей таких организаций— самоорганизованность рабочих команд. И это как раз первый компонент в нашей методике Chaos.
Объясню на примере «Формулы-1». Когда болид приезжает на пит-стоп, члены команды не собираются на совещание, на котором происходит планирование, распределение задач, оценка их сложности, назначение ответственных и прочее. Каждый механик сразу же приступает к работе и делает то, за что он ответственен.
К этому стремимся и мы, только наш болид — это редакционная идея, которая тоже сразу берется в работу. Каждый знает, что он должен делать и за что отвечает. И на выходе через, скажем, 2–3 дня, у нас есть уже какая-то игра, или тест, или новый элемент на сайте. Но где же MVP, маркетплейс, где же согласование с заказчиком и спонсором? Все это заменяет самоорганизованность! Мы сами организуемся, сами принимаем решение, сами оцениваем результат и делаем выводы — и сами потом за него отвечаем.
Команда
А теперь к практике — рабочая команда должна быть небольшой, но обладать всеми необходимыми навыками. Конечно, в зависимости от сложности и специфики, состав может меняться, но чаще всего в ней будут:
- Автор — он же заказчик, он же редактор, который придумывает общий смысл, тексты, оценивает результат.
- Дизайнер
- Разработчик
- Тестер
Все эти роли должны быть определены на берегу, и каждая из них несет ответственность за свою часть.
С чего начинается разработка
В большей части случаев «эмбрион» идеи оформляется в задачу после 10 минут обсуждения в чате или вживую. Итог такого обсуждения — краткое описание проекта, к которому каждый член команды добавляет что-то от себя: дизайнер — наброски, разработчик — комментарии, уточняющие логику и другие детали. На основе этой работы уже формируется более подробное и детальное описание. А затем ставится галочка «Все готово к разработке». И начинается разработка.
Какая такая галочка?
И тут мы приходим ко второму компоненту — единой среде коммуникации. Для нас это Basecamp, в котором собирается все относящееся к проекту: описание, задачи («тудушки»), сроки, комментарии, макеты и все сопутствующее.
Важно понимать, что среда должна быть именно единой и работать по одинаковым правилам. Например, вот несколько правил, которые мы определили для себя.
- Как писать и редактировать описание
- Куда складывать документы, макеты и другие файлы
- Где находятся финальные тексты (не всегда в описании)
- Где и как проставлять дедлайны, чтобы они всем были видны
- Где и как проставлять «тудушки», чтобы они были всем понятны
Предупрежу сразу: привести людей в эту среду (в нашем случае в Basecamp) и сделать ее их основным инструментом непросто: не всем очевидно, чем это лучше, чем просто написать в чат. Это одна из проблем, которую мы пытаемся решить до сих пор.
Проставление галочек напротив выполненных задач — важный момент. Они дают сигнал, что макет финальный и можно начинать разработку. Или что разработка завершена и можно начинать тестирование. Или что все готово к запуску. Благодаря «тудушкам» члены команды избавлены от необходимости тратить ценное время на прояснения всех этих вопросов. Может выглядеть как что-то совсем очевидное, но до перехода на Basecamp мы не раз сталкивались с ситуацией, когда, например, разработка сдана, а тестировщик не в курсе, что можно приступать, — и в итоге наступала всеобщая фрустрация.
Проблемы приоритизации
Перед разработчиками, которые обслуживают сразу большое количество систем (в случае «Медузы» это и сайт, состоящий из множества компонентов, и мобильное приложение, и внутренняя админка редакции, и интеграции с другими сервисами), вечно стоит проблема: как расставить приоритеты между задачами, при этом никого не обделить и не забыть про собственный технический долг. Часто это работает по принципу «кто громче кричит — того задача и важнее». Редактор столкнулся с криво работающей функцией в админке, которая не блокирует его работу, но настолько его раздражает, что он пройдет по всем инстанциям? Эту недоработку исправят быстрее, чем что-то более серьезное, с которым все почему-то решили смириться.
Это приводит к тому, что задачи делаются в хаотичном режиме, технический долг просто накапливается, а разработчики выгорают. Чтобы это исправить, нужно придать этому хаосу немного формализации. Наладить процесс.
Первое: нужен человек, который просто способен более объективно, чем сами разработчики, оценить важность задачи. В «Медузе» это люди, ответственные за конкретное направление или продукт. Они за пять минут разговора могут ранжировать все задачи. И моя задача тут — сделать диалог продуктивным и убедиться, что обеим сторонам все понятно.
Второе: все задачи должны быть приведены к одному знаменателю и находиться в единой системе измерения. Это нужно, чтобы в дальнейшем не сравнивать килограммы с градусами. Иными словами, задачу «изменить цвет блока на сайте» будет неразумно сравнивать с разработкой системы документооборота. Но если первую задачу соединить с группой аналогичных задач по сайту, а вторую разбить на более мелкие модули, то в этом всем уже появляется какой-то смысл.
Далее — дело техники. Сводим все задачи вместе, просим ответственных ранжировать задачи между собой. И получаем бэклог задач, рассортированных по приоритетам и продуктам. Кстати, бэклог мы ведем в Airtable.
Из моего рассказа может показаться, что главное — все формализовать. Это не так — вот несколько советов, которые помогут еще лучше организовать список задач:
- Чрезмерная формализация убивает процессы. Не нужны формальные встречи. Приоритеты можно расставить за пять минут за кофе.
- Приоритеты нужно регулярно пересматривать в отношении других задач, это не разовое упражнение.
- «Свод» задач с приоритетами — это не оружие против заказчиков, а помощник в коммуникации с ними.
- И самое главное — список задач должен быть легко обрабатываемым, не нужно пихать туда все подряд.
Кстати, есть простой способ определить, что процесс устроен не так: если вы ни черта не можете в нем разобраться, значит, его цель уж точно не повышение качества и эффективности работы. А если он просто чуть сглаживает углы и заполняет пустоты в естественном его течении — вы на правильном пути.
Бонус! Еще несколько советов, которые пригодятся в работе:
- Всегда стоит начинать с целей. И двигаясь вперед, всегда нужно к ним возвращаться, чтобы понять, на правильном ли вы пути.
- Аналитика — всегда помощник. Собственное мнение — хорошо, опрос друзей — тоже, но цифры могут дать наиболее объективную картину.
- Делайте короткие и емкие конспекты после всех встреч. Прикладывайте их к описанию.
- Одна иллюстрация или схема лучше абзаца текста.
- Затраты времени на поддержку документации проекта всегда окупятся. Кстати, описание может стать как инструкцией, так и сценарием для тестирования.
- Заказчик должен быть частью рабочей группы и принимать участие в процессе всей работы.
- Пишите ретроспективу: после завершения проекта всегда важно понять, что было сделано не так и где можно было сделать лучше.
- Чек-листы в схожих проектах позволят ничего не упустить. Например, большинство наших игр содержат одинаковые наборы «тудушек» — про планирование, разработку, тестирование и контент.
- Сделать хороший проект — успех. Остановить мертвый проект — не меньший успех.
- Личные сообщения — нет. Групповой чат — да.
- Ежедневный 10-минутный чекин лучше часовой встречи раз в неделю.
Читайте другие материалы о «Медузе» в нашем блоге.