О космолетах и «спейсах». Как сделать фичу, изменив по дороге весь продукт

24 апреля в платформе Wrike произошло важное изменение: команда объявила публичный релиз новой фичи — «Spaces», в русской версии — «Пространства».

Цель Spaces — улучшить работу команд в таск-менеджере и упростить навигацию в продукте, сделав процессы органичнее и прозрачнее. Получилось ли у нас? Продолжайте читать и узнаете, как раскатывать серьезные обновления в большой компании и не облажаться, как обеспечить взаимодействие 30 скрам-команд и какие уроки мы вынесли из процесса разработки продукта, релиз которого обошелся нам потом и кровью немалыми усилиями и прорывным командным духом.

htjvid85rzbjhr7sl4dhsqabyoa.png

Зачем были придуманы Spaces?


Когда Wrike создавался, он был ориентирован на решение проблем эффективности небольших команд по 15–20 человек. Таким командам удобно работать в одном месте, где есть «пространство» для всех.

Со временем размеры аккаунтов кратно выросли. Теперь продуктом пользуются распределенные команды в аккаунтах с тысячами людей, а в будущем мы видим Wrike как удобный инструмент для работы множества отделов компании: с одной стороны, работающих в разных процессах, с другой — все еще имеющих необходимость взаимодействовать друг с другом.

Поскольку в реальном мире команды существуют в разных кабинетах, офисах, странах, команда Wrike задумалась о создании специального пространства для них, чтобы они могли одновременно работать в рамках своего процесса и не терять связи с другими отделами.

Spaces позволяют отдельным рабочим группам эффективно наладить рабочий процесс: дать нужные им инструменты и структуру данных, доступ к различным формам запросов, чтобы они могли организовать собственное рабочее пространство и действовать более сосредоточенно. Также Spaces позволяют лучше контролировать распространение информации в многофункциональных командах и повышают уровень безопасности данных.

3eiauherykqw1luk-wmxjbijrjg.png

Идея создания Spaces принадлежит Саше Плотвинову и Ване Савельеву, продакт-менеджерам Wrike. Сначала они провели исследования, нарисовали на доске прототип решения для команд, собрали макеты и завалидировали идею. Позже ее доработали на Wrike Хакатоне, где сделали шаг в сторону и собрали прототип Personal Space, который дополнил концепт.

«Spaces» — это, в первую очередь, фича для команд. Однако она основана на концепции жизненного личного пространства, которое необходимо каждому, чтобы исключить лишнюю информацию и посторонний шум.

Какие проблемы решают Spaces?

Если упрощать, то Wrike состоит из проектов и инструментов для работы с ними. Например, работая над комплексным релизом, вы создаете ряд проектов, следите за их прогрессом через диаграмму Ганта, контролируете загрузку команд с помощью Workload и, по результатам, составляете отчет для стейкхолдеров.

Вроде бы всё просто, но, если у вас в одном аккаунте работают тысячи человек в большом количестве команд с пересекающимися процессами и используется много инструментов, то появляются две проблемы: процессами становится сложно управлять и интерфейс пользователя перегружается лишними элементами.

9l6g-4en2ke43tfe4eus4ufown4.png
было

vp_t1esul1hmrff7b3do5xaetyo.png
стало

Такие препятствия для эффективной командной работы возникают по ряду причин: во-первых, в одном дереве папок соседствует множество команд; пользователь постоянно видит нерелевантную информацию и может по-неосторожности нарушить структуру «чужой» команды. Во-вторых, доступ к управлению процессами есть только у администраторов, и структура аккаунта зачастую формируется главными менеджерами-администраторами.

В процессе разработки Spaces мы пришли к двум ключевым задачам:

  • Пользователь должен видеть только то, что ему релевантно
  • На место вертикального управления должны прийти делегирование и самоорганизация


Wrike относится к тем компаниям, которые верят, что горизонтальный менеджмент выигрывает у вертикального, а «бирюзовые» организации показывают себя с наиболее эффективной стороны. Подход, реализованный в Spaces, поможет команде выйти на новый уровень прозрачности и самоорганизации, где превалировать будет именно горизонтальный менеджмент.

«Если раньше у администратора аккаунта была высокая степень ответственности по процессам, то теперь он сможет доверить организацию рабочего процесса команды ее непосредственному руководителю, который зачастую лучше знает особенности работы своей команды».

 — Иван Савельев, продакт-менеджер Wrike

С какими трудностями мы столкнулись?


