Общение аналитика с бизнесом обычно происходит через призму сбора требований – сначала аналитики собирают требования, потом передают их в разработку и в конце сдают уже готовую разработку по этим требованиям. В рамках доклада мы обсудим:
-
Как собирать требования.
-
Как их квалифицировать и ранжировать.
-
Где фиксировать требования.
-
Как передавать требования разработчику, и что при этом от разработчика нужно получить.
-
И как сдать уже готовую разработку бизнесу – понять, что требования исполнены, и работа с ними закончена.
Начнем с терминологии – что такое требование?
Когда жена говорит мужу: «Купи мне шубу», это требование – точнее, это некая просьба, которая подразумевает обязательное выполнение.
У бизнеса тоже есть требования, они так и называются – бизнес-требования. Это такие же просьбы, но без выполнения которых бизнес не может функционировать или его функционирование затруднено. К примеру, директор фирмы говорит: «Я хочу, чтобы мои сотрудники не опаздывали на работу» – это бизнес-требование. Если сотрудник не вышел на работу, или он опоздал, то функционирование фирмы затруднено или вообще невозможно.
Причем следует разделять потребности и требования. Потребность бизнеса – это цель или идея, для выполнения которой нужно выполнить действия. В нашем примере потребность бизнеса – в стабильном выходе сотрудников на работу для обеспечения максимальной прибыли организации, а требование – сформулированное желание владельца процесса.
Нам как аналитикам нужно не любое бизнес-требование, потому что мы не любое бизнес-требование можем исполнить. Нам нужно выявлять такие требования, которые можно переложить на программу и автоматизировать.
Допустим, программа не может заставить людей приходить на работу вовремя. Но мы можем предложить фиксировать время прихода на работу и выдавать статистику: когда пришел/ушел, сколько отработал и так далее. Это бизнес-требование вполне укладывается в задачу для автоматизации.
Можно задействовать специальную аппаратуру для фиксирования времени прихода на работу и различного рода таймбуки – решения, которые встроены в систему на проходной и передают данные о том, когда человек пришел на работу, сразу в 1С:ЗУП.
С такими бизнес-требованиями мы можем работать. И при общении с бизнесом мы всегда должны рассматривать любое требование с точки зрения того, можно ли его исполнение автоматизировать.
Источники требований
Условно появление требований можно разделить на два вида:
-
Требования к аналитику внутри компании. Это когда руководители компании собрали совещание и решили продавать товары через маркетплейс. Приходят к аналитику и спрашивают: «Что нам нужно в части автоматизации, чтобы продавать на маркетплейсах?»
-
Проектные требования. Это когда аналитик приезжает в компанию в рамках проекта и начинает собирать требования, причем там руководители могут даже не задумываться, что им нужно. В этом случае требования буквально приходится добывать или помогать формулировать в таком виде, с которым можно будет работать при автоматизации.
Методы сбора требований
Какие есть способы получения требований? Я бы выделил четыре самых популярных:
-
Анкетирование. Этот способ имеет смысл использовать, когда нужно опросить большое количество человек. Вместо длительных личных бесед мы разрабатываем анкету и отправляем ее на заполнение. Затем обрабатываем полученную информацию и фиксируем требования.
-
Прототипирование. Этот способ может использовать, например, продавец программного обеспечения. Он приходит к директору некоего бизнеса и показывает прототип приложения для торговых представителей – в нем удобно работать, вводить заявки и так далее. В этом случае мы отталкиваемся от прототипа, собираем по нему требования – что удобно, что неудобно.
-
Интервьюирование. Это мой самый любимый вариант – здесь мы общаемся непосредственно с пользователем и в процессе узнаем, как он работает в текущей программе, есть ли какая-то автоматизация, есть ли планирование, что не устраивает и т.д.
-
И как частное от интервью можно выделить пользовательские истории. Собирая пользовательскую историю, мы разговариваем с пользователем с точки зрения программы – спрашиваем, что он вносит в программу, что от нее ожидает. Но этот способ не всегда подходит, потому что если программа достаточно глубоко автоматизирована, пользователь даже не знает, что как она работает.
Важно при сборе требований
При сборе требований особенно важно:
-
Определить ключевого специалиста. Иногда нам выделяют специалиста, но он оператор – ему дают какие-то документы, он вносит их в систему. Куда дальше идет эта информация, для чего – он может и не знать. В таких случаях надо требовать, чтобы вам дали более компетентного сотрудника.
-
Выяснить суть процесса. Когда нам высказывают какие-то бизнес-требования, нам нужно учитывать, что за ними может скрываться множество «подводных камней». Поэтому первое, что мы должны спросить «Зачем все это нужно». Если не могут объяснить, просить дать специалиста, компетентного в этом вопросе.
-
Зафиксировать информацию. Сейчас очень много вариантов записи информации – диктофоны, видео на телефоне. Все записываем и потом прослушиваем, просматриваем и фиксируем требования.
Регистрация требований
Для фиксирования требований есть специальные программы.
-
Excel – самое очевидное. Создаем в Excel реестр и указываем в нем все требования. Минусы инструмента: требования получаются «плоские»: одна строчка – одно требование. Но для небольших проектов это подходит, да и Google-таблицы нам в помощь.
-
Jira – самая известная и топовая программа по управлению требованиями. Но у нее тоже есть минус – она дороговата для внедрения, поэтому не все ее используют.
-
Redmine. Тоже хорошая программа с теми же принципами, что и Jira. Кроме того, она бесплатная. У меня были проекты, где мы вели требования на Redmine.
-
Решения 1С – например, можно вести требования в 1С:Документооборот или разработать собственное решение под требования компании. И даже интегрировать его с Redmine или с Jira.
Примеры
На слайде – пример реестра в Google-таблице. Обычно мы используем такой реестр, когда сдаем работы – когда у нас большой объем информации и каждую таску заводить некогда.
В табличном виде с требованиями удобно проводить первичную обработку – квалифицировать, ставить приоритеты и так далее.
Это Jira. Слева – отдельный таск, справа – канбан-доска. На такой доске удобно просматривать задачи – видеть узкие места, где они скопились, чтобы потом их разобрать.
Это Redmine. Суть та же, что и в Jira: есть отдельные задачки, и есть общий список, где задачи можно фильтровать.
А здесь показано, как выглядит карточка задачи в нашей разработке на 1С – можно указать тему задачи и ее описание, описать разработчику, что нужно сделать. Можно поставить MVP. И удобно фильтровать по статусу, исполнителю, приоритету и так далее.
Риски и работа с ними
При сборе требований мы сталкиваемся с очень большими рисками:
-
Риск разработать не тот продукт, неправильно считать требования заказчика. Чтобы этого избежать, нужно:
-
составить протокол интервью, куда досконально собрать все требования;
-
донести список требований ответственным лицам и получить ответ, что они их поняли и приняли. На больших проектах это делать обязательно – так у вас будут доказательства, что вы все сделали согласно требованиям.
-
-
Риск изменения требований. Все меняется, предприятия не стоят на месте, появляются новые идеи и запросы. Требования, которые были актуальны сегодня, через полгода могут измениться на 50 процентов. Такими рисками надо управлять:
-
на каждый этап стоит первоначально составить рамочный договор, где описать весь планируемый объем работы;
-
и для каждого изменения оценивать и подписывать допсоглашения с описанием и оценкой работ по каждому этапу.
-
Квалификация требований
При сборе требований важно записывать и отражать все по-максимуму. Затем нужно определить бизнес-требования, которые мы можем автоматизировать, квалифицировать их и ранжировать – например, разбить бизнес-требования на функциональные и нефункциональные:
-
Функциональные. Когда вам, например, говорят, что нужно вводить некий документ, например – выписывать счет-фактуру.
-
Нефункциональные. Когда от нас требуют, что программа должна выводить счет-фактуру за 3 минуты.
В первую очередь нам важны функциональные требования. Нефункциональные требования мы тоже фиксируем, но возвращаемся к ним в последнюю очередь.
Ранжирование требований
Когда мы получили требования, нам надо их ранжировать – определить для них первый, второй, третий приоритет и т. д.
Это нужно для того, чтобы в первую очередь создать минимально работающую систему по основным бизнес-процессам компании. Улучшения системы можно оставить на стадию доработки и стабилизации системы.
Также учитываем очередность разработки: в первую очередь делаем справочники, во вторую – документы, в третью очередь – отчеты.
На слайде пример из реальной документации, как у нас ранжируются требования.
-
На первом по приоритету месте – критичные для функциональности требования, без которых ничего не сможет работать.
-
На втором месте – требования, которые важны для запуска, но не критичны. Программа работать будет, но неудобно.
-
На третьем месте – некритичные требования. Мы их фиксируем, но можем вообще не учитывать, если они выходят за рамки проекта.
Уточнение требований
После того как мы провели первый сбор требований, проанализировали их, у нас могут возникнуть дополнительные вопросы. Тогда назначаем дополнительную встречу с заказчиком.
Что важно на этой встрече?
-
Нужна повестка. Люди должны знать, по какому вопросу мы собираемся, что будем обсуждать.
-
Модерация встречи. Следите за направлением беседы, не давайте клиентам много рассуждать на отдаленные темы.
-
Ведите протокол встречи. Фиксация договоренностей в протоколе очень важна. В моей практике были случаи когда нужно было предъявить заказчику решения по каким-либо протоколам через полтора-два года после совещания.
Техническое проектирование и передача разработчикам
Коротко коснемся технического проектирования и передачи требований разработчикам.
Мы в компании придерживаемся следующего принципа: каждую задачу по разработке нужно дробить на несколько мелких. В таком случае мы при необходимости сможем привлечь большую команду разработчиков и раздать им эти маленькие «кусочки».
Также важна коммуникация с программистами. Приучайте их отписываться вам в мессенджер о том, что они взяли задачу в работу или завершили по ней разработку. Потому что когда идет работа одновременно с несколькими разработчиками, и оповещения из Jira валятся на почту, можно пропустить письмо. Просто попросите разработчика: взял работу – отписался. Сделал разработку – сказал вам, что можно тестировать. Это элементарные коммуникации, но почему-то для многих это проблема. И это очень плохо, потому что влияет на скорость проекта.
Сдача работ заказчику
При сдаче работ заказчику, как правило, начинается: «Вы сделали не так», «Вы сделали не то», «А мы думали, что вы сделаете так».
Вот это «думали» надо сразу исключать – не надо думать, у нас вся работа выполнена согласно техническому заданию. Если есть замечания, мы их фиксируем.
Причем аналитику очень важно выделять замечания, которые являются новыми требованиями. Если вы их сразу зафиксируете и проговорите, что это новое требование и что такого не было в ТЗ, то и РП потом будет проще общаться с заказчиком, оценивать эти новые требования, и в целом проект будет идти проще. И это как раз именно аналитики могут сделать.
При сдаче работ оформляем протокол. В нем фиксируем требования, как мы планировали их реализовать и замечания заказчика. Потом эти замечания переносятся в реестр, и пошли квалифицировать «Дополнение», «Ошибка», «Новые требования» и так далее.
На слайде – пример такого кусочка протокола.
Отчеты по исполнению требований
Всегда заполняйте информацию по задаче качественно – вносите все данные. Если каких-то данных в задаче не будет, РП не увидит в отчете, на какой стадии проект, как он продвигается, у кого какая нагрузка.
Именно для отчетов мы и оформляем задачи в Jira, Redmine и т.д. И именно эти отчеты РП использует на проектном комитете, когда рассказывает заказчику о стадии проекта, времени его исполнения.
Периодичность показов разработки заказчику
Считается, что чем быстрее исполнитель покажет заказчику прототип, тем проще ему будет работать над проектом дальше. Опираясь на прототип, заказчику легче понять, как все будет работать, высказать свои замечания, обозначить новые требования.
По Agile рекомендуется показывать прототип раз в две недели.
Как понять, что требования выполнены?
В конце крупных проектов помимо сдачи работ заказчику, происходит проверка системы на прочность, которая включает в себя:
-
Функциональное тестирование – это все шаги от ввода НСИ и настройки системы, а также проверка процессов закупки, продажи, производства, планирования и т.д.
-
Интеграционное тестирование, которое проверяет наличие проблем при интеграции различных систем с сайтами, ЗУПом и т.д.
И если мы работаем в фирме-франчайзи, при сдаче работ заказчику нам важен подписанный акт, который подтверждает, что клиента все устроило.
Вопросы и ответы
Сталкиваетесь ли вы с ситуациями, когда проект уже закончен, но потом у заказчика появляются новые требования, и он снова приходит к вам с просьбой что-то усовершенствовать? Если да, то как нужно хранить информацию, чтобы быстро найти прошлые требования этого заказчика?
Все зависит от ваших договоренностей. Иногда с заказчиком работает наша клиентская поддержка, а иногда полностью передаем поддержку на команду заказчика, если у него есть свой ИТ-отдел.
Вопрос быстрого поиска информации связан с качеством оформления требований. Если все зафиксировано в Jira, найти информацию совсем несложно.
Наш собственный лайфхак: у каждого блока есть свой тимлид, к которому можно обратиться с вопросом по проекту через какое-то время, потому что он помнит требования, знает, где их посмотреть и т.д.
Также желательно всю документацию по проекту передавать заказчику – если все останется у него, всем будет удобнее.
*************
Статья написана по итогам доклада (видео, интерактив), прочитанного на конференции INFOSTART EVENT.
