Привет участникам форума!

Есть проект на котором очень большие проблемы с документацией - документ требований отсутвует, но есть функциональный дизайн в котором есть и элементы требований и элементы самого ФД т.е. элементы реализации. Документ ранее писался Заказчиком и в недавно передан нам на поддержку. + этот документ не совсем актуален т.е. функционал дорабатывался в обход документа. В данный момент Заказчик не совсем понимает необходимость срочной актуализации документа, он не хочет на это выделять достаточные ресурсы. Предложения разделить данный документ на ФД и ДТ не нашли понимания со стороны Заказчика. После общения с Заказчиком стало ясно что он имел отрицательный опыт от ведения подробной документации.  т.е. у него сформировался достаточно четкий стереотип - ненужного и тупого аналитика.
Мне необходимо убедить этого Заказчика в необходимости ведения нормальной документации, хотя процессы самого проекта тоже придется поменять, но это немного в сторону, с этим тоже все плохо...
Свои мысли хочу сформулировать в виде рисков, котороые он получает в связи с не правильным ведением документов.

Вот что сформулировал в данный момент:
1. Появление нового член команды. Новый член команды очень долго входит в проект. Для получения информация требуется постоянное консультирование с командой, что очень не эффективно – т.к. команда тратит свое время на объяснение, у нового члена команды возникаю простои в результате ожидания объяснений. Вхождение в проект требует очень большого времени. Временной подключение людей с других проектов невозможно.
2.Существенное расширение проекта - подключение на проект сразу нескольких новых человек. Для консультаций всех новых людей у команды просто физически не хватит времени. Быстрое расширение команды невозможно.
3.Временное отлучение от проекта одного из члена команды (в случае болезни, отпуска, перехода на другой проект, и т.д. ) ведет к потере информации и существенного времени на ее восстановление.
4. Невозможно качественно выполнить тестирование (как они тестируют я пока не понял). Поставки системы сырые и не достаточно протестированы.

Возможно у когото есть опыт решения такой такой проблемы?

1. ИМХО аргументация которую Вы предложили может быть убедительна для Вашего начальника, но вряд ли она будет убедительна для Заказчика (если этот внешний Заказчик- другая организация).
2. Документация является важным инструментом при работах по сопровождению системы. В тексте договора на сопровождение системы по идее должны быть предусмотрены Ваши обязательства по поддержанию работосопособности системы только в рамках описанного в технорабочей документации функционала и в соответствии с требованиями ТЗ. Иначе Вы рискуете "подписаться" на непредсказуемо большой объем работ.

Shur, поздравляю с сотней!

Полностью согласен с Shur. Аргументы крайне не убедительны для Заказчика. Заказчик скажет, что это Ваши трудности и проблемы, как Вы там орагнизуете процесс. Мне нужна система!

Однако нужно найти аргументацию, которая ясно покажет Заказчику, что может случиться вслучае игнорирования и нежелания финансировать эту работы. Причем это нужно сделать так, чтобы показать, что пострадает в первую очередь сам Заказчик и лучше, если вам удасться показать, что Вы собственно отделаетесь только головной болью, а финансово это Вас не затронет. Т.е. все издержки за упрямство будут виной самого Заказчика. Вопрос как это сделать? Вероятно, это должно жестко регламентироваться документами

1. ИМХО аргументация которую Вы предложили может быть убедительна для Вашего начальника, но вряд ли она будет убедительна для Заказчика (если этот внешний Заказчик- другая организация).

Начальнику нужно аргументировать и обосновывать Заказчику все предстоящие работы. В нашем случае Заказчик заплатил только за создание документа, но отказался платить за его поддержку. так вот нужно убедить в том что он ошибся.

2. Документация является важным инструментом при работах по сопровождению системы. В тексте договора на сопровождение системы по идее должны быть предусмотрены Ваши обязательства по поддержанию работосопособности системы только в рамках описанного в технорабочей документации функционала и в соответствии с требованиями ТЗ. Иначе Вы рискуете "подписаться" на непредсказуемо большой объем работ.

Про договор не в курсе, видимо там такого нет.

Shur, поздравляю с сотней!

Полностью согласен с Shur. Аргументы крайне не убедительны для Заказчика. Заказчик скажет, что это Ваши трудности и проблемы, как Вы там орагнизуете процесс. Мне нужна система!

Они так щас и работают. Просто пока ни один из фатальных рисков не произошел. Но это пока...

Однако нужно найти аргументацию, которая ясно покажет Заказчику, что может случиться вслучае игнорирования и нежелания финансировать эту работы. Причем это нужно сделать так, чтобы показать, что пострадает в первую очередь сам Заказчик и лучше, если вам удасться показать, что Вы собственно отделаетесь только головной болью, а финансово это Вас не затронет. Т.е. все издержки за упрямство будут виной самого Заказчика. Вопрос как это сделать? Вероятно, это должно жестко регламентироваться документами

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

Я как раз и хочу сформулировать их чтобы дать понять Заказчику необходимость выделять деньги на документацию.

ArtemyY,
давайте порассуждаем.

есть сторона Заказчика и сторона Подрядчика - ваша сторона.
Между ними есть некий договор, устный или письменный. Если устный плохо.
Если договор лучше, но тоже может быть плохо.

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

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

