Ваши процессы попахивают. Как это понять и что делать?

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

Сначала чуть-чуть истории. В 1999 году Мартин Фаулер выпустил знаменитую книжку, в которой, кроме всего прочего, описал принадлежащее Кенту Беку понятие сode smell.

«A code smell is any characteristic in the source code of a program that possibly indicates a deeper problem. They indicate weaknesses in design that may slow down development or increase the risk of bugs or failures in the future» © Kent Beck, Martin Fowler

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

В процессе разработки

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

Нерадивые сотрудники

Например, вам кажется, что у вас нерадивые сотрудники — они не пишут комментарии, мерджат прямо в мастер, всегда опаздывают на 2-3 минуты, скучают на ретро, и, вообще, на собеседования приходят сплошные «не те». 

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

Нерадивый сотрудник может быть проблемой в сотруднике или в процессе онбординга, но это почти всегда «запах» какой-то проблемы, bad smell.

Формальные отношения

Кто из вас сталкивался с такой реакцией своих коллег?

• Не буду выполнять задачу, пока аналитик не заполнит все данные по шаблону;

• Не буду поднимать прод, пока не заполнят тикет в Jira по всем правилам;

• Пока не опишите все события в ваших логах, мы не примем ваш сервис в эксплуатацию.

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

Наличие формального отношения к работе — это признак потенциальных проблем в процессе (сейчас или в будущем), еще один bad smell.

Лишний труд

Бывает, что совещания занимают больше одного часа разработчика каждый день, а планирование спринта «съедает» один рабочий день команды. Вроде бы все хорошо, работа идет, но на задачи, не связанные с разработкой, уходит больше десяти процентов времени. Пожирающих время практик очень много — это и code review, и заполнение отчетов по работе, и всевозможные совещания, обсуждения, согласования, ожидания.

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

Сплошная дребедень

«…То тюлень позвонит, то олень». Десяток разных задач на разработчика в неделю, по три проекта на одном сотруднике, приоритеты меняются четыре раза в неделю, люди жалуются, что не могут сесть и спокойно подумать — это тоже прекрасный признак проблемы в процессах. Думать полезно, не думать — очень опасно для работы, multitasking приводит к потерям (про это можно почитать или послушать у, например, Алексея Пименова).

Т.е. суета, многозадачность, многопроектность – это тоже bad smell, тоже возможный признак проблем в процессах.

 «Я в домике»

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

Все это еще один набор симптомов не очень удачных процессов. Задачи вроде бы выполняются, всё нормально работает, но все участники процесса не хотят общаться друг с другом, хотят сидеть в своем «домике». 

Сложнее всего заметить симптомы «я в домике» в том случае, когда именно с вами (или вашей командой) не хотят общаться. Когда у вас проблемы с коммуникациями — вы никогда о них не узнаете, так как никто не хочет с вами общаться, почти что «уловка 22».

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

Идеальный мир

У вас нет никаких проблем в процессах? Я видел несколько компаний, которые были уверены, что у них всё идеально в процессах. И это были самые ужасные процессы, которые я видел в своей жизни. 

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

Причины

Ну вот, некоторые симптомы мы описали. Но какие болезни могут скрываться за этим симптомам, какие причины обычно приводят к bad smell, почему же процессы начинают «попахивать»?

Ритуалы

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

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

Ложь

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

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

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

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

Коммуникации

Большая часть проблем в процессах связана с проблемами в коммуникациях. В общении людей очень много моментов, где можно сделать плохо. Можно использовать разные языки (например, программистский и менеджерский), и не отследить, что фраза «Я сделаю задачу за неделю» в этих языках значит совершенно разные вещи. Для программиста она означает «я точно не сделаю раньше, чем через неделю», а для менеджера —  «через неделю задача будет на проде протестирована и задокументирована». И это еще простой, много раз описанный и понятный пример проблем в коммуникациях.

У людей разные личные цели, у разных команд разный OKR или KPI — и эта разница тоже мешает коммуникации, так как всем выгодно по-разному трактовать одни и те же слова. Бороться с этим сложно, но учитывать — необходимо.

Неудобство

Иногда дело не в коммуникациях и не в ритуалах. Попахивающая практика может быть просто неудобна. Если для получения нового тестового стенда нужна заявка в Jira на 25 полях вместе с парой страниц мотивации (это реальный пример) — то никто не будет заказывать тестовые стенды без крайней необходимости.

В свое время я делал доклад о том, как внедрять новые методологии и процессы, говоря, что не надо сразу покрывать тропинки бетоном — посмотрите сначала, как люди реально ходят, а потом уже делайте это удобным. Увы, так делают крайне редко, чаще есть какой-то сверху спущенный процесс — и программисту, QA-менеджеру или любому другому сотруднику просто неудобно по нему идти. А если человеку неудобно — то он этого просто не делает.

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

