Техноцели (4/4)

Кстати, о непосредственно работе над техноцелями. (Врочем, этот абзац в той же степени справедлив для продуктовых целей.) Если вы в команде распределяете цели/проекты по людям, которые в дальнейшем тащат их в 1 щачло, вы плохо работаете с рисками. Например, есть 4 человека в команде. И 4 цели/проекта. Если каждый человек будет делать свой проект, то к концу квартала вы рискуете подойти с 4 незаконченными проектами. Напомню, проект, законченный на 90% - это незаконченный проект. Даже если случится чудо, и все успеют закончить свои проекты, пользу от этих проектов мы начнем получать лишь с конца квартала. Не лучше ли сначала командными усилиями, вчетвером, затащить самый ценный проект и уже через месяц начать получать с него профит, потом командой затащить второй, и в середине квартала получать пользу от него, и так далее? Тут работает тот же cost of delay, быстрее обналичиваются эффекты, да и риски легче митигировать.
 
Любой прогресс нужно трекать. Для этого у нас есть ежемесячные гринлайты/чекапы.
Там мы смотрим вот примерно то же самое, что попало в планирование - И*-Р2-П1-С*-В[1-3].
Плюс иногда смотрим на большие цели - есть ли там изменение динамики вследствие успехов/неуспехов локальных вех.
Плюс там рассказываем о влетах и можем упомянуть про мелкие, но важные/интересные задачки.
В конце полугодия полезно собрать итоговый результат - по средним и большим целям, а также по метрикам вечных.
 
Также отмечу, про промежуточные точки контроля нужны не только для того, чтобы проветь свою успеваемость, но и для возможных корректировок планов. Чем чаще мы сверяемся, правда ли текущие усилия приближают нас к целевой картине, тем больше у нас возможностей адаптировать свой план к конъюнктуре момента. Короткая гранулярность сверки помогает быстрее поворачивать в нужную в моменте сторону.
  
Итого, я бы предложил два вида техноцелей - большие (цели) и небольшие (проекты).
Остальная техничка никуда не девается, но ее можно так явно не заводить и не трекать, лишь бы все работало хорошо (ну типа метрики, все такое).
Большие цели обязательно должны декомпозироваться на какое-то количество небольших проектов по принципу OKR - то есть мы верим, что вот такие проекты приведут нас к цели.
При этом не обязательно каждый небольшой проект должен быть привязан к какой-то большой цели, если он сам по себе обоснованно полезен.
Каждый проект должен иметь объяснимую пользу, желательно на метриках.
Если этот проект делается в рамках большой цели - он сам по себе тоже должен приносить частичную пользу.
Также удобно укладывать цели/проекты в дерево, чтобы было наглядней, в какие метрики оно бьет.
 
То есть флоу должен быть примерно такой:
 
стратегия -> цели (зачем?) -> проекты (как?) -> планы -> ... -> профит!!! -> статус-чек
 
Итого получаем каскад от ценностей к конретному плану с оценкой результата и профита. Как-то так.