Комментарии 29
Иногда полезнее пойти еще дальше и попытаться понять не только то, как мыслит клиент, но и как мыслят клиенты клиента. Иногда неожиданные решения обнаруживаются.
Администратор плюнул, пошел в соседний супермаркет, купил переходники по $10 за штуку.
Если вы хотите приводить аналогии, то приводите их правильно:
"Администратор плюнул, взял 200 метров неизолированного медного провода, и столько же алюминиевого, засунул концы в розетки, а остальное - к вилкам аппаратуры, разложил по полу. Все работает, убило только кошку случайно" - вот так аналогия немного ближе к реальности.
Это не аналогия, это реальный случай из жизни:)
При чем тут программирование? Порой программисты точно так же реагируют на изменение требований.
А может и правильно реагируют? Ваш "пример из жизни" здесь неуместен.
Сегодня приходит старый клиент - и говорит: мы тут накатили старую базу на новый софт, прямо наживую, почему-то не работает теперь. Ну, там, руками в базе переименовали еще колонку заодно, все равно не работает.
Решение "на $10" - мне пойти и руками это прямо на живой базе поправить.
Решение чуть дороже: вернуть как было и миграциями догнать базу до правильной версии.
"Администратор плюнул, взял 200 метров неизолированного медного провода, …
В данном случае, под администратором подразумевается не сисадмин ;-)
Если сложно провести мысленный эксперимент — не беда. На помощь приходит резиновая уточка. Посадите ее напротив себя и расскажите уточке, что вы придумали...
А что делать, если с уткой мы друг друга прекрасно понимаем, а с заказчиком нет?
Все очень просто: не нужно предлагать фигню! Просто прежде, чем предлагать, попробуйте провести мысленный эксперимент: как люди будут пользоваться тем, что вы предлагаете? Будет ли им удобно? Это типовое решение или ваше ноу-хау? Ноу-хау можно предлагать, если у вас уже достаточно опыта
фраймеворк (или как его там) "Дизайн мышления" предлагает говорить все че на ум приходит и переваривать на следующем шаге выкинуть/изменить/оставить идею из списка (а вдруг две разные идеи в тандеме инсайд вызовут).
Я один не понял, причем здесь программисты? Или имеются ввиду какие-нибудь фрилансеры-одиночки? Так-то обычно с заказчиками работают специальные люди, которые и должны уметь читать мысли оных заказчиков, предлагать им решения, которые лучше всего подойдут под эти мысли и после того, как заказчик будет согласен с решениями - транслировать их в тикеты понятные программистам.
Идеальные, подробные, точные, непротиворечивые тикеты в Jira. Желательно псевдокодом записать.
Было-бы неплохо. Но как правило просто юзер стори по шаблону "As a [persona], I [want to], [so that].". А потом уже под сторей идет обсуждение и разбиение на подзадачи. Бывают стори хорошие, понятные, когда люди их составляющие умеют работать с клиентами. А бывают, что не умеют, тогда и стори кривые и начинаются гадания.
Смысл-то в чем. Угадыватели мыслей это отдельные люди, которые получают за это зарплату. И если они работу делают свою плохо и зря получают зарплату, то тогда да, программистам придется самим в угадайки играть, получается бизнет нанимающий негодных этих людей должен тратить ресурсы более дорогих программистов на выполнение их работы. Лично мне такой подход не особо по душе.
Вот вы и процитировали Spec By Example Аджича. А под story обсуждают и разбивают тоже специально обученные люди или команда?
Что из приведенного на первом изображении относится к компетенции программистов?
В век победившего agile, когда даже в банках проводят "фича-груминги" команде могут транслировать цели на весьма разном уровне. Во много зависит от того "программист" — это "senior developer", "software engineer" или "coder".
Это просто идеальный пример. Напомню, в Японии в сети электропитания 100В. Частоты при этом 50Гц и 60Гц различаются.
Техника гарантированно сгорела. Администратора уволили, страховая отказалась покрывать убытки.
Хиппи Энд (нет)
Да не сгорела и не уволили. Все нормально там разрешилось. Может там не переходники были, а преобразователь. Это было лет десять назад, я не буду звонить человеку со словами "Какие там были переходники? Быстро вспоминай!"
Техника гарантированно сгорела.
От пониженного напряжения, или от повышенной частоты?)
И переходники на картинке - без заземления. Да, я в курсе что в Японии такие розетки.
Я не знаю что там за колхозная группа играла что требования к электропитанию звукового оборудования не прописали в райдере, но как раз к администратору и претензии.
Действительно, пример просто идеальный - человек, который должен отвечать за организацию - профакапил один из важных моментов, а потом выкрутился тем что приделал костыли изолентой. Все как в родном IT (прослезился).
Это была цирковая труппа, поэтому требования к оборудованию у них несколько отличаются от музыкантов. Дело было много лет назад, тогда мало кто вообще в Японии бывал. Профакапил ли администратор? Безусловно. Было ли предложенное японской стороной решение приемлемым? Зависит. Решил ли администратор проблему? Решил. Про котсыли и изоленту в ИТ — это не в бровь, а в глаз, плачу с вами :)))
Нужно учиться додумывать
И далее:
Почему / Зачем / Чтобы что?
Интересно было бы у автора послушать ответ на вопрос, зачем опытному программисту, (который на сегодняшнем рынке труда нарасхват), додумывать что-то за заказчика и учиться читать его мысли?
идеально-полное и точное ТЗ - это программный код.
Вам, наверное, никогда не ставили задачу: "Сделайте так же, как в нашей текущей системе. Вот вам исходники."
Исследовать легаси и технический долг - задача на порядок более сложная, чем понять даже хреновое ТЗ и додумать за заказчика.
В самом худшем случае надо будет повторить все не найденные баги в старой системе "чтобы у нас сходилось" и "вот же работает, сделайте так же".
С таким же успехом можно назвать идеально полным и точным ТЗ какой-нибудь ехе-шник.
Как читать мысли и зачем это программистам