Готовься, статья длинная. К сожалению или счастью, для полноты картины недостаточно рассказать о последних шагах на пути к изменениям. Поэтому начнём со старта проекта и дойдём до сегодняшних дней. С заметками и выводами, всё как положено. Поехали.
Главная идея: построить систему управления, подходящую для продуктовой компании в целом. Чтобы она охватывала все, или почти все, отделы и являлась связующим звеном между ними. А работа каждого отдела сделалась прозрачной для остальных и была чётко вписана в общую структуру достижения целей компании.
Этап 1. Диаграммы Ганта
Первым инструментом управления были Диаграммы Ганта. Этот инструмент был достаточно попсовым в те годы, и отчасти поэтому был выбран тогдашним руководителем проекта. К тому моменту мы, как команда-подрядчик, уже имели богатый опыт проектных работ, с конечным циклом разработки продуктов, по различных методикам, начиная с формирования требований и заканчивая выпуском готового продукта. Вся работа разбивалась на промежуточные этапы, поэтому управление через Диаграммы Ганта в моменте вопросов не вызывало.
Важное наблюдение. При изучении любой методологии есть два уровня понимания:
- Идеологический – когда ты понимаешь суть метода, его ключевые тезисы и плюсы от внедрения. Но этот уровень далёк от реальности, потому что, как правило, примеры использования метода идеализированы или сильно упрощены для легкого усвоения;
- Практический или реальный – когда ты внедряешь метод в проект и команду. На данном этапе начинают возникать частные вопросы, конфликты с текущими процессами или вовсе непринятие каких-то аспектов. Здесь-то и начинает зарождаться настоящее понимание;
Итак, вернёмся к Chronos. План "накидали", красивые диаграммы нарисовали. Смотрелось замечательно! А дальше, начав работы, мы поняли:
- План проекта – это документ, содержащий подробную информацию о проекте: его объемах и целях, исполнителях и задачах, сроках и бюджетах. На его основе рисуется Диаграмма Ганта. Но если ты запускаешь продукт с нуля, всегда будет не план, а самая обычная "карта желаний" владельца или руководителя. Она очень часто будет разбиваться о реальные данные опросов, реакции аудитории и т.д.;
- Точные сроки выполнения – самый большой идиотизм для креативных задач, где нет единого стандарта для реализации. Все оценки максимально далеки от реальности, сроки постоянно двигаются, а руководитель превращается в менеджера Google-таблицы с данной диаграммой;
- Для команды или подрядчиков – выгорание, так как нарушение сроков – плохо, а соблюдение сроков – это ночи без сна. Самое главное, что даже взяв времени с запасом, на нестандартных задачах будет непредсказуемый объем багов, которые после окончания этапа или релиза нужно будет править;
- Этот инструмент не про продуктовый подход, итеративное тестирование и корректировку в зависимости от новых вводных;
- Это удобный инструмент для визуализации загрузки сотрудников, понимания, чем они занимаются и чем будут заниматься в ближайшее время;
- На Диаграмме Ганта чётко видно зависимости, что за чем идет и что от чего зависит. Правда это уже не в Google таблицах лучше делать, а в любом специализированном сервисе, например в Ganttpro.
Планирование и приоритезация в период использования данного инструмента исходили от руководителя проекта и единственного носителя ключевой информации из сферы. Порядок элементов определялся субъективными представлениями о том как это должно быть в продукте. В дополнение, была одна финансовая цель, на которую ориентировались и корректировали её в случае, если обновления не давали нужного эффекта.
Этап 2. Waterfall или Водопад
Следом, видя все проблемы выше и решив, что проблема в плохой проработке этапов до релиза, Диаграммы Ганта заменили методологией Waterfall (водопада), или каскадной методологией. Во многом структура этой методологии заимствована у Ганта, так что переход прошел незаметно. Согласно Waterfall работа над проектом должна идти в несколько этапов, следующих друг за другом, от первого и до последнего. Их количество от проекта к проекту, от схемы к схеме, может меняться, но суть одна.
Мы собираем требования, по сути это тот самый брифинг заказчика из прошлой статьи. После приступаем к проектированию – максимальная детализация ТЗ, возможно прототипы. В общем все, чтобы оценить требуемые ресурсы. Затем реализация, где мы реализуем требуемый функционал или продукт согласно ТЗ, по пути дополняя ТЗ упущенными деталями. Проверка, тестирование и исправление багов и проблем продукта. Развертывание – "заливаем на прод" (загружаем на основной/боевой сервер), сдаем заказчику.
И снова мы столкнулись с той же проблемой. Есть четкий выверенный план и техническое задание, что же может пойти не так? Конечно же, все, что было перечислено выше, а также:
- Особенность метода в отсутствии возможности перескакивать этап или возвращаться на прошлый в случае недоработок. Пожалуй, самое неприятное ограничение. В связи с частыми обновлениями и новыми данными, возникающими по мере переходов между этапами. Были попытки решить это через разные версии и запуск нового цикла с доработками или корректировками после первой версии. Но это, конечно, путает приоритеты и сильно замедляет выпуск функционала;
- Все требования должны быть заранее известны. Сделать это очень сложно, потому что заказчик часто и сам не знает, чего хочет. В таких ситуациях гибкие методологии показывают себя куда лучше;
- Тестирование происходит в самом конце. То есть если у вас в конце всплывает множество багов, то их закрывают заплатками, так как особого выбора нет – сроки всегда кончаются вчера;
- Плюсом стало наличие подробных ТЗ и документации по проекту, что может сильно снизить риски замены кадров на каждом из этапов. Дальше, правда, появляется вопрос поддержки актуальности ТЗ и хранения версий, но сложно отнести это к минусам или плюсам – просто особенность, которую нужно учитывать.
В конечном счёте, данный метод оказался еще менее гибким, чем Гант. Какие-то проблемы даже усилились.
**Мы же после долгих наблюдений и участия в этом уверены, что для большинства IT-проектов данные инструменты практически всегда не подходят.**
Этап 3. Дорожные карты
Наше вступление в управление проектом ознаменовалось уходом от Ганта и Водопада к их главному противнику того времени – дорожным картам. Большим, красивым и модным)
Дорожная карта – это визуализация основных шагов к достижению цели или ступеней развития проекта. Важно, что дорожная карта не показывает, кто делает, что делает и как. Только сами верхнеуровневые задачи.
С введением дорожной карты возникли сложности с ее прозрачностью для основателя и инвестора проекта. После прошлого детализированного визуального представления о функционале и датах его выпуска, сложно было смотреть на верхнеуровневые блоки, так еще и без точных сроков. Пришлось родить некий промежуточный вариант, сохраняющий декомпозицию до функциональных единиц и разбивку по отделам.
Со временем, поняв бессмысленность этой затеи, мы перешли на примерную оценку этапов. Так как не выходя на чисто стратегический уровень планирования, появляется много перестановок, как и на Диаграммах Ганта. Что, на тот момент, усиливалось частым изменением вектора приложения усилий от основателей проекта. Тогда дорожная карта стала, скорее, наглядной диаграммой, подсказывающей последовательность выпуска, что приблизило ее к более гибкому формату.
Пример одной из итераций на картинке:
Каждая ячейка равна 1 неделе, план выстраивался уже с учетом ключевых мероприятий и приоритизацией на основе обратной связи от пользователей. Полностью решить проблему с субъективностью принятия решений о последовательности релизов и выборе функций для разработки, к сожалению, не удалось. Но несмотря на это, мы верили, что есть система и формат, в котором все будет работать иначе.
Сегодня этот период вспоминается с улыбкой, но, поверьте, тогда контроль за этим "чудовищем" был не менее болезненным, чем в период Ганта. В заключение данного этапа:
- Дорожная карта, несмотря на визуальное отображение пути следования, не снимала вопрос со стрессом команды из-за частой смены вектора. Иногда, всего за неделю, дорожная карта могла измениться до неузнаваемости. Все это создавало непонимание как необходимости таких изменений, так и вектора движения, ведь доверия к такой динамичной карте попросту не может быть;
- Попытки адаптировать дорожную карту под плюсы Ганта или Водопада – были глупой идеей. Разный уровень декомпозиции, разные функциональные задачи. Контроль за таким роадмапом оказался не проще, а порой и сложнее, чем Гантом;
- Жесткая зависимость блоков стала номинальной, что позволило легче убирать или перемещать их. Но этот плюс слабо ощущался из-за проблем выше;
- Пришло окончательное понимание, что нужно вводить целеполагание и правильную приоритизацию. Фокус крайне важен. Если слишком часто переключаться с одного на другое просто потому, что в моменте это кажется более перспективным – можно оказаться с кучей недоработанных продуктов и огромным тех. долгом;
- Процессы стали сильно более гибкими. Вся работа выстроилась по принципу производственных цепочек, где каждый отдел генерирует свой результат и передает его в дальше. Эта концепция сохранялась довольно долго, но, со временем, отделы перестали осознавать себя как единое целое. Вследствие этого появлялись кейсы, когда один "копал" налево, а второй – прямо.
Этап 3.5. Промежуточный. Единая система управления проектом, OKR
К этому моменту мы, в целом, сильно продвинулись на пути к пониманию желаемого формата управления в компании. Собрав все минусы и плюсы предыдущих решений, мы снова приступили к поискам.
Одним из самых важных решений на тот момент стал переход всей команды к работе в одной системе управления проектами. Долгое время разработка и другие отделы работали в разных системах. И для того чтобы увидеть полную картину, все приходилось собирать по кускам. Тогда-то мы и нашли Clickup. Развивающийся перспективный продукт, казалось нам в тот день.
Этот переход не только дал единое пространство для работы, но и подсветил интересный формат работы. В процессе перехода, внутри Clickup был обнаружен шаблон OKR.
OKR – это система постановки целей, используемая Google, LinkedIn, Uber, Avito и многими другими компаниями. Она позволяет синхронизировать команду с помощью прозрачности и дерева целей. OKR были введены Эндрю Гроувом из Intel ещё в 1970-х, так что данный фреймворк проделал долгий путь. Подробнее можно прочитать, например, в инструкции от сотрудника Авито.
Ниже – картинка обновленной дорожной карты с учетом целей.
Цели расписаны отдельно и имеют свои KR (Key Results). Стало проще валидировать беклог. Все элементы дорожной карты стали верхнеуровневыми и объем перетасовок сильно снизился относительно прошлых версий, но они все равно продолжались. Новые вводные после опросников, реализации mvp и других тестов могли изменить приоритет у той или иной идеи, от чего необходимо было делать перестановки.
Также, после добавления OKR у нас появилась концептуальная проблема: цели шли "сверху вниз", а не наоборот.
Здесь необходимо сказать, что в формате OKR общий вектор и пожелания задаются "сверху", но цели внутри этого вектора должна ставить команда, таким образом она становится более вовлеченной. Руководство, основатели и прочие стратегические элементы тоже могут принимать участие в формировании целей, но без директивного подхода. Придётся объяснять причины и убеждать команду, чтобы она поверила в цель. В свою очередь, все члены команды делают то же самое.
**Проблема целей "сверху" в чистом виде в том, что это не приближает нас к идеальной системе управления. Во-первых, постановка сверху снимает ответственность с команды, так как эту цель придумывали не они. Во-вторых – команда гораздо сильнее погружена в продукт и может предложить более адекватные и реалистичные цели.**
На деле, конечно, всё оказалось не так просто…
- Один из самых интересных фидбеков по использованию OKR указывает на ключевую сложность внедрения: "У меня проблема с постановкой личных целей, еще и тут это надо делать". То есть, если хотите постановки от команды, будьте готовы к тому, что надо будет этому в прямом смысле совместно учиться;
- В описании методики 70% выполнения считается отличным результатом и завершает цель. Эффективные менеджеры, придумавшие это, хотели ставить цели завышенными, не демотивировав при этом команду. Это, в общем, работает, но не всегда и не очень долго. Лишь несколько итераций. Люди – не дураки, и быстро понимают, как работает система. Мы от этого отказались. Если цель не выполнена на 100%, значит она не завершена. В противном случае начинают возникать абсурдные случаи. Примеры кейса, где логика ломается;
- Цель "Исправить 12 багов, которые ломают систему". Не думаю, что кто-то посчитает хорошим итогом только 70% достигнутого результата тут, потому что без исправления всех, система работать просто не будет;
- Цель "Выполнить миграцию всех данных на новый сервер". Будет абсурдом радоваться только 70% данным на новых серверах;
- Что может быть целью? В чем ее можно измерять? Какие метрики действительно влияют на достижение цели? Немало конкретных вопросов, где не выйдет ориентироваться на поверхностные примеры из статей. Здесь все очень индивидуально, и необходимо коллективно доходить до того, какие могут быть цели;
- Не ставьте целью деньги. Постановка денежной цели работает только в том случае, когда абсолютно не важен способ её достижения и долговечность результатов. На коротком периоде или в критической ситуации, для мотивационного рывка или чего-то подобного – возможно, но для последовательного развития лучше, как нам кажется, переосмыслить подход;
- Куда впихнуть управленческие задачи или те, которые не подходят под цель, но должны делаться? Сюда входит рефактор, регламенты, документация и т.д. Мы пробовали делать заплатки этой проблемы, но это пришлось решать полноценно.
Этап 4. GIST, ICE. Наши дни
В этот же период появилась еще одна методология GIST. Видимо, если не проверил 100500 методологий, то никогда не по-настоящему управлял проектом. В ней объединяются все прижившиеся у нас инструменты, но исчезает дорожная карта, заменяясь действительно гибким решением.
Гибкость получается за счет отсутствия фиксированных планов как факт. Детально можно ознакомиться в статье от создателя Итамара Гилада (переведенная статья), а если кратко:
G – Goals – Цели. Уровень целей в методологии не был жёстко зафиксирован, поэтому можно использовать ее на любом этапе развития продукта и компании. В нашем случае – это уже ранее введенные OKR.
I – Ideas – Идеи. Все идеи по достижению целей. В случае с OKR, мы расписываем идеи для конкретных KR. Все идеи приоритезируются по ICE, подробнее можно прочитать в этой статье.
S – Steps – Шаги. Декомпозиция идеи на этапы, то есть конкретные шаги для реализации и проверки идеи. Важно, что согласно методологии описывать сразу все шаги не требуется. Действовать необходимо итерационно:
- Провести исследование;
- Сделать и проверить прототип;
- Сделать и проверить MVP и т.д.
То есть если на каком-то из этапов вы понимаете, что идея не жизнеспособна – отказывайтесь. Ваша цель в данном случае – как можно раньше понять, что идея провальная.
T – Tasks – Задачи. Декомпозиция шагов на конкретные задачи для сотрудников. Здесь все просто. Под логику работы и ведения задач каждого отдела закидываем задачи, связанные с шагами.
Как упоминалось выше, все идеи имеют свою оценку по ICE. Но это не статичная история, все три составляющих со временем могут меняться.
- Получили новые цифры из недавнего исследования по идее? Значит надо поправить Impact и повысить Confidence.
- Тестирование на прототипе показало, что не хватает нескольких функций? Надо увеличить Effort.
Все это меняет приоритет задачи относительно остальных идей и позволяет переключаться на более перспективные, закидывая эти в ожидание или попросту убирая из работы. Чем раньше, тем меньше ресурсов на нее будет потрачено. Это ключевая крутая идея данной методологии.
Другой бонус – это прозрачность, при четком ведении внутри системы управления проектами. То, что раньше давал только Гант или Водопад – теперь в одном флаконе, но без надобности делать перестановки каждые три минуты в какой-то таблице. Все приоритеты меняются сами при добавлении новых вводных и изменении оценки. Для каждой идеи можно увидеть шаги, посмотреть какие задачи делали, и как шёл процесс. Рай для управленцев!
Теперь планирование можно визуально делать хоть на стикерах. Будет понятно, что делают и почему. Но это в идеальном мире, а как мы знаем, любая методология требует проверки практикой и адаптации под компанию.
Самый большой квест с данной методологией – это понимание на каком уровне она должна работать. Это касается как идей, так и целей, ведь есть цели внутри отдела, есть цели глобальные, есть цели по продуктам, – что из этого надо брать и раскладывать по методологии? Готового ответа просто не оказалось, брали и проверяли методом перебора на реальных задачах компании.
С идеями такая же сложность. Что является идеей из предложенных?
- "Разместить видеообзор на лендингах и социальных сетях";
- "Давать подписку в подарок после покупки любого другого продукта";
- "Через рекламу внутри приложения можно приводить лиды на консультации".
Вроде бы все это похоже на идеи. Вот только нюанс в их разном уровне, а то и вовсе что-то уже не идея, а готовое решение... Надо учиться правильно формулировать идеи на основе своих мыслей.
Мы для себя решили, что идея не должна быть конкретным действием, а является замыслом, определяющим направление и содержание возможного спектра действий. Сделано так для того, чтобы не сужать круг возможных тестов самой идеи. Например, "увеличить узнаваемость путём наращивания присутствия в соц.сетях" – это идея. А "разместить 3 ролика на определённую тематику в телеграм-канале" – это задача и конкретное действие.
Для поиска решений всех вопросов, описанных ранее, мы подошли к задаче продуктово. Делаем небольшой тест, получаем результат, меняем решение, если результаты не устраивают. Или же начинаем его внедрение для всех, если полет нормальный. На сегодня, после всех изменений, плюсы следующие:
- Ушли в прошлое вечные "перешивания" дорожной карты, обновления таблиц или каких-то досок. Теперь тратим это время на другие задачи;
- Несмотря на то, что GIST, ICE и OKR еще необходимо докручивать под себя, разбираясь с вопросами команды по пути, мы получили более прозрачную модель приоритезации того, что сейчас возьмем в работу. Уменьшили количество влетающих срочных прорывных идей – теперь они записываются, оцениваются и берутся в работу только в случае, если она соответствует цели и оценка высокая;
- Логика работы с идеями, где необходимо как можно раньше понять ее несостоятельность, помогает экономить ресурсы компании и команды. Больше нет больших релизов сложного функционала, который оказывается ненужным или неправильно реализованным для пользователей. Теперь все зависит от того, насколько качественно и правильно тестируется гипотеза. Чем лучше мы это делаем, тем быстрее понимаем: отпустить идею и не тратить на нее ресурсы, или нужно довести ее до ума, с большей уверенностью в ее положительном влиянии на метрики;
- Гибкость в процессах. Сейчас команда сама выбирает, что взять в приоритет из идей, ровно как и сама принимает решение, если необходимо изменить курс в работе;
- Сильно больше тестов гипотез стало проводиться без участия разработки или дизайна, что сильно экономит ресурс. Некоторые идеи просто не затрагивают команду и трансформируются или убираются еще на этапе работы продактов.
Текущие проблемы:
- ICE, как система приоритизации звучит очень просто, но почти полностью субъективна. Два человека, выставляя оценку в 5 баллов для Confidence, могут совсем по-разному воспринимать ее;
- Как ранее писали, постановка целей – не самая простая задача в целом, и нам командой предстоит и дальше учиться этому;
- Правильная формулировка идей с точки зрения методологии. Тоже только учимся и ищем баланс, чтобы это не превращалось в бюрократию, а именно помогало сформулировать идею через дополнительные вопросы;
- Сейчас мы перешли к одной общей цели для компании в формате OKR, чтобы сподвигнуть все отделы думать и совместно решать, как её достигнуть. Это круто, но остаются задачи, которые не подходят под эту цель. Они, как правило, управленческие и от них нельзя отказаться, но и заносить в данную цель некорректно. Напрашивается разделение целей на бизнесовые и управленческие;
- Все в команде знают цель, к которой мы идем, и причину движения к ней, но не все понимают, как на нее могут прямо повлиять. Допустим, разработчики и дизайнеры почти всегда являются лишь исполнителями задач от заказчиков – маркетинга или продактов;
- Поддержание порядка в системе управления проектами. При переходе, пока все учатся, остается много мусора, неописанных идей, забытых шагов и т.д. Необходимо будет докручивать процессы внутри каждого отдела, чтобы был единый стандарт оформления всего внутри.
Планы как это исправлять:
- Для ICE добавим критерии, чтобы оценку можно было проставлять не из воздуха. Например, в случае с Confidence мы добавим чек-лист с 5-10 вопросами формата "да/нет" и баллами за каждый вопрос. Такая идея реализована у конкурента? +2 балла к оценке. Коллеги поддерживают эту идею? +1 балл. В теории это может решить вопрос субъективности при оценках;
- С целями – просто продолжаем экспериментировать и учиться. Здесь цикл проверки долгий, так как они не пересматриваются часто;
- Упростим определения во внутреннем документе о том, что такое идея и добавим кроме примеров 1-3 вопроса, которые помогут получить нужную формулировку;
- Добавим разделение на бизнесовые цели и управленческие, проверим как это работает для начала только в одном отделе. Фактически, это решение, в случае успеха, приблизит нас к матричной системе организации, что было давней нашей целью;
- Проблема влияния на цель скорее всего решится в случае успеха гипотезы в пункте выше;
- Точечно с каждым руководителем отработаем завалы и поймем, как это решить или автоматизировать. Конкретного решения нет, так как люди были созданы, чтобы ломать любые системы. Но пока что единственно эффективный концептуальный способ – сделать так, чтобы это нужно было команде, тогда все и всё будут вести и заполнять.
Выводы:
- Иногда кажется, что всё можно внедрить или сделать сильно быстрее. И это было бы действительно так, если бы мы были машинами. Но мы люди. Для правильной совместной работы нам необходимо быть на одном уровне понимания друг с другом, иметь схожий понятийный аппарат и т.д. Бывает, что только на это могут уйти годы. А когда это есть, всё автоматически начинает двигаться во много раз быстрее.
- Если кто-то говорит, что внедрил такую-то методологию и через 2 недели компания начала расти х1000 млн раз, есть вероятность, что здесь что-то не так. Лучше задать уточняющие вопросы. После этого, с большой вероятностью, ты перестанешь расстраиваться из-за того, что все "запускают ракеты", а ты до сих пор решаешь низкоуровневые задачи.
- По опыту работы с другими проектами, взращивая свои, фиксируется наблюдение: для того, чтобы любой бизнес-проект занял хоть какое-то стабильное место на рынке, в нём базово устаканились процессы, появилась узнаваемость и т.д. должно пройти, в среднем, около 4-х лет. Сюда не включается "успешный успех" и история с чересчур масштабными венчурными инвестициями. Речь про стандартный подъём любого прибыльного бизнеса. Не аксиома, но, начиная новый проект, не расстраивайся и готовься к марафону со спринтовыми отрезками.
- Всё происходящее потихоньку приближает нас к формату, похожему на систему Магомеда Чартаева. Есть ощущение, что в будущем, по-настоящему успешными, помимо корпораций, станут предприятия с подобной организационной моделью.