Оценка требований. Глава 1. Ищем виноватых
Привет! Эта статья написана для нашего блога руководителем отдела аналитики Акелона Ксенией Романовой. С неё мы начинаем серию публикаций на тему оценки требований. Тема настолько обширная, и вопросов по ней так много, что можно написать целую книгу, которой почему-то до сих пор нет. Для своего блога мы решили подготовить комплексный материал по оценке требований, который будет состоять из трех глав. Первую главу мы посвящаем одному из самых спорных вопросов — кто должен готовить оценку.
Более двух лет я участвую в собеседованиях аналитиков и консультантов по внедрению систем. Очень часто, задавая вопрос: «Приходилось ли вам участвовать в оценке требований?”, я получаю большую вариацию ответов: "Нет, у нас этим занимался <подставь любого участника проектной команды>".
Топ самых часто встречающихся: руководитель проекта, архитектор, разработчик. Наверное, только 40% аналитиков по моему опыту могут заявить, что готовили оценку самостоятельно или хотя бы принимали участие в этом процессе.
И действительно, сложно “узаконить” единственно верный вариант, который будет работать лучше других во всех компаниях сразу, и причин на то множество.
Во многом, исполнитель определяется в зависимости от способа подготовки оценки. Рассмотрим парочку примеров.
Если требование типовое, а у компании есть точная методика, то можно использовать Параметрическую оценку. Например, Заказчику нужно разработать 3 новых справочника. Разработка и внедрение одного справочника занимает 8 часов. Тогда исполнитель оценки умножает кол-во справочников на норматив и получает итоговую оценку в 24 часа. С такой оценкой успешно справится любой участник команды.
Похожим по уровню сложности способом является Оценка по аналогам. Его суть заключается в том, чтобы подготовить оценку на основании опыта выполнения аналогичных работ. Например, в прошлый раз мы сделали 3 таких справочника за 24 часа, значит и эти оценим так же.
На практике же, оба этих способа работают крайне редко, ведь требования к справочникам могут отличаться как по функциональности, так и по составу работ по их внедрению.
Тогда на помощь приходит один из самых распространенных методов — метод Экспертной оценки. Он основан на опыте и знаниях человека, подготавливающего оценку. Этот метод прекрасно учитывает уникальность требований, но ставит перед его последователями непростой вопрос: А кто у нас будет “экспертом”?
Для ответа на этот вопрос предлагаем сформулировать ожидания от этой роли.
Оценка требования подразумевает оценку всех работ, которые команде необходимо выполнить, чтобы это требование реализовать.
Эти работы включают как время разработчика на написание кода, так и время других участников команды на тестирование, документирование, внедрение… Подробнее о том, какие работы должны входить в оценку, и как их посчитать, рассмотрим в следующей главе.
Следовательно, как минимум этот человек должен:
- прекрасно разбираться в бизнес-процессах Заказчика, чтобы оценить эффективность и применимость требования, уточнить детали;
- глубоко знать внедряемый продукт, чтобы оценить возможности реализации требования и предложить лучший вариант;
- понимать объем требуемых работ по разработке и внедрению, чтобы организовать работу по оценке смежных специалистов (разработчиков, тестировщиков);
- иметь боевой опыт в реализации подобных задач, чтобы определить должный уровень рисков;
- уметь защитить результаты оценки перед Заказчиком.
Теперь переложите эти требования на свою команду. Кто в вашей команде отвечает им в наибольшей мере? Аналитики, руководители проектов, разработчики?
В нашей компании — это, безусловно, аналитики.
Вне зависимости от того, как называется ваша роль в команде, если вы занимаетесь оценкой требований, планируете начать или можете получить такую задачу от руководителя, следующие статьи серии будут обращены к вам.
Если подходящего варианта нет, пишите в комментариях, кто у вас в компании отвечает за оценку требований.
А для того, чтобы не пропустить выход следующих глав, подписывайтесь на наш телеграм-канал, в котором мы публикуем анонсы статей
В корне не согласен. Средний аналитик по больнице может провести только ручное тестирование, и написать hello world с пузырьковой сортировкой на целевом языке. Отсюда адекватная оценка работ на базе скилов невозможна, а возможна только по аналогии с другими задачами, которые совсем не обязательно должны быть типовыми.
При этом, аналитик должен быть в курсе загрузки участников команды на смежных проектах, болезней, отпусков коллег, а также их психологии и подхода каждого к работе. Отсюда вывод: аналитик должен участвовать в согласовании выделения ресурсов на проект, а отсюда уже следуют управление бюджетом проекта, найм людей и т.д. Это сфера ответственности руководителя проекта, как ни крути.
Рядовой аналитик способен на оценку по принципу "скажем квартал, потом разберёмся", а не рядовой фактически работает менеджером проекта за зарплату аналитика, что так же не есть хорошо.
как точно сказано. Особенно про "менеджера проекта за зарплату аналитика". Фактически задачи менеджера проекта и системного аналитика много, где пересекаются. Вопрос как выйти из этого порочного круга?
Спасибо за развернутый ответ! На то вопрос и спорный.
Мы, честно говоря, не планировали освещать вопрос планирования реализации требований (когда и кем работы будут выполнены), а хотели ограничиться только оценкой (сколько часов надо, чтобы это сделать). Вопрос планирования работ безусловно лежит в зоне ответственности РП.
С предложением, что аналитик один (!) не посчитает трудозатраты на разработку, тоже согласны)
думаю, что наша следующая глава внесет больше ясности :)
Опрос не работает. Пишет "Опрос не найден"