Привет! Я Саша, уже почти пять лет я работаю в IT. Был инженером-технологом, руководителем проектов, бизнес-аналитиком и системным аналитиком в компаниях разного размера. И не понаслышке знаю, как специалистам бывает тяжело разобраться в требованиях клиента. Эта проблема становится глобальной, когда правки в изначальный бриф приходится вносить почти каждый релиз — «Почему нет этого функционала? Мы думали вы сделаете». Отсюда возникают лишние трудозатраты, потеря лояльности клиента и снижение мотивации команды. Чтобы этого не произошло, важно на первых этапах дотошно уточнять каждую деталь.
Саша Воронов
Системный аналитик Naumen Contact Center
Ниже разберу 6 ошибок сбора требований, с которыми встречался на практике. И расскажу, как их не допустить. Статья будет полезна начинающим аналитикам и менеджерам проектов.
Ошибка 1. Не зовете на встречу функциональных пользователей
Когда я был совсем «зеленый» — работал менеджером в компании N. Участвовал в нетипичном для команды проекте. Бизнес-процессы клиента были совсем нам не знакомы.
Мне пришла задача: рассчитать бюджет проекта, оценить плановый ФОТ и трудоемкость, подготовить устав. Чтобы погрузиться в новую отрасль, прочитал ТЗ по похожим проектам. Собрал проектную команду и руководителей со стороны клиента на мозговой штурм. Мы вместе решили, как будут покрываться те или иные требования технического задания. Пожали руки и уже пошли думать над реализацией — здорово, работа пошла. Но заметили? Я не позвал на встречу тех, кто будет пользоваться нашим продуктом. Это ошибка.
Продукт должен решать «боли» бизнеса. А правдиво рассказать о них могут только пользователи. Также они помогут понять нюансы бизнес-процессов.
Ошибка 2. Не выясняете детали
Продолжу на примере кейса выше. Предыдущую промашку поняли, исправили: позвали на встречу будущих пользователей продукта. Выслушали их боли и пожелания, стандартно опросили по брифу. «Концепция ясна, детали выясним позже», — решили мы. Прописали и согласовали план по ресурсам, а уже потом начали копать вглубь по требованиям клиента. В итоге реальные трудозатраты превысили плановые почти в три раза! Пришлось заключать дополнительное соглашение и двигать сроки.
Чем раньше вы начнете уточнять детали, тем меньше ошибок совершите в планировании работ. А, значит, не нарушите дедлайны и поставите более четкое ТЗ разработчикам. Получите лояльного клиента и довольную команду.
Рекомендую включить бриф следующие вопросы:
— Какие бизнес-процессы будет поддерживать или автоматизировать новая система?
— Какие сценарии использования, use cases, можете описать для новой системы?
— Какие ключевые функции и возможности должна иметь новая система для удовлетворения ваших потребностей?
— Кто будут основными пользователями системы? Какие у них задачи и роли?
— Какие проблемы или недостатки видите в текущей системе?
— Какие внешние системы или данные должны быть интегрированы с новой системой?
— Какие данные должна обрабатывать и хранить новая система?
— Какие требования по безопасности и защите данных важны для компании?
— Какие отчеты и аналитические инструменты должны быть в системе?
— Какие требования к производительности и масштабируемости системы?
Это лишь небольшой список вопросов, но он может стать хорошей отправной точкой для начала сбора требований.
Еще, чтобы лучше понять причины требований можно использовать технику «5 почему». Задавайте вопрос «Почему?» пока не получите результат. Например, у клиента есть проблема: сайт компании часто падает. Что нужно выяснить:
1. Почему сайт компании падает?
— Сервер перегружается.
2. Почему сервер перегружается?
— На сервере слишком много одновременных запросов.
3. Почему на сервере слишком много одновременных запросов?
— Сайт не оптимизирован для большого количества пользователей.
4. Почему сайт не оптимизирован для большого количества пользователей?
— На этапе разработки не была проведена нагрузочная проверка.
5. Почему не была проведена нагрузочная проверка?
— В проекте не было заложено времени и ресурсов на тестирование производительности.
Так мы смогли узнать истинную причину проблемы: недостаточное планирование и отсутствие тестирования производительности на этапе разработки привели к тому, что сайт не был подготовлен к большим нагрузкам. Эта информация поможет сформулировать понятное требование.
Ошибка 3. Не фиксируете договоренности в общем файле
В этой же компании мне дали вести проект уже в стадии реализации — предыдущий менеджер перешел на другую роль. Важно, что в это же время на стороне клиента также сменился ЛПР. Так на одном из созвонов новый ЛПР попросил внести существенную правку в ТЗ, хотя на ранних этапах этого требования не было, о чем я и сообщил. Клиент настаивал, что раз теперь за проект взялся он, то будем реализовывать по-новому. Возразить я не мог — общего файла, где мы фиксировали предыдущие договоренности и согласовывали их, не было. А по договору правка корректна. Изменения внесли, но, чтобы уложиться в сроки, пришлось привлечь дополнительные человеческие ресурсы.
Чтобы таких ситуаций не возникало, фиксируйте все договоренности в общем поле и назначьте ответственных за согласование. Обсудите с клиентом формат внесения изменений на берегу, желательно пропишите это в договоре. Требования могут меняться — это нормально. Главное, чтобы и вы, и клиент были готовы к тому, что внесение изменений потребует дополнительных трудозатрат.
Ошибка 4. Используете размытые формулировки
На одном из проектов столкнулся с плохо написанным техническим заданием. Компании было важно успеть податься на тендер, поэтому глубокой проработки ТЗ не случилось. Там были абстрактные формулировки без метрик и описания. Текст не давал понимания, что конкретно нужно клиенту. Для наглядности приведу цитаты: «система должна быть удобной в использовании», «система должна быть быстрой», «должна быть обеспечена высокая безопасность», «интерфейс должен быть красивым и современным».
С таким заданием работать невозможно — мы сделаем не то, что хочет клиент. Важно понимать, какие задачи решает команда, реализуя требования. Поэтому, если вы получили текст без объективной информации, возвращайтесь к заказчику и дотошно проясняйте каждый пункт. Например, «должна быть обеспечена высокая безопасность» — что значит «высокая», каким стандартам должна соответствовать, какой подход в компании к оценке информационной безопасности?
Ошибка 5. Соглашаетесь на нереализуемые требования
Однажды получил от пресейла ТЗ:
— «Система должна автоматически, без участия пользователя выполнять расчеты, при этом, заменять недостоверные исходные данные и выдавать пользователю рекомендацию N».
— «Система должна быть доступна 99,9999 % времени в год».
— «Система должна выдавать прогнозы с точностью 99,99 %».
Тогда я действовал по правилу, есть задача — надо делать. И выгорел. Эти требования были заведомо невыполнимыми. Позже я вернулся к клиенту и объяснил, что мы не сможем разработать такую систему, так как ограничены ресурсными и техническими рамками. Но перед этим потерял много времени и нервов.
Если по итогам обсуждений понимаете, что в рамках вашего проекта функциональность не реализуема, не бойтесь говорить об этом. Вы работаете в определенных границах и, если их нарушать, проект будет близок к провалу. Эскалируйте! Выходите с проблемой к руководителю проекта или тимлиду.
Ошибка 6. Не используете блок-схемы
Проработав два года руководителем проектов, в прошлом году решил перейти на позицию ведущего бизнес-аналитика в той же компании. Попал на проект реализации информационного обмена между тремя информационными системами:
— Система 1 проводит расчёт, передаёт данные в Систему 2.
— Система 2 проводит расчёт и передаёт данные Систему 3.
Чтобы выявить все требования, мы проводили совещания, говорили много слов, писали протоколы встреч. Но спустя несколько месяцев оставалось ощущение, что ни одна из сторон до конца не понимает, что нужно сделать. Тогда я предложил рисовать :) И мы быстрее согласовались с клиентом по требованиям. Схемы — отличный инструмент, чтобы у всех сформировалось единое представление о процессах.
Суть важнее следования догмам нотаций.
Каждый воспринимает информацию по-разному: кому-то проще анализировать речь и текст, кому-то — изображения и схемы. Поэтому сухой текст рекомендую подкреплять графикой. Можно использовать любые нотации — UML, BPMN, ArchiMate, ГОСТ-34. Главное, чтобы все ЛПР понимали суть нарисованного. В этом кейсе мы использовали UML, делюсь упрощенной схемой процесса:
Сейчас в работе стараюсь использовать накопленный «потом и кровью» опыт и следовать правилам:
— Обсуждать требования и с представителями бизнеса, и с функциональными пользователями.
— Итоги встреч оформлять в виде постановок и согласовывать их с клиентом. Следить, чтобы в протоколе всегда были:
согласованные бизнес-требования,
схемы или диаграмма процессов,
объективные данные и не размытые формулировки,
ограничения,
ожидаемое поведение функционала и приемочный тест.
— Не соглашаться на нереализуемые требования.