# БИБЛИОТЕКА Статистика Redmine Управление Критическая цепь Требования и IT Системная инженерия Стейкхолдеры Информация Социальные связи Экономика и общество Саморазвитие Логика, интеллект Сумма технологии ТЕСТИРОВАНИЕ Книги и ссылки QA и QC Цикл тестирования Тест план Тест-дизайн и покрытие Баг-репорт Уровни тестирования Виды тестирования Шаблоны документов XPATH Безопасность Нагрузочное Android Автоматизация Selenium WebDriver Генератор ИНН и т.п. РАЗРАБОТКА Ресурсы Цикл разработки ПО Continuous Integration OOP - базис Frontend HTTP/REST основы Apache web-server Регулярные выражения git Javascript Perl Python Полезности в Windows LINUX Ресурсы права, юзеры и группы crontab IP tables SSH консоль (терминал) tips & tricks useful apps БАЗЫ ДАННЫХ SQL MongoDB
Эта страница:
- Почерпнуть мудрость - Программные комплексы для управления требованиями - Мнение - Трассировка требований
Ещё в этом разделе:
БИБЛИОТЕКА Системная инженерия Требования и IT Управление Критическая цепь Стейкхолдеры Информация Саморазвитие Логика, интеллект Социальные связи Экономика и общество Сумма технологии
Другие разделы:
# MONGO DB SQL РАЗРАБОТКА БИБЛИОТЕКА LINUX ТЕСТИРОВАНИЕ
Требования и IT
Если заказчик любимый - делаем то, что ему нужно.
Если заказчик нормальный - делаем то, что он хочет.
А если заказчик мерзкий - делаем то, что он написал в ТЗ.
Почерпнуть мудрость

Разное

О качестве требований в IT-проектах, начистоту (с позиции команды разработки). С примерами.

Практика формирования требований в IT-проектах от А до Я.

Программные комплексы для управления требованиями
Мнение

Заказчик при формулировке заказа должен определиться по трем пунктам:

  1. Формулировка проблемы. Определяем суть затруднения и описываем его в 1-2 предложениях (для начала).
  2. Критерии приемки. Каждый критерий представляет собой ответ на вопрос: «Как мы поймем, что решили эту проблему? Что должно появиться (или исчезнуть в результате решения проблемы?» Ответы на этот вопрос даст и заказчику, и исполнителю четкое представление как на финише будет оцениваться результат. Формулировки этих ответов позволяют так же определить MVP решения, если мы расставим приоритеты для полученного списка.
  3. По аналогии с интерфейсами, которые обсуждают инженеры, следует определить зависимые области. Все области, которые взаимосвязаны с решением проблемы, должны быть проинформированы об изменениях, и, возможно сами претерпеть изменения.
Если хотя бы на один вопрос нет четкого ответа, то заказ исполнителю будет неквалифицированным, и браться за него не стоит.

взято отсюда:
4 года я был аналитиком и руководителем проектов.
И я считал свои ТЗ отличными и понятными. Я правда над этим много работал. Например, мне однажды попадалась подробная анкета на верстку от топового фрилансера на fl.ru, с 500+ положительными отзывами. Анкета состояла из 30+ пунктов поверх очень хороших макетов. Я из нее взял пунктов 10, и стал использовать на всех этапах, от ТЗ до приемки.

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

Например в ТЗ есть форма регистрации на 5 полей
99% ТЗ содержат перечень полей:
  • *Имя
  • *Email
  • День рождения
  • Телефон
  • Комментарий
  • Город

И поставив звездочки около имени и email заказчик, считает, что уже достаточно описал форму. И если есть moqups или дизайн формы - то вообще какие тут могут быть еще вопросы. А так как в его "сайте/портале/CRM/ERP..." таких форм десятки, а страниц десятки типов, то ТЗ уже и так на 50-100 страниц. А значит достаточно подробное)

Что же мы забыли
  • Валидации полей на типы
  • Валидации полей на лимиты (вряд ли 1800 год рождения - нормально)
  • Валидации полей на уникальность (ну это же очевидно)
  • Где проходит эта самая валидация(на сервере, или в браузере; понятно, что уникальность email мы не можем проверить в браузере, а вот желание проверять валидность и обязательность полей в браузере хорошо бы указать)
  • Ошибки валидации (и даже если попросить их указать, вряд ли вы увидите две разные ошибки на невалидный email и уже существующий)
  • А еще мы забыли уведомления на email, подтверждения телефона, восстановление пароля, авторизацию через соцсети и т.д. И каждый из этих пунктов - это формы, валидации, проверки, тексты ошибок, редиректы после успеха и неуспеха
  • А еще самый коварный вопрос: при авторизации через соцсети, если пользователя с таким email нет, то отказывать в авторизации или создавать нового пользователя? А письмо ему на email в этом случае надо отправлять или нет?

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

Какие из всего этого я сделал выводы для себя?
Неважно какую роль я играю: аналитик, заказчик, программист, руководитель проекта - если я вижу, что ТЗ содержит тонны подводных камней, я сажусь и вместе в диалоге его прорабатываю. Как с тем, кто является для меня заказчиком, так и с тем, кто является для меня исполнителем.
Нет никакого смысла отправлять заказчика доделывать ТЗ, со словами "ТЗ мутное". Он не будет его доделывать, а просто найдет того, кто будет с таким работать. Наступит на все грабли, и справедливо будет считать всех программистов козлами. А ведь у него был шанс, поработать с хорошим программистом, который поможет сделать ТЗ не мутным.
Также нет никакого смысла отдавать все на откуп разработчикам с мыслями: "Форма регистрации, табличка отзывов, страница профиля - это же так стандартно. Что тут может быть непонятно." Разработчик в 99% сделает как он делал в прошлом проекте, или как принято в его стеке технологий, или как ему проще и нравится. Его "нравится" редко когда совпадает с чувством прекрасного у заказчика.
И нет никакого смысла вылизать сразу все ТЗ на 3ё500 страниц.

Мой рецепт:
  • Разбить проекты на части
  • Выбрать 1 часть. В начале желательно важную для проекта
  • Детально описать
  • Сделать 50%. Задать появившиеся вопросы
  • Доделать, показать, получить правки, доделать
  • Взять следующую часть

А еще очень важен постоянный диалог в стиле:
"Мы разбили проект/задачу на 7 частей. Первая часть займет неделю. Мы подготовили вопросы по ней. Сейчас проговорим детали.… (после того, как проговорили детали) Дня через три мы придем с новой порцией вопросов по первой части. А в начале следующей недели так же будем прорабатывать часть 2, подготовьте свои соображения, мы подготовим наши вопросы". И опять же это касается любого участника процесса: как заказчика, так и руководителя проекта, и тимлида, и разработчика, и дизайнера, и даже верстальщика.

Известно, что энтропия (в данном случае мера бардака в проекте) сама увеличивается, если не прикладывать осознанных усилий к её уменьшению. Так что помогают только осознанные усилия, диалоги, контроль, согласования, умелое отстаивание уже утвержденного, выкидывание лишнего. И только, если все это для уменьшения энтропии, а не снятия отвественности и оставления для себя свободы деталий и вариантов "нагнуть другую сторону"

Трассировка требований

Набросок схемы:

( скачать схему в XML )