Кейс «Инглекс»: как мы сделали процессы в компании прозрачными

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

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

Школа «Инглекс» начиналась с небольшой команды, но со временем разрослась до 150 сотрудников (не считая преподавателей). Часть людей работала в офисе, часть — удаленно. И, само собой, начались менеджерские проблемы.

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

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

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

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

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

Мы решили реализовать концепцию «единого окна в МФЦ» в рамках компании. Рассмотрим, какие функции выполняет наш проектный офис.

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

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

Уточняет ТЗ. Бывает так, что заказчик описывает задачу неполно и отдает исполнителю. Последний отвлекается от своих дел, смотрит задачу, а там чего-то не хватает. Исполнитель просит ПО выяснить все недостающие детали. Так остальные работники могут полностью сконцентрироваться на делах, а не на переписках и созвонах.

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

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

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

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

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

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

Если вы хоть раз писали маркетинговый или пиар-текст, вы знаете, что над тремя предложениями можно просидеть целый день, крутить их туда-сюда, пока не «кликнет». А для человека со стороны результат работы — это три предложения, и просто невозможно поверить, что это заняло 5 часов. Поэтому мы не просим контентщиков трекать реально потраченное время, чтобы не создавать напряжения.

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

И вот так гибко мы подходим ко всем отделам. У всех есть свои тонкости, и ушло некоторое время на притирку.

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

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

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

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

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

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

За 1 год существования проектного офиса удалось: