Прототипирование словами

#эксперименты #практики

Уже вот как несколько месяцев я провожу эксперимент внутри команды с внедрением практики - дизайна ревью задачи, перед началом разработки. Честно сказать результатом не доволен пока, но вынес несколько полезных инсайтов из этого эксперимента. Для тех кто первый раз слышит об этой практике поясню: Перед тем как начать что-то писать в коде - сядь и напиши текстом, что ты собираешься напрограммировать. Грубо говоря опиши предстоящее решение на бумаге. Последовательно, логически верно, с нужными деталями, может даже с диаграммами и рисунками. Покажи данную писанину своему лиду и еще до того, как что-то будет написано в коде. Возможно вы сможете найти узкие места в реализации и поправите это на бумаге. Как только к дизайну решения вопросов не будет - садись его реализовывать, но не отходи от намеченного в тексте решения без явной на то необходимости. А если необходимость настала - опиши эту необходимость на бумаге и зафиксируй в задаче ниже изначального дизайна решения.

Очевидный профит от такой практики:

• улушается проработка задачи
• отрабатываются белые пятна до реализации
• тренируется прототипирование на бумаге
• формируется первичная документация
• сохраняется контекст при передачи задачи дальше по процессу

Минусы, которые я заметил:

• косноязчность выражения мыслей разработчиками
• не соответствие реализации запланированному дизайну
• плохая вовлеченность лида в ревью (это мой косяк в данном случае)
• опускание важных деталей при написании дизайна
• лень и забывчивость в написании самих ревью (необязательность)

Не очевидные для меня моменты:

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

Пока в команде у меня это не сильно прижилось, но думаю нужно продолжать культивировать эту практику. Во всяком случае я точно уверен и уже вижу пользу от её внедрения. Но вот, что точно для себя отметил, так это необходимость более глубокого контроля её выполнения. Сама по себе не прорастает.. 🙂

В своих личных проектах я часто программировать начинаю до того, как что-то сформулирую на бумаге. Мне думать кодом, как и многим разрабом сподручнее. И достаточно давно стал бить себя за это по рукам. Последние два проекта, которые я начинал писать с нуля были оформлены в обратной последовательности - сначала бумага, потом код. И от одного я в итоге отказался, осознав его не состоятельность. Это было в какой-то степени даже откровением. Дня три я перечитывал написанное в попытке найти ошибку и зацепиться хоть за какую-то жизнеспособную функцию в нем, но не найдя похоронил саму идея проекта. Отпустив неудачу, я осознал, что мне наоборот очень даже повезло, ибо не потратил кучу времени впустую. Ведь на написание плана реализации у меня ушло всего несколько часов, вместо нескольких недель на разработку, которые я бы потом выкинул.

В общем рекомендую попробовать, хотя бы даже просто на себе. Хотя точно говорю - в командах это работает очень эффективно! Я это не сам придумал, а подслушал у старших колег по цеху 🙂 Не знаю уж сколько времени ушло у них на культивацию практики до рабочего состояния, но про её эффективность наслышан не из одного утюга.