---

Эффективное управление проектами и процессами имеет решающее значение для организаций любого размера.

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

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

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

Пользовательские разрешения играют критическую роль в платформах B2B SaaS, особенно в инструментах управления проектами, где баланс между сотрудничеством и безопасностью может определить успех проекта.

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

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

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

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

Понимание пользовательских разрешений

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

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

В контексте программного обеспечения для управления проектами, такого как Blue, пользовательские разрешения включают:

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

Важность пользовательских разрешений в управлении проектами трудно переоценить:

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

Достижение согласия

Мы уже писали, что каждая функция в Blue должна быть твердым ДА, прежде чем мы решим ее разработать. У нас нет роскоши сотен инженеров и возможности тратить время и деньги на создание вещей, которые не нужны клиентам.

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

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

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

Больше гибкости в управлении доступом пользователей.

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

Почему?

Мы понимали, что это сложно!

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

Когда мы изучили рынок, мы заметили, что очень немногие из наших конкурентов пытались внедрить мощный механизм пользовательских разрешений, как тот, который запрашивали наши клиенты. Те, кто это делал, часто оставляли его для своих самых высоких корпоративных планов.

Стало ясно, почему: усилия по разработке значительны, а ставки высоки.

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

Бросая вызов статус-кво

Тем не менее, по мере того как мы продолжали расти и развиваться, мы пришли к важному осознанию:

Традиционная модель SaaS, при которой мощные функции зарезервированы для корпоративных клиентов, больше не имеет смысла в сегодняшней бизнес-среде.

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

Мы задали себе вопрос: почему размер рабочей силы или бюджета компании должен определять их способность защищать свои данные и поддерживать эффективные процессы?

Функции уровня предприятия для всех

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

Мы считаем, что:

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

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

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

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

Проектирование и разработка

Когда мы решили заняться пользовательскими разрешениями, мы быстро поняли, что сталкиваемся с огромной задачей.

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

Задача была сложной: нам нужно было реализовать каскадные разрешения, позволить редактирование на лету, внести значительные изменения в схему базы данных и обеспечить бесшовную функциональность по всей нашей экосистеме — веб, Mac, Windows, iOS и Android приложения, а также наш API и вебхуки.

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

Наш подход сосредоточился на двух ключевых принципах:

1. Разделение функции на управляемые версии
2. Принятие поэтапной доставки.

Столкнувшись со сложностью полномасштабных пользовательских разрешений, мы задали себе важный вопрос:

Какова была бы самая простая возможная первая версия этой функции?

Этот подход соответствует принципу Agile о доставке минимально жизнеспособного продукта (MVP) и итерации на основе обратной связи.

Наш ответ был удивительно простым:

1. Ввести переключатель для скрытия вкладки активности проекта
2. Добавить еще один переключатель для скрытия вкладки форм

Вот и все.

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

Хотя это может показаться не впечатляющим на первый взгляд, этот подход предложил несколько значительных преимуществ:

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

И вы знаете, на самом деле довольно скромно иметь огромное видение чего-то, а затем выпустить что-то, что является такой маленькой частью этого видения.

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

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

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

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

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

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

Вот конечный результат:

Технические соображения

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

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

GraphQL, с другой стороны, похож на разговор с шеф-поваром, который может приготовить что угодно. Вы говорите шеф-повару, какие именно ингредиенты вы хотите (поля данных) и в каких количествах. Затем шеф-повар готовит блюдо, которое точно соответствует вашему запросу — ни больше, ни меньше. Это, по сути, то, что делает GraphQL — он позволяет клиенту запрашивать именно те данные, которые ему нужны, а сервер предоставляет только это.

Важный обед

Примерно через шесть недель после начальной разработки Blue наш главный инженер и CEO вышли пообедать.

Тема обсуждения?

Стоит ли переключаться с REST API на GraphQL. Это не было легким решением — принятие GraphQL означало бы отказ от шести недель первоначальной работы.

