Одна из насущных проблем в командах, разрабатывающих программные продукты, — борьба за эффективность. Обсуждая эту проблему, часто говорят: «хотим повысить эффективность наших команд» или «ожидаем эффективности от коллег и партнеров». Однако в большинстве случаев разговоры об эффективности — это только желание максимально ускорить поставку готового продукта. Но действительно ли скорость — именно то, что нужно бизнесу в данный момент? Да и могут ли agile-подходы обеспечить требуемую скорость?
«Где-то на полпути гибких методик в Россию появилось мнение, что agile — это про скорость. Но это совсем не так», — считает Павел Капусткин, руководитель проектов компании HeadHunter. Свыше 20 лет он управляет командами разработки и с 2007 года применяет agile-подходы в организации работы различных компаний, помогая разработчикам и заказчикам программного обеспечения достигать желаемых результатов.
В agile-команде разработчик постоянно задействован в различных видах активности, не связанной с написанием кода. Agile облагает его множеством «налогов» в виде встреч, ревизий кода, инженерной и коммуникативной деятельности.
«Agile нужен не для того, чтобы писать код быстрее, а чтобы делать больше полезного. Делать в целом меньше, но лучше», — говорит Капусткин.
Стремление сделать побыстрее зачастую заводит команду в тупик. Продуктовая команда эффективна ровно настолько, насколько она в состоянии поставлять бизнес-ценности. И тут очень важен баланс между показателями «достаточно хорошо, чтобы пользоваться» (good enough) и «время вывода на рынок» (time to market). Эти два параметра имеют смысл только в связке друг с другом, то есть разработчики должны сделать софт в максимально сжатые сроки, не потеряв по дороге общий смысл. «Если мы выдаем по три функции в неделю, c вероятностью 90% ни одна из них не несет реальной ценности», — уверен Капусткин.
Продуктовая команда — это не просто люди, которые пишут, верстают и тестируют код, это совокупность экспертизы, иногда неожиданно глубокой, и использовать ее только для написания программного кода не очень разумно, полагает он. С помощью этой коллективной экспертизы можно продуцировать значительно больше ценности для бизнеса, обогащая продукт. Через культивирование в командах осознанности и продуктовых компетенций можно существенно повысить вовлеченность сотрудников и, как следствие, эффективность.
Каким образом повысить эффективность разработки путем изменения уровня осознанности в команде, Капусткин расскажет на конференции «Agile, DevOps, ITSM — инструменты и опыт реальных проектов цифровой трансформации», которую издательство «Открытые системы» проведет 23 октября 2018 года. Год за годом Капусткин дотошно протоколирует свою работу с командами и систематизирует свои наблюдения. В результате на свет появилась четырехуровневая модель, с которой познакомятся участники конференции.
Четыре шага к эффективности
Каждая agile-команда проходит через четыре этапа развития осознанности, каждый этап характеризуется совершенно разными целями, компетенциями, мотивацией и степенью вовлеченности сотрудников. Причем уровни осознанности слабо коррелируют, а иногда и вовсе не связаны с технической экспертизой команды. Имея примерно одинаковые исходные характеристики, команды, находящиеся на разных этапах развития, показывают совершенно разную эффективность, и уровень их технической подготовки играет второстепенную роль.
Под осознанностью понимается степень адекватности восприятия человеком или группой своего места в системе координат компании и продукта, своей роли и влияния, правильности понимания целей и задач команды, а также корреляции личных целей с целями команды и компании в целом. Самый верхний уровень подразумевает полное понимание и принятие целей компании и полноценное участие команды в трансформации всей компании в целом.
Как понять, на каком этапе команда находится сейчас? Чего от нее можно ожидать, а чего — не стоит? В чем ей можно и нужно помочь на этом пути, а в чем лучше не мешать? Об этом участники конференции узнают из доклада Капусткина «Эффективная разработка без магии и ГМО». От участников конференции докладчик, в свою очередь, рассчитывает получить обратную связь в виде вопросов и критики, которые позволят ему дальше развивать свой подход.
Диапазон применимости
Даже те компании, где давно практикуют гибкие подходы, сильно различаются по организационной структуре и культуре, уровню зрелости менеджмента, пониманию agile и возможностей его использования в бизнесе, а также по уровню имплементации.
«В большинстве организаций agile начинается на уровне команд разработки и там же заканчивается», — говорит Капусткин. Уже на уровне департаментов царит классический менеджмент с его бюджетами, планированием, диаграммами Ганта и совершенно негибкой структурой.
На верхнем уровне управления эффективность оценивают, как правило, по выполнению финансовых показателей. Но где-то умеют сопоставлять результаты работы продуктовых команд с финансовыми показателями, а где-то царит метод «палец-пол-потолок». Cистемный подход и подход «цели и ключевые результаты» (objectives & key results, OKR) в качестве альтернативы классическим KPI на практике встречается нечасто.
В редких случаях agile-практики получается применить на стратегическом уровне. Но при любом организационном ландшафте на уровне команд разработки можно договориться о подходах к оценке эффективности.
Спектр способов, использующихся для оценки эффективности разработки, может быть широк даже в границах одной компании. Там, где есть множество команд разработки с разными задачами, могут сосуществовать три-четыре подхода к оценке их эффективности.
Максимально эффективно подход, нацеленный на повышение осознанности, работает при создании не слишком больших продуктов, которые делаются двумя, максимум тремя командами. Чем больше число команд, тем сложнее перенести на них данную модель, поскольку добиться понимания продукта у ста человек и зажечь их одной целью гораздо сложнее, чем у двух десятков.
Кроме того, для cервисных команд и заказной разработки фокусы могут различаться достаточно сильно. В обслуживании внутренних заказчиков важны концентрация на SLA и качестве сервиса, умение быстро прорабатывать мелкие задачи и улучшать систему, избегая при этом революционных изменений.
