20 мыслей об ИТ-проектах. Мысль №3. "О правильных требованиях к системе"

14.10.19

Управление проектом

Очередной темой серии статей “20 мыслей об ИТ-проектах” будут требования к системе. По результатам голосования был вариант про карьеру проектных ИТ-специалистов, но ее я коснулся в докладе на Воронежском митапе, немного изменив и сделав акцент в сторону аналитиков. В ближайшем выпуске сделаю небольшую выдержку по теме.

После вынужденного перерыва возвращаюсь к обещанному циклу статей.  Отвечаю на вопрос “куда пропал?)”. Все банально, нехватка времени. А еще я умудрился затеять ремонт. В квартире. Я конечно знал, что управление проектами родилось в строительстве, но только сейчас это реально прочувствовал на себе. Сколько аналогий с ИТ-проектами!  Даже на таком казалось простом проекте как квартира, мне пришлось наблюдать все последствия плохого управления. А управлял этим делом нанятый прораб, который, как оказалось, только начал сам организовывать ремонты и по сути своей остался просто мастером. Получилось примерно как программиста отправить управлять ИТ-проектом. 

 

Итак, о требованиях. Как многие знают, о требованиях я уже писал и рассказывал на конференции, а повторяться не хочется. Поэтому, сегодня буду краток и сконцентрируюсь именно на “правильных” требованиях, а конкретнее на их формулировке, пригодной для использования. По сути, мне придется сделать конспект ранее мной же сказанного, только другими словами. Как это там называется, кажется редакция 2.х))

 

Для “правильной” работы с требованиями нужно сделать 4 вещи:

  1. Определиться с видами требований.

  2. Определиться с уровнем требований.

  3. Прогнать каждое требование через фильтр качества.

  4. Создать систему идентификации  прослеживаемости жизненного цикла требований.

 

Собственно все! Больше ничего не нужно. Давайте разберемся с этими четырьмя пунктами.

 

Определиться с видами требований.

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

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

 

Определиться с уровнем требований.

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

Например: “В системе должна быть поддержка штрихкодов”. Где поддержка, при каких условиях, каким устройством, каких штрихкодов, в каких документах и каких операциях… Под этим может пониматься, например,  “при сканировании двумерного штрихкода мобильным телефоном в документ “перемещение товаров” должен подставляться товар и его фактическое количество на складе”. И в каждой операции могут всплыть разные детали, иногда весьма существенные. Поэтому, все варианты использования сканера нужно расписать отдельными требованиями.

По моему опыту, куски с агрегированными требованиями в документах чаще встречаются не от того, что “и так все понятно”, а как раз наоборот. От того, что не смогли или не захотели разобраться. Видимо будут применяться золотые формулы:  “там прорвемся” и “программисты разберутся”.

Если делаете документ с агрегированными требованиями, то поступайте так со всеми требованиями. Это обосновано, когда действительно не хватаем информации. Да и оценить работы будет сложно. Возможно, в этом месте как раз подойдет какой-нибудь SCRUM с открытым бюджетом. Сам документ вряд ли можно будет назвать техническим заданием, скорее это будет некая “концепция системы”. 

 

Прогнать каждое требование через фильтр качества.

С тех пор, как я рассказывал о теме на конференции в 2012 году, ничего не поменялось. Читать тут.

Если читать лень, вот на картинке все наглядно:

 

Создать систему идентификации  и прослеживаемости жизненного цикла требований

