Уйти из Notion и экосистемы Google без вреда для проектов: опыт Express 42

Начиная с февраля мы ищем аналоги западным сервисам, пробуем новые инструменты и пересобираем процессы по фреймворку p3express. Я, руководитель проектного офиса Express 42 Альбина Кузнецова, специально для PMCLUB рассказала, как адаптироваться, менять «костыли» и устоять в кризис.

Для начала коротко о нас: Express 42 занимается digital-трансформацией, ускорением поставки продукта и выхода в продакшн. Основные направления — анализ, консалтинг, внедрение DevOps-практик и обучение.

В мае 2021 года мы в компании внедрили фреймворк p3express для удобного управления проектами. Это пошаговая система, которая описывает весь цикл работы над проектом — от запуска до завершения. Об интеграции p3express я рассказывала на вебинаре и писала в статье. Вкратце объясню и тут.

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

Также прописали FAQ с информацией по проектам. Например, в разделе «Инструментарий» храним подробности о других фреймворках. А в разделе «Положительные практики» — свод фич, которые придумали и внедрили на отдельных проектах.

Но, спустя год, всё пришлось полностью поменять.

Бизнес часто жалуется, что вынужден подбирать альтернативные сервисы из-за невозможности оплачивать и работать на западном ПО или по постановлению правительства. В нашем случае параллельно с этим проходила трансформация ролевой модели и основных предложений компании в ответ на изменения рынка.

После начала СВО изменился характер запросов. Ранее клиенты говорили «мы хотим масштабироваться» или «мы расширились — нужно подтянуть спецов по DevOps». Теперь они приходят с просьбой помочь сохранить то, что есть, минимизировать урон от санкций и неопределённости. Сотрудники уезжают, снижается производительность и уходят сервисы. То есть клиент хочет решить конкретную проблему.

Поэтому объяснение/доставка ценности стала проходить на этапе технических пресейлов и обсуждения условий и границ сотрудничества, а не по ходу самих работ. Особенно важным стало для обеих сторон чётко придерживаться обозначенных сроков. И такие изменения запросов запустили цепочку изменений наших подходов к ведению проектов.

В результате мы упразднили роли Delivery manager и Project coordinator. Вместо них запустили новые для компании: Presale manager и Project manager. Сформировали проектный офис и с мая по август наняли четырёх ПМов (с одним не прошёл матчинг по стилю работы).

С конца февраля мы начали искать новые сервисы. Определили для себя, какие инструменты действительно нужны — безотносительно прежних решений (привет, первый принцип NUPP):

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

Вначале мы подключили slack-аутентификацию для входа пользователей, а на момент написания статьи перешли на использование отдельного SSO-провайдера

Поиском таск-трекера занималась я. По сути, выбор был между «Яндекс.Трекером» и Kaiten. Я потратила две-три недели на «потыкать» и провести все кейсы.

«Яндекс.Трекер» понравился тем, что в нём изначально можно настроить пайплайн под каждый проект, включая его специфику, и пользователю достаточно двигать таску по статусам одной кнопкой «Далее». Самое сложное — прописать всю логику на старте в зависимости от того, какой проект, по каким шагам и к кому должен идти.

Но я отказалась от этого варианта, потому что сервис на тот момент нуждался в доработках. Также при незначительном изменении в проекте нужно было перепрограммировать всю логику. То есть для содержания трекера нужно было бы выделять отдельного человека. Это дорого — и зачем?

Сейчас у меня не сохранились прошлые тестовые наработки, когда изучала инструмент и настраивала его под нужды Express 42. Но при подготовке этой статьи увидела, что команды «Яндекса» уже внесли много крутых фич за прошедшие полгода.

Остановилась на Kaiten, так как сервис уже был знаком команде. Мы тестировали его года три назад. В нём есть основные функции для ведения проектов: канбан-доски, таблицы, календарь, таймлайн.

Я начала думать, как перенести информацию p3express в Kaiten. Было непросто, потому что с мая мы формировали проектный офис. Это значило, что в короткие сроки надо заонбордить и в компанию, и в проекты проджектов, которые раньше работали в других парадигмах.

На каждый проект оформляются две доски в определённом пространстве с портфелем проекта. Одна доска — это заметки/напоминания для проджекта: что и на какой стадии нужно сделать. Также все шаблоны и карточки клиентов/проектов мы оформляем в вики.

Вторая доска — чисто производственная, где лиды и инженеры ставят себе задачи и выполняют.

На борде для ПМ-ов такой же принцип, как в Notion: есть карточка, в ней — описание, роли, шаги в виде чек-листа. Вот, к примеру, карточка с описанием запланированной встречи команды.

Как и в Notion, некоторые шаги из p3express у нас объединены или адаптированы. Некоторые вынесены за пределы проекта. Например, определением потенциальных рисков мы занимаемся ещё на этапе технического пресейла, чтобы подготовиться уже к моменту старта работ, предупредить клиента о возможных альтернативах, если те или иные риски сработают.

Миграцию в Kaiten закончили примерно в мае-июне, но до сих пор нельзя сказать, что всё полностью настроили под себя. Работа идёт каждый день, даже если ресурс остаётся только на то, чтобы лежать в направлении цели. Многое стало возможным только после появления настоящего проектного офиса и с приходом крутых ПМ-ов в нашу компанию.

Также раньше у нас всё было в Google — пользовались «Диском», «Таблицами», «Документами». После начала СВО мы не могли оплатить корпоративную подписку и перешли на «Яндекс», пользуемся его хранилищем. Но заменить гугловские сервисы очень сложно. «Яндекс Документы» пока не смогли заменить весь необходимый функционал.

Искали что-то вроде юзер-френдли баз данных, в которых можно работать, как в Excel. Остановились на Airtable и оплачиваем его с зарубежной карточки. Понимаем, что и Airtable может в любой момент забанить российских пользователей. Поэтому параллельно разрабатываем похожий внутренний продукт.

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

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

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

Поиском новой вики-системы занималась команда разработки, поэтому в этой главе говорит teamlead Алексей Зимонин.

Учитывая, что база знаний должна быть не только для инженеров, отсекли варианты без WYSIWYG-редактора и те, где используется только Markdown.

Также необходима была возможность бесшовного переезда с Notion. В дальнейшем использовали Markdown-экспорт и на тот ещё момент ручной импорт страниц. Чуть позже дописали скрипт для экспорта/импорта, но оставалась проблема с внутренними ссылками.

Yandex Wiki был недостаточным по функционалу и с ограниченным интерфейсом, но рассматривался как основная SaaS-альтернатива.

В итоге выбрали Outline Wiki. По наиболее похожему внешне (не надо переучиваться), наименее лагающему и open-source продукту.

Outline также активно обновлялся на момент выбора.

По настройке никаких хитростей:

Из-за отсутствия на момент миграции импорта из Notion мы вручную мигрировали самые критичные страницы и постарались максимально быстро договориться о создании новых страниц уже в новой базе знаний. Затем распределили миграцию по подразделениям. Все переносили те пространства, за которые были ответственны.

Старались одновременно выполнить актуализацию данных. Была попытка подключить нового техписа на перестройку структуры разделов, но отказались от этого (возможно из-за того, что это требовало больших ресурсов, а техпис был один). Архивные страницы и наиболее разросшиеся разделы по оценкам было нереально перенести за разумные сроки вручную, поэтому написали скрипт для автоматизации массового экспорта/импорта. Наличие REST API у Notion и Outline было огромным плюсом.

Ещё на момент переезда не было поддержи вложений в Outline, поэтому вытаскивали записи на «Яндекс.Диск».

Из минусов — все таблицы (базы), которые были в Notion с карточками, тоже не работали в Outline, что вынудило ускорить выбор решения с таск-трекером.

В «Яндекс» мы мигрировали за полтора месяца, в Kaiten и новую вики — примерно за три. И миграция продолжается и сегодня: до сих пор мы ищем лучшие решения, адаптируем рабочее пространство и ловим побочные эффекты.

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

Кейс подготовила онлайн-школа для менеджеров проектов и продуктов PMCLUB совместно с Express 42. Мы рассказываем об эффективном управлении, планировании и рабочих инструментах. Подписывайтесь на нас на vc.ru и в Telegram.

#инструменты #тасктрекер #kaiten #p3express