Эта статья - продолжение моей статьи "о пользе регламентов" в рамках цикла статей "О чем РП не рассказывают на курсах". 

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

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

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

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

Ну а теперь - приступим. И начнем издалека.

Почему ИТ - это не “свободные художники”.

Для начала, откуда этот разговор: я много раз выстраивал процессы работы ИТ команд и периодически сталкиваюсь с мнением, что процессы и регламенты в ИТ не нужны, они только вредят свободной творческой атмосфере. Бюрократия убивает дух ИТшника, как свободного художника. При этом я вижу, как эти "свободные художники" вкалывают по 12 часов в день почти без выходных, чувствуют себя крайне важными и выгорают, а их заказчики, бизнес, ходят и ругаются, что задачи не выполняются в срок, ИТшники жрут огромный ФОТ и занимаются "непойми чем". Картина настолько повсеместна, что явно требует решения.

Если такое происходит в небольшой компании, где 10 разработчиков и один техдир, который все проблемы знает наизусть, все разруливается вручную. Но когда ИТ команда становится больше 15-20 человек, а бизнес представляет собой несколько подразделений, ручное управление становится просто опасным, потому что:

1. ИТ команда перестает эффективно и предсказуемо решать проблемы бизнеса. 

2. Бизнес справедливо начинает ругаться на неэффективное ИТ.

3. ИТ команда выжигает саму себя на бессмысленную беготню по непонятным приоритетам. Тот случай, когда ты пытаешься всем угодить, а в итоге сам виноват.

И закономерный итог: замедление цифровой трансформации в компании, замедление скорости разработки продуктов, и, что самое печальное, непредсказуемость.

Если вы видите похожую ситуацию у вас на рабочем месте - эта статья про вас.
Если вы не видите такую ситуацию у вас на рабочем месте - это вовсе не значит, что у вас такой проблемы нет. По опыту, бОльшая часть таких проблем не осознаются топ-менеджерами, потому что они находятся “внутри” процесса. Получается также, как в психологии: чтобы увидеть проблему, надо поглядеть на нее со стороны, глазами другого человека. А у них времени нет, надо решать текучку. А текучки все больше, а времени все меньше… Как в бородатом анекдоте: “Че думать-то?! Прыгать надо!!”

Как то я общался с другом, у которого был собственная компания, в ней продукт и команда разработки на 20 человек. Он меня клятвенно заверял, что у него все сроки под контролем и он отлично знает, чем занят каждый разработчик. А когда покопались, выяснилось, что переносы сроков носят массовый характер, планирование не ведется и все работает только потому, что владельцу доверяют заказчики продукта, и они готовы терпеть переносы сроков. Ясно же, что эта ситуация не будет вечной: инвестденьги не бесконечны, а как относятся к людям, которые не способны выдержать данное слово?

Это же касается и стартапов: там важно получить результат в рамках выделенного финансирования, срок не столь важен. Как-то на Ютюбе я слушал лекцию Продакта из Яндекса, которая говорила, что их best practice - это не озвучивать сроки заказчику, потому что сроки все время едут вправо. “Никогда такого не было и вот опять” :)  Такое возможно только в одном случае: вас залили инвестденьгами. Но такое бывает редко и обязательно заканчивается. Рано или поздно, к такому менеджеру придет дедлайн и его просто уволят за профнепригодность (его терпели, потому что были деньги, а теперь денег нет).

Итого: случаи, когда у вас есть роскошь работать в режиме “свободного художника” в ИТ встречаются редко и обязательно заканчиваются. Свободные художники превращаются в производственный персонал, который выполняет задачи в срок и получает за это зарплату. ИТ не ценно само по себе. ИТ дает бизнесу операционную эффективность. За счет CRM компания не теряет лиды и зарабатывает больше. За счет ERP компания не теряет заявки, обрабатывает их быстрее и зарабатывает больше. За счет CMDB снижаются операционные косты на поддержку ИТ инфраструктуры.  За счет сайтов и приложений - тоже самое. Даже если я - ИТ интегратор, и я сам себе бизнес, я все равно не первичен, я делаю работы для компании, которая хочет заработать с помощью моих проектов. Я не свободный художник. Мои проекты завязаны на долгосрочные цели компаний, которые ведут их к достижению их целей. 

