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

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



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


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

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

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

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



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

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

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

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

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


    было


    стало

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

    В процессе разработки 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. Через некоторое время был сделан следующий шаг — создание своего рода “игровой площадки”, на которой был создан сильно упрощённый интерфейс основного продукта, включающий в себя интеграцию большинства компонентов. Это позволило спроектировать и отладить их взаимодействие между собой.



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


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

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

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

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

    Количество проблем, возникающих при взаимодействии 30 команд друг с другом в очень интенсивном 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-мире не делается по щелчку пальцами, поэтому, если проект находится в разработке долго, и на вас начинают «косо поглядывать», берегите свои нервы и знайте: пусть не сегодня, но завтра или послезавтра бесконечно ускользающие нити сплетутся, туман развеется и вас ждёт успех — ведь вы верите в то, что делаете, правда?
    Wrike
    106,62
    Wrike делает совместную работу над проектами проще
    Поделиться публикацией

    Комментарии 0

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

    Самое читаемое