Как читать мысли и зачем это программистам
Случай в стране восходящего солнца
Приехали артисты в Японию, все написали в райдере, а про розетки забыли. А розетки там другие. Спрашивают «а есть переходники?» Японцы занервничали, забегали, начали боссам звонить. Прошло двадцать минут, возвращаются, говорят:»$2000 и мы снабдим все переходниками». Администратор плюнул, пошел в соседний супермаркет, купил переходники по $10 за штуку.
При чем тут программирование? Порой программисты точно так же реагируют на изменение требований. Кто мог подумать, что у артистов из Европы нет переходников? Как они посмели не отразить это в ТЗ райдере. Теперь еще месяц разработки, никак не меньше.
Японские вилки
Без ТЗ результат ХЗ?
Чересчур активный заказчик проявляет инициативу с ТЗ
Программисты просят идеальное ТЗ, но это миф, потому что идеально-полное и точное ТЗ — это программный код. Нужно учиться додумывать. Это трудно, больно, неприятно, но совершенно необходимо.
Довольно часто требования исчерпывающего ТЗ продиктованы страхом и/или нежеланием брать ответственность. За пятнадцать лет я не участвовал ни в одном проекте, в котором все было выполнено по ТЗ, написанному заранее. Это банально слишком дорого. Я мог бы написать еще стену текста о том, что не так с супер-мега-подробными ТЗ, но за меня с этим прекрасно справились @doctorsolberg в статье «Ваш личный лангольер. Чем опасно слишком подробное ТЗ на разработку?» и @AlexanderByndyu в статье »12 проблем при работе по техническому заданию в IT-продукте». Поэтому лишь подпишусь под этими точками зрения: ТЗ (оформленное в том или ином виде) — это хорошо. Но нужно уметь вовремя остановиться и оставить простор для решений в процессе реализации.
Но как это сделать? Страшно! А вдруг то, что я предложу не понравится заказчику/заинтересованным лицам? Все очень просто: не нужно предлагать фигню! Просто прежде, чем предлагать, попробуйте провести мысленный эксперимент: как люди будут пользоваться тем, что вы предлагаете? Будет ли им удобно? Это типовое решение или ваше ноу-хау? Ноу-хау можно предлагать, если у вас уже достаточно опыта. Первые пару десятков раз предлагайте типовые решения. Авторизация по сетчатке глаза на веб-сайте — это безусловно свежий подход, но почему-то чаще она происходит с помощью пары логин/пароль или соцсети.
О чем спросить заказчика
Чтобы предложить не-фигню, нужно понимать цели разработки. Лучше всего для этого подходят две техники за авторством Гойко Аджича: Impact Mapping и Spec By Example. Суть первой в том, чтобы задать вопросы «почему?», «что?» и «как?», ключевой из которых — «почему?» или «зачем?» или… «чтобы что?». Spec By Example предлагает список приемов совместной работы над спецификацией.
Трассировка фичей по бизнес-целям в стиле Impact Mapping
Почему / Зачем / Чтобы что?
Коломбо не стеснялся казаться глупым, чтобы раскрыть преступление
Если вы не понимаете, зачем вас просят сделать то или иное, задавайте вопрос «чтобы что»? Вообще, не бойтесь казаться глупее (в разумных пределах). Гораздо чаще стоит бояться ровно противоположного.
— Давайте в списке задач сделаем фильтры как в Excel, чтобы по каждой колонке выводился список возможных значений из БД. И еще, как в том другом продукте, пусть рядом с каждым вариантом выведем количество записей в БД. Вся эта информация же у нас есть.
— Зачем?
— Ну им будет удобно.
— А почему нужно выводить количество строк для каждой опции?
— Там есть фильтр по исполнителю. Если слишком много задач назначено на одного человека, то нужно перераспределить задачи.
— БИНГО! Фильтры нужны, чтобы перераспределять задачи… Может быть, оставить фильтры как есть, но сделать отдельный раздел с предупреждениями? Так гораздо проще, чем переделывать всю систему фильтрации ради одного раздела.
— Да, так тоже нормально, главное, чтобы мы могли легко увидеть эту информацию.
Подробнее о технике Spec By Example читайте в статье «Specification By Example — BDD для прагматиков». Про Impact Mapping я вскользь упоминал в докладе «Как запустить MVP и не превратить его в технический долг».
Что лучше предложить самому
Вопросы вида «приклеить» или «прибить» лучше решить самостоятельно. Бизнес-пользователи не эксперты в разработке ПО. Они приходят к «технарям» за решением бизнес-задач. Они не знают, какое техническое решение подойдет в том или другом случае, поэтому ждут, что им посоветуют. Но что, если вы сами не уверены, что посоветовать?
Метод резиновой уточки
Если сложно провести мысленный эксперимент — не беда. На помощь приходит резиновая уточка. Посадите ее напротив себя и расскажите уточке, что вы придумали. Не херня получается? Если где-то на середине вы понимаете, что предлагаете уточке херню, то подумайте еще. Качество предложений резко улучшится.
Минутка рекламы для .NET-разработчиков. Уточка может помочь и во многих других ситуациях, но она не заменяет общение с живыми экспертами. На этой неделе мы проводим конференцию DotNext, где после каждого доклада можно как следует позадавать спикеру уточняющие вопросы. А Уди Дахан (создатель NServiceBus и эксперт в DDD) будет там с Q&A-сессией, то есть как раз чтобы ответить на вопросы участников в сфере своих компетенций. Вопросы Уди можно задать здесь.
А еще в этом сезоне мы решили поэкспериментировать с форматами и с @fillpackart обсудить в прямом эфире стоит ли быть фулл-стеком, как правильно собеседовать, много или мало платят разработчикам. Если у вас есть вопросы к нам, заполняйте вот эту форму.
В общем, если уточки вам недостаточно, приходите.
Чеклист
Вот несколько приемов, которые расширят ваш репертуар предложений:
Task-Based UI
UI можно проектировать на основе структуры данных или на основе вариантов использования. Второе предпочтительнее. Подробнее читайте в этой статье «What is Task Based UI». Бонус: Task-based UI хорошо сочетается с CQRS и GraphQL.
Make illegal states unrepresentable
Еще один принцип, который позволит улучшить качество проектирования. Отлично сочетается с Task-based UI. Разделять большие типы можно как на уровне структуры хранения данных, так и на уровне DTO и соответствующих им UI-элементам.
Обработка ошибок
И снова Скотт Влашин. Даже если монады для обработки ошибок — это не ваше, посмотрите на раздел «Учитываем возможные ошибки при проектировании». Нужно разделять ожидаемые ошибки и исключения. К первым относятся ошибки валидации, проверки прав доступа, другие бизнес-правила. Ко вторым — ошибки, о которых мы не подумали при проектировании и/или системные сбои. В первом случае нужно подсказать пользователю, как исправить ошибку. Во втором — поставить баг в трекер и исправлять в порядке приоритетов в соответствие с серьезностью бага.
Заключение
Уточняйте бизнес-цели, задавайте вопросы «зачем» и «почему» («чтобы что»)
Предлагайте типовые решения
Расширяйте свой репертуар проверенными временем решениями
