Давайте попробуем разобраться, в чем же ценность бизнес-анализа и как измерить качество этой работы.
Часто смысл разговора о необходимости присутствия аналитика на проекте сводится к следующему:
- Здравствуйте, Вам в проекте нужен аналитик.
- Здравствуйте. А зачем?
- Ну как зачем?! Чтобы требования собрать, обсудить… с заказчиком.. спецификация… разработчику задачи поставить…
- Простите, Вы неразборчиво что-то говорите. Я Вас не понимаю.
- Аналитик! Он нужен! Требования! Команда! Качественно, чтобы…
- У нас продакт оунер работает напрямую с командой разработки. Все замечательно.
- Понятно. Спасибо…
Если вы – уже не первый год в ИТ и высокоуровневые рассуждения – не для вас, смело дожидайтесь второй части статьи.
Как вы знаете, аналитик – это, прежде всего, роль . Эту роль можно разделить среди нескольких людей. И дядюшка Вигерс (K.Wiegers) нам про это говорит, и Международный институт по бизнес-анализу (IIBA) про это не забывает.
Неполный список критериев, которые определяют необходимость в выделенной роли аналитика, может выглядеть так:
- Зрелость организации (как заказчика, так и исполнителя)
- Размеры проекта (с т.зр. сроков, бюджета, количества заинтересованных лиц)
- Географическая распределенность заинтересованных лиц
- Сложность организационной структуры компании
- Сложность предметной области
Не стесняйтесь этот список дополнять в комментариях к статье.
Если мы считаем, что аналитик – это роль, то данная роль будет описывать ограниченное множество действий, выполняемых кем-то или чем-то в рамках определенного процесса (спасибо Википедии). “Действия” для удобства заменим на “активности”.
Значит, нам нужно понять, какие активности обычно выполняет аналитик. Причем, эти самые активности можно выполнять, используя множество разных техник, о которых речь в данном случае не идет.
Согласно последнему своду знаний от IIBA, к активностям аналитика относятся:
- Определение проблем и целей организации
- Анализ потребностей и решений
- Создание стратегий
- Осуществление изменений
- Фасилитация взаимодействия между заинтересованными лицами
Конечно, в контексте белорусских реалий, рядовой аналитик является больше аналитиком требований (или системным аналитиком), нежели бизнес-аналитиком.
Поэтому разработка бизнес-стратегии – это для него некая эфемерная и непонятная активность (как и слово “стратегия”).
Думаю, можно пересчитать на пальцах тех, кто действительно занимается проблемами наиболее высокого уровня, решение которых подразумевает потенциальные изменения в бизнес-модели организации. Буду рад, если у вас получится меня переубедить, возможно даже, поделившись личным опытом и примерами.
Карл Вигерс выделяет следующие области (группы) активностей по бизнес-анализу:
- Определение бизнес-требований
- Определение подхода к работе с требованиями
- Выявление заинтересованных лиц
- Сбор требований
- Анализ требований
- Документирование требований
- Коммуницирование требований
- Фасилитация в валидации и приоритизации требований
- Управление требованиями
Поскольку слово “анализ” присутствует как в списке основных активностей, так и в самом названии нашей с вами профессии, можно предположить, что это важная активность (капитан не дремлет!). А возможно, и самая важная.
И когда мы говорим о распределении активностей аналитика среди других ролей, то часто подразумеваем нечто вроде следующего:
- Продакт оунер (он же Product owner, владелец продукта) сам определяет и формулирует бизнес-потребности, приоритизирует бизнес-требования
- Проектный менеджер вместе с ведущим разработчиком занимаются сбором и документированием требований
- Тестировщик проверяет качество требований (например, полноту)
- Кто-то из перечисленных выше ролей будет также заниматься коммуницированием требований и управлением ими
Есть ненулевая вероятность, что при отсутствии отдельной роли под названием “аналитик” может отсутствовать и активность под названием “анализ”. Конечно, люди в нашей сфере собрались неглупые, и почти всегда требования на всех уровнях (будь то бизнес-требования, требования заинтересованных лиц или требования к решению) в некой форме подвергаются анализу. Не всегда формально, не всегда осознанно, но все-таки это происходит.
И в таких случаях возможны различные сценарии. И неважно, говорим ли мы о проекте по разработке сайта-визитки, внедрении ERP-системы или целой программе (группе проектов) по автоматизации одного из основных бизнес-процессов в компании и замене соответствующих систем. Результат определяется таким количеством переменных, что отдельно выделить вклад именно аналитических активностей, зачастую, очень трудно.
Стоит отметить, что на сегодняшний день провальных проектов гораздо больше, чем успешных. Сегодня гораздо больше проектов с превышенным бюджетом, проектов, которые не решают действительную проблему клиента, проектов с затянутыми сроками. Об этом можно почитать здесь, здесь, да и много где еще. И эту проблему пытаются решить по-разному.
Почти каждый год на рынке появляются новые гибкие методологии или вариации на тему существующих. Например, SAFe предлагает нам масштабируемый и контролируемый Agile. А еще есть Nexus, DAD и дюжина других. С другой стороны, есть аналитики, которые и код не пишут, и за бюджет проекта не отвечают, а должны как раз помочь клиенту четко сформулировать бизнес-проблему и потом помочь инженерам эту самую проблему эффективно (это важно!) решить.
Значит ли это, что при прочих равных условиях проект, в котором есть аналитик, будет более успешным, чем проект без аналитика? Если да, то как это своевременно определить? Как понять, что аналитические активности выполняются в достаточной степени и с достаточным качеством? Как повлияют на проект плохо выполняемые те или иные БА активности?
Об этом поговорим в следующей части статьи. Вместо заключения хочу заметить, что с точки зрения ТРИЗ идеальный аналитик – это аналитик, которого нет, но функция которого выполняется. Другими словами, функция аналитика оптимизируется путем минимизации затрат (зарплата, дополнительная цепочка в коммуникации и т.д.) и максимизации пользы (более качественные требования, сокращение ошибок, вызванных человеческим фактором и т.д.).
Это, в некоторой степени, можно наблюдать в ситуации, когда владелец продукта, поработав с опытным аналитиком, к середине проекта набрал достаточно знаний, чтобы самостоятельно формулировать и документировать качественные требования и работать напрямую с одной или несколькими командами разработки. В таком случае потребность в отдельной роли аналитика резко снижается.
При этом, нельзя сказать, что снижается и польза от аналитических активностей. Поэтому (и не только) имеет смысл оценивать качество не работы отдельного аналитика, а качество анализа (т.е. всех активностей и артефактов) в целом на проекте или в организации
В предыдущей части статьи мы описали, почему зачастую сложно определить пользу от бизнес-анализа. Однако популярность этой профессии активно растет, что косвенно говорит о том, что польза, как правило, есть.
В этой части поговорим о том, как можно измерить качество аналитических активностей.
Сразу стоит отметить, что “качество активностей” – это не то качество, которое мы хотели бы измерить. В идеальном мире хотелось бы измерить качество результата работы аналитика. А результатом должна являться решенная проблема или реализованная возможность.
Но здесь мы снова упираемся в «стопицот» зависимостей, факторов и неопределенностей, которые на данный момент точно измерить нельзя. Да, сегодня качество результата ИТ-проекта с точки зрения измеряемости все еще ближе к творчеству, нежели к науке (скажем, к математике). Поэтому, преодолев последний порыв к философствованию и пустословию, предлагаю обсудить, что же мы сегодня все-таки можем измерить.
Из всех определений термина “качество”, на мой взгляд, к бизнес-анализу лучше всего подходит следующее: сравнение ожиданий от услуги и производительности данной услуги. Перевод вольный, оригинал можно найти здесь.
Качество бизнес-анализа в рамках определенного контекста (фаза проекта, проект, программа) будет определяться тем, насколько полно и качественно выполняются отдельные аналитические активности. Также имеет смысл рассматривать качество артефактов, насколько это возможно.
Итого измеряем:
- Качество аналитических активностей в общем процессе
- Качество аналитических артефактов
Источник: dzen.ru
Бизнес-анализ и мобильные приложения: почему заказчики не видят ценности в аналитике и как им её донести
Часто заказчики не понимают ценности бизнес-аналитика. Кажется, что эти функции могут выполнять другие члены команды: разработчики, тестировщики, менеджеры проектов. Мы уже затрагивали эту тему в статье «Топ-5 заблуждений в работе аналитика», и сегодня хотим поговорить об этом подробнее.
Меня зовут Анна Цветкова, я бизнес-аналитик в Surf. Мы занимаемся мобильной аутсорс-разработкой и делаем разные проекты: банкинг, е-комм, есть даже госзаказы. И, конечно, нам приходится объяснять клиентам, зачем на проекте нужен бизнес-аналитик. Рассказываю, почему так происходит и как показать заказчику ценность аналитика.
Почему заказчик не видит ценности в аналитике как в отдельном члене команды
- На стороне заказчика есть команда аналитики. Обычно это крупные заказчики с обширной инфраструктурой: банки или государственный сектор. Инхаус-аналитики, как правило, никогда не работали с мобильными приложениями и не знают специфики.
- Подключение аналитика увеличивает бюджет разработки.
- Прошлый опыт взаимодействия с аналитиком был неудачным. Например, потому что заказчик не увидел результатов выполнения задач.
- Заказчик думает, что команда разработки сможет получать требования от него напрямую.
На каких проектах нужен аналитик
Конечно, не всем компаниям нужен аналитик, и у меня нет цели доказывать, что без него — никуда. В Surf мы поняли, что нуждаемся в отдельном аналитике, когда к нам пришли крупные заказчики: мобильный банкинг (Зенит, СМП) и крупный е-коммерс (Магнит, Лабиринт).
До этого задачи аналитика выполнял менеджер проекта: собирал и документировал требования, разбирался в логике работы. На крупных проектах его ресурса просто перестало хватать.
Давайте обсудим, какие факторы влияют на то, выделять аналитика как отдельную роль или нет.
Размер и сложность проекта
➖ Без аналитика справится стартап с шестью фичами и целью выкатить MVP за 4 недели.
➕ Аналитик необходим на крупных и сложных проектах. Например, на проекте мобильного банка: много логики, особенностей отрасли и законодательства. Чего только стоит недавняя фича Me2Me, которую регулятор обязал разработать в кратчайшие сроки.
Нужно было за два месяца с нуля спроектировать процесс работы пользователя с фичей и взаимодействие мобильного приложения и сервера. Задача не из легких:)
Количество заинтересованных лиц в проекте
Заинтересованные лица — они же стейкхолдеры — поставляют требования. Каждый преследует свои цели и отвечает за конкретное направление: продажи, маркетинг, IT, производство. Требования стейкхолдеров нужно выявить, задокументировать и учесть в проектировании решения.
➖ Без аналитика можно справиться, когда стейкхолдеров пара человек.
➕ Аналитик необходим на большом проекте, где стейкхолдеров может быть и 10 человек. При таком количестве заинтересованных лиц нужно не только выявлять требования, но и строить коммуникации: понять, как управлять их ожиданиями, кто принимает решения, какая у кого степень влияния на проект и так далее. Это большая работа, для которой не хватит ресурса и навыков у других членов команды.
Продолжительность проекта
Этот фактор напрямую зависит от размера и сложности проекта.
➖ Без аналитика можно обойтись, как мы сказали выше, если команда за несколько недель разрабатывает MVP.
➕ Аналитик необходим крупным заказчикам: они, как правило, разрабатывают проекты годами. За это время команда проекта на стороне исполнителя и на стороне заказчика может поменяться, проект обрастает новой логикой. Важность ведения базы знаний и постоянная актуализация особенно нужна на проектах с большим количество фич.
Если вы поставили плюсики напротив каждого из пунктов «Аналитик необходим», поздравляю: вам — сюрприз — нужен аналитик 🙂
Что будет с мобильным приложением, спроектированным без аналитика
Рассмотрим проблемы, которые могут возникнуть на проекте без аналитика.
Неучтённые кейсы, сорванные сроки и бюджет, некорректно работающий продукт
Проблема: неучтённые кейсы всплывают на этапе разработки либо потом приходят как доработки. Они превращаются в дополнительные задачи для разработки: это риск не уложиться в согласованные сроки и бюджет либо отдать пользователям некорректно работающий продукт.
Например, есть задача: сделать приложение для заказа еды. На главном экране — актуальная информация о заказе: статус, наполнение, время доставки и так далее. Оформление заказа происходит после оплаты.
Но этой информации разработчику мало. Непонятно:
- Как это будет связано с доставкой заказа. Как работает система, которая распределяет заказы между курьерами? Заказ поступает курьеру сразу после оплаты?
- Есть ли возврат средств за заказ? Если да, как он будет реализован?
- Можно ли отслеживать путь курьера в приложении?
Разработчику приходится выяснять ответы на вопросы, тратить время на ожидание ответа от заказчика, обсуждать с дизайнером, как это учесть в прототипах. Время разработки фичи увеличивается в несколько раз.
«Кривая» логика и неучтённые пользовательские сценарии
Задача аналитика — видеть продукт в целом, соблюдать консистентность системы, выявлять зависимости фич друг от друга и агрегировать полученную информацию в виде документации. Если описывать фичи в отрыве друг от друга, приложение не будет работать корректно. Раздражение и негатив пользователей обеспечены.
Вернёмся к примеру с приложением доставки еды. У пользователя есть промокод со скидкой на первый заказ. Он может ввести его в корзине, когда совершает заказ, или в профиле. Если пользователь введёт промокод в профиле, скидка не применится: система должна отложить промокод до совершения заказа.
Требования к реализации были недостаточно четкие. Разработчик реализовал логику так: промокод, введённый через профиль, применялся сразу. Пользователь его терял, потому что заказа-то не было. Когда это выяснилось, пришлось уточнять требования и переделывать логику работы промокодов.
Почему так произошло? Когда описывали требования к вводу промокода на первый заказ, не учли кейс ввода промокода из профиля. Разработчик подумал, что так и нужно: вдруг этот промокод будет отложен на сервере. Аналитик описал бы эту разницу в требованиях в явном виде, и переделывать логику не пришлось.
Не учли особенности платформ iOS и Android: возникнут проблемы с внешним видом и работой нативных компонентов
Основных платформ для разработки две: iOS и Android. Есть и другие, менее популярные. Часто при работе с мобильными продуктами не учитывают:
Особенности реализации для каждой платформы: например, в Android развита работа с кэшем, а на iOS работу с кешированием данных реализовать сложнее.
Нативные для каждой платформы компоненты: они существенно экономят время разработки.
Великое множество устройств со своими разрешениями экранов. Приложением должно быть удобно пользоваться даже на самом маленьком экране.
Пример: пикер для выбора даты. На iOS выглядит так:
На Android — так:
У заказчика не было специальных требований к внешнему виду дата-пикера. Но дизайнеру хотелось сделать творческий и красивый дизайн: он нарисовал кастомный компонент с анимацией выбора дня недели. Разработчики взяли его в работу: потратили в несколько раз больше времени, чем вышло бы на подключение нативного пикера.
Если бы на проекте был аналитик, он вовремя заметил бы этот момент, предложил использовать нативный компонент и сэкономил часы разработки без ущерба для удобства пользователя.
Есть другие специфичные кейсы: чтобы их проработать, мало быть просто пользователем мобильных приложений. Нужно иметь опыт работы с «внутрянкой», понимать особенности работы приложения.
Возьмём, к примеру, аутентификацию в приложении с помощью биометрии. В зависимости от платформы и вендора, на устройстве могут быть:
- Touch ID;
- Face ID или распознавание лица;
- Fingerprint.
В описании кейсов, реализации и тестировании необходимо учесть, что у некоторых устройств на базе Android есть оба вида биометрии: и аутентификация по отпечатку пальца, и распознавание лица. Если не описать этот кейс, пользователь получит некорректно работающую биометрию либо баги в дизайне: например, текст в алерте для настройки биометрии не будет влезать на экран.
Неучтённые состояния экранов, что вновь приводит к некорректной работе приложения, увеличенным срокам разработки и бюджетам
Часто дизайнеры учитывают состояния экранов, которые возникают в ответ на действие пользователя: например, пользователь отключил на устройстве интернет.
Какие состояния могут быть:
- загрузки и обновления экрана,
- ошибок,
- валидационные,
- когда для экрана не получены данные (например, если нет баннеров с акциями на главном экране, нужно отобразить заглушку или стейт ошибки),
- анимации.
Если не продумать состояния на этапе проектирования:
- Пользователь может получить бесконечную загрузку приложения, что не очень хорошо.
- Разработчики потратят лишнее время, ожидая, пока дизайнер дорисует недостающие состояния.
Аналитик во время предварительного ревью дизайна укажет на недостающие экраны и состояния: разработчик на старте работы над фичей может не тратить время на ревью.
Заказчик: японский банк с отделениями по всему миру.
Задача: разработать мобильное приложение на платформах iOS и Android. Разработка и поддержка бэкенда — на стороне департамента информационных технологий банка.
Ситуация: В IT-департаменте банка есть собственные аналитики: они пишут постановки на бэкенд, но опыта работы с мобильными приложениями у них нет.
Предстояло разработать одну из основных фич банковского приложения — главный экран. Он состоит из множества элементов: список счетов, остатки средств, новости и обновления, возможность открыть новые продукты.
Аналитики со стороны банка написали ТЗ. На этапе разработки команда столкнулась с проблемами:
- Не учли в дизайне и не описали поведение элементов на экране: свайпов, возможностей обновления экрана, раскрывающиеся списки, анимацию. Банковские аналитики просто не знали, что такое поведение нужно описывать, потому что не работали с мобильными продуктами.
- Неоптимально организована инициализация экрана. Для формирования экрана клиент отправлял около 10 запросов. Скорость обработки одного запроса на сервере относительно низкая, поэтому пользователю приходилось ждать загрузки экрана 7–8 секунд. По ходу разработки стало понятно, что отправлять 10 запросов при обновлении экрана — лишняя работа. Чтобы получить основную информацию, достаточно отправить всего три. Оставшиеся можно вызывать по триггеру — конкретному действию пользователя в приложении.
- Непонятно, откуда какую информацию брать: нет маппинга моделей из ответов на запросы на дизайн.
В итоге бюджет и сроки разработки увеличились. Вместо кодинга разработчики уточняли требования.
Как показать заказчику ценность аналитика
По опыту, нельзя просто взять и рассказать заказчику, как хорошо пригодился аналитик на других проектах. Мы поняли, что эффективнее всего предложить заказчику провести эксперимент: внедрить аналитика в команду и оценить результаты.
Перед этим можно провести презентацию нового процесса работы. Нарисовать процесс as is и процесс to be. Подсветить места, в которых сейчас есть проблемы. Показать, как подключение аналитика может эти проблемы пофиксить.
Статистика и цифры — наше всё. У каждого эксперимента должны быть метрики, по которым можно сделать выводы об успешности. В случае с аналитиком можно сформулировать такие критерии:
- Среднее время проектирования фичи (без сбора бизнес-требований — это остаётся в зоне ответственности заказчика).
- Среднее время на ревью ТЗ от разработчика.
- Количество вносимых изменений в ТЗ после ревью разработчика.
- Оценку по разработке фичи.
- Фактическое время разработки фичи.
При общении с заказчиком любые предложения или аргументы подкрепляйте фактами, цифрами, результатами исследований. Составьте таблицу и посчитайте эти же затраты в деньгах с использованием средней ставки разработчика в час.
Итоги эксперимента подводите совместно с заказчиком. Посмотрите на статистику, соберите обратную связь от команды, сравните старые показатели с новыми. На основании цифр проще сделать выводы об эффективности работы аналитика.
И помните, что глобально вы с заказчиком преследуете одну цель — разработать качественный продукт в оговоренные сроки и бюджет.
Аналитик необходим на крупных и сложных проектах
Аналитик — не лекарство от всех болезней, но он необходим для долгосрочных и крупных проектов с большим количеством логики, фич и заинтересованных лиц. А ещё — на проектах по разработке мобильных приложений 🙂
Почему?
- В крупных компаниях за разработку продукта отвечают несколько отделов (и много стейкхолдеров): IT-департамент, маркетинг, продажи и так далее. У каждого — собственные цели и задачи в продукте, каждый — эксперт в своей области. Аналитик соберёт, обработает и формализует цели, задачи и пожелания участников, чтобы выстроить единую картину продукта.
- В проекте может меняться и команда разработки, и стейкхолдеры. Важно иметь актуальную базу знаний: за её создание и поддержку отвечает аналитик. База знаний помогает сократить время онбординга и быстро находить ответы на вопросы по продукту.
- Участники разработки видят продукт под разными ракурсами: дизайнер — с точки зрения UX/UI и компонентов, разработчик — с точки зрения модулей, классов, архитектуры. У каждого — фрагментарное видение. Но хорошо работающий продукт — цельный продукт, поэтому его необходимо рассматривать как единую картину. Именно аналитик рассматривает продукт в общем и со всех сторон (так называемый «helicopter view»), формирует цельное видение результата и декомпозирует его: что должен спроектировать дизайнер, что — разработчик.
Чтобы показать заказчику ценность работы аналитика, лучше всего подойдет эксперимент. Это наглядно покажет, что затраты на работу аналитика полностью окупают экономию бюджета, которую он приносит.
Кейсы и лучшие практики в области системной и бизнес-аналитики, новости, вакансии и стажировки Surf — в телеграм-канале Surf BA Team. Присоединяйтесь!
- surf
- surfstudio
- бизнес-анализ
- бизнес-аналитика
- аналитика
- работа с клиентами
- работа с закачиком
- советы
- опыт
- мобильная разработка
- Блог компании Surf
- Анализ и проектирование систем
- Аналитика мобильных приложений
Источник: habr.com
beskov
Примем, что по умолчанию аналитическая работа так или иначе выполняется в любой команде, независимо от того, есть там выделенный аналитик или нет. В любом случае люди делают предположения, опираются на них, сообщают друг другу, проверяют их на практике.
На что влияет наличие выделенного аналитика в проекте:
- Обоснованность предположений
- Согласованность предположений и решений внутри проектной команды, с заказчиком и прочими контрагентами
- Полнота выявленных и закрытых рисков
- Кейсы — есть истории того, как конкретный специалист выявил проблему, помог команде принять сложное решение, сэкономил усилия, упростив требования и т.д.
- Удовлетворённость потребителей — сбор оценок «потребителей» работы аналитика, по любой шкале, с интеграцией оценок отдельных участников команды.
- Численный расчёт соотношения отдача / вложения.
С первыми 2-мя подходами мы уже работаем, однако у них есть свои недостатки, а именно — всё-таки может оставаться неясным, даёт ли этот специалист компании больше, чем забирает, или нет.
Численный расчёт хотя и прекрасен своей идеей объективности, на практике упирается в немалые ограничения. Но попробовать подойти к этой задаче всё-таки интересно.
На какие важные бизнес-показатели влияет системный аналитик?
Да всё те же:
- Cost — стоимость разработки
- Time — длительность выполнения проекта
- Volume — объём результата проекта
- Quality — качество результата проекта
Введение в проект системного аналитика, как и любого другого специалиста, должно повышать рентабельность проекта, которая выглядит как:
Volume * Quality / Cost
Какие бывают типовые положительные эффекты от выделенного аналитика:
При Fixed Scope (Volume):
Повышение Качества
Сокращение Длительности
Сокращение Стоимости
При Fixed Time:
Повышение Качества
Повышение Объёма
Сокращение Стоимости
Думаю, каким образом возможно повышение качества результата проекта пояснять особо не надо — это мы рассмотрели во 2-м абзаце.
Каким образом возможно сокращение длительности? Вовремя и полно выявленные и согласованные требования избавляют команду от 2-х традиционных бичей:
1. Переделки — когда не так поняли заказчика.
2. Переработки — когда недооценили объём работ из-за недостаточной детальности требований
Отсюда же следует и возможное сокращение стоимости, в случае Fixed Scope — за счёт сокращения длительности, в случае Fixed Time — за счёт сокращения размера проектной команды (скажем, 4 разработчика вместо 5).
Теперь осталось разобраться с единицами измерения. Cost можно выражать в человекоднях, если более точно — в деньгах. Volume можно выражать в количестве прошедших тестирование функциональных точек, способов применения или пользовательских историй. Quality можно мерять как % пройденных тестов.
23 comments — :
( 23 comments — Leave a comment )
(Deleted comment)
Если мы добавим ещё 1-го разработчика, то rework может стать и > 1 FTE, потому что каждый новый участник проекта увеличивает неопределённость и беспорядок 🙂 Типа пейте кофе (работайте по agile?) — делайте глупые вещи быстрее 🙂
Думал конечно, именно с этого и начал, просто всё это всё равно подчиняется общей формуле эффективности.
Разработчик еще может и не обладать способностями системного аналитика или желанием заниматься этой работой
Спасибо за интересный пост!
Несколько мыслей про проекты fixed cost, т.к. сама ими занимаюсь большую часть времени.
На мой взгляд, эффективность аналитика проявляется по завершении фазы согласования требований. Когда от заказчика начинают идти новые требования (которые именно новые требования, а не баги), или, говоря по-простому, CR. Соответственно, сколько из CR спецификация позволяет выполнить как CR, а не как баги ввиду пропущенных требований, характеризует качество требований, а соответственно, и эффективность работы системного аналитика.
Хорошие требования — это не только сокращение переделок или переработок. Возьмем идеальный случай: мы идеально поняли требования, записали, согласовали и реализовали. Переделки и переработки все равно будут 100%. Просто потому что бизнес меняется 🙂 Но без системного аналитика PM будет разруливать ситуации изменения требований «по-понятиям», а с системным аналитиком есть надежда, что 1) изменения будут оплачены 2) процесс внесения изменений будет прозрачен для заказчика.
Про измерение согласно той формуле, что ты написал — это отдельная тема, если хватит времени — сейчас напишу 🙂
На мой взгляд, соотношение числа чистых CR ко всем CR характеризует качество работы аналитика, а не его эффективность для проекта в бизнес-показателях (а мне хочется именно таких по определённым причинам).
Если он писал ТЗ полгода, а команда без него написала своё псевдо-ТЗ, и в результате чего команда без аналитика написала систему за +20% времени, чем могла с аналитиком, то такой подход может быть более рентабельным (см. выше коммент Антона).
здесь ключевой момент «может быть». А может и не быть.
Аналитик это скорее про митигирование рисков, чем про прямой экономический эффект. Это из серии «окупить страховку КАСКО».
Ну вот у нас возникают прагматические вопросы вида «Стоит ли ставить аналитика в проект, где команда состоит из 3-х человек?», «… из 4-х человек? 5-ти?», «Второго аналитика там, где в команде 10 разработчиков?», «Приносит ли этот аналитик больше пользы, чем вреда?».
Первое, что приходит в голову — обратиться к экспертной оценке менеджера проекта. Он, как правило, вполне может нелинейно просуммировать различные факторы и выдать оценку. А факторов много:
* особенности заказчика
* сроки проекта и текучка в команде (чем больше, тем более детальные нужны требования)
* переговорные способности менедежера проекта (чтобы CR-ы не пропихивали как баги)
* квалификация команды
* особенности предметной области
* квалификация и личность конкретных предлагаемых аналитиков
* и еще на пару страниц 🙂
P.S. Лена спать ушла, я за нее отдуваюсь 🙂 Завтра придет и проплюсует 🙂
Ну мы собственно именно этим сегодня и займёмся 🙂 Только в другой, субтрактивной форме — что будет с V,Q,C,T этого проекта, если из него изъять аналитика.
А если на уровне отдела на эту задачу смотреть, то это вопрос стратегический; «Несколько десятков аналитиков жрут несколько миллионов долларов в год. Где их вклад?». И ответ на него стратегический: факт наличия аналитиков позволяют нам решать задачу, поставленную акционерами: иметь высокие стандарты процессов разработки, а именно (CMM Lx, etc). В соответствии с методологией (RUP, etc), которой придерживаются такие компании как (IBM, etc) аналитик должен производить следующие артефакты (а, б, в, etc), что требует Х выделенных аналитиков на каждые Y разработчиков+тестировщиков.
В случае любого проекта хотя бы средней сложности (от 100К USD) будут договариваться «по понятиям» о большом количестве CR, так как сам бизнес и существующие компьютерные системы меняются. Нельзя описать то, чего не существует. А тут уже будет иметь значение sales — сможет убидить заказчика в том, что хорошо бы доплатить, или нет.
>> Полнота выявленных и закрытых рисков
Ты, наверное, имел в виду только риски, связанные с требованиями («заказчик получил не то», «исполнитель налетел на бесплатные работы» и пр). В целом в проекте кроме рисков, связанных с требованиями, уйма рисков на которые аналитик влиять не может.
>> Volume * Quality / Cost
Знаешь, что плохо в этой метрике? Оно неизмеримо на практике. Показатели слишком «мутные».
Померять реально можно только cost.
Volume — как мерять на практике функциональные точки на разных проектах, чтобы можно было хотя бы качественно сравнить? Те же юз-кейсы и истории могут просто отличаться на порядок по сложности, хотя количество будет одинаковое. В Факторе есть один юз-кейс — «очистить адрес», затраты на него измеряются в десятках человеко-лет 🙂
Quality — % тестов слишком слабый показатель, в одном проекте может быть один тест который проходит, а в другом — 5 из 30 падает, при этом сложность тестов может быть несравнимо. Ну и на нормальном проекте к моменту сдачи обычно проходят все текущие автотесты (при этом проект может бажить и разваливаться на лету :)).
Источник: beskov.livejournal.com