Обзор методов сбора требований к ПО, или Как стать лучшим другом заказчика и старшим братом пользователей?

Меня зовут Дмитрий Летяго. В ИТ я около 6 лет. Занимался автоматизацией бизнес-процессов в «Лабиринте», автоматизировал производственные процессы в «Ростехе» и на текущий момент развиваю госсистему «Независимый регистратор». Также являюсь выпускником Школы IT-менеджмента РАНХиГС.

Последствия

Думаю, что каждый из нас в работе сталкивался с ситуацией, когда заказчик заказал у нас вроде бы велосипед, но по каким-то причинам получил мопед по цене автомобиля.

Вроде бы два колеса, руль, сиденье, едет из точки A в точку B, но что-то не то.

Успешным успехом такой исход, наверное, вряд ли назовешь, потому что ожидания не оправдались.

У такого исхода могут быть последствия.

1. Минимальные потери происходят тогда, когда заказчик в принципе забивает на ваше решение и не пользуется им. Либо когда он использует лишь 20% разработанной функциональности – грубо говоря, использует ноутбук ради калькулятора.

2. Хуже, когда это бьет по мотивации команды. Начинаются разговоры: «нас никто не ценит», «мы делаем работу зря». Это приводит к выгоранию.

В докладе про токсичных сотрудников, с которым выступала Ирина Шишкина, озвучивалось, что выгорание может привести даже к депрессии и к самоубийству. Нам такое, понятно, не нужно.

3. Если ожидания заказчика (бизнеса) оказались обманутыми, отношения портятся. Начинаются разговоры: «пришли эти айтишники, поставили свои компьютеры – только мешают работать, а толку от них нет».

4. И самый главный риск – потеря денег. Либо мы начинаем исправлять ситуацию за свой счет, либо мы в принципе разрываем наши договоры и контракты с нашими контрагентами.

А в случае с госразработкой такой исход может привести к тому, что наша компания попадет в РНП (реестр недобросовестных поставщиков) по решению ФАС России. Срок пребывания организации в РНП в среднем составляет три года.

Это значит, что компания на три года лишается целого сегмента рынка. В текущих реалиях это можно, наверное, сравнить с банкротством, если компания вовремя не перестроится и не начнет брать какие-то коммерческие проекты.

Как избежать негативных последствий?

Для минимизации рисков нужно договориться с заказчиком на берегу. Провести некоторое предобследование, изучить его проблему и уровень понимания этой проблемы самим заказчиком.

На слайде показан график зависимости подходящих решений от количества требований.

• Когда заказчик слабо понимает, чего хочет, у него уровень требований на уровне N1 – мы можем предложить ему большое количество вариантов: начиная от готовых коробочных решений и их кастомизации до заказной разработки с нуля. Более того, мы можем даже просто сказать заказчику: «Тебе не нужно IT, перепиши регламент за 2 копейки, и будет все ок».

• А если заказчик предъявляет большое количество требований, которое стремится к N3, область решений у нас сильно сужается. В этом случае без разработки с нуля ничего сделать нельзя, и по-другому его проблему не решить.

Если мы все-таки решили разрабатывать ИТ-продукт с нуля, первое, с чего должен начать работу аналитик, – это погрузиться в предметную область.

Следует обработать доступные источники требований:

1. Изучить имеющуюся документацию: различные регламенты, нормативку, инструкции и прочее.

2. Изучить информационные системы: те, что мы собираемся заменить нашим решением, и те, которые будут с ним взаимодействовать. Кроме этого, конечно же, изучить рынок и аналоги, ведь наверняка эту проблему уже кто-то решал, и не такая уж она и уникальная;

3. И самый главный источник требований – это заинтересованные стороны, люди.

Дальше в докладе мы рассмотрим, как работать с заинтересованными сторонами, и какие для этого есть методы.

Идеальный представитель заинтересованной стороны

Как аналитику понять, с кем из заинтересованных сторон будет наиболее комфортно и эффективно работать?

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

• Когда мы приходим в автошколу, мы не обладаем ни знаниями, ни навыками. Мы – новички, и относимся к 1-му уровню.

• Затем мы обучаемся, получаем теоретические знания, но у нас еще нет навыков, кроме пары уроков вождения с инструктором. На этом этапе мы начинаем относиться ко 2-му уровню.

• Потом мы заканчиваем автошколу, выходим на дороги общего пользования, и у нас появляется хороший навык, но возникают ситуации, когда мы забываем знания. Люди начинают делать все на автомате, не задумываясь. Если сейчас любого опытного водителя заставить сдать экзамен по теории, без дополнительной подготовки сдадут не многие – чтобы сдать, придется освежить свои знания. Это 3-й уровень.

