Все записи

Работа над ошибками | Как правильно работать
с требованиями

Саша Воронов уже почти пять лет работает в IT. Был инженером-технологом, руководителем проектов, бизнес-аналитиком и системным аналитиком в компаниях разного размера. И не понаслышке знает, как специалистам бывает тяжело разобраться в требованиях клиента. Эта проблема становится глобальной, когда правки в изначальный бриф приходится вносить почти каждый релиз — «Почему нет этого функционала? Мы думали вы сделаете». Отсюда возникают лишние трудозатраты, потеря лояльности клиента и снижение мотивации команды. Чтобы этого не произошло, важно на первых этапах дотошно уточнять каждую деталь.

1jpg

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

Ошибка 1

Не зовете на встречу функциональных пользователей

Мне пришла задача: рассчитать бюджет проекта, оценить плановый ФОТ и трудоемкость, подготовить устав. Чтобы погрузиться, прочитал ТЗ по похожим проектам. Собрал проектную команду и руководителей со стороны клиента на мозговой штурм.
Мы вместе решили, как будут покрываться те или иные требования технического задания. Пожали руки и уже пошли думать над реализацией — здорово, работа пошла. Но заметили? Я не позвал на встречу тех, кто будет пользоваться нашим продуктом. Это ошибка.

Продукт должен решать «боли» бизнеса. А правдиво рассказать о них могут только пользователи. Также они помогут понять нюансы бизнес-процессов.

Ошибка 2

Не выясняете детали

Предыдущую промашку поняли, исправили: позвали на встречу будущих пользователей продукта. Выслушали их боли и пожелания, стандартно опросили по брифу. «Концепция ясна, детали выясним позже», — решили мы. Прописали и согласовали план по ресурсам, а уже потом начали копать вглубь по требованиям клиента. В итоге реальные трудозатраты превысили плановые почти в три раза!

Пришлось заключать дополнительное соглашение и двигать сроки.

Чем раньше вы начнете уточнять детали, тем меньше ошибок совершите в планировании работ. А, значит, не нарушите дедлайны и поставите более четкое ТЗ разработчикам. Получите лояльного клиента и довольную команду.

Чтобы лучше понять причины требований можно использовать технику «5 почему». Задавайте вопрос «Почему?» пока не получите результат.

Ошибка 3

Не фиксируете договоренности в общем файле

На одном из созвонов новый ЛПР попросил внести существенную правку в ТЗ, хотя на ранних этапах этого требования не было, о чем я и сообщил. Клиент настаивал, что раз теперь за проект взялся он, то будем реализовывать по‑новому. Возразить я не мог — общего файла, где мы фиксировали предыдущие договоренности и согласовывали их, не было.

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

Чтобы таких ситуаций не возникало, фиксируйте все договоренности в общем поле и назначьте ответственных за согласование. Обсудите с клиентом формат внесения изменений на берегу, желательно пропишите это в договоре. Требования могут меняться — это нормально. Главное, чтобы и вы, и клиент были готовы к тому, что внесение изменений потребует дополнительных трудозатрат.

Ошибка 4

Используете размытые формулировки

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

С таким заданием работать невозможно — мы сделаем не то, что хочет клиент. Важно понимать, какие задачи решает команда, реализуя требования. Поэтому, если вы получили текст без объективной информации, возвращайтесь к заказчику и дотошно проясняйте каждый пункт. Например, «должна быть обеспечена высокая безопасность» — что значит «высокая», каким стандартам должна соответствовать, какой подход в компании к оценке информационной безопасности?

Похожие новости

Истории коллег, в которых поддержка команды изменила все

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

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

Тимлид в команде джунов: путь к доверию и развитию команды

Вика Анисимова пришла в Naumen стажером, выросла до системного аналитика и теперь руководит командой сопровождения web SMP. 

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

История успеха | Ксения Тарануха

Ксюша пришла в техподдержку Скорозвона — без технического образования, но с опытом в коммуникациях и желанием развиваться. За два с половиной года она глубоко погрузилась в продукт, а затем перешла в аналитику. И уже на старте помогла реализовать фичу, которая упростила подключение SIP URI для клиентов — за этот вклад она даже получила премию Naumen Профи.

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

Все новости