Конечно, существенные изменения в продукте несут за собой большие риски и ряд трудностей. Вот некоторые из них:

Трудность 1. Cгладить риски

Адаптировать аккаунт под новый способ организации работы — довольно трудоемкая задача. Внутри Wrike проблему обнаружили почти сразу: как компания с множеством команд и процессов, мы попадаем под категорию клиентов, которых считаем своей же аудиторией и ежедневно пользуемся своим продуктом. Внутри командного аккаунта (более 800 человек из всех международных офисов) мы запускали релизы и тут же получали фидбек изнутри — это помогло подготовиться к публичному релизу и максимально митигировать риски заранее.
Для тех, кто никогда не пользовался Wrike, на начальных этапах мы провели серию solution-интервью, запустили тестирование с помощью сервиса UserTesting, а также сделали программу раннего доступа к функционалу Spaces для желающих клиентов.

Перед запуском на всю аудиторию, мы также провели A/B тестирование на новых триалах, чтобы убедиться, что новая парадигма навигации интуитивно понятна новым пользователям. Из тестирования стало ясно, что новые пользователи успешно начинают пользоваться продуктом. Также мы опрашивали тестовую и контрольную группу и обнаружили, что среди респондентов пользователи гораздо чаще говорили о понятности интерфейса и простоте использования Wrike.

Трудность 2. Донести ценность решения до клиента

У Wrike есть множество клиентов, которые уже пользуются сервисом и настроили свои рабочие процессы, поэтому был риск, что новый функционал будет воспринят неохотно.

Мы запустили private beta для ключевых клиентов и подключили к процессу наш отдел Professional Services.
Чтобы донести проблему, а, впоследствии, и ее решение до клиентов, Customer Success менеджеры вместе с администраторами аккаунтов выявляли проблемы организации процессов на раннем этапе и рассказывали клиентам, как Spaces могли их решить. Таким образом, мы транслировали максимальную ценность Spaces, которая перевешивала размер затрат на перестройку. Мы не просто внезапно «выкатили фичу», а систематически готовили клиентов к ее появлению: Customer Success менеджеры проводили вебинары, учили клиентов ориентироваться в новом функционале, делали обучающие email-рассылки, рассказывали про best practices.

Позднее мы вообще не делали никаких призывов: клиенты стали сами приходить на программу раннего тестирования и пользоваться новой фичей.

Трудность 3. Одно улучшение требует многих изменений

Платформенное улучшение затрагивает разные аспекты продукта, и мы решили браться за модернизацию, чтобы не стоять на одном месте. Нам повезло с командой разработчиков, которая развязывала самые невероятные технические узлы и находила оптимальные решения на протяжении всей работы над проектом. Кроме того, все понимали необходимость этой инициативы, поэтому мы всегда имели сильную поддержку со стороны VP и CEO.

Команда разработки с самого начала приняла решение создать минимально связную архитектуру, превратив все решение в набор отдельных бизнес-компонентов и мини-приложений, интегрирующихся и взаимодействующих между собой только в Workspace (конечный продукт, который видит пользователь Wrike).

Для этих компонентов был создан отдельный репозиторий, включающий в себя песочницу. В ней можно было не только посмотреть каждый компонент в действии и показать его, например, на спринт-ревью, но и вести его полноценную разработку и тестирование. Сборка, прогоны юнит-тестов и автотестов отнимали на порядок меньше времени, чем при разработке в полноценном Workspace. Это позволило разработчикам быстро итерировать, показывая результаты в конце каждого спринта, а, в случае необходимости, оперативно вносить изменения как в функционал, так и в API. Через некоторое время был сделан следующий шаг — создание своего рода «игровой площадки», на которой был создан сильно упрощённый интерфейс основного продукта, включающий в себя интеграцию большинства компонентов. Это позволило спроектировать и отладить их взаимодействие между собой.

j4_p6ukg6ccofjosmhtrppu2-yc.png

Как команды взаимодействовали между собой?


В Wrike около 20 скрам-команд, работающих над своей частью продукта, каждая из которых либо затронута фичей в настоящее время, либо будет включена в процесс в ближайшей перспективе. Вопрос межкомандного взаимодействия в ходе разработки Spaces порой вставал очень остро — ведь у каждой команды свои продуктовые OKR-ы на квартал.

Вопрос коммуникации стоял в приоритете: там, где удавалось заранее все обсудить, договориться и формализовать договоренности, взаимодействие получалось лучше, чем с теми командами, с которыми предварительных обсуждений не было. В последнем случае команде разработки приходилось самим вносить правки или дорабатывать чужой функицонал.

