Не умею работать с руководством: отстаивать границы впихуемости по порученным задачам.
Бизнес всегда будет желать напихать задач полную панамку.
Первым рубежом в обороне и систематизации задач будет оценка и группировка, — это Твоя ответственность. Важно понимать границу между оценкой (примерное представление о размере задачи) и декомпозицией (уже полноценная работа над ней). Процесс уточнения и детализации задач называют грумингом (или backlog refinement), а оценка задач проводится в рамках планирования или специальных встреч. Оценивают задачи в крокодилах, бананах, бутылках — или по классическим методам, например, покеру планирования с использованием последовательности Фибоначчи.
Зачем нужна такая грубая оценка? Чтобы бизнес мог сопоставить трудозатраты с потенциальной ценностью задачи. После этого он может применить фреймворки приоритезации, такие как MoSCoW, ICE, RICE и прочие, чтобы определить, что действительно нужно сделать в первую очередь.
Это позволяет избежать ситуации, когда разработчики бросаются на "огненные" задачи, которые в конечном счёте не приносят ценности, а реально важные вещи тонут в хаосе.
Держать бэклог в приоритезированном состоянии — это только полдела. Надо ещё понять, сколько задач команда может физически осилить. Надо понять широту размаха челюсти команды - velocity :) Для этого существует несколько способов оценки, включая оценку в человеко-часах, сторипоинтах, T-shirt sizes и другие.
Velocity — это не просто количество задач за спринт, а сумма их оценок (например, в сторипоинтах) за спринт, а совокупная способность команды выполнять задачи, включая багфиксы, тестирование, митинги и прочую обвязку. В реальности бОльшая часть времени может уходить на поддержку, рефакторинг и другие технические нужды. Поэтому рассчитывать, что 100% ресурсов пойдут на новые задачи, — полный фейл. Не попадись на эту удочку!
Как только команда поймёт своё реальное velocity, станет очевидно, что любая новая задача вытесняет другую. Кому станет очевидно? И команде, и бизнесу. И вот тут начинается меджик — бизнес перестаёт думать, что производительность команды резиновая.
Теперь можно чётко отстаивать границы впихуемости. Если бизнес диктует, что "завтра всё должно быть в 100 раз масштабируемо", CTO не кидается в бой с криками "сейчас запилим!", а чётко объясняет, какие ресурсы потребуются, какие риски возникнут и какие альтернативные варианты возможны. Главное — не просто говорить "нет", а предлагать реалистичные варианты решения проблемы.
Видишь? Мы отстроили процесс груминга, приоритезации, декомпозиции и оценки задач, взятие в работу только реального объёма бэклога спринта, и внезапно — у нас резко наладились отношения с бизнесом. Бизнес больше не ждёт чудес, команда работает без авралов, CTO перестаёт быть мальчиком на побегушках.
Важно с бизнесом говорить на его языке. Если разработчики постоянно в аврале, а менеджеры требуют новых фич, нужно донести, чем это обернётся:
Затраты на поддержку вырастут → Дороже обслуживать.
Продукт становится нестабильным → Клиенты уйдут к конкурентам.
Отток специалистов → Потери на найме и онбординге.
Поэтому CTO — это не просто технический управленец, а человек, который понимает, как встроить технический блок в коммерческую стратегию компании и поддерживать баланс между техническими возможностями и бизнес-целями.
Впихуемость — штука коварная, как чемодан без ручки: тащить тяжело, а бросить страшно. Отстаивай границы, управляй ожиданиями, приоритизируй с умом — и однажды бизнес сам предложит оставить пару задач в бэклоге "на потом".
П.С. объявляю конкурс на иллюстрацию к этому посту!
