Согласование требований

Это первый самостоятельный этап работы программиста над задачей. У нас нет аналитиков, поэтому все, начиная от требований и заканчивая замерами производительности готового решения, выполняет непосредственно разработчик.

Почему это важно? Без четких требований легко уйти в бесконечные правки или пропустить ключевые детали.

🎯 Цель этапа:
Разработать и согласовать требования, по которым задача будет считаться выполненной. Требования — это ответ на вопрос: «Как мы поймем, что всё работает как надо?»

Пример для проекта «Быстрые настройки в отчетах руководителю»:
- Руководитель меняет округление не более чем за 4 клика (сейчас 6 кликов)
- Контекст отчета не теряется при изменениях
- Настройки сохраняются индивидуально для пользователя

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

❌ Частая ошибка
Неправильно подгонять требования под свое решение. Нужно уметь максимально отдалиться от конкретной идеи и постараться описать то, что на наш взгляд поможет решению.

Не нужно в требованиях указывать конкретные проектные решения:
- Настройки указываются как отдельный реквизит на форме
- При закрытии отчета вариант округления сохраняются в пользовательских настройках
- Быстрые настройки открываются в модальном окне

Совет: Если сложно отвязаться от своей идеи, придумайте 2-3 альтернативных решения (даже абсурдных). Это поможет выделить суть требований.

📖 Пользовательская история
Для подготовки требований отлично помогает ключевая пользовательская история. Обычно именно из нее и рождаются хорошие требования. Про User Story есть много отличных материалов, поэтому я просто приведу пример для нашей задачи:

Я как руководитель
ХОЧУ увидеть цифры в отчете в тысячах рублей
ЧТОБЫ быстрее принимать решение, не производя округление в голове

Такие истории помогают понять, что нужно пользователю, а не как это сделать.

Без использования ключевых пользовательских истории сложно на согласовании описать какую проблему мы собираемся решать. Поэтому использовать их — обязательно.

🚀 Согласование
С историей и требованиями разработчик идет на согласование с командой и ответственным за продукт.
Но об этом уже в следующем посте.

📝 Полезные материалы:
1. Требования к ПО на пальцах
2. Гайд по написанию пользовательских историй и критериев приёмки

#Процесс #Разработка

Никита Арипов | 1C. Подписаться

Согласование требований. Продолжение

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


🎯 Зачем это нужно?

Цель согласования — обсудить с тимлидом и ответственным за продукт, что:
☑ Требования закрывают реальную боль пользователей
☑ Задачу нужно решать именно сейчас


🔧 Как проходит процесс?

1. Подготовка
◦ Выбираем 20-минутный слот в расписании.
◦ Приглашаем тимлида и ответственного за продукт
◦ Приглашаем коллег по нужным направлениям (например, если проект про НДС или УСН — подключаем налоговых специалистов)

2. Демо (10 минут)
◦ Показываем анализ проблемы, требования и пользовательскую историю
◦ Пример: «Руководителю сложно настроить отчет → нужно дать возможность делать это контекстно»

3. Обсуждение (10 минут)
◦ Уточняем границы проекта: что включаем, а что оставляем «за скобками»
◦ Обсуждаем серые зоны: что еще не учли, кому может быть хуже?
◦ Ищем компромиссы: возможно сделать инструкцию, а не делать проект

4. Итог
◦ Фиксируем решение. Отправная точка для дальнейшей работы над проектом.


Варианты результата:

✅ Делаем! Требования согласованы — переходим к идее
❌ Не делаем. Отлично! Сэкономили время, если задача не критична или решается без разработки
🔄 Ни к чему не пришли. Нужно уточнить данные и вернуться с новыми аргументами


❗️Важные моменты:

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

- Фокус на главном
Бывает так, что мы специально какую-то часть задачи не делаем. Или наоборот делаем только какую-то одну, даже небольшую часть задачи. А все остальное оставляем на потом. Здесь важно выделить самое критичное и важное, а также защиить свою задачу от неконтролируемого роста

- Жесткий тайминг
На весь процесс - 20 минут.
Почему?
◦ Долго рассказываешь - не хватит времени на обсуждение
◦ Слишком коротко - не раскрыта суть и нечего обсуждать
◦ Уважаем время коллег. Ты тратишь не только свое время, но и время коллег. Очень грустно приходить на согласования на которых ни к чему не пришли.


📌 Что дальше?

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

#Процесс #Разработка

Никита Арипов | 1C. Подписаться