Такая очевидная и простая вещь, как идентификация требований, в большинстве проектов не организована и требования не прослеживается. Под идентификацией и прослеживаемостью подразумеваются две вещи:  сам принцип идентификации и некая система, где эти требования учитываются. С принципом все просто, можно взять и пронумеровать типа раз, два, три. А вот с системой учета требований могут возникнуть вопросы. Где их учитывать? Есть специализированные программные продукты, но они громоздкие и дорогие, в нашей индустрии не прижились. Есть практика использования систем типа Task Manager. Таковых сейчас очень много, в т.ч. и бесплатных, которые прекрасно работают в облаке через браузер. Кто-то разрабатывает собственные системы, функционал не сложный. В крайнем случае подойдет и Excel или Google-таблица. Каждая команда сама решает, как им удобнее, все практики рабочие и могут иметь место. Важно, чтобы:

  1. Когда вы обсуждаете что-то неработающее с пользователем, вы должны понимать требование номер “какой” вы обсуждаете.

  2. Когда разработчик  что-то программирует, он должен понимать, что работает над требованием номер “Х”. И когда выпустил новый релиз тоже. Реализовал требование “Х1”, исправил ошибку в требовании “X2”. 

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

  4. Когда вы сдаете проект заказчику, вы должны четко понимать, какие требования “ХХ” выполнены и переданы, а какие остались не реализованными. 

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

  6. И т.д и т.п. Вы всегда должны понимать, где находитесь. Идентификация требований является основой для управления ими. 

Всем хороших проектов и ждем выпуск №4 :)

Требования к системе Техническое задание

См. также

Внедрение крупного проекта на ERP 2.5 с применением методических решений из УПП 1.3 и обеспечением товаров с разных складов с учетом серий

Кейсы проектов Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    14237    0    ASchekachev    37    

55

ТРИЗ. Решение нерешаемых проблем в бизнесе

Управление проектом Бесплатно (free)

Советскую теорию решения изобретательских задач давно применяют крупнейшие мировые корпорации, причем не только в технологической области, но и в сфере бизнеса. На конференции Infostart Event 2021 Post-Apocalypse основатель бизнес-клуба ТРИЗ Алексей Благих рассказал, как с помощью ТРИЗ решать нерешаемые задачи, и почему метод проб и ошибок здесь не поможет.

09.11.2022    4153    0    user1576201    10    

17

Я - ЗУПер! Часть 1. Компетенции сотрудников.

Бизнес-анализ Управление проектом Команда Управление ИТ Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Цикл статей о том, почему акушер-сантехник широкого профиля - это ПЛОХО. Расскажу плюсы специализации на одной предметной области. Рассмотрим понятные аналогии из других областей. Проанализируем пару вакансий, естественно без указания компании.

09.09.2022    10596    0    biimmap    79    

73

Как донести здравый смысл до заказчика. Инструменты архитектора

Управление проектом Архитектура Бесплатно (free)

Андрей Овсянкин на конференции Infostart Event 2021 Post-Apocalypse поделился инструментами, которые помогают ему обрабатывать большой поток задач и экономить недели на обсуждении проекта. Он рассказал, как искать ошибки в процессах, какие диаграммы полезны при общении с заказчиком и с помощью каких инструментов можно быстро рисовать наглядные картинки вместо долгих разговоров.

05.08.2022    13030    0    Evil Beaver    17    

116

Скальпель, зажим, … пластырь, валерьянка. Мы закончили..: инструменты работы бизнес-аналитика

Архитектура Бесплатно (free)

Считается, что аналитику для работы на проекте достаточно уметь строить бизнес-процессы в одной-двух популярных нотациях. Но это не так, потому что работа аналитика гораздо разнообразнее и не ограничивается рисованием схем. О том, какие инструменты пригодятся аналитику и помогут ему сделать свою работу комфортной и удобной, на конференции Infostart Event 2021 Moscow Premiere рассказала руководитель отдела сопровождения финансового учета компании «Самокат» Анастасия Штей.

23.06.2022    6454    0    ashtey    1    

41

Путь покупателя интернет-магазина (Customer Journey) с использованием УФМТП

Архитектура Управленческий учет Бесплатно (free)

Недавно у меня вышла статья под названием «Универсальная функциональная модель торгового предприятия (УФМТП) в нотации IDEF0». И одно из пожеланий читателей было пояснить подробнее, как я лично пользуюсь этой моделью и как вообще ее можно применять на практике. В этой статье я выполню просьбу читателей. И на примере взаимодействия покупателей с интернет-магазином продемонстрирую практическое применение этой модели.

