Здравствуйте, Дельгядо Филипп, Вы писали:

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

ДФ>>>Гм, а часто ли встречаются задачи, которые не являются исследовательскими?
G>>Их в нашем деле подавляющее большинство. Не надо путать технологию и науку. Если не знать технологию сбора кубика-рубика — то его сборка тоже бешеный креатив. Если каждый раз изобретать все заново — то жизнь ваша будет увлекательна, конечно. Но вы проиграете.

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

ДФ>Логично в этом случае, как и рекомендуют ГОСТы, сделать сначала НИР, результатом которого будет ТЗ
ДФ>(правда, не понятно, кто будет этот результат принимать — специалистов такого класса у заказчика скорее всего нет).
ДФ>Но это, в общем, идеальный случай разумных отношений с заказчиком.

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

ДФ>Но, опять-таки, часто встречаются случаи, когда один менеджер продал другому "систему автоматизации, которая решит все ваши проблемы", а даже цели автоматизации в договоре не прописаны — вот тут и начинается вполне обычное веселье — как впихнуть и исследование и собственно разработку в один проект. При этом, по традиции, сроки сжатые.

В этом случае тем более надо проводить обследование за свой счет. Чтобы понять, какой фронт работ предстоит.

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

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

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

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

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

Если вы не проводили обследования — то как именно вы требованиями управляли? Собирали то их как?

ДФ>P.S. А что, бывают проекты, в которых выработка ТЗ формально вынесена в отдельный проект, а оценка общего результат происходит по результатам формирования ТЗ? Т.е. в идеале такие есть — но я о них не слышал.

Бывают при гособоронзаказе. Цитирую мануал по составлению ТЗ на военные НИР для изделий электронной техники:

2. Цели и задачи НИР
В разделе приводят задачи, на решение которых направлена НИР, и предполагаемые пути реализации ее результатов (постановка прикладных НИР, ОКР, и т.д.)
...
3. Требования к выполнению НИР
...
В конце раздела указывают, чем должна заканчиваться работа (разработкой рекомендаций и предложений по реализации результатов НИР, проекта ТЗ на ОКР, нормативно-технических документов)

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

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

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

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

На первую фазу выделите для начала некоторое разумное время, скажем, неделя. В конце недели подведите итоги, и решите, вы вышли из фазы, или нет. Если нет — поставьте себе конкретные цели на следующую неделю, и повторяйте. Заранее ограничьте deadline, к которому вы должны уложиться с первой фазой, чтобы хоть как-то уложиться в общие сроки. Поставьте себе цель номер 1 — первым делом очертить хотя бы scope работ, чтобы как можно быстрее оценить масштаб работы.

G>>Я понимаю, что инженерам хочется думать о своей работе как о чем-то высоком, но "чисто НИРовских" задач в бизнесе практически не бывает — их мало.
ДФ>Задача исследовательская не с технической точки зрения (там как раз все обычно очевидно), а с точки зрения удовлетворения потребностей новым способом.

Понятно.

G>>Описывая всю разработку в терминах agile вы по сути обманываете менеджмент. Вы стираете границу между НИР и ОКР, убиваете на крупном уровне управление рисками, и подводите свою организацию под значительные риски.

ДФ>Угу. Я по сути вкладываю консалтинг, сбор требований, выработку ТЗ внутрь проекта. Раз уж не удалось сделать их вне проектных условий.

Это вполне нормально на мой взгляд. Сами так делали.

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

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

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