В процессе внедрения

Увы, многие практики начинают пахнуть еще на этапе внедрения, задолго до того, как ими начали пользоваться. Посмотрим, а какие «ароматы» чаще всего встречаются на этом этапе:

Очевидность

Один из законов Мерфи гласит:

«Любая сложная задача имеет простое, легкое для понимания, (описанное на Хабре), неправильное решение» © Артур Блох

Разумеется, при изменении процессов сложно не попасться в ловушку очевидности:

• Упала производительность на удаленке? — Давайте загоним всех в офис. 

• Ненадежные релизы? — Давайте запретим выкладываться в пятницу. 

• Сотрудники без предупреждения уходят в другие конторы? — Давайте будем каждую неделю делать OneToOne по чек-листу.

• Не доверяем командам? — Давайте введем грейды и матрицу компетенций.

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

Безальтернативность

Прежде чем внедрять какую-то практику — оценивали ли другие варианты, оценивали возможные последствия? Например, много ли вы знаете компаний, где при внедрении SCRUM рассматривались хоть какие-то альтернативы?

Так делает Google

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

Если в Google используется сложная многостадийная система набора сотрудников — давайте сделаем себе такую же в нашей никому не известной компании из 20 человек. Google внедряет методологию SRE? Давайте для нашего небольшого интернет-магазинчика тоже создадим команду SRE. Ну и назначим в нее нашего несчастного сисадмина, всё равно больше никого нет.

Если вы — не Google, то 90% практик Google к вам не имеет никакого отношения, так как решают те проблемы, которых у вас просто нет. Более того, даже если компания успешна на рынке и зарабатывает много денег, совершенно не значит, что внутри у этой компании всё хорошо. В реальности коммерческий успех и качество практик и процессов могут быть не связаны никак. У множества успешных компаний на высококонкурентном рынке весьма ужасные или очень специфические процессы, которые вам не подойдут. 

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

Так сказал Kent Beck

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

Я очень надеюсь, что никто и никогда не будет ссылаться на мои доклады в стиле: «Так сказал Фил, поэтому давайте делать именно так». Я не просто так стараюсь избегать конкретных советов или решений и больше задавать вопросы, нежели отвечать на них. Вера в авторитеты — одно из худших когнитивных искажений, потому что позволяет не думать.

Я так сказал!

Еще один «прекрасный» вариант внедрения процесса — по приказу сверху. Пришел CTO и сказал: «Давайте внедрять SCRUM!» (или SRE, или 360, или что-нибудь еще). Альтернативы не предполагаются, вопросы не поощряются!

Намного эффективнее менять процессы аккуратно, с коммуникацией  между тем, кто внедряет, инициирует практику, и тем, кто в ней участвует. 

Причины

Некоторые причины «неудачных» запахов в процессе внедрения  — те же, что и в процессе разработки:

• Ритуалы;

• Ложь;

• Коммуникации;

• Неудобство.

Но стоит добавить и еще пару причин плохого запаха.

Карго-культ

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

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

Временами мне кажется, что карго-культ — это вообще основная проблема индустрии. Не надо так!

Культура

Питер Друкер как-то говорил, что «культура ест стратегию на завтрак». У любой практики есть некоторое (обычно не рефлексируемое) представление о том, какая культура компании нужна, чтобы ее внедрять. 

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

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

Примеры

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

Напомню, что у каждой технологии и практики всегда есть хорошие и плохие стороны. Не бывает плохих и хороших практик — все удачны для какого-то конкретного контекста. И приводя в пример «обычно попахивающие» практики я ни в коем случае не имею в виду, что проблема  именно с ними. Увы, проблема в их популярных методах использования. Станислав Лем писал когда-то: 

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

Code review with Pull Requests

Как и многие другие популярные практики, тотальный code review появился в очень специфических условиях — разработка open source с неизвестными коммитерами без выстроенных процессов тестирования и так далее. И принцип «при достаточном количестве глаз все ошибки будут найдены» формулировался Эриком Реймондом именно для этой ситуации.

Далеко не многие из нас разрабатывают классический open source. Поэтому использование практики в совсем другом контексте почти всегда «попахивает» — возникающими сложностями в коммуникациях, трудозатратами, задержками. Очень редко code review внедряется после анализа альтернатив и понимания реальной необходимости.

Про возможные подходы к peer review я рассказывал на Подлодке.

Системные аналитики

У кого именно от системных аналитиков приходит, например, описание API и модели данных? А у кого описание пользовательских экранов делают системные аналитики? А у кого не появляется желание потом переделать потом то, что пришло от системных аналитиков?

