Как IT-студии и агентства в Казахстане ведут клиентские проекты в Plane

IT-студии и агентству в Plane удобнее всего вести каждого клиента отдельным проектом внутри одного рабочего пространства. Этапы работ становятся статусами, у каждой подзадачи один ответственный, заказчик заходит гостем и видит только свой проект, заявки приходят через Intake, а часы списываются прямо на задачи. Такая схема собирается за день и держится годами, если с первого дня договориться о правилах.

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

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

Типичная студия живёт так: задачи приходят в WhatsApp-чат с клиентом, ТЗ лежит в отдельном документе, часы считаются в таблице, а актуальный статус знает только менеджер проекта. Пока клиентов три, это работает. На десятом клиенте начинаются потери.

Симптомы узнаются сразу:

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

Трекер сам по себе это не исправит. Исправляет связка: понятная структура, одинаковые статусы во всех проектах и правило, что работа существует только в трекере. Plane подходит под эту связку, потому что задачи, документы, заявки и часы в нём живут вместе.

Структура: пространство, проекты, модули и циклы

Рабочее пространство в Plane соответствует студии целиком. Каждый клиент получает проект. Если у крупного клиента несколько продуктов с разными командами, заводите проект на продукт, а не на клиента. Внутри проекта модули отвечают за фичи или этапы договора, циклы за итерации, а релизы фиксируют поставки.

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

Уровень Plane	Что это в студии	Пример	Владелец
Рабочее пространство	Студия целиком	Все клиенты и внутренние проекты	Руководитель студии
Проект	Клиент или продукт клиента	«Клиент А — мобильное приложение»	Менеджер проекта
Модуль	Фича или этап договора	«Личный кабинет», «Интеграция оплаты»	Тимлид
Цикл	Итерация на одну-две недели	«Цикл 14»	Менеджер проекта
Релиз	Поставка клиенту	«Версия 1.3 в сторах»	Тимлид
Задача	Результат, который видит клиент	«Экран оплаты»	Исполнитель или тимлид
Подзадача	Шаг с одним ответственным	«Вёрстка экрана оплаты»	Исполнитель
Pages	ТЗ, протоколы, решения	«Протокол встречи 12.10»	Менеджер проекта
Внутренний проект	Пресейл, оценки, R&D	«Оценка для нового клиента»	Руководитель студии

Короткие идентификаторы проектов делайте осмысленными: по префиксу задачи в комментарии или коммите сразу видно, о каком клиенте речь.

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

Доступ клиента: роли Members и Guests

Команда студии работает с ролью Member, администраторы пространства с ролью Admin. Клиента приглашают как Guest и добавляют только в его проект. Гостевая роль ограничена: клиент может видеть задачи и комментировать, но не управляет настройками и не видит чужие проекты. Конкретный набор прав гостя зависит от настроек проекта и версии Plane, поэтому до первого приглашения заведите тестового гостя и посмотрите на проект его глазами.

Если нужен более тонкий контроль, например разные права для заказчика и его подрядчика, в старших тарифах Plane есть Granular Access Control. Для большинства студий хватает базовых ролей и дисциплины в том, что писать в клиентском проекте.

Что	Клиент (Guest)	Команда (Member)
Задачи своего проекта	В объёме, который разрешают настройки проекта	Все
Другие клиентские проекты	Не видит	Видит проекты, куда добавлен
Комментарии к задачам	Читает и пишет	Читает и пишет
ТЗ и протоколы	Согласованные версии	Все страницы и черновики
Оценки, ставки, маржа	Не видит, ведём во внутреннем проекте	Видит руководитель и менеджер
Часы по задачам	Получает выгрузкой к акту	Списывает и видит в отчётах
Заявки	Отправляет через Intake	Разбирает и принимает
Статус цикла	Видит доску проекта	Видит доску, таблицу и дашборды

Главное правило: в клиентском проекте пишем так, будто клиент читает каждое слово. Обсуждение оценок, внутренних ошибок и споров о приоритетах уходит во внутренний проект или в командный чат.

Статусы по этапам и подзадачи с одним ответственным

В Plane статусы настраиваются внутри проекта и группируются в стандартные группы: бэклог, не начато, в работе, завершено, отменено. Для студии удобно, чтобы статусы повторяли этапы работы и были одинаковыми во всех клиентских проектах:

1. Бэклог — заявка принята, но не запланирована.
2. Требования — уточняем у клиента, пишем ТЗ.
3. Дизайн — макеты и согласование.
4. Разработка — код.
5. Тест — внутренний QA.
6. Приёмка — мяч на стороне клиента.
7. Готово и Отменено.

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

Крупную задачу разбивайте на подзадачи так, чтобы у каждой был ровно один ответственный: дизайн экрана, бэкенд, фронтенд, тест. Задача без ответственного или с тремя ответственными на практике не принадлежит никому.

Зависимости фиксируйте связями blocking и blocked by. Если фронтенд ждёт API, связь видна обоим исполнителям и менеджеру, и задержка бэкенда перестаёт быть сюрпризом в день демо.

