Как зафиксировать требования
Не буду долго рассказывать про причины написания лонгрида на такую дискуссионную тему. Лишь постараюсь зафиксировать ход своих мыслей как я выбираю способ фиксации требований с заказчиками.
В чем проблематика?
Есть несколько общепризнанных способа зафиксировать требования к системе:
Классический и широко используемый способ, включающий подробное описание требований к ПО, целей проекта, сроков, бюджета, критериев приемки и других важных аспектов. Это моя любовь. Всё понятно, что делать, как сдавать, за что заплатят и т.д. Какие минусы? Требует времени, обычно за это должны платить заказчики, т.к. это достаточно серьезные трудозатраты. Как реализовать? Сначала общее ТЗ с детализацией этапа проектирования, а затем частные технические задания (ЧТЗ) уже детально расписывающие функционал.
2. Зафиксировать описание бизнес-процессов или пользовательские истории
Такой способ зафиксировать требования не ограничивает на ранних этапах исполнителя способом реализации. С одной стороны это очень удобно, но с другой стороны Заказчика тоже никто не ограничит в трактовках смыслов. Закладывайте 20-30% именно на этот случай. В любом случае что-то будет работать не так как "кто-то" имел ввиду. Желательно критерии приемки зафиксировать на ранних этапах
3. Описать SRS (Software Requirement Specification)
Цитирую: "Функциональный дизайн/спецификация в контексте разработки программного обеспечения относится к процессу определения и документирования функций и работы системы, а также к способам взаимодействия этих функций с пользователями и другими системами. Он включает в себя детализацию требований к каждой функции программного обеспечения и способам их реализации, не углубляясь при этом в конкретные детали реализации на уровне кода. Функциональный дизайн фокусируется на "что" должна делать система, в отличие от "как" она это будет делать, что является предметом технического дизайна."
Что это значит? На старте имеющийся функционал системы должен быть понятен всем участникам процесса. А в SRS вы описываете только настройки и доработки под ваш проект. Круто? Да Нет!!! Чаще всего Заказчик вообще не втыкает чего хочет. Идти в такой путь можно только с полным пониманием контура проекта всеми участниками и с полным погружением команд в проект. Обычно это проекты внедрения больших проектов, являющихся промышленным стандартом.
Что же выбрать?
Обычно, чтобы принять такое решение мне хватает пары дней, из которых я 70% времени собираю инфо. Я очень люблю придумывать фреймворки для таких решений, в этом случае я также придумал как посчитать в баллах. Мои входные данные для принятия решения:
Изучите бэкграунд технического и функционального заказчика, в каких проектах внедрения они участвовали, каких результатов добились, участвовали ли в проектах разработки
В идеале получить однозначный ответ на вот эти вопросы:
1. Есть ли технический заказчик и какой у него опыт внедрения?
а. Технического заказчика (ИТ-службы) на стороне клиента нету. Ну нету и нету. В проекте эту роль выполнять вам - 0 баллов
б. Технический заказчик есть, но у него совсем другой профиль, например он может заниматься только железом и сопровождением инфры. Он, конечно, вам чем-то сможет помочь, но скорее в узкой части - 1 балл
в. Технический заказчик есть и у него есть опыт внедрения ИТ-проектов, но совсем не тех, которые вам близки. Будьте аккуратны, такие ребята могут начать надувать щеки, умничать и вставлять палки в колеса - 2 балла
г. Техзаказчик есть и у него есть нужный вам опыт, но например, в другой отрасли или с другими бизнес-требованиями. Это потенциально, ваш лучший соратник на проекте - 4 балла
д. Техзаказчик, который делал ровно то, что нужно и может даже не раз. Супер-редкость, но поздравляю если это так. Будьте аккуратны, у него могут быть уже готовые подрядчики или продукт, который он хочет внедрять. Он как ваш потенциальный лидер проекта, так и лучший саботажник. Он будет тыкать палками ровно туда где болит - 5 баллов
2. Есть ли функциональный заказчик и какой у него опыт внедрения?
а. Функционального заказчик на стороне клиента нету. Видел такое пару раз, наверное проект будет на холде пока не найдется такой человек - 0 баллов (я бы поставил это как стоп-фактор для входа в проект, он будет просран и вы будете в этом виноваты)
б. Функциональный заказчик есть, но он не понимает требований к Вашей системе или не готов работать а проактивном режиме, в таком случае ему придется сначала показать базовый функционал, а он будет "накидывать" свои идеи. Вы потратите на него очень много ресурса - 1 балл
в. Функциональный заказчик есть, и он понимает, что хочет, но это расходится с пожеланиями стейкхолдера или нарушает правовую базу. И в том и другом случае - готовьтесь работать с возражениями - 2 балла
г. Функциональный заказчик есть и готов рационально участвовать в проекте, но не готов к официальному подтверждению своей потребности. Вы будете бегать за ним с бумажками, но функционально он будет со всем согласен - 4 балла
д. Функциональный заказчик мечты: все хочет, все понимает, является полноценной частью команды и имеет успешный опыт внедрения похожих или не очень продуктов - 5 баллов
3. Модификаторы
а. Понимание заказчиком всех функциональных аспектов вашей системы, в идеале подтвержденное опросником, но звучит как сюр, знаю. (Да +1 балл / Нет -1 балл)
б. У вас понятная схема контрактования и закрытия работы для второй стороны (Да +1 балл / Нет -1 балл)
в. В команде заказчика есть лояльные сотрудники (Да +1 балл / Нет -1 балл)
г. В команде заказчика есть явные пассажиры/саботажники, которые открыто препятствуют (Да -1 балл / Нет +1 балл)
д. Вы получили доступ к инфраструктуре заказчика на ранних этапах и для вас нет сюрпризов по развертыванию сервиса (Да +1 балл / Нет -1 балл)
Правильно оцените насколько то с чем вы идете к Заказчику соответствует его ожиданиями
В идеале получить однозначный ответ на вот эти вопросы:
а. Если продукта нет и вы находитесь в нулевой стадии проекта, то ничего страшного в этом нет, но для нашей оценки - 0 баллов
б. Если продукт находится на этапе прототипа и Вам предстоит допиливать систему до реального продукта - 1 балл
в. Если продукт находится в продуктивной эксплуатации, но требует доработок по более чем 50% функциональностям (тут могут быть пользовательские истории, функциональные модули или какие-то еще Ваши способы выделить блоки функций) - 2 балла
г. Продукт находится в высокой стадии готовности и на ранних этапах проекта вы не обнаружили высокой потребности в доработках, но уровень документированности и доступности доработок не позволяют спланировать полный перечень больших функциональных изменений - 3 балла
д. Продукт находится в высокой стадии готовности и на ранних этапах проекта вы не обнаружили высокой потребности в доработках, уровень документирования, открытости API и наработки по коннекторам с различными системами апробированы на других проектах - 4 балла
е. Вы внедряете коробочный продукт, который не дорабатывается, а настраивается силами аналитиков - 5 баллов
2. Готовность команды к реализации проекта
а. Вы собираете команду под проект - 0 баллов
б. У вас есть команда с которой вы делали проект для другого заказчика и они с вами на одной волне - 1 балл
в. У вас есть лиды для всех потенциальных групп для реализации проекта и они понимают архитектуру вашего Продукта - 2 балла
г. У Вас есть до 50% требуемой команды и они погружены в продукт - 3 балла
д. Пункт "г" + команда внедрения с успешным опытом внедрения минимум - 4 балла
е. Вы пересаживаете команду с аналогичного успешно выполненного проекта - 5 баллов
3. Модификаторы
а. У вас нет проблемных проектов в портфолио (Да +1 балл / Нет -1 балл)
б. У вас нет субподрядчиков в команде, для которых придется составлять официальные ТЗ (Да +1 балл / Нет -1 балл)
в. Ваша команда изначально создавала продукт (Да +1 балл / Нет -1 балл)
г. Вы используете гибкую модель расширения и настройки функционала без хардкода и "системных" справочников (Да -1 балл / Нет +1 балл)
д. Продукт могут внедрять другие интеграторы (Да +1 балл / Нет -1 балл)
Как принять решение?
Отлично, погрузились, посчитали. Получили какие--то абстрактные баллы. Что дальше? А дальше я предлагаю следующую уловку.
Если баллов меньше 15 - У вас в распоряжении есть только ТЗ
Если баллов от 15 до 20 - Вы можете поиграть с заказчиков в Agile
Если баллов от 20 - Наверное вы "Интегратор" и можете позволить себе SRS
Почему с первого проекта вы не сможете подобрать наиболее полный набор документации? В работе Менеджера, хоть это слова и стало ругательным, но оно мне нравится, единственное что качественно меняется с опытом - это точность прогнозирования сроков, стоимости и рисков по проектам. Поэтому Ваша внутренняя шкала за несколько лет откалибруется и вы будете "На глаз" определять требуемый состав документации