Все ИТ продукты - это помощь бизнесу. И мы, ИТшники, работаем на бизнес. Это очень важно помнить. Бизнес - это не идиоты, которые хотят сделать вашу жизнь плохой. Нет, это чуваки, которые платят нам живые деньги за то, что мы им помогаем работать их работу быстрее.

Но как же правильно помогать работать быстрее и прозрачнее?

Базовый процесс

Итак, что у нас на входе: 

• ИТ команда завалена задачами, беклог пухнет, огромное число внеплановых задач от бизнеса, Бизнес эскалирует руководству плохой перфоманс ИТ.

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

Красные круги операционного ада, и выход из него всегда один и тот же: процессы. 

Чтобы качественно решить задачу, нужна точная постановка. Она будет звучать так:

1. Бизнес должен иметь предсказуемые и прозрачные (всегда можно увидеть) сроки выполнения задач.

2. ИТ команда должна быть защищена от треш-разработки (когда требования формируются "на ходу" непредсказуемо).

Мой опыт автоматизации процесса управления ИТ командами у клиентов нашей компании "КР Проектное управление" показывает, что для начала достаточно формализовать следующие шаги:

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

Данный процесс легко масштабируется на подпроцессы при необходимости: к примеру, сразу очевидно, что нужен формализованный процесс разработки (тут любимый спор на тему SCRUM, Kanban или их гибриды), процесс планирования можно разделить на планирование потока небольших работ и планирование и инициацию проектов, и так далее.

Пробежимся по шагам подробнее.

1. Получение требования.
   Рыба гниет с головы, а хаос начинается с того, что требования от бизнеса прилетают в ИТ команду по-разному: по почте, со встречи, по прямому звонку разработчику (так же быстрее!). Для структуризации хаоса, надо оставить один четкий и понятный всем канал. Каналом может быть: email, проект в вашем трекере, даже эксель - на самом деле неважно. Важно, чтобы его регулярно разбирали, и он был доступен вашему бизнесу.

   Этим шагом вы сразу защитите вашу ИТ команду:

   • От внеплановых задач, поступающих разработчикам напрямую.

   • От некачественных постановок (перед передачей постановки разработчику, вы сможете ее проверить и принять или НЕ принять).

2. Примерная оценка.
   Необходима для оценки и приоритизации. Бизнес сам не должен оценивать фичи, оценивать должны те, кто будет выполнять работы. Оценка предварительная, с точностью 30-50%, так как для большой фичи дать точную оценку с непроработанными ФТ невозможно, а принять решение go-no go все-таки надо. Примерную оценку дают обычно менеджеры на основании оценки разработки (как делать оценку так, чтобы попадать, напишу отдельно у себя на ТГ канале, координаты см выше).

3. Согласование бюджета. Тут от нас (ИТшников) ничего не надо. Сидим на попе ровно и ждем, согласовывают работу или нет. Если нет - отмена, если да - идем далее.

4. Планирование. Очень важный шаг. Это то место, где ИТ менеджер на основании предварительной оценки дает срок реализации и фиксирует его с заказчиком. Как мы помним, наша задача - делать все, чтобы его не двигать вправо, а если и двигать, то предсказуемо, прозрачно и заранее. Планирование может осуществляться в Гантте через расстановку задач, через расстановку по спринтам или тикетами в трекере - зависит от вашего процесса и инструментов, используемых в вашей компании. Сюда же будет относиться подпроцесс изменения сроков: change management. Он 100% вам понадобится как раз на случай срочноважных задач от бизнеса, чтобы показать “для того чтобы сделать что-то нужное, надо перенести что-то ненужное”. Ну, или увеличить команду, если нужно все и сразу.

5. Исполнение.

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

   Главное требование к исполнению - прозрачность процесса для бизнеса и для ИТ менеджеров. Ведь чем непрозрачнее работа разработчика, тем чаще его будут отрывать всякими тупыми вопросами вида “а что с этим тикетом?” И разработчик вместо работы, будет отрываться на то, что элементарно визуализируется (например, через статусную модель спринта).

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

6. Приемка.

   Это то место, где заказчик принимает работы и должен сказать ОК. 

7. Передача в поддержку.

   Это процедуры, необходимые для передачи вашего кода или доработок в службу эксплуатации (если она есть).

