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