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

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

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

Это реинжиниринг бизнес-процессов, который вообще-то лежит вне контекста автоматизации. Совершенно отдельная работа. Выполняется специально обученными консультантами, а не программистами. Это, если угодно, совершенно отдельный НИР.

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

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

А идеи заглянуть в учебник по управлению товарными остатками — не возникало? У вас, конечно, у заказчика понятно что нет.

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

Алгоритм и бизнес-правила согласуются дешевле и быстрее. Для этого полнофункциональный билд излишен.

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

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

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

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

А то я не сталкивался с этой проблемой — автоматизация во время реорганизации . Надо взять паузу, чтобы заказчик устаканил свои процессы. Разработку тормознуть, выделить заказчику аналитика. Какой смысл вести разработку постоянно переделывая?

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

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

Excel формы вам не нужны на этом этапе. Это отчеты. Вам нужна первичка, на основании которой строятся отчеты, а ее по два раза в месяц не переделывают.

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

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

2 часа на роль — обычно хватало с избытком. Надо знать, что надо спрашивать, и главное — что спрашивать не надо. Вы с менеджерами поменьше говорите, и будет гораздо меньше 8 часов.

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

Значит, в том проекте нормы нарушались. Наличие ГОСТ-оских документов не означает, что разработка ведется организовано.

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

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

Вам не нужен постоянный контакт со всеми ролями. Кроме того, аналитик должен уметь внимателно читать документы. Когда я сказал "неделя" — я четко сказал далее, где вы мой текст вырезали, что надо каждую неделю в течении фазы inception контроллировать прогресс и выполнять целеполагание на следующую неделю. Я ничего не сказал на тему того, для чего "достаточно" недели, а для чего нет.

ДФ>Обычно, впрочем, не везет и на часть вопросов по алгоритмам или нужным процессам следует ответ "сделайте, там посмотрим, подходит или нет".

А вы вопросы задаете по нужным процессам? Ну вы даете. Разумеется, вам так и ответят. Вы должны сами уметь процессы идентифицировать и описывать, в этом работа аналитика и состоит.

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

в мало-мальски крупной компании более 5 ролей исполнителей, ни один из которых не знает полной картины. О менеджменте я вообще молчу — они нихрена не шарят в реальном положении вещей по фактическим бизнес-процессам. Вам просто некому показать, чтобы было "посмотрим", никто там не пендрит в этом, чтобы адекватно оценить вашу систему. Вы должны наверняка сработать, для этого и нужно фактические процессы с организации снять. Читайте книгу SADT, короче.

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

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

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

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

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

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

Мой тезис — заказчик никогда не знает, что он хочет. У него есть общие критерии, и все. Это ваша работа, выяснить, что ему на самом деле нужно. Будете ориентироваться на то, что он хочет — это как с беременной женой. "Свари суп из говна!" Помните анекдот?

ДФ>то, что называют agile технологиями — методики, позволяющие довести размер стадии до двух недель-месяца. Они нужны в тех случаях, когда заказчик почти совсем не представляет, что же он хочет получить.

Когда вы лишены возможности выяснить, что заказчику нужно. Только тогда итерации — как последний шанс и только на первой фазе. Разделять надо "хочет" и "нужно". Над первым у вас контроля нет, над вторым — почти всегда есть.