![](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-элементам.
Обработка ошибок
И снова Скотт Влашин. Даже если монады для обработки ошибок — это не ваше, посмотрите на раздел «Учитываем возможные ошибки при проектировании». Нужно разделять ожидаемые ошибки и исключения. К первым относятся ошибки валидации, проверки прав доступа, другие бизнес-правила. Ко вторым — ошибки, о которых мы не подумали при проектировании и/или системные сбои. В первом случае нужно подсказать пользователю, как исправить ошибку. Во втором — поставить баг в трекер и исправлять в порядке приоритетов в соответствие с серьезностью бага.
Заключение
Уточняйте бизнес-цели, задавайте вопросы «зачем» и «почему» («чтобы что»)
Предлагайте типовые решения
Расширяйте свой репертуар проверенными временем решениями
Комментарии (29)
baldr
18.10.2021 18:45+9Администратор плюнул, пошел в соседний супермаркет, купил переходники по $10 за штуку.
Если вы хотите приводить аналогии, то приводите их правильно:
"Администратор плюнул, взял 200 метров неизолированного медного провода, и столько же алюминиевого, засунул концы в розетки, а остальное - к вилкам аппаратуры, разложил по полу. Все работает, убило только кошку случайно" - вот так аналогия немного ближе к реальности.
marshinov Автор
18.10.2021 18:51+4Это не аналогия, это реальный случай из жизни:)
baldr
18.10.2021 19:26-1При чем тут программирование? Порой программисты точно так же реагируют на изменение требований.
А может и правильно реагируют? Ваш "пример из жизни" здесь неуместен.
Сегодня приходит старый клиент - и говорит: мы тут накатили старую базу на новый софт, прямо наживую, почему-то не работает теперь. Ну, там, руками в базе переименовали еще колонку заодно, все равно не работает.
Решение "на $10" - мне пойти и руками это прямо на живой базе поправить.
Решение чуть дороже: вернуть как было и миграциями догнать базу до правильной версии.
pae174
19.10.2021 10:01+1Если аппаратура российского артиста заточена под 220 вольт то в Японии через переходник за $10 она просто не стартует - там 110.
kuzzzov
18.10.2021 19:17+20Если сложно провести мысленный эксперимент — не беда. На помощь приходит резиновая уточка. Посадите ее напротив себя и расскажите уточке, что вы придумали...
А что делать, если с уткой мы друг друга прекрасно понимаем, а с заказчиком нет?
dreesh
18.10.2021 19:32+1Все очень просто: не нужно предлагать фигню! Просто прежде, чем предлагать, попробуйте провести мысленный эксперимент: как люди будут пользоваться тем, что вы предлагаете? Будет ли им удобно? Это типовое решение или ваше ноу-хау? Ноу-хау можно предлагать, если у вас уже достаточно опыта
фраймеворк (или как его там) "Дизайн мышления" предлагает говорить все че на ум приходит и переваривать на следующем шаге выкинуть/изменить/оставить идею из списка (а вдруг две разные идеи в тандеме инсайд вызовут).
Politura
19.10.2021 02:10Я один не понял, причем здесь программисты? Или имеются ввиду какие-нибудь фрилансеры-одиночки? Так-то обычно с заказчиками работают специальные люди, которые и должны уметь читать мысли оных заказчиков, предлагать им решения, которые лучше всего подойдут под эти мысли и после того, как заказчик будет согласен с решениями - транслировать их в тикеты понятные программистам.
marshinov Автор
19.10.2021 07:24+4Идеальные, подробные, точные, непротиворечивые тикеты в Jira. Желательно псевдокодом записать.
Politura
19.10.2021 07:50+1Было-бы неплохо. Но как правило просто юзер стори по шаблону "As a [persona], I [want to], [so that].". А потом уже под сторей идет обсуждение и разбиение на подзадачи. Бывают стори хорошие, понятные, когда люди их составляющие умеют работать с клиентами. А бывают, что не умеют, тогда и стори кривые и начинаются гадания.
Смысл-то в чем. Угадыватели мыслей это отдельные люди, которые получают за это зарплату. И если они работу делают свою плохо и зря получают зарплату, то тогда да, программистам придется самим в угадайки играть, получается бизнет нанимающий негодных этих людей должен тратить ресурсы более дорогих программистов на выполнение их работы. Лично мне такой подход не особо по душе.
marshinov Автор
19.10.2021 07:56Вот вы и процитировали Spec By Example Аджича. А под story обсуждают и разбивают тоже специально обученные люди или команда?
Politura
19.10.2021 08:21+1Конечно команда (включая того, кто и сторю создал). Но на этом этапе читать мысли заказчика уже не надо, они уже прочитаны. Конечно если человек сделавший сторю делает свою работу хорошо.
marshinov Автор
19.10.2021 10:33+1Раз обсуждает команда разве она не додумывает детали реализации в процессе обсуждения? Я против того, чтобы выносить вопросы "приклеить" или "прибить" в ТЗ, а не за отмену ТЗ как такового. Кажется, это я явно в статье написал. Может быть мы неверно друг друга понимаем?
Yser
19.10.2021 05:12+3Трассировка фичей по бизнес-целям в стиле Impact Mapping
Что из приведенного на первом изображении относится к компетенции программистов? Ну разве что последний шаг, который должен быть началом ТЗ.
Итого: в такой замечательной идее, о том как программисты не додумывают за бизнесом даже первая иллюстрация - ни о чем.Я бывал на обеих сторонах - бизнеса и программирования и хочу рассмотреть рубрику "решения за $10", т.к. судя во всему, именно она предлагается в качестве идеала.Мы имеем:
Заказчика, который может и не разбираться в технической стороне, но зачастую не может формализовать даже собственные бизнес-процессы (это если они вообще существуют в виде хоть какого-то осмысленного процесса).
Подрядчика, к которому приходит заказчик со своей "идеей". В "решении за $10" на стороне подрядчика, в прослойке перед программерами, сидят такие же болванчики-передасты, которые не могут в формализацию, но могут в коммуникацию и все такое.
Программистов. Опять же надо понимать, что в рубрике "решения за $10" просто не будет программистов с достаточной квалификацией или тех, кто после варки в подобной "процессной каше", не опустит руки, и, также как и все остальные, не начнет перекладывать отвественность за решение на клиента, менеджера и т.п..
Итого:
Как контрактор, я так и работаю - с вопросами, докапыванием до сути и выяснением реальных потребностей бизнеса, а не то что клиент думает что ему надо. Зачастую это в ущерб собственной прибыли. И это уже что-то типа привычки и я делаю также на фулл-тайм занятости.
Но, я прекрасно понимаю тех, кто работая на контору этого не делает. И если у вас в компании есть такая проблема , то она, скорее всего связана с тегами "Управление разработкой Управление проектами Управление продуктом", а не с тегом "Программирование". Т.к. именно от того как организован процесс и зависит конечный результат.marshinov Автор
19.10.2021 10:26+1Что из приведенного на первом изображении относится к компетенции программистов?
В век победившего agile, когда даже в банках проводят "фича-груминги" команде могут транслировать цели на весьма разном уровне. Во много зависит от того "программист" — это "senior developer", "software engineer" или "coder".
mvv-rus
19.10.2021 18:40+1Мне вот во всем этом непонятно, зачем бизнесу требуются дорогие сеньоры с навыками телепатии, вместо того, чтобы 9 из 10 из них заменить дешевыми кодерами, не имеющих таких навыков — это ж какая экономия может быть?
Почему так не получается, и что сделать, чтобы получилось?marshinov Автор
19.10.2021 19:14Брукс что-то писал про сущность и акциденцию на эту тему. Может дело в них…
kudriako
19.10.2021 07:57+1Это просто идеальный пример. Напомню, в Японии в сети электропитания 100В. Частоты при этом 50Гц и 60Гц различаются.
Техника гарантированно сгорела. Администратора уволили, страховая отказалась покрывать убытки.
Хиппи Энд (нет)
marshinov Автор
19.10.2021 08:00Да не сгорела и не уволили. Все нормально там разрешилось. Может там не переходники были, а преобразователь. Это было лет десять назад, я не буду звонить человеку со словами "Какие там были переходники? Быстро вспоминай!"
SergeyMax
19.10.2021 09:54+3Техника гарантированно сгорела.
От пониженного напряжения, или от повышенной частоты?)
baldr
19.10.2021 09:59+2И переходники на картинке - без заземления. Да, я в курсе что в Японии такие розетки.
Я не знаю что там за колхозная группа играла что требования к электропитанию звукового оборудования не прописали в райдере, но как раз к администратору и претензии.
Действительно, пример просто идеальный - человек, который должен отвечать за организацию - профакапил один из важных моментов, а потом выкрутился тем что приделал костыли изолентой. Все как в родном IT (прослезился).
marshinov Автор
19.10.2021 10:30Это была цирковая труппа, поэтому требования к оборудованию у них несколько отличаются от музыкантов. Дело было много лет назад, тогда мало кто вообще в Японии бывал. Профакапил ли администратор? Безусловно. Было ли предложенное японской стороной решение приемлемым? Зависит. Решил ли администратор проблему? Решил. Про котсыли и изоленту в ИТ — это не в бровь, а в глаз, плачу с вами :)))
HellWalk
19.10.2021 15:28-5Нужно учиться додумывать
И далее:
Почему / Зачем / Чтобы что?
Интересно было бы у автора послушать ответ на вопрос, зачем опытному программисту, (который на сегодняшнем рынке труда нарасхват), додумывать что-то за заказчика и учиться читать его мысли?
Vladimir_Izotov
19.10.2021 22:38-1идеально-полное и точное ТЗ - это программный код.
Вам, наверное, никогда не ставили задачу: "Сделайте так же, как в нашей текущей системе. Вот вам исходники."
Исследовать легаси и технический долг - задача на порядок более сложная, чем понять даже хреновое ТЗ и додумать за заказчика.
В самом худшем случае надо будет повторить все не найденные баги в старой системе "чтобы у нас сходилось" и "вот же работает, сделайте так же".
С таким же успехом можно назвать идеально полным и точным ТЗ какой-нибудь ехе-шник.
raamid
Иногда полезнее пойти еще дальше и попытаться понять не только то, как мыслит клиент, но и как мыслят клиенты клиента. Иногда неожиданные решения обнаруживаются.