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