Plane для продуктовой команды: проекты, циклы и рабочее окружение на VPS

Откройте общий список задач любой живой продуктовой команды, и вы увидите примерно такую картину: «Кнопка оплаты не нажимается на узких экранах», «Подготовить онбординг к релизу через две недели», «Личный кабинет для партнёров» и рядом «Обновить текст письма». Первая запись — вопрос часа. Вторая — работа с дедлайном. Третья — замысел, который проживёт несколько месяцев и распадётся на десятки частей. Четвёртая — мелочь на пять минут. Формально это все «задачи», но у них разный масштаб, разный срок жизни и разные вопросы, которые к ним задают. Если сложить их в одну плоскую ленту, лента перестаёт отвечать на главный вопрос: что мне делать дальше?

Plane построен вокруг того, что на этот вопрос можно отвечать с разных сторон, не размножая сами задачи. В официальном README перечислены Work Items с вложениями, Cycles, Modules и сохраняемые Views (README Plane). Это не четыре независимых инструмента, а четыре взгляда на один и тот же набор записей. Разберём, как это работает, на одном сквозном примере, а потом посмотрим, что проверить на своём VPS и в выбранной редакции, прежде чем переносить в систему всю команду.

Один замысел, который придётся разрезать

Возьмём условный продукт: сервис записи на консультации для небольших клиник. Это пример для разбора, не история реального клиента. Команда из шести человек: продакт-менеджер, дизайнер, два разработчика, тестировщик и человек на поддержке. Крупный замысел квартала: «Онлайн-предоплата записи». Пациент выбирает слот, платит, получает подтверждение, а клиника видит оплату в расписании.

Замысел нельзя положить в трекер одной карточкой «Сделать предоплату». Такая карточка либо навсегда останется «в работе», либо будет закрыта в тот момент, когда кто-то решит, что «в целом готово». Её надо разложить на Work Items, то есть на единицы работы, которые можно назначить, оценить, обсудить и закрыть. Для нашего примера получается примерно такой набор:

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

Обратите внимание на свойство этого списка: в нём есть дизайн, backend, тексты, тестирование и поддержка. Работа идёт в разных руках и в разное время. Часть пунктов возникнет позже: например, после первой демонстрации выяснится, что клиникам нужен отчёт по оплатам. Замысел растёт, а значит, его границы должны быть где-то записаны. Этим занимается Module.

Module отвечает на вопрос «что это за работа»

Module — содержательная группа. Мы создаём модуль «Онлайн-предоплата» и привязываем к нему все перечисленные Work Items. Теперь есть место, где виден весь замысел целиком: сколько частей, какие закрыты, какие ещё не начаты, где застрял дизайн. Модуль не привязан к календарю команды. Он может занять шесть недель или три месяца, и никто не обязан закончить его к определённой пятнице.

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

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

Cycle отвечает на вопрос «что мы делаем сейчас»

Cycle — это временной отрезок, обычно короткий: в нашем примере две недели. Из всех Work Items команда выбирает те, на которые у неё действительно хватит рук в этот период. И вот здесь проявляется главная идея: в цикл попадают элементы из разных модулей и из тех, у которых модуля нет вовсе.

Допустим, на ближайшие две недели берём:

• из модуля «Онлайн-предоплата» — правила возврата, экран оплаты и создание платёжной сессии;
• исправление ошибки с кнопкой на узких экранах, у которой модуля нет;
• обновление текста письма, которое относится к другому модулю, например «Уведомления».

Это не копии. Каждый из этих Work Items существует в одном экземпляре, и просто смотрит на него несколько представлений. Когда разработчик закрывает создание платёжной сессии, это меняется и в цикле, и в модуле: прогресс замысла сдвигается, а оставшийся объём цикла уменьшается. Не нужно переносить карточку, дублировать её в «спринтовую» доску или помнить, где какая версия актуальна. Именно отсутствие дубликатов делает данные пригодными для разговора: цифры в цикле и в модуле не могут разойтись, потому что они считаются по одним и тем же записям.

Теперь понятно, как разводятся ответственности. Модуль отвечает на вопрос продакт-менеджера «как продвигается предоплата и что ещё осталось». Цикл отвечает на вопрос команды «успеем ли мы то, что обещали на эти две недели». Один и тот же Work Item участвует в обоих разговорах, и ему не нужно ничего переписывать.

Что делать с недоделанным в конце цикла

Цикл заканчивается, а экран оплаты ещё не принят. Работа не исчезает и не копируется: её нужно либо перенести в следующий цикл, либо вернуть в общий список. Правило, которое стоит принять заранее: решение о переносе принимается осознанно на встрече, а не автоматически. Если три цикла подряд один и тот же элемент переезжает дальше, это сигнал, что он слишком крупный и его надо разрезать на два-три Work Items. Модуль в этот момент ничего не теряет: новые части просто добавляются в него.

Проект как граница, а не как папка

Остаётся вопрос, который многие решают не сразу: сколько проектов заводить. Проект в Plane — самая внешняя рамка, внутри которой живут Work Items, циклы и модули. Соблазн велик — завести проект на каждый замысел: «Предоплата», «Уведомления», «Отчёты». Но тогда мы теряем возможность взять в один цикл работу из разных замыслов, потому что цикл живёт внутри проекта.

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

View: фильтр, который не нужно собирать заново каждое утро

Последняя сущность из перечня README — сохраняемые Views (README Plane). Смысл простой: вы один раз настраиваете сочетание фильтров и группировки и сохраняете его под понятным именем. Дальше представление открывается одним действием, а не собирается заново из пяти выпадающих списков.

Сила View раскрывается, когда он описывает не «всё о проекте», а ежедневную роль одного человека. Вот три примера для нашей команды.

• Тестировщик. Элементы текущего цикла в состоянии «на проверке», отсортированные по приоритету. Утром ему не нужно искать, что пришло: список уже ответ.
• Разработчик. Элементы, назначенные на него, из текущего цикла, не закрытые, сгруппированные по модулю. Он видит и очередь работы, и то, к какому замыслу она относится.
• Продакт-менеджер. Элементы модуля «Онлайн-предоплата», у которых нет исполнителя или нет описания. Это список вопросов, которые требуют его внимания.

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

Признаки плохого представления

Хороший View отвечает на один вопрос. Плохой пытается ответить на все сразу: десять фильтров, три группировки, и никто не помнит, зачем он создан. Простая проверка: назовите представление глаголом или вопросом. «Что мне проверить сегодня» работает. «Общий вид 2» — нет. Если имя не придумывается, значит, у представления нет читателя, и его, скорее всего, никто не откроет через неделю.

Проверка на небольшом рабочем наборе

Прежде чем переносить в систему всю команду, стоит прогнать через неё один реальный замысел целиком. Не демонстрационные данные, а настоящую маленькую историю с живыми людьми. Для нашего примера хватит двадцати-тридцати Work Items. Что проверяем:

1. Путь одного элемента. Создайте Work Item, привяжите к модулю, включите в цикл, закройте. Убедитесь, что во всех трёх местах он выглядит одинаково и не появился дважды.
2. Вложения. README указывает, что Work Items поддерживают вложения (README Plane). Приложите к элементу то, что у вас действительно ходит в работе: макет экрана оплаты, скриншот ошибки, небольшой документ. Откройте вложение под другим участником команды, а не под тем, кто его загрузил.
3. Роли в представлениях. Попросите тестировщика и разработчика один день работать только через свои сохранённые Views. Если им приходится возвращаться к общему списку, значит, фильтры подобраны неверно.
4. Конец цикла. Намеренно оставьте один элемент недоделанным и проведите его перенос. Это самый частый момент, когда процесс выявляет свои слабые места.

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

Команды действия: где они пригодятся

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

Какая редакция лежит под вашим пилотом

Это самая тихая и самая важная часть выбора. Документация Plane различает Cloud и self-hosted-варианты: Community, Commercial и Airgapped (Plane: Understanding editions). Для команды, которая хочет поставить Plane на собственный сервер, первое практическое следствие: слова «Plane умеет X» без уточнения редакции ничего не гарантируют.

README описывает Self-hosting как отдельный способ развёртывания, но сам по себе обзор функций не доказывает, что все редакции содержат одинаковый набор (README Plane). Поэтому пилот должен начинаться не с установки, а с короткого списка: что нашей команде действительно нужно из описанного выше. Проекты, циклы, модули и представления — это то, ради чего мы затеяли разговор. Если на вашем пилоте они работают в выбранной редакции так, как вам нужно, вопрос закрыт. Если вам требуется что-то сверх этого, это нужно сверять отдельно.

Community и AGPL v3

Community-редакция распространяется по лицензии AGPL v3 (Plane: Understanding editions). Для команды, которая просто использует Plane внутри себя, это обычно означает работу с открытым кодом без отдельной оплаты лицензии, но юридические последствия AGPL, особенно если вы планируете изменять код или предоставлять сервис другим лицам по сети, лучше обсудить с тем, кто отвечает за такие вопросы в вашей организации. Здесь мы не даём юридической оценки, а только фиксируем: тип лицензии указан в документации, и он относится именно к Community.

