Работа каждого руководителя начинается с PDCA (Plan–Do–Check–Act)⁠⁠

Работала в одном из моих самых первых стартапов командиром админов девочка-админ из Питера. Говорят, в Питере даже у хулиганов два высших образования — вот и она была чёткая, как питерский пацан и резкая, как клинок в питерской подворотне! Её отец (тоже питерский админ) учил так, — пока чёткий план не составишь, руки на клавиатуру не кладёшь!

Хорошее правило, да и вообще стандартный управленческий цикл состоит из 4х элементов: планирование, работа, контроль и развитие. Никакую компоненту выкинуть не получится. Если оставить только планирование и развитие без контроля за результатом, — получается ерунда. Именно так всё тогда и случилось.

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

Беда была в том, что планировать она умела, а вот выполнять получалось не очень. Точнее как... Так получилось, что исполнителем был как раз её отец, но он не исполнял. А она не могла его проконтролировать должным образом. В результате из всего управленческого цикла было только планирование.

Зато бабло на развитие команда админов просила регулярно, — чтобы влить, например, в оборудование. Я однажды отказал в финансировании на обновление серверов — решение оказалось ошибочным: сервис перешёл в режим ReadOnly на несколько суток, пока срочно не докупили новых серверов. Без прозрачности и системного контроля принятие каких бы то ни было решений превращается в рулетку (русскую) — и почти всегда стреляют в бизнес. Этот случай я до сих пор использую как пример рисков при отсутствии контроля в управленческом цикле.

Руководителю лучше заранее решить, за что браться самому, а что делегировать для обеспечения полноты управленческой цепочки. Ну или надеется на "авось", а потом расхлебывать. В нашем случае девочка планировала, её отец брался за работу и развитие. Но цепочка была неполной как раз из-за отсутствия контроля — никто по-настоящему не отвечал за результат. Вот и получили то, что получили.

Какой вывод можно сделать? Любая перекошенная конфигурация PDCA почти всегда чинится — главное, вовремя откалибровать баланс между вовлечённостью руководителя и делегированием. А вот если без балансировки просто потерять какой-то элемент из цепочки, то последствия неизбежны.

Не умею работать с руководством: отстаивать границы впихуемости по порученным задачам.

Бизнес всегда будет желать напихать задач полную панамку.

Первым рубежом в обороне и систематизации задач будет оценка и группировка, — это Твоя ответственность. Важно понимать границу между оценкой (примерное представление о размере задачи) и декомпозицией (уже полноценная работа над ней). Процесс уточнения и детализации задач называют грумингом (или backlog refinement), а оценка задач проводится в рамках планирования или специальных встреч. Оценивают задачи в крокодилах, бананах, бутылках — или по классическим методам, например, покеру планирования с использованием последовательности Фибоначчи.

Зачем нужна такая грубая оценка? Чтобы бизнес мог сопоставить трудозатраты с потенциальной ценностью задачи. После этого он может применить фреймворки приоритезации, такие как MoSCoW, ICE, RICE и прочие, чтобы определить, что действительно нужно сделать в первую очередь.

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

Держать бэклог в приоритезированном состоянии — это только полдела. Надо ещё понять, сколько задач команда может физически осилить. Надо понять широту размаха челюсти команды - velocity :) Для этого существует несколько способов оценки, включая оценку в человеко-часах, сторипоинтах, T-shirt sizes и другие.

Velocity — это не просто количество задач за спринт, а сумма их оценок (например, в сторипоинтах) за спринт, а совокупная способность команды выполнять задачи, включая багфиксы, тестирование, митинги и прочую обвязку. В реальности бОльшая часть времени может уходить на поддержку, рефакторинг и другие технические нужды. Поэтому рассчитывать, что 100% ресурсов пойдут на новые задачи, — полный фейл. Не попадись на эту удочку!

Как только команда поймёт своё реальное velocity, станет очевидно, что любая новая задача вытесняет другую. Кому станет очевидно? И команде, и бизнесу. И вот тут начинается меджик — бизнес перестаёт думать, что производительность команды резиновая.

Теперь можно чётко отстаивать границы впихуемости. Если бизнес диктует, что "завтра всё должно быть в 100 раз масштабируемо", CTO не кидается в бой с криками "сейчас запилим!", а чётко объясняет, какие ресурсы потребуются, какие риски возникнут и какие альтернативные варианты возможны. Главное — не просто говорить "нет", а предлагать реалистичные варианты решения проблемы.

Видишь? Мы отстроили процесс груминга, приоритезации, декомпозиции и оценки задач, взятие в работу только реального объёма бэклога спринта, и внезапно — у нас резко наладились отношения с бизнесом. Бизнес больше не ждёт чудес, команда работает без авралов, CTO перестаёт быть мальчиком на побегушках.

Важно с бизнесом говорить на его языке. Если разработчики постоянно в аврале, а менеджеры требуют новых фич, нужно донести, чем это обернётся:

• Затраты на поддержку вырастут → Дороже обслуживать.

• Продукт становится нестабильным → Клиенты уйдут к конкурентам.

• Отток специалистов → Потери на найме и онбординге.

Поэтому CTO — это не просто технический управленец, а человек, который понимает, как встроить технический блок в коммерческую стратегию компании и поддерживать баланс между техническими возможностями и бизнес-целями.

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

П.С. объявляю конкурс на иллюстрацию к этому посту!