Desinit in piscem mulier formosa superne
В гармоничных компаниях всё же действует разделение ролей. Продакт генерирует идеи, прожект планирует и контролирует, аналитик анализирует, снимает и описывает требования. Но на деле вам может довестись работать в компаниях, в которых экономят на персонале и писать требования самостоятельно. В небольших проектах это вполне норм, даже напротив, минимизирует конфликты — самому с собой договориться проще, чем с выделенным аналитиком.
Но даже если аналитик есть, вам придётся верифицировать его работу и всячески ему помогать. Давайте разберём ключевые ошибки, которые можно насовершать, применительно к работе с требованиями:
Не зовёте на встречи по сбору требований функциональных заказчиков
Компетенций человека, которого заказчик вам выделит для сбора требований, может оказаться недостаточно. Нужно звать тех, кто будет реально использовать разрабатываемый продукт, людей, чьи боли он призван убрать.
На последнем проекте у меня была совсем весёлая ситуация — есть девушка-руководитель проекта со стороны заказчика, хорошо разбирающаяся в айти, но плохо понимающая процессы автоматизируемого подразделения. И есть четыре сотрудника, хорошо понимающих процессы, но плохо разбирающихся в айти. Ну и, само собой, два начальника, куда без них. Но да, лучше такой зоопарк заказчиков, чем полагаться только на теоретические построения.
Короче, привлекайте реальных пользователей.
Недостаточно внимания уделяете деталям
Прочитайте статью про тестирование требований, она полезная. Чем глубже вы погружаетесь в детали исследуемой предметной области, тем выше вероятность разработать успешный продукт.
Все знают про метод «пяти почему». На деле, уже на третьем «почему» заказчик начинает закипать. Но это ваша работа, только так вы сможете докопаться до сути.
1. Почему сайт компании падает?
— Сервер перегружается.
2. Почему сервер перегружается?
— На сервере слишком много одновременных запросов.
3. Почему на сервере слишком много одновременных запросов?
— Сайт не оптимизирован для большого количества пользователей.
4. Почему сайт не оптимизирован для большого количества пользователей?
— На этапе разработки не была проведена нагрузочная проверка.
5. Почему не была проведена нагрузочная проверка?
— В проекте не было заложено времени и ресурсов на тестирование производительности.
Иногда может оказаться, что проблему надо решать не кодированием, а корректировкой процессов. Это уже не аналитика, это уже консалтинг, но и на такое можно наткнуться.
Погружение в детали — основная задача этапа точной оценки. Очень часто бывает, что в результате такого погружения, первичная оценка возрастает в несколько раз.
Не фиксируете договорённости в общем файле
Это в большей степени относится к процедурам управления требованиями и фиксации изменений. Все новые договорённости с заказчиком нужно заносить в общий файл, запрашивать по электронной почте подтверждения формулировок.
Процедуру управления договорённостями можно прописать в договоре, чтобы придать ей юридический вес.
Особенно важный момент, когда вы передаёте или принимаете проект от другого менеджера.
Используете в требованиях размытые формулировки
Фразы «система должна быть удобной в использовании», «система должна быть быстрой», «должна быть обеспечена высокая безопасность», «интерфейс должен быть красивым и современным» — ваши враги. Их в требования быть не должно, нужны чёткие и тестируемые критерии качества системы.
В моей практике был, например, случай доведения «система должна быть быстрой» до предела. Система логировала время выполнения каждой операции, по итогам месяца собирался отчёт, который показывал, какой процент той или иной операции превысил норматив. И в некоторых случаях, мы попадали на штрафы.
Допускаете попадание в ТЗ невыполнимых требований
Вам может прилететь с успешного пресейла что-то, вроде: «Система должна автоматически, без участия пользователя выполнять расчеты, при этом, заменять недостоверные исходные данные и выдавать пользователю рекомендацию N», «Система должна быть доступна 99,9999 % времени в год», «Система должна выдавать прогнозы с точностью 99,99 %».
Совершенно очевидно, что они нереализуемые. Надо говорить с заказчиком, обсуждать их, приводить аргументы и превращать в реализуемые.
Не используете схемы и диаграммы
Если есть возможность подкрепить какие-то формулировки в требованиях диаграммами, это стоит сделать. Требования станет намного легче читать, кроме того, уменьшится время согласований, заказчики обычно диаграммы воспринимают очень хорошо.
Можно использовать какую-нибудь формальную нотацию, но на деле всё чаще всего скатывается к прямоугольникам со стрелочками. Их же обычно и достаточно.
