Как архитектору и разработчику найти общий язык схематизации

Задачи общей схемы

1. Объяснить, зачем делается внедрение или фича.
2. Передать требования бизнеса.
3. Найти лучшую последовательность действий.
4. Прописать каждое действие так, чтобы это было понятно и бизнесу, и разработчику.
5. Дать разработчику понимание ценности как внедрения в целом, так и каждого действия.

Опасность излишне детализированных схем

Это схема кода, а не процесса. Здесь:

• у разработчика нет понимания, зачем он пишет код;

• у бизнеса нет понимания, зачем разработчик пишет код;

• нет ценности, входа и выхода;

• нет свободы для разработчика;

• Увидеть ошибки ДО написания кода сложно.

‍

Результат:

1. На схеме две грубые ошибки. Предложенный поток подвержен отказам, не предусматривает высоких нагрузок, не отвечает на простейший вопрос «зачем тут redis».
2. Разработчик не может предложить иное решение — на схеме же уже указаны инструменты. Зона ответственности разработчика размывается — он перестает быть ответственным за конечный результат.
3. Менеджер не понимает схему глубоко, видит только технические термины.
4. Схема из общего инструмента работы превратилась в инструмент манипуляции.

Так правильно

Схема в формате бизнес-процесса

или в виде интеллект-карты