ann.dombrovskaya
- 24 сент. 2020 г.
- 8 мин. чтения

Pivot-Pivot-Pivot! Как управлять стремительно меняющимися требованиями

Никто из нас не любит изменения. Но меньше всех любит их команда разработчиков, когда речь заходит о новых требованиях к задачам, уже взятым в спринт, а тем более, выполненным. В моем последнем проекте таких было достаточно, и эту статью я писала по результатам его ретроспективы. Поэтому в какой-то степени ее можно назвать работой над ошибками и даже мануалом для тех, кто будет менеджить требования в условиях “rapidly changing environment”.

Попав в проект, я обрадовалась: чистый аджайл, T&M-контракт, фиксированы только сроки и состав команды, а скоупом проекта можно играть. Да скоупа как такового и нет: есть идея, вайрфреймы, примерное видение и дедлайн. Именно здесь скрывался подвох: MVP (в нашем случае MLP — Minimal Lovable Product) нужно было сделать за три месяца, начиная с сегодняшнего дня. Отсутствие концепта того, что именно мы предлагаем юзеру как MLP, сразу поставило дедлайн под вопрос для всей команды.

Итак, проект начался 1 июня: UX-трек и трек разработки стартанули одновременно. На этапе отрисовки User Flow оказалось, что одно из основных флоу не несет для пользователя никакого value — и мы сделали первый Pivot. Процессы регистрации и входа в систему, которые мы придумывали, не поддерживались решением из коробки — и мы сделали второй Pivot. Начали разработку по варфреймам, потому что design kit рисовало стороннее агентство, занимающееся разработкой бренда продукта, а мы от него зависеть не хотели.

У команды начали появляться сомнения: конец первого месяца из трех, а у нас еще не зафиксированы цели спринтов и нет даже примерной разбивки скоупа по спринтам до первого релиза. Скоуп у нас получилось зафиксировать тезисно, однако слово “Pivot” звучало в нашем проекте чаще, чем на лестнице, по которой Росс Геллер тащил многострадальный диван.

Затем у клиента появился UX-консультант, который решил внести изменения почти на каждом скрине. Локдаун настиг его где-то в Азии, а команда клиента была распределена по всем часовым поясам США — от океана до океана — как и часть нашей продуктовой команды. Поэтому к концу второго месяца у нас были две версии вайрфреймов в Invision для обсуждения на UX-созвонах с клиентом (была и третья — с дизайнами), вайрфреймы в Zeplin на каждый спринт для разработчиков и вайрфреймы, вставленные в спецификации в Confluence. Вся эта картина хаотично обновлялась из разных тайм-зон, поэтому, закрыв стори вечером, утром можно было найти кучу изменений в требованиях и дизайнах.

Было много и других нюансов: operations team все время вносила коррективы и пожелания (особенно по текстам), интеграция с Salesforce никак не заводилась из-за выбранной архитектуры синхронизации аккаунтов, а менеджмент решил переиграть концепт миграции уже существующего SEO-контента на новый сайт и поменять коней архитектуру на переправе. В какой-то момент стало ясно, что скоуп нужно нещадно резать, иначе мы ничего не успеем — уже написанные и утвержденные требования пришлось дробить и выкидывать Fast-followers.

Pivot-Pivot-Pivot!

Наконец, дедлайн подвинулся с 1 сентября на 21 августа, но мы все-таки успели. Правда, только благодаря самоотверженной работе команды и готовности клиента рубить скоуп шашкой. Причем нещадно.

Короче говоря, из всей этой истории я сделала некоторые выводы. И сформулировала пункты, следуя которым, можно в следующий раз немного облегчить жизнь команды разработчиков и тест-инженеров.

Зафиксировать скоуп и цели для каждого спринта релиза как можно раньше.

Даже если у вас чистый аджайл, даже если ничего не понятно, все равно пропишите цели каждого спринта на весь релиз-скоуп. Прописанный скоуп позволяет понять, насколько он амбициозен. Он помогает команде и клиенту (а главное, топ-менеджменту клиента) одинаково оценивать, насколько мы продвинулись, а бизнес-аналитику, проджект-менеджеру и продакт-оунеру определить масштаб трагедии, убедиться, что ничего не забыли покрыть строями и требованиями, отслеживать этапы реализации фич и раньше осознать, что пора выкидывать функционал. Чем раньше вы начнете согласовывать это решение с менеджментом, тем лучше, а связный написанный текст воспринимается легче, чем туманные опасения, выраженные на словах. Нет ничего страшного, что скоуп будет меняться — главное, не забывайте обновлять соответствующий документ.

Постоянно оставаться в контексте

Ходите на все UX-митинги c участием клиента и без, просите подключать вас ко всем обсуждениям требований, контента, стратегий и даже деталей архитектуры. Если сбором требований занимается онсайт-команда, скажем, в США, заведите регулярный созвон в 8 утра по EST и просите апдейт. Следите за всеми комментариями в Invision и комментируйте сами, когда заметите, что правки не соответствуют вашему видению, видению команды разработчиков или идут вразрез с задачами, выполненными ранее. Как только вы теряете контекст, перестаете быть опорой для команды — у кого тогда спрашивать, как должно быть? К тому же, вы можете упустить важное изменение требований (у меня на позднем митинге зазвонил телефон, пришлось пропустить пять минут обсуждения — в результате в спринт почти ушла стори с неправильными требованиями — на груминге было стыдно) или не поднять красный флаг клиенту и UX-команде там, где мы не сможем выполнить их пожеланий из-за ограничений в разработке.

Создать "to-do" список уточнений и правок

Заведите чек-лист и записывайте каждое новое изменение дизайнов и требований, о котором услышали от клиента с командой или которое задумали сами. У меня всегда под рукой такой список в блокноте — мне нравится вычеркивать выполненные задачи. Говорят, это вызывает такой же бурный выброс эндорфинов, как прием алкоголя (хм, выходит эффективно-продуктивная работа способствует ЗОЖу!). Примерно такая:

Когда я уходила в отпуск, команда оказалась несколько фрустрирована и создала подобный список в Confluence. Он мне потом очень помог влиться в процесс, проставив галочки “done”.

Использовать матрицу Эйзенхауэра, если правок слишком много

