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

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

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

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

Большая ловушка

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

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

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

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

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

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

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

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

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

Разве Agile не говорит, что у вас не может быть фиксированного объема?

Это что-то вроде городской легенды о том, что в Agile-среде у вас не может быть фиксированного прицела. У вас даже может быть фиксированный срок. Но в этой ситуации следует признать, что либо стоимость (хотя это сопряжено с рядом рисков), либо качество должны оставаться гибкими, причем последнее всегда является крайней мерой.

Однако самое главное - быть готовым к изменениям. Почти всегда на протяжении всего проекта придумывается новая замечательная функция или функция больше не требуется. Было бы очень обидно не ответить на это.

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

«Но ведь ресторан быстрого питания с гамбургерами - это простая среда?» Да, это правда, но когда они только начинали, это было сложно, и им приходилось продолжать экспериментировать, чтобы найти решение, которое сработает. Все эксперименты, которые они проводили, помогли упростить среду, поэтому теперь она выглядит очень простой и дает стабильные результаты.

Заключение

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

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

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

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

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

Автор: Сэмюэл Кэтт, мастер Scrum в Crunch. В свободное время Сэмюэл активно занимается английским пулом, принимает участие в ряде соревнований.

Узнайте больше о технологической команде Crunch и наших текущих возможностях здесь.

📝 Прочтите этот рассказ позже в Журнале.

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