Случай в стране восходящего солнца
Приехали артисты в Японию, все написали в райдере, а про розетки забыли. А розетки там другие. Спрашивают «а есть переходники?» Японцы занервничали, забегали, начали боссам звонить. Прошло двадцать минут, возвращаются, говорят: «$2000 и мы снабдим все переходниками». Администратор плюнул, пошел в соседний супермаркет, купил переходники по $10 за штуку.
При чем тут программирование? Порой программисты точно так же реагируют на изменение требований. Кто мог подумать, что у артистов из Европы нет переходников? Как они посмели не отразить это в ТЗ райдере. Теперь еще месяц разработки, никак не меньше.
Без ТЗ результат ХЗ?
Программисты просят идеальное ТЗ, но это миф, потому что идеально-полное и точное ТЗ - это программный код. Нужно учиться додумывать. Это трудно, больно, неприятно, но совершенно необходимо.
Довольно часто требования исчерпывающего ТЗ продиктованы страхом и/или нежеланием брать ответственность. За пятнадцать лет я не участвовал ни в одном проекте, в котором все было выполнено по ТЗ, написанному заранее. Это банально слишком дорого. Я мог бы написать еще стену текста о том, что не так с супер-мега-подробными ТЗ, но за меня с этим прекрасно справились @doctorsolberg в статье «Ваш личный лангольер. Чем опасно слишком подробное ТЗ на разработку?» и @AlexanderByndyu в статье «12 проблем при работе по техническому заданию в IT-продукте». Поэтому лишь подпишусь под этими точками зрения: ТЗ (оформленное в том или ином виде) — это хорошо. Но нужно уметь вовремя остановиться и оставить простор для решений в процессе реализации.
Но как это сделать? Страшно! А вдруг то, что я предложу не понравится заказчику/заинтересованным лицам? Все очень просто: не нужно предлагать фигню! Просто прежде, чем предлагать, попробуйте провести мысленный эксперимент: как люди будут пользоваться тем, что вы предлагаете? Будет ли им удобно? Это типовое решение или ваше ноу-хау? Ноу-хау можно предлагать, если у вас уже достаточно опыта. Первые пару десятков раз предлагайте типовые решения. Авторизация по сетчатке глаза на веб-сайте — это безусловно свежий подход, но почему-то чаще она происходит с помощью пары логин/пароль или соцсети.
О чем спросить заказчика
Чтобы предложить не-фигню, нужно понимать цели разработки. Лучше всего для этого подходят две техники за авторством Гойко Аджича: Impact Mapping и Spec By Example. Суть первой в том, чтобы задать вопросы «почему?», «что?» и «как?», ключевой из которых — «почему?» или «зачем?» или… «чтобы что?». Spec By Example предлагает список приемов совместной работы над спецификацией.
Почему / Зачем / Чтобы что?
Если вы не понимаете, зачем вас просят сделать то или иное, задавайте вопрос «чтобы что»? Вообще, не бойтесь казаться глупее (в разумных пределах). Гораздо чаще стоит бояться ровно противоположного.
— Давайте в списке задач сделаем фильтры как в 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
Иногда полезнее пойти еще дальше и попытаться понять не только то, как мыслит клиент, но и как мыслят клиенты клиента. Иногда неожиданные решения обнаруживаются.