В ходе обсуждения метрики для работы аналитика возникла вот такая мысль: аналитик снижает риск переделки системы. Многие так или иначе про это говорят. И вот что интересно: риск — это вероятность*ущерб. Это чисто математическое определение. Использование практики системного анализа, очевидно, работает на снижение вероятности в этой формуле. То есть, это попытка заранее проработать нужды и потребности заказчика и пользователей, ничего не забыть, не сделать лишнего или ненужного, а сделать сразу только востребованное и полезное. Чтобы не пришлось переделывать или неожиданно расширять объем работ, когда сроки и бюджет уже согласован, а вот о содержании проекта у заказчика и исполнителя оказалось разное мнение.
Риски же тут огромны: Chaos Report дает оценку около 17-20% вероятности полного провала проекта, и 40-50% вероятности значимого выхода проекта за границы сроков или бюджета. Конечно, любому менеджеру хочется снизить такие огромные вероятности. Что интересно, эти вероятности практически не зависят от квалификации команды (если только вы не набрали совсем неподходящих людей — тогда вероятность примерно на 10% выше. Что интересно — связь с высокой квалификацией менеджмента вообще отрицательная — менеджеры с высокой квалификацией с большей вероятностью ведут проект к провалу).
Так вот практики agile или микросервисов подходят к этой задаче с другой стороны — они снижают ущерб. Работа короткими итерациями с частыми поставками (а значит — с частым получением обратной связи) разделяет большую систему на маленькие инкременты, потеря или переделка каждого из которых не несет большого ущерба. Даже если вероятность накосячить очень высока. Кроме того, в процессе этого путешествия команда постепенно узнает предметную область и задачу всё лучше и лучше, а значит — может предложить лучшее решение (см. Paul Ralph, Is Requirements Engineering Inherently Counterproductive?), то есть и вероятность тоже со временем снижается.
Микросервисный подход разделяет ущерб не по времени, а пространственно, структурно — если сломается один микросервис, то большого ущерба это не должно нанести — на то и разделение ответственности и выделение изолированных контекстов.При этом, в общем случае, кажется, эффективность снижения риска оказывается кратно выше, чем в случае применения системного анализа: работу обычно разбивают на очень много коротких итераций, даже в небольшом проекте их обычно больше 20. Микросервисы тоже тяготеют к большому количеству, даже в небольшом проекте из может быть десяток, в крупных системах — сотни.
Навскидку, применение системного анализа вряд ли способно снизить риски в десятки раз. Значит, гораздо выгоднее снижать ущерб — там, при хорошем раскладе, можно добиться кратного снижения рисков. Нельзя сказать, что работа системных аналитиков совсем бесполезна — так как это независимые переменные, вы можете снижать и ущерб, и вероятность, будет только лучше. Главное, чтобы аналитики не тормозили вас в получении обратной связи от пользователей или рынка.
Риски же тут огромны: Chaos Report дает оценку около 17-20% вероятности полного провала проекта, и 40-50% вероятности значимого выхода проекта за границы сроков или бюджета. Конечно, любому менеджеру хочется снизить такие огромные вероятности. Что интересно, эти вероятности практически не зависят от квалификации команды (если только вы не набрали совсем неподходящих людей — тогда вероятность примерно на 10% выше. Что интересно — связь с высокой квалификацией менеджмента вообще отрицательная — менеджеры с высокой квалификацией с большей вероятностью ведут проект к провалу).
Так вот практики agile или микросервисов подходят к этой задаче с другой стороны — они снижают ущерб. Работа короткими итерациями с частыми поставками (а значит — с частым получением обратной связи) разделяет большую систему на маленькие инкременты, потеря или переделка каждого из которых не несет большого ущерба. Даже если вероятность накосячить очень высока. Кроме того, в процессе этого путешествия команда постепенно узнает предметную область и задачу всё лучше и лучше, а значит — может предложить лучшее решение (см. Paul Ralph, Is Requirements Engineering Inherently Counterproductive?), то есть и вероятность тоже со временем снижается.
Микросервисный подход разделяет ущерб не по времени, а пространственно, структурно — если сломается один микросервис, то большого ущерба это не должно нанести — на то и разделение ответственности и выделение изолированных контекстов.При этом, в общем случае, кажется, эффективность снижения риска оказывается кратно выше, чем в случае применения системного анализа: работу обычно разбивают на очень много коротких итераций, даже в небольшом проекте их обычно больше 20. Микросервисы тоже тяготеют к большому количеству, даже в небольшом проекте из может быть десяток, в крупных системах — сотни.
Навскидку, применение системного анализа вряд ли способно снизить риски в десятки раз. Значит, гораздо выгоднее снижать ущерб — там, при хорошем раскладе, можно добиться кратного снижения рисков. Нельзя сказать, что работа системных аналитиков совсем бесполезна — так как это независимые переменные, вы можете снижать и ущерб, и вероятность, будет только лучше. Главное, чтобы аналитики не тормозили вас в получении обратной связи от пользователей или рынка.