Поиск идеальной системы управления

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

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

Этап 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-х лет. Сюда не включается "успешный успех" и история с чересчур масштабными венчурными инвестициями. Речь про стандартный подъём любого прибыльного бизнеса. Не аксиома, но, начиная новый проект, не расстраивайся и готовься к марафону со спринтовыми отрезками.
Всё происходящее потихоньку приближает нас к формату, похожему на систему Магомеда Чартаева. Есть ощущение, что в будущем, по-настоящему успешными, помимо корпораций, станут предприятия с подобной организационной моделью.