Comments 24
Для любителей неповторимых оригиналов лучше добавлять действительно оригинал на русском языке в виде Meeting(Совещание). И существует на бумаге по одноимённому рассказу Алексея Березина так же на русском языке. Почему не углубились в тему, хотя на её основе делаете выводы?
Потому что ссылка на оригинал присутствует в описании обоих приведённых видеороликов.
Присутствует ссылка на оригинал рассказа, но не присутствует на оригинал видео Meeting(Совещание) 2011-го года на канале Sergey Berezin, хотя ваше видео датировано более поздним 2014-м годом (калька с русского на английский). Из чего я делаю заключение, что вы не знаете о других "видео".
Что ж так сложно с пониманием... раз уж пошутили о своём статусе "в теме" и неприязни дубляжа, то и видео оригинала на русском языке лучше приложить. Для полноты картины. Спасибо!
Касаемо выдаваемого ТЗ, то к нему всего три требования:
1) Полнота описываемой задачи. (сюда же входит описание критериев и методов их определения. Например, линия зеленого цвета должна быть конкретной толщины (например, 0,18 мм) и с диапазоном длины волны отражаемого света от 500 до 565 нанометров. В результате, дальтоники не являются оценщиками цвета линий, а математики не будут говорить о её толщине в 0 мм. )
2) Исключение противоречий среди подзадач. (В тестировании обычно на это приводят пример из "все кнопки подтверждения должны быть зелёными" и "кнопка подтверждения выхода из аккаунта должна быть красной", что является противоречием друг другу. В рассказе автор не сделал акцент на то, что линии должны быть прямыми, породив кучу псевдорешений. Но если бы сделал, то взаимная перепендикулярность всех семи линий друг другу могла бы стать противоречием)
3) Выполнимость. (т.е. отсутствие задач типа "поймать золотую рыбку из сказки")
И прогоняя по всем трём пунктам, можно самим дописать ТЗ (что обычно и происходит) и утвердить у заказчика.
Ни разу не спорю насчёт требований к ТЗ, готов подписаться под каждой строчкой. Если сам готовлю - делаю так же (список чуть-чуть другой, но на 95% совпадает). Статья про то, что делать, когда задача "рисовать красное зелёным цветом" уже прилетела. Как её переформулировать, чтобы подсластить пилюлю тому, кто будет реализовывать.
Терпеть не могу это видео. Оно показывает заказчиков идиотами, но идиотами выступает исполнитель, который непригодного "эксперта" привели на переговоры.
Заказчик не должен и не может на 100% владеть терминалогией. Заказчик говорит "прозрачный", реакция "аха-ха идиот". Да нет, не идиот. Он имеет ввиду "полупрозрачный", и то что этого не может понять "эксперт" это проблема "эксперта". Собственно задача эксперта в таком общении - ПОНЯТЬ требования заказчика. Не то что он говорит буквально в ТЗ записать, а "расшифровать" его косноязычные высказывания и понять исходную задачу. Иногда вообще надо понять безнес проблему которую он пытается решать и только потом формировать требования к реализации.
Ролик показывает проблему несколько гиперболизированно - согласен. В той постановке проблемы ролика, которую Вы обозначили, виноват больше всего менеджер, который не провалидировал требования (на противоречивость, тестируемость и т.п.). То, над чем смеются другие - неумение выражать свои желания клиентом. Я не хочу искать, кто из них "на самом деле" больше виноват. Обе точки зрения объединяет то, что в результате больше всех будет страдать ответственный за реализацию специалист. Моя статья - это просто небольшая подсказка для менеджеров, как можно превращать неудобные задачи (неважно по чьей вине возникшие) в такие, за которые которые будет приятно браться.
https://www.youtube.com/watch?v=Og2HsT1qX5s
Тем не менее, задачку-то решили, формально полностью учтя требования заказчика. Другой вопрос, если вот так взять и все формальные требования выполнить - будет ли заказчик доволен? Или он все же хочет что-то другое?
Ну так и я тоже самое говорю: эксперт и ПМ нужны для того, чтобы понять бизнес проблему которую надо решить и предложить решение, которое позднее станет ТЗ.
Понять проблему - это не задача эксперта. Эксперт предоставляет экспертную оценку, а не анализ проблем клиента. Иначе чем тогда занимает бизнес-аналитик? У вас ПМ - это продакт-менеджер или проджект-менеджер? Задачи и методы у последних тоже разные.
Понять проблема - задача всех присутствующих со стороны исполнителя. Именно для этого они там: услышать заказчика, понять задачу, прикинуть сроки и бюджет.
Детали в духе "Продакт или проект" - это уже детали за рамками моей квалификации.
Вам никогда не приходилось писать часть приложения, когда общую решаемую проблему бизнеса вам не только не рассказали, но и категорически отказываются это делать сейчас и в будущем?
И нет, не задача всех присутствующих сторон исполнителя понять проблему. Иногда это невозможно в силу специфики задач. Рамки ответственности должны быть описаны в твоём контракте. Задача исполнителей сделать свой бизнес прибыльным даже решая несуществующие проблемы, иногда их придумывать самим и возглавлять тренды.
Даже если часть бизнес задачи черный ящик - ситуацию это не меняет никак. Всё сводится к "расшифровать и понять".
То что задача заработать - это за рамками обсуждаемого видео. Там абстрактная команда пытается критиковать абстрактный запрос. О деньгах там речи не идет.
Ещё раз, "расшифровать и понять" - это не задача каждого из исполнителей. Да и не полная эта задача, как минимум ещё предложить решение остаётся со всеми граничными условиями.
И с последним много нюансов бывает у заказчика, очевидное для вас, может быть совсем неочевидным для него, а ещё моральные стороны вопроса при решении, сроки и т.п.
Понять очень сложно, если вы не считаете что-то проблемой или минимум её надуманность не вызывает у вас сомнений, а брать заказы нужно.
Достаточно часто встречает ситуация, когда принесенная проблема заказчиком вовсе не проблема, зато реальная проблема стоит рядом. Вот в последнем и надо переубедить заказчика, выставить перед ним цепь взаимосвязей. И как правило, при этом ты выяснишь, что заказчик может оказаться неадекватным идиотом. И будешь реализовывать его полурешение, которое с заранее известным результатом не поможет его проблеме. Но вникать в тонскости своего же бизнес-процесса он не захочет, чтобы говорить с тобой предметно. Такое встречается сплошь и рядом. Увы! Хотя конечно не с каждым первым. Но это видео как раз про этих вторых.
Ценю предложенное решение за юмор и находчивость (и да, я его видел - тема всё-таки не новая), но Вы уже сами ответили на свой же комментарий. Не будет заказчик доволен, к сожалению. Формальное следование требованиям - легчайший, по моему опыту, способ получить судебные иски и испортить свою репутацию.
Вот вы и смогли разделить понятия верификации (выполнение формальных требований) и валидации (выполнение довольства продукцией). А следовательно и отличие QC (в первом варианте) от QA.
Специалиста просят сделать то, что невозможно в принципе: нельзя нарисовать что-то определённым цветом с помощью другого цвета.
Попробуйте нарисовать красками молоко в белой чашке, стоящей на столе, покрытом белой скатертью :)
Это вопрос работы с светом/тенью. Сложно, но проф художник сделает такое без особых проблем.
Молоко в белой чашке, стоящей на столе, покрытом белой скатертью - это понятно, здесь нет противоречий. Да, технически (очень) сложно - но любой понимает, что должно получиться в результате. Более корректной аналогией было бы задание "нарисовать чёрное пятно белой краской".
Правильная постановка проблемных задач