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

July 25 2023
Регламенты нужны, чтобы упрощать работу
Переход на новые регламенты
Регламенты работы в Jira
Регламенты — не панацея

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Список задач разработчика на спринт с общим разбиением на статусы: Подготовить к работе, В работе (отдельно Эпики + Стори и Задачи) и Готовые задачи.

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

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

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

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

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

Автор статьи
Мария Михневич
Менеджер команды WB—Tech. Администратор таск-трекера Jira

Подпишитесь на блог WB—Tech

Никакого спама, только анонсы новых статей

    Последние статьи

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

    Рассказали, как осуществили перенос пользовательских данных из Jira (Internal Directory) в директорию Microsoft Active Directory.

    Как эффективно хранить и актуализировать корпоративные данные средствами low/no-code

    Рассказали, как организовали поток HR-данных, чтобы оргструктура и бонусно-бухгалтерские расчеты всегда были актуальны.

    Мало кода, больше результативности: платформы low-code и no-code

    О low-code и no-code платформах, примерах использования и разбор нужно ли быть программистом.

    ИП Гришанин Кирилл Олегович
    ИНН 774313842609

    Коворкинг Starthub

    Б. Новодмитровская ул., 36, стр. 12, вход 6,
    Москва, Россия, 127015

    Коворкинг Wework

    Ahad Ha'am 54,Tel Aviv-Yafo,Израиль

    © 2023 WB—Tech. Мы разрабатываем уникальные решения для компаний из России, США и Европы.