«Были и экстраординарные случаи: однажды пришлось интегрировать достаточно крупную и сложную компоненту, разрабатываемую сторонней командой раньше, чем она была этой командой закончена (в итоге она появилась в нашем куске функционала раньше, чем в основном). Что поделать — мы пытались закончить работу в рамках деделайнов и пришлось выкручиваться. А то время, которое мы потратили на приведение всего в порядок после того, как компонента была закончена, нам пришлось размазать тонким слоем при работе над другими фичами — интеграция же по плану была давно закончена!»

 — Алексей Картавенко, Frontend Teamlead

Количество проблем, возникающих при взаимодействии 20 команд друг с другом в очень интенсивном agile-окружении, не должно обескураживать. Для практически любой компании наладить scrum процесс — это уже достижение, а уж scrum of scrums — фантастика: тут и продакт-оунеры, и лиды, и обычные разработчики должны научиться работать друг с другом.

Вот такие советы дает команда Spaces тем, кто готовится сделать большой проект:

  1. Как можно чаще обсуждайте промежуточные варианты проекта с разными участниками процесса, постоянно собирайте фидбэк и ищите дополнительную пищу для размышлений.
  2. Если то, что вы делаете, может быть использовано внутри компании (нам очень повезло с этим в Wrike), запускайте пилотный проект. Раскатывайте на всех, информируйте всех, запускайте формы обратной связи!
  3. Определите уровень готовности, при котором вы сможете включить функционал лояльным заказчикам: среди них всегда есть те, кто любят идти «в ногу со временем» и активировать всякие экспериментальные фичи. Их фидбэк будет особо ценным, потому что именно они — ваша целевая аудитория. В вашем распоряжении все механизмы раннего тестирования: A/B эксперименты, ограниченные и контролируемые выкатки альфа- и бета-версий, Early Access доступ по запросу и т. д.
  4. Балансируйте между скоростью разработки и ее качеством, как на доске для сёрфинга: не бойтесь оставить технический долг в текущем спринте, но сразу же заводите задачи на его ликвидацию, как только ситуация прояснится. Не забудьте присвоить этим задачам самый высокий приоритет. Недальновидно делать полное покрытие юнит- и авто- тестами функционала, который может видоизмениться после фидбэка уже в следующем спринте. Тем более, не просто глупо, а преступно для инженера в итоге оставить мусорный код и позволить ему дойти до релиза.
  5. Старайтесь как следует готовиться к каждому следующему спринту: проводите PBR-ы (Product Backlog Refinement), обязательно берите в текущий спринт задачи на исследование того, чем планируете заниматься в следующем, разговаривайте с Product Owner и UX-дизайнером столько, сколько считаете нужным: преследуйте их на кухне и в курилке, проясняя детали. Постарайтесь синхронизировать бэкенд, фронтенд и тестирование таким образом, чтобы взаимодействие шло «внахлест», чтобы никто не простаивал, ожидая готовности от коллег другой специализации, чтобы не приходилось сидеть на моках, а потом их выкидывать и т.д.
  6. Ближе к дате релиза, когда страсти накаляются и основной объём работы переносится с разработчиков на QA-инженеров, подставьте им свое плечо: сами тестируйте свой код, запускайте регрессию, помогайте с разбором, пробуйте писать автотесты.
  7. При взаимодействии с другими командами заранее начинайте регулярные обсуждения того, как именно вы это будете делать. Все соглашения и планы записывайте, генерируйте документацию, можете даже составлять контракты — не потому что кто-то будет пытаться вас обмануть и не сделать лишнего, а потому что у каждого своя пена дней и ваши проблемы — лишь на пять процентов чужие. Синхронизация по спринтам — идеальный вариант, стремитесь к нему.
  8. При использовании чего-то, разрабатываемого другими командами, относитесь с осторожностью к заявлениям о том, что «почти всё готово, берите и интегрируйте». Сначала придётся всё выяснить, если не хотите попасть впросак, слепо взяв то, что дают и построив на этом свои планы (особенно календарные).
  9. И самое главное: ни одна серьёзная вещь в сложном IT-мире не делается по щелчку пальцами, поэтому, если проект находится в разработке долго, и на вас начинают «косо поглядывать», берегите свои нервы и знайте: пусть не сегодня, но завтра или послезавтра бесконечно ускользающие нити сплетутся, туман развеется и вас ждёт успех — ведь вы верите в то, что делаете, правда?

© Habrahabr.ru