Приветствую. Меня зовут Игорь Устюжанин.

Мне довелось поработать в разных ролях при разработке ИТ-продуктов - от инженера-программиста до руководителя продукта. Этот опыт я получил в компании СКБ Контур, куда пришел разработчиком аж в 1999 году, будучи студентом 4-го курса.

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

«Комната с опускающимся потолком» — в названии статьи я пытался передать эмоцию руководителя проекта, когда он оказывается в ситуации жуткого дефицита ресурсов, бесконечной очереди задач и в условиях постоянной нехватки времени. Эти ощущения вызывают ассоциацию какого-то смыкающегося пространства.

Оговорки

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

Во-первых, что такое сопровождение, что я понимаю под этим термином? Когда у нас появляется первый клиент, мы, продавая сервис, обещаем, что:

• продукт будет без багов;

• если это веб-продукт, то он будет скорострельным, доступным 24/7;

• если продукт зависит от законодательства, то будет онлайн-соответствие законодательству.

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

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

Все находятся в одной подводной лодке, все работают на одну цель, один результат.

Цель статьи — рассказать о причинах. То есть вскрыть природу происходящего: почему внутри команды начинаются противоречия.

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

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

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

Но я уверен, что основные мысли статьи применимы к любой разработке ИТ-продуктов.

Итак, поехали!

Заинтересованные стороны

Нужно понимать, что проект (продукт), окружен ожиданиями определенных лиц:

• Руководители, которые запускали этот проект. Или инвесторы, которые вкладывались в проект. Всем им показывали бизнес-план с финансовыми показателями, сроками, количеством фичей и пользователей;

• Руководитель проекта;

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

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

Ожидания заинтересованных сторон

График демонстрирует динамику развития продукта.

По вертикали отложен какой-то объем V (это может быть: количество пользователей, объем выручки, количество новых фич и т.д), по горизонтали — время t. Точка t0 — это точка, в которой у нас появился первый клиент и, соответственно, пласт задач сопровождения.

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

Идеальная картинка, конечно, демонстрируется третьим синим графиком. Она предполагает, что произойдет ускорение динамики.

А если по факту окажется второй сценарий (красная линия), то это будет вызывать вопросы, будет ощущение, что что-то идёт не так.

Шаг индукции

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

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

На вертикальной оси на графике откладывается объем ресурса команды. По горизонтальной оси — время. Точка t0 — это момент, когда с появлением первого пользователя в продукте, появляется поток задач сопровождения. t1 и t2 — время выпуска первой и, соответственно, второй версии продукта после появления первого пользователя. Выделенная синим область — это объем ресурса команды, потраченного на решение задач сопровождения, остальное (то, что выше выделенной области) в столбиках (t0-t1 и t1-t2) — это ресурс, потраченный на задачи развития (создание чего-то нового, чего раньше не было в продукте).

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

Рассмотрим итерацию развития продукта t0—t1.

Выделенная синим область — багаж сопровождения, который был до этого. А то новое, что вы сделали в t0—t1 (например, новая фича) расширило границы вашей ответственности (элементарно кода стало больше, система усложнилась), и, соответственно, в итерацию t1—t2 задача сопровождения стала больше. Помимо нагрузки, которая присутствовала в итерацию t0—t1, добавилась дополнительная дельта.

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

Кризис

Со временем от итерации к итерации задачи развития порождают все новые и новые задачи сопровождения. В какой-то момент такая динамика приводит к ситуации, которую я условно назвал «кризис».

Чем же характеризуется эта ситуация?

Начнем с нижнего графика.

С момента t0, когда появился первый клиент, шли итерации — одна за другой. Выделенная синим часть столбика — ресурс, который тратится на сопровождение. Эта область постоянно растет. И природа этого роста в том, что сделанное новое в предыдущей итерации увеличивает поток задач сопровождения в последующих. Если начертить линию по границе, разделяющей объем ресурса на задачи развития и сопровождения, то по большому счету получим некую функцию от времени f(t). И f (t) всё время будет стремиться ползти вверх.

И первое, что увидит менеджер, который ведет проект, — это то, что у него не хватает ресурса на адекватную скорость развития продукта (римская цифра II на графике). Он что-то обещал внешнему миру (своим руководителям или инвесторам). Например: «Мы к первому кварталу этого года запилим такой-то функционал». А потом понимает, что ресурса на развитие ему не хватает. Скорость роста в сравнении со скоростью в предыдущие периоды уже не та.

На самом деле скорость не та, потому что столбик сопровождения (выделенный синим) на графике всё сожрал. Остался только маленький белый столбик над выделенной областью, чтобы сделать новую фичу, сложность которой не меньше, чем было раньше.

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

Верхний график — график ожиданий. Руководитель и команда проекта чувствуют некую неэффективность: «Мы стали делать меньше. Что-то происходит не так...». Команда, которая была замотивирована на результат, начинает нервничать. Руководитель проекта, видя падение скорости, начинает оказывать давление на команду: «Что-то эти разработчики какие-то сытые стали, бегают плохо. Наверное, расслабились».

У руководителя проекта тоже карма падает — инвесторы (его начальство) ожидали линию, наклон которой как минимум не будет падать. Это ещё один удар по менеджеру, к нему появляются вопросы.

Ну, и третий, неприятный момент. На нижнем графике на вертикальной оси откладывалось значение объема ресурса команды. По сути — определенное количество человек, задействованное в работе над итерацией развития продукта. Горизонтальная линия, параллельная оси t, — это 100% команды. Нужно отметить, что состав команды неоднороден, там есть начинающие специалисты, есть середнячки и есть ведущие технические специалисты. Задачи развития продукта — это задачи, требующие в первую очередь компетенции сильных разработчиков и середнячков. Такие задачи, требующие приложения высокой квалификации, являются необходимой составляющей для их профессионального роста. Без них сениор- и мидл- разработчики будут постепенно выгорать, чувствуя отсутствие своего развития (римская цифра III на графике). Они начинают впадать в депрессию, ходить к руководителю проекта, говорить: «Слушай, мне стало неинтересно, я в другой проект хочу перейти». И это ещё один удар по менеджеру проекта.

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

Частая ответная реакция

Что чаще всего делает менеджер, попав в ситуацию описанного выше «кризиса»?

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

Руководитель проекта считает, что с ростом численности команды вырастет ресурс, который будет направляться на задачи развития. Динамика роста выровняется и проблема будет решена. Менеджер начинает набирать людей, но программисты за один день не ищутся. А после того, как они наняты, начинается этап их погружения в задачи. Толк от новичков появляется в лучшем случае через месяц-два после найма в зависимости от сложности проекта (цифра 2 на графике). А за это время задачи сопровождения успевают «сожрать» оставшийся свободный ресурс команды, и, когда новички «входят в строй», ситуация принципиально не меняется.

Зазор между объемом ресурса команды и объемом ресурса, требуемого на задачи сопровождения продукта, практически не меняется (цифра 1 на графике).

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

Что же делать?

1. Бдить

Первая мысль очень простая: руководитель проектов должен уметь определять границу распределения ресурса команды между задачами сопровождения и развития.

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

Когда понятна природа задач сопровождения, легче планировать дальнейшие действия.

2. Выстроить отношения

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

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

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

3. Не делать фигни

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

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

Оставляя неэффективные фичи в продукте, вы увеличиваете поле для задач сопровождения, которые будут «сжирать» ваш ограниченный ресурс, жизненное пространство команды продукта будет сужаться, потолок опускаться…

4. Рефакторинг

Если увидели, что источником многих задач сопровождения является какая-то архитектурная неоптимальность продукта, которая постоянно генерирует баги, то надо выделить время на рефакторинг. Цена такого шага отображена на графике в точке t0. Объем задач на сопровождение падает, и, возможно, дальнейший график роста объема таких задач выполаживается.

Кстати, такой подход анализа дает один из способов оценивать эффективность рефакторинга. Если у вас есть 10 идей рефакторинга, выберите ту, которая больше всего «уронит» график в точке tрефакт.

5. Усиление

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

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

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

6. Выносить задачи сопровождения за пределы основной команды разработки

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

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

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

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

Вместо заключения

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

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