![](https://habrastorage.org/getpro/habr/upload_files/7e1/85e/22a/7e185e22a4a9050c7a7b7899c6fba077.png)
Случай в стране восходящего солнца
Приехали артисты в Японию, все написали в райдере, а про розетки забыли. А розетки там другие. Спрашивают «а есть переходники?» Японцы занервничали, забегали, начали боссам звонить. Прошло двадцать минут, возвращаются, говорят: «$2000 и мы снабдим все переходниками». Администратор плюнул, пошел в соседний супермаркет, купил переходники по $10 за штуку.
При чем тут программирование? Порой программисты точно так же реагируют на изменение требований. Кто мог подумать, что у артистов из Европы нет переходников? Как они посмели не отразить это в ТЗ райдере. Теперь еще месяц разработки, никак не меньше.
![Особенности национального электричества Особенности национального электричества](https://habrastorage.org/getpro/habr/upload_files/4df/b75/a41/4dfb75a41f4766d6f086f85998c20b2c.jpeg)
Без ТЗ результат ХЗ?
![Чересчур активный заказчик проявляет инициативу с ТЗ Чересчур активный заказчик проявляет инициативу с ТЗ](https://habrastorage.org/getpro/habr/upload_files/95a/984/fbb/95a984fbb9bd26e81c5bc6b2920697cd.png)
Программисты просят идеальное ТЗ, но это миф, потому что идеально-полное и точное ТЗ - это программный код. Нужно учиться додумывать. Это трудно, больно, неприятно, но совершенно необходимо.
Довольно часто требования исчерпывающего ТЗ продиктованы страхом и/или нежеланием брать ответственность. За пятнадцать лет я не участвовал ни в одном проекте, в котором все было выполнено по ТЗ, написанному заранее. Это банально слишком дорого. Я мог бы написать еще стену текста о том, что не так с супер-мега-подробными ТЗ, но за меня с этим прекрасно справились @doctorsolberg в статье «Ваш личный лангольер. Чем опасно слишком подробное ТЗ на разработку?» и @AlexanderByndyu в статье «12 проблем при работе по техническому заданию в IT-продукте». Поэтому лишь подпишусь под этими точками зрения: ТЗ (оформленное в том или ином виде) — это хорошо. Но нужно уметь вовремя остановиться и оставить простор для решений в процессе реализации.
Но как это сделать? Страшно! А вдруг то, что я предложу не понравится заказчику/заинтересованным лицам? Все очень просто: не нужно предлагать фигню! Просто прежде, чем предлагать, попробуйте провести мысленный эксперимент: как люди будут пользоваться тем, что вы предлагаете? Будет ли им удобно? Это типовое решение или ваше ноу-хау? Ноу-хау можно предлагать, если у вас уже достаточно опыта. Первые пару десятков раз предлагайте типовые решения. Авторизация по сетчатке глаза на веб-сайте — это безусловно свежий подход, но почему-то чаще она происходит с помощью пары логин/пароль или соцсети.
О чем спросить заказчика
Чтобы предложить не-фигню, нужно понимать цели разработки. Лучше всего для этого подходят две техники за авторством Гойко Аджича: Impact Mapping и Spec By Example. Суть первой в том, чтобы задать вопросы «почему?», «что?» и «как?», ключевой из которых — «почему?» или «зачем?» или… «чтобы что?». Spec By Example предлагает список приемов совместной работы над спецификацией.
![Трассировка фичей по бизнес-целям в стиле Impact Mapping Трассировка фичей по бизнес-целям в стиле Impact Mapping](https://habrastorage.org/getpro/habr/upload_files/0c2/29d/d23/0c229dd2343d30d958604f13e44bb946.png)
Почему / Зачем / Чтобы что?
![Коломбо не стеснялся казаться глупым, чтобы раскрыть преступление Коломбо не стеснялся казаться глупым, чтобы раскрыть преступление](https://habrastorage.org/getpro/habr/upload_files/859/aa6/6e4/859aa66e43bfc3e61d1cffacb5001a78.png)
Если вы не понимаете, зачем вас просят сделать то или иное, задавайте вопрос «чтобы что»? Вообще, не бойтесь казаться глупее (в разумных пределах). Гораздо чаще стоит бояться ровно противоположного.
— Давайте в списке задач сделаем фильтры как в 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-элементам.
Обработка ошибок
И снова Скотт Влашин. Даже если монады для обработки ошибок — это не ваше, посмотрите на раздел «Учитываем возможные ошибки при проектировании». Нужно разделять ожидаемые ошибки и исключения. К первым относятся ошибки валидации, проверки прав доступа, другие бизнес-правила. Ко вторым — ошибки, о которых мы не подумали при проектировании и/или системные сбои. В первом случае нужно подсказать пользователю, как исправить ошибку. Во втором — поставить баг в трекер и исправлять в порядке приоритетов в соответствие с серьезностью бага.
Заключение
Уточняйте бизнес-цели, задавайте вопросы «зачем» и «почему» («чтобы что»)
Предлагайте типовые решения
Расширяйте свой репертуар проверенными временем решениями