Design in Practice от Rich Hickey
Посмотрел доклад “Design in Practice” от Rich Hickey, автора языка Clojure.
В докладе он рассказывает про свое виденье процесса проектирования ПО. Есть небольшой уклон в сторону дизайна языков программирования, но все его советы можно применить и к кровавому энтерпрайзу. Доклад не технический, возможно будет более полезен разработчикам от уровня синьор, тех лидам или менеджерам. Rich Hickey великолепный рассказчик, так что советую посмотреть. Далее будут заметки, которые я делал для себя по ходу доклада.
Составьте словарь терминов¶
Определите его в одном месте и следуйте ему везде, в разговорах, документации, коде. Постоянно поддерживайте актуальность словаря.
Словарь может выглядеть как таблица с колонками “Термин на русском”, “Перевод на английский”, “Значение”
Задавайте вопросы¶
Вопросы не только позволят вам лучше разобраться в том, что вы делаете, но и могут спровоцировать дискуссию, из которой может родиться вообще альтернативный взгляд на проблему.
Разработчики часто задают вопросы вроде “что мы сделали вчера?” или “что будем делать сегодня?”. Но редко задают не менее важный вопрос “зачем мы это делаем?”. Особенно важен этот вопрос на стадии дизайна. Он позволяет держать фокус на проблеме, которую решаем, если фокус потерян, то есть риск начать делать не то.
Quote
Если вы не будете сосредоточены на проблеме, то вы можете создать нечто, что вообще не решает никакой проблемы.
Фразы вроде “Нам нужно добавить фичу X в продукт” это не описание проблемы, это решение, которое придумал заказчик для своей проблемы. Старайтесь выяснить, что за ними стоит, часто проблему заказчика можно решить более эффективным способом, чем тот что он придумал.
Об этом, кстати, говорил Джефф Паттон в книге «Пользовательские истории. Искусство гибкой разработки ПО», когда критиковал использование понятия “требования”.
Заранее договаривайтесь об ожиданиях от экспериментов¶
Если для принятия решения в дизайне вам нужно провести какой-то эксперимент, то сначала определите, какие результаты эксперимента вы хотите получить? Как эти результаты вам помогут в принятии решения?
Нарисуйте таблицу-шаблон для результатов ваших экспериментов, такую что посмотрев на нее вы сможете сказать “да, если у меня будут эти данные, то я смогу принять решение!”. Иначе есть риск уйти на неделю в эксперименты и в конце понять, что это никак вам не помогло.
Notes
Как часто происходит такой диалог:
- Для решения проблемы есть технологии X и Y.
- Отлично! Давайте попробуем на одном стенде сделать это через X, а на другом через Y.
Через 2 недели экспериментов мы возвращаемся к обсуждению.
- У нас получилось! X и Y, оба подхода работают!
- Супер! Так и что мы выбираем?
- Без понятия…
Используйте Decision Matrix в принятиях решений¶
Если у вас есть несколько вариантов решения проблемы и сразу трудно выбрать лучший, то попробуйте использовать Decision Matrix. Для этого определите критерии, по которым будут сравниваться решения. Не таскайте этот список критериев из одного шаблона в другой, каждый раз выписывайте только то, что реально для вас важно в данной ситуации. В ячейках не ставим галочки или да/нет. Пишите развернутые описания как этот вариант решения реализует критерий.
DM это еще и инструмент коммуникации, новый человек может быстро подключиться к процессу. Вы убеждаетесь, что у всех участников процесса одинаковое понимание проблемы и критериев ее решения.
Пример Decision Matrix:
