Уточнение того, что именно нужно заказчику - это работа с требованиями, так сказать, на основе печального опыта - финализировать договорённости, что мы общаемся на одном языке с заказчиком, и когда он говорит о табурете, он имеет в виду именно табурет, а не какой-то другой объект для сидения.
(Предупреждая вопрос о релизе и внезапном осознании, что заказчик хотел компьютерное кресло - такое тоже бывает. На берегу договорились об одном, но к моменту релиза бизнес осознал, что хотел совсем другого. Но это отдельная история.)
То есть, уточняя параметры изделия (табурет и его характеристики), мы определяем, какой именно табурет мы должны изготовить. А далее, из этого уже определяем неявное - для чего он нам нужен: для сидения на кухне или для исполнения цирковых номеров.
Но вообще, ваше замечание справедливо, и по-хорошему, если мы не являемся компанией, которая специализируется строго на изготовлении мебели для дома (а потому нам в принципе не могут заказать какой-то специализированный табурет с необычным функционалом), то уточнять нужно не только параметры табурета, но и его предназначение: для чего он - сидеть, стоять, жонглировать.
Это неявные требования, подразумевающиеся по умолчанию.
Если у вас будет задача "Добавить в модальное окно кнопку "Закрыть"", само собой разумеющимся будет завязать на эту кнопку функционал закрытия модального окна.
Так и в данном примере - если мы разработали табурет, то ожидается, что на нём можно будет сидеть. Иначе для чего мы вообще его делали?
Я с вами полностью согласна. Всё вами сказанное справедливо и отлично отражает картину того, как должен выглядеть процесс разработки в идеале :)
Более того, я слышала о компаниях, в которых примерно так всё и происходит, и участие тестировщика в разработке ограничено именно этапом, когда хорошо проанализированная и готовая задача приходит в тест.
Но по моему опыту, такую тщательную подготовку требований и хороший анализ могут себе позволить зрелые компании, процессы в которых слаженно работают не первый год.
А бывают молодые компании и стартапы, в которых команда только набирается, а продукт разрабатывается в очень сжатые сроки. В таких командах, к сожалению, описанный вами подход - непозволительная роскошь. Там и процессы могут быть не отстроены на старте, и бизнес не готов играть по правилам разработки, а потому переобувается на ходу. В таких случаях приходится вешать картинку с идеальным циклом разработки на стену, как напоминание, к чему стремимся - но в моменте делать так, как требует текущая реальность.
Случается такое, что задача, переданная в разработку, прилетает в середине спринта (тогда она имеет риск прийти к тестировщику на анализ уже выполненной). В лучшем случае - аналитик получает бизнес-запрос, посвящает разработке требований текущий спринт (по факту, если аналитик на проекте один - то и того меньше), и к следующему спринту уже выдаёт требования, по которым ведётся разработка. Да, на ПБР и грумингах команда может ознакомиться с задачей и задать какие-то вопросы, если видит дыры. Но всё это не спасает от того, что тестировщик садится смотреть текущие задачи и находит ещё пачку вопросов к описанным требованиям.
И вот в таких условиях тестировщик участвует во всех этапах работы над задачей - и тестирует требования, и задаёт вопросы, и проверяет соответствие результата требованиям, и, собственно, проводит тестирование. Можно было бы, конечно, отругать аналитика за поверхностные требования, а разработчика - за то, что сам не проверил, работает ли его функционал, но какой в этом смысл, если бизнес ждёт фичу ещё вчера, и это не единственная ожидаемая фича?
Я очень хочу верить, что любой не загнувшийся стартап рано или поздно перестанет быть стартапом, построит стабильные процессы (и коммунизм), научит бизнес быть последовательным в хотелках и заживёт хорошо и спокойно. Но для начала этому стартапу надо "взлететь" - а это уже другая история :)
Спасибо за отличную статью!
Очень помогла освежить в памяти основной функционал Postman после полугода перерыва.
Уточнение того, что именно нужно заказчику - это работа с требованиями, так сказать, на основе печального опыта - финализировать договорённости, что мы общаемся на одном языке с заказчиком, и когда он говорит о табурете, он имеет в виду именно табурет, а не какой-то другой объект для сидения.
(Предупреждая вопрос о релизе и внезапном осознании, что заказчик хотел компьютерное кресло - такое тоже бывает. На берегу договорились об одном, но к моменту релиза бизнес осознал, что хотел совсем другого. Но это отдельная история.)
То есть, уточняя параметры изделия (табурет и его характеристики), мы определяем, какой именно табурет мы должны изготовить. А далее, из этого уже определяем неявное - для чего он нам нужен: для сидения на кухне или для исполнения цирковых номеров.
Но вообще, ваше замечание справедливо, и по-хорошему, если мы не являемся компанией, которая специализируется строго на изготовлении мебели для дома (а потому нам в принципе не могут заказать какой-то специализированный табурет с необычным функционалом), то уточнять нужно не только параметры табурета, но и его предназначение: для чего он - сидеть, стоять, жонглировать.
Спасибо за заметку!
Это неявные требования, подразумевающиеся по умолчанию.
Если у вас будет задача "Добавить в модальное окно кнопку "Закрыть"", само собой разумеющимся будет завязать на эту кнопку функционал закрытия модального окна.
Так и в данном примере - если мы разработали табурет, то ожидается, что на нём можно будет сидеть. Иначе для чего мы вообще его делали?
Я с вами полностью согласна. Всё вами сказанное справедливо и отлично отражает картину того, как должен выглядеть процесс разработки в идеале :)
Более того, я слышала о компаниях, в которых примерно так всё и происходит, и участие тестировщика в разработке ограничено именно этапом, когда хорошо проанализированная и готовая задача приходит в тест.
Но по моему опыту, такую тщательную подготовку требований и хороший анализ могут себе позволить зрелые компании, процессы в которых слаженно работают не первый год.
А бывают молодые компании и стартапы, в которых команда только набирается, а продукт разрабатывается в очень сжатые сроки. В таких командах, к сожалению, описанный вами подход - непозволительная роскошь. Там и процессы могут быть не отстроены на старте, и бизнес не готов играть по правилам разработки, а потому переобувается на ходу. В таких случаях приходится вешать картинку с идеальным циклом разработки на стену, как напоминание, к чему стремимся - но в моменте делать так, как требует текущая реальность.
Случается такое, что задача, переданная в разработку, прилетает в середине спринта (тогда она имеет риск прийти к тестировщику на анализ уже выполненной). В лучшем случае - аналитик получает бизнес-запрос, посвящает разработке требований текущий спринт (по факту, если аналитик на проекте один - то и того меньше), и к следующему спринту уже выдаёт требования, по которым ведётся разработка. Да, на ПБР и грумингах команда может ознакомиться с задачей и задать какие-то вопросы, если видит дыры. Но всё это не спасает от того, что тестировщик садится смотреть текущие задачи и находит ещё пачку вопросов к описанным требованиям.
И вот в таких условиях тестировщик участвует во всех этапах работы над задачей - и тестирует требования, и задаёт вопросы, и проверяет соответствие результата требованиям, и, собственно, проводит тестирование. Можно было бы, конечно, отругать аналитика за поверхностные требования, а разработчика - за то, что сам не проверил, работает ли его функционал, но какой в этом смысл, если бизнес ждёт фичу ещё вчера, и это не единственная ожидаемая фича?
Я очень хочу верить, что любой не загнувшийся стартап рано или поздно перестанет быть стартапом, построит стабильные процессы (и коммунизм), научит бизнес быть последовательным в хотелках и заживёт хорошо и спокойно. Но для начала этому стартапу надо "взлететь" - а это уже другая история :)