Прозрачность — панацея от баттхёртов

Я уже пытался лечить «механический» scrum (часть 1 ^[1], часть 2 ^[2], часть 3 ^[3]), а в этой статье постараюсь выписать универсальное лекарство от «подгорания». Само по себе «подгорание», «бурление» и т.п. — это хорошо, это значит вам не все равно (а ведь безразличие — это шаг к унынию, или, как принято в IT — к выгоранию). На тему вреда выгорания написано и снято много материалов, например: вот ^[4], вот ^[5], вот ^[6] или вот ^[7].

Одна распространенная мудрость гласит: «Баттхёрты — двигатель прогресса». Но часто бывает так: пригорело => быстро принимается поверхностное решение, маскирующее проблему => решение воплощается в жизнь => пригорать продолжает. Другими словами, вместо того, чтобы разобраться и поставить диагноз, мы сразу приступаем к лечению. Попытаюсь это проиллюстрировать примерами.


Сперва определимся с термином «прозрачность». Scrum guide ^[8] определяет её так:

Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.

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

Эти определения относятся только к процессу, мне хочется рассмотреть понятие шире. Давать точные научные определения я не возьмусь, но попробую описать «прозрачность» через условия необходимые для её существования. Итак, для прозрачности необходимы:

• Объект, который кому-то нужен ^[9];
• Общая для всех заинтересованных сторон цель, относящаяся к объекту;
• Желание всех заинтересованных сторон достигнуть цели;
• Способность всех общаться на одном языке, т.е. возможность выработать такой понятийный аппарат, который будет содержательным для всех заинтересованных сторон (например, такие термины, как ROI ^[10] и Redux ^[11], похоже что лежат в разных и далеких друг от друга плоскостях, хотя очень ёмкие в конкретных информационных средах).

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

В первую очередь, отвечаем на главные вопросы:

• Для чего собрались?
• Какая цель?

Дальше возможна такая последовательность действий:

• Определяемся с терминологией (например, готовую ^[12] задачу все понимают одинаково, а не так, что для разработки — это, когда код написан, а для бизнеса — это когда клиент начал пользоваться результатами);
• Договариваемся о ключевых аспектах и о том, как мы будем измерять их состояние, как будем воспринимать результаты (например, собираемся раз в день, смотрим на план, определяем наше состояние относительно этого плана);
• Воплощаем задуманное.

Отдельно хочется подчеркнуть, что важна согласованность и общее принятие договоренностей, без этого сложно добиться вовлеченности. Ведь в директивных системах (например, в армии) понятийная база едина, действия и критерии оценивания понятны, но насколько это принято (есть ли эмпатия ^[13]) участниками — большой вопрос.

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

Тварь я дрожащая или право имею?

В последнее время, как мне кажется, очень остро стоит вопрос профессионального выгорания в IT среде (Целые тематические митапы проходят на эту тему, например, PiterJS ^[14], где был доклад ^[15] моего коллеги Жени Кота bunopus ^[16]).

Труд наш интеллектуальный, склад ума аналитический, ну вы и сами в курсе. Как мне кажется, есть склонность придумывать сложности там, где их нет. Иногда это происходит именно от отсутствия прозрачности (вот пара результатов исследований: один ^[17] и два ^[18]), а не из-за большого объема работы: нужной информации нет — придумаю её сам (помним же про аналитический склад ума), из предположения сделаю выводы — составлю план и пойду воевать с воздушными замками. Вот вопросы которые могут нас (ITшников) волновать:

• А не ерунду ли я делаю? Как моя работа улучшает мир?
• Насколько я хорош в своем деле?
• Да они знают, кто я? Да кто они такие? Да что они себе позволяют?
• Что дальше? Куда я иду? С теми ли я иду?

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

• Цели, миссия и стратегия компании открыты и понятны для работников, и они на слуху. Все тактические задачи преподаются через связь со стратегией, всегда понятно, для какой текущей цели требуется та или иная работа. Понятно не только, что нужно делать, но и зачем это нужно делать.
• Работники регулярно получают обратную связь по поводу результатов своей работы: достижения, точки роста (например, опросы 360 ^[19] или 1 to 1 ^[20]). Совместное планирование развития и инспекция динамики достижения этого плана.
• Описанная оргструктура и коммуникации внутри нее: о чем и с кем можно пообщаться. Социальные контракты, визитные карточки команд и т.п.
• Прозрачная система мотивации, дерево карьерного роста и, возможно, геймификация этого процесса. Можно вдохновляться примерами ЛитРес ^[21] или 2ГИС ^[22], и строить свою культуру, в которой работникам понятно, как определять и влиять на свой уровень материальной мотивации.

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

Крестовые походы

Мы вайтишники любим ломать копья на священных войнах: React vs Angular ^[23], iOS vs Android, ООП vs функциональщина и т.д. Но к сожалению или к счастью, нет «серебряной пули». Есть конкретная задача и пути решения. Когда мы стоим перед выбором технологии, фреймворка, архитектуры и т.п., с большой долей вероятности мы находимся в «запутанном» домене, согласно модели Кеневин ^[24], а, как следствие, тут нет правильно ответа. В этой ситуации желательно осознать и зафиксировать решаемую задачу, понять, какие альтернативы мы рассматриваем, какие критерии есть у нас для принятия решений. Нужно собрать эти данные вместе, сделать выбор и тоже его документально зафиксировать. По прошествии времени стоит возвращаться к этим артефактам и сверятся с тем, куда мы движемся. Все изменчиво: мир, компания, команда, конкретные люди, условия и т.д., поэтому, когда у нас есть информация о том, какие направления и почему мы выбирали, то можно легче скорректировать путь на основе этих знаний. А не попадать в классическую ситуацию с разрыванием тельняшки на груди ^[25]: «Да кто вообще это все придумал?! Похоже люди были профнепригодны, раз такое нагородили. Вот он правильный ответ, он очевиден. Я сейчас всех спасу и всё переделаю».

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

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

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

Внедрение agile / scrum / kanban / lean в сжатые ср*ки

Есть в Agile-среде извечный спор: «С чего начинать трансформацию: с культуры / ценностей / майндсета или механик / ритуалов / артефактов?». Такая классическая дилемма курицы и яйца. Моя позиция в том, что у «сильного и независимого» agile-коуча может случиться так, что команда через механики постепенно придет к осознанности. Но чаще, если начинать с механики и внедрять какой-нибудь подход как карго-культ, то скорее всего мы получим скепсис и разочарование в методике, а в худшем варианте еще и наживем хейтеров. Как это может получиться, отлично описано в Scream Guide ^[26] (тут огненный перевод ^[27]).

Поэтому я за то, чтобы анализировать, насколько Agile-ценности заходят в вашем случае, а уже потом приступать к применению фреймворка или методики. Универсального теста нет, но есть лакмусовые бумажки (например: тест на agile ^[28] и гид по agile ^[29]): сперва подумайте, поможет конкретно в вашем случае условный scrum или нет (еще пример тест-таблицы ^[30]).

Рассмотрим пример: у бизнеса подгорает от того, что разработка идет медленно, принимается решение — давайте внедрим scrum / kanban / lean, ведь это ускоряет разработку (чтобы это не значило). А по прошествии времени делаем выводы: «это шарлатанство и маркетинговые уловки, это не работает». Знакомая история? Мое мнение, что начинать стоит с прозрачности. Давайте поймем, что именно беспокоит. Давайте начнем говорить в одних терминах и термины понимать одинаково. Давайте сформулируем вопросы: «В чем проблема?», «Как мы понимаем, что это плохо?», «Как понять, что стало лучше?», «Как мы определим, что стало хорошо?», «Все ли осознали проблему и воспринимают её как проблему (а например не прихоть бестолковых менеджеров)?». И когда всё стало прозрачным, то в этот момент можно искать решения. Ведь «медленная разработка» может означать:

• Нет нормального процесса деплоя, развертывание изменений на прод — это боль. Варианты решения — внедряйте DevOps ^[31] культуру, запускайте CI / CD ^[32];
• Бизнес и разработка не научились разговаривать. Бизнесу кажется, что разработка ничего не понимает, а разработка, наоборот, считает, что бизнес не знает, чего хочет. Варианты решения — попробуйте выстраивать целеполагание, стройте Impact Mapping ^[33] или используйте OKR ^[34];
• Иерархическая структура наполненная микроменеджментом, в которой происходит медленное принятие тактических решений из-за необходимости согласований у вышестоящих. Варианты решения — обучайте людей фасилитации, проводите эксперименты с доверием ^[35] (посмотрите мотивирующий ролик с TED ^[36]);
• Список можно продолжать.

Ситуаций может быть много, для каждой из них, есть свои инструменты улучшений. И зачастую внедрение agile / scrum / kanban / lean / etc. похоже на забивание гвоздей микроскопом и, по сути, создание видимости бурной деятельности, но не на поиск решения проблемы. Поэтому здесь работает правило «не сотвори себе кумира»: не стоит искать серебряную пулю в хайповых подходах / методологиях / фреймворках, сперва просто осознайте какую задачу решаете, а инструмент решения выбирайте уже после этого. И окажется, что, встав на путь непрерывных улучшений (осознание проблемы, формализация работы с ней, наведение прозрачности, поиск решений через эксперименты), вы выстроите свой процесс не похожий ни на что, зато отлично работающий именно у вас.

К чему я это всё

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

Если вы дочитали до этого места и у вас бомбануло от очередной популистко-капитанской статьи, то можно попробовать задать себе на вопросы:

• Отчего подгорело?
• А почему это взбесило меня?
• Что могло бы быть по другому, чтобы не вызвало у меня таких эмоций?

Напишите все это в комментариях: расставим все точки над i и сделаем этот вопрос прозрачным.
Резюмируя: непрозрачность может приводить к распаду общества на группы, священным войнам, манифестам ^[37] и т.д. А ведь можно сесть и для начала попробовать говорить на одном языке и слышать друг друга. Всем прозрачности!

За иллюстрации спасибо, Сай Kin ^[38]!

Автор: Dmitry Podkorytov

Источник ^[39]