О пользе регламентов в жизни руководителя ИТ разработки

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

Она не совсем про Руководство проектами, она пошире: про руководство командами разработки. Но если вы Руководитель и у вас на проекте разработки ПО есть хотя бы пара разработчиков, вам ее будет полезно прочитать.

Эта статья – часть цикла статей о том, чего не рассказывают на курсах РП, и что в жизни понадобится вам с первого же дня работы: о так называемых софтскиллах РП. Кому это интересно, читайте статьи здесь и заходите в мой ТГ канал «Морковка спереди, морковка сзади».

Правила – это скучно.

Я давно заметил, что, когда набираю новых менеджеров и рассказываю им про регламенты и правила разработки в компании, они очень внимательно слушают, усиленно кивают и вообще – само внимание. А спустя пару недель или месяц, внезапно выясняется, что они не даже не кликнули по ссылке, которую я отправлял в письме. И читают регламенты исключительно из-под палки. Хотя, казалось бы, что там: 5 листов, 30 минут осознанного времени, не более. Почему так?

Когда я был маленький, меня заставляли мыть руки перед едой и я всегда бесился: мне это было незачем, это крало мое время и вообще, не слушаться было гораздо веселее, чем слушаться (что будет, если не послушаться маму??)

Когда я подрос, меня заставляли ходить в школу. Там было скучно, ставили странные оценки за неинтересные знания и надо было соблюдать ровно одно правило: не нарушать так, чтобы родителей не вызвали в школу. Потом был институт, где правило было одно: сдай сессию любой ценой. А потом началась работа, где мне стали платить деньги за сделанные проекты, но внезапно переставали платить за несоблюдение каких-то дурацких (как я тогда думал) правил.

«Для документов есть sharepoint, для формирования проекта надо делать бумажку с названием «Устав», который надо у всех подписать руками, для запуска очевидно необходимых работ надо делать документ с вызывающим зевоту названием «Финансово-Экономическое обоснование»».

А я только начал работать: энергии полно, я хочу перевернуть мир. Я точно знаю, чего хочет заказчик, я обсудил все с лидом разработки, работа кипит, через неделю релиз, мы успеваем и тут… Меня вызывает мой руководитель и ругается: проектный план неактуален, документов по проекту нет, тикетов нет, разработчики делают непойми что. Минус премия. Но за что?? Я же сделал проект? Я же обо всем договорился? Нечестно! «Все, я пойду на hh, буду искать место, где ценят не за бумажки, а за реальные результаты» — думал я. Сейчас я понимаю, насколько это была детская позиция. Но тогда никто не смог внятно объяснить, а зачем все это нужно?

Состояние «Я Художник, Я Так Вижу и плевать мне на ваши правила» я периодически встречаю в нашей айтишной среде до сих пор не только у разработчиков, но и у CEO достаточно крупных компаний. Откуда такое пренебрежение правилами, к теме статьи не относится. Важно зафиксировать, что на правила компании многие склонны класть болт, предпочитая работать без правил.

Зачем нужны правила? Ответ очевиден: для того же, для чего нужны законы в стране. Регламенты вашей компании – те же самые законы в миниатюре. Если их не будет совсем, в вашей компании будет бардак. Если их будет слишком много, ваша компания погрязнет в бюрократии. То есть приходим к моей любимой теме: баланс.

Где же баланс?

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

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

По моему опыту, бардак начинается уже в команде от 5-10 разработчиков. Но владельцы или менеджеры смотрят на это сквозь пальцы: вроде все работает, а то, что менеджер ноет, что надо процесс – так это менеджер рукожоп, управлять не умеет.

Когда команда превышает 20-30 человек, отсутствие регламентов становится критичным и начинается бардак. Бизнес не понимает, где обещанные плановые задачи, менеджер тоже не понимает, а Генеральный, понимая, что все сроки нарушаются, по критичным вопросам сам ходит к разработке, что вносит еще бОльший хаос. Начинаются круги операционного треша, который рождает еще больше треша. И на выходе получаем то, что на картинке.

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

Какие регламенты нужны?

Важно помнить о балансе: правила должны быть, но они не должны существенно тормозить работы. Для небольших команд разработки в 5-20 человек достаточно формализовать следующие шаги:

1. Поступление новой задачи/проекта: единая точка входа для новых задач, оценка задач, приоритизация задач.

2. Планирование задачи/проекта: планирование сроков и ресурсов, их фиксация.

3. Выполнение задачи/проекта: это ваш процесс разработки. Он так или иначе есть у всех, но важно следить за его исполнением согласно п2 выше и ограничивать внеплановые задачи.

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

Разумеется, регламентов может быть и больше, я говорю о необходимом минимуме, который дальше по мере роста можно масштабировать (к примеру, п1 можно разбить на правила оформления ФТ для бизнеса, правила оценки фич и правила приоритизации беклога и так далее). Главное помнить, что правила должны позволять работать команде с наименьшим количеством конфликтов, выдавая результат в предсказуемые сроки, предоставляя прозрачную отчетность.

Разумеется, из любых правил бывают исключения. Тот же Адзизес, гуру бизнес-консалтинга, говорит, что регламенты могут ограничивать бурный рост компании, когда надо захватывать новые рынки. Но это должны быть именно исключения. А если у вас 50% задач иду вне планов работ, сроки едут и бизнес ругается – наверное, регламенты все-таки нужны 😊

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

Итого:

Менеджерам, которые снисходительно относятся к регламентам, рекомендую помнить, что, не читая регламенты вашей компании, вы:

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

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

3. Ведете себя по-детски и непрофессионально. Убегают от законов дети. Позиция взрослого человека и профессионала — смотреть, работают правила или нет, и, если нет, менять их.

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

На прощание небольшой тест на зрелость вашу и вашей компании (писать результаты можно прямо в моем ТГ канале по ссылке вначале, а можно на Хабре):

• Уровень 1: есть ли регламенты управления разработкой в вашей компании?

• Уровень 2: читали ли вы их?

• Уровень 3: пробовали ли вы их менять?

• Уровень 4: меняли ли вы их (п.3 и 4 – это не одно и тоже!)

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

Как говорится: «Тихо, тихо ползи, улитка, по склону Фудзи вверх, до самых высот!»

 

 

 

 

 

 

 

 

 

 

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

 

Пример хороший 1: есть беклог, распределенный по спринтам, есть даты готовности спринтов – бизнес понимает, когда работа будет сделана.

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

Пример плохой 1: есть беклог, но нет правил приоритизации, в беклог пихают что попало вне очереди, все планирование по спринтам едет. Вроде процессы есть, а бизнес не понимает, когда будет результат

Пример плохой 2: есть проектный план с расставленными ресурсами, но ресурсы дергают