По моему опыту, сами системные аналитики — прекрасные люди. Но от сотрудника в этой роли ждут умения и хорошо разбираться в предметной области, и в технологических процессах, и во внутренностях реализации кода, да и вообще уметь писать код — фактически системные аналитики пишут код, только в Word. При этом всё это за зарплату middle девелопера. Логично, что всё вместе получается не очень успешно. 

Но это проблема не системных аналитиков. Проблема в добавлении еще одного слоя коммуникаций в достаточно сложной систему. Это еще один барьер между теми, кто ставит задачи, и теми, кто их реализует. Поэтому эта прослойка «попахивает». Бывают ситуации, когда эту практику реально необходимо внедрять, она реально полезна. Но реальных кейсов я практически никогда не видел.

Scrum

Это самая часто «попахивающая» практика, потому что я ни разу не видел, чтобы ее внедряли без почти всех описанных выше ароматов. Я не говорю, что она плохая — это прекрасная практика, Последние редакции SCRUM guide вообще прекрасны, по ним можно делать все, что угодно. Но внедряют SCRUM именно так, как внедряют.

А что делать?

ОК, мы посмотрели кучу разных проблем. Теперь поговорим, а что с этим всем можно делать и как можно избавляться от запахов. Я ни в коем случае не буду давать рекомендации «делайте так». Но расскажу про несколько методов, которые иногда помогают мне или моим знакомым и которые, как мне кажется, стоит изучить.

ТРИЗ

Теория Решения Изобретательских Задач — методика для решения инженерных задач, созданная в 40-х годах Генрихом Сауловичем Альтшуллером. ТРИЗ я очень советую изучить. Вся методика довольно сложна, но понятия «идеальной системы» и методы «разрешения противоречий» легко применимы к задачам управления.

Для быстрого изучения ТРИЗ я советую детскую книжку «Месяц под звездами фантазии» Б. Л. Злотина и А. В. Зусмана. Она читается за один вечер, и в ней описаны все основные приемы, нужные неинженеру.

Рациональный подход

Этот вроде бы научный метод (поставим проблему — измерим параметры — поймем, что поменять — измерим, что получилось) основывается на прекрасной цитате Питера Друкера: «Вы не можете управлять тем, что не можете измерить». Есть одно маленькое «но» — Друкер никогда этого не говорил, а говорил ровно противоположное.

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

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

STATIK

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

Помощь клуба

Есть замечательный телеграмм-чат конференции Team Lead Conf под названием «Боль тимлида». В нем много людей, которые могут ответить на разнообразные вопросы — Сорока, Шароватов, Фабриченко, Пименов, Ивлиев и многие другие.

Но есть проблема. Не стоит ждать прямого и простого ответа на заданные вопросы. На самом деле главная польза от этого чатика — не конкретные ответы, а конструктивная токсичность участников чата. Будьте готовы к тому, что вас начнут спрашивать: «А зачем вам это надо?», «А какие проблемы вы пытаетесь решить?» и «Какие первые три страницы в Google вы прочли перед тем, как задавать нам эти глупые вопросы?»

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

Философия

Ну и напоследок самый сложный совет. За последние несколько тысяч лет в философии, как ни странно, появилось довольно много интересных и эффективных методов, которые нам тоже могут пригодиться:

Метод радикального сомнения Декарта. По-хорошему, это вообще основной инструмент тимлида — мы всегда должны сомневаться в происходящем: не «пахнут» ли наши практики, удачны ли они, правду ли нам говорят на конференциях? Неплохо почитать и оригинал.

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

Гегель, Энгельс, Платон, Витгенштейн, Богданов, … Из Гегеля родился ТРИЗ, из Платона — объектно-ориентированный анализ, функциональный анализ и вообще вся наша деятельность. Витгенштейн рассказывает, как можно четко и ясно думать, и как можно потом отказываться от своих четких и ясных мыслей. Богданов создал общую теорию систем еще до Берталанфи.

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

Итого

Итак, у нас получился довольно простой подход к улучшению процессов:

• Почувствовать «запашок» проблемы;

• Прояснить цель;

• Понять проблему и необходимость ее решения;

• Придумать решение;

• Построить идеальный слегка улучшенный процесс.

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

Закончить хочу моей любимой цитатой:

«Цель войны (а также процессов, разработки и т.д.) – мир, лучший чем довоенный. Хотя бы с вашей точки зрения» © сэр Бэзил Лиддел Гарт

Видео моего выступления на TeamLead Conf 2021:

Конференция TeamLead Conf 2022 пройдет 21 и 22 марта совместно с KnowledgeConf. Доклады по Knowledge будут отдельным треком. Расписание уже готово, а купить билет можно здесь.