Участники:

• Максим Цепков, Custis, Архитектор, http://mtsepkov.org, https://t.me/mtsepkov
• Юрий Куприянов, Systems.Education, Тренер, Архитектор, Аналитик, https://t.me/systemswing
• Евгений Скориков, AWG, архитектор, автор курсов
• Андрей Бураков, ArchWays.ru, основатель, technical product owner, автор курсов, https://t.me/another_api
• Сергей Нужненко, agile-коуч, архитектор, аналитик, автор курсов

Ведущий: Денис Бесков, Systems.Education, руководитель школы, инженер по требованиям, еx-архитектор

1**. Каков ваш опыт работы с требованиями за последние 3 года?**

Юрий Куприянов

• Во многих крупных проектах от поставщиков требуют применения формального ГОСТов и они составляют многостраничные документы, однако обычно это имеет отдаленное отношение к реальному процессу производства. Получается двойная работа: отдельные практики для создания системы и отдельные - для закрытия контракта.
• Если же требования пишутся "по-честному" и действительно используются для создания системы или оценки стоимости проекта, в большинстве случаев не хватает времени на их тщательную проработку и выдерживание корректного уровня детализации, что приводит к документам, в которых одни части системы прописаны максимально детально — до уровня конкретных экранов и структур БД, а другие — максимально общо, вообще без возможности проверки.
• При этом существенная часть функций остается не проанализирована и просто забыта, что выясняется уже в середине проекта и приводит к перерасходу бюджета и удлинению сроков.
• В своей практике, когда я выступаю и заказчиком, и проектировщиком, я составляю требования и проверяю их в соответствии с принятыми практиками анализа, но обычно это мой рабочий инструмент, который нужен только мне самому для того, чтобы подумать над системой и лучше понять задачу и предметную область.
• После того, как приняты решения по структуре системы и способам реализации - исходные требования становятся уже не нужны, т.к. постановка задач программистам происходит уже в формулировках целевого решения, и по ним же проводится приемка.

Максим Цепков

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