В первый день работы с трекером команда создает проекты, приглашает коллег и заводит задачи. Через несколько месяцев меняется порядок согласования, появляются новые роли, часть работы начинают выполнять автоматические правила. Потом нужно объединить проекты, передать дела ушедшего сотрудника или разобраться, почему задача оказалась в другом статусе.
В такие моменты особенно заметно, насколько хорошо инструмент приспособлен к жизни компании.
Мы делаем Quevell с расчетом на эту жизнь. Чтобы команда могла вести повседневную работу, менять свой процесс и понимать, что происходит с ее задачами, настройками и данными.
В основе продукта лежат 19 лет опыта его основателя в корпоративном IT: эксплуатация сервисов, управление доступом, интеграции, администрирование и миграции. Из этой работы выросло внимание к вопросам, которые продолжают возникать после внедрения: как сопровождать систему, кто может ее менять, как проверить результат и что останется от прежних решений.
Начинать с задачи человека
У команды есть вполне конкретные причины открыть трекер. Исполнителю нужно понять, что делать дальше. Руководителю нужно увидеть, где работа остановилась. Администратору нужно изменить процесс так, чтобы коллеги могли продолжить работу.
Нам близок подход Amazon Working Backwards. Перед разработкой там описывают будущий продукт в виде пресс-релиза и ответов на вопросы: кому он нужен, какую проблему решает, что понравится клиенту и что может его разочаровать. Этот механизм описан в письме Энди Джесси акционерам за 2024 год.
Полезен сам порядок рассуждения: сначала представить, что изменится для человека, затем выбирать реализацию.
Например, возможность создать правило автоматизации оставляет важный вопрос: как понять, что оно сделает с существующими задачами?
В Quevell правило можно проверить на реальных данных без сохранения изменений. Проверка показывает подходящие задачи и действия, которые были бы выполнены. Внешние вызовы при такой проверке не отправляются. Администратор получает возможность оценить результат до включения правила.
Это тот уровень конкретности, к которому мы стремимся. У каждой возможности должен быть понятный рабочий смысл, включая действия человека перед ее использованием и после него.
Помогать менять процесс
Команды уточняют свои договоренности по мере работы. Добавляют согласование, убирают лишний этап, разделяют большой проект, меняют ответственность. Мы хотим, чтобы Quevell позволял развивать процесс и сохранял достаточно информации для разбора изменений.
Поэтому опубликованные рабочие схемы имеют историю ревизий. Можно посмотреть прежнюю версию, узнать автора и время публикации, загрузить ее как черновик для новой. Возврат к прежнему устройству процесса тоже становится новым осознанным изменением.
У задачи есть своя история, у компании есть журнал изменений. Если потребуется выяснить, кто изменил настройку или выдал доступ, ответ должен находиться в системе.
Хороший пример внимания к последствиям изменений есть у Stripe. В материале о новом порядке выпуска API компания объяснила, что клиенты просили большей предсказуемости для планирования своей инженерной работы. В ответ Stripe изменила порядок релизов и переработала журнал изменений, чтобы было проще понять влияние обновления на конкретную интеграцию. Нам близок этот принцип: развитие сервиса должно учитывать работу людей, которые от него зависят.
В собственной разработке мы проверяем изменения автоматически и на отдельном стенде перед выпуском. Причины архитектурных решений записываем. Так при следующем изменении можно вернуться к исходной задаче и понять, почему система устроена именно так.
Сохранять управляемость
В небольшой команде многое можно согласовать в разговоре. По мере роста становится важнее явно определить доступ и ответственность.
В Quevell права задаются ролями в проектах и ограничениями отдельных задач. Права администратора можно предоставить на срок: после его окончания они перестают действовать автоматически. Передача дел помогает передать работу преемнику при уходе сотрудника.
За этими решениями стоит простое ожидание: человеку нужно достаточно полномочий для своей работы, а компании нужна возможность разобраться, кому и зачем они предоставлены.
Мы также считаем, что сопровождение самого трекера должно требовать разумных усилий. Если обычная административная операция превращается в обход десятков проектов вручную, для нас это повод пересмотреть устройство продукта. Внутри Quevell этот принцип закреплен отдельно: сокращать административную работу и не создавать искусственных неудобств ради продажи следующего тарифа.
Он относится и к данным. Компания должна иметь возможность забрать результаты своей работы. Сейчас Quevell поддерживает экспорт задач в CSV, архив с вложениями и экспорт страниц базы знаний в Markdown. Форматы и ограничения описаны в документации; единой выгрузки всей компании пока нет. Данные команды мы не продаем. В сервисе нет рекламных пикселей, записи пользовательских сессий и сбора отпечатков браузера. Это часть нашего отношения к информации, которую компании доверяют рабочему инструменту.
Дать команде попробовать свой процесс
Сейчас Quevell объединяет задачи и проекты, доски, спринты, рабочие схемы, автоматизацию и базу знаний. Через API его можно связать с другими системами.
Мы хотим, чтобы команда могла проверить продукт на своей работе: провести небольшой проект, настроить нужные поля, попробовать автоматизацию, посмотреть историю изменений.
Для этого пять мест и один сервисный аккаунт доступны бесплатно, со всеми возможностями, пока компания активна. Пробного периода с обратным отсчетом нет. Дополнительные места оплачиваются отдельно.
Дальнейшее развитие Quevell мы хотим строить на конкретных рабочих ситуациях. В обращении пользователя нам важно понять, чего он пытался добиться, где возникло препятствие и какие последствия оно имеет для команды. Такой разговор помогает выбрать решение, которое будет полезно и за пределами одного запроса.
Мы хотим добиться вполне практичного результата: чтобы команда могла годами вести работу в Quevell, менять устройство своих процессов и сохранять понимание происходящего.
В этом блоге будем разбирать решения, которые помогают к этому прийти: инженерные и управленческие практики, работу с доступом и данными, устройство надежных систем. Первая история о самом Quevell. Следующие смогут быть полезны и тем, кто работает с другими инструментами.