Согласование требований
Это первый самостоятельный этап работы программиста над задачей. У нас нет аналитиков, поэтому все, начиная от требований и заканчивая замерами производительности готового решения, выполняет непосредственно разработчик.
Почему это важно? Без четких требований легко уйти в бесконечные правки или пропустить ключевые детали.
🎯 Цель этапа: Разработать и согласовать требования, по которым задача будет считаться выполненной. Требования — это ответ на вопрос: «Как мы поймем, что всё работает как надо?»
Пример для проекта «Быстрые настройки в отчетах руководителю»:
- Руководитель меняет округление не более чем за 4 клика (сейчас 6 кликов)
- Контекст отчета не теряется при изменениях
- Настройки сохраняются индивидуально для пользователя
То есть это рамки, которые мы сами себе ставим, чтобы ничего не забыть и не делать лишнего. А вот как конкретно это будет реализовано решаем позже. То есть будет ли это подменю, реквизиты на форме или напрыгивающее окно — решается на следующих этапах.
❌ Частая ошибка Неправильно подгонять требования под свое решение. Нужно уметь максимально отдалиться от конкретной идеи и постараться описать то, что на наш взгляд поможет решению.
Не нужно в требованиях указывать конкретные проектные решения:
- Настройки указываются как отдельный реквизит на форме
- При закрытии отчета вариант округления сохраняются в пользовательских настройках
- Быстрые настройки открываются в модальном окне
Совет: Если сложно отвязаться от своей идеи, придумайте 2-3 альтернативных решения (даже абсурдных). Это поможет выделить суть требований.
📖 Пользовательская история Для подготовки требований отлично помогает ключевая пользовательская история. Обычно именно из нее и рождаются хорошие требования. Про User Story есть много отличных материалов, поэтому я просто приведу пример для нашей задачи:
Я как руководитель ХОЧУ увидеть цифры в отчете в тысячах рублей ЧТОБЫ быстрее принимать решение, не производя округление в голове
Такие истории помогают понять, что нужно пользователю, а не как это сделать.
Без использования ключевых пользовательских истории сложно на согласовании описать какую проблему мы собираемся решать. Поэтому использовать их — обязательно.
🚀 Согласование С историей и требованиями разработчик идет на согласование с командой и ответственным за продукт. Но об этом уже в следующем посте.
📝 Полезные материалы: 1. Требования к ПО на пальцах 2. Гайд по написанию пользовательских историй и критериев приёмки