На обратном пути в офис CEO задал главный инженер важный вопрос: "Будем ли мы сожалеть о том, что не сделали это через пять лет?"

Ответ стал очевидным: GraphQL был правильным путем.

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

Наше предвидение в принятии GraphQL принесло плоды, когда дело дошло до внедрения пользовательских разрешений. С REST API нам понадобилась бы другая конечная точка для каждой возможной конфигурации пользовательских разрешений — подход, который быстро стал бы непрактичным и трудным для поддержки.

GraphQL, однако, позволяет нам динамически обрабатывать пользовательские разрешения. Вот как это работает:

• Проверки разрешений на лету: Когда клиент делает запрос, наш сервер GraphQL может проверить разрешения пользователя прямо из нашей базы данных.
• Точное извлечение данных: На основе этих разрешений GraphQL возвращает только запрашиваемые данные, которые соответствуют правам доступа пользователя.
• Гибкие запросы: По мере изменения разрешений нам не нужно создавать новые конечные точки или изменять существующие. Один и тот же запрос GraphQL может адаптироваться к различным настройкам разрешений.
• Эффективное извлечение данных: GraphQL позволяет клиентам запрашивать именно то, что им нужно. Это означает, что мы не запрашиваем избыточные данные, которые могут потенциально раскрыть информацию, к которой пользователь не должен иметь доступ.

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

Проблемы

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

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

Наше решение включало несколько раундов тестирования пользователей и итеративного проектирования.

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

Обеспечение согласованности между платформами представило собой свои собственные проблемы. Нам нужно было внедрить пользовательские разрешения единообразно на наших веб-, настольных и мобильных приложениях, каждое из которых имело свой уникальный интерфейс и соображения пользовательского опыта. Это было особенно сложно для наших мобильных приложений, которые должны были динамически скрывать и показывать функции в зависимости от разрешений пользователя. Мы решили эту проблему, централизовав нашу логику разрешений на уровне API, обеспечивая, чтобы все платформы получали согласованные данные разрешений.

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

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

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

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

Этот подход запуска для подмножества пользователей, а также наш типичный 2-3 недельный "бета" период в нашем публичном бета-версии помогает нам спокойно спать по ночам. :)

Взгляд в будущее

Как и с любыми функциями, ничего никогда не бывает "сделано".

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

Давайте подробнее рассмотрим каждый аспект.

Разрешения на теги

Мы считаем, что было бы замечательно иметь возможность создавать разрешения на основе того, имеет ли запись один или несколько тегов. Самый очевидный случай использования заключается в том, что вы создаете пользовательскую роль "Клиенты" и позволяете пользователям в этой роли видеть только записи, имеющие тег "Клиенты".

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

Это может стать еще более мощным с помощью комбинирования AND/OR, где вы можете задавать более сложные правила. Например, вы можете установить правило, которое позволяет доступ к записям, помеченным как "Клиенты" И "Публичные", или к записям, помеченным как "Внутренние" ИЛИ "Конфиденциальные". Этот уровень гибкости позволит создать невероятно тонкие настройки разрешений, соответствующие даже самым сложным организационным структурам и рабочим процессам.

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

Фильтры пользовательских полей

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

Представьте, что вы можете установить разрешения следующим образом:

• Показывать только записи, где выпадающий список "Статус проекта" установлен на "Публичный"
• Ограничить видимость элементов, где многофункциональное поле "Отдел" включает "Маркетинг"
• Разрешить доступ к задачам, где отмечен флажок "Приоритет"
• Отображать проекты, где числовое поле "Бюджет" превышает определенный порог

Настраиваемая навигация по проектам

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

Управление комментариями

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

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

Заключение

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

С Blue у вас есть все функции, доступные с нашим планом — мы не считаем, что функции уровня предприятия должны быть зарезервированы для корпоративных клиентов!