12.05.2022    1992    0    raiml    2    

5

Универсальная функциональная модель торгового предприятия в нотации IDEF0

Архитектура Управленческий учет Бесплатно (free)

Из чего состоит предприятие? Какие функции основные, а какие нет? В данной статье вы найдете ответ на этот и другие вопросы. Модель, построенная на основе опыта бизнес-консультанта с использованием нотации IDEF0.

12.05.2022    6601    0    raiml    4    

7

Технология вялых проектов

Управление проектом Бесплатно (free)

Не все ж такие молодцы.

11.05.2022    5303    0    1c-intelligence    49    

41
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Senator_I 163 14.10.19 19:28 Сейчас в теме
Спасибо. Интересна тема про аналитиков, жду продолжения и удачи в ремонте! )))
2. chavalah 1073 14.10.19 21:19 Сейчас в теме
(1) про аналитиков будет) я тут в отпуске сидел думал и решил себя заставить дописать книгу. Буквально вот сейчас над ней работаю. Еще 5 дней отпуска осталось.
wowik; Senator_I; +2 Ответить
3. VmvLer 15.10.19 10:00 Сейчас в теме
я зарекся делать ремонты - пустая трата времени.
лучше "переехать" на другое дерево - так поступают колонии обезьян в тропиках.

я чувствую, что они поступают системно, предлагая новые горизонты себе и потомству.

По теме, писанина мудреная в расчете на руководителей проектов и секту курсачей "управление проектами", посему
точную оценку пусть дает эта аудитория в количестве 2-5% от специалистов 1С.

А с точки зрения "топической обезьяны" - эта мудреность от лукавого.
Для успешной реализации проекта, в том числе проекта 1С-автоматизации в частности, НЕ нужны руководители проектов с кипой документации для прикрытия некоторых мест когда начнут быть горшки. А кто же нужен?

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

Почему это не очень часто работает у нас?
Да потому что вместо "продюсеров" процессам берутся рулить "руководители проектов". Причем, у последних ворох
устаревших догм, не нацеленных на результат.
4. chavalah 1073 15.10.19 10:42 Сейчас в теме
(3)Спасибо, интересное мнение.
Я вот думаю, что профессиональный продюсер это и есть профессиональный руководитель проектов.
5. genayo 16.10.19 09:20 Сейчас в теме
(3) Сейчас наоборот, тенденция, что для современной разработки руководители проектов не нужны...
6. chavalah 1073 16.10.19 21:31 Сейчас в теме
(5)Примеры есть? Это интересная дискуссионная тема)
7. genayo 17.10.19 09:37 Сейчас в теме
(6) Так все, кто по SCRUM работают, БИТ-ERP в частности.
8. chavalah 1073 17.10.19 12:32 Сейчас в теме
(7)Все это не пример)) Пример это когда команда из Пети, Маши и Феди сделали проект такой-то и готовы об этом рассказать. А мы сможем задать им вопросы в живом диалоге. И выяснится, что по факту там было много чего, о чем не говорят.
Aggressorak; +1 Ответить
9. genayo 17.10.19 14:54 Сейчас в теме
(8) Так вроде они выступали на инфостарт ивенте последнем, рассказывали.
10. chavalah 1073 17.10.19 15:08 Сейчас в теме
(9)Так там речь шла во-первых про замену УПП на ERP, во-вторых не сказано, как внедрялось УПП и кто какую работу проводил по бизнес-анализу. А я на 100% уверен, что ее там хватило. И там был РП опять на 100%.
11. genayo 17.10.19 15:49 Сейчас в теме
(10) То есть, вы считаете, что они лукавят, когда говорят, что у них в штате нет ни одного РП?
12. chavalah 1073 17.10.19 15:51 Сейчас в теме
(11) думаю они просто выбрали для себя нишу проектов, где РП не нужен, т.е. нет там особого контакта с бизнесом и 90% это просто разработка
13. maxx 991 05.11.19 11:37 Сейчас в теме
А у вас нет идеи или уже есть курс-тренинг на практике по написанию ТЗ или где-то у кого-то есть в такой же концепции как у вас?
Я бы с удовольствием поучаствовал.

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

