Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: ArtemyY от 29 Ноября 2007, 13:05:45
-
Привет участникам форума!
Есть проект на котором очень большие проблемы с документацией - документ требований отсутвует, но есть функциональный дизайн в котором есть и элементы требований и элементы самого ФД т.е. элементы реализации. Документ ранее писался Заказчиком и в недавно передан нам на поддержку. + этот документ не совсем актуален т.е. функционал дорабатывался в обход документа. В данный момент Заказчик не совсем понимает необходимость срочной актуализации документа, он не хочет на это выделять достаточные ресурсы. Предложения разделить данный документ на ФД и ДТ не нашли понимания со стороны Заказчика. После общения с Заказчиком стало ясно что он имел отрицательный опыт от ведения подробной документации. т.е. у него сформировался достаточно четкий стереотип - ненужного и тупого аналитика.
Мне необходимо убедить этого Заказчика в необходимости ведения нормальной документации, хотя процессы самого проекта тоже придется поменять, но это немного в сторону, с этим тоже все плохо...
Свои мысли хочу сформулировать в виде рисков, котороые он получает в связи с не правильным ведением документов.
Вот что сформулировал в данный момент:
1. Появление нового член команды. Новый член команды очень долго входит в проект. Для получения информация требуется постоянное консультирование с командой, что очень не эффективно – т.к. команда тратит свое время на объяснение, у нового члена команды возникаю простои в результате ожидания объяснений. Вхождение в проект требует очень большого времени. Временной подключение людей с других проектов невозможно.
2.Существенное расширение проекта - подключение на проект сразу нескольких новых человек. Для консультаций всех новых людей у команды просто физически не хватит времени. Быстрое расширение команды невозможно.
3.Временное отлучение от проекта одного из члена команды (в случае болезни, отпуска, перехода на другой проект, и т.д. ) ведет к потере информации и существенного времени на ее восстановление.
4. Невозможно качественно выполнить тестирование (как они тестируют я пока не понял). Поставки системы сырые и не достаточно протестированы.
Возможно у когото есть опыт решения такой такой проблемы?
-
1. ИМХО аргументация которую Вы предложили может быть убедительна для Вашего начальника, но вряд ли она будет убедительна для Заказчика (если этот внешний Заказчик- другая организация).
2. Документация является важным инструментом при работах по сопровождению системы. В тексте договора на сопровождение системы по идее должны быть предусмотрены Ваши обязательства по поддержанию работосопособности системы только в рамках описанного в технорабочей документации функционала и в соответствии с требованиями ТЗ. Иначе Вы рискуете "подписаться" на непредсказуемо большой объем работ.
-
Shur, поздравляю с сотней!
Полностью согласен с Shur. Аргументы крайне не убедительны для Заказчика. Заказчик скажет, что это Ваши трудности и проблемы, как Вы там орагнизуете процесс. Мне нужна система!
Однако нужно найти аргументацию, которая ясно покажет Заказчику, что может случиться вслучае игнорирования и нежелания финансировать эту работы. Причем это нужно сделать так, чтобы показать, что пострадает в первую очередь сам Заказчик и лучше, если вам удасться показать, что Вы собственно отделаетесь только головной болью, а финансово это Вас не затронет. Т.е. все издержки за упрямство будут виной самого Заказчика. Вопрос как это сделать? Вероятно, это должно жестко регламентироваться документами
-
1. ИМХО аргументация которую Вы предложили может быть убедительна для Вашего начальника, но вряд ли она будет убедительна для Заказчика (если этот внешний Заказчик- другая организация).
Начальнику нужно аргументировать и обосновывать Заказчику все предстоящие работы. В нашем случае Заказчик заплатил только за создание документа, но отказался платить за его поддержку. так вот нужно убедить в том что он ошибся.
2. Документация является важным инструментом при работах по сопровождению системы. В тексте договора на сопровождение системы по идее должны быть предусмотрены Ваши обязательства по поддержанию работосопособности системы только в рамках описанного в технорабочей документации функционала и в соответствии с требованиями ТЗ. Иначе Вы рискуете "подписаться" на непредсказуемо большой объем работ.
Про договор не в курсе, видимо там такого нет.
-
Shur, поздравляю с сотней!
Полностью согласен с Shur. Аргументы крайне не убедительны для Заказчика. Заказчик скажет, что это Ваши трудности и проблемы, как Вы там орагнизуете процесс. Мне нужна система!
Они так щас и работают. Просто пока ни один из фатальных рисков не произошел. Но это пока...
Однако нужно найти аргументацию, которая ясно покажет Заказчику, что может случиться вслучае игнорирования и нежелания финансировать эту работы. Причем это нужно сделать так, чтобы показать, что пострадает в первую очередь сам Заказчик и лучше, если вам удасться показать, что Вы собственно отделаетесь только головной болью, а финансово это Вас не затронет. Т.е. все издержки за упрямство будут виной самого Заказчика. Вопрос как это сделать? Вероятно, это должно жестко регламентироваться документами
Все верно, риски должны быть сформулированы в соответвующих документах и должен происходить процесс управления ими, разработок планов по уменьшению влияния того или иного риска. Документ на проекте есть, только рисков там нет, управления ими соответвенно.
Я как раз и хочу сформулировать их чтобы дать понять Заказчику необходимость выделять деньги на документацию.
-
ArtemyY,
давайте порассуждаем.
есть сторона Заказчика и сторона Подрядчика - ваша сторона.
Между ними есть некий договор, устный или письменный. Если устный плохо.
Если договор лучше, но тоже может быть плохо.
Кто-то заключал этот договор, оценивал смету, соглашался на предложенную сумму. Вероятно в договоре обозначены типы работ и стоимость.
Возможно в ходе проекта вы поняли, что вам нужны средства на поддержание документации в надлежащем виде и поняли, что ресурсов под это вы не предусмотрели. Но тогда - это уже ваша вина. Тут надо уговаривать и убеждать, а не давить.
Если же ситуация совершенно иная, тогда надо искать законные (юридические) способы давления.
Поскольку Вы говорите что документ писался самими Заказчиком и более того потерял актуальность, тогда Вы имели право принять этот документ только после его ревизии. Но если приняли - тут что можно поделать?
-
Начальнику нужно аргументировать и обосновывать Заказчику все предстоящие работы. В нашем случае Заказчик заплатил только за создание документа, но отказался платить за его поддержку. так вот нужно убедить в том что он ошибся.
Какого рода документы входят в документацию? Это и руководство пользователя(ей) и описание системы на разных уровнях (включая уровень разработчиков)?
1. Поддержка пользовательской (рабочей) документации может быть полезна для Заказчика, если у него будут появляться новые пользователи и будет актуальна организация их обучения. Весьма вероятно, что Заказчик неявным образом попытается переложить связанные с обучением проблемы на Вас (особенно если требования к квалификации персонала не оговаривались в договоре на создание системы или в документации).
2. Если обсуждается необходимость поддержки документации уровня разработчиков системы, то если у Заказчика нет своих ИТ-специалистов, которые что-то своё с Вашей системой делают, то вряд ли он согласится поддерживать такую документацию.
3. Не очень понятна роль аналитика (постановщика задач?) в процессах сопровождения. Если предполагается, что под сопровождением системы понимается её "ползучая модернизация" в ходе которой будут производиться доработки системы по постановкам, которые будет делать аналитик, то работать в таком режиме по договору "равномерного и непрерывного" сопровождения можно только при очень дружественных отношениях с Заказчиком. По хорошему каждую такую работу надо уже оформлять отдельными договорами или дополнениями к основному договору (по каждой работе надо иметь возможность согласовывать цены и объемы). А если такие задачи действительно небольшие и разработчики неплохо ориентируются в предметной области , то можно обойтись без выделенного аналитика. При интенсивных контактах с Заказчиком по поводу "непрерывного потока" небольших задач более актуален менеджер проекта (в основном на этапе заключения договора и согласования условий работ) и архитектор, которые будет следить, чтобы на уровне программной реализации не разъехался изначальный замысел системы.
4. Если всё-таки новые постановки предполагаются, то если Вы полагаете, что документацию надо дорабатывать (для себя), то как раз затраты на документирование постановок задач по доработке в рамках сопровождения можно отнести на процессы проектирования. И просить отдельные деньги именно на проектирование решения по постановке, а не на документирование решений. Т.е. акцент сделать на понятие "проектирование", а не "документирование". И развеять иллюзии у Заказчика, насчет того, что системы "просто" программируют (без проектирования), если такие иллюзии у него существуют :).
-
Если Заказчики на вас "подсели", то интересную мысль преложил Shur.
Скажите что при разногласиях между вами и З по поддержке, Вы будете базироваться на текущем ФД, и если он будет не актуальным, то З может просто петерять часть работющего ф-ла.
Так же если это надо вам и З, то разделить затраты поровну.
-
Документ о функциональном дизайне -- действительно гемор для Заказчика, это по AIM кажись нужно в большей степени разработчику, чем заказчику. Ну какой мне, как заказчику, прок от документа в котором будут изложены объекты предметной области и изменения их состояний, если я не собираюсь лезть в ДИЗАЙН системы? А вот документ ТРЕБОВАНИЙ к системе и его актуализация (т.е. ЧТО должна делать система) -- Заказчику и разработчику нужен, т.к. по нему будет осуществляться как разработка и тестирование, так и приемка софта.
-
Спасибо за ответы, но мне кажется я немного не точно описал ситуацию на проекте. Проект декйствительно строится в большей степени на хороших отношениях с Заказчиком. ИТ служба состороны заказчика являектся частью нашей команды или мы их. По сути ПМ на стороне Заказчика и убеждать надо его о необходимости вести документацию "правильно". С нашей стороны тоже есть ПМ но это более формальная роль и влияние на проект имеет очень небольшое.
Скорее всего в договоре не прописаны данные ньюансы - требуемая документация, уровень участников. Я не знаю, не доработка ли это наших юристов и саелзов или просто результат долгого и доверительного сотрудничества. В конце концов это не моя компетенция.
Я как аналитик, могу лишь предостеречь Заказчика - что его ждет в отсутвии данных документов. Я попытался описать это в виде рисков, хотя пока это скорее мысли и идеи, риски планирую попытаюсь сформулировать более четко. Но я предполагаю что я не все возможные риски описал.
-
Если я не ошибаюсь, риски обычно описываются в документе "План управления проектом", который составляется Менеджером проекта и согласовывается с Заказчиком.
По поводу всякого рода договоров - если "Документ ранее писался Заказчиком и в недавно передан нам на поддержку.", то должен быть соответствующий договор, в котором прописаны все условия этой передачи (в том числе и актуализация проектных артефактов).
Если же всего этого нет - то, ИМХО, нужно искать пути решения данной проблемы используя дипломатические навыки :).
-
[skip]
Узнайте, кого из фирмы заказчика уважает тот самый выделяющий деньги человек, познакомьтесь с этим уважаемым, заведите дружеские доверительные отношения, поделитесь мнениями о системе. Убедите его в актуальности ваших просьб и попросите поговорить с выделяющим деньги человеком. При встречах с выделяющим деньги человеком не зацикливайтесь на своих желаниях, спросите что им нужно, что им не нравится, что им не хватает, пожалейте его, встаньте на его место и Вы многое поймете...
-
[skip]
Согласен вопрос коммуникаций очень важен. Очень важно преподнести информация правильно, в нужный момент и нужным людям. Но всетаки в данный момент меня прежде всего интересует вопрос Рисков проекта.
-
ArtemyY, внесите в риски проекта - риск непонимания заказчиком важности ведения документации и поробуйте расписать кто и за что тут отвечает, посчитайте влияние на проект и систему в целом, оцените вклад.
-
Галоген! Нехорошо чужие важные цитаты удалять, база данных боитесь переполнится?!
Личные вопросы в личку :) Задумываюсь о будущем