Ворчливый IT-дед

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

Берем вариант И1-Р1-П1-С1-В1, то есть внутренняя маленькая планируемая асап крит цель. Такие предлагаю пропускать мимо всех процессов. Потому что вряд ли ей кто-то будет интересоваться, задача срочная и важная, лучше сразу сделать и не тратить время на оформительство.
 
Впрочем, то же самое можно сказать про все маленькие цели. Просто если источник - руководство или инфра, а важность - крит или важно, задачу И[2-3]-Р1-П*-С*-В[1-2] нужно
а) точно сделать (не продолбать),
б) сказать об этом заказчику в свободной форме. То есть формализм с целями и планированием тут избыточен, если вы выполняете свои обещания и у вас норм коммуникация с заказчиком.
 
Прежде, чем приступать к планированию, нужно убедиться, что у нас есть актуальная стратегия технологического развития. Потому что если ее нет, не получится убедиться, что проекты в плане не отдаляют нас от целей. В стратегии должны быть зафиксированы какие-то таргет-стейты, целевой стек, чувство прекрасного, а также - утвержденные большие цели (Р3) на горизонте. И уже составляющие этих больших целей должны быть пригодны к планированию. Большие цели планировать бесполезно, их нужно декомпозировать с убывающей детализацией.
 
В стратегии стоит обозначать основные постулаты, что мы считаем хорошим и правильным. Каким требованиям должна верхнеуровнево отвечать система. Какие подходы мы практикуем. Эдакий манифест + таргет-стейт.
 
Про влеты. Очевидно, на то они и влеты, что запланировать их нельзя. Но нужно понимать, что они будут. А значит -
а) оставлять под них небольшой зазор (никогда не планируйтесь "под крышечку"! кстати, продуктовых целей это тоже касается),
б) при появлении влета максимально прозрачно уведомлять стейков тех проектов, которые сдвинутся из-за влета (и на гринлайте/чекапе тоже подсвечивайте).
Асап-криты (И*-Р*-П2-С1-В1) примерно все тут.
 
Про вечные цели. Тут тоже нет большого смысла упарываться в их оформление или планирование. Просто не продалбывайте их показатели, и всем будет все равно, как вы это делаете. Условно говоря, можно не ставить цель "повысить рпс-аптайм в сервисе Х", если на момент гринлайта там будет целевое значение.
 
Таким образом, воронка проектов, пригодных к планированию, состоит из небольших планируемых целей И*-Р2-П1-С*-В[1-3]. Уже не столь важен источник - для прозрачности работы и корректности учета капасити нужно планировать и внутренние задачи тоже. Размер проектов должен позволять уложить их в 1-2 квартала. Если больше - декомпозируйте.
 
Дальше осталось приоритизировать проекты, исходя из их срочности и важности. Тут уже можете сами выработать формулу отношения порядка. Но интуитивно - срочное-важное должно попасть в план с сильно большей вероятностью, чем бессрочный найс-ту-хэв. Рекомендую попробовать посчитать такую метрику как cost of delay - и брать в работу в первую очередь те проекты, откладывание которых стоит дороже. Но, очевидно, если задача асап - ее надо сразу брать в работу. Если есть конкретный срок, и он в планируемом ку, надо брать (если в следующем ку, но работы много - нужно брать уже в этот). И сначала критичное и важное. И уже потом полости в плане заполнять не-срочными и найс-ту-хэв вещами. Ими же можно заполнять полости в процессе квартала, например если не было влетов, а зазор остался.