Метки используйте для типа работ: «дизайн», «фронтенд», «бэкенд», «QA», «DevOps», «аналитика». Две метки стоит завести обязательно: «гарантия» для исправлений в рамках договора и «вне договора» для запросов, которые нужно оценить и продать отдельно. По нашему опыту, именно вторая метка быстрее всего окупает внедрение трекера в студии.

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

Одни и те же задачи разным людям нужны в разном виде. Plane поддерживает сохранённые представления с фильтрами и несколько раскладок: список, доска, календарь, таблица и Gantt. Для студии работает такой набор:

• Клиенту — доска его проекта по статусам. Ничего лишнего.
• Менеджеру проекта — таблица по всем своим проектам с фильтром «Приёмка» и просроченными сроками.
• Тимлиду — доска по исполнителям, чтобы видеть перегрузку и задачи, заблокированные другими.
• Руководителю студии — Gantt по модулям крупных проектов и дашборд с загрузкой команды.
• Разработчику — «мои задачи» по всем проектам, отсортированные по приоритету.

Сложные фильтры удобно собирать на PQL, языке запросов Plane, похожем на JQL. Представления на уровне рабочего пространства позволяют смотреть сразу на все проекты, это главный инструмент менеджера, который ведёт несколько клиентов.

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

Документы и заявки: Pages и Intake

ТЗ, протоколы встреч, решения по архитектуре и описание окружений храните в Pages внутри проекта клиента. Документ можно связать с задачей, а задачи создать прямо из протокола: решение на встрече сразу превращается в работу с ответственным. Подробнее о том, что и где хранить, мы разбираем в статье о документации команды без Confluence.

Шаблон протокола встречи с клиентом:

• дата и участники;
• что показали;
• какие решения приняли;
• какие задачи создали, со ссылками;
• что ждём от клиента и к какому сроку.

Пароли и ключи доступа в Pages не храните. Для них нужен менеджер секретов.

Intake решает проблему заявок из ниоткуда. Клиент или менеджер заводит заявку в Intake, в том числе через email-адрес приёма. Дежурный менеджер разбирает поток раз в день: принимает в проект, отклоняет с объяснением или помечает дублем. В бэклог попадает только разобранная заявка, с меткой «гарантия» или «вне договора».

Учёт часов и почасовые договоры

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

Правила, которые работают:

• Списывать время ежедневно, а не в пятницу по памяти.
• Списывать на подзадачу, а не на проект целиком.
• Часы по гарантии помечать отдельно, их не выставляют клиенту.
• Работы «вне договора» не начинать до согласования оценки.

Plane не заменяет финансовую систему: ставки, счета и маржа считаются отдельно на основе выгрузки.

Контекст Казахстана. Почасовые договоры с казахстанскими ТОО обычно закрываются ежемесячным актом выполненных работ, и выгрузка часов по задачам становится приложением к нему. Клиенты привыкли писать в WhatsApp, поэтому правило «задача существует только в Intake» нужно проговорить на старте договора, а менеджеру выделить время на перенос сообщений. Если клиенту важно, чтобы данные хранились в Казахстане, ставьте self-hosted Plane на сервер казахстанского хостера. Хостинг оплачивается в тенге по договору, тогда как облачные тарифы оплачиваются картой в долларах. Какую редакцию выбрать, разбираем в статье о версиях Plane.

Чек-лист запуска Plane в студии

1. Одно рабочее пространство на студию, проект на клиента или продукт клиента.
2. Внутренний проект для пресейла, оценок и обсуждений.
3. Одинаковые статусы во всех клиентских проектах с критериями входа.
4. Метки по типу работ плюс «гарантия» и «вне договора».
5. Правило: у подзадачи ровно один ответственный.
6. Связи blocking и blocked by для зависимостей между исполнителями.
7. Сохранённые представления для клиента, менеджера, тимлида и руководителя.
8. Шаблоны страниц: ТЗ, протокол встречи, описание окружений.
9. Intake включён, назначен ответственный за ежедневный разбор.
10. Учёт времени включён, правило ежедневного списания объявлено.
11. Тестовый гость проверил, что видит клиент.
12. Первый клиент переведён в Plane, остальные после двух-трёх недель.

Как мы это делаем

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

Если вы хотите пройти этот путь с поддержкой, посмотрите страницу услуги внедрения таск-трекеров Jira и Plane: там описаны этапы, сроки и что входит в результат.

---

Источники. Тарифы и функции Plane: plane.so/pricing. Исходный код и документация Community Edition: github.com/makeplane/plane. Цены на октябрь 2026 года при годовой оплате и могут меняться.

Термины простыми словами

Рабочее пространство

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

Guest (гостевая роль)

Доступ для внешнего человека, например заказчика. Гость видит только свой проект в рамках настроек и может комментировать, но не видит других клиентов и внутренние обсуждения.

Intake

Единая точка приёма заявок в Plane, в том числе по email. Менеджер ежедневно разбирает поток: принимает в работу, отклоняет или помечает дублем.

Модуль и цикл

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

Бэклог

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

Blocking и blocked by

Связь между задачами: одна не может двигаться, пока не готова другая. Например, фронтенд ждёт бэкенд, и менеджер видит задержку заранее, а не в день демо.

QA

Проверка качества: внутреннее тестирование перед тем, как показать результат клиенту. В студии задача попадает на приёмку только после такого теста.

Granular Access Control

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