Доробатывал ли техническое задание заказчика?

Опыт доработки и улучшения технических заданий от заказчиков

Да, это была постоянная часть моей работы

На протяжении 10+ лет я регулярно работал с техническими заданиями от заказчиков и довольно часто приходилось их доработать, уточнить и привести в адекватное состояние. Это одна из критически важных функций Business Analyst, которая часто решает судьбу всего проекта.

Типичные проблемы в исходном ТЗ

1. Расплывчатые требования

• Заказчик описывает желаемый результат в очень общих терминах
• Пример: "Нужна система для управления продажами" без конкретных процессов
• Решение: Проводим workshops и собираем требования с нуля через анализ их бизнес-процессов

2. Технические ошибки и неточности

• Заказчик (особенно нетехнический) описывает решение, а не проблему
• Предлагает неправильные архитектурные подходы
• Указывает устаревшие технологии
• Пример: "Нужна система на Flash"
• Решение: Предлагаем современные аналоги, объясняем технические причины

3. Отсутствие acceptance criteria

• Непонятно, что значит "готово"
• Нет чётких метрик успеха
• Примеры:
  • "Система должна быть быстрой" (вместо конкретных time constraints)
  • "Удобный интерфейс" (без определения целевых пользователей)
• Решение: Определяем SMART критерии для каждого требования

4. Неполнота

• Забыты целые компоненты системы
• Не описаны edge cases
• Отсутствуют non-functional requirements
• Нет сценариев интеграции с существующими системами
• Решение: Проводим полный analysis и дополняем ТЗ

5. Противоречия

• Требования конфликтуют между собой
• Примеры:
  • "Минимизировать стоимость" vs "Максимизировать функционал"
  • "Очень быстрое внедрение" vs "Высокая надёжность"
• Решение: Помогаем заказчику расставить приоритеты

6. Отсутствие контекста

• Нет описания текущего состояния (as-is)
• Не объяснены бизнес-причины требований
• Нет информации о stakeholders
• Решение: Собираем полный контекст через интервью и анализ

Конкретный пример из практики

Заказчик (крупная торговая сеть) предоставил ТЗ на 5 страниц с требованием: "Разработать систему управления складом с интеграцией в 1С".

Проблемы, которые я выявил:

• Не было описания текущих складских процессов
• Не указаны ключевые метрики (время обработки заказа, точность инвентаризации)
• Не определены пользователи (кладовщики, менеджеры, директор)
• Интеграция с 1С описана как "обмен данными", но не сказано, какие данные
• Не учтены особенности разных складов в разных регионах

Что я сделал:

1. Организовал серию интервью с сотрудниками складов, операционного отдела и финансистов
2. Провел анализ существующего процесса в 1С и текущих боль-пойнтов
3. Создал детальное описание as-is и to-be процессов
4. Определил точные требования к интеграции (какие справочники, какая синхронизация, как разрешать конфликты)
5. Описал user stories для каждого типа пользователя с acceptance criteria
6. Добавил non-functional requirements (производительность, надёжность, backup)
7. Выявил риски (например, разные версии 1С на разных складах)

Результат:

• ТЗ выросло с 5 до 40 страниц детальной документации
• Проект прошёл без задержек (именно потому что требования были ясны)
• Заказчик получил систему, которая полностью соответствует его потребностям

Методология доработки ТЗ

1. Анализ и вопросы

• Читаю ТЗ критически
• Ищу неточности, противоречия, пропуски
• Составляю список вопросов к заказчику

2. Stakeholder анализ

• Определяю, кто действительно будет использовать систему
• Провожу интервью с разными категориями пользователей
• Выявляю конфликтующие требования между группами

3. Process mining

• Документирую текущий процесс (as-is)
• Выявляю "боль-пойнты" и неэффективности
• Предлагаю улучшения в целевом процессе (to-be)

4. Уточнение требований

• Каждое требование должно быть SMART
• Определяю success criteria
• Описываю variations и edge cases

5. Архитектурное консультирование

• Предлагаю технические альтернативы
• Объясняю trade-offs
• Помогаю выбрать оптимальное решение

6. Риск-анализ

• Выявляю потенциальные проблемы
• Предлагаю mitigation strategies
• Документирую assumptions и dependencies

Как я это преподношу заказчику

Очень важно правильно подходить к заказчику, чтобы не обидеть его:

Хорошо:

• "Спасибо за подробное ТЗ! Для уточнения несколько вопросов..."
• "Я вижу вариант, который может быть эффективнее. Давайте обсудим..."
• "Обнаружил зависимость между требованиями X и Y. Это конфликтует ли с вашими приоритетами?"

Плохо:

• "Это ТЗ совершенно неправильное"
• "Вы забыли половину требований"
• "Это технически невозможно"

Результаты хорошей доработки ТЗ

• Минус 50-70% багов в процессе разработки (потому что требования были ясны)
• Минус 20-30% временных затрат (не нужны переделки)
• Максимум 95% удовлетворённости заказчика (получает то, что реально нужно)
• Возможность реалистичной оценки (понимаем real scope)
• Снижение рисков (выявляем проблемы ДО разработки)

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