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

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

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

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

Рассказываем, как всё устроено у нас — какие регламенты у нас приняты, как они нам помогают и как мы следим за их выполнением.

Регламенты нужны, чтобы упрощать работу

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

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

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

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

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

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

Переход на новые регламенты

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

Изменения вносят шаг за шагом, привлекая команду к решению: «У нас есть проблема. Мы берем задачи в спринт, но тратим время на обсуждения и срываем сроки. Давайте попробуем поработать по-другому, будет ли так продуктивней?». Вместо того, чтобы воевать с командой, мы привлекаем их на свою сторону и вместе вырабатываем решение.

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

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

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

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

Регламенты работы в Jira

Давайте разбираться, как мы работаем в таск-трекере.

Больше всего наш воркфлоу похож на Канбан — задачи переходят от сотрудника к сотруднику как на конвейере, у каждого только одна задача находится в работе. Задачи планируем недельными спринтами. Таски храним в Jira, все общение — в Slack.

Мы уже писали подробно, как выстроена наша работа в Jira →

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

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

Проджект-менеджер создает задачу, описывает её и назначает исполнителя

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

Когда в карточке задачи появляется оценка времени — это сигнал проджект-менеджеру, что задачу можно брать в спринт.

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

Разработчики только декомпозируют задачу и дают оценку времени на работу. Все остальные поля — приоритет, ответственных и прочее — заполняет проджект-менеджер. Эти дополнительные поля нужны для настройки фильтров и сортировки карточек на досках в Jira.

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

Список задач разработчика на спринт

Регламенты — не панацея

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

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

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