Помимо церемоний и артефактов

Как мы создали высокоэффективную Agile-команду в Global Technology.

Хирен Патель, старший менеджер по управлению проектами

Вплоть до 2022 года команда специалистов по продуктам и инженерам ресторанного бизнеса Global Technology создавала информационные панели с использованием методологии водопада. Отчасти это произошло из-за того, что McDonald's отдал разработку на аутсорсинг, и может возникнуть соблазн заранее определить все детали масштаба и окончательных результатов в контракте.

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

В этом посте рассказывается о том, как производительность, а также восприятие нашей команды улучшились в 2022 году, когда команда изменила свой подход. Команда внедрила методологию Agile scrum, но это еще не все.

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

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

Сосредоточьтесь на продуктах, а не на проектах
Когда люди думают о проектах, они предполагают, что проекты имеют конечную цель. На самом деле, многие ведущие профессиональные организации по управлению проектами прямо определяют проект как имеющий конечную цель. На первый взгляд идея проектов кажется очень практичной в корпоративном мире. Контракты утверждаются быстрее, когда окончательные результаты и твердые сроки определяются заранее; планирование бюджета упрощается, когда объем и график уже фиксированы; и управлять ожиданиями вместе с руководством кажется легче, когда действуют тройные ограничения.

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

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

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

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

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

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

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

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

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

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

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

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