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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обожаю эту картинку. Даже названия не нужно.

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

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

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

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

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

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

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

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

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

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