Построили в Notion систему управления задачами и ресурсами для DevOps-стартапа

Задача

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

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

Итоги нашей коллаборации: 

• На 75% сократили продолжительность ежедневных командных синхронизаций — с двух часов до 30 минут.
• На 87% уменьшили количество зарегистрированных клиентских претензий за первые 3 недели после внедрения предложенных нами решений.
• Создали единый контур управления, который объединил клиентские запросы, ежедневные задачи, спринты, роадмапы и проектные знания.
• Заложили основу для расчета маржинальности отдельных проектов и планирования загрузки специалистов.
• Сотрудники стали реже забывать о задачах, а менеджеры активнее информировать заказчиков о статусах, изменениях и причинах задержек.

Компания также получила:

• единый стандарт ведения проектов;
• более прозрачное распределение ресурсов;
• историю выполнения задач;
• базу знаний для передачи контекста;
• регулярную клиентскую отчетность;
• данные для анализа загрузки;
• основу для расчета маржинальности;
• возможность постепенно развивать систему без внедрения тяжелой ERP.

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

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

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

Решение: единый контур операционного управления

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

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

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

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

Любой запрос становится управляемой задачей

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

Для каждой задачи фиксировались:

• проект;
• клиент;
• ответственный;
• тип работы;
• приоритет;
• текущий статус;
• ожидаемый результат;
• связь со спринтом или роадмапом.

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

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

Ежедневные доски сохранили скорость реакции

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

На них команда видела:

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

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

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

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

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

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

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

Карточки проектов стали точкой входа для сотрудников

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

Мы определили минимальный набор информации, необходимый для работы:

• описание проекта и его бизнес-контекст;
• состав команды;
• зоны ответственности;
• ключевые клиентские контакты;
• особенности инфраструктуры;
• правила коммуникации;
• текущие задачи и риски;
• ссылки на документацию;
• связанные спринты и роадмап.

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

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

Клиентские отчеты стали частью процесса, а не отдельной задачей

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

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

• план прошедшего спринта;
• выполненные задачи;
• невыполненные задачи;
• причины переноса;
• текущие блокеры;
• план следующего спринта;
• актуальный бэклог.

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

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

Роадмапы связали ежедневную работу со стратегическими целями

Все проекты клиента можно было разделить на две основные группы.

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

Вторая — активная разработка или развертывание. Эти проекты создавали более крупные задачи, но лучше поддавались планированию.

Для второй группы мы создали роадмапы внутри той же системы.

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

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

Так роадмапы стали инструментом не только проектного, но и ресурсного планирования.

Новый формат стендапов сократил встречи в четыре раза

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

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

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

Результат

Мы помогли создать систему операционного менеджмента, с элементами knowledge base и основами для последующего создания ERP-системы.  Мы систематизировали работу IT-отдела компании, внедрили планы, прогнозы, прозрачность как для внутренних процессов, так и для взаимодействия с заказчиком. Самое главное, что система минимально повлияла на ежедневную работу сотрудников — ничего нового они делать не стали, они также ходят на созвоны, и берут задачи в чате, но теперь они упорядочены и учтены. 

Одним из наиболее заметных положительных эффектов стало снижение недовольства клиентов на 85-90%. В начале работы мы сделали Fire reporting system, куда вносились все претензии клиентов, которые были разделены на три уровня. По итогам внедрения новой системы таких претензий стало на порядок меньше, потому что сотрудники перестали забывать про задачи, и стали активнее держать клиента в курсе событий. 

Еще одним интересным эффектом системы стала возможность построения модели расчета маржинальности проектов. Но детали этого модуля мы раскрыть не можем. 

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

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

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