Культ Карго

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

Культ карго или карго-культ (англ. cargo cult — поклонение грузу), также религия самолётопоклонников или культ Даров небесных — термин, которым называют группу религиозных движений в Меланезии. В культах карго верят, что западные товары (карго, англ. груз) созданы духами предков и предназначены для меланезийского народа. Считается, что белые люди нечестным путём получили контроль над этими предметами. В культах карго проводятся ритуалы, похожие на действия белых людей, чтобы этих предметов стало больше. Культ карго является проявлением «магического мышления».

Можно с легкостью это переложить на сферу ИТ, когда команды просто повторяют разные внешние проявления той или иной практики не задумываясь, что должно являться результатом. Что-то резко вспомнились огромные фанерные «антикрылья» на копейках и 4 трубы – это тоже яркий пример культа карго.

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

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

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

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

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

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

Кстати, когда команда начинает вести записи встреч, то многие начинают словоблудить (словесный понос открывается), чтобы показать, что они что-то делали, а не пинали балду большую часть дня. Это кстати показатель. Но некоторые боятся, что их задача описывается всего одним предложением и начинают: В далекой-далекой галактике… – это тоже надо пресекать и проводить воспитательные беседы, что не стоит стеснятся того, что задача описывается одним предложением и занимает целый день. Еще тревожным знаком может быть, если люди тихо-тихо говорят о своих задачах, словно стесняются того, что сделали.

Пока что на этом этапе и остановились, но профит уже опять уходит. Ко всему прочему могут закрадываться мысли, мол если все и так записывается и рассылается, так может ну их эти встречи, может я так вышлю задачи скопипасченные из check-in comment и нормуль? Нет не нормуль. Потому что во время лично встречи можно тут же задать вопросы или что-то решить, получить дополнительную информацию. Лично общение поднимает градус доверия в команде так или иначе. Однако при собраниях надо именно слушать, а не физически присутствовать иначе ценность встреч начинает стремительно падать и превращаться из полезного инструмента в ритуал.

После того, как все научились более-менее связно, четко, громко и ясно выражать то, что они сделали за день, можно переходить к следующему этапу – ретроспективе. В пятницу, во второй половине дня можно собираться, разбирать задачи за неделю, и решать почему что-то долго делалось и что надо сделать, чтобы в следующий раз они решились быстрее. Были ли какие-то объективные сложности в решении задачи, или же просто звезды не сошлись и кофе закончилось. В таких беседах не стоит переходить на личности, обвинять в чем-то, чтобы не вызывать дискомфорта от встреч. Кстати, стоит на таких встречах выключать мобильники или сдавать в один пакет! На таких встречах может быть выработаны дальнейшие практики и развитие команды, могут обнажиться застарелые болячки команды, которые не видны при каждодневной работе (большое видно на расстоянии). Стенограмму таких встреч так же стоит вести и фиксировать основные решение, распечатывать их и в течении недели и более следить за их выполнением. Не следующей ретроспективе обсуждать, получилось ли решить задачи и проблемы обозначенные в прошлый раз, или что помешало выполнению. Должна быть максимальная открытость и, конечно же, желание решить проблемы.

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

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

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

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

 

Hard’n’Heavy!

2 комментарий на “Культ Карго

  1. Давно читаю ваш блог, много интересного, спасибо! Немного не согласен с применением карго к рассмотренным ситуациям, скорее это формальное отношение к делу. Карго подразумевает полное непонимание сути вопроса. А востальном много плюсуюсь. Описанные вами процедуры действительно очень эффективны для повышения эффективности команды. Другое дело что реализовавыть их обычно лень. Обычно все и так всех устраивает и какие то меры принимаются при явных выходах за допустимые рамки. Есди этого нет то можно и поволынить и поизобретать велосипед и т.д)

    • Спасибо за комментарий!
      Да, действительно я немного слукавил называя так статью. Но в статье я расписал переходы и в таком виде культа карго не возникает, на мой взгляд. Так как это постепенное внедрение и его четко надо контроллировать по времени.
      Однако чаще бывает формальный подход, и мне кажется, что со временем такой формализм, такой подход к делу приведет к утрате даже первоначальных полезных свойств.

      А лень вообще очень страшная штука =))

Оставить комментарий