Вкрученный гвоздь или вбитый шуруп?

Меня расстраивает, когда аналитики комментируют какие-то инструменты или термины, исходя из давности появления в индустрии или отдельного опыта в одной единственной сфере. Если аналитик подходит к решению задачи с какими-то стереотипными установками, он лишает себя и команду возможности ярких, качественных решений. Получается, что частное побеждает целое.

🔅Встретила на днях мнение "бизнес-требование – это старо и не модно". При таком подходе получается, что выбор инструмента или классификации требований зависит не от решаемой проблемы, а от предвзятой установки. Скажем, теорема Пифагора сформулирована более двух тысяч лет назад. Станет ли сумма квадратов катетов равняться чему-то новому, если мы назовем теорему старой или наоборот начнем цитировать на древнегреческом?

Не уверена шла ли речь о документе или о об уровне требований. Просто интересно наблюдать как зацикленность в отношении инструментов и терминов может повлиять на качество решения. Выбор подхода к документированию не должен диктоваться какой-то условной модой.

Есть сферы деятельности, где важен документ БТ. Например, при построении процессов в крупном промышленном производстве, где цена ошибки высока, где требуется тщательное проектирование процессов и их детальная валидация. Если же речь о бизнес-требовании как уровне информации, то его можно объявить немодным или иначе назвать, но он от этого существовать не перестанет.

🔅Встречаю мнения и в другую сторону. В чате одной уважаемой конференции недавно наблюдала дискуссию: "Детальное ТЗ гораздо лучше пользовательских историй". Тут уместен вопрос: "Для чего лучше?" Речь идет о разных инструментах, которые применяются для разных задач. Попытки подменить одно другим порождает примеры вида "Вкрученный гвоздь держался хуже, чем вбитый шуруп".

ТЗ может быть необходимо, если задача требует предварительного детального проектирования, а в основе лежат правила, которые редко меняются. Сложно представить себе историю: "Я, как пассажир самолета, хочу, чтобы он летел" 🤷‍♀️

Пользовательская история пригодится, если нужно верхнеуровнево зафиксировать ожидания от бизнес-приложения. В моем опыте была когда-то такая задача. Требовалась информация для предварительной оценки затрат на разработку нового приложения. Решение о разработке нужно было принять за 2-3 дня. В итоге за две большие встречи с заказчиками собрали карту историй. По этой карте была дана предварительная оценка. Для разработки приложения такой подход не годится, а для первых оценок этого оказалось вполне достаточно. Причем я не возьмусь утверждать, что это был единственно возможный вариант решения такой задачи.


Я это к тому, что аналитику важно уметь поставить под сомнение расхожие мнения и собственные предубеждения, а руководствоваться в первую очередь особенностями конкретной задачи. Чем больше разных инструментов вы научитесь использовать в разном контексте, тем больше разных задач сможете быстро решать. Иначе работа может превратиться в попытки подладить задачу под инструмент.


В дополнение делюсь списком книг, которые помогут развить критическое мышление. Некоторые принесла с тренинга по решению проблем (problem solving) и сама еще не читала ☺️
📍"Шум. Несовершенство человеческих суждений", Даниэль Канеман, Оливье Сибони, Касс Р. Санстейн, 2021
📍"Метод McKinsey. Использование техник ведущих стратегических консультантов для решения личных и деловых задач", Итан Расиел, 2012 (есть обзор)
📍"Думай медленно...Решай быстро", Даниэль Канеман, 2011
📍"Решение проблем по методикам спецслужб. 14 мощных инструментов", Джонс Морган, 1998
📍"Искусство системного мышления. Необходимые знания о системах и творческом подходе к решению проблем", Джозеф О'Коннор, Иан Макдермотт, 1997

#мысливслух