Ещё про нумерации тех же требований. Очень часть хочется в описании других требований ссылаться на другие требования, но так как в процессе написании их количество всё время меняется в описании ссылаться на номера не очень получается. А оставлять это на потом, не хорошо забудешь. Может быть посоветуете какие инструменты?
14. chavalah 1073 05.11.19 11:49 Сейчас в теме
(13)
1. По поводу тренинга: была такая идея, и она еще жива. Буду думать. Закончу книгу сначала.
2. Если делать все просто в текстовом редакторе, то при разветвленных требованиях действительно не удобно за всем этим следить. Поэтому напрашивается некая система (программа). Есть западные, дорогие Но это из пушки по воробьям. Насчет " чуть ли не каждое словосочетание и предложение это отдельное требование" хорошо бы пример.
Чтобы не менять нумерацию при ссылках в документе, можно ввести свою нумерацию, отдельную от нумерованного списка, предварительно продумав структуру номера. Тогда он меняться не будет. Нумерация требований вовсе не обязана быть последовательной, это ведь просто идентификатор. Уникальный ключ. В одном номере списка в документа может быть несколько требований.
15. maxx 991 05.11.19 12:11 Сейчас в теме
(14) вот например выдержка из ТЗ к вопросу требований, пункт про регистрацию в системе дополнительного соглашения к договору:

"ДОПОЛНИТЕЛЬНОЕ СОГЛАШЕНИЕ

В АИС необходимо обеспечить возможность регистрации в любой момент поступившего дополнительного соглашения к договору контрагента. Причины регистрируемых в АИС дополнительных соглашений:
• Изменение реквизитов контрагента, реквизитов расчетного счета контрагента;
• Изменения объема конкретного квартала года и как следствие размеры платы за указанный квартал;
• Изменения объема конкретного объема квартала в году;
• Изменения объемов кварталов на весь период действия договора;
• Изменение ставки платы (изменения в законодательстве);

Дополнительные соглашения после подготовки отправляются на регистрацию в ТОРРВ , только после регистрации ТОРРВ в общем реестре параметры дополнительных соглашений вступают в силу.
Если в дополнительном соглашении изменяются параметры расчета размера платы (квартальные объемы, ставки), то после ввода дополнительного соглашения должны быть скорректированы (рассчитаны) таблицы расчетов по годам, которые были указаны при «Регистрации параметров договора» или предыдущим дополнительным соглашением.
Если дополнительное соглашается изменяет параметры начисления платы договора за прошедший и уже рассчитанный квартал, то после внесения дополнительного соглашения скорректированные расчеты должны относится к текущему учетному кварталу с признаком «корректировочный» с указанием корректировочного квартала или кварталов."
16. chavalah 1073 06.11.19 09:25 Сейчас в теме
(15) конечно не весь контекст понятен, но на первый взгляд, разделил бы на 4 пункта:
1.
В АИС необходимо обеспечить возможность регистрации в любой момент поступившего дополнительного соглашения к договору контрагента. Причины регистрируемых в АИС дополнительных соглашений:
• Изменение реквизитов контрагента, реквизитов расчетного счета контрагента;
• Изменения объема конкретного квартала года и как следствие размеры платы за указанный квартал;
• Изменения объема конкретного объема квартала в году;
• Изменения объемов кварталов на весь период действия договора;
• Изменение ставки платы (изменения в законодательстве);


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

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

4.
Если дополнительное соглашается изменяет параметры начисления платы договора за прошедший и уже рассчитанный квартал, то после внесения дополнительного соглашения скорректированные расчеты должны относится к текущему учетному кварталу с признаком «корректировочный» с указанием корректировочного квартала или кварталов."


А в сценарий тестирования по п.1. необходимо включить проверку всех 5-ти условий.
Оставьте свое сообщение