Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
SCRUM в России, как и на территории всего бывшего СССР, стал самой популярной методологией разработки ПО не только среди любых «гибких» вариаций и даже среди всех итерационных производственных парадигм. И, действительно, с 2013 года научные исследования консультантов SSC последовательно показывают:
1. SCRUM наращивал свою востребованность и с 2017 года явно доминирует среди «гибких» методологий: часть из них (вроде XP) не вызывают энтузиазма в крупных организациях, часть из них (например, KANBAN) вообще не внедрены нигде, кроме как посреди субъективных ощущений отдельных генеральных директоров отдельных web-студий;
2. SCRUM к 2020 году стал основной методологией разработки для лучших российских софтверных вендоров, как для обеспечения критериев качества продукта, так и с точки зрения оптимизации продуктивности и загрузки команд.
При этом мы понимаем, что SCRUM очень адаптивен внутри каждого проекта, а многие команды используют элементы сразу из нескольких «гибких» методологий, условно называя все вместе - наш SCRUM.
Безусловно остаются целые области российской IT-отрасли, в которых инженеры ничего не знают про SCRUM, но будем честны: они ничего не знают и в целом о программной инженерии 20-х годов нашего века, а их программное обеспечение могло быть создано 20 и даже 30 лет назад: ведь это те же самые задачи автоматизации для самолетов, ракет и станков, которые и сами превосходно «помнят» 20-й век. Коммерческая разработка выбрала SCRUM-методологию и последовательно преодолевает разнообразные сложности этой парадигмы. Одна из регулярно возникающих задач – это необходимость снижать себестоимость команды в «тяжелые» для бизнес-заказчиков времена.
Вместе с этим, парадигма SCRUM-разработки ПО эволюционно развивается в высоком темпе: появляются новые методы и подходы к оптимизации трудозатрат в развитии продуктов, к росту продуктивности и вовлеченности инженеров, к повышению разнообразных качественных параметров программных продуктов (UX, LTV, time-to-market, т.д.). В данной заметке выделен лишь один подход в сокращению бюджетов проектных команд разработки ПО, а именно: оптимизация ролей в SCRUM-команде. Мотивы для такой оптимизации обычно противоположены:
1. количество сотрудников в проекте превышает обычные представления о SCRUM-команде в 7-9 человек (нужно раздать роли и\или сократить команду);
2. команда не укомплектована полностью: часть ролей необходимо совместить или вообще отказаться от них.
Проведение оптимизации ролей команд необходимо начинать с самого универсального. К счастью, эти общие рекомендации давно разработаны практиками IT-отрасли. Так, например, рекомендации консультантов SSC, основанные на солидном проектном опыте, могут быть сформулированы следующим образом:
scrum-мастер – это не самостоятельная роль, это текущий участник проектной команды, выполняющий ежедневную работу: найдите лидера, который совместит эту роль со своею;
тимлид, техлид, архитектор - только одна из данных ролей оплачивается бюджетом проекта на 100%. Нужно искать правильную роль или баланс их частичного участия;
внутренний аутсорс услуг DevOps-инженеров, вместо включения инженера в состав команды – это работающий, но рискованный способ оптимизации бюджета.
Прежде всего, забудьте эту книжку десятилетней давности Геоффа Ваттса про служение scrum-мастера своей команде, потому что мастер – это не проводник в мир «гибких» технологий, не хранитель знаний, ни даже менеджер, который запланирует спринт или проведет дейлик. Это статья в расходах вашего проекта, в редких случаях – ступенька в карьере хорошего инженера до «правильной и полезной» роли. Поэтому сразу определим: лидер одного из направлений в проекте – тимлид, ведущий аналитик, ведущий QA инженер и даже ПМ – могут быть scrum-мастер безо всяких сложностей. Поэтому определите scrum-мастера из числа текущих лидеров команды разработки таким образом, чтобы эта роль в проектной команде не несла дополнительных издержек для проекта.
Единственное исключение в практике консультантов SSC можно охарактеризовать следующим кейсом: в коллективе IT-предприятия (с 25+ лет опыта отрасли) более 80% инженеров не имеют никакого опыта работы в парадигме SCRUM, при этом медиана карьеры в отрасли разработки ПО превышает 13 лет. Сложные трансформационные процессы в таких случаях будут требовать серьезных усилий в области преодоления организационного сопротивления, что делает экономически возможным привлечение отдельно выделенных scrum-мастеров в проектах разработки. Во всех остальных случаях: scrum -мастер – это совмещенная роль, которая доверена одному из лидеров проекта или его руководителю.
Однако, бюджет проекта можно сократить еще сильнее, если это нужно. Например, тимлид, техлид и архитектор – это сколько FTE (целых человек) для среднего SCRUM проекта? Лучшие ПМ говорят, что это один и тот же лидер разработки ПО для команды до 10 человек в проектах длиною в 6-9 месяцев. Нам кажется правильным в усредненных случаях (SCRUM команда проекта до 10 человек) сократить эти три роли до одного-двух человек (1,5 FTE). Ключевая роль – тимлид, он аллоцирован на 100% и выполняет все типичные функции лида. Далее рассмотрим аллокацию архитектора: масштабы проекта (а не только бюджет) могут требовать привлечения solution- и даже enterprise-архитектора. Однако, в оцениваемом горизонте полугода его вовлечение вряд ли займет более 0,5 FTE. И наконец, техлид – это та роль, которой следует прежде всего пожертвовать в проекте, который испытывает бюджетные ограничения. Вместе с этим роль техлида чрезвычайна важна при масштабировании разработки, особенно при использовании проприетарных технологий и сложных интеграций между проектами. Для более масштабных по количеству инженеров методологий разработки ПО (Scrum of Scrum, SAF) техлиды обеспечивают необходимую технологическую поддержку слаженности разработки ПО несколькими командами и соответствие получаемого программного продукта всем нефункциональных требованиям.
И наконец, последний подход к оптимизации состава проектной команды в виду ограничений по бюджету – это изменение бюджетирования DevOps-инженеров (и похожих ролей, вроде сисадминов, инженеров сред, инженеров по автоматизации разработки ПО и т.п.). Выделение таких инженеров во внутренние службы, которые оказывают свои сервисы по внутренней цене компании, - это небыстрый, но эффективный вариант оптимизации бюджетов ваших проектов разработки. Конечно, каждому ПМ и тимлиду хотелось бы иметь выделенного инженера на среды, CI\CD и прочее, но более перспективным с точки зрения оптимизации затрат на проекты кажется комплексная автоматизация этих регулярных потребностей силами выделенных DevOps-служб внутри софтверной компании. Безусловно такая трансформация несет в себе определенные риски, связанные с оперативностью решения инфраструктурных проблем в проекте, кроме того, в некоторых компаниях снижается глубина погружения DevOps-инженеров в проблемы каждого проекта. Эти риски управляемы: с формальной точки зрения – это SLA и KPI в DevOps-сервисах, с неформальной – создание хороших рабочих отношений, закрепление инженеров за зонами ответственности (например, по технологическим стекам или проектам).
По нашему мнению, данные оптимизации сокращают расходуемый бюджет в среднем SCRUM проекте (до 3 FTE при удачном распределении усилий). Также это позволяют увеличить управляемость бюджетом проекта, перенаправив дополнительные средства на усиление необходимых позиций вместо тех, что уже сложились из-за устоявшихся привычек IT-компании. При этом модификация данных рекомендаций (как показывает проектных опыт SSC) позволяет добиться оптимизации бюджета и в более масштабных проектах, где методология разработки ПО (например, SAF) подразумевает одновременное слаженное участие десятков специалистов.
