Давайте еще немного инсайтов подкину Компании пытаются принимать управленческие решения на основе данных. Для этого выстраиваются общие системы учета. Я имею в виду построение иерархии от стратегии к портфелю, от портфеля к программе, от программы к продуктам и далее к гранулярным бизнес-задачам и опциональной техническим таскам. Такую систему выстроить не просто, особенно чтобы она была согласованной, непротиворечивой, актуальной. В консалтинговой работе это обычно отдельный проект, причем достаточно сложный, однако… даже самая отлаженная система может разбиться о действия на местах. Например: ▪️Закрытие задач в трекере на уровне бизнес-задач воспринимается как формальность (или обязанность - «закрывай и точка»). По факту команды продолжают тратить ресурсы на доработку по уже закрытым задачам, это мало того, что искажает статистику, но и вызывает закономерные вопросы – вы ж все сделали, вот задачи в статусе «готово», почему новые не берем? а если берем - почему 20 задач закрыто, а функционала нет? Вообще, это вопрос контроля. К слову, ровно эту проблему решал Sprint Review в Scrum - задача не просто должна быть переведена в формальный статус, мы демонстрируем как она работает 🙂 Как мне сказал один CIO компании, где проводил пилот - «Я теперь понял в чем наша суперсила, - пока все рассказывают, что они сделали – мы показываем» ▪️Опасность средних значений, вроде .. в среднем 1.5 недели, но есть выбросы на 250-300 дней, который забивают пропускную способность. Кстати, если обратиться к Демингу, то он как раз и говорит, что улучшать нужно то, что приводит к сильным выбросам, он это называл «специальные причины», а когда «специальные причины» устранены, можно начинать работу над трендом. В общем, - среднее маскирует проблемы. ▪️Из-за отсутствия процесса проверки гипотез бэклог может забиться мусором. Тут все просто - не только сама система отслеживания важна, но важно и что через нее проходит. ▪️Отсутствие контроля за нефункциональными требованиями (NFR) порой приводит к совершенно абсурдным сбоям. Ну елки-палки, тихое выключение логирования из-за того, что база переполнилась.. а еще такие вещи «API отдает данные 20 секунд». А сколько должно? «Не знаю». Еще слышал такой ответ на вопрос «а что с безопасностью?» - «Там какая-то своя магия, отдаем и через какое-то время получаем какой-то отчет». И никто не в курсе, что проверяет безопасность, а если вы не в курсе, что там проверяют, как вы заложите требуемые архитектурные тактики? Вот эти проблемы тоже нужно решать, потому что, возвращаясь к теме поста, - задачу закрыли, процент выполнения на более высоком уровне подрос, а потом в вас возвращает эту задачу безопасность, производительность, эксплуатация.. открывать снова? Заводить новую? Как планировать в таких условиях, категорически непонятно. И снова мы возвращаемся к взаимосвязям: бизнес-модель + стратегия + процесс + продукт + архитектура + разработка + тестирование + эксплуатация + первая линия, почти любое изменение затрагивает тем или иным образом как минимум два из этих доменов, а некоторые - вообще все, в разных точках, и измнения нужно максимально сбалансировать, а потом еще и настраивать на основе результатов, потому что система сложная =) Ни разу консалтинг не прост, как многие думают при первом приближении (но я согласен и с тем, что он бывает разным у разных людей) =)