Регламенты нужны, чтобы упрощать работу
Переход на новые регламенты
Регламенты работы в Jira
Регламенты — не панацея
Распространенная проблема руководителей и менеджеров в IT — это коммуникация с командой. Информация не передается, карточки задач заполняются неправильно, сами задачи теряются, ответственных нет. Регламентов тоже нет или они неудобные, их не выполняют или за ними никто не следит.
Все не так страшно, пока все сидят в одном офисе: можно встать из-за монитора и обсудить вопросы лично. Для распределенной команды, где все работают удаленно, обмен информацией — это жизненно важный бизнес-процесс. Без этого IT-компания просто не сможет функционировать.
Рассказываем, как все устроено у нас — какие регламенты у нас приняты, как они нам помогают и как мы следим за их выполнением.
Регламенты нужны, чтобы упрощать работу
У нас разработчик получает уже ранжированный по важности список задач, чтобы их даже выбирать не приходилось — бери и делай по порядку. Об остальном заботится проджект-менеджер, а тасктрекер и автоматизация ему помогают.
Основной принцип: вообще не заставлять разработчиков. Пусть они пишут код и не парятся о заполнении карточек задач, статусов, полей и прочего.
Наши правила — это язык общения. Смена статуса задачи — это сигнал коллегам к началу работы. Если игнорировать статусы, задача будет простаивать. А если переключить статус по регламенту, то можно не писать в личку и не переспрашивать сто раз — система позаботится, чтобы задачу подхватили.
Наши правила помогают искать слабые места наших рабочих процессов. Jira хранит всю информацию о работе, каждый клик сотрудников можно выгрузить и проанализировать. Это значит, что все слабые места и «бутылочные горлышки» мы обнаружим и устраним.
Часто на Jira жалуются, что она слишком громоздкая, слишком замороченная, слишком тяжелая в освоении. Для нас это не избыточное переусложнение, а системный подход к коммуникации в команде.
Правила дорожного движения нужны, чтобы не случалось автомобильных аварий. Регламенты в разработке проектов нужны, чтобы не срывать сроки, чтобы себестоимость проектов не разрасталась из-за бесконечных обсуждений задач. С помощью наших правил мы не пытаемся выстроить тотальную систему контроля. Не пытаемся внедрять Jira просто из азарта, раз уж подписка оплачена. Это наш способ свести к минимуму потери времени, снизить трение в нашем механизме разработки проектов.
Переход на новые регламенты
Важно понимать, что внедрение регламентов — это постепенный процесс. Если руководитель внезапно установит диктатуру регламентов, он встретит сопротивление команды и молчаливый саботаж.
Изменения вносят шаг за шагом, привлекая команду к решению: «У нас есть проблема. Мы берем задачи в спринт, но тратим время на обсуждения и срываем сроки. Давайте попробуем поработать по-другому, будет ли так продуктивней?». Вместо того, чтобы воевать с командой, мы привлекаем их на свою сторону и вместе вырабатываем решение.
Изменения не будут эффективны, если команде станет некомфортно работать. Поэтому основной фокус — создать разработчикам условия, в которых они будут максимум времени тратить именно на разработку.
По нашему опыту, когда мы объяснили разработчикам смысл этих правил и обозначили, чего мы хотим от команды, им стало проще соблюдать регламенты. Когда цель действий стала понятна, люди сами начали предлагать новые инструменты и механики, чтобы улучшить процесс.
Конечно, недовольные будут всегда. Появление новых регламентов — это стресс для команды. Недобросовестным сотрудникам станет сложнее скрывать безделье. Но и добросовестные работники могут решить, что им не доверяют, что их усилия не ценят, что им собираются меньше платить. Задача руководителя — развеять опасения и обозначить недвусмысленные цели изменений.
Часто говорят, что для IT-проектов главное — это команда. Удивительно, как часто руководители забывают, что они тоже часть этой команды. Каждая компания уникальна, и выбрать комфортный алгоритм работы — это задача, которую можно решить только сообща.
Регламенты работы в Jira
Давайте разбираться, как мы работаем в таск-трекере.
Больше всего наш воркфлоу похож на Канбан — задачи переходят от сотрудника к сотруднику как на конвейере, у каждого только одна задача находится в работе. Задачи планируем недельными спринтами. Таски храним в Jira, все общение — в Slack.
Краткое описание движения задач по процессу. Новые задачи падают в бэклог в Jira. Разработчики в течение недели оценивают время на их выполнение, выясняют подробности, делят большие задачи на задачки и задаченьки.
Проджект-менеджеры ставят задачам приоритет и заполняют остальные поля. Дальше обычный алгоритм: разработка → проверка тимлидом и проджект-менеджером → тестирование → продакшен. С любого этапа задачу могут вернуть обратно на доработку.
В конце каждого рабочего дня мы выделяем час на планирование следующего спринта. Нам важно, чтобы в спринте не было обсуждения текущих задач — это отвлекает разработчиков, тормозит работу и срывает сроки. Все вопросы нужно выяснить заранее, чтобы брать в спринт только те задачи, которые готовы сделать.
Когда в карточке задачи появляется оценка времени — это сигнал проджект-менеджеру, что задачу можно брать в спринт.
Разработчики только декомпозируют задачу и дают оценку времени на работу. Все остальные поля — приоритет, ответственных и прочее — заполняет проджект-менеджер. Эти дополнительные поля нужны для настройки фильтров и сортировки карточек на досках в Jira.
В конце недели проджект-менеджер еще раз проверяет все задачи и запускает спринт. В понедельник разработчик садится за компьютер, открывает Jira, и видит список задач. Он с ними уже знаком, он уже выяснил все подводные камни, ему уже ничего не мешает писать код. Разработчик отхлебывает чаек и приступает к работе.
Регламенты — не панацея
К сожалению, регламентами не заменишь работников. В любом случае, будут случаться факапы, недопонимания, срывы сроков и простые человеческие ошибки. Как любая система, наша не дает стопроцентной гарантии.
У нас нет ответов на все вопросы. Например, наши разработчики работают только над одним проектом за раз, поэтому у нас нет конфликтов между проджектами за рабочее время специалиста в спринте. Мы не можем подсказать, как решать такие противоречия. Каждый маленький элемент паззла достался нам через пробы и ошибки. Это живая система, которая продолжает развиваться.
Сила процессов каждой компании — в их уникальности. Из многообразия систем и регламентов мы выбирали те методы, которые будут удобны нам, и не стеснялись отбрасывать все, что не сработало. Так победим.
Если хотите обсудить ваш проект, напишите нам. За 10 лет мы запустили 40 сложных программных продуктов для частных инвесторов, крупных бизнесов и государственных организаций. Поможем и вам 🙂
