Работа над ошибками | Как правильно работать с требованиями
Саша Воронов уже почти пять лет работает в IT. Был инженером-технологом, руководителем проектов, бизнес-аналитиком и системным аналитиком в компаниях разного размера. И не понаслышке знает, как специалистам бывает тяжело разобраться в требованиях клиента. Эта проблема становится глобальной, когда правки в изначальный бриф приходится вносить почти каждый релиз — «Почему нет этого функционала? Мы думали вы сделаете». Отсюда возникают лишние трудозатраты, потеря лояльности клиента и снижение мотивации команды. Чтобы этого не произошло, важно на первых этапах дотошно уточнять каждую деталь.
Саша разобрал несколько ошибок сбора требований, с которыми встречался на практике. А также поделился советами, как правильно работать с требованиями.
Ошибка 1
Не зовете на встречу функциональных пользователейМне пришла задача: рассчитать бюджет проекта, оценить плановый ФОТ и трудоемкость, подготовить устав. Чтобы погрузиться, прочитал ТЗ по похожим проектам. Собрал проектную команду и руководителей со стороны клиента на мозговой штурм.
Мы вместе решили, как будут покрываться те или иные требования технического задания. Пожали руки и уже пошли думать над реализацией — здорово, работа пошла. Но заметили? Я не позвал на встречу тех, кто будет пользоваться нашим продуктом. Это ошибка.
Продукт должен решать «боли» бизнеса. А правдиво рассказать о них могут только пользователи. Также они помогут понять нюансы бизнес-процессов.
Ошибка 2
Не выясняете деталиПредыдущую промашку поняли, исправили: позвали на встречу будущих пользователей продукта. Выслушали их боли и пожелания, стандартно опросили по брифу. «Концепция ясна, детали выясним позже», — решили мы. Прописали и согласовали план по ресурсам, а уже потом начали копать вглубь по требованиям клиента. В итоге реальные трудозатраты превысили плановые почти в три раза!
Пришлось заключать дополнительное соглашение и двигать сроки.
Чем раньше вы начнете уточнять детали, тем меньше ошибок совершите в планировании работ. А, значит, не нарушите дедлайны и поставите более четкое ТЗ разработчикам. Получите лояльного клиента и довольную команду.
Чтобы лучше понять причины требований можно использовать технику «5 почему». Задавайте вопрос «Почему?» пока не получите результат.
Ошибка 3
Не фиксируете договоренности в общем файлеНа одном из созвонов новый ЛПР попросил внести существенную правку в ТЗ, хотя на ранних этапах этого требования не было, о чем я и сообщил. Клиент настаивал, что раз теперь за проект взялся он, то будем реализовывать по‑новому. Возразить я не мог — общего файла, где мы фиксировали предыдущие договоренности и согласовывали их, не было.
По договору правка корректна. Изменения внесли, но, чтобы уложиться в сроки, пришлось привлечь дополнительные человеческие ресурсы.
Чтобы таких ситуаций не возникало, фиксируйте все договоренности в общем поле и назначьте ответственных за согласование. Обсудите с клиентом формат внесения изменений на берегу, желательно пропишите это в договоре. Требования могут меняться — это нормально. Главное, чтобы и вы, и клиент были готовы к тому, что внесение изменений потребует дополнительных трудозатрат.
Ошибка 4
Используете размытые формулировкиНа одном из проектов столкнулся с плохо написанным техническим заданием. Компании было важно успеть податься на тендер, поэтому глубокой проработки ТЗ не случилось. Там были абстрактные формулировки без метрик и описания. Текст не давал понимания, что конкретно нужно клиенту. Для наглядности приведу цитаты: «система должна быть удобной в использовании», «должна быть обеспечена высокая безопасность».
С таким заданием работать невозможно — мы сделаем не то, что хочет клиент. Важно понимать, какие задачи решает команда, реализуя требования. Поэтому, если вы получили текст без объективной информации, возвращайтесь к заказчику и дотошно проясняйте каждый пункт. Например, «должна быть обеспечена высокая безопасность» — что значит «высокая», каким стандартам должна соответствовать, какой подход в компании к оценке информационной безопасности?
