Так получилось, что в последнее время я много работаю с требованиями к продукту от «внутреннего заказчика», в том числе от коллег из различных отделов и технических команд (внутри компании).
И ко мне постоянно приходят люди с просьбой к нашей команде реализовать те или иные фичи, что-то переделать, что-то добавить, что-то убрать.
В этой статье я хочу рассказать вам, как можно работать со всем этим набегающим хаосом.
Статья написана исходя из практики работы, и не преследует цели охватить всю тему управления проектами, требованиями, командами, качество последующей реализации требований разработчиками, тему анализа результатов внедрения и т.д. И оно охватывает лишь небольшую узкую часть между «хочет» и «реализация», которая касается как раз самих требований: произвольные желания/требования/пожелания/проблемы и т. д. летят к нам, и мы работаем с ними и в конце концов мы получите то, что подходит для развития.
Выясняем настоящую проблему
Когда кто-то приходит с проблемой, требованием, идеей новой функции и т. д., он не всегда доносит ее до нас в готовом виде, пригодном для реализации.Как правило, это либо какой-то «космос» — что-то очень большое, нестандартное, нереальное, требующее полной переделки всего для решения небольшой проблемы, актуальность которой неизвестна.
Или просто «сырое», непонятное, неконкретное требование.
Например, человек предлагает добавить новую функцию.
И сделать это так-то, предлагая какую-то техническую реализацию.
При этом не зная, как все работает и как это можно реализовать.
Очевидно, что нельзя просто взять такие требования такими, какие они есть, и реализовать их.
Если бы они сделали это, мир давно бы погрузился в хаос и тьму подземного мира.
Чтобы хоть немного отодвинуть хаос и тьму преступного мира, нам необходимо понять, что стоит за этими идеями и предложениями.
Какую проблему действительно хочет решить пришедший к вам человек, какую проблему решить? 
Это не всегда сразу ясно и очевидно.
Часто вам приходится задавать одни и те же вопросы снова и снова.
Или разные вопросы.
Пока наконец не станет ясно, что не так по сути, по сути вопроса, и как в понимании человека должно быть «так».
И это понимание, как правило, сильно отличается от первоначальной формулировки задачи/проблемы.
Но не получив его, невозможно перейти к следующим шагам и удовлетворить потребность.
Понять, что человек Фактически нужно целое искусство, которому посвящены целые притчи (например, «Владимир Тарасов - Приближаясь к оленю»), книги (например, «Роб Фицпатрик - Спроси маму») и практические интенсивы (например , по заказной разработке).
Здесь следует отметить, что ситуация, когда кто-то приходит со странными, непонятными, криво сформулированными или, с вашей точки зрения, неверными требованиями – нормальный .Старая история о покупателе дрели
Мужчина приходит в магазин и покупает там дрель.Но на самом деле ему не нужна дрель, ему нужна дыра в стене, которую он хочет просверлить.
Поэтому он покупает дрель.
Но это не все.
Само отверстие не нужно.
Необходимо повесить большую красивую картину в тяжелую раму.
И этот герой хочет повесить картину, чтобы порадовать тещу, которая давно просила его повесить картину, но он до сих пор этого не сделал.
Нам кажется, что мы уже нашли корень проблемы.
Но нет. Ведь через день состоится футбольный матч, который очень хочет посмотреть наш герой.
А чтобы у тещи не было повода его беспокоить, он организовал себе повод иметь право смотреть футбол - сделал то, что его давно просили - повесил картину.
То есть, когда он купил дрель, он вообще-то хотел спокойно смотреть футбол.
Для людей вообще естественно, что они чего-то хотят, но они не всегда могут точно и правильно сформулировать то, что хотят. Люди, как правило, именно такие – это естественно.
То есть дело не в том, что кто-то неправ, а в том, как вы умеете работать с такой ситуацией.
В этом конкретном моменте работа с внутренним заказчиком мало чем отличается от работы с внешним.
Требования к уже существующим функциям
Самый простой случай — когда оказывается, что то, что хочет человек, у нас уже есть.История о шпионе.
Однажды в один город отправили шпиона, чтобы узнать, где находится патронный завод. В помощь дали информацию, что в городе есть церковь, и если идти прямо по улице и налево, то где-то в том направлении будет завод. В город приезжает шпион.
Он встречает бабушку и спрашивает: - Скажите, как пройти к церкви? - Вы видите патронный завод? Идите прямо от него, а затем направо.
Там будет церковь.
Возможно, не совсем так, как человек ожидал, предполагал, представлял.
Просто человек либо не знает, что оно существует, либо не знает, как им пользоваться, либо у него неверная информация о том, как оно работает. Или вам просто нужно что-то настроить/включить, чтобы получить то, что вам нужно.
Когда все так просто, остается только дать человеку инструкции, как получить нужный ему результат, используя имеющиеся возможности.
Готовый.
Регулярные требования
Часто бывает, что требования схожи, различаются лишь нюансами (потенциальной) конфигурации, или примерно об одном и том же, но немного разными словами.Такие требования можно объединить, чтобы понять, насколько и где гибкость нужна (или понадобится в будущем), а где она не нужна.
Каковы основные функции? Сделать однажды одну систему или часть функционала, которая будет удовлетворять все эти потребности сразу.
Возможно, с разными настройками или вариациями, но вам не нужно будет делать одно и то же несколько раз для каждой потребности отдельно.
Здесь очевидно, что во всех случаях необходима система отправки писем, а сами задачи отправки приходят из разных мест и при разных обстоятельствах.Пример:
К вам приходят представители нескольких разных отделов (обычно независимо друг от друга и в разное время) и говорят, что одному нужно отправлять отчеты по электронной почте клиентам по списку, другому нужны уведомления на определенный круг адресов о том, что какие-то технические системы не работают. не работает. работают. Приходит третий и хочет, чтобы по результатам такой-то обработки клиентских данных клиенту было отправлено письмо с результатами обработки.
Соответственно, складывается некая единая система отправки писем.
В котором задачи могут приходить из разных систем.
А если все вышеперечисленные события (с которыми к нам пришли желающие отправить письма) происходят внутри одной системы, то даже лучше: значит, систему можно сделать еще более единообразной и простой.
Если мы не будем работать с входящими требованиями таким образом, а сразу пойдем в разработку в сыром виде, то через какое-то время мы обнаружим собственную систему с несколькими разными отправителями писем, каждый из которых работает по своей логике, имеет своя особенная реализация, настройки, функции.
И чтобы изменить небольшой кусочек логики во всех трёх, или добавить в один из этих отправителей функцию от другого, нужно либо копипастить код, либо переписать достаточно большую часть и провести её рефакторинг после реализации и эксплуатации.
Хотя, в принципе, можно было заранее понять, что так и будет.
Противоречивые требования
Бывает, что какие-то конкретные два или более требований противоречат друг другу.Иногда «совсем», которые никак нельзя совместить.
Иногда все же можно предусмотреть «разные режимы», в каждом из которых одно требование удовлетворяется, а другое отсутствует. Или решить одну из задач по-другому – тогда противоречие исчезнет. Чтобы двигаться к решению, нужно начать раскручивать цепочку «почему/почему».
По каждому из требований (как описано в первой части статьи).
То есть мы должны как можно глубже понять, откуда именно возникли такие требования, и чего «на самом деле» хотят люди, пришедшие с этими требованиями.
Тогда у нас есть возможность либо найти другие варианты решения этих «реальных проблем», либо понять, как можно совместить эти противоречивые требования.
Например, если одно требование действительно необходимо только в каких-то конкретных узких условиях, а другое — в других конкретных узких условиях.
Тогда окажется, что они не пересекаются.
Либо проблему, для которой было придумано такое-то требование, можно решить совсем другим способом, возможно, даже более простым и эффективным.
И тогда одно из требований исчезает (или превращается во что-то совершенно иное - никак не связанное со вторым), а второе остается.
И противоречия больше нет. Или поймите: эти требования никак нельзя совместить, и нужно выбрать одно.
Но, к счастью, это все равно случается довольно редко.
Все это возможно, потому что практически каждую проблему можно решить несколькими способами.
А если от конкретной исходной, грубой, возможно, полутехнической формулировки подниматься все выше и выше в понимании того, в чем состоит проблема в принципе, то вариантов решения становится все больше.
Включая нетехнические варианты решения (уровень настроек, процессный, организационный и т.д.).
И чем шире выбор вариантов, тем легче выбрать два варианта решения двух задач, которые никак не мешают друг другу, а могут даже помочь, если это возможно.
Котел требований
Идея в том, что изначально все разнородные требования из всех источников должны слиться в одну кучу, в единый котел.После чего их оттуда можно разобрать, проанализировать по вышеописанным вариантам – «повторяющиеся» или «противоречивые», чтобы на выходе уже подготовленные: неповторяющиеся и непротиворечивые требования, которые можно «взять и сделать» в правильный заказ.
То есть идея состоит в том, чтобы посмотреть на картину целиком.
За все, что есть сейчас и что хотят добавить или изменить.
И исходя из всей этой картины решать, что, как и когда делать.
В этом контексте все входящие требования являются сырьем для того, чтобы на выходе получить готовые к разработке задачи.
При этом выходные задачи не всегда будут однозначно совпадать с какой-либо входящей потребностью.
Одна задача может удовлетворять сразу несколько потребностей или охватывать целый класс требований.
Или просто станьте частью какой-то большой истории.
Нижняя граница
Так наступающий хаос превращается в красивый, полезный и удобный для разработчиков набор задач и функций вашей системы, который радует ваших коллег.Теги: #управление продуктом #продукт #требования к программному обеспечению #системные требования #требования клиентов #корпорации #внутренние продукты #внутренние продукты #внутренние проекты #внутренние коммуникации #коммуникации с клиентами #коммуникации эффективные коммуникации #Управление разработкой #Управление проектами #Управление продуктом
-
`Секретный Ключ К Интернету!"
19 Oct, 24 -
Рубиновый Подкаст Noname S04E10
19 Oct, 24 -
Рекомендации По Созданию Презентаций
19 Oct, 24 -
Будильники
19 Oct, 24