Если же ситуация совершенно иная, тогда надо искать законные (юридические) способы давления.

Поскольку Вы говорите что документ писался самими Заказчиком и более того потерял актуальность, тогда Вы имели право принять этот документ только после его ревизии. Но если приняли - тут что можно поделать?

Начальнику нужно аргументировать и обосновывать Заказчику все предстоящие работы. В нашем случае Заказчик заплатил только за создание документа, но отказался платить за его поддержку. так вот нужно убедить в том что он ошибся.

Какого рода документы входят в документацию? Это и руководство пользователя(ей) и описание системы на разных уровнях (включая уровень разработчиков)?
1. Поддержка пользовательской (рабочей) документации может быть полезна для Заказчика, если у него будут появляться новые пользователи и будет актуальна организация их обучения. Весьма вероятно, что Заказчик неявным образом попытается переложить связанные с обучением проблемы на Вас (особенно если требования к квалификации персонала не оговаривались в договоре на создание системы или в документации).
2. Если обсуждается необходимость поддержки документации уровня разработчиков системы, то если у Заказчика нет своих ИТ-специалистов, которые  что-то своё с Вашей системой делают, то вряд ли он согласится поддерживать такую документацию.
3. Не очень понятна роль аналитика (постановщика задач?) в процессах сопровождения. Если предполагается, что  под сопровождением системы понимается её "ползучая модернизация" в ходе которой будут производиться доработки системы по постановкам, которые будет делать аналитик, то работать в таком режиме по договору "равномерного и непрерывного" сопровождения можно только при очень дружественных отношениях с Заказчиком. По хорошему каждую такую работу надо уже оформлять отдельными договорами или дополнениями к основному договору (по каждой работе надо иметь возможность согласовывать цены и объемы). А если такие задачи действительно небольшие и разработчики неплохо ориентируются в предметной области , то можно обойтись без выделенного аналитика. При интенсивных контактах с Заказчиком по поводу "непрерывного потока" небольших задач более актуален менеджер проекта (в основном на этапе заключения договора  и согласования условий работ) и архитектор, которые будет следить, чтобы на уровне программной реализации не разъехался изначальный замысел системы.
4. Если всё-таки новые постановки предполагаются, то если Вы полагаете, что документацию надо дорабатывать (для себя), то как раз затраты на документирование постановок задач по доработке в рамках сопровождения можно отнести на процессы проектирования. И просить отдельные деньги именно на проектирование решения по постановке, а не на документирование решений. Т.е. акцент сделать на понятие "проектирование", а не "документирование". И развеять иллюзии у Заказчика, насчет того, что системы "просто" программируют (без проектирования), если такие иллюзии у него существуют .

Если Заказчики на вас "подсели", то интересную мысль преложил Shur.
Скажите что при разногласиях между вами и З по поддержке, Вы будете базироваться на текущем ФД, и если он будет не актуальным, то З может просто петерять часть работющего ф-ла.
Так же если это надо вам и З, то разделить затраты поровну.

Документ о функциональном дизайне -- действительно гемор для Заказчика, это по AIM кажись нужно в большей степени разработчику, чем заказчику. Ну какой мне, как заказчику, прок от документа в котором будут изложены объекты предметной области и изменения их состояний, если я не собираюсь лезть в ДИЗАЙН системы? А вот документ ТРЕБОВАНИЙ к системе и его актуализация (т.е. ЧТО должна делать система) -- Заказчику и разработчику нужен, т.к. по нему будет осуществляться как разработка и тестирование, так и приемка софта.

Спасибо за ответы, но мне кажется я немного не точно описал ситуацию на проекте. Проект декйствительно строится в большей степени на хороших отношениях с Заказчиком. ИТ служба состороны заказчика являектся частью нашей команды или мы их. По сути ПМ на стороне Заказчика и убеждать надо его о необходимости вести документацию "правильно". С нашей стороны тоже есть ПМ но это более формальная роль и влияние на проект имеет очень небольшое.

Скорее всего в договоре не прописаны данные ньюансы - требуемая документация, уровень участников. Я не знаю, не доработка ли это наших юристов и саелзов или просто результат долгого и доверительного сотрудничества. В конце концов это не моя компетенция.
Я как аналитик, могу лишь предостеречь Заказчика - что его ждет в отсутвии данных документов. Я попытался описать это в виде рисков, хотя пока это скорее мысли и идеи, риски планирую попытаюсь сформулировать более четко. Но я предполагаю что я не все возможные риски описал.

Если я не ошибаюсь, риски обычно описываются в документе "План управления проектом", который составляется Менеджером проекта и согласовывается с Заказчиком.

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

Если же всего этого нет - то, ИМХО, нужно искать пути решения данной проблемы используя дипломатические навыки .

[skip]

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

[skip]

Согласен вопрос коммуникаций очень важен. Очень важно преподнести информация правильно, в нужный момент и нужным людям. Но всетаки в данный момент меня прежде всего интересует вопрос Рисков проекта.   

ArtemyY, внесите в риски проекта - риск непонимания заказчиком важности ведения документации и поробуйте расписать кто и за что тут отвечает, посчитайте влияние на проект и систему в целом, оцените вклад.

Галоген! Нехорошо чужие важные цитаты удалять, база данных боитесь переполнится?!

Личные вопросы в личку Задумываюсь о будущем