Так сложилось, что последнее время я много занимаюсь работой с требованиями к продукту от «внутреннего заказчика», в том числе от коллег из различных подразделений и технических команд (внутри компании). И ко мне постоянно приходят люди с тем, чтобы наша команда реализовала те или иные фичи, что-то переделали, добавили, убрали.
В данной статье я хочу рассказать, как можно со всем этим входящим хаосом работать.
Статья написана по мотивам практики работы, и не предполагает охватить всю тему управления проектами, требованиями, командами, качеством последующей реализации требований разработчиками, тему анализа результатов внедрения и т.д.
А охватывает только небольшую узкую часть между «хотелками» и «реализацией», которая именно про сами требования: к нам влетают произвольные хотелки/требования/пожелания/проблемы и т.д., а мы с ними работаем и на выходе получаем то, что пригодно для разработки.
Когда кто-то приходит с проблемой, требованием, идеей новой фичи и т.д. то далеко не всегда приносит нам это в готовом виде, пригодном для реализации. Как правило это или какой-то “космос” — что-то очень большое, выбивающееся, нереалистичное, требующее переделать всё полностью для решения небольшой проблемы, актуальность которой неизвестна. Или просто “сырое”, непонятное, неконкретное требование.
Например, человек предлагает добавить новую фичу. И сделать это таким-то способом, предлагая какую-то техническую реализацию. При этом не зная как что устроено и как что можно реализовать. Очевидно, что нельзя просто брать как есть такие требования и реализовывать. Если бы так делали, то мир давно бы погрузился в хаос и мрак преисподней.
Чтобы хаос и мрак преисподней немного отодвинуть, нам нужно понять, что стоит за этими идеями и предложениями. Какую задачу пришедший к вам человек реально хочет решить, какую проблему закрыть?
Далеко не всегда это понятно и очевидно сразу. Часто приходится продираться, по многу раз задавая одни и те же вопросы. Или разные вопросы. Пока наконец не станет понятно, что не так по сути, по существу вопроса, и как в понимании человека должно быть “так”. И это понимание, как правило, очень сильно отличается от первоначальной формулировки задачи/проблемы. Но не получив его, невозможно перейти к следующим шагам и удовлетворить потребность.
Понять, что человеку на самом деле нужно, — целое искусство, которому посвящают целые притчи (например “Владимир Тарасов — Приблизиться к оленю”), книжки (например “Роб Фитцпатрик — Спроси маму”) и практические интенсивы (например по кастомер девелопменту).
В этом конкретном моменте работа с внутренним заказчиком не особо отличается от работы с внешним.
Когда всё так просто, то остаётся только дать человеку инструкцию, как получить нужный ему результат используя уже имеющиеся возможности.
Готово.
Часто бывает, что требования похожи, различаются только нюансами (потенциальной) настройки или примерно об одном и том же, но немного разными словами. Такие требования можно объединить, чтобы понять, сколько и в каких местах гибкость нужна (или потребуется в будущем), а где не нужна. Какие основные функции? Чтобы один раз сделать одну систему или кусок функционала, которая удовлетворит все эти потребности разом. Возможно, с разными настройками или вариациями, но не нужно будет под каждую потребность отдельно делать то же самое несколько раз.
Соответственно, вырисовывается некая единая система отправки писем. В которую задачи могут поступать из разных систем. А если все вышеперечисленные события (с которыми пришли к нам желающие отправлять письма) происходят внутри одной системы, то ещё лучше: значит, систему можно сделать ещё единообразнее и проще.
Если же мы не работаем с поступающими требованиями таким образом, а они в сыром виде поступают сразу в разработку — то через какое-то время мы найдём свою систему с несколькими разными отправщиками писем, каждый из которых работает по своей логике, имеет свою особую реализацию, настройки, функции. И чтобы во всех трёх поменять маленький кусок логики, или добавить в один из этих отправщиков функцию из другого, нужно или копипастить код, или переписать довольно большую часть и рефакторить уже после внедрения и эксплуатации. Хотя, в принципе, заранее можно было бы понять, что так всё и будет.
Бывает, что какие-то конкретные два или более требования противоречат друг другу. Иногда “совсем”, что никак нельзя совместить. Иногда всё-таки можно предусмотреть “разные режимы”, в каждом из которых одно требование удовлетворяется, а другое при этом оказывается недоступно. Или решить какую-то из задач другим способом — тогда противоречие исчезнет.
Чтобы продвинуться в сторону решения, нужно начать разматывать цепочку “для чего / почему”. По каждому из требований (как было описано в первой части статьи). То есть мы должны понять как можно глубже, из чего возникли именно такие требования, и что люди, пришедшие с этими требованиями, хотят “на самом деле”.
Тогда у нас появляется возможность или найти другие варианты решения этих “реальных задач”, или понять, как можно совместить эти противоречивые требования.
Например, если одно требование по факту нужно только в каких-то конкретных узких условиях, а другое в других конкретных узких условиях. Тогда оказывается, что они и не пересекаются. Или ту задачу, для решения которой придумали такое-то требование, — можно решить совсем другим способом, возможно, даже более простым и эффективным. И тогда одно из требований исчезает (или превращается в совсем другое — которое никак не связано со вторым), а второе остаётся. И противоречия уже нет.
Или понять: эти требования никак не могут быть совмещены, и нужно выбрать какое-то одно. Но, к счастью, это всё-таки бывает достаточно редко.
Всё это возможно потому, что практически каждую задачу можно решить несколькими способами. А если мы от конкретной исходной, сырой, возможно, полу-технической формулировки поднимаемся всё выше и выше в понимании того, что за задача в принципе стоит, — то вариантов решения становится всё больше и больше. В том числе и не-технические варианты решения (уровня настроек, процессные, организационные и т.д.). А чем шире выбор вариантов, тем проще подобрать два варианта решения двух задач, которые никак друг другу не мешают, а даже, может, и помогают, если получится.
Идея в том, что первоначально все разнородные требования из всех источников должны сливаться в некую единую кучу, в некий единый котёл. После чего можно их оттуда разбирать, анализировать на предмет вышеописанных вариантов — “повторяющихся” или “противоречивых”, чтобы на выходе выдать уже подготовленные: неповторяющиеся и непротиворечивые требования, которые можно “брать и делать” в правильном порядке.
То есть, идея в том, чтобы взглянуть на всю картину целиком. На всё, что есть сейчас и что хотят добавить, изменить. И исходя из этой цельной картины уже решить: что, как и когда делать.
В таком контексте, все входящие требования — это сырьё для того, чтобы на выходе получить готовые к разработке задачи. Причём, задачи на выходе далеко не всегда будут один-к-одному совпадать с какой-то входящей потребностью. Одна задача может удовлетворять сразу несколько потребностей или закрывать целый класс требований. Или быть только частью какой-то большой истории.
Вот так входящий хаос превращается в красивый, полезный, и понятный для разработчиков набор задач и функций вашей системы, которая радует ваших коллег.
В данной статье я хочу рассказать, как можно со всем этим входящим хаосом работать.
Статья написана по мотивам практики работы, и не предполагает охватить всю тему управления проектами, требованиями, командами, качеством последующей реализации требований разработчиками, тему анализа результатов внедрения и т.д.
А охватывает только небольшую узкую часть между «хотелками» и «реализацией», которая именно про сами требования: к нам влетают произвольные хотелки/требования/пожелания/проблемы и т.д., а мы с ними работаем и на выходе получаем то, что пригодно для разработки.
Выяснение реальной проблемы
Когда кто-то приходит с проблемой, требованием, идеей новой фичи и т.д. то далеко не всегда приносит нам это в готовом виде, пригодном для реализации. Как правило это или какой-то “космос” — что-то очень большое, выбивающееся, нереалистичное, требующее переделать всё полностью для решения небольшой проблемы, актуальность которой неизвестна. Или просто “сырое”, непонятное, неконкретное требование.
Например, человек предлагает добавить новую фичу. И сделать это таким-то способом, предлагая какую-то техническую реализацию. При этом не зная как что устроено и как что можно реализовать. Очевидно, что нельзя просто брать как есть такие требования и реализовывать. Если бы так делали, то мир давно бы погрузился в хаос и мрак преисподней.
Чтобы хаос и мрак преисподней немного отодвинуть, нам нужно понять, что стоит за этими идеями и предложениями. Какую задачу пришедший к вам человек реально хочет решить, какую проблему закрыть?
Далеко не всегда это понятно и очевидно сразу. Часто приходится продираться, по многу раз задавая одни и те же вопросы. Или разные вопросы. Пока наконец не станет понятно, что не так по сути, по существу вопроса, и как в понимании человека должно быть “так”. И это понимание, как правило, очень сильно отличается от первоначальной формулировки задачи/проблемы. Но не получив его, невозможно перейти к следующим шагам и удовлетворить потребность.
Понять, что человеку на самом деле нужно, — целое искусство, которому посвящают целые притчи (например “Владимир Тарасов — Приблизиться к оленю”), книжки (например “Роб Фитцпатрик — Спроси маму”) и практические интенсивы (например по кастомер девелопменту).
Тут нужно заметить, что ситуация, когда кто-то приходит со странными, непонятными, криво сформулированными или, с вашей точки зрения, некорректными требованиями, — нормальная. Для людей в целом естественно, что они чего-то хотят, но не всегда могут точно и правильно сформулировать, что они хотят. Люди, как правило, именно такие — это естественно. То есть дело не в том, что кто-то неправильный, а в том, как вы умеете работать с такой ситуацией.Старая байка про покупателя дрели
Приходит мужик в магазин и покупает там дрель. Но на самом деле ему нужна не дрель, ему нужна дырка в стене, которую он хочет просверлить. Поэтому он покупает дрель.
Но и это не всё. Дырка не нужна сама по себе. Она нужна, чтобы повесить большую красивую картину в тяжёлой раме. А картину этот герой хочет повесить, чтобы угодить тёще, которая давно просила его повесить картину, а он всё не делал этого.
Вот нам кажется, что мы уже нашли коренную проблему. Ан нет.
На самом деле, через день будет футбольный матч, который наш герой очень хочет посмотреть. И чтобы у тёщи не было поводов ему мешать, он организовал себе повод иметь право смотреть футбол — сделал то, что его давно просили — повесил картину.
То есть покупая дрель, он на самом деле хотел спокойно посмотреть футбол.
В этом конкретном моменте работа с внутренним заказчиком не особо отличается от работы с внешним.
Требования по фичам, которые уже есть
Самый простой случай, когда выясняется, что то, что человек хочет, — у нас уже есть. Возможно, не совсем в том виде, как человек ожидал, предполагал, представлял себе. Просто или человек не знает о том, что оно есть, или не умеет пользоваться, или у него неверная информация о том, как это работает. Или просто нужно что-то донастроить / включить, чтобы получить то, что нужно.Байка про шпиона.
Отправили как-то шпиона в один город узнать, где находится патронный завод. В помощь дали информацию, что в городе есть церковь, и если от неё пройти по улице прямо и налево — то где-то в той стороне и будет завод.
Вот приезжает шпион в город. Встречает бабку и спрашивает:
— скажи, а как к церкви пройти?
— а вот видишь патронный завод? От него иди прямо и потом направо. Там и будет церковь.
Когда всё так просто, то остаётся только дать человеку инструкцию, как получить нужный ему результат используя уже имеющиеся возможности.
Готово.
Повторяющиеся требования
Часто бывает, что требования похожи, различаются только нюансами (потенциальной) настройки или примерно об одном и том же, но немного разными словами. Такие требования можно объединить, чтобы понять, сколько и в каких местах гибкость нужна (или потребуется в будущем), а где не нужна. Какие основные функции? Чтобы один раз сделать одну систему или кусок функционала, которая удовлетворит все эти потребности разом. Возможно, с разными настройками или вариациями, но не нужно будет под каждую потребность отдельно делать то же самое несколько раз.
Тут очевидно, что во всех случаях нужна система отправки писем, а сами задачи на отправку поступают из разных мест при разных обстоятельствах.Пример:
К вам приходят (как правило независимо друг от друга и в разное время) представители нескольких разных отделов и говорят, что одному нужно отправлять отчёты на емэйлы клиентам из списка, другому — уведомления на определённый круг адресов о том, что какие-то технические системы не работают. Третий приходит и хочет, чтобы по результатам такой-то обработки клиентских данных, клиенту отправлялось письмо с результатами обработки.
Соответственно, вырисовывается некая единая система отправки писем. В которую задачи могут поступать из разных систем. А если все вышеперечисленные события (с которыми пришли к нам желающие отправлять письма) происходят внутри одной системы, то ещё лучше: значит, систему можно сделать ещё единообразнее и проще.
Если же мы не работаем с поступающими требованиями таким образом, а они в сыром виде поступают сразу в разработку — то через какое-то время мы найдём свою систему с несколькими разными отправщиками писем, каждый из которых работает по своей логике, имеет свою особую реализацию, настройки, функции. И чтобы во всех трёх поменять маленький кусок логики, или добавить в один из этих отправщиков функцию из другого, нужно или копипастить код, или переписать довольно большую часть и рефакторить уже после внедрения и эксплуатации. Хотя, в принципе, заранее можно было бы понять, что так всё и будет.
Противоречивые требования
Бывает, что какие-то конкретные два или более требования противоречат друг другу. Иногда “совсем”, что никак нельзя совместить. Иногда всё-таки можно предусмотреть “разные режимы”, в каждом из которых одно требование удовлетворяется, а другое при этом оказывается недоступно. Или решить какую-то из задач другим способом — тогда противоречие исчезнет.
Чтобы продвинуться в сторону решения, нужно начать разматывать цепочку “для чего / почему”. По каждому из требований (как было описано в первой части статьи). То есть мы должны понять как можно глубже, из чего возникли именно такие требования, и что люди, пришедшие с этими требованиями, хотят “на самом деле”.
Тогда у нас появляется возможность или найти другие варианты решения этих “реальных задач”, или понять, как можно совместить эти противоречивые требования.
Например, если одно требование по факту нужно только в каких-то конкретных узких условиях, а другое в других конкретных узких условиях. Тогда оказывается, что они и не пересекаются. Или ту задачу, для решения которой придумали такое-то требование, — можно решить совсем другим способом, возможно, даже более простым и эффективным. И тогда одно из требований исчезает (или превращается в совсем другое — которое никак не связано со вторым), а второе остаётся. И противоречия уже нет.
Или понять: эти требования никак не могут быть совмещены, и нужно выбрать какое-то одно. Но, к счастью, это всё-таки бывает достаточно редко.
Всё это возможно потому, что практически каждую задачу можно решить несколькими способами. А если мы от конкретной исходной, сырой, возможно, полу-технической формулировки поднимаемся всё выше и выше в понимании того, что за задача в принципе стоит, — то вариантов решения становится всё больше и больше. В том числе и не-технические варианты решения (уровня настроек, процессные, организационные и т.д.). А чем шире выбор вариантов, тем проще подобрать два варианта решения двух задач, которые никак друг другу не мешают, а даже, может, и помогают, если получится.
Котёл требований
Идея в том, что первоначально все разнородные требования из всех источников должны сливаться в некую единую кучу, в некий единый котёл. После чего можно их оттуда разбирать, анализировать на предмет вышеописанных вариантов — “повторяющихся” или “противоречивых”, чтобы на выходе выдать уже подготовленные: неповторяющиеся и непротиворечивые требования, которые можно “брать и делать” в правильном порядке.
То есть, идея в том, чтобы взглянуть на всю картину целиком. На всё, что есть сейчас и что хотят добавить, изменить. И исходя из этой цельной картины уже решить: что, как и когда делать.
В таком контексте, все входящие требования — это сырьё для того, чтобы на выходе получить готовые к разработке задачи. Причём, задачи на выходе далеко не всегда будут один-к-одному совпадать с какой-то входящей потребностью. Одна задача может удовлетворять сразу несколько потребностей или закрывать целый класс требований. Или быть только частью какой-то большой истории.
Итог
Вот так входящий хаос превращается в красивый, полезный, и понятный для разработчиков набор задач и функций вашей системы, которая радует ваших коллег.
