Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: ArtemyY от 19 Сентября 2007, 16:57:38
-
Привет участникам форума.
Попытаюсь сформулировать, как мне кажется, довольно серьезную проблему. Очень интересно мнение со стороны. Возможно проблема спецефическая (для моих проектов, моей организации), но возможно общая для всех.
Посылая документ требований Заказчику(или документ описание бизнес процессов) на согласование мы ставим перед собой задачу определить одинаково правильное видение процессов и разрабатываемой функциональноси. Для этого Заказчик должен вникнуть в каждую деталь документа. В ответ мы ждем от него замечаний комментарии которые помогут исправить документ и максимально привести его в соответствие с реалиями.
Вы когда ни будь задумывались «Что думает заказчик когда видит наш документ после получения его на согласование?». «Какие мысли у него возникают в голове?».
Думаю что то на подобие:
«Для чего они все это делают, пустая трата времени, запрограммировали бы сразу и не тратили бы и свое и мое время»
«Ничего не понятно в документе, непонятные диаграммы, схемы. Зачем же так подробно описывать, они бы еще как свет в комнате включать описали»
«Ну, в чем смогу разобраться сделаю замечания, а в чем нет, потом разберемся когда запрограммируют»
Заказчик часто просто не понимает что согласования требований является ключевым и зачастую определяет успешность всего проекта.
У аналитика же при отсылке документа возникают несколько другие мысли:
«Ну, что смогли выяснить, то согласуем, что нет Заказчик сам виноват, не рассказывал ничего, а я все равно свою работу выполнил».
При этом Заказчик наоборот рассчитывает на квалификацию создателя документа. И на его инициативу, при этом аналитик часто ждет того же. Получается замкнутый круг.
Мы рассчитываем на то что Заказчик ориентируется в бизнесе, т.е. является экспертом предметной области, но мы должны понимать что он скорее всего понятия не имеет о UML, о диаграммах EPC, и т.д. Мы понимаем что это очень просто, но человеку не имеющего отношение к ИТ банальные прецеденты являются полностью непонятным артефактом и чтобы вжиться в документ от него требуется огромные усилия и затрата времени.
Документ требований действительно обеспечивает связь между другими членами проектной команды (каждый член команду более менее сможет разобраться в аналитическом документе) и здесь все более менее продумано, но связь документа с Заказчиком очень нечеткая.
Заказчик вообще может не иметь представления о методике разрабоки ПО, про этапность проектирования. Зачем ему это нужно? Заказчик просто не понимает какие задачи преследуются на этапе сбора требований.
В итоге, ошибки начинают проявляться на стадии тестирования (ведь именно в этот момент бизнес кидает на проработку Системы все силы) Заказчик начинает тратить значительные затраты и человеческие ресурсы на изменение документации, доработку Системы или, что происходит чаще, просто отказывается от ведения документации по причине ее не состоятельности(следствие невнимательного согласования) и нежелании ждать и тратить, и просто дорабатывает Систему на коленке (По моему так разрабатывается 80% процентов ПО у нас).
Хотя, для сокращения затрат необходимо прикладывать максимум сил именно на этапе проектирования и моделирования Системы. Да, это долгосрочные вложения ресурсов, но прибыль и экономия очевидна.
Проектная команда должна максимально привлечь Заказчика в работу над документом. Должен понять что от его инициативности зависит очень много. Для этого он должен действительно захотеть работать над ним т.к.только административные ресурсы привлечения редко приносят максимальный результат. Для того чтобы Заказчик захотел, необходимо чтобы он понял.
-
ArtemyY, подобные дискуссии уже велись на форуме. Эти проблемы хорошо описаны во многих как отечественных, так и зарубежных книгах.
Документ требований безусловно важен для заказчика, поскольку он содержит то, что он хочет. Если не вовлекать заказчика в этот процесс, то вряд ли он получит то, что он хочет. С другой стороны заказчик оплачивает работу, он должен понимать, за что он платит деньги. Где-то в одной из веток форума приведены судебные прецеденты - почитайте их, очень полезное чтиво. Так что полезность понимания ТЗ очевидна. Она сродне тому, что написано в контракте, который мы подписываем не глядя, а потом вдруг оказываемся в щекотливой ситуации.
Теперь насчет представления документа заказчику в виде UML, eEPC, IDEF0 и т.п. Да, конечно, заказчик совсем не обязан понимать все это, потому он должен требовать описания втакой форме, которую он понимает! Если это не возможно или обременительно )за предоставления адаптированного документа разработчик может потребовать некоторую сумму сверху), заказчик может воспользоваться услугами независимого эксперта или иметь в штате достаточно грамотного в этой области человека. Вне всякого сомнения заказчику совершенно не имеет смысла знать как разрабатывается ПО.
Вместе с тем не надо ассоциировать заказчика с одним человеком - это в реальности все равно группа людей. Кроме того есть такое понятие как профессионализм, доверие и репутация. Поиграйте этими понятиями, я думаю многое станет более понятным...
-
Да, проблема усугубляется когда заказчик это группа людей и чем больше людей тем больше рисков. В моих случаях было и есть именно так...
Вот как раз к созданию "адаптивного документа" и я тоже прихожу, но к сожалению ни разу на моих проектах он не использовался, хотя необходимость в нем, как я сейчас уже понимаю, была всегда т.к. проекты были достаточно большие и количество согласующих соответственно. Согласующими как правило являются бухгалтера разного уровня, специалисты операционных подразделений, начальники отделов. При этом ИТ отделы у Заказчика как правило не способны обеспечить алтернативу данного документа, процесс согласования пускается на самотек.
Сейчас я как раз продумываю содержание такого документа, определяюсь с целями.
В документ планирую кратко описать этапность проектирования ПО, выделить этап сбора требований и дать понять важность этапа, на сколько важна детальность описания, к чему ведут ошибки описания, описать что Заказчик не получит Систему вовремя если не достаточно подробно он его изучит и согласует. Заказчик должен понимать огромную важность согласования документа, а также ответственность которую он на себя берет. Он также должен понимать свою компетенцию, в том что он может настаивать на более детальном описании тех или иных моментов, на изменении содержания в плоть до переработки документа.
Продать документ уверен сможет, надо только грамотно предложить.
Очень интересен опыт создания подобных документов, примеры структуры разделов.
-
Нельзя отдавать на откуп документ требований Заказчику, если он безотвественно подходит к делу. Надо разжевать и положить в рот (прочитать ТЗ вместе с ним) и сделать нужные исправления. А то получите то что имеете....
-
Я думаю большого смысла в создании адаптивного документа - нет. Лучше иметь человека, кот. будет ходить и согласовывать требования и их разжевывать у Заказчика. А то получите еще одну ненужную трасировку адаптивных разделов на требования.
-
ArtemyY, я возможно повторю то, что говорится в источниках, на которые ссылается Galogen, но тем не менее.
ТЗ - это не (просто) результаты обследования, это совместный документ, служащий для фиксации принятых решений. Он помогает в дальнейшей коммуникации по проекту, но сам по себе является лишь картиной, слепком коммуникации на момент своего написания. Поэтому когда ТЗ высылается заказчику на согласование, он должен получать не кота в мешке, а на 90% известный документ. Следовательно и нотация должна быть выбрана и согласована ещё на первых встречах по сбору требований, если не раньше.
Если у Заказчика нет людей, обладающих культурой вычитки сложных технических документов, то значит нужно облегчать нотацию, либо, если это недопустимо ввиду сложности системы - либо требовать привлечения с его стороны соответствующих специалистов либо отказываться от проекта.
"Для того чтобы Заказчик захотел, необходимо чтобы он понял" - а это уже консалтинг и управление ожиданиями. Для этого проводятся вводные встречи, где с презентациями и флипчартами показывается, как будет строиться работа, что будет происходить, кто в чём будет участвовать, разрешаются вопросы, настраиваются отдельные моменты.
Заказчик должен быть не столько инициативный (иначе вы рискуете свалиться под грузом противоречивых идей и требований), сколько вовлечённый. Фактически на время проекта вам нужно слиться с заказчиком в единую команду, а не перебрасываться документами через стену электронной почты.
Если заказчиков уровня директоров/начальников отделов много, то нужно объяснять необходимость менеджера проекта со стороны Заказчика, который будет участвовать в согласовании и приоритезации требований с соотв. полномочиями, иначе вы останетесь один на один с Лебедем, Раком и Щукой и все эти животные останутся несчастными и во всём обвинят вас.
-
ArtemyY, я возможно повторю то, что говорится в источниках, на которые ссылается Galogen, но тем не менее.
ТЗ - это не (просто) результаты обследования, это совместный документ, служащий для фиксации принятых решений. Он помогает в дальнейшей коммуникации по проекту, но сам по себе является лишь картиной, слепком коммуникации на момент своего написания. Поэтому когда ТЗ высылается заказчику на согласование, он должен получать не кота в мешке, а на 90% известный документ. Следовательно и нотация должна быть выбрана и согласована ещё на первых встречах по сбору требований, если не раньше.
В идеале да. Но при условии что уровень пользователей для которого выбрана нотация не изменен.
Но в условиях длительного проекта все терпит изменения - пересматриваются рамки проекта, появяются новыю люди из бизнеса, изменяется само руководство. Все предусмотретьне реально.
Если у Заказчика нет людей, обладающих культурой вычитки сложных технических документов, то значит нужно облегчать нотацию, либо, если это недопустимо ввиду сложности системы - либо требовать привлечения с его стороны соответствующих специалистов либо отказываться от проекта.
Мы проект не выбираем. Мы его делаем в сложившихся условиях. Заказчика не изменить, можно только совершенствовать себя
"Для того чтобы Заказчик захотел, необходимо чтобы он понял" - а это уже консалтинг и управление ожиданиями. Для этого проводятся вводные встречи, где с презентациями и флипчартами показывается, как будет строиться работа, что будет происходить, кто в чём будет участвовать, разрешаются вопросы, настраиваются отдельные моменты.
Заказчик должен быть не столько инициативный (иначе вы рискуете свалиться под грузом противоречивых идей и требований), сколько вовлечённый. Фактически на время проекта вам нужно слиться с заказчиком в единую команду, а не перебрасываться документами через стену электронной почты.
"Заказчик должен быть членом команды" - именно! Вот как раз я и ищу варианты коммуникаций. Презентации согласен, способ, при чем более эффективный но более дорогой для заказчика. При этом презентавать будем именно материалы "адаптивного документа" т.е. он нужен...
Если заказчиков уровня директоров/начальников отделов много, то нужно объяснять необходимость менеджера проекта со стороны Заказчика, который будет участвовать в согласовании и приоритезации требований с соотв. полномочиями, иначе вы останетесь один на один с Лебедем, Раком и Щукой и все эти животные останутся несчастными и во всём обвинят вас.
-
Все буквари по управлению проектами в один голос твердят, что заказчик должен активно участвовать в обсуждении и фиксации требований. Но жизнь всегда оказывается сложнее. :)
Из текущего опыта:
- Заказчик находится на другом континенте, и я в глаза его не видел. При этом наши с ним варианты английского - это разные языки.
- Реальный Заказчик появляется только в момент объявления тендера. До этого момента мы сами себе заказчики, и приходится отслеживать и реализовывать как можно больше требований рынка в надежде, что они кому-то понадобятся (что характерно, в таких тендерах заказчики имеют привычку включать некоторые функции в список "на всякий случай").
Но, конечно, стараемся обсудить как можно больше деталей до начала разработки. По крайней мере, нам так кажется. :)
Подход - индивидуальный. С некоторыми заказчиками разрабатывается и согласовывается детальное ТЗ. Для некоторых приходится составлять длинный список вопросов, разбивать на части и отправлять его по почте - любые более-менее сложные документы они просто не читают.
-
1. Даже качественный документ не отменяет личных коммуникаций. Как уже говорил Денис, действительно нужно "разжевывать" документ заказчику, некоторые положения требований и например те же юзкейсы/сценарии нужно в комиксах показывать (при необходимости) ... это я о storyboarding в расширенном понимании. Вам, как аналитику, нужно нарисовать в воображении заказчика КАРТИНКУ ... тогда у заказчика и появиться понимание. И если сначала показать в комиксах, а потом написать формальным языком (и приложить комиксы :-)), то как правило это позволяет улучшить ситуацию с пониманием.
2. Не согласен с утверждением что юзкейсы малопонятны нетехническому человеку. Скорее всего вопросе КАК их писать и как иллюстрировать.
3. Не следует подменять ТРЕБОВАНИЯ описанием бизнес-процессов. БП в данном случае больше нужны чтобы понять КАК РАБОТАЕТ организация (для того чтобы эти процессы автоматизировать, а не реинженирить). Если конечно вы понимаете под БП то же что и я, а не ERP-шный подход с их "функциональной архитектурой" и т.п. ... где под БП они запросто понимают то, что описывается collaboration диаграммами в модели дизайна по, тому же классическому RUP.
4. Проблему "длинных" проектов с изменяющимися людьми/потребностями/процессами и соответственно требованиями на декларативном (и практическом) уровне методологи уже решили. Именно ответом на них было появление а) итерационной модели ЖЦ б) соответствующих методологий (тот же RUP и гибкие (agile) методологии). Вопрос только в том КАК вы с заказчиком договорились работать. Идеальный вариант при таких условиях -- time & materials ... но наша реальность -- это fixed price. Но при этом, чего греха таить, эта price как правило включает риски связанные с переделкой софта, на так ли ;-) (иначе откуда такие гигантские бюджеты на создание не слишком сложных систем в госсекторе ... даже с учетом откатов).
4. Ни одна методология или классный документ не сможет ни чем помочь, если со стороны заказчика нет драйвера этого проекта ... тот кому этот проект действительно нужен и поможет решить массу очевидных проблем. Или попросту если заказчик слабо заинтересован в результатах.
5. greesha, я был рад вас увидеть на семинаре по Scrum в Люксофте. Вы таки им заинтересовались по следам моих рекомендаций :-). Отвечая на вашу ситуацию и как вы сами слышали на семинаре ... должен быть тот самый Product Owner ... и не важно внутри он вас (ваш маркетниг -- т.е. то что вы пишите как "мы сами себе заказчики") или на стороне заказчика. Проблемы с английским - это частная проблема, которая при готовности инвестировать в это деньги со стороны вашего менеджмента -- решаема, а не проблема методологии :-). Тендеры, и их требования, не означают того, что вы не будете общаться с заказчиком в процессе разработки если его таки выиграете. Если при таком тендере заказчик не желает с вами общаться вообще, значит можно быть уверенном в том, что победитель уже известен (с ним уже пообщались), а всем остальным отведена роль статистов.
-
Иногда нет возможности сесть с каждым согласующим и разъяснить ему все особенности разработки документа требований. Когда согласующих 1-2, то да это оптимальнее, но когда 4-8 то думаю уже разумнее создать именно "адаптивный документ". В моем случае на всем нашем проекте в данный момент с нами взаимодействует порядка 40-60 человек из бизнеса(при этом есть "текучка" в данном круге, ~5% в месяц). Ко всем не подойдешь...
40-60 согласующих - это какой-то страшный перебор. Надо поставить перед руководством проекта со стороны заказчика жесткое требование сократить число согласующих до разумного. На практике, я бы сказал, что при наличии примерно 7-10 согласующих лиц у заказчика приходится вводить внутри команды отдельную проектную роль - "согласующий", и на 100% специальный выделенный человек будет ходить по этим согласующим у заказчика, и с ними общаться. Иначе что-то согласовать в разумные сроки нереально. Причем это от типа заказчика (гос / не гос), по-моему, мало зависит.
Если же вы имеете в виду 40-60 лиц, с которыми вы как-либо взаимодействуете, то и в этом случае, кажется, это перебор. Как говорят "буквари по управлению требованиями", надо будущих пользователей категоризировать и определить представителей от каждой категории пользователей. У вас вряд ли 40-60 категорий, скорее, просто по некоторым категориям вы общаетесь с несколькими людьми параллельно. Но эти накладные расходы можно сократить. Выбор ответственных за представление интересов своей категории пользователей лучше всего закрепить формальной бумажкой у заказчика. Ну, а вам надо их, в свою очередь, тоже чем-то заинтересовать. Ну и повлиять на то, чтобы эти представители были назначены из числа адекватных, компетентных и лояльных к вам специалистов.
Ну, это я попытался дополнить высказывания "аксакалов форума", с которыми в этой ветке полностью согласен.
-
5. greesha, я был рад вас увидеть на семинаре по Scrum в Люксофте. Вы таки им заинтересовались по следам моих рекомендаций :-). Отвечая на вашу ситуацию и как вы сами слышали на семинаре ... должен быть тот самый Product Owner ... и не важно внутри он вас (ваш маркетниг -- т.е. то что вы пишите как "мы сами себе заказчики") или на стороне заказчика.
Да, я туда действительно пошёл по Вашей "наводке". :)
Дело в том, что мы ведём параллельно несколько разнородных проектов. Фактически в команде из шести человек, каждый обычно работает над задачами, относящимся к разным проектам: программисты работают над разными приложениями, тестировщик изучает третье, "аналитики" общаются каждый со своими "закреплёнными" клиентами (слово "аналитики" я взял в кавычки, потому что для меня они аналитики, а для руководства - скорее, поддержка клиентов). Поэтому SCRUM "в чистом виде" мы вряд ли сможем внедрить, но некоторые очень полезные идеи я из семинара для себя вынес. Впрочем, это уже оффтоп.
Тендеры, и их требования, не означают того, что вы не будете общаться с заказчиком в процессе разработки если его таки выиграете. Если при таком тендере заказчик не желает с вами общаться вообще, значит можно быть уверенном в том, что победитель уже известен (с ним уже пообщались), а всем остальным отведена роль статистов.
В России чаще всего так и есть.
А вот в Иране, например, тендеры проводятся "по-честному", по крайней мере, у меня сложилось такое впечатление. Сначала оцениваются предложения по набору формальных признаков - технические характеристики, наличие сертификатов, демонстрация некоторых принципиальных возможностей (например поддержка языка фарси - она либо есть, либо нет). Ну и цена, конечно.
А уже после тендера, если удалось зацепиться, начинается реальная работа с заказчиком.
-
40-60 согласующих - это какой-то страшный перебор. Надо поставить перед руководством проекта со стороны заказчика жесткое требование сократить число согласующих до разумного. На практике, я бы сказал, что при наличии примерно 7-10 согласующих лиц у заказчика приходится вводить внутри команды отдельную проектную роль - "согласующий", и на 100% специальный выделенный человек будет ходить по этим согласующим у заказчика, и с ними общаться. Иначе что-то согласовать в разумные сроки нереально. Причем это от типа заказчика (гос / не гос), по-моему, мало зависит.
Если же вы имеете в виду 40-60 лиц, с которыми вы как-либо взаимодействуете, то и в этом случае, кажется, это перебор. Как говорят "буквари по управлению требованиями", надо будущих пользователей категоризировать и определить представителей от каждой категории пользователей. У вас вряд ли 40-60 категорий, скорее, просто по некоторым категориям вы общаетесь с несколькими людьми параллельно. Но эти накладные расходы можно сократить. Выбор ответственных за представление интересов своей категории пользователей лучше всего закрепить формальной бумажкой у заказчика. Ну, а вам надо их, в свою очередь, тоже чем-то заинтересовать. Ну и повлиять на то, чтобы эти представители были назначены из числа адекватных, компетентных и лояльных к вам специалистов.
Да, конечно 40-60 пользователей всего на проекте взаимодействет. По отдельному ТЗ 4-8 человек.
У нас так и есть, каждую категорию представляет лицо из отдела ИТ. Вот только этот человек не всегда может грамотно разъяснить и объяснить несмотря на то что он из ИТ. Опять приходим к тому что проще описать весь материал необходимый при согласовании в адаптивном документе.
Ну, это я попытался дополнить высказывания "аксакалов форума", с которыми в этой ветке полностью согласен.
Т.е. вы всетаки считаете что адаптивный документ не нужен, а нужно сначала правильно организовать работу на проекте???
Но рельно к правильному мы только можем стремится, а реалии таковы, что правильно организовать достатончо сложно, а создание документа требований остается наиболее критичным этапом. При чем концов причин появлении ошибок при нахождении их на этапах разработки и тестирвния найти сложно. Все это списывают на нормальное течение проекта и на рабочие моменты хотя этого можно избежать!!!
Создание "адаптивного документа" максимально дешевый способ попытки решить эти проблемы, но уверен все это окупится, при чем уверен что этого ни кто не заметит, типа так и должно было быть :)
Если всетаки создадим такой документ и внедрим его в процесс то обязательно поделюсь опытом, я уверен в успехе!
-
У нас так и есть, каждую категорию представляет лицо из отдела ИТ. Вот только этот человек не всегда может грамотно разъяснить и объяснить несмотря на то что он из ИТ.
Мы у себя такую ситуацию идентифицируем как один из стандартных рисков при выявлении требований. "Лицо из отдела ИТ" не может выступать представителем какой-либо категории пользователей, за исключением категории "пользователи отдела ИТ". Потребности конечных пользователей должен выражать в проекте конечный пользователь, а не ИТ-шник. Тут ситуация сложная. Сотрудники отделов ИТ заказчика - это наши союзники - им, в итоге, внедрять и поддерживать то, что мы сделаем. Поэтому дружить с ними надо однозначно. Но то, что они не могут представлять интересы "бизнеса" - это, по-моему, очевидно. Достаточно посадить рядом человека из бизнеса и ИТ-шника, который думает, что он понимает потребности бизнеса, и попросить ИТ-шника рассказать своими словами, как устроен бизнес. В 90% случаев человек из бизнеса через пол-минуты начинает нервничать и встревать со словами "да нет же, все совсем не так"... Это типовая ситуация; смотрим это кино у каждого первого заказчика. Привлекайте ИТ-шников как экспертов. Но не как представителей категорий пользователей
-
Т.е. вы всетаки считаете что адаптивный документ не нужен, а нужно сначала правильно организовать работу на проекте???
Я бы не противопоставлял. То, что "нужно сначала правильно организовать работу на проекте" - это сомнению не подлежит.
Насчет адаптивного документа - я не писал, что "он не нужен". Но, честно говоря, я не до конца понимаю, что за документ вы хотите написать.
Изначально термин "адаптированный документ" возник в ответе Galogen'а:
Теперь насчет представления документа заказчику в виде UML, eEPC, IDEF0 и т.п. Да, конечно, заказчик совсем не обязан понимать все это, потому он должен требовать описания втакой форме, которую он понимает! Если это не возможно или обременительно )за предоставления адаптированного документа разработчик может потребовать некоторую сумму сверху), заказчик может воспользоваться услугами независимого эксперта или иметь в штате достаточно грамотного в этой области человека. Вне всякого сомнения заказчику совершенно не имеет смысла знать как разрабатывается ПО.
Здесь речь про то, что если "заказчик UML не понимает", то надо написать требования тем языком, который он понимает. Но мне в данном случае кажется, что порядок действий несколько перепутан. Опять же, сошлюсь на "буквари", требования изначально и должны излагаться на языке бизнеса. Именно так, чтобы их понял прежде всего заказчик. А дальше вы можете уже для проектной команды сделать отдельный документ, где перевести все требования на технический язык.
Вы же говорите о документе, в котором:
... планирую кратко описать этапность проектирования ПО, выделить этап сбора требований и дать понять важность этапа, на сколько важна детальность описания, к чему ведут ошибки описания, описать что Заказчик не получит Систему вовремя если не достаточно подробно он его изучит и согласует.
Это не документ с требованиями, это некий организационный документ. Я бы сказал, что-то типа Устава проекта. Если вы его напишете и согласуете с Заказчиком, вреда не будет. Если же вы сможете заставить его еще и выполнять те процедуры, которые вы там пропишете - можете смело ставить себе памятник при жизни, набирать Учеников и писать книгу "Как заставить заказчика исполнять регламент проекта".
В-общем, пишите, да обрящете. Либо ваш документ заработает, либо вы приобретете ценный жизненный опыт :)
-
Да, термин адаптивный документ заимствовал у Galogen'а, надеюсь не против.
Нет, думаю это не устав проекта.
Основная цель документа сделать из заказчика(эксперта предметной области) полноценного участника команда. Он должен четко понимать свое место, задачи и копметенции. Он должен понимать цену ошибки, понимать что если в документе останется не точно изложеная мысль, упущена деталь то по сути ошибка будет сделана в:
1. функциональном дизайне(у нас так называется документ c описанием интерфейсов, запросов, алгоритмов с детализацией до базы).
2. в системе
3. В тестовой документации.
Соответвенно необходимо провести работы по устранению ошибки в документации, в системе выполнить повтороное тестирвание.
т.е. задачи документа не организовать, а информировать Заказчика. Документ носит ознакомительный характер. Может быть оформлен в виде презентации, но думаю в условиях нашего проекта это не реально или в виде документа, тогда будет посылаться заказчику вместе с документом требований.
Т.о. документ должен содержать следующие разделы:
1. Описание жизненного цикла разработки ПО (этапность).
2. Описание структуры проектной команды.
3. Описание ошибок в документе требований, последствия ошибок.
4. Описание использованных нотаций.
-
Изначально термин "адаптированный документ" возник в ответе Galogen'а:Здесь речь про то, что если "заказчик UML не понимает", то надо написать требования тем языком, который он понимает. Но мне в данном случае кажется, что порядок действий несколько перепутан. Опять же, сошлюсь на "буквари", требования изначально и должны излагаться на языке бизнеса. Именно так, чтобы их понял прежде всего заказчик. А дальше вы можете уже для проектной команды сделать отдельный документ, где перевести все требования на технический язык.
Каюсь, Михаил. Действительно вы правы. Контекст вопроса увел от истинного пути.
Однако есть вопрос, описать требования на языке заказчика, а какова степень детализации? Где та грань, за которой мы описываем требования уровня заказчика и не вносим требования уровня системы, на котором как раз актуальны разные схемы, нотации и прочее?
Насколько понятным путем текстовое структурированное описание бизнес-процесса в отличии от какой-то графической нотации?
Я просто примеряю ситуацию к руководству нашего вуза, т.е. достаточно консервативной аудитории топ-менеджеров со своими представлениями?
-
А я думал что адаптивный документ - это некая облегчённая интерпретация требований. Я был неправ.
Ваш документ должен быть в таком случае, но его полезность опять же сомнительна, надо будет его шлифовать на многих клиентах
-
ArtemyY, мне кажется, есть нечто забавное в том, что чтобы вовлечь Заказчика в разработку 1-го документа (проектного - ТЗ), вы хотите сначала нагрузить его вторым (процессным).
-
ArtemyY, вот давайте рассмотрим ситуацию.
Заказчик (З) - некто, кто желает пошить себе костюм.
Разработчик (П) - некто, кто шьет ему костюм.
При этом у разработчика может быть сложная структура: модельер, закройщик, собственно портной. Для простоты ситуации пусть он один в одном лице.
Заказчик пришел к портному.
З: Хочу пошить костюм
П: какой фасон желаете
З: а что вы можете предложить
П: вот каталог
З: так что-то мне все не нравится
П: а чтобы вы хотели
З: дав вот так и так - высказывает пожелания
П: внимательно слушает и записывает пожелания
утрясаются фасон, стиль, цвет, ткань, пуговицы, снимается мерка и прочие моменты
П назначает срок примерки, убеждаясь, что все понятно для З, он удовлетворен пониманием П требований и ценой которую ему назвали
приходит срок примерки
П надевает на З костюм начинает его адаптировать по фигуре. З довольный уходит. П назначает срок изготовления
З приходит примеряет все отлично
Обычный процесс верно? З взаимодействует с человеком и он абсолютно не знает как ведется процесс, сколько человек готовит его костюм, как вообще шьется костюм
Представим другую ситуацию.
З приходит в мастерскую. З просят раздеться и встать в некую кабинку. Просят зажмурить глаза. Можно открыть.
Все мерка снята. С помощью программы для З демонстрируют его костюм на макете. З в сомнении, он слишком консервативен, но решает довериться.
З приходит через день его костюм готов без примерки - он его одевает и страшно доволен.
Разве при всех этих действиях нужно знать заказчику жизненный цикл ПО, структуры команды, знания технологий и методов создания костюма.
Вот если ему принесут костюм другого цвета, фасона, размера - тут он будет недоволен
-
Денис "Майевтик",
у него етсь альтернатива, не читать документ. Ознакомление с документом будут носить рекамендательный характер.
Но в любом случае документ должен быть максимально легким и в плане объема и в плане информации.
-
Galogen,
Абсолютно не согласен. Не корректное сравнение. Цена ошибки не сопоставима!
Представляете если бы костюм шился тиражом 10000. Уже ближе к нашему случаю. Думаю Заказчику пришлось бы утверждать проект вплоть до выкроек + вникнуть в весь технологический процесс чтобы понять за что он платит что его ожидает, что его ждет.
Заказчик должен быть максимально привлечен в команду на этапе сбора требований.
-
у него етсь альтернатива, не читать документ. Ознакомление с документом будут носить рекамендательный характер.
Но в любом случае документ должен быть максимально легким и в плане объема и в плане информации.
А почему вы вообще думаете, что проблемы неэффективности КОММУНИКАЦИЙ с помощью ДОКУМЕНТА могут быть решены с помощью ДОКУМЕНТА же?
-
Абсолютно не согласен. Не корректное сравнение. Цена ошибки не сопоставима!
Конечно, Вы правы, ситуации не сравнимы.
Представляете если бы костюм шился тиражом 10000. Уже ближе к нашему случаю. Думаю Заказчику пришлось бы утверждать проект вплоть до выкроек + вникнуть в весь технологический процесс чтобы понять за что он платит что его ожидает, что его ждет.
Заказчик должен быть максимально привлечен в команду на этапе сбора требований.
Действительно ли это так? Возьмем господина Коберна. Он достаточно четко пишет на стр.55 (переводная книга о Современных методах описания требований) когда основное действующее лицо - читай заказчик - важен. а когда не важен.
Абсолютно не понимаю, почему заказчик должен знать технологические нюансы. Если же он их знает, какого черта он тогда нанимает разработчика? Пусть тогда сам и руководит проектом. Тогда все проблемы и снимаются.
Заказчик платит за результат,а не технологический цикл. Он потому и платит, что нафиг ему вникать во весь технологический цикл - он доверяет разработчику, ожидая от него профессионализма. Другое дело, что иногда заказчик ожидает от разработчика, того, чего ему от него не следует ожидать.
Да заказчик рискует деньгами, а разработчик рискует репутацией. Потом нужно понимать, что заказчик - это не один человек, а коллектив. Раньше при внедрении АСУП или АСУ, заказчик часто нанимал дляэтой цели субподрядчика - некий проектный институт, который и готовил сбалансированное техническое задание.
Современная практика как мне кажется, тоже вернется возможно к этому.
-
А почему вы вообще думаете, что проблемы неэффективности КОММУНИКАЦИЙ с помощью ДОКУМЕНТА могут быть решены с помощью ДОКУМЕНТА же?
А почему нет?
-
В общем, действительно, проблема не новая.
Заказчику не надо знать методологию. Заказчик должен четко знать, что от него требуется. Для этого в договор вы включаете все требования к заказчику, которые необходимо выполнить. И не надо его убеждать в важности или не важности этапа сбора требований, так как вы пишете, что ТЗ будет являться основанием приемки системы, по этому, что он подпишет, то и получит. Если заказчик адекватен и хочет резултат, он и сам будет заинтересован в четком изложении, понятном для нго, что же он получит. Если заказчику результат не нужен - вы его не получите никак.
Лицо являющееся Заказчиком который подписывает договор и как правило определяет верхнеуровневые - бизнес требования к системе, основные цели, как правило отличается от лица Заказчика который соглсовывает детальные требования. Так вот последний и понятия не имеет о договорах и прочик уставах проекта. И это не правильно, но нагружать его этой информацией явно не стоит...
По поводу документа: любой инженерный документ пишется в расчете на то, что в вопросе сможет разобраться любой адекватный человек с высшим образованием. Задача аналитика - писать заказчику на русском языке. Если есть нужда включить диаграммы, можно включить раздел с кратким описанием, как читать диаграммы.
Тот адаптивный документ, что был описан - это регламент внедрения или план проекта. Такой документ всегда можно написать и утвердить протоколом, как документ, регламентирующий действия в проекте.
Это не регламент!!! Это справочная информация
Это нормальная ситуация. Тогда пишите договора грамотно, чобы в азделе "Заказчик обязан" стояло все, что вам надо для успешного завершения проекта.
Похоже, теоретики предусмотрели все... Это выходит прототипный метод в условиях, когда заказчик об этом не осведомлен ;-) По нашему - каша из топора...
... Алиса знала, что если залпом выпить бутылочку с надписью Йад, то почти наверняка почувствуешь легкое недомогание... (с)
Отказ от каждой здравой идеи может и не убить проект, но все равно повлияет на результат.
Те проблемы, что у Вас описаны лечатся грамотной работой руководителя проекта. Если в этом месте в проекте провал - то у Вас стоит выбор: или методами работы в разведке тащить на себя рычаги руководителя проекта и тайком за них дергать или смириться и на своем месте сделать работу максимально качественно, прикрыться бумагой и вовремя отойти в сторону, когда громада, воздвигнутая на зыбком фундаменте, станет рушиться. А может, вы варите кашу из топора и все исправится на следующей итерации: заказчик пощупает первую версию и выкатит вполне разумный список требований на доработку или переделку...
Мне кажется Вы говорите об идеальном управлении проектом...
И потом, я надеюсь что с документом фундамент простоит гораздо дольше и каша будет наваристее :)
-
А почему нет?
Если коротко - потому что это абсурд. Только Мюнхгаузен мог вытащить сам себя из болота за волосы.
-
Лицо, ставящее подпись УТВЕРЖДАЮ со сторонв заказчика несет ответственность (гражданскую в суде, а иногда и уголовную) за свою часть обязательств по документу. По этому его задача (и в его власти) выпустить соответствующий приказ по своей организации, в котором будет четко прописано, как надо относиться к согласованию и кому.
Извиняюсь за резкость.. Для чтения в туалете.
Если этот документ смогут читать и в туалете, то значит я не зря потратил время.
Если за спиной ваших согласующих не стоит человек с дубиной или перед ними не висит морковка, они с места не двинутся, какие рекомендации не выпускай. Ваша идея повесить морковку агитационного характера: документ, убеждающий людей отнестись к вашей проблеме внимательно. Но без поддерживающей агиткомпании (а, значит, снова организационных мер) этот документ даже не прочитают, особенно, если он будет длиннее трех-четырех станиц.
Да, конечно, часть людей наплюет на документ. Документ ориентирован на людей которые хотят, но не имеют возможности(у них нет материалов/информации) разобраться в ситуации и хорошо сделать Систему. Если необходимо повсить процент читающих, то без административного ресурса не обойтись, но для начала думаю достаточно просто послать (документ)...
При чем тут идеальное управление? Заставить директора заказчика выпустить нужный вам приказ по организации - это не магия - это гораздо более реальнО, чем вам кажется. Надо только перед этим сесть и подумать, что конкретно вы хотите от организации, чтобы потом не выпускать еще 20 поправок. Бывают ситуации, когда подчиненные позволяют себе положить на подпись генерального - вот тогда начинаются совместные танцы с мотивационным бубном, но и здесь вместе с руководством заказчика это гораздо проще.
-
Конечно, Вы правы, ситуации не сравнимы.
Действительно ли это так? Возьмем господина Коберна. Он достаточно четко пишет на стр.55 (переводная книга о Современных методах описания требований) когда основное действующее лицо - читай заказчик - важен. а когда не важен.
Абсолютно не понимаю, почему заказчик должен знать технологические нюансы. Если же он их знает, какого черта он тогда нанимает разработчика? Пусть тогда сам и руководит проектом. Тогда все проблемы и снимаются.
Заказчик платит за результат,а не технологический цикл. Он потому и платит, что нафиг ему вникать во весь технологический цикл - он доверяет разработчику, ожидая от него профессионализма.
Риск получить не разговорчивого и неадекватного заказчика есть всегда. В результате и профессионал может завалить проект.
Вот именно, "Доверяет разработчику и ожидает от него проффесионализма". Заказчик часто себе говорит "ну если они об этом не спрашивают значит это не нужно - они ведь профессионалы". Аналитик может упустить некоторые моменты, упускает и будет упускать, какой бы он профессионал не был. Мы должны подготовить Заказчика к этому!
Т.е. Заказчик должен не только ожидать, но и котролировать разработку документа требований т.к. это требования являются детализацией его договоренности о разработке ПО или приложением к договору на разработку.
Другое дело, что иногда заказчик ожидает от разработчика, того, чего ему от него не следует ожидать.
Да заказчик рискует деньгами, а разработчик рискует репутацией. Потом нужно понимать, что заказчик - это не один человек, а коллектив. Раньше при внедрении АСУП или АСУ, заказчик часто нанимал дляэтой цели субподрядчика - некий проектный институт, который и готовил сбалансированное техническое задание.
Современная практика как мне кажется, тоже вернется возможно к этому.
-
Посылая документ требований Заказчику(или документ описание бизнес процессов) на согласование мы ставим перед собой задачу определить одинаково правильное видение процессов и разрабатываемой функциональноси. Для этого Заказчик должен вникнуть в каждую деталь документа. В ответ мы ждем от него замечаний комментарии которые помогут исправить документ и максимально привести его в соответствие с реалиями.
Заказчику все равно, что от него требуют, для него это дополнительная, лишняя работа. Максимум, что сделает, это прочтет, разбираться точно не будет. Поэтому, пишите документы на русском (чтобы понятно было не ИТшнику, а любому человеку), для наглядности можно рисовать формы, и небольшие диаграммы (как рисунки), не более, больше всего должно быть текста.
P.S. есть прием - чем больше написано, тем вероятнее, что читать не будут совсем. Подпишут так. Но при внедрении будут говорить, что кучу вещей надо переделывать.
-
Это не факт. Во всяком случае в моей практике были моменты, когда занеся ручку для утверждающей подписи на документе, заказчик лез внутрь и выкатывал в 10 раз больше замечаний и уточнений, чем за весь предыдущий цикл сбора требований. Все же подпись дисциплинирует.
Согласна, среди руководства много умных людей.
-
Согласна, среди руководства много умных людей.
Умных -- много, толковых мало (с) ...
-
А кого можно назвать толковым? Вообще в жизни.
-
А кого можно назвать толковым? Вообще в жизни.
Ну это же классика: "Сюда нужно поставить шлагбаум. Или одного толкового майора."
:)