Коммерческие возможности не переносятся автоматически

Документация прямо предупреждает: возможности и правила коммерческой редакции нельзя переносить на Community без отдельной проверки (Plane: Understanding editions). На практике это значит следующее. Если вам понадобятся, например, вопросы входа через корпоративную систему, количество рабочих мест, расширенная аналитика или иные возможности, не считайте их доступными только потому, что они упоминаются в общем описании продукта или в чужом отзыве. Откройте страницу редакций, найдите нужную функцию именно в колонке выбранной редакции и, если ответа нет, задайте вопрос разработчикам до того, как команда начнёт работать в системе.

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

Если вы пока выбираете между разными трекерами, а не между редакциями одного, сравнение подходов есть в материале «Plane или Taiga: что выгоднее и когда». Здесь мы исходим из того, что выбор в пользу Plane уже сделан.

Где разместить пилот и сколько ему нужно ресурсов

Для пилота подойдёт обычный виртуальный сервер с root-доступом: вы сами решаете, как развернуть Plane и какую редакцию выбрать. На VPS MAATRIX предложены NVMe-диски, процессоры AMD EPYC и root-доступ; в публичном предложении названы площадки UK, US, RU и FR, а оплата возможна картой РФ и через СБП. После оплаты VPS создаётся автоматически, по заявлению сервиса, за пару минут (VPS MAATRIX). Какие операционные системы и образы доступны в нужной локации, проверяйте в форме заказа.

Тарифные ступени в линейке такие: Ba — 1 vCPU, 2 ГБ RAM, 40 ГБ NVMe; Uab — 2 vCPU, 4 ГБ, 80 ГБ; Heka — 4 vCPU, 8 ГБ, 160 ГБ; Maat — 8 vCPU, 16 ГБ, 240 ГБ; Djed — 16 vCPU, 32 ГБ, 320 ГБ. Эти цифры описывают ресурсы сервера, но не обещают, что на нём уместится столько-то пользователей или проектов: ёмкость зависит от конкретной нагрузки, объёма вложений и сопутствующих сервисов на той же машине.

Как подойти к выбору разумно? Для пилота на шесть человек и тридцать записей начните с небольшой ступени и наблюдайте. Следите за тремя вещами: сколько памяти занято в рабочее время, как ведёт себя процессор, когда несколько человек одновременно открывают представления, и как быстро растёт занятое место из-за вложений. Если запаса хватает, оставайтесь; если нет, переходите на ступень выше. Такой подход даёт вам собственные измерения вместо чужих «минимальных требований», которые легко оказываются неприменимыми к вашей нагрузке.

Что в этой истории нужно сделать самостоятельно, а не ждать «из коробки»? Сохранность данных: наличие автоматических резервных копий во всех тарифах в публичных сведениях не подтверждено, так что план копирования базы и вложений вам нужно продумать самим и проверить на пилоте так же, как проверяется работа циклов. Это не отдельная большая тема статьи, а условие, чтобы рабочий набор не пришлось собирать заново.

Как выглядит правильная настройка в первый день

Соберём всё в короткий порядок действий для нашей условной команды.

1. Определите, в какой редакции вы работаете, и сверьте с её описанием все функции, которые вам нужны сверх базовых: вход, количество мест, аналитику.
2. Создайте один проект на команду и продукт.
3. Заведите модуль для первого реального замысла и разложите его на Work Items.
4. Откройте первый цикл на две недели и выберите в него элементы из разных модулей и без модуля.
5. Создайте по одному представлению для каждой повседневной роли и дайте им названия-вопросы.
6. Прикрепите к нескольким элементам настоящие вложения и откройте их под другими участниками.
7. Проведите перенос недоделанного элемента между циклами, чтобы увидеть, как система ведёт себя в неудобный момент.

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

Утро тестировщика

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

Тестировщик приходит и открывает одно сохранённое представление, которое называется «Что проверить сегодня». В нём нет баги с узкой кнопкой, которую вчера уже закрыли, нет описаний замыслов, которые ещё не начаты, нет чужих элементов. Есть два Work Items из текущего цикла в состоянии «на проверке»: создание платёжной сессии и письмо с подтверждением. У первого приложен скриншот ошибки из прошлой проверки. Второй относится к другому модулю, но человеку это неважно: ему показана именно следующая работа.

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