Архитектура информационных систем. Гибкий процесс развития продуктов

Одно время стали довольно популярными обсуждения на тему: а как-бы нам использовать agile за границами ИТ. Несколько таких дискуссий вы, безусловно, найдете в группе FB GosAgile или в блоге Atlassian

Честно говоря, я не помню, чтоб в них было сказано что-то уж очень полезное. Возможно, я просто читал их недостаточно внимательно, а быть может авторы ограничивались слишком простой калькой с процессов разработки ПО. Ниже я опишу некую гипотезу о том, как мог бы выглядеть процесс new product development, адаптированный к современным реалиям посредством agile Lean и Kanban. В какой-то мере это будет продолжением статьи Чему ИТ может научить бизнес.

В принципе, попыток совместить гибкие методологии разработки программ с другими полезными подходами сделано довольно много(cм., например, картинку в начале этой заметки с версией Gartner комбинации Design Thinking, Lean Startup и Agile), но в большинстве из них смысловые вещи остаются где-то между строк.

Давайте начнем с традиционного процесса развития новых продуктов и услуг, именуемого обычно new product development. На рисунке ниже, который я люблю показывать в своих презентациях, изображен один из вариантов такого подхода от известного разработчика инструментов корпоративной архитектуры и управления портфелем проектов компании PlanView. Вполне себе такой «водопадный» или каскадный процесс, именуемый еще порой как stage-gate approach. Самая правильная идея в этой картинке это, некая воронка инноваций, по аналогии с воронкой продаж, иллюстрирующая тот факт, что до финиша дойдут далеко не все, а задача проектного офиса не столько в том, чтоб запустить побольше продуктов, а наоборот – отсеять лишние, сконцентрировав скудные ресурсы организации на реализации самых перспективных идей.

В лучшем случае что-то подобное существует в вашей организации. Чаще в компаниях стихийным образом бегают разные люди, каждый со своим проектом и инициативой, в призрачной надежде инициировать выделение средств для реализации своих хотелок на ближайшем бюджетном комитете. Причем все стремятся попасть именно на ближайший, как будто он резиновый и топ-менеджерам просто больше нечем заняться как сидеть по пять-шесть часов и выслушивать нескончаемый поток просьб дать тому или иному отделу еще немножко денег. Типичный push подход, когда организация не понимает, что именно и зачем она собирается сделать и потому пытается сделать сразу всё и ещё вчера. Немного перерисуем эту картинку в виде Kanban-доски.

Подробнее: https://mxsmirnov.com/2017/06/24/lean-product-development/https://vk.cc/868TtQ