Привет! Это продолжение жесткого разбора базовых ИТ-процессов.
В прошлый раз мы выяснили, что без формализованного «входа» (шлюза) любая ИТ-команда превращается в пожарную команду, которая тушит то, что громче кричит.
Но теория — это скучно. Сегодня — практика.
Я прошлась по своим заметкам консультанта и ментора и собрал 9 самых частых бед, которые убивают ИТ-департаменты изнутри. А главное — даю 4 железобетонных правила, с которых нужно начать, если вы хотите выжить.
Почему у большинства бардак?
Потому что все пытаются внедрить сложные методологии (PMBoK), не закрыв базу. Это как построить крышу небоскреба на фундаменте из песка.
Вот она, база. Читайте и примеряйте на себе.
9 симптомов того, что ваш «вход» сломан (диагноз)
Если узнаете себя хотя бы в трех пунктах — статья для вас.
- Нет общей очереди (беклога). Задачи прилетают в личку тимлиду, техдиру и просто в «Телеграм-чат с боссом». Итог: CIO на разрыв, внеплановые пожары, выгорание тех, кто ловит эти задачи лицом.
- Беклог есть, но приоритетов нет. Все задачи — срочные и важные. Если у всего приоритет «Критический», то приоритета нет вообще. Команда делает то, что громче крикнут.
- В беклоге нет оценок. Вы не знаете, сколько это займет времени. Вы просто обещаете «как-нибудь сделать побыстрее». Спойлер: не получится.
- Нет формализованных постановок. Задачи ставятся в стиле «сделай как в том приложении». Разработчик делает «как понял», заказчик говорит «это не то». Сроки горят, все злы.
- Нет планирования. Потому что нет ни очереди, ни приоритетов, ни оценок. Ресурсы команды пересекаются, задачи валятся, сроки едут вправо, а виноватых не найти.
- CEO не понимает, что делает IT. Директор видит черный ящик. Туда что-то кидают, оттуда что-то выходит, но когда — непонятно. Обычно это приводит к замене CIO.
- Бизнес ненавидит IT. И часто справедливо. Бизнес не идеален, но из-за неотстроенных процессов именно айтишники становятся крайними.
- IT считает себя героями. «Мы отстреливаемся от неадекватных заказчиков в окопах, спасая мир!». Нет, ребята. Если заказчики постоянно лезут без очереди, вы просто не смогли выстроить процесс.
- Внеплановых задач больше 70%. Это не команда, это служба спасения. Плановые задачи при этом не делаются, становятся срочными, и круг замыкается.
Унылый итог: бизнес не верит, CEO не понимает, CIO недоволен, команда перерабатывает и выгорает, а сроки едут вправо, как их ни крути. Треш-угар.
Что делать? 4 железобетонных правила
Эти правила не требуют внедрения сложных правил или покупки дорогого софта. Они требуют только одного — дисциплины. Делайте обязательно, если у вас еще не так.
Правило 1. Общий беклог входящих (и только так)
Команде запрещено брать задачи в работу мимо единого беклога.
Слово «запрещено» — жесткое. Но это работает. Как только вы договорились, каждое нарушение выносится на публичное обсуждение: «Почему задача ушла в обход очереди? Что случилось? Как мы это допустим в следующий раз?». Если не обсуждать нарушения, система развалится за неделю.
Правило 2. Приоритизация (любая, но честная)
Неважно, какую методику вы выберете. Важно, чтобы все стороны договорились ее соблюдать.
Задача бизнеса — расставить приоритеты. Задача IT — сказать, сколько это займет времени. Любое несоблюдение приоритетов (когда большая шишка просочилась мимо) должно открыто обсуждаться.
Правило 3. Единый формат постановки задач
Входящие требования должны быть пригодны для верхнеуровневой оценки. Если бизнес пишет «сделайте приложение красивым» — это не задача.
- Либо бизнес учится писать ФТ (функциональные требования).
- Либо это делает аналитик за свой счет.
Но есть жесткое правило: Если постановка непригодна для оценки — задача возвращается бизнесу без помещения в беклог. Пока она не будет готова, она не считается поступившей в работу.
Правило 4. SLA по оценке и планированию
Бизнес должен знать, когда он получит ответ. Это снимает 90% нервотрепки.
«Оценка и плановый срок реализации будут предоставлены в течение 5 рабочих дней» — это нормально.
Если за 5 дней вы не можете дать оценку — значит, нужно подключать аналитику или уточнять требования (см. Правило 3). Но молчание убивает коммуникацию.
Важно! Это работает только в связке
Сделать только одно правило из четырех — бесполезно.
- Если вы сделаете беклог, но не будете приоритизировать — будет очередь из «срочно».
- Если вы сделаете приоритеты, но не будете следить за форматом постановки — разработчики будут тратить время на уточнения и злиться на бизнес.
- Если вы сделаете все это, но не скажете бизнесу про SLA — они будут дергать вас каждый час: «Ну когда вы уже оцените?».
Сделаете всё вместе — получите предсказуемость.
Сделаете часть — недовольный бизнес пойдет к CEO и скажет: «ИТ саботирует, мы им задачи кидаем, а они их не берут, придумали какие-то очереди!». И процессы снова вернутся в треш-угар.
Что дальше?
Вы наладили шлюз. Задачи теперь приходят чистыми, описанными и с приоритетом.
Отлично. Но это только первый шаг. Теперь нужно понять: а кто это вообще будет делать?
Следующая, самая страшная и сложная тема — Ресурсное планирование.
Как понять, что команда не резиновая?
Как сказать бизнесу «нет», когда ресурсов на их крутую идею просто нет?
И как не сгореть самим, пытаясь объять необъятное?
Об этом — в Части 3. Ресурсное планирование (или "Откуда берутся руки").
А как у вас с приоритетами? Есть единый беклог или до сих пор задачи в личку падают?
Подписывайтесь на наш канал: Автопилот для бизнеса