Что такое проекты развития и зачем они нужны в вашей компании

Привет, на связи Игорь Котов — директор по производству в Технократии. Сегодня хочу вам рассказать, как мы работаем с проектами развития. Что это такое и какой фреймворк мы выбрали для этого.

Всё началось в 2019 году. У нас было порядка 50 человек и мы росли х2 год к году. Когда компания активно расчёт, ей требуется быстро меняться потому что нет выстроенных процессов, которые бы обеспечивали способность переваривать такой рост. Отсутствуют страхующие механизмы и многое создаётся впервые. Необходимо успевать за ростом количества сотрудников и проектов.

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

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

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

1. Постановка задачи. Этот этап аналогичен составлению ТЗ. От качества и полноты этого документа будет зависеть полученный результат. Ведь как известно без ТЗ результат ХЗ: )

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

   
   

3. Внедрение изменения. Внедрение изменения наверное самый долгий этап и аналогично разработке требует вовлечённости и слаженной команды.
   

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

5. Фиксация результата. Как и в разработке после того, как мы отловили все ошибки и стабилизировали релиз наступает время передачи заказчику и начала эксплуатации продукта.

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

Это один из самых важных этапов, так как от того, как мы сформулировали задачу и будет зависеть какой результат мы получим и получим ли вообще. Соответственно первым делом мы должны определить критерии завершённости изменения. Можно назвать это целью проекта. Для этого отлично подходят классические постановки по S. M.A. R.T. или по методике OKR.

При формулировании задачи распространённой ошибкой может быть «лечение симптомов», а не истинной проблемы, которую мы хотим исправить. Если вы это поймёте на этом этапе, то это сэкономит вам кучу сил, когда вы снова будете возвращаться к лечению тех же самых «болячек» в компании. Чтобы понять, что же привело к появлению этих «симптомов» можно использовать диаграмму Исикавы или технику «5 почему?».

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

Когда с постановкой закончено наступает этап разработки стратегии изменений. Здесь мы для себя выработали несколько принципов, которых стараемся придерживаться. В первую очередь мы стараемся всегда описать стратегию «на бумаге». Это позволяет не забыть исключения или какие-то редкие кейсы, которые в разговоре можно легко упустить. Для наглядности мы также приняли для себя правило, что стратегию изменений описываем в виде схем или диаграмм. Мы экономим своё время и время других людей, поэтому наглядные и ёмкие блок-схемы или BPMN диаграммы это скорее необходимость.

Для построения красивых и понятных диаграмм можно посоветовать сейчас популярный инструмент Miro, который в себе содержит уже кучу готовых шаблонов для представления данных или старый добрый Visio от Microsoft. Разумеется можно обратиться к аналоговому маркеру и флипчарту.

После всех предварительных этапов начинается внедрение. Как и любой наш проект по разработке ПО внедрение мы начинаем с установочной встречи (kickoff) . На этой встрече мы собираем всех стейкхолдеров процесса, рассказываем о цели изменения, презентуем стратегию и дедлайны. Важно донести это до каждого, кого касается изменение, чтобы дальнейший процесс не вызывал дополнительные вопросы, ведь дальше начинается пилот. Мы запускаем MVP. Особенностью этого процесса является то, что пилотирование проводится на небольшой выборке людей или проектов, чтобы убедиться в работоспособности гипотезы. Это снижает риск последствий от непродуманных действий.

Данный этап нужен, чтобы синхронизироваться в понимании, насколько всё идёт по плану и избежать ошибок. Как и при разработке ПО, на этапе тестирования мы снимаем текущие показатели и сравниваем их с теми, которые мы определили на этапе постановки задачи. Целевые показатели как раз и нужны для того, чтобы на этом этапе подтвердить или опровергнуть правильность выдвинутой гипотезы.

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

Случается, что идея не выстрелила. В этом случае лучше вернуться на 1 этап или отложить проект до лучших времён.

Если пройдя все 4 этапа идея проекта развития доказала свою состоятельность и эффективность, то новые правила масштабируются на всю компанию / отдел / проект, а сама стратегия фиксируется в wiki или своде правил, к которым имеет доступ любой сотрудник. Принципиальный момент здесь состоит в том, что регламенты и правила фиксируются только после того, как мы поймём, что схема рабочая.

Используя этот подход уже не первый год и реализовав множество проектов развития могу выделить основные преимущества.

• Прозрачные ожидания всех заинтересованных сторон;
• Результаты фиксируются только в конце, когда убедились, что изменение работает;
• Понятный план действий и наглядность движения проектов развития;
• Мягкое внедрение за счёт пилотного запуска;
• Фреймворк хорошо встраивается в методологию OKR

Мы начали этот процесс на уровне руководства компании, когда в 2019 году поняли, что наши процессы не успевают за ростом количества сотрудников и проектов. Но в последствии, внедрив методологию OKR, этот фреймворк стал использоваться на уровне отдельных департаментов и отделов. Я считаю, что эта практика также хорошо ложится на продуктовые команды, которые готовы системно подходить к изменениям внутренних процессов. Также этот подход можно использовать в менторстве отдельных сотрудников.

Также подписывайтесь на наш телеграм-канал «Голос Технократии». Каждое утро мы публикуем новостной дайджест из мира ИТ, а по вечерам делимся интересными и полезными статьями.