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

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

Техноцель - по сути, это все, что не исходит от продукта/бизнеса напрямую.
 
Оно может появляться из разных (И)сточников:
1. Изнутри команды. Чаще всего, вам самим видней, что болит, и во что нужно проинвестировать. Тут вам нужно уметь объяснить "чтобы что". Например, мы хотим потратить месяц на рефакторинг сервиса Х, потому что сейчас разбор каждого дьютика по нему занимает час+, а после рефакторинга мы сможем дать техсапу тулинг самостоятельного разбора жалоб.
2. От руководства. В рамках какой-то стратегии или вижена. Руководство тоже должно объяснить "чтобы что". Например, переписать легаси-сервис Х на стек У, потому что найм разработчиков на стеке У дешевле и мы хотим в перспективе переходить на него.
3. От инфры. Обычно связано с какими-то масштабными переездами/стройками. Тот редкий случай, когда аргументации "чтобы что" может не быть. Например, переезд в новый оркестратор деплоя, потому что старый закапывают (а вот с хрена ли, и кому станет лучше - не всегда легко выяснить, но сделать с этим иногда ничего нельзя).
 
Другой разрез целей - их условный (Р)азмер/продолжительность. Тут цели бывают
4. Маленькие. То, что можно сделать за 1-2 спринта. Просто сделайте и не любите голову, как их оформлять и отчитываться, дольше расписывать. Просто если это важное, предупредите соседние команды, кому полезно знать, и, может, расскажите о результатах на техновстрече, если есть что поведать. Например, "а кстати - мы тут запилили клевый линтер, можете переиспользовать".
5. Небольшие. Делаются за квартал или два. Их надо нормально описать и защитить, они составляют костяк утилизации техноквоты. Например, написать драйвер для постгреса под ноду.
6. Большие. Занимают больше полугода, иногда год-два. По ним нужно самое четкое описание и обоснование. Их нужно делить на этапы/вехи/майлстоуны. Иногда можно сразу весь проект расписать на несколько кварталов вперед, но чаще - ближайший этап описывается подробно, а последующие - верхнеуровнево. Важно, чтобы ближайший этап был четко обозрим, конечен, и должен уже приносить пользу даже до окончания проекта целиком. Например, распил очередного монолита.
7. Вечные. Это те направления деятельности, которыми нужно в той или иной степени заниматься перманентно - иногда более интенсивно, иногда менее. Например, выполнение метрик technical excellence, ZBP, secutity error budget. Тут важно четко понимать, где сейчас что западает, куда сильнее навалиться.
 
С точки зрения (П)ланируемости - тут все просто, есть всего два типа.
8. Можно запланировать заранее. Мы заведомо знаем, что это надо делать. Например, адопшен какой-то технологии.
9. Влёты. В планах не было, но внезапно появилась такая потребность. Например, уперлись в производительность какого-то куска и надо его оперативно сделать более масштабируемым.
 
Еще один срез - (С)рочность. Выделим три варианта:
10. Асап. Надо брать задачу вот прямо сейчас. Например, уязвимость 0 дня.
11. К определенному сроку. Например, к моменту вступления в силу какого-нибудь определенного закона.
12. Не важно когда, просто надо сделать. Например, перейти с самопального решения на какую-то поддерживаемую библиотеку.
 
И последнее - (В)ажность.
13. Крит. Нельзя не делать, есть сильный негативный эффект от не-делания. Например, баг, блокирующий функциональность.
14. Важно. Есть понятный положительный эффект от задачи. Например, тыква, которая снижает потери при инцидентах.
15. Nice to have. Лучше сделать, но не болит. Например, перейти на новый ci, потому что в нем есть какая-то фишка.
16. Можно не делать. Если цель попадает в эту категорию, лучше ее сразу закрыть. Ну а нафига.
 
Теперь, собственно, давайте разбираться, какое должно быть целеполагание и процесс трекинга целей в зависимости от их попадания в ту или иную комбинацию срезов выше. Тут буквально 288 вариантов получается, давайте их все раскидаем по форматам работы с целями. Шутка. Или нет?