Принятие изменений в существующем продукте почти всегда связано с высокими рисками. Что делать бизнес-аналитику, получая запрос на изменение, зачем вовлекать в процесс команду и как договариваться с заказчиком, спросили у BA team lead EPAM Михаила Бахраха.
Привет, меня зовут Михаил Бахрах, в статье поделюсь практическим опытом, накопленным за последние 8 лет в бизнес-анализе. Основные типы проектов, в которых я участвовал — это Greenfield, Business transformation, Re-engineering types, длительностью от 6 до 18 месяцев. Сейчас работаю business analyst team lead в компании EPAM.
Важный момент: я буду говорить об изменениях в контексте уже заимплементированного инкремента продукта. То есть, речь пойдет о change request процессе, когда изменение возникает на основании чего-то разработанного.
Расскажу, какие изменения могут возникнуть на этом этапе, на что способны повлиять, как правильно оценивать change request и управлять изменениями.
Критерии оценки и виды изменений
При оценке, как один из основных факторов, нужно учитывать тип проекта и тип контрактных обязательств. Популярные форматы проектов это Waterfall и Agile. Если говорить о контрактных договоренностях, чаще всего это будут Fixed Price или Time and Materials.
Кроме типа проекта, для оценки изменения важно учитывать фазу работ, финансы, коммуникации, архитектуру и политику компании заказчика.
Waterfall — подход к деливери методологии, когда итоговое решение и сроки определены заранее, а команда должна воплотить все максимально подробно.
Это поэтапная методология разработки в долгосрочной перспективе. Сначала делают анализ продукта, потом дизайн, разработку и тестирование. Соответственно, чем более поздняя фаза, тем дороже будет проект.
Кажется, что при Waterfall подходе очень трудно вносить изменения в процессе работы. Однако тут нужно учитывать фактор «политики» компании поставщика услуг — насколько важен для компании клиент вне контекста «заработать денег» и какие бюджеты заложены в проект.
Waterfall априори подразумевает существенные риски, ограничения и assumptions, поэтому в бюджет часто закладывают довольно большие деньги. Так что иногда клиенту могут «бесплатно» подтвердить разработку дополнительного изменения.
Agile — не подход, а скорее, mindset с разными фреймворками, которые используются как методологии по деливери разработки продукта. В Agile разработка происходит по циклам-итерациям: каждые 2-4 недели команда выдает рабочий инкремент продукта.
Если результат не понравился — команда исправляет; понравился — работаем дальше. Тут, конечно, многое зависит от типа контрактных отношений, но об этом дальше.
Fixed Price — связан не с методологией, а с подходом к контрактным обязательствам клиента. Fixed Price — это ограничение по бюджету, а в большинстве случаев, еще и по времени и ресурсам.
Например, клиент спрашивает:
— Сколько будет стоить ваше решение?
— 500 тысяч.
— Хорошо, — говорит клиент, — я даю эту сумму, а вы должны уложиться в нее и сделать решение.
Заказчик хочет видеть результат, но одновременно, есть только 500 тысяч. Если у клиента ограничен бюджет, то будет и ограничение по таймлайну, и это нужно учитывать при оценке, обсуждении и принятии решения по изменению. Важно доносить до заказчика, что кроме нарушения таймлайна, новое изменение потребует дополнительных денег.
Time and Materials — противоположность Fixed Price, больше применимо к Agile.
Здесь клиент может сказать:
— Нужно разработать вот это, но я еще не уверен, что хочу видеть в финале. Давайте пока 10 разработчиков, сколько они стоят в месяц?
— 100 тысяч долларов.
— Я буду платить 100 тысяч в месяц, — говорит заказчик, — и смотреть на результат. Изменения в Time and Materials могут легко подтверждаться клиентом, так как он платит за людей, а не за объем работ.
Но нюансы здесь все же есть: даже когда у заказчика имеет большой бюджет и возможность увеличивать ресурсы, у него все-равно будут ожидания по времени окончания определенной фазы или всего проекта. И вот тут важно отслеживать изменения, так как они могут существенно сдвигать сроки окончания проекта.
В данной статье я разделил типы изменений по иерархической сегментации изменений относительно решения. Изменения делим на 4 группы: точечные, уровень целостных функций, уровень компонент системы и кросс-компонент или уровень экосистемы.
Точечные изменения
Примером точечного изменения на фронтенде может быть название кнопки, навигация и т.д. Для бэкенда это будут: api запрос, калькуляции, технические и бизнес правила и т.д.
Как выглядит точечное изменение в реальном кейсе:
В системе отображался список объектов, например, маркетинговые кампании, а в них — список элементов. Когда пользователь хотел переместить элемент из одной папки в другую, то нажимал «выбрать папку/элемент/файл», — и система показывала попап с плоским нераскрытым списком элементов (файлов и папок).
Приходит запрос от заказчика: «Давайте переделаем, чтобы в попапе сразу видеть всю древовидную структуру для выбора файлов».
С точки зрения user interface изменение кажется простым, но, прежде чем принимать решение, нужно посмотреть, какие критерии оценки затрагивает ситуация:
- Коммуникации — действительно ли все согласны на изменение. Сначала я пообщался с заказчиком, потом пошел к разработчикам и QA. Команда сказала, что изменение не такое уж простое, потому что придется выдернуть из сторонней системы список файлов и папок с помощью api. Причем, выдергиваем только первый уровень, а этих уровней может быть 5 или 10, и значит, производительность визуализации в UI будет перегружена.
- Элементы архитектуры. Запрос выглядел настолько точечным и простым, что можно было сказать разработчикам: «Ребята, измените визуализацию с одноуровневого списка на древовидный». Но когда начали выяснять подробности, оказалось, что на уровне бэкенда изменение повлияет на архитектуру.
- Фаза работ. К тому времени, мы уже имплементировали api, который выдергивал первый уровень файлов и папок. Чтобы поменять одноуровневый список на древовидный (сразу показывать 2-4 уровня), пришлось бы изменить api и просить поставщика — стороннюю систему, — поддержать многоуровневый возврат запроса для этого api. Соответственно, я как ВА, понимал, что в фазе, когда api уже заимплементирован и существуют договоренности с заказчиком, не реалистично менять вид списка.
В итоге, заказчик отказался от древовидной структуры файлов, когда ему объяснили, что придется переделать api и договориться со сторонним поставщиком об изменении структуры его сервисов по предоставлению списков данных.
Уровень целостной функции (фич/ feature)
Если в процессе разработки, заказчик попросил новую функцию или захотел изменить бизнес-правила, это будет примером изменений на уровне фич.
Продолжу пример со списком объектов:
Клиента устраивало, что в системе есть файлы и папки, но еще, заказчик просил добавить возможность копирования, например из корневой папки в папку второго уровня.
Мы приняли запрос с учетом двух критериев оценки:
- Финансы: поскольку функцию копирования не обсуждали и не утверждали в договоре на решение, мы хотели попросить за нее дополнительную оплату в рамках Fixed Price проекта.
- Политика: конечно, новый функционал потребовал бы дополнительной оплаты. И здесь появляется фактор политики: можно было предложить заказчику, что фича будет стоить меньше денег или включить оплату в следующий контракт.
Мы искали лучшее бизнес-решение, поэтому приняли изменение и выставили счет, а дальше решал заказчик.
Уровень компонентов
На средних и больших проектах бывают компоненты, которые разбиваются между командами по релизам, майлстоунам и т.д. Примеры: глобальное изменение, когда задействованы несколько компонентов, например, каталог, база данных клиентов, обработка заказов внутри одной системы.
Конкретный пример, с которым я столкнулся, — это изменение интерфейса на сайте подарочных сертификатов.
Мы создали фронтенд интерфейс для продажи сертификатов, заимплементили его и шли дальше. В какой-то момент, в кулуарах, заказчики и стейкхолдеры обсудили такое требование: «Хотим, чтобы пользователь на этапе выбора сертификата и на этапе после покупки видел два разных юзер интерфейса».
Проект был Agile и Time and Material, то есть, клиент платил фиксированную сумму в месяц. Нюанс был в том, что мы уже запланировали и разработали интерфейс для обоих типов действий пользователя: когда человек купил сертификат и когда только подбирает.
Поэтому, ключевым критерием оценки стала фаза проекта. На начальном этапе мы бы просто изменили дизайн и разработали то, что хотел заказчик. Но мы были на фазе почти готового UI.
Мы активно коммуницировали с заказчиком, объясняя:
- какими способами можно совершить изменение;
- насколько серьезную работу придется провести;
- как это отразится на таймлайне.
В итоге, изменение подтвердили и согласовали с заказчиком сдвиг сроков.
Кросс-компонент/экосистем уровень
Экосистема — слово, достаточно популярное в IT-сфере, — нечто логичное, эргономичное, «бесшовно» включенное в нашу жизнь. Об экосистеме говорят, когда создается рабочий продукт, полностью соответствующий потребностям бизнеса. Например, большой Enterprise проект, где команды по 30-40 человек делают разные компоненты, и все это в целом — одна экосистема. В таком проекте изменение логики работы функции повлияет на несколько компонентов или на всю систему.
Пример из практики: Метод подсчета и сбора денег за сервис
Заказчик продавал товары, и каждый месяц брал с клиента деньги за определенный сервис. В системе подсчета были недостатки, поэтому приходилось постоянно что-то поправлять вручную.
В процессе оплаты были задействованы несколько отдельных подкомпонентов системы: вычисление суммы, выставление счетов, определение, какой именно продукт использовать для каждого клиента.
Заказчик хотел внести изменения в существующий продукт, и в этом случае мы делали акцент на политику компании, потому что серьезное изменение нужно было внести в Waterfall проект, в котором все заранее обговорено.
Изменение повлияло на работу многих компонентов системы, поэтому пришлось предварительно обсуждать с заказчиком мельчайшие детали.
Эти реальные примеры показывают, что даже точечное изменение, которое на первый взгляд выглядит несерьезным, может иметь влияние, соизмеримое с уровнем кросс-компонентов.
С точки зрения сегментации на уровне solution, точечное изменение выглядит мелочью по сравнению с компонент левел. И если бизнес-аналитик не разберется, то может получить подобный запрос от клиента и подумать: «Что там, просто кнопку изменить, это быстро». ВА напишет дополнительные требования на изменения, подтвердит и пообещает сделать.
Но бизнес-аналитик, допустим, не учел, что небольшое изменение влияет на архитектуру стороннего приложения, по которому у заказчика нет контракта на внесение changes.Тогда получится, что точечное изменение может стоить 500 тысяч, а компонент левел — только 250 тысяч.
Поэтому даже к тому, что выглядит небольшим и несерьезным, бизнес-аналитику лучше относиться с тем же уровнем ответственности, как и к тому, что сразу выглядит очень серьезно.
Дальше расскажу, какие 4 правила всегда помогают мне держать изменения под контролем.
Управление изменениями
Здесь пойдет речь не столько о последовательных шагах по управлению, сколько о ключевых правилах, которые я держу в голове, работая с любыми изменениями. Понимание и соблюдение этих правил всегда приносит value для заказчика, независимо от того, будут изменения приняты или отвергнуты.
- Выяснять причину изменений, почему появилось конкретное требование. Изменение может быть вызвано желанием заказчика что-то улучшить (business need) либо решить какую-то проблему, которую не обнаружили своевременно.
- Сохранять прозрачность процесса. Это значит, что я никогда не пытаюсь поскорее решить проблему, поговорив всего с 1-2 людьми, или создав ticket без всяких пояснений. Важны коммуникации и включенность заказчика, команды, заинтересованных людей со стороны заказчика, чтобы все понимали происходящее.
- Сотрудничать с заказчиком. Смысл этого правила в позитивном, активном и совместном взаимодействии с заказчиком на формальном и неформальном уровнях.
- Управлять временем. В работе с изменениями все должно быть ASAP, потому что change management априори в топ-приоритете.
Как работают эти 4 правила, покажу на примере:
Запрос на изменение возник на этапе UAT (user acceptance testing). UAT — это финальная фаза выдачи продукта, которая есть в любой методологии. Разработанный продукт отдают на тестирование конечному клиенту или пользователю. Например, для системы продажи путевок, продукт может тестировать турагент: как все работает.
Если пользователь находит какую-то проблему, то передает ее выше по структуре своей организации.
Мы разрабатывали систему для продажи продуктов ТРК потребителям, а конечными пользователями были работники самой компании.
И вот, в процессе приемки, один из таких пользователей приходит к своему начальнику — руководителю отдела продаж и говорит:
— Я вижу, что в профиле заказа для клиента отсутствует необходимое поле «адрес 2», а мы не можем пользоваться системой без этого поля.
Руководитель отдела продаж связался с владельцем продукта со стороны заказчика — и сказал, что на сегодня, задача с полем для адреса — самая критичная и нужно разобраться как можно скорее.
Владелец продукта пришел ко мне и тут сработало третье правило: сотрудничество. В процессе работы на проекте, я постоянно создавал informal подход в отношениях с клиентом, и это было взаимовыгодно. Поэтому клиент не возмутился, не передал проблему моим менеджерам, а сказал: «Давай обсудим, что можно сделать с этой проблемой».
Здесь я включил первый пункт: выяснение причины, — и стал расспрашивать: «Что не так с этим адресом?» Мы готовили продукт около года, выясняли детали, я сам стоял в точках продаж, смотрел как клиентам продают, как оформляют. И этого поля с адресом не было в требованиях.
Я сказал product owner-у: «Давай не будем копать в детали только с тобой, а обсудим все вместе. Можешь организовать митинг с руководителем отдела продаж и с пользователем, который понял проблему?»
Здесь было задействовано правило прозрачности процесса: я не говорил, что у нас change request management, поэтому давайте оформим тикет, обсудим с вами, потом я обсужу это с менеджерами и т.д. Я был абсолютно прозрачен: не понимаю проблему и готов ее обсудить.
Product owner организовал митинг, мы собрались и стали выяснять в чем проблема. Пользователь ответил, что нет поля «адрес 2», которое он вводил на протяжении последних десяти лет.
Дальше диалог был примерно таким:
— А к чему это ведет? В чем проблема, если адреса нет?
— Ну, я всегда его ввожу.
— А зачем это нужно?
— На самом деле просто у меня есть указание всегда его вводить.
Он посмотрел на своего руководителя отдела продаж и спросил:
— Зачем мы его вводим?
А руководитель сказал:
— Я думал, ты мне ответишь.
Затем они попросили время на обдумывание и, в итоге, сообщили, что это поле не важно. Проблема была решена без привлечения вышестоящего менеджмента, дополнительных денег, смещения сроков и т.д.
Эти четыре фактора: причина, прозрачность, сотрудничество и время, помогают правильно обрабатывать требования заказчика. Дальше расскажу, почему важно соблюдать порядок в оценке любого изменения.
Как узнать, что изменение необходимо
В работе я оцениваю необходимость изменения пошагово. На первом шаге смотрю, в чем value предложенного изменения и для кого это важно. Следующий шаг — анализ и обсуждение с заинтересованными сторонами. И только в последнюю очередь перехожу на формальный этап — задокументировать возможное изменение, организовать impact анализ, assessment и resolution пути.
Важно действовать именно в таком порядке: Personal — Informal — Formal, потому что иначе можно испортить отношения с заказчиком и переделывать одно и то же несколько раз.
Допустим, на митинге бизнес-аналитику озвучили, что нужно внести изменение: добавить новую кнопку.
Аналитик, пропустив первые 2 пункта, сразу перешел к официальной части, и прямо на митинге сказал: «Хорошо, договорились, я сейчас создам задачу, направлю на менеджера и он будет с ней разбираться».
Если на митинге присутствовал представитель заказчика, он передаст информацию своему менеджеру, а тот свяжется с вашим РМ-ом и будет возмущаться: «С какой стати вы выставляете нам change request на кнопку? Мы даже не обсудили как это будет работать, какую кнопку выбрать, как имплементировать, сколько это будет стоить, а вы уже выставили change request».
Здесь нарушен не только порядок оценки изменения но и фактор прозрачности процесса: заказчику может показаться, что change request будет очень дорогим и это вызовет конфликт.
Поэтому, когда со стороны заказчиков или менеджеров возникает запрос: «я хочу что-то изменить», есть другой вариант. Бизнес-аналитик всегда может сказать: «я все записал, дам ответ завтра». Это нормально воспринимается, так как любой заказчик ожидает два ответа на свой запрос: Кто сделает и Когда. Если ВА эти два ответа дал, то, в большинстве случаев, можно взять время на обдумывание и продолжить беседу позже.
Как работает пошаговая оценка, рассмотрим на абстрактном примере: три стейкхолдера хотят три кнопки разного цвета: зеленую, красную и синюю.
Я говорю: «Хорошо, сегодня подумаю, какое может быть оптимальное решение и отвечу завтра» . Дальше провожу оценку изменения по трем шагам.
- Personal — кому и зачем это нужно.
Как один из вариантов, я бы назначил 15-минутную встречу с каждым из трех заказчиков, чтобы прояснить, почему ему так важна зеленая кнопка, а не красная, в чем польза.
Учитывайте и контекст роли каждого стейкхолдера, потому что некоторые заказчики могут быть с должностью вице-президент, а на решение будет влиять его помощник, с должностью секретарь.
С одной стороны, нельзя сказать такому заказчику официально при других: «твоя красная кнопка мне не нравится», — потому что это его дискредитирует. В то же время, нужно проанализировать, реально ему это нужно или заказчик просто хочет показать свою значимость перед другими.
- Informal — обсуждение с заинтересованными людьми
Когда вы для себя проанализировали, в чем нюансы, сложности, проблемы, варианты решения изменения, и поняли его, — можно продолжить оценку через неформальный процесс общения с заинтересованными людьми. Ваша команда может сказать, что красная кнопка не подходит по нефункциональным требованиям к взаимодействию пользователя с UI.Например, красный цвет может быть слишком раздражающим для людей с особенностями восприятия.
После обсуждения, можно собрать этих же трех заказчиков и сказать: «Ребята, красная кнопка не подходит для людей с нарушениями зрения. Зеленая кнопка проходит, но наши аналитики сделали анализ рынка и выяснили, что зеленые кнопки используются крайне редко».
Всю эту информацию можно наложить на уровень влияния стейкхолдеров, то есть, если знаете, кто из трех человек самый главный, можно все представить так, чтобы выбрать его кнопку, и скорее всего, он сам потом переговорит с остальными.
- Formal — формальная стадия
Клиенты могут сказать: «Хорошо, ты нас убедил по этой кнопке, но другие две остались. Все-таки нам бы хотелось понять, как выбрать из них». И только на этом этапе можно оформить задачу или провести документ и сказать: «Вот мы приняли такие решения, остался финальный вопрос». Заказчики знают, что ВА с ними все обсудил, они все поняли, им дали все «за» и «против». Позже заказчики вернутся в формальную задачу и выберут одну кнопку.
Плюсов у такого пошагового подхода два: будет принято решение по изменению, с которым все согласны и нет негатива в сторону поставщика (ВА или любого участника проекта).
Вовлеченность команды
Под командой я подразумеваю всех участников: РМ, деливери или технический менеджер, ведущий аналитик, тестировщик, DevOps. Если люди любого уровня в вашей команде не понимают необходимости изменений, это повлияет на применение, обработку запроса и контекст в целом.
Чтобы повысить вовлеченность команды, опытный ВА выстраивает бизнес-процессы с помощью различных инструментов. Конечно, на проекте есть РМ, который может сказать: «У нас change request management, описан процесс работы с изменениями, вот вам страничка в Wiki, Confluence, любые ресурсы. Ознакомьтесь, и когда пришло изменение, работайте.
Однако, по-моему мнению, бизнес-аналитик должен действовать, как связующее звено между бизнесом и технической частью, как проводник между заказчиком и проектом. И в основном, я пытаюсь взять на себя такую связующую роль, независимо от того, что делают все остальные.
На чем я концентрируюсь, вовлекая команду в изменения:
Процесс
Насколько люди понимают, как мы обрабатываем изменение на проекте?
Задача ВА — чтобы все понимали процесс на уровне обработки и внедрения решения.
Бывают сценарии, когда ВА все сделал правильно: прошел через персональную стадию оценки изменений, проанализировал informal, перешел к формальной фазе и создал задачу.
А затем, ведущий разработчик, который каждое утро контролирует бэклог, увидел тикет, решил, что change request в приоритете, — и срочно отдал в разработку.
Если Dev Lead не в курсе процесса обработки изменения, то не знает, что мы ждем комментарий от заказчика или ВА должен был написать: «Все обсудили, статус изменить на такой-то».
Когда просто говорят: «Давайте обработаем изменение», — каждый услышит что-то свое. Одну и ту же задачу люди понимают по-разному. Даже в бытовом плане, если попросить сделать бутерброд с колбасой и с сыром, кто-то сделает два куска сыра и один — колбасы, а кто-то — 6 кусков колбасы и 1 сыра.
Поэтому, процесс может быть описан в Wiki, но лучше организовать один созвон и убедиться, что у всех есть одинаковое понимание.
Смысл изменений
Команде важно понимать не только процесс — «Как» мы обрабатываем изменения, но и «Зачем», что это дает в целом для пользователей, покупателей или бизнеса. Именно бизнес-аналитик должен выдать команде смысл и все горизонты изменения.
Что это даст бизнесу: например, что эти три кнопки дают заказчикам? Допустим, красная кнопка — ускорит реакцию пользователя, чтобы выдать какую-то деталь на заводе, и производительность увеличится на 40 процентов.
Понимание смысла косвенно влияет на процесс. Из моего опыта, команде, которая будет работать над изменением: прописывать какую-то банальную строчку кода, в формате «поменять класс, добавить функцию» и т.д., личностно важно понимать ценность внедрения, что я даю этим изменением?
Например, если меняется интерфейс работы с купленным сертификатом, пользователю становится удобнее работать, он видит полезные функции и может корректно обработать сертификат и т.д.
Терминология
В основном, изменения обрабатывают бизнес-аналитики, проектные менеджеры или архитектор. Однако много раз в процессе работы я контролировал и успевал вовремя, когда люди внутри команды, не связанные с обработкой изменений на этапе их зарождения, например, Dev Lead или QA, брали на себя ответственность за change request.
Бывает, что на митинге заказчик говорит: «Я думаю, какую кнопку сделать: зеленую, красную или синюю», — и ведущий девелопер сразу отвечает: «Окей, мы подготовим этот change request и разработаем его».
Вроде фраза звучит нормально, но в контексте терминологии есть важная приставка к этому словосочетанию. Это слово «возможный».
Обсуждая что-то с заказчиком, я никогда не обещаю: «Я обсужу, подготовлю или проанализирую этот запрос на изменения». Я всегда говорю: «Это — возможное (potential или possible) изменение, и я его обработаю».
Когда вы обещаете: «я проанализирую запрос и дам ответ», — для некоторых заказчиков это звучит как нарушение прозрачности процесса. Клиент может думать, что вы уже выставляете change request без предварительного обсуждения.
Ответственность бизнес-аналитика
Работа с изменениями — это активности с высокими рисками на каждом этапе, где нет места «я не знаю/забыл» или «я сам это сделал/подумал так будет лучше».
Независимо от предварительного визуального размера, изменение может вызвать критические последствия, поэтому даже запрос точечного уровня никогда нельзя оценивать как что-то простое.
Ответственность бизнес-аналитика — оценить изменение, а затем, правильно выстроить работу с заказчиком и командой. Смысл в том, чтобы быть ответственным на своем уровне, понимать, кто и где принимает решения. Это относится к стейкхолдер менеджменту, причем не только относительно внешних заказчиков: у вас в команде могут быть эксперты по домену, один или несколько архитекторов, — их тоже нужно включать в процесс принятия решений.
Создание и принятие изменений в существующем продукте, особенно в разрабатываемом, почти всегда связано с высокими рисками: когда возникает change request, ВА не может и не должен говорить: «Я знаю, это займет 5 секунд или это 100 дней». Чтобы избежать критических последствий, нужно с одинаковым уровнем ответственности относиться и к тому, что выглядит очень серьезно, и к маленьким точечным на вид изменениям.