Оценка влияния бизнес-аналитика на скорость работы команды
•Télécharger en tant que PPTX, PDF•
0 j'aime•381 vues
Доклад Дениса Голубева на конференции Analyst Days-6 www.analystdays.com
Recommandé
Recommandé
Contenu connexe
Similaire à Оценка влияния бизнес-аналитика на скорость работы команды
Similaire à Оценка влияния бизнес-аналитика на скорость работы команды (20)
Plus de SQALab
Plus de SQALab (20)
Оценка влияния бизнес-аналитика на скорость работы команды
- 1. ОЦЕНКА ВЛИЯНИЯ БИЗНЕС- АНАЛИТИКА НА СКОРОСТЬ РАБОТЫ КОМАНДЫ ДЕНИС ГОЛУБЕВ, ДМИТРИЙ ЛЮТИКОВ (соавтор), 2017 Sayan Mountains, Bear Lake
- 2. 2CONFIDENTIAL ОБ АВТОРЕ Денис Голубев. Product Manager, в недалёком прошлом – Senior Business Analyst, a в более отдалённом — биржевой финансовый аналитик. Профессиональные интересы. Методы оценки эффективности работы распределённых команд разработки ПО, анализ бизнес- процессов, управление рисками, математическая статистика. Образование. Ижевский государственный технический университет им. М. Т. Калашникова, факультет «Прикладная математика», специальность «Экономист-математик» (2005 г.).
- 3. 3CONFIDENTIAL СИТУАЦИЯ Заказчик. Холдинг, занимающийся предоставлением через интернет букмекерских услуг и услуг онлайн-казино. Территориально – Лондон, Великобритания. S.T.A.R. Команда. Около 30 человек: разработчики, тестировщики, бизнес-аналитики, дизайнеры. Проект. Семейство сайтов, оптимизированных для работы на мобильных устройствах. Контент преимущественно приходил от API, основная часть задач разработки относилась к фронтенду.
- 4. 4CONFIDENTIAL ЗАДАЧА Проблема. Аналитическая стадия стала узким местом всего процесса разработки. S.T.A.R. Предложенное решение. Подключение к процессу BA с одновременным разделением процесса на анализ требований и анализ компонентов. Бэклог Анализ Разработка
- 5. 5CONFIDENTIAL ДЕЙСТВИЯ S.T.A.R. Обзор • Все ли UC отражены? • Все ли требования достаточно детальны? • Учтены ли возможные исключительные ситуации? • Все ли нужные активы (цвета, иконки и т.д.) предоставлены? Уточнение • Упущенные UC или альтернативные варианты UC • Уточнение требований • Запрос отсутствующих активов • Оценка возможных решений (с командой) Дополнение • Дополнение спецификации UC, вариантами UC, активами • Согласование с Заказчиком • Перевод тикета на этап анализа компонентов (теханализа)
- 6. 6CONFIDENTIAL Группа A – тикеты, которые были проанализированы без участия BA. Всего 19 шт. Среднее время нахождения на этапе анализа – 13.5 ч.-дн. (человеко-дней). Группа B – тикеты, в анализе которых участвовал BA в составе команды. Всего 7 шт. Среднее время нахождение в анализе (анализ требований + теханализ) – 8.9 ч.-дн. Вывод – участие BA из числа членов команды в анализе требований сократило среднюю продолжительность данного этапа в 1.52 раза (т.е. на 34%) 34% 66% РЕЗУЛЬТАТЫ (ч. I) S.T.A.R.
- 7. 7CONFIDENTIAL РЕЗУЛЬТАТЫ (ч. II) S.T.A.R. Группа тикетов Длительность фазы анализа, ч.-дн. в ср. Малые 10.3 Средние 18.6 Большие 21.7 Малые Средние Большие
- 8. 8CONFIDENTIAL РЕЗУЛЬТАТЫ (ч. III) S.T.A.R. 2 17 10 Малые Средние Большие Уменьшение общих трудозатрат на тикет, человеко-дней, в среднем Вывод Эффект сокращения общего срока работы над тикетом наблюдался в каждой из групп, но наиболее заметным он был для групп «Средние» и «Большие».
Notes de l'éditeur
- Добрый день, коллеги! Меня зовут Денис Голубев. В данный момент я Product Manager в одной не слишком известной (пока!) компании, но в недалёком прошлом я работал бизнес-аналитиком на ряде проектов с иностранными заказчиками, а ещё раньше – был биржевым финансовым аналитиком. Закончил я факультет прикладной математики Ижевского государственного технического университета в 2005 году. Специальность – «Экономист-математик». Немного экономики и много математики. Не вся она пригодилась в дальнейшей жизни и работе, но вот теорвер и матстат – пригодились. Мне живо интересны методы оценки эффективности работы распределённых команд разработки, а главное – как эту эффективность повысить. Ключевую роль, на мой взгляд, в решении этой задачи играет управление бизнес-процессами, в которых взаимодействуют разные подразделения команды. Об одном опыте такого управления я бы и хотел вам рассказать.
- Заказчиком на том проекте выступала средней величины британская компания, специализирующаяся на «оказании услуг» (если можно так сказать) онлайн-казино и букмекерства (в основном ставки на спорт, но не только). Проект охватывал семейство сайтов различных региональных подразделений Заказчика в разных странах. Сайты имели разный дизайн и «разговаривали» на разных языках, но имели общий «движок» и API. Доработкой и поддержкой этих сайтов и занималась команда, б.ч. которой находилась в Ижевске (Удмуртская Республика), а меньшая (в основном, дизайнеры) – в Восточной Европе. К моменту моего прихода на проект в качестве бизнес-аналитика, на нём уже были сложившиеся бизнес-процессы, построенные вокруг канбан-доски с тикетами-задачами на ней, и неким своим пониманием принципов Agile (ну, как это обычо и бывает).
- В один не совсем прекрасный день Дима Лютиков, team coordinator с нашей стороны, заметил, что на доске отражается проблема: тикеты накапливались в колонке «Анализ», и висели там по многу дней, а то и недель. Налицо был «боттлнек», связанный с тем, что анализом (как требований так и технических компонентов) занимались те же разработчики, которые потом тикеты реализовывали. Совершенно естественно, что у них в приоритете было написание и рефакторинг кода, а никак не коммуникация с BA Заказчика, которая, к тому же, в то время велась преимущественно по eмэйл. Ребята занимались несвойственным им делом, занимались добросовестно (серьёзных «косяков» удавалось избегать), но очень медленно. В результате координатором было предложено решение в виде подключения к команде BA с нашей стороны, который бы взял на себя анализ собственно требований, отделив его от анализа компонентов, необходимых для разработки (в дальнейшем называвшийся, обычно, «теханализом»).
- [WIP: На этом слайде я не планирую останавливаться надолго, надо рассказать его за 2-3 минуты] Основные этапы аналитической стадии работы над тикетом представлены на диаграмме. Как правило, требования передавались нам в виде пожеланий бизнеса с начальной степенью проработки бизнес-аналитиками заказчика. Результат часто обладал смысловой связностью, но при этом почти всегда ему не хватало таких вещей, как описание поведение системы в exceptional cases, необходимые активы и т.д. Всё это запрашивалось в ходе этапа уточнения и затем фиксировалось в спецификации в том или ином виде. После этого тикет пускался дальше – на подготовительный этап разработки, носивший имя «Теханализ».
- [WIP] Для целей анализа бралась простая средняя по двум выборкам. Время работы по дням определялось по логам Jira с точностью до часа и минуты когда происходил перевод тикета между этапами, которые затем приводились к дням и округлялись до первого знака после запятой. Оценённые таким образом по общей длительности аналитической фазы тикеты были разнесены по двум группам: в группу «А» попали те, которые разработчики анализировали самостоятельно, без участия BA: в группу «B» - те, участие в анализе которых принимал BA. Средняя длительность аналитической фазы в случае второй группы оказалась чуть более чем на треть меньше, чем у первой группы.
- [WIP: Тут важно донести до аудитории четкое понимание того, что вот есть фаза аналитики в рамках всего процесса работы над тикетом, и есть общее время этой работы. Сокращение зафиксировано именно по общей продолжительности, т.к. ранее бывали случаи, когда без BA тикет быстро «проскакивал» анализ, но затем «увязал» в девелопменте. Именно по причинам невыявленных или недопонятых требований. Ну и общий вывод в конце какой-то должен быть, пусть и краткий (на 1-2 минуты)]
- [WIP] 1. Границы применимости в плане фазы проекта. Была фаза Delivery. На этапе обсуждения T&M лучше послушать других (докладчиков). 2. История взаимоотношений с заказчиком – долговременные, проект не в красной (а лучше в зелёной) зоне, большие планы по развитию. 3. Предостережение: в случае, если Заказчик имеет культуру ведения бизнеса, ориентированную скорее на внутрикорпоративные интересы, нежели на результат в виде продукта, аргументацию, подобную изложенной в докладе, с ходу применять не следует. Что, впрочем, не снимает с хорошего аналитика обязанности стремиться повлиять на мировоззрение заказчика в том направлении, которое позволит лучше и быстрее решать задачи, стоящие перед проектной командой.