Можно ли улучшить эффективность разработки без взаимодействия с заказчиком?

4. 4 Недостаток или полное отсутствие информации Сложность ее поиска Отсутствие структурированной RMS Сложные внутренние коммуникации и отсутствие возможности проводить общение с бизнесом Недостаточная эффективность работы команд Dev и QA Проблемы

5. 5 “+” “-” Requirement Management и Knowledge Management програмномого продукта «Общее пространство» проекта Команда говорит «на одном языке» Четкое разделение зон ответственности Возможность проверки полноты и непротиворечивости требований Удобство оценки трудозатрат Подозрение на бюрократию Риск избыточности Сложность сопровождения

6. 6 Новая роль в команде Features QA Dev BATW

7. 7 Customer scenarios Помогают понять, какие бизнес- процессы сопровождает программный продукт Помогают понять особенности бизнеса Помогают испытать юзабилити Помогают понять реальные нужды заказчика

8. 8 Бизнес-требования Функциональные требования Нефункциональные требования Набор Бизнес-правил Описание UI Описание взаимодействия с внешними системами Ограничения (доступа, нагрузки и тд.) Сценарии прохода Критерии для тестирования Взаимосвязи компонент Requirement and Knowledge Management Systems

9. 9 Mind Map Определение основных направлений (функциональности приложения) Определение состава компонент Визуализация состава приложения Mind Map - способ фиксации процесса мышления, наиболее похожий на то, как рождаются и развиваются мысли и идеи в нашем сознании.

10. 10 Основные потребители спецификаций Что должна содержать в себе спецификация для улучшения эффективности Dev team и QA team Business needs and goals Process Flow Scenarios Business Requirements System Requirements External Integration Requirements Component Relations UI Description Оптимизация структуры документа

11. 11 Customer Journey Map

12. 12 Новый спринтовый процесс • New business needs • New user stories • Write-ups ВА • AS-IS model • Specification update • Component relations • Impact Analysis • Help with decomposition SA • Decomposition • Implementation DEV • Test case creation • System testing process QA

13. 13 Ускорен поиск информации о системе (до 5 мин) Эффективный анализ райтапов до имплементации Снижено количество дефектов Улучшен процесс взаимодействия команд Точная оценка трудозатрат Результат

14. Спасибо за внимание! Евгения Рабодзей erabodzei@oneincsystems.com Analyst, Team Lead

Editor's Notes

