Здравствуйте, Gaperton, Вы писали:

G>Заказчик, разумеется, такой НИР (который, в общем, на самом деле не НИР — это простое обследование) не оплатит. По крайней мере, сразу. Однако это не повод не заслать к нему аналитиков — вы потом затраты на обследование можете включить в общий счет работ первого этапа.

Э, про обследование существующих бизнес-процессов я тут не говорю, это само собой разумеется (хотя и не всегда удавалось их провести — но я тогда был маленький и неопытный, не умел заставить показать пользователей системы).
У меня значительная часть проектов была связана с тем, что существующие процессы не устраивают заказчика, и вместе с автоматизацией меняются и алгоритмы работы. Т.е. нужно автоматизировать не то, что есть, а то, что должно быть.
И собственно НИР — это построение картинки того, что должно быть. Включая, возможно, всякие навороты.
Ну,например, у заказчика высокие остатки на складах, долгая доставка, много затрат человекочасов на планирование логистики и низкое качество планирования.
Требуется (т.е. уже продано) решение, которое за счет некого алгоритма планирования решит указанные проблемы (т.е. автоматическое построение планов отгрузки, например, на основании информации из астрала). Алгоритмов готовых у заказчика нет, есть общие идеи, применимость которых нужно проверять.
Но проект — fixed-price.
Вот в этом случае, на мой взгляд, постоянное общение с заказчиком (с реальными будущими пользователями), регулярные билды, которые смотрят те же пользователи с реальными данными — необходимы.


ДФ>>Вот в этом случае мне представляется разумным начинать с итеративной разработке прототипов (как в НИР и предполагается), держа в голове перерастание этих прототипов в промышленную систему. И в качестве "процесса" для такой разработке подходят некоторые идеи agile (малые команды, тесная коммуникация с заказчиком, ранняя интеграция, постоянное тестирование, приоритезирование и т.п.).

G>Объясните мне, с каким "заказчиком" вы собираетесь коммуницировать с случае корпоративной ИС где 15 ролей пользователей, и менеджмент не знает деталей и нюансов работы исполнителей? А директор вообще не имеет представления о деталях фактических бизнес-процессов (ему по должности не положено в такие детали вникать)?

Есть два варианта. Или с "ответственным за проект" с той стороны — а уж он достанет нужных людей с нужных уровней.
Или со всеми 15ью ролями пользователей. В первый вариант я верю значительно меньше.


G>Суть обследования, которое надо провести перед началом разработки (если конечно переделывать ничего не хочется, что видимо и есть источник нескончаемого фана при agile разработке), и состоит в этом "общении" с заказчиком, выявлении фактических ролей, выявление фактического документооборота и бизнес-операций. О которых никто кроме непосредственных исполнителей точной и достоверной информацией не обладает. Не надо с менеджментом общаться для анализа бизнес-процессов — категорически нет. А то будете по двадцать пять раз "спринты" крутить. С исполнителями надо говорить.

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

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

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

ДФ>>Но, конечно, с проектированием (предварительным) и управлением требованиями (по мере их появления и если вообще это удается делать — я провалил (или вытянул очень большими усилиями) не один проект, прежде чем не осознал важность управления требованиями.

G>Если вы не проводили обследования — то как именно вы требованиями управляли? Собирали то их как?
Проводил, конечно. И все формы были. 2х часов на роль, конечно, мало, в сумме где-то часов по 8 уходило, не считая последующих уточняющих вопросов.
Иногда — и гораздо больше.

ДФ>>P.S. А что, бывают проекты, в которых выработка ТЗ формально вынесена в отдельный проект, а оценка общего результат происходит по результатам формирования ТЗ? Т.е. в идеале такие есть — но я о них не слышал.
G>Бывают при гособоронзаказе. Цитирую мануал по составлению ТЗ на военные НИР для изделий электронной техники:
Бывают, да. Хотя когда пришлось участвовать в одном из проектов ГАС "Выборы" (он, насколько я помню, делался по военным нормам), ТЗ писался одновременно с приемкой.


ДФ>>А если договор с fixed-price на НИР+ОКР вместе? Т.е. одна общая сумма и на то, и на другое. Или есть методики, которые позволяют корректно разделить общие затраты на стадии и определить, когда нужно прекращать НИР?

G>Следуйте циклу РУП. Он гласит, что стадии у вас как минимум четыре.
G>1. Завершается, когда вы на 90% имеете общее представление (во всей команде и вместе с заказчиком) о том, что надо делать. Я так понял — это и есть цель вашей НИР?
G>На первую фазу выделите для начала некоторое разумное время, скажем, неделя.
За это время можно только предметную область обрисовать (да и то далеко не всякую). Если ставить целью НИР постановку на 90% (причем только концептуальную, без пользовательских интерфейсов, без данных, только роли, сущности, существенные алгоритмы) и при постоянном контакте со всеми заинтересованными ролями — то для нормального проекта на 10 человеколет нужно не меньше месяца. Если повезет.
Обычно, впрочем, не везет и на часть вопросов по алгоритмам или нужным процессам следует ответ "сделайте, там посмотрим, подходит или нет".
Т.е. нужно делать прототип, причем, увы, заказчики очень плохо (как выяснилось) умеют понимать такую вещь как неполнофункциональный прототип. И заставить их оценить эффективность алгоритма или решения без всех рюшечек иногда просто нельзя.
Вот эта стадия и выливается в первую, вторую и третью одновременно.

G>4. Завершается, когда вы даете рабочую версию.
А вот от предыдущей до этой может пройти несколько подходов, иногда (если не постараться) с изрядным рефакторингом.
А уже если заказчик требует конкретных интерфейсных решений (которые, опять таки, на стадии 1 всяко не получить) — то и больше.

G>Есть книга такая — SADT называется. Так вот, там кроме самой нотации SADT(IDEF0) описывается в деталях, как должен вести себя аналитик на интервью, чтобы заказчику было непросто всякий балшыт на уши аналитику вешать. Очень рекомендую, мне в свое время эта книга сильно помогла.

Спасибо, почитаю. Но тут даже не вешанье на уши, просто специалист за полгода очень сильно поменял свое профессиональное мнение о некоторых вещах.
При том, что встречи с заказчиком (нижним уровнем реальных пользователей) проходили раз в месяц сессиями по два дня (заказчик в другой стране, чаще никак), с четкой фиксацией всех результатов, согласованием правильности понимания, отслеживанием взаимовлияния появлявшихся требований и т.п.

Но если бы мы сразу делали процесс более итеративным — этих проблем было бы меньше.

Если сформулировать мою позицию:
чем точнее заказчик знает, что он хочет — тем более длинные итерации может себе позволить исполнитель. Но каждая итерация, конечно, включает в себя все 4 стадии.
то, что называют agile технологиями — методики, позволяющие довести размер стадии до двух недель-месяца. Они нужны в тех случаях, когда заказчик почти совсем не представляет, что же он хочет получить.