После вынужденного перерыва возвращаюсь к обещанному циклу статей. Отвечаю на вопрос “куда пропал?)”. Все банально, нехватка времени. А еще я умудрился затеять ремонт. В квартире. Я конечно знал, что управление проектами родилось в строительстве, но только сейчас это реально прочувствовал на себе. Сколько аналогий с ИТ-проектами! Даже на таком казалось простом проекте как квартира, мне пришлось наблюдать все последствия плохого управления. А управлял этим делом нанятый прораб, который, как оказалось, только начал сам организовывать ремонты и по сути своей остался просто мастером. Получилось примерно как программиста отправить управлять ИТ-проектом.
Итак, о требованиях. Как многие знают, о требованиях я уже писал и рассказывал на конференции, а повторяться не хочется. Поэтому, сегодня буду краток и сконцентрируюсь именно на “правильных” требованиях, а конкретнее на их формулировке, пригодной для использования. По сути, мне придется сделать конспект ранее мной же сказанного, только другими словами. Как это там называется, кажется редакция 2.х))
Для “правильной” работы с требованиями нужно сделать 4 вещи:
-
Определиться с видами требований.
-
Определиться с уровнем требований.
-
Прогнать каждое требование через фильтр качества.
-
Создать систему идентификации прослеживаемости жизненного цикла требований.
Собственно все! Больше ничего не нужно. Давайте разберемся с этими четырьмя пунктами.
Определиться с видами требований.
Иногда встречаются документы, где в кучу намешаны требования совершенно разных видов. Например, требования к функциональности, безопасности, производительности. И все вперемешку. Это не только снижает понимание и восприимчивость команды, но и делает работу более энергозатратной. Не надо так делать. Лучше сгруппировать их по видам и отрабатывать отдельно.
В подавляющем большинстве случаев приходится иметь дело с функциональными требованиями. Стоит отметить, что иногда все же целесообразно включать в раздел функциональных и иные виды требований. Например, если нужно разработать отчет, который должен формироваться не дольше 1 мин, а данные этого отчета должны выдаваться в соответствии с уровнем доступа. Тогда у нас добавятся требования к производительности и безопасности. В данном контексте лучше их указать в разделе функциональных, т.к. указанные требования могут повлиять на архитектуру разработки с самого начала.
Определиться с уровнем требований.
Главная мысль заключается в том, чтобы не мешать требования разного уровня в одном документе. Разные уровни требований — разные виды документов. Иначе, неизбежно вызовет проблемы. И вообще, работать с требованиями верхнего уровня это высший пилотаж, доступный только сработавшимся командам, которые специализируются на однотипных задачах и могут себе позволить оперировать агрегированными понятиями, каждый понимая под ними одно и тоже.
Например: “В системе должна быть поддержка штрихкодов”. Где поддержка, при каких условиях, каким устройством, каких штрихкодов, в каких документах и каких операциях… Под этим может пониматься, например, “при сканировании двумерного штрихкода мобильным телефоном в документ “перемещение товаров” должен подставляться товар и его фактическое количество на складе”. И в каждой операции могут всплыть разные детали, иногда весьма существенные. Поэтому, все варианты использования сканера нужно расписать отдельными требованиями.
По моему опыту, куски с агрегированными требованиями в документах чаще встречаются не от того, что “и так все понятно”, а как раз наоборот. От того, что не смогли или не захотели разобраться. Видимо будут применяться золотые формулы: “там прорвемся” и “программисты разберутся”.
Если делаете документ с агрегированными требованиями, то поступайте так со всеми требованиями. Это обосновано, когда действительно не хватаем информации. Да и оценить работы будет сложно. Возможно, в этом месте как раз подойдет какой-нибудь SCRUM с открытым бюджетом. Сам документ вряд ли можно будет назвать техническим заданием, скорее это будет некая “концепция системы”.
Прогнать каждое требование через фильтр качества.
С тех пор, как я рассказывал о теме на конференции в 2012 году, ничего не поменялось. Читать тут.
Если читать лень, вот на картинке все наглядно:
Создать систему идентификации и прослеживаемости жизненного цикла требований
Такая очевидная и простая вещь, как идентификация требований, в большинстве проектов не организована и требования не прослеживается. Под идентификацией и прослеживаемостью подразумеваются две вещи: сам принцип идентификации и некая система, где эти требования учитываются. С принципом все просто, можно взять и пронумеровать типа раз, два, три. А вот с системой учета требований могут возникнуть вопросы. Где их учитывать? Есть специализированные программные продукты, но они громоздкие и дорогие, в нашей индустрии не прижились. Есть практика использования систем типа Task Manager. Таковых сейчас очень много, в т.ч. и бесплатных, которые прекрасно работают в облаке через браузер. Кто-то разрабатывает собственные системы, функционал не сложный. В крайнем случае подойдет и Excel или Google-таблица. Каждая команда сама решает, как им удобнее, все практики рабочие и могут иметь место. Важно, чтобы:
-
Когда вы обсуждаете что-то неработающее с пользователем, вы должны понимать требование номер “какой” вы обсуждаете.
-
Когда разработчик что-то программирует, он должен понимать, что работает над требованием номер “Х”. И когда выпустил новый релиз тоже. Реализовал требование “Х1”, исправил ошибку в требовании “X2”.
-
Когда специалист обучает пользователей, он должен быть уверен, что все требования включены в программу обучения или нашли отражение в пользовательских инструкциях.
-
Когда вы сдаете проект заказчику, вы должны четко понимать, какие требования “ХХ” выполнены и переданы, а какие остались не реализованными.
-
Когда в техподдержку приходят обращения, она должна понимать, относительно каких требований возник вопрос. Возможно, вопрос вообще находится за рамками проекта. Таким образом этапы внедрения в промышленную эксплуатацию часто превращаются в черную дыру, засасывающую все ресурсы.
-
И т.д и т.п. Вы всегда должны понимать, где находитесь. Идентификация требований является основой для управления ими.
Всем хороших проектов и ждем выпуск №4 🙂
Related Posts
Оценка и планирование проекта
Мысли о видах информационных систем…
Конфигурация "Выдача пропусков и учет рабочего времени"
Управление ИТ-проектами. Модуль 3: продвинутый курс по гибкому управлению проектами. Agile. Первый поток. Вебинары проходят с 11 сентября по 27 ноября 2024 г.
Загрузка/Выгрузка Excel для справочника "Графики работы сотрудников"
Онлайн-курсы по управлению ИТ-проектами от Марии Темчиной
Спасибо. Интересна тема про аналитиков, жду продолжения и удачи в ремонте! )))
(1) про аналитиков будет) я тут в отпуске сидел думал и решил себя заставить дописать книгу. Буквально вот сейчас над ней работаю. Еще 5 дней отпуска осталось.
я зарекся делать ремонты — пустая трата времени.
лучше «переехать» на другое дерево — так поступают колонии обезьян в тропиках.
я чувствую, что они поступают системно, предлагая новые горизонты себе и потомству.
По теме, писанина мудреная в расчете на руководителей проектов и секту курсачей «управление проектами», посему
точную оценку пусть дает эта аудитория в количестве 2-5% от специалистов 1С.
А с точки зрения «топической обезьяны» — эта мудреность от лукавого.
Для успешной реализации проекта, в том числе проекта 1С-автоматизации в частности, НЕ нужны руководители проектов с кипой документации для прикрытия некоторых мест когда начнут быть горшки. А кто же нужен?
Нужны другие мозги, другая философия которая предусматривает прежде всего не защиту от негативных результатов,
а четкую нацеленность на позитивный результат. Проще говоря, необходимы профессиональные продюсеры, лучше с западной школой достижения результата. Это работает(очень часто у них) в кино, в сериалах, а играх, в программных проектах….
Почему это не очень часто работает у нас?
Да потому что вместо «продюсеров» процессам берутся рулить «руководители проектов». Причем, у последних ворох
устаревших догм, не нацеленных на результат.
(3)Спасибо, интересное мнение.
Я вот думаю, что профессиональный продюсер это и есть профессиональный руководитель проектов.
(3) Сейчас наоборот, тенденция, что для современной разработки руководители проектов не нужны…
(5)Примеры есть? Это интересная дискуссионная тема)
(6) Так все, кто по SCRUM работают, БИТ-ERP в частности.
(7)Все это не пример)) Пример это когда команда из Пети, Маши и Феди сделали проект такой-то и готовы об этом рассказать. А мы сможем задать им вопросы в живом диалоге. И выяснится, что по факту там было много чего, о чем не говорят.
(8) Так вроде они выступали на инфостарт ивенте последнем, рассказывали.
(9)Так там речь шла во-первых про замену УПП на ERP, во-вторых не сказано, как внедрялось УПП и кто какую работу проводил по бизнес-анализу. А я на 100% уверен, что ее там хватило. И там был РП опять на 100%.
(10) То есть, вы считаете, что они лукавят, когда говорят, что у них в штате нет ни одного РП?
(11) думаю они просто выбрали для себя нишу проектов, где РП не нужен, т.е. нет там особого контакта с бизнесом и 90% это просто разработка
А у вас нет идеи или уже есть курс-тренинг на практике по написанию ТЗ или где-то у кого-то есть в такой же концепции как у вас?
Я бы с удовольствием поучаствовал.
По нумерацию требований вроде бы логично. Но когда пишешь ТЗ все равно сваливаешься в описание, состоящее из нескольких предложений и абзацев, в которых чуть ли не каждое словосочетание и предложение это отдельное требование. Если их нумеровать отдельно, то не поймёшь о чём идёт речь. Такое ощущение, что сначала надо дать описание легко понимаемое тем, кто это потом будет читать со стороны Заказчика и Исполнителя, а потом давать резюме по тексту в виде таблицы пронумерованных требований.
Ещё про нумерации тех же требований. Очень часть хочется в описании других требований ссылаться на другие требования, но так как в процессе написании их количество всё время меняется в описании ссылаться на номера не очень получается. А оставлять это на потом, не хорошо забудешь. Может быть посоветуете какие инструменты?
(13)
1. По поводу тренинга: была такая идея, и она еще жива. Буду думать. Закончу книгу сначала.
2. Если делать все просто в текстовом редакторе, то при разветвленных требованиях действительно не удобно за всем этим следить. Поэтому напрашивается некая система (программа). Есть западные, дорогие Но это из пушки по воробьям. Насчет » чуть ли не каждое словосочетание и предложение это отдельное требование» хорошо бы пример.
Чтобы не менять нумерацию при ссылках в документе, можно ввести свою нумерацию, отдельную от нумерованного списка, предварительно продумав структуру номера. Тогда он меняться не будет. Нумерация требований вовсе не обязана быть последовательной, это ведь просто идентификатор. Уникальный ключ. В одном номере списка в документа может быть несколько требований.
(14) вот например выдержка из ТЗ к вопросу требований, пункт про регистрацию в системе дополнительного соглашения к договору:
«ДОПОЛНИТЕЛЬНОЕ СОГЛАШЕНИЕ
В АИС необходимо обеспечить возможность регистрации в любой момент поступившего дополнительного соглашения к договору контрагента. Причины регистрируемых в АИС дополнительных соглашений:
• Изменение реквизитов контрагента, реквизитов расчетного счета контрагента;
• Изменения объема конкретного квартала года и как следствие размеры платы за указанный квартал;
• Изменения объема конкретного объема квартала в году;
• Изменения объемов кварталов на весь период действия договора;
• Изменение ставки платы (изменения в законодательстве);
Дополнительные соглашения после подготовки отправляются на регистрацию в ТОРРВ , только после регистрации ТОРРВ в общем реестре параметры дополнительных соглашений вступают в силу.
Если в дополнительном соглашении изменяются параметры расчета размера платы (квартальные объемы, ставки), то после ввода дополнительного соглашения должны быть скорректированы (рассчитаны) таблицы расчетов по годам, которые были указаны при «Регистрации параметров договора» или предыдущим дополнительным соглашением.
Если дополнительное соглашается изменяет параметры начисления платы договора за прошедший и уже рассчитанный квартал, то после внесения дополнительного соглашения скорректированные расчеты должны относится к текущему учетному кварталу с признаком «корректировочный» с указанием корректировочного квартала или кварталов.»
(15) конечно не весь контекст понятен, но на первый взгляд, разделил бы на 4 пункта:
1.
• Изменение реквизитов контрагента, реквизитов расчетного счета контрагента;
• Изменения объема конкретного квартала года и как следствие размеры платы за указанный квартал;
• Изменения объема конкретного объема квартала в году;
• Изменения объемов кварталов на весь период действия договора;
• Изменение ставки платы (изменения в законодательстве);
2. Фразу надо переформулировать, т.к. не ясно, как должна вести себя система:
3.
4.
А в сценарий тестирования по п.1. необходимо включить проверку всех 5-ти условий.