• И 4-й уровень специалиста – это уровень, при котором специалист обладает и знаниями, и навыками. В контексте водителя это будет инструктор или профессиональный автогонщик.

Как такую модель спроецировать на предметную область и на то, с кем мы работаем?

• 1-й уровень – это, как правило, молодые специалисты, стажеры и новички. Часто, когда аналитик приходит собирать требования, ему дают в помощь новичка. История не очень благоприятная, из нее ничего хорошего не выйдет, нужно стараться от нее отказываться.

• 2-я ситуация происходит тогда, когда диктовать требования вызывается сам руководитель отдела. Это человек, который понимает, как все должно работать в теории, но, так как он непосредственно не участвует руками в работе своих подчиненных и будущих пользователей, он может упускать целую кучу важных вещей.

• 3-й уровень – это специалисты с большим стажем, которые яро уверены, что их годами выращенный процесс не подвержен никаким изменениям и «эти ваши компуктеры ничего не сделают!»

• И 4-й уровень я назвал «развивающийся специалист». Это люди, которые занимаются погружением новичков в отдел, обучением и занимают активную позицию в своей предметной области.

Методы работы

После того как мы определились, с кем работать, давайте разберемся, какие есть методы сбора требований:

• Самый известный и распространенный метод – это интервью.

• Также можно использовать наблюдение за работой сотрудников со стороны.

• Или пройти в компании стажировку.

Поговорим про интервью.

• Первое, что нужно сделать – это заранее ставить встречу, чтобы ваш собеседник смог как-то подготовиться к ней (хотя бы морально). Заранее забить переговорку, если такая возможность есть.

• Второе – это вовремя прийти на встречу.

• Третье – важно правильно сесть.

Рассмотрим, какие варианты посадки есть.

На слайде показана типичная переговорка, где красным цветом я обозначил позицию, которую лучше избегать. Это позиция противостояния, благодаря которой заказчик со своей стороны будет вас не очень благоприятно воспринимать.

И в принципе когда аналитик идет на встречу с заказчиком, то какой у него должен быть настрой?

• Аналитик – это не продажник. У нас нет задачи впарить заказчику что-нибудь подороже и т.д.

• Аналитик ничего не должен заказчику – мы ничего не просим, не умоляем, чтобы нам уделили время.

• Аналитик – это партнер, который приходит в бизнес, чтобы вместе с ним сесть и помочь бизнесу решить его проблему.

Мы – партнеры, поэтому при выборе расположения за столом выбирайте:

• либо соседние кресла – общение в позиции «друг», но тогда при работе с документами вы не сможете четко отследить реакцию вашего собеседника;

• либо (самое крутое) – места под 90 градусов, в этом случае вы сможете наблюдать реакцию на ваши вопросы и при этом не будете находиться в позиции противостояния.

Кроме этого при интервью:

• Обязательно нужно заранее составить перечень вопросов. Часто бывает так, что аналитик недостаточно погружается в предметную область, готовит пару вопросов и думает, что их хватит на двухчасовую дискуссию. Как правило, за 10 минут он получает ответ на свои вопросы, и все, а встреча назначена на час. В следующий раз, когда встреча будет действительно нужна, собеседник 10 раз подумает, нужно ли ему приходить. Поэтому лучше составить исчерпывающий список вопросов. Пускай даже за час вы не успеете все обсудить, но вы сможете прямо там договориться о том, чтобы перенести оставшиеся вопросы на другую встречу, обсудить их в режиме звонка или в режиме переписки.

• Еще одна рекомендация, немного субъективная. Она зависит от того, насколько ваш заказчик или представитель заинтересованной стороны консервативен или прогрессивен. Не все поймут, если вы на встрече будете сидеть с ноутбуком и что-то там печатать. Собеседник не видит, что вы там делаете, а если вы захотите что-то показать, вам придется постоянно крутить экран. Я всегда пользуюсь листком бумаги и ручкой. Всегда можно что-то быстро набросать, показать, зачеркнуть, порвать. Перенести записи в электронный вид не занимает много времени. Как правило, люди со стороны IT – сторонники бумаги. А сторонники компьютеров постоянно бегают в IT со своими идеями и что-то хотят.

• И последний пункт: в завершении интервью нужно обязательно обозначить дальнейшие шаги и в кратчайший срок прислать протокол. Вы говорите, что сегодня-завтра вы пришлете краткий протокол встречи и в течение недели, например, подготовите описание задач или требований и пришлете на ознакомление. Важно, чтобы собеседник понимал, что вы не просто пришли, пообщались и ушли в свой черный ящик и неизвестно когда оттуда вылезете, а чтобы у него было представление, что будет дальше.