Итого, базовый процесс состоит всего из 7 ключевых кубиков. Причем, он будет состоять из них как для небольшой фичи на 1 человекодень (ее тоже надо прогонять через процесс), так и для проекта на 5000 человекодней. Только для большого проекта это все по PMBoK будет называться фазами Инициации, Планирования, Исполнения, Монторинга и Завершения. Как видите, ничего нового.

А дальше для каждого кубика пишется регламент. Даже если он небольшой (“все новые требования шлите на it@xxxxx.xx”), он все равно нужен, чтобы каждый раз не надо было объяснять и бизнесу и своим сотрудникам, как работает команда. Пишете регламент, согласовываете, вывешиваете в общедоступном месте и дальше просто отдаете ссылку нуждающимся.

Регламенты.

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

Условно, для команды в 10 разработчиков достаточно простых правил в пару абзацев, а для команды из 300 человек придется расписать все подробнее.

1. Регламент поступления требований: должен содержать требования к каналу поступления, к оформлению требований и к скорости реагирования. Это регламент больше для структуризации вашего заказчика, который привык, что до этого все было удобнее и проще. Регламент должен содержать требования к выставлению приоритета от бизнеса. Практика показывает, что это крайне болезненный процесс: бизнес все и всегда считает критичным, но ИТ команда не должна разрываться. Так что тут возможно выделение отдельного регламента по приоритизации задачи.

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

3. Регламент согласования бюджета: понадобится для больших организаций, где выделение денег, особенно на большие проекты, это долгая история.

4. Регламент планирования: касается согласования сроков. Сюда можно включить правила приоритизации и планирования задач к исполнению из беклога, оформление проектных планов в Гантте, управление бюджетами и ресурсами. 

5. Регламент исполнения: Тут должны быть правила разработки по этапам (дизайн-разработка-тестирование), включая правила постановки задачи в вашем инструменте (трекер, как правило), правила оформления кода, правила работы с репозиториями, правила списания времени, правила внутреннего тестирования. Здесь можно долго упражняться, главное помнить несколько целей: 

   1. Защищенность разработчика и понимание, чем он занимается в ближайшую неделю, как минимум (чтобы не дергаться, а спокойно писать код).

   2. Прозрачность для стороннего наблюдателя (чтобы разработчиков не дергали их же менеджеры или бизнес).

   3. Контроль ключевых точек (очереди в аналитику, разработку и тестирование, перфоманс отдельных команд и тп) - это нужно для руководителя, чтобы понимать, хватает ему ресурсов или нет и получать точные данные об этом (поможет при запросе ресурсов).

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

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

Вывод

Что мы получим после формализации 7 кубиков?

1. Четкое понимание потока новых задач и контроль очередей на входе в каждое сосотояние, который позволит выявить “тупняки”.

2. Четкое понимание порядка выполнения и сроков.

3. Прозрачный процесс разработки.

4. Процесс передачи в поддержку, чтобы потом мучительно не вспоминать “а что это мы навнедряли?”

Никакого хаоса.

Контролировать все точки по этим кубикам - одно удовольствие:

• бизнес ругается, что его задачи не выполняются? Давайте поглядим на качество постановок - все задокументировано;

• ИТ разработка тормозит? - смотрим очереди: общую, на аналитику, разработку и тестирование и идем к руководству просить дополнительные ресурсы.

Выглядит просто. Для реализации, как правило, хватает проектной системы (планирование ресурсов и бюджетирование) и трекера (управление задачами разработки). Почему же этого никто не делает?

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

Остальным , на мой взгляд, мешает то, что всегда мешает при внедрении новых бизнес процессов: невозможность взглянуть на проблему “сверху” из-за огромного количества операционки, сопротивление новому на всех уровнях от разработчиков (они расскажут про цифровое рабство), до самого бизнеса (удобно бегать к разработке напрямую, а потом валить все на ИТ), короче все по классике: верхам некогда, низам пофигу. 

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

PS: Если есть замечания и дополнения по подходу - буду рад комментариям.

PPS: Если вам нужна помощь для реализации подхода выше - пишите по контактам в комментариях.

PPPS: И подписывайтесь на мой канал: “морковка спереди, морковка сзади” где я разбираю кейсы для руководителей проектов, которым их не учат на курсах.