Помните основы тайм-менеджмента (https://www.eisenhower.me/eisenhower-matrix/)? Там, где про важные и срочные дела? Я для себя этот момент немного переформатировала: правки делятся на быстрые и важно-срочные. Если их очень много, всегда можно что-то забыть или не успеть уточнить.

Поэтому: сначала мелкие и срочные правки (таска уже в спринте), потом — крупные и срочные правки. Можно обсудить их с командой разработки и QA командой: возможно, некоторые так и останутся важными, зато окажутся не такими уж срочными. Перед самым дедлайном я не высказала разработчику предположение, что таску, над которой он работает, возможно, выкинут из скоупа. И потом корила себя, что он потратил такое ценное перед релизом время на никому не нужный функционал.

Мелкими и не срочными изменениями можно заняться на каких-нибудь неинтересных митингах, а про крупные, неважные и несрочные можно вообще забыть — пока вы до них доберетесь, их уже выкинут из скоупа текущего релиза.

Максимально дробить юзер-стори

Здесь была моя ошибка. Стори тянулись из спринта в спринт, требования постоянно правились, а потом некоторые из них приходилось еще и разбивать, когда от какого-то куска функционала решали отказаться. Очень маленькие стори (вплоть до «хочу иконку на рабочем столе — несмотря на советскую власть! — чтоб по клику на нее активировать пользователя, и чтоб пользователю мне после активации приходил имейл») обеспечивают большую прозрачность прогресса для клиента и позволяют легко выкинуть любое подобное требование из скоупа, чтобы протестировать функционал без нее.

Создавать один "source of truth"

Я уже писала, сколько версий вайрфреймов и дизайнов было в нашем проекте, в Invision у нас не появился North Star Vision 1.0. Он постоянно обновлялся, когда из скоупа решали что-то выкинуть или наоборот добавить туда новые фичи. Кстати, если в скоуп нужно что-то добавить, ОБЯЗАТЕЛЬНО в первую очередь обсудите это с командой — иногда может оказаться, что критические фичи не так сложно заимплиментить. А о возможностях любых компонентов, взятых из коробки, лучше спросить/прочитать заранее. Тогда любые попытки клиента обсудить варианты их кастомизации можно будет пресекать на корню.

Не хранить требования к Jira-таскам в Confluence. Увы, это не работает!

Я по природе человек ленивый, мне не нравится править требования сразу в нескольких местах. Я люблю описать стори в Confluence, а в Jira просто добавить ссылку на нужную страницу. Но если требования меняются часто, такой подход обречен. Представьте: вы подготовили стори, описывающую разработку функционала по вайрфремам, команда разработчиков запилила вайрфремы и логику, но тут появились дизайны. Что делать? Обновлять страницы в Confluence нельзя — они заимплиментированы и ждут тестирования. Может, создать новую версию требований? Но тогда Confluence будет захламлен неактуальными требованиями.

В итоге команда решила, что требования в Confluence мы все-таки будем обновлять, а вот в Jira станем создавать конкретные маленькие стори (помните, что дробить их нужно по максимуму?) с отдельным описанием, зафиксированной ссылкой на скрин в Zeplin (а не в Invision, который постоянно обновляется) и ссылкой «Хотите знать контекст задачи — идите в Confluence». К стори подзадачами нужно при этом прикреплять функциональные таски. Это упростило нам процесс чистки скоупа: если стори исключалась из релиза, все подзадачи следовали за ней автоматически и не захламляли беклог.

Использовать Канбан или максимально короткие скрам-спринты

Это совет скорее для проджект-менеджеров, но я все равно хочу на нем остановиться, потому что считаю, что бизнес-аналитик может и должен на это влиять! Допустим, изначально вы выбрали двухнедельные спринты. Но за две недели в задачах может измениться очень многое, на что команда уже не успеет эффективно отреагировать. Для нас и недельные спринты оказались слишком длинными, притом что на еженедельную подготовку спринта уходило очень много времени.

Когда дедлайн проекта с 1 сентября перенесли на 21 августа, мы просто добавили в спринт все оставшиеся задачи без эстимейтов, чтобы не тратить время разработчиков на подготовку. Чистили борд уже по ходу — получилось совсем не айс ни для команды, ни для клиента, так как на команде висела куча задач в to-do статусе и сложно было понять, что мы успеваем, а что нет. По сути скрам-борд превратился в канбан, пока мы не навели там порядок.

Раз в неделю обсуждать скоуп с командой

“I might sound obvious”, но скоуп на следующий спринт, а равно изменения North Star Vision, обязательно обсуждайте с командой. Зовите продакта, UX-трек, всех разработчиков и QA (только не забудьте всем, кроме лидов, предоставить выбор: потратить время на разработку или еще один митинг). Так вы сможете выявить узкие места, озвучить, что было выкинуто из скоупа проекта (девелоперы и на митингах бывают погружены в код, такую информацию они могут просто пропустить). Кстати, заранее откройте все страницы с требованиями и дизайнами, чтобы не давать переключаться контексту, пока страница грузится.

Наладить прозрачный процесс апрува дизайнов и требований

Менеджите клиента, не бойтесь отслеживать его реакцию и просить посмотреть дизайны ASAP. Перепроверяйте правки и помните, что клиент тоже может ошибаться. У людей на стороне заказчика могут быть более приоритетные задачи, поэтому не просто предлагайте варианты, но и делитесь видением, какой из них стоит принять в разработку. Учитесь говорить клиенту нет: если задача уже выполнена, обсудите с клиентом, насколько правки приоритетны и могут ли они потерпеть до следующего релиза. А еще предложите клиенту отправить North Star Vision своему топ-менеджменту не накануне внутреннего релиза продукта, а как можно раньше. Иначе придется согласовывать отдельные правки уже на высшем уровне компании-заказчика.

Не торопиться вносить текстовые правки стейкхолдеров в скоуп спринта

Я уже говорила про важные и срочные изменения, но хочу отдельно отметить текстовые правки. В нашем проекте клиент делал огромную ставку на правильное позиционирование продукта, поэтому КАЖДОЕ слово и каждая текстовка имела для него очень большое значение и могла меняться по 100500 раз за спринт. Сначала я собирала все текстовые замечания в одну таску и просила что-то править в каждом спринте. Пока не поняла, что это бессмысленно: контент на одних и тех же страницах менялся со скоростью, если не света, то звука. Тогда-то мы объяснили клиенту, что все текстовки нужно смотреть в North Star Prototype и править их тоже там. Уже перед самым релизом мы попросим фронтенд-команду разом пройтись по всем скринам и обновить тексты.

В заключение хочу сказать: буддизм учит, что одно из трех величайших страданий человека — страдание от перемен. Поэтому будьте готовы, что в таких проектах, как наш, команда временами будет фрустрировать (мне бы тоже не понравилось, если моя трехдневная работа оказалась никому не нужна). Поэтому оставайтесь стержнем для команды! С изменениями не стоит бороться (невозможно бороться с тем, чего не в силах изменить — парадокс, но в вашем случае это и будут сами изменения). Остается только принять тот факт, что вещи по природе своей непостоянны. Все, что остается BA, — пытаться сгладить боль от этих перемен для команды. И just keep swimming!