Всем привет! Меня зовут Тимур, я работаю попугаем проджектом в одной большой пчелиной компании. Это моя первая статья на Хабре, и в ней я делюсь опытом вымучивания процессов. Надеюсь, вам будет интересно. Поехали!

В этом году по мимо выпуска фичей, подготовки к релизами и вылизывания проектной документации я решил упороться в процессы. Цель была простая - снять напряжение и ускорить поставку. Скажу сразу работа шла нудно, долго, с согласованиями на недели, короче классическая история с кучей стейкхолдеров и участников, где каждый хочет сделать свое участие максимально легким, а проблемы переложить на чужие плечи. Вот наша история, как мы убрали несколько хронических ограничений.

Первое. Скоринг по RICH

Каждая задача проходила оценку: охват, влияние, уверенность, трудозатраты. Мы собирались рабочей группой заказчиков, обсуждали, спорили, синхронизировали понимание по эффектам и сложности. В результате появился прозрачный список задач для разработки. Это дало простой, но мощный эффект: ИТ наконец начало давать стабильные оценки сроков, которых раньше просто не существовало. Появились реальные даты запусков, правда сначала мы в них не попадали, но постепенно начали приходить в плановые даты.

RICH фреймворк, который используют для скоринга задач или проектов. Reach (охват), Impact (влияние) Confidence (уверенность), Effort / Hours (затраты/часы). Формула такая: R × I × C / H = Score

Второе. WIP ограничения

В один период времени ИТ брало столько проектов, сколько реально могло переварить. Никаких протолкнуть через знакомых. Если эффект низкий ,то жди своей очереди. Это быстро очистило хаос и снизило давление на команды. Однако бизнес продолжает давить с тем, чтобы напихивать больше задач и ,что самое смешное они же не успевают предоставить мало-мальски адекватное описание требований, а об этом дальше.

Третье. Бизнес требования

Мы перестали брать в работу задачи с описанием в 1 предложение на листике туалетной бумаги, стиле. Разработали единый формат требований для заказчиков и согласовали его под подпись, хоть и электронную :-) Требования стали полными: контекст, детали, влияние на другие системы. Теперь скрытые доработки в других системах стали явными еще на стадии оценки задачи. Еще одной цель было снижение простоев аналитиков, включая время на выявление требований, но с этим пока не очень, расскажу дальше почему.

Четвёртое. Формализованный процесс тестирования

Мы не ускорили релизы, но убраливопрос: «А что нам показывать на демо?», в тех случаях, когда сервис разрабатывало больше одной командой. Да, не смотря на то, что ИТ проводило интеграционные тесты, они все еще не могли прийти и показать сервис целиком. Здесь как и в 3 пункте формализованные требования согласовали со всеми участниками. Теперь у ИТ и бизнеса прозрачный и понятный процесс, критерии и артефакты. Демо стало нормальным событием, команды приходили подготовленными и почти все сервисы проходили демо без замечаний.

Что получили в итоге?

Процесс стал больше похож на линейное производство, а не на хаотичные и нервные попытки хоть что-то вытащить в релиз. Появились реальные коммиты по срокам, появилась прозрачность в работе ИТ, стало понятно, кто что делает и зачем. Замеры time-to-market тоже это подтвердили: поток ускорился примерно на 30%.

Напряжение, конечно, осталось. И связано оно в основном с тем, что раньше ИТ давали слишком оптимистичные сроки. Сейчас мы это поправили, прогнозы стали честнее, и есть ощущение, что команды наконец выдохнут.

Но остался один минус. Нагрузка на PO/PM выросла. Чтобы система работала, продакт должен глубоко разбираться в каждой задаче, описывать, уточнять, проверять. Это повышает качество, но снижает пропускную способность. Если бизнес продолжит давить объёмом, PO будут выгорать, это только вопрос времени.