Привет, коллега.
Если ты senior PM, руководитель группы или СТО, и у тебя в ИТ-департаменте творится «треш-угар и посыпание голов пеплом» — добро пожаловать.
Прошлая неделя была по лайту, теперь время хардкора. Я начинаю серию статей про базовый минимум процессов, без которого любая ИТ-команда от 50 человек превращается в филиал психдиспансера.
Никакой воды. Только мой опыт (17+ лет в РП, консультирование, внедрение софта и менторинг).
Сегодня — Часть 1. Формализация входящего потока задач (Вход в IT).
Почему без этого вы сдохнете?
В маленькой компании (до 30 человек) всё просто: подошел к директору, тот сказал «сделай», ты сделал. Все честные, все свои.
Но когда ИТ-команда разрастается до 50–500 человек, коммуникации рвутся. Бизнес начинает орать, что ИТ — тормозы. ИТ орет, что бизнес — дураки и не знают, чего хотят.
И корень зла часто в одном: дырявый вход.
Представьте шлюз канала. Если шлюз сломан, воду (задачи) хлещет отовсюду. Канал переполняется, берега (ресурсы) размывает, всех топит.
Так вот, у 90% моих клиентов шлюз просто отсутствует как класс.
Как выглядит типичный АД?
- Задача прилетает откуда угодно: в личку в Telegram, на почту, устно в курилке, от жены финдиректора.
- Описание задачи — «Сделай красиво». Ни критериев, ни бизнес-целей, ни ожидаемого результата.
- Приоритет у всех — «Вчера». Если у всех приоритет «Критический», значит, нет приоритетов вообще.
- Объем растет как на дрожжах. Вчера просили «кнопку», сегодня хотят «бэкенд и отчетность» в той же задаче.
Знакомо? Если да, читаем дальше.
Что делаем? Ставим заслон
Нам нужен единый входной шлюз. Одно окно. Формализация входа решает три задачи:
- Отсев мути (не даем загружать команду тем, что не надо делать).
- Качественная постановка (чтобы разработчик понимал, что от него хотят).
- Приоритизация (чтобы ресурсы не распылялись на 100500 задач сразу).
Мой ToDo-лист для аудита «Входа»
Вот чек-лист, с которым я захожу в проект. Проверьте себя по пунктам.
1. Есть ли у вас единая точка входа (Service Desk / Портал запросов)?
- Если нет: задачи летят в личку к тимлидам. Тимлиды ничего не успевают, код не пишут, выгорают.
- Что делать: Запретить ставить задачи устно или в личку. Все -только через систему (Jira, Kaiten, Yandex Tracker — не важно). Да, это жестко. Да, бизнес будет возмущаться. Но если задачу нельзя записать, она не делается.
2. Есть ли шаблон задачи (Definition of Ready — DoR)?
- Если нет: вам приносят «сделай приложение как у Тинькова».
- Что делать: Внедрить минимальный шаблон. Задача готова к работе, когда в ней есть:
Автор и постановщик.
Бизнес-требование (зачем это нужно).
Функциональные требования (что конкретно должно работать).
Критерии приемки (как мы поймем, что сделано).
3. Есть ли у вас регулярный комитет по приоритизации (например, еженедельно)?
- Если нет: разработчики делают то, что громче крикнуло вчера вечером.
- Что делать: Создать ритуал. Раз в неделю собираются «старейшины» (заказчик, РП, архитектор) и сортируют задачи. У кого денег больше или чья задача валит прод — тот и главный. Остальные ждут.
4. Работает ли у вас «Водкаст» (или «Отказ») ?
- Грустно, но факт: 50% хотелок бизнеса не нужны.
- Что делать: Если задача не влезает в приоритеты или у команды нет ресурсов — нужно уметь говорить «Нет». Аргументированно, с цифрами: «Если мы сделаем это сейчас, мы не сделаем тот релиз по продажам. Выбирайте».
Резюме первой части
Формализация входа — это не бюрократия. Это фильтр.
Если не починить этот этап, у вас никогда не будет предсказуемых сроков. Ресурсное планирование (о котором завтра) будет невозможно, потому что в самый разгар спринта прилетит «срочная хотелка» от большого босса и сломает весь график.
Задача этого кубика — сделать так, чтобы в IT-производство попадали только правильные задачи, в правильном виде и с правильным приоритетом.
Как у вас организован вход? Задачи прилетают через тикеты или в Telegram? Пишите в комментариях, интересен реальный опыт (или боль).
Завтра будет Часть 2. Самое страшное — Ресурсное планирование. Не переключайтесь.
Подписывайтесь на наш канал: Автопилот для бизнеса