<b>Инженерный документ, который экономит время команды: что должно быть внутри</b>
Инженерный документ нужен не для красоты, а чтобы решение можно было повторить, проверить и поддержать без автора.
Обычно в нём держат 4 блока:
— цель и границы: что делаем, а что сознательно не трогаем
— варианты и критерии выбора: почему выбран именно этот путь
— риски и допущения: где возможна ошибка и что сломается первым
— план внедрения и отката: как катить изменение и как его быстро остановить
Чаще всего проблемы начинаются, когда в документе есть только идея без ограничений, или есть список задач без объяснения, зачем они нужны. Такой текст сложно обсуждать и ещё сложнее использовать как основу для работы.
Полезная привычка — писать так, чтобы после чтения у человека оставались три ответа: что меняется, почему именно так и как проверить, что всё работает. Тогда документ живёт дольше встречи и не теряется в переписке.
Если ответов на эти три вопроса нет, документ ещё не готов — лучше сократить его и убрать лишнее, чем оставлять неясности.
DevTools Brief — обзор инструментов
@devtools_brief
<b>Инженерный документ, который экономит время команды: что должно быть внутри</b>
Этот пост опубликован в Telegram-канале DevTools Brief — обзор инструментов. Подписаться можно по ссылке: @devtools_brief.