Всем приветДля начала представлюсь: Евгения Рабодзей, Краснодар.В аналитике уже около 6 лет. Начинала в АО «Тандер», работала в развитии информационных систем для логистики, сейчас с удовольствием развиваюсь в компании One Inc. Russia.Сегодня покажу, как качественно справляться с задачами бизнес и системного анализа без возможности каких-либо коммуникаций с заказчиком, или как принято говорить с кастомером, как построить эффективное взаимодействие между командами разработки и тестирования, каких результатов добились мы: Расскажу, с какими проблемами столкнулись Как развивались Какие приемы используем
Пару слов о компании и продукте, над которым работаем.Мы - продуктовая компания, представительство американской компании One Inc. (http://oneincsystems.com) на территории России и Украины. Разрабатываем линейку продуктов для страхового бизнеса США (автострахование, страхование недвижимости, жизни). Продукт, над которым работает команда из Краснодарского офиса AppOne – это полноценный продукты, объединяющий в себе Customer Relationship Management и Agency Management решения. Отсюда сразу становится ясно, что бизнес логика сложна как в ширину, так и в глубину. У нас - современный технологический стек, скрам с 2-недельными спринтами и мы никогда не стоим на месте. На базе огромного проекта постоянно рождаются и развиваются множество не менее интересных подпроектов, которые максимальноь интегрируются между собой.
Итак, с как все работало раньше? Есть продукт, команды Dev, QA и BA, которые непосредственно работали с пожеланиями заказчиков на стороне США. Изначально никто не вел единую и целостную документацию для продукта.Были частичные описания отдельных фич или их отдельных частей.Более того, 4 года назад компания перешла на трекинговую систему Jira и документацию перевели на систему Confluence, но при переходе большая часть знаний о продукте была потеряна. В связи с этим существовал ряд проблем, препятствовавших повышению эффективности команд
1)Информация о работе системы местами отсутствовала, местами была неактуальна, 2) ее было сложно искать, не были налажены процессы взаимодействия. поиск необходимых знаний порой занимал у специалиста больше одного рабочего дня!3) отсутствовала как таковая система управления требованиями, то, что было можно назвать беспорядочным набором знаний4)Более того, при отсутствии каких-либо описаний той или иной фичи приходилось обращаться с вопросами к коллегам из США, а это во-первых, отнимало их рабочее время, а, во-вторых, из-за разницы часовых поясов был немаленький временной лаг, что также тормозило работу над задачами.5) В результате систематически происходила задержка релиза в среднем на 5 дней, которую списывали на проблему с получением и доступом к информации.Таким образом возник вопрос, насколько на проекте нужна целостная система управления требованиями и база знаний и стоит ли тратить ресурсы на развитие полноценной такой системы?
Вам когда-либо доводилось начинать работать с проектом, которому уже, предположим, более 5 лет?А теперь представьте, насколько сложно в нем разобраться, если на протяжении всей его жизни никто не поддерживал , базу знаний о продукте в актуальном состоянии или вообще ее не вел? Я считаю, что такая система имеет право быть, более того, она должна обязательно присутствовать!+: 1. обеспечивает «общее пространство» проекта. Любой участник в любой момент времени может получить необходимую информацию как по конкретной задаче, так и по общему направлению работы. 2. Команда говорит «на одном языке» — ведь гораздо проще понять человека, сообщающего «об ошибке в функции, описанной в спецификации», чем «о непонятном баге в в какой-то фитче, которую кто-то там и когда-то там пофиксил». 3. Единая и актуальная база знаний позволяет четко определить зоны ответственности среди участников команды, а система упра 4. Документ наглядно помогает проверить полноту требований и их непротиворечивость 5. Также, накладывая новые задачи на описание текущей работы програмного продукта, мы можем намного точнее определить трудозатраты. Из «-»: 1. Изначально посмотрев на весь процесс сопровождения RMS, может показаться, что это бюрократия.Но я считаю, что это всего лишь предубеждение. И чем старше и масштабней продукт, тем выше потребность в развитии системы управления требованиями. Иначе можно просто запутаться, принять неверное решение и тд. 2. Не смотря на все «плюсы», очень часто выходит так, что некоторая информация в описании может быть избыточной.Для избежания такого риска нужно просто согласовать единую структуру документов и каждый раз после написания проходить по чеклисту необходимых характеристик документа:ЕдиничностьЗавершенностьПоследовательностьАтомарностьОтслеживаемостьАктуальностьВыполнимостьНедвусмысленностьОбязательностьПроверяемость 3. Также такие системы необходимо постоянно сопровождать, тк неактуальный документ сразу же теряет свою ценность и перестает приносить пользу как проекту, так и членам команды.
Для накопления знаний о работе системы к Dev и QA добавили роль технический писатель. В рамках нашего проекта основными задачами техрайтера были Банальная фиксация информации, уточнений и тд Описание модели «как сейчас это работает» Составление некоторых полезных статей по настройке тестового окружения. Основным и единственным потребителем такой информации стала команда QA.Техрайтер не мог принимать решений или участвовать в решении спринтовых задач, выдвигать предложения к новым фитчам и тд.То есть техрайтер = накопитель. Спустя некоторое время, выяснилось, что даже при увеличении покрытия информации не все, описанные ранее проблемы ушли.Да, поиск информации стал занимать меньше времени, но при этом так же было достаточно большое количество дефектов в новых фичах, также продолжали задерживать завершение спринта. Полного понимания того, чего же от нас в итоге ждет кастомер не было. И стало понятно, что команде необходим более сильный специалист, который сможет не только правильно развивать систему управления требованиями, но и участвовать в разработке, проводить анализ требований, предлагать альтернативные варианты решений проблем.Таким образом появились в команде системные аналитики, но это далеко не означало, что такие специалисты сию минуту все изменят и смогут сразу же устранить все накопившиеся проблемы, потому что 1 – покрытие описания системы примерно колебалось в пределах 30-40%, что на самом деле очень немного, 2 – не было понимания бизнеса в целом, потому что страховой бизнес США очень сильно отличается от российского, 3 – мышление конечного пользователя также отличается в связи с различиями в менталитете. Вывод – чтобы повысить эффективность всей разработки, нужно для начала вырастить аналитика и наделить его всеми необходимыми знаниями и скиллами.
Прежде всего эффективному аналитику необходимо понимать реальные потребности кастомера. Для этого очень помог Customer Scenario analysis. Все достаточно просто, мы играли в ролевую игру, встав на место нашего главного пользователя – продюсера.Сценарий — наглядное схематическое представление того, как пользователь решает свою рабочую задачу с помощью нашего продукта, что ему помогает и что мешает в достижении цели.Пользовательские истории и сценарии использования нужны для понимания основных мотивов пользователей и погружения в мир кастомера, сценарии использования помогают наиболее оптимально и удобно для кастомера спроектировать интерфейс, помогают оптимально провести тест и исселовать юзабилити системы.Мы как раз-таки это сделали – попробовали продать страховой продукт, при этом обращали внимание, на каком этапе, какие шаги вызывают сложности и потерю времени (конкретно для нашего кастомера очень важен временной аспект, потому что чем больше страховых продуктов за день он сможет обработать и продать, тем больше денег в итоге он получит).Таким образом, проведя подобный анализ мы достигли следующих целей: Узнали, какие процессы сопровождает продукт Поняли особенности бизнеса Проверили юзабилити Поняли, что для кастомера наиболее важно.
После того, как мы продвинулись к пониманию того, что же хочет от нас получить заказчик, с какой целью он использует разрабатываемый продукт, можно приниматься за разработку системы управления требованиями, приводить в порядок все мануалы по описанию моделей, создавать структуру документов. Система управления требованиями прежде всего должна содержать в себе как минимум: Бизнес-требования Функциональные требования Системные требования Набор Бизнес-правил Описание UI Описание взаимодействия с внешними системами Ограничения Сценарии прохода Аксептэнс тест критерии Взаимосвязи компанент продукта В принципе, все это в той или иной мере и степени готовности у нас имелась перечисленная информация, но она опять же была не упорядочена, нечитабельна и сложна для понимания.Иногда, чтобы понять, как проверить работу той или иной фичи необходимо было проводить целое расследование. Стоит отметить некоторую особенность принципов документирования в нашей компании.У нас есть два типа документов – specifications – это те документы, которые относятся к Knowledge Management – это полноценное описание системы, функциональностей, которые она выполняет, то есть это полный набор знаний о продукте. Над такими документами работаем мы – аналитики в России.Второй тип – requirements или write-ups – это документы описывающие новые требования, за них отвечают аналитики США, которые непосредственно общаются с бизнесом. Наложив, write-up на спецификацию, можно получить полноценную картину, как работет сейчас и что нужно изменить, чтобы удовлетворить новые потребности бизнеса.
Следующий шаг – структурировать нашу систему управления знаниями о продукте Для этого необходило было систематизировать дерево спецификаций.Перевое, что пришло в голову – упорядочить в соответствии деревом меню приложения.Но такой подход не оказался таким удобным, как изначально ожидалось. Потому что, как я и говорила, задачи нашего продукта не только Customer relationship management, но и Agency Management, то есть для прогона того или иного процесса, необходимо установить различные настройки на разных уровнях (админка, уровень организации, офиса , настройки интеграций с внешними системами и тд.)Поэтому необходимо было оъединить документы по функциональным направлениям продукта.Но прежде нужно определить такие направления.Здесь mind Map подходит как ничто лучше, с ее помощью мы не только смогли понять в каких бизнес- направлениях работает продукт, определили, в каких функциональностях участвуют те или иные сущности и компоненты, как они между собой связаны.Итак, карта мыслей помогла нам: Выделить функциональности Компоненты Визуализировать все взаимосвязи В настоящий момент мы пользуемся тулом Wiki Confluence (есть, конечно более удобные тулы, но wiki вполне подходит для достижения наших целей). Поэтому у нас можно увидеть порядок документов как по дереву меню приложения, так и применив поиск по лейблам посмотреть группировку по функциональностям и компонентам. Такой подход помог как разработке, так и тестированию работать эффективней.Разработчики без доп анализа огромного кода глядя на карту понимают, на что может повлиять требуемая имплементация, а тестировщики, понимают, какие места приложения нужно дополнительно проверить на предмет «неожиданных поломок»))
Но на этом мы не остановились и решили не только увеличить покрытие документации(организовав удобную структуру RMS), но и улучшить качество самого документа.К этому моменту я уже получила много обратной связи о том, что нужно улучшить, чего не хватает, что неудобно для восприятия от всех членов наших команд.Пожелания, а иногда даже противоречивыми, и нам стало понятно, что необходимо найти оптимальный компромисс, ту самую золотую середину.Что делать? Для начала необходимо определиться с основным потребителем документа.На данный момент у нас есть 4 группы:Dev teamQA teamBA teamCustomer Support team. Чтобы отдать приоритет одной из групп мы ответили на вопросы: Why – почему та или иная команда использует спецификацию? What – что она должна содержать? Who – кто ее использует? When – когда ее используют? Where – где ее необходимо использовать? В итоге приоритет номер один выиграли ребята из отдела тестирования. Почему? Все просто, именно они дают итоговую оценку стабильности релиза. Именно они при заведени багов должны точно знать, что должен делать продукт и какие ожидания пользователя. Именно они это делают постоянно именно они должны сравнивать ожидаемое поведение . Разработчики же используют спецификацию для ознакомления код все-таки верен или как должна работать фича, для которой пришел запрос на доработку или исправление. Бизнес аналитики сверяют новые нужды клиента с текущими возможностями продукта. Кастомер саппорт тим реже всех обращаются к спецификациям чтобы понять я вляется баг, прилетевший с продакшена ошибкой, или так и было задумано. С наиболее приоритетным потребителем определились, теперь состав и структура документа. Как выяснилось, самым первоочередным пунктом – были цели и нужды кастомера. (Объясню, раньше, когда нам приходили райтапы пункта нужды, ии проблемы кастомера отсутствовали, а цели были описаны очень скудно. Например, необходимо, чтобы «отчет выгружался по пятницам в 10 утра». То есть не совмсем понятно, почему именно 10 утра, может его можно формировать заранее, например ночью и дать возможность пользователю выгружать отчет в любой момент времени по требованию. То есть вместо реальной задачи нам предлагали просто решение, которое не факт, что было наиболее оптимальным и замыливало взгляд других членов команды. Теперь же, мы обсудили и добились, чтобы нам более полно описывали в первую очередь проблему, которую нужно устранить, таким образом мы можем найти несколько вариантов решения и в итоге имплементировать наиболее оптимальное) Также документ должен обязатеьно содержать описание бизнес-процесса, сценарии использования, бизнес-требования, системные требования(здесь же и ограничения), правила для интеграции с внешними системами, взаимосвязи компонент, чтобы можно было понимать, на что доработка в конкретной фиче может еще повлиять, и, конечно описание UI (Дисплей рулы и валидация). НО, так как у нас продукт предназначен еще и для зада Agency Management, то у нас есть документы по описанию логики отчетов, там структура несколько иная: есть еще описание фильтрации, принципов формирования отчета, частота использования и тд.
Итак, мы уже поняли, как работает кастомер и какие основные потребности должно удовлетворять приложение, разработали концепцию RMS, структуру и содержание спецификаций, расставили приоритеты среди пользователей, сейчас с успехом восполням недостоющее описание логики продукта. Но все еще продолжаем сталкиваться с тем, что не до конца понимаем, что «чинить в первую очередь», как найти проблемы с UX как его улучшить. Какими приемами мы пользуемся когда сталкиваемся с такой проблемой? В этом случае, для исследования UX мы применяем Customer Journey map (инструмент визуализации взаимодействия потребителя с продуктом или услугой). Создание CJM – это одновременно и процесс анализа, и метод генерации идей по совершенствованию продукта. CJM отображает взаимодействие, развёртываемое во времени, разложенное на атомарные составляющие. Составляющие взаимодействия относятся как к процессу (цели и задачи потребителей, их действия, ожидаемый результат, проблемы и барьеры, препятствующие переходу на следующий шаг, точки касания (touchpoints), материалы, инструменты, оборудование, KPI с точки зрения бизнеса и т.д.), так и к психоэмоциональному состоянию потребителя (мысли, чувства, эмоции). CJM наглядно демонстрирует: ожидания клиентов узкие места в бизнес-процессах возможности для изменений, улучшений UX Иными словами, этот инструмент будет полезен, если кастомеры представляют для вас значимую ценность и вы хотите видеть свои цели, в первую очередь, ориентированным на клиента. Как говорится, сделать жизнь кастомера лучше. Хочу пояснить, что такой прием подходит далеко не во всех случаях. Вот например, какую-то глубокую логику расчета заработной платы с помощью такого приема понять невозможно.Здесь необходимо уже выяснять, сопоставлять требования, исследовать систему совместно с аналитиками бизнеса.
Таким образом аналитик на нашей стороне стал достаточно компетентным специалистом для принятия решений, ему стали доверять члены команд Dev и QA.И со временем мы вклинились в спринтовые процессы разработки новых фич, решения новых задач. Ранее на входе в спринт разработчик получал writeup, декомпозировал его кое-как, если возникали вопросы, то приходилось ждать каждый ответ не менее суток, после имлементации задача переходила в тестирование. Из-за не очень ъорошего понимания бизнес-процессов и отсутствия полноценного описание «как было», находили очень много дефектов, на устранение которых также приходилось тратить время.Что происходит сейчас.Еще до планирования нового спринта, аналитик разбирает потенциальные задачи, анализирует райтапы, проводит Impact анализ, определяет связные описания текущей работы продукта, то есть подготавливает основательную базу для разработки и тестирования. Таким образом мы каждый раз стараемся сделать все, чтобы спринт прошел гладко с минимальными потерями времени и ресурсов.В самом начале спринта аналитик совместно с разработчиками проводит декомпозицию(то есть разбиение задачи на множество мелких подзадач), указывая на все места в продукте, на которые может повлиять имплементация. Также на декомпозиции мы объясняем, как это работет у бизнеса и что из всех доработок кастомеру важнее всего.
Как все это помогло на практике: Члены команд должны тратить на поиск информации не больше 5 минут, ведь теперь есть описание системыПри отсутствии какой-либо информации больше нет необходимости самостоятельно ее искать и опять же тратить время. QA и Dev команды просто переводят задачи на нас, не теряя своего времени. Райтапы проходят ревью на наличие «подводных камней»(Impact analysis) еще до того, как начинается процесс имплементации, что также помогает лучше распределить ресурсы на этапе планирования. Как следствие, снижено количество дефектов на 68% (в этом помог анализ райтапов) Мы стали лучше понимать цели, мы их унифицировали и конкретизировали. И как дополнительный бонус всегда есть под рукой российский аналитик, который понимает потребности пользователя, это очень полезно при принятии решений в условиях удаленности от кастомера. И полностью устранен «пинг-понг» между бизнес-аналитиком США и российским разработчиком Стала точнее оценка трудозатрат, потому что мы точно определяем влияние доработки и ее масштаб Чтобы подытожить, хочу отметить, что каждый из перечисленных подходов далеко не новый и уж тем более не инновационный.Но абсолютно точно могу сказать, что каждый из них нужно использовать на нужном этапе и с правильными целями.Сценарии, например, помогают выделить бизнес-процессы кастомераCJM помогает с UX вопросами. Помогает понять именно взаимодействие с продуктом с точки зрения пользователя и найти узкие места. Описание «As-Is» модели помогает четко понимать, в каком месте необходимо, что-то изменить, чтобы добиться цели в срок.Разбиение на компоненты и взаимосвязи помогает не допускать большое количество ошибок при разработке и отдавать кастомеру обновления в срок.Таким образом мы добились повышения эффективности, используя множество пусть даже базовых приемов в совокупности. Я уверена, если бы мы пользовались постоянно только одним из них, то не смогли бы достичь текущих результатов и не наладили бы процесс работы и взаимодействия команд.
Вопросы?

Можно ли улучшить эффективность разработки без взаимодействия с заказчиком?

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (11)

Similar to Можно ли улучшить эффективность разработки без взаимодействия с заказчиком?

Similar to Можно ли улучшить эффективность разработки без взаимодействия с заказчиком? (20)

More from SQALab

More from SQALab (20)

Можно ли улучшить эффективность разработки без взаимодействия с заказчиком?

Editor's Notes