О качественном ТЗ ⠀ Дали ТЗ, разработчика - все готово, нужно | Александр Детянцев

О качественном ТЗ
⠀
Дали ТЗ, разработчика - все готово, нужно протестировать, обучить пользователей и запускаться. Ну ок.
⠀
Тестирование первой процедуры - ошибка, правим, вторая процедура - ок, третья - ошибка. В общем функционал проверили, ошибки исправили.
⠀
И тут заказчик спрашивает, а ещё это будет. Изучаю, созваниваюсь с ИТ-специалистом системы, с которой интегрируемся, ок, да данные есть. Хранятся в таких-то полях. Разговариваю с разработчиком, да можем получить, нужно проанализировать структуру, код как это можно забирать с минимальными доработками.
⠀
Вечер, можно так. Ок, надо согласовать с архитектором.
⠀
Встреча с архитектором, нет так не пойдет. Собираемся втроём аналитик, архитектор, разработчик. Принимаем решение, что делаем по нормальному. Но увеличиваются сроки. Собираемся с командой, говорим что сроки сдвигаются. А бизнесу уже озвучено, что мы готовы. Молчание, но деваться не куда, надо делать, стараться по максимуму.
⠀
Вывод, что требования бизнеса, что требования систем, с которыми делается интеграция, нужно очень детально описывать и обязательно согласовывать с архитекторами всех систем участвующие в интеграции, обменах. Иначе упущенная мелоч на старте - часы переделок логики, структуры, кода в будущем и как следствие срыв сроков.