Организация процессов производства информационных систем. Часть 2. Формирование проектного решения

На мой взгляд пропагандисты Scrum явно лукавят.<...>
Вопрос лишь в том, кто будет оплачивать все эти перерождения почти готового продукта? Тут возможно два базовых варианта:
* У заказчика есть неограниченный финансовый кредит.<...>
* Заказчик, заключив договор на определенную сумму<...>

Хм. Странно, а в моей практике наиболее массовый вариант — есть контракт с фиксированным бюджетом, но на входе не детализированное ТЗ. И управление объемом детализации, реализации и качеством — позволяет производить множество изменений на каждом из этапов.
Ведь зачастую, во многих крупных проектах внедрения информационных систем, заказчики не являются экспертами в том, что им нужно и уж тем более состава действий в проекте, т.к. не понимают что делает команда — они эксперты в своей области. И в конечном итоге то они ожидают результат от проработки их задачи, а не ритуального исполнения последовательности действий в диаграмме гантта.
Суть agile заключается в том, что возможность распланировать сложный проект до уровня часов и конкретных задач — это даже не инженерная или управленческая задача, а искусство — т.е. достаточно субъективная вещь. И даже атомарная инженерная задача в рамках проекта не имеет однозначных оценок трудозатрат — так как в том числе упирается в конкретного исполнителя с его системой мотивации, квалификации и готовности окружения с которым он будет работать.
Поэтому вместо того, чтобы самообманываться, что процесс в областях с высокой неопределенностью будет контролируемым на всю глубину — предлагается иметь цель и корректировать средства, методы, а часто и результаты в ходе проекта. А вопрос оценки стоимости оставить все же искусству продавцов.

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

Какое отношение имеет agile к профессиональным навыкам бизнес-аналитика, позволяющих качественно вытянуть из заказчика его потребности, и исходя из своего собственного опыта и опыта, подчеркнутого из чужих успешных проектов, спроектировать наилучший для заказчика продукт?

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

Суть agile заключается в том, что возможность распланировать сложный проект до уровня часов и конкретных задач

это суть любого планирования. Подробно об этом искусстве будет разложено в следующей части статьи.

есть контракт с фиксированным бюджетом, но на входе не детализированное ТЗ.

Почитайте пример такого подхода по ссылке приведенной в статье. Заказчику ничего не мешает заключить с Вами договор на 3 коп. а после потребовать, реализации продукта на миллион. Причем все в рамках действующего законодательства.

Какое отношение имеет agile к профессиональным навыкам бизнес-аналитика, позволяющих качественно вытянуть из заказчика его потребности, и исходя из своего собственного опыта и опыта, подчеркнутого из чужих успешных проектов, спроектировать наилучший для заказчика продукт?

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

Часто это уже не так. По крайней мере есть ряд продуктов — на котором первичное макетирование метаданных почти ничего не стоит и при этом это уже будет работоспособный прототип, который выпускается частями и отрабатывается конкретные потребности и ожидания пользователей — пробующих. А объяснить заказчику на пальцах как будет выглядеть система, особенно когда участников множество — предъявляет к заказчику требования сопоставимые к уровню бизнес-аналитика, что просто невыполнимо.

Почитайте пример такого подхода по ссылке приведенной в статье. Заказчику ничего не мешает заключить с Вами договор на 3 коп. а после потребовать, реализации продукта на миллион. Причем все в рамках действующего законодательства.

Зачем мне читать — если я с этим просто работаю постоянно в практике )). Если дошло до законодательства, а это суд — значит проект изначально был непроработан и вовсе не в детализации проектных задач, а в модели управления им и рисками и отношениями с заказчиком.
Проекты с детальной, документированной проектной проработкой предполагают, что оба участника и заказчик и исполнитель находятся в конкурентной позиции. А есть большой класс задач и проектов, где это вовсе не так. В них заказчик также зависим от успешности проекта как и исполнитель. Банально в кастомных системах получить потом поддержку, если система выполнена по плану и формальным признакам с убытком исполнителя — будет крайне затруднительно. А без этого система жить и развиваться не будет дальше — деньги на неё будут просто выброшены. Таких примеров внедрений множество. Более того — задача внедрения ИС часто ведь жизненно необходима для заказчика — нормативно ли как для госки или обусловленная бизнес-убытками, потерей конкурентности. Поэтому если стороны заинтересованы получить результат — проще договориться, чем закрыться документированием.
Но безусловно это не договора на 3 копейки и в такие договора и проекты не входят без управления отношениями с заказчиком, что также является часть проектного управления.

По крайней мере есть ряд продуктов — на котором первичное макетирование метаданных почти ничего не стоит и при этом это уже будет работоспособный прототип, который выпускается частями и отрабатывается конкретные потребности и ожидания пользователей

Я специально посвятил целый раздел, для определения точки зрения, на понятие БОЛЬШОЙ системы. На этапе предпроектного исследования могут еще не быть известны ни команды, ни инструменты и платформы которые будут использоваться. Их возможно только предстоит выбрать по итогам первого этапа. Команд в проекте может быть много и они могут использовать самые разнообразные технологии, которые еще надо будет соединить в единую систему.

Если дошло до законодательства, а это суд — значит проект изначально был непроработан

Если нет требований к разрабатываемому продукту, то проект уже изначально не проработан!

Бывает все прозаичнее. Команда получает при старте лишь аванс. Основной расчет может производиться при сдаче проекта. При этом если задействованы подрядчики и субподрядчики и проект идет больше полугода, то работа идет в кредит. То есть небольшая команда условно говоря каждый месяц кредитует 1 млн. руб. за полгода 6 млн. руб. Причем субподрядчику их должен не заказчик, а подрядчик. Заказчик не принимает продут у подрядчика, подрядчик соответственно у субподрядчика. Так дедка за репку, бабка за дедку. Я к тому, что в жизни больших проектов все сложнее, чем просто сходить вальяжно в суд. людям надо платить зарплату, кредиторам проценты, а доказать, что Вы делали все согласно контракту невозможно — нет детальных условий контракта.