Один хороший человек, ставший другом, а когда-то был клиентом, сегодня меня спросил, почему я вообще не пишу ничего о своих проектах, чем занимаюсь. Я всегда старался писать обобщенно, отстраненно, мне всегда казалось, что если писать как-то о том, что вот это было в проекте, это будет восприниматься с отторжением. Плюс NDA, конечно. И в итоге он меня убедил, обезличенно и там где нет нарушения NDA 🙂 Мне кажется, такие истории будут интересны, чтобы посмотреть как оно вообще бывает. Если зайдет, я продолжу периодически публиковать кейсы, начал с этого, потому что в нем цифры (а все цифры реальные) просто мозгодробительные, но правда в том, что изнутри этого часто не видно и не удивлюсь, что среди вас есть люди с подобными цифрами, даже если еще не знаете об этом 🙂 Кейс 1 (достаточно давний) Компания (крупная и успешная с точки зрения бизнеса) обратилась за аудитом IT-процессов. Стратегическая задача компании – переход к продуктовому подходу в разработке, однако руководство (новое на тот момент) понимало, что без диагностики текущего состояния масштабирование приведет к росту операционных издержек. Что было исследовано Аудит охватил процессы анализа, проектирования, разработки и тестирования для двух ключевых IT-направлений: ERP и веб. Методы проведения ▪️Серия интервью с участниками команд ▪️Оценка уровня зрелости по модели DASA ▪️Анализ метрик потока задач ▪️Оценка орг структуры и архитектурных процессов Обнаруженные проблемы ▪️Управление потоком задач Количество незавершенных задач за год выросло с ~500 до ~1000, а среднее время выполнения увеличилось с 30–45 до 90 дней Скорость поступления задач не изменилась (~10 задач в день) По одному из направлений объем задач «в работе» составлял примерно 12–13 месяцев работы; этап тестирования накопил очередь на 8–10 месяцев вперед Все новые задачи немедленно принимались в работу без триажа и приоритизации ▪️Продуктовая разработка Частое и непредсказуемое поступление задач Владельцы продукта удалены от команд; решения принимаются на основе документов Только 35–40% задач попадают в бизнес-ожидания Бизнес-цели команд не определены; команды не верят в достижимость планов ▪️Организационная структура Значительные координационные затраты между функциональными подразделениями ▪️Тестирование Тестировщики не знают, чего ожидать, новые функционал появляется непредсказуемо Автоматизация тестирования отсутствует, последний регресс занял 2 недели силами 5 чел Пропускная способность тестирования ~7 задач в месяц при объеме разработки ~62 задачи в месяц ▪️Архитектура Отсутствует актуальная база знаний NFR не определены Инциденты с инфраструктурой (пример - логи хранились в БД, которая переполнилась, логирование остановилось незаметно для команды) Предложенные и проведенные работы ▪️Управление процессом и потоком задач Формирование Канбан-системы Объединение всех систем управления задачами для получения сводной картины Введение регулярных каденций ▪️Управление продуктом Формулировка видения продукта, описание клиентских сегментов, определение ключевой продуктовой метрики Запуск Discovery-процесса для быстрой проверки продуктовых гипотез Внедрение скоринговой модели ▪️Архитектурный процесс Фиксация архитектурных ограничений, принципов, атрибутов качества Настройка мониторинга Периодические технические review архитектуры Результаты ▪️Попадание в бизнес-ожидания от 35-40% поднялось до 70% ▪️Сокращение Lead Time в направлении ERP в 2.3 раза за 6 месяцев ▪️Сокращение Lead Time в направлении веб-разрабоки в 3.7 раза за 6 месяцев ▪️Определены (некоторые) NFR и встроены в CI/CD-пайплайн Вывод Вывод, который я часто постулирую – синергию изменений и устойчивость результатов зачастую дает именно комбинированный подход, в данном случае процесс + продукт + инженерия, они взаимосвязаны и если не рассматривать их цельно, то благие намерения по оптимизации одного слоя могут замедлить всю систему и сделать ее еще менее управляемой.