Второй метод сбора требований – это наблюдение за работой людей.

Этот метод хорошо работает, когда у вас в качестве заинтересованной стороны такой сотрудник с «короной», который не может сам в деталях рассказать о своих функциях.

Как можно организовать наблюдение за работой со стороны?

• Первое – это договориться о том, чтобы вы общались с этим человеком на его рабочем месте в «боевой» обстановке.

• Второе (более сложный путь) – это договориться о том, чтобы на период сбора требований рабочее место аналитика физически перенесли в бизнес-подразделение, где и планируется автоматизация.

Но у этого метода есть и недостатки.

• Самый главный недостаток – это большие трудозатраты по сравнению с интервью.

• Кроме того, есть риск того, что период вашего нахождения в бизнес-подразделении может не совпасть с важными активностями, которые возникают на периодической основе, например, с подготовкой каких-нибудь отчетов. Вы можете упустить связанные с этим моменты.

• И третье: есть риск того, что, когда вы общаетесь с человеком на его рабочем месте, он просто начнет показывать вам исполнение должностной инструкции, а не реальную работу. Он решит, что вы пришли его проконтролировать, чтобы он не совершал ошибки.

И третий метод сбора требований – это стажировка.

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

У стажировки как метода сбора требований тоже есть недостатки:

• Трудозатрат здесь еще больше, чем в предыдущих двух методах, вместе взятых.

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

• И еще один специфический долгосрочный риск – иногда аналитик настолько настажируется, что его просто хантят в предметную область, и он говорит: «Не хочу в IT, хочу в закупки!» и уходит туда.

Кроме интервью, наблюдения и стажировки для сбора требований я бы обязательно подключил:

• прототипирование (например, в Figma);

• опросные листы или своеобразный CustDev;

• и очень круто, если есть эксперты в этой предметной области, которых можно привлечь в качестве консультантов – они очень быстро и эффективно снимают часть вопросов, чтобы лишний раз не нервировать и не дергать бизнес.

Формализация требований

После того как аналитик собрал требования по этим методам, он должен их формализовать.

Расскажу ключевые моменты.

1. Нужно использовать простой язык. Не должно быть каких-то двусмысленных фраз, все должно быть однозначно;

2. Не нужно показывать свои теоретические знания, и что вы умнее заказчика. Нужно использовать термины, которые знает и заказчик, и вы, чтобы не было разногласий;

3. Кроме того, требования нужно писать так, чтобы каждое требование подвергалось проверке с конкретным ожидаемым результатом;

4. В одном требовании – одно требование. Не надо несколько требований схлопывать в одно. Пусть требование будет маленькое, но отдельное.

На выходе при сборе требований обязательно должен быть документ – такие документы могут называть: ОПЗ, ФТ, БФТ, ЧТЗ и т.д.

Для меня это просто постановка для заказчика, из которой потом рождается постановка разработчикам.

Этот документ обязательно нужно подвергнуть ряду проверок.

Первый уровень проверки требований – это Peer Review (в противопоставление Code Review). Это когда постановку проверяет ваш коллега-аналитик. Либо ведущий аналитик, либо просто ваш коллега.

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

После этого документ обязательно должен попасть на проверку к разработчикам или к тимлиду разработчиков (зависит от команды).

Разработчики дают свою обратную связь, на основании которой в документ тоже вносятся изменения.

Документ обязательно должен попасть в руки к тестировщикам, чтобы они имели представление, каким образом эти требования в дальнейшем проверять и тестировать, когда это будет сделано.

После проверки постановки требований на всех трех уровнях (аналитиков, разработчиков и тестировщиков) отдаем документ заказчику на согласование.

Если заказчик увидел этот документ, все перечеркнул и сказал: «Делайте по-другому!», начинаем этот цикл заново.

Доказано: понятные требования ускоряют процесс разработки

Часто бывают такие ситуации, когда автоматизация затрагивает большой процесс, который проходит через несколько отделов. Мы готовим постановку, согласуем с профильным отделом, он нам дает обратную связь, и мы думаем: «Вроде этот блок не касается закупок, касается только производства. Зачем нам эти изменения доводить до закупок?»

Это ошибка, потому что ожидания отдела, с которым постановку не согласовали, будут не оправданы. То, насколько сильно нам в итоге прилетит по шапке, зависит лишь от того, кто из представителей заинтересованных сторон имеет большее влияние.

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

В заключение приведу цитату Карла Вигерса:

«Несмотря на опасения, что работа над требованиями замедлит создание продукта, доказано, что понятные требования ускоряют процесс разработки».

Поэтому любите своих пользователей, дружите с заказчиками, и все будет хорошо.

Вопросы

Как вы преодолеваете сопротивление сотрудников со стороны заказчика при фиксации информации в протоколах? Когда вы весь бизнес-процесс проговорили, формализуете в протокол, отправляете на согласование и начинается: «Я вам этого не говорил!» Люди боятся, что какая-то неформальная информация от них пойдет в документацию по проекту.

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

Нужна эскалация. Это не значит, что руководитель должен спустить ему сверху требования, которые нужно донести до нас. Руководитель просто должен ему донести: «Этот аналитик работает на нас, и ему нужно доверять». До него пару раз донесут эту мысль, и он будет уже более лояльным. Этот метод очень хорошо работает.

Имеется в виду, что человек на месте выполняет определенные процессы, дает результат. Руководителю нужен результат, он не погружается в сам процесс. У руководителя есть теория, как это должно работать, но на самом деле это же не всегда так.

Естественно, нужно описывать, как все работает на самом деле, иначе это бессмысленная работа.

Мы и хотим реально все описать. Поговорили с человеком на месте, реально описали. Но когда пытаемся это запротоколировать и официально закрепить, исполнитель говорит: «Я под таким не подпишусь».

Все просто: берете его за руку, идете к его руководителю и обсуждаете, действительно ли сотрудник работает так или нет. Руководитель говорит: «Да, так», и все, весь вопрос решится.

Если по мнению руководителя он все делает неправильно, и нужно все переделать, зафиксируйте, как они хотят переделать.

Если человек наотрез не хочет формализовывать свой процесс, настаивая на том, что ему автоматизация не нужна, тогда мы исключаем этот блок из проекта. В документе фиксируем: «Исключить из проекта такие-то задачи» и приносим директору на подпись. Тогда обсуждение у вас пойдет в обратную сторону.

Есть такие люди, которые боятся за свое место. У меня были случаи с замдиректора по экономике. У нее были очень сложные Excel-связи, которые никто в компании не мог понять, и несколько лет никто не мог это автоматизировать. И она никому не хотела это рассказывать.

Получается, если руководитель не в курсе того, как исполнитель исполняет свою работу, у него другое об этом представление, мы должны отталкиваться от того, как эту работу видит его руководитель?

Нет. В данном случае, мы исключаем этот блок задач и снимаем ответственность за то, что этот объем функций не будет реализован. Вы не отказываетесь от этого совсем, а просто исключаете.

Если без этого можно реализовать дальнейший проект, то исключили, подписали, сделали все остальное, а потом, если надо, вернулись к этому вопросу.

Вы говорите, что в итоге должен получиться документ с постановкой требований. Используете ли вы какие-то BPMN-схемы с описаниями процессов? Просто обычно говорят: «Я хочу CRM-систему», а ваша задача – это разложить, построить схему процессов и разобраться, нужно там CRM или что-то другое.

Конечно, аналитик должен использовать в своей работе схемы. Но все зависит от конкретной задачи, которую он решает.

Если это небольшая доработка существующей системы, то схема, возможно, и не нужна. А если это глобальное внедрение на раннем этапе, то здесь одним листочком не обойтись – нужен какой-то документ в виде ЧТЗ, который будет включать в себя и схемы, и описание баз данных и т.д.

То, каким должен быть документ на выходе, зависит от задач. Но схема – это неотъемлемая часть работы аналитика и в принципе любых документов, которые с этим связаны.

Вы рассказали, что для итоговых требований проводится ревью с аналитиком, с разработчиком, с тестировщиком, и только потом они отдаются заказчику. Это действительно у вас так работает? И насколько сложно было прийти к этому? Потому что люди хотят заниматься своей работой.

Проверка разработчиком и проверка тестировщиком помогают проверить реализуемость требований. Без проверки нельзя доказать, что требование реализуемо.

К этому нам прийти было сложно. И долго. И больно.

Но сейчас это работает. Когда процесс выходит на накатанные рельсы, он занимает пару часов.

А сильное сопротивление преодолевали? Много ушло времени?

Конечно сильное. Здесь многое зависит не только от аналитика, а и от того, насколько влиятелен руководитель проекта, сможет ли он всем объяснить, что это действительно нужно. Если РП слабенький, то тимлид с короной на голове будет диктовать свои правила и никакие документы смотреть не будет.

Кто со стороны заказчика вычитывает эти требования? Понятно, что в составлении требований принимали участие несколько рядовых сотрудников, а кто утверждает итоговый документ?

Утверждает, как правило, человек руководящей должности со стороны заказчика, но вычитывают все заинтересованные стороны, которые в этом принимали участие.

Это важно, чтобы было понимание, что все ими сказанное не потерялось, а зафиксировано в документе.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.