Перейти к материалам
медуза

Управление проектами в «Медузе» Как придумать утром, нарисовать в обед, выпустить вечером — а в процессе этого не сойти с ума

Источник: Meduza

Рассказывает руководитель проектов «Медузы» Алексей Буцких.

«Медуза». Крупная компания! Огромный отдел разработки, бригада аналитиков, департамент инноваций, ПМ-офис, а помимо этого — огромный IT-отдел, много людей на аутсорсе, четко налаженный пайплайн продуктов и другие составляющие успешной компании. Вероятно, такое представление складывается о компании, которая часто на слуху, да еще и постоянно выпускает новые игры, таблицы, анимированные графики, видео, нативную рекламу и присутствует на множестве платформ.

Какова же реальность? А реальность в том, что все вышеперечисленные задачи выполняет небольшая группа людей: семь разработчиков, включая техдиректора, четыре дизайнера, включая арт-директора, ну и я — руководитель проектов.

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

У нас просто хаос

«Медуза» запустилась осенью 2014 года, но первые четыре года компания как-то обходилась без руководителя проектов. Какие-то вещи решались внутри техотдела, с какими-то помогал издатель, а какие-то получались просто потому, что их нужно срочно сделать — и редакция, разработчики и дизайнеры просто объединялись и делали. Около года в «Медузе» даже существовал «мостик», человек, который передавал разработчикам пожелания редакции, а затем переводил с разработческого языка на русский, почему что-то будет сделано позже, а что-то — не так, как ожидается. Роль руководителя проектов помимо коммуникации еще подразумевает непосредственно ведение проектов, распределение ресурсов, упорядочивание процессов, а также контроль их соблюдения.

Когда летом 2019 года меня позвали в «Медузу» руководить проектами, я как раз принимал активное участие во внедрении очередного подвида Scrum-методологии в другой компании. Для тех, кто не знает: Scrum — это, если сказать просто, что-то вроде свода правил о том, как должен происходить проект. Сейчас про Agile или Scrum говорят все, но когда я спросил, используются ли в «Медузе» какие-либо формализованные методологии, мне ответили: «У нас просто хаос».

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

Бирюзовая организация и ремонт болида

«Бирюзовая организация» — это очередной модный термин, который сейчас популярен в крупных компаниях. Все стремятся стать такими организациями, а «Медуза», на мой взгляд, была такой с самого начала, хотя этого термина у нас никто, возможно, и не знает. Одна из ключевых особенностей таких организаций— самоорганизованность рабочих команд. И это как раз первый компонент в нашей методике Chaos.

Объясню на примере «Формулы-1». Когда болид приезжает на пит-стоп, члены команды не собираются на совещание, на котором происходит планирование, распределение задач, оценка их сложности, назначение ответственных и прочее. Каждый механик сразу же приступает к работе и делает то, за что он ответственен.

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

Команда

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

  • Автор — он же заказчик, он же редактор, который придумывает общий смысл, тексты, оценивает результат.
  • Дизайнер
  • Разработчик
  • Тестер
«Механики» нашего болида

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

С чего начинается разработка

В большей части случаев «эмбрион» идеи оформляется в задачу после 10 минут обсуждения в чате или вживую. Итог такого обсуждения — краткое описание проекта, к которому каждый член команды добавляет что-то от себя: дизайнер — наброски, разработчик — комментарии, уточняющие логику и другие детали. На основе этой работы уже формируется более подробное и детальное описание. А затем ставится галочка «Все готово к разработке». И начинается разработка.

Какая такая галочка?

И тут мы приходим ко второму компоненту — единой среде коммуникации. Для нас это Basecamp, в котором собирается все относящееся к проекту: описание, задачи («тудушки»), сроки, комментарии, макеты и все сопутствующее.

Важно понимать, что среда должна быть именно единой и работать по одинаковым правилам. Например, вот несколько правил, которые мы определили для себя.

  • Как писать и редактировать описание 
  • Куда складывать документы, макеты и другие файлы
  • Где находятся финальные тексты (не всегда в описании)
  • Где и как проставлять дедлайны, чтобы они всем были видны
  • Где и как проставлять «тудушки», чтобы они были всем понятны

Предупрежу сразу: привести людей в эту среду (в нашем случае в Basecamp) и сделать ее их основным инструментом непросто: не всем очевидно, чем это лучше, чем просто написать в чат. Это одна из проблем, которую мы пытаемся решить до сих пор.

Проставление галочек напротив выполненных задач — важный момент. Они дают сигнал, что макет финальный и можно начинать разработку. Или что разработка завершена и можно начинать тестирование. Или что все готово к запуску. Благодаря «тудушкам» члены команды избавлены от необходимости тратить ценное время на прояснения всех этих вопросов. Может выглядеть как что-то совсем очевидное, но до перехода на Basecamp мы не раз сталкивались с ситуацией, когда, например, разработка сдана, а тестировщик не в курсе, что можно приступать, — и в итоге наступала всеобщая фрустрация.

Чек-листы в схожих проектах позволят ничего не упустить

Проблемы приоритизации

Перед разработчиками, которые обслуживают сразу большое количество систем (в случае «Медузы» это и сайт, состоящий из множества компонентов, и мобильное приложение, и внутренняя админка редакции, и интеграции с другими сервисами), вечно стоит проблема: как расставить приоритеты между задачами, при этом никого не обделить и не забыть про собственный технический долг. Часто это работает по принципу «кто громче кричит — того задача и важнее». Редактор столкнулся с криво работающей функцией в админке, которая не блокирует его работу, но настолько его раздражает, что он пройдет по всем инстанциям? Эту недоработку исправят быстрее, чем что-то более серьезное, с которым все почему-то решили смириться.

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

Первое: нужен человек, который просто способен более объективно, чем сами разработчики, оценить важность задачи. В «Медузе» это люди, ответственные за конкретное направление или продукт. Они за пять минут разговора могут ранжировать все задачи. И моя задача тут — сделать диалог продуктивным и убедиться, что обеим сторонам все понятно.

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

Далее — дело техники. Сводим все задачи вместе, просим ответственных ранжировать задачи между собой. И получаем бэклог задач, рассортированных по приоритетам и продуктам. Кстати, бэклог мы ведем в Airtable. 

Задачи, разобранные по продукту и приоритету

Из моего рассказа может показаться, что главное — все формализовать. Это не так — вот несколько советов, которые помогут еще лучше организовать список задач:

  • Чрезмерная формализация убивает процессы. Не нужны формальные встречи. Приоритеты можно расставить за пять минут за кофе. 
  • Приоритеты нужно регулярно пересматривать в отношении других задач, это не разовое упражнение. 
  • «Свод» задач с приоритетами — это не оружие против заказчиков, а помощник в коммуникации с ними.
  • И самое главное — список задач должен быть легко обрабатываемым, не нужно пихать туда все подряд. 

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

Бонус! Еще несколько советов, которые пригодятся в работе:

  • Всегда стоит начинать с целей. И двигаясь вперед, всегда нужно к ним возвращаться, чтобы понять, на правильном ли вы пути.  
  • Аналитика — всегда помощник. Собственное мнение — хорошо, опрос друзей — тоже, но цифры могут дать наиболее объективную картину. 
  • Делайте короткие и емкие конспекты после всех встреч. Прикладывайте их к описанию.
  • Одна иллюстрация или схема лучше абзаца текста.
  • Затраты времени на поддержку документации проекта всегда окупятся. Кстати, описание может стать как инструкцией, так и сценарием для тестирования.
  • Заказчик должен быть частью рабочей группы и принимать участие в процессе всей работы.
  • Пишите ретроспективу: после завершения проекта всегда важно понять, что было сделано не так и где можно было сделать лучше. 
  • Чек-листы в схожих проектах позволят ничего не упустить. Например, большинство наших игр содержат одинаковые наборы «тудушек» — про планирование, разработку, тестирование и контент.
  • Сделать хороший проект — успех. Остановить мертвый проект — не меньший успех. 
  • Личные сообщения — нет. Групповой чат — да. 
  • Ежедневный 10-минутный чекин лучше часовой встречи раз в неделю. 
Читайте другие материалы о «Медузе» в нашем блоге.

Слушайте музыку, помогайте «Медузе»