Автор статьи: Дмитрий Курдюмов
Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе зарубежом.
Все мы с вами так или иначе сталкиваемся с требованиями, когда мы что-то от кого-то хотим, когда кому-то что-то объясняем. И так или иначе, когда мы с вами доносим определенные требования, наша цель — передать полную картину, чтобы наш запрос был выполнен.
В разработке программного обеспечения или продуктов существует разные типы требований:
функциональные
нефункциональные
пользовательские
бизнес-требования
и много других.
Фокус требований в Agile
В Agile все требования рассматриваются через призму ценности для конечного пользователя. И поэтому большинство требований должны в первую очередь идти от потребностей пользователей.
Почему? Потому что наши продукты в итоге будут покупать пользователи.
(!) Но это не значит, что мы должны слепо спрашивать их, что им нужно. Вместо этого мы должны изучать их потребности и поведение.
Для того, чтобы разобраться, как изменить подход к управлению требованиями, давайте разберемся, какие основные ошибки мы допускаем в этом процессе?
Первая ошибка — идти от конкретных решений, а не от потребностей пользователей
То есть закладывать в требование сразу сформулированное решение.
Например, часто заказчики приносят требования в следующем виде:
Я хочу, чтобы вы сделали кнопку.
Я хочу, чтобы вы сделали вот этот модуль.
и многие команды просто принимают эти требования как данность, перекладывая ответственность за требования на заказчика, со словами «он лучше знает, что ему нужно».
На самом деле — нет. Как говорил Генри Форд «Если бы я спросил пользователей напрямую, что им нужно, они бы ответили — более быстрая лошадь». Так и в жизни — пользователи и заказчики часто формулируют требования в контексте решений и ошибка команды — слепо их принимать. Но заказчик чаще всего вообще не специалист в разработке продуктов, которые вы делаете. Он хочет решить свою проблему. А ваша задача — узнать, а какую проблему он хочет решить.
Какие вопросы стоит задавать заказчику, чтобы понять его истинные потребности?
К примеру, к вам приходит заказчик с просьбой сделать для него коробку для вещей. Заказчик — холостой мужчина лет 40 со стабильным заработком.
Какие вопросы бы вы ему задали?
Можно начать задавать ему сразу вопросы про критерии, размеры, прочность коробки, цвета и прочие фичи и плюшки. И побежать ее скорее делать, взяв предоплату с вашего заказчика. Что получиться в итоге? Скорее всего, разочарованный заказчик и потраченные деньги. Коробка, может, и классной получится, но решит ли она его проблему?)
Заказчик, как правило, не знает, какое решение ему нужно. Точнее, он может думать, что ему нужна коробка, а по факту он просто хочет, чтобы решилась его проблема. А к вам он обращается, чтобы вы помогли ему эту проблему решить.
Поэтому откажитесь от вопросов про характеристики, а задавайте вопросы про ценность.
Главный вопрос, который стоит задать вашему заказчику: «Зачем тебе нужна эта коробка?»
Ведь в ответе кроется суть: коробка может быть для разных целей:
Для того, чтобы убирать вещи в не сезон, например, летом убираются в коробку зимние вещи;
Для удобства сортировки вещей в шкафу;
Для того, чтобы перевезти вещи в новую квартиру.
и еще 100500 вариантов.
От этого зависит, какое решение вы будете создавать.
Например, вашему заказчику нужно убирать зимние вещи летом, чтобы освобождать место в шкафу, так как места у него не так много. Таким образом, вы знаете, какая у него задача и проблема: Задача — Иметь место для актуальных вещей в шкафу, проблема — мало места в шкафу, вещи мнутся.
Выявляйте пользовательские потребности и формулируйте Пользовательские истории
После выявления главной задачи и проблемы вы формулируете пользовательские истории, которые отражают потребности заказчика и не содержат решения и характеристик.
Например, это может быть: «Я, как холостой мужчина 40 лет, хочу убирать зимние вещи из шкафа, и тогда у меня будет место, чтобы повесить летние вещи».
И на этом этапе, когда вы узнали потребность вашего пользователя, вы можете задать ему вопросы:
А какие это вещи?
Насколько их много?
и так далее.
Далее несете это требование команде и вместе придумываете решение, которое наиболее полно решит проблему заказчика, будет дешевле для заказчика и проще для вас в реализации. И это может быть вовсе не коробка ;)
А, например, дополнительные вешалки или вообще сервис по хранению вещей вне дома с доставкой, а может, это будет и простая картонная коробка.
Спрашивайте больше «зачем», разбирайтесь в проблеме заказчика, и только потом предлагайте более простое и наилучшее решение
Вторая ошибка — писать требования в письменном виде и молча передавать в разработку, ставя задачи
В таком контексте теряется смысл, который вы закладываете в требования. Когда аналитик разбирается в том, что нужно сделать, он может в процессе анализа хорошо разобраться, что действительно нужно, но в тексте этот смысл потеряется, так как невозможно его досконально передать.
Это как с фотографиями с отпуска — одно дело, вы молча отправите их своим друзьям, а другое дело — вместе соберетесь и вы расскажете, как на самом деле все было. Для вас это не просто фотографии, в них заложен большой смысл, который остается за кадром — это атмосфера, ваши чувства, эмоции, запахи и так далее. То же самое с требованиями в разработке продукта. Когда вы передаете сухой документ — разработчики теряют смысл того, что действительно нужно сделать, и качество решений получается сильно ниже.
Итого: Уходите от детальных описаний решений, а вместо этого эти требования создавайте вместе с командой, вовлекайте команду в разработку требований и придумывания решения все вместе. Это могут быть встречи, воркшопы, мозговые штурмы или непрерывный процесс, в котором все участвуют.
Третья ошибка — описывать большой объем требований наперед
В Agile процесс разработки требования идет итеративно, в зависимости от фокуса команды в данный момент итерации. Не стоит писать детальные требования дальше чем на 1-2 итерации, так как все, скорее всего, поменяется. Не тратьте на это время. Формулируйте требования в пользовательских историях в легком формате и храните их в беклоге. А при решении о скором создании — собирайтесь и обсуждайте детали с командой, фиксируя критерии приемки.
Что такое критерии приемки?
Это детали, которые вы выясняете в процессе проработки пользовательской истории. И также это список, по которому вы будете проверять — выполнена ли пользовательская история или нет.
Например: «Я, как холостой мужчина 40 лет, хочу убирать зимние вещи из шкафа, и тогда у меня будет место, чтобы повесить летние вещи».
Критерии приемки:
Вещи сложены в специальный отсек и не мнутся
Объем вещей — 100 литров
Отсек должен быть в высоту не более 55 см
В отсеке должно быть разделение для верхней одежды
Если резюмировать, рецепт Agile-требований такой:
Не тратьте месяцы на то, чтобы описать досконально все в начале проекта, идите последовательно, формируйте более детальные требования на 1-2 итерации вперед и описывайте их в легковесном формате в виде критериев приемки.
Вместо фокуса на решении, сформулируйте основные пользовательские истории и далее в ходе разработке уточняйте их. Задавайте вопросы «Зачем», когда вам приносят готовое решение на вход, чтобы разобраться в проблеме пользователя и заказчика.
Придумывайте решение пользовательским историям вместе всей командой в ходе мозговых штурмов, встреч. Используйте доски, чтобы рисовать. Такие встречи сэкономят время и улучшат понимание контекста командой. А качество решений будет выше.
А если вам понравилась статья, жду в своем телеграмм-канале и на сайте.
Приглашаем всех желающих на открытое занятие «Бизнес для ИТ или ИТ для бизнеса?», на котором обсудим:
- Зачем компании нужен БА?
- Как БА взаимодействует с другими участниками процесса?
- Почему БА важен для успешной трансформации компании?
Регистрация доступна по ссылке.
Комментарии (7)
Myclass
12.08.2022 00:20+1Извините, но ваши слова
Но заказчик чаще всего вообще не специалист в разработке продуктов, которые вы делаете.
не верны. Как раз таки заказчик и есть тот, кто знает свои процессы или имеющие системы. Да, он может быть ничего не понимает в языках программирования или в базах данных. Но сказать — вот там хочу кнопку — что в этом может быть неправильного?
В общем вы очень пространно и поверхностно описали неимоверно сложный процесс — Requirements Managmenent. Уметь вместе с клиентом выяснять всё то, что ему нужно, за что он готов платить деньги — это целое искуство, одним-двумя пунктами это не описать так, чтобы с этим можно было практически что-нибудь делать. Поэтому вопрос — для какой аудитории была эта статья?..Заказчик, как правило, не знает, какое решение ему нужно.
Зачем такое говорить? Ага — заказчик не знает? Он не знает, а вы знаете. Да, есть моменты, когда не все детали с самого начали могут быть описаны, потому что есть нюансы с технологиями, топологией системы итд. Но заказчик приходит к вам или с идеей, или с представлением, или с конкретными требованиями. Поэтому выставлять заказчика, как что-то, что готово выложить деньги, но не знает за что — мне такое в жизни ещё за мои 35 лет в IT не попадалось.В Agile все требования рассматриваются через призму ценности для конечного пользователя.
Вы буквально две строчки до этого указали, что есть нефункциональные требования. Многие из них вообще исходят не от клиента — такие как технологии, требования к базам данных, к инструментам программирования, к самому программированию итд. Они могут быть клиенту без разницы, как и где вы сохраняете например исходный код, но их упоминание — часто есть обязанность. Это первое, а второе — не в Agile требования расматриваются не так-же?
И вообще перечислив эти типы требований — не описали ни один из этих типов. Особенно мне понравилось выражение «и много других.»
Для новичков — настолько мало, что ничего не смогут для себя почерпать. Для продвинутых — не вижу ни одной конкретной детали, которую не описали уже 100500 раз в других местах.
lxsmkv
12.08.2022 04:45+1Но сказать — вот там хочу кнопку — что в этом может быть неправильного?
На первый взгляд, да. Но если пойти дальше, то окажется, что кнопка ему нужна чтобы выполнить какую-то задачу. Так вот, нужно говорить не о кнопке, а о конечной задаче.
Допустим, кнопка ему нужна чтобы сортировать список адресов по удаленности от склада. Значит его интересует не сортировка ради сортировки, а ему нужно знать самый ближний адрес для доставки. А зачем ему знать этот адрес? Чтобы передать его доставщику. И тут слово за слово выясняется, что можно все это сделать без всякой кнопки и доставщику будет автоматически приходить самый приоритетный адрес на мобильное приложение да еще и с оповещением получателя.Дело в том что заказчик/пользователь предлагает решения в рамках своего ограниченного понимания технологий. Например на Фольксвагене исторически планирование делалось через электронные таблицы, поэтому приложения которые они заказывают часто напоминают навороченые электронные таблицы в браузере.
Можно конечно сказать, мол, ну хочет человек говна на палке, зачем его переубеждать? Но тогда клиент после работы со своим новым приложением подумает, блин, а стоило вообще слезать с экселя, ведь ничего не поменялось, только время и деньги потерял. Так все попытки цифровизация или модернизации пойдут прахом. И мне кажется, что IT-консалтинги, которые дорожат своей репутацией и гордятся своим профессионализмом, должны впрягаться в проблемы клиента, а не просто выставлять счет за человекочасы.
P.S.: У меня был знакомый у него была небольшой печатный бизнес, брошуры всякие, визитки. Он кроме этого делал и дизайн. Так вот, он рассказывал, что сперва приходил к клиенту и проводил у него какое-то время чтобы "понюхать воздух", понять его бизнес и мотивацию. Мне кажется это очень правильный подход. Иначе велик риск сделать не то что надо.
Myclass
12.08.2022 08:49+1Дело в том что заказчик/пользователь предлагает решения в рамках своего ограниченного понимания технологий. Например на Фольксвагене исторически планирование делалось через электронные таблицы, поэтому приложения которые они заказывают часто напоминают навороченые электронные таблицы в браузере.
Понимаете, что вы уртрируете? В своей жизни я постоянно обратные примеры вижу, когда заказчикам нужна простая сортировка числовой колонки, в конце концов они получат никому не нужную CRM систему, а в цене оплатят 'полёт на Марс'.
lxsmkv
12.08.2022 14:12+1в конце концов они получат никому не нужную CRM систему
Но это будет значить что мы сделали не то что нужно. А это именно тот "былинный отказ" которого мы хотим всеми силами избежать. Нет ничего плохого в кнопке для сортировке числовой колонки, и эта функция по всем канонам ремесла может быть реализована. Но контекст реализации будет не "я как пользователь хочу сортировать таблицу товаров по количеству". А например "заведующий складом должен отслеживать товары с низким резервом, чтобы вовремя их дозаказать" и в рамках этой проблемы, решением может вполне быть кнопка сортировки колонки, потому что из предложеных вариантов заказчик выбрал самый дешевый и приемлемый по удобству. Но среди предложеных вариантов может быть и добавление колонки с каким-нибудь коэффициентом тенденции расхода, что может оказаться еще удобнее, потому что приоритет в реальности зависит не только от запаса но и от тенденции к уменьшению.
Заметьте как только я описал проблему как проблему, а не как решение, мой пример с добавлением колонки родился сам собой. Это возможность для заказчика понять свой бизнес лучше, а для разработчиков возможность проанализировать как цифровые технологии могут ему в этом помочь.Конечно можно работать с командой как с роботом но тогда получится как эти нелепые виллы в стиле "хочу чтобы дорохо-бохато". Мы же фейспалмим от этого и понимаем, что такое уродство может возникнуть только в том случае если заказчик не предоставляет дизайнеру и архитектору никакой свободы действий. И можно сказать: "Ну и что? Слово клиента - закон!"
Значит надо обьяснить заказчику как работает команда. Что она не работает в режиме "пульта дистанционного управления", а работает по методологии, и заказчику будут предоставленны предусмотренные методологией рамки для выражения своих "хотелок", но он ни в коем случае не должен совать свой нос в компетенции команды иначе сотрудничество придется прекратить. (Может помните этот случай https://www.artlebedev.ru/news/2007/nokia/ ?)Конечно, если ты работаешь не по гибкой методологии, то можно просто фигачить нелепые виллы, за это тоже деньги платят, но тогда не называй это аджайлом.
lxsmkv
12.08.2022 05:10Совершенно случайно недавно стал интересоваться темой сбора требований и наткнулся на интересный часто задаваемый вопрос, мол как быть с чисто техническими требованиями. Например обновления фреймворка с версии 4.8 на версию 5.0. Пользователя это как бы не касается никак.
Но подумав я пришел к выводу, что это не так. Ведь обновляют фреймворк для чего-то. Значит разработчикам будет легче разрабатывать на нем, т.е. улучшится возможность поддержки приложения. Или например улучшится производительность. Или портируемость. Или поддержка конечных устройств. Или безопасность. Или расширяемость.
Даже если разработчиков не считать стейкхолдерами/пользователями, то приложение ведь когда-то передадут заказчику. И вдруг он, бедный, неожиданно получит новую роль - поддержка приложения. (Теперь это его проблема) И тогда модернизация фреймворка вполне себе ложится в пользовательскую историю про поддержку приложения клиентом. Это то, о чем он мог не подумать вовсе, но для этого мы и есть, профессионалы, чтобы объяснить ему, что жизненный цикл приложения установкой на целевые системы не заканчивается.По этой же самой причине, например, в ноутбуках или автомобилях предусмотрены технические возможности для облегчения ремонта и обслуживания. Пользователю оно напрямую в решении его повседневных задач (то, для чего он это покупал) не помогает. Но рано или поздно случится необходимость ремонта, и тогда наличие таких возможностей, будет влиять на стоимость и скорость ремонта, а также на возможность модернизации и продления срока службы. Т.е. эти предусмотренные чисто технические возможности превратятся в ценность (value) для покупателя.
Так что надо думать шире. И все можно очень стройно обосновать.
ViseMoD
12.08.2022 10:43+1"Технические" требования в большинстве случаев сводятся к обеспечиванию необходимого качества работы системы, которые описываются атрибутами качества. В вашем примере это может быть требование как к поддерживаемости решения, так и безопасности. Ведь более старая версия фреймворка может с одной стороны накладывать ограничения на внесения изменений в функциональность, с другой - иметь дырки, которые могут использовать злоумышленники.
RomTec
В одном списке вперемешку они выглядят не совсем уместно, т.к. из разных категорий. На примере "типов автомобилей" - легковые, грузовые, бензиновые, дизельные, отечественные, служебные и т.д.