Как я в конкурсе идей участвовал.

Как-то раз в одной компании участвовал в довольно стандартном конкурсе идей, где можно накинуть любые свои фантазии на тему, что можно было бы сделать. Вопрос был поставлен так (примерно): "Представьте, что ресурсы не ограничены (в рамках реального), какие идеи вам хотелось бы реализовать в рамках своей команды/продукта? Можно написать до 3 вариантов."

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

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

"Идея номер раз - экспериментальный подход к разработке.

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

Особенности работы в этой команде:
1. Команда состоит из двух ролей - developer и UI/UX designer (или просто - разработчик и дизайнер).
2. Убираем роль QA
3. Убираем деление на frontend и backend
4. Убираем обязательное код-ревью как этап процесса
5. Убираем ручное релизное тестирование
6. Дизайнер формулирует и ставит задачи и он же их принимает
7. Разработчик выполняет весь цикл создания - фуллстек разработка, тестирование, автотесты, стабильность системы
8. Каждый является сам себе лидом и управляет своей работой
9. Если это распределенная команда - в ней организованы "голосовые комнаты" и в прайм-тайм работа ведется в них
10. Применяем практики покрытия метриками, мониторингом и алертами всех фичей по умолчанию, делаем статус системы полностью прозрачным
И так далее.

Второй шаг - по мере работы формируем фреймворк под такой стиль разработки ("one-step-development"). Заявляем минимум утроение эффективности работы + сокращение lead time до 1-2 дней при таком подходе и проверяем эту гипотезу.

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

Четвертый шаг - к нам со всего мира идут топовые ребята, которые хотят так работать.

Пятый шаг - становимся евангелистами нового движения, методологии и фреймворка.

Профит:
- топовый HR-бренд (привлекаем в команду лучших сотрудников, меньше затраты на поиск и найм)
- сильный технический бренд (привлекаем больше клиентов)
- эффективность и гибкость разработки (сильно сокращаем time-to-market, особенно на этапе подготовки требований и приемки)"

Несколько пояснений по тексту:

- Под премией 100% подразумевается х2 оклад
- Роль дизайнера в этой схеме включает в себя еще как минимум бизнес-анализ
- Под "lead time до 1-2 дней" имеется в виду время поставки самой мелкой фичи по стандартному процессу, типа "задача на полчаса". При обычной работе через весь цикл разработки это примерно 1-2 недели.
- "Голосовые комнаты" и работа в них - это когда вы сидите в войс чате (набор комнат под команды и проектные группы) в прайм тайм (основное рабочее время, обычно 4-6 часов), и переходите в канал afk если вы не на месте. Это не значит, что все нон-стопом разговаривают о чем-то, это просто возможность в реальном времени обратиться как в офисе с вопросом и сделать командное взаимодействие плотным, без асинхронных задержек.
- DevRel - developer relations

Пока что не выпала возможность реализовать (в современных реалиях это довольно радикально), но я процентов на 90 уверен в успехе, так как по отдельности почти все элементы уже опробованы. Осталось только выпасть случаю.

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

Специализация vs. интеграция.

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

Первый из таких принципов - в knowledge based (основанной на знаниях) работе чем меньше ролей нужно для выполнения задачи, тем работа эффективнее.

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

Тем временем, потихоньку эта тема проникает в мейнстрим, и толчком к этому стало развитие ИИ.

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

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

Людей, совмещающих в своем мозгу весь производственный цикл разработки ПО - практически нет. А те, кто есть - вероятнее всего не в найме. Крупные структуры до сих пор во многих местах традиционно строятся на изоляции функций, например: продакт-менеджер (идея), продуктовый аналитик (данные для идеи), бизнес-аналитик (структурирование идеи), системный аналитик (связь бизнес-постановки и системы), архитектор (верхний уровень технического дизайна), тимлид (нижний уровень технического дизайна), разработчик (написание кода руками), тестировщик (проверка задачи и реализации), автотестер, девопс, и потом несколько видов саппорта, все выполняют свои изолированные друг от друга роли в рамках сложных контрактов (систем правил), которые неизбежно не покрывают все зоны ответственности, и это сверху замазывается толстым слоем менеджмента, который выискивает нон-стопом эти дыры и сводит концы с концами.

продолжение ниже

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

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

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

Остальные роли, в том числе менеджер, являются вынужденной фрагментацией этих двух.

"Это не то, что я имел в виду!"... или коммуникационные издержки.

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

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

В конечном итоге в менеджменте самый низкий на данный момент достижимый уровень (на мой взгляд) это биология поведения.

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

- Для кооперативного выполнения работы нужно делиться информацией.
- При передаче информации происходят потери.
- Чем больше таких передач происходит, тем больше потери.
- Также влияет качество передачи и качество приема (они всегда не идеальные, но они могут сократить потери).

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

Соответственно, следуя простой логике, с этим можно сделать 3 вещи:
1. Сократить количество передач информации
2. Увеличить качество передачи
3. Увеличить качество приема

Вот это уже конкретная работа для менеджера.

Пример первого - это как раз уменьшение количества ролей до минимально возможного, пока позволяет квалификация (и мотивация) участников.

Один из примеров второго я приводил в посте о постановке задач.

Про качество приема информации и в чем это конкретно выражается (по сути один из важнейших навыков разраба начиная от мидла и тем более для сеньора) еще буду писать позже.

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

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

Следующим постом расскажу как происходит такая потеря информации на конкретных рабочих примерах.

"Это не то, что я имел в виду!"... или коммуникационные издержки (часть 2).

Представим обычную ситуацию - продакт выслушал чью-то хотелку, сделал заметки. Потом провел аналитику (как эту фичу лучше сделать) и написал задачу, передал в разработку. Прошла пара недель (скажем, наступил следующий спринт), дошло до этой задачи, тимлид ее прочитал, задал уточняющие вопросы. Еще через несколько дней получил ответы. Нарезал задачу на фронт и бэк, добавил технических деталей реализации, передал в работу. Бэк сделал свою часть, фронт свою. Потом они состыковали свою работу и двинули задачу на QA. Через 2 дня задачу взял QA, у него появились свои вопросы по задаче, которых не было ранее. Он задал их разработчикам. Они ответили как поняли. Пару раз QA двигал задачу назад, обнаруживая дефекты. В результате еще через пару недель зарелизили задачу. Еще через неделю продакт вспомнил про нее, запланировал встречу и показал изначальному автору хотелки (допустим, это руководитель сейлз департамента, а доработка касалась CRM). И получил в ответ - "Это не то, что я имел в виду!" В разработку летит задача с высоким приоритетом - переделать, срок вчера.

Итого, что мы имеем:
- 6 участников процесса
- 5-6 недель от идеи до релиза
- созданная ценность - нулевая

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

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

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

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

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

Коммуникационные издержки между подразделениями - история

В комментариях был вопрос:

"Планируешь ли писать пост о том, как ты организуешь воркфлоу внутри своей компании дабы убрать коммуникационные издержки между подразделениями?"

Тема интересная (как и многие другие, но вопрос - это отличный повод поговорить), и для того, чтобы ее раскрыть, я начну с истории.

Как-то лет 5 назад я работал на позиции Delivery Manager в одной компании, в отделе разработки было 3 команды - B2B (бэк-фронт-QA), B2C (бэк-фронт-QA) и 1С (просто программисты). И там как раз была эта штука - проблемы в потере информации между командами, и проблемы, вытекающие из несогласованности действий.

У каждой команды были свои дейлики. Заняв новую роль, я начал ходить на все три каждый день.

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

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

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

Что я сделал:

➖Мы обсудили с тимлидом 1С ситуацию, он был заинтересован, естественно, прекратить клевету в сторону своей команды и в любой исходе, при котором они просто имеют возможность делать работу, которая от них требуется
➖Я обсудил с продактами ситуауцию с "непрозрачностью работы", и, так как задачи "зависают на стороне 1С", предложил еженедельные встречи, где можно "синкануться", то есть вместе посмотреть пул общих задач, синхронизировать работу по ним
➖Сделал гугл табличку (даже не стал внедрять изменения в систему работы в Jira, дальше будет ясно почему) со списком задач, которые требуются от команды 1С - ссылка на задачу, дата, к которой она нужна, и фактический срок. Сам стал заполнять эти данные, тимлида 1С попросил готовиться ко встречам

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

Вторая встреча длилась уже минут 20.

Третья и пара следующих сводились к тому, что люди собирались на 5 минут, смотрели на табличку, разговаривать было не о чем, так как все данные есть в ней, все плану делается ко сроку, либо уже готово. Обсуждать стало нечего. А задачи в 9 из 10 случаев делались раньше требуемого срока, и в 10 из 10 случаев делались раньше, чем свою часть заканчивала B2C команда.

Потом встречу отменили (обсуждать-то стало нечего), и вопрос о том, что задачи якобы вечно блокируются на стороне 1С, был исчерпан.

(продолжение предыдущей темы)
Коммуникационные издержки между подразделениями - а почему?

Возникает (наверно, у вас тоже) вопрос - а почему вообще так получилось?

То есть почему взрослые люди вместо того, чтобы просто поставить в соседнее подразделение задачу и объяснить что и к какому сроку им нужно, предпочитают сидеть и перемывать кости другим людям, которые воображаемо что-то не делают для них?

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

Можно было бы сказать, что это вопрос софт-скиллов, но некорректно называть скиллами (навыками) то, что сводится к психологии поведения и намерениям, а не способностям. То есть человек может, но не хочет. Желание - это же не софт-скилл?

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

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

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

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

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

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

(продолжение предыдущей темы)
Коммуникационные издержки между подразделениями - ответ.

Теперь можно вновь вернуться к изначальному вопросу:
"Планируешь ли писать пост о том, как ты организуешь воркфлоу внутри своей компании дабы убрать коммуникационные издержки между подразделениями?"

Первое - тут есть неточность. Убрать коммуникационные издержки нельзя, их можно только снизить.

Второе - я не могу назвать это воркфлоу (рабочий процесс), потому что как такового единого рабочего процесса для эффективной (с низкими издержками) коммуникации между подразделениями нет. Существующие фреймворки, типа SAFe, LeSS и т.п. - это не более чем описание самых общих принципов, без учета конкретного бизнеса со всем его многообразием особенностей. Унифицированный подход неизбежно превращается в прокрустово ложе, которое как катком проходит по сильным и слабым сторонам подразделений, срезая их, оставляя только посредственность в организации работы.

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

Поэтому деятельность по наладке работы между подразделениями считается более сложной, чем внутри. Между подразделениями, как будто в силу какой-то злой магии, задачи делаются с гораздо большим количеством блокеров, задержек и всяческих проблем. Банальная часть объяснения - интеграция разных областей создает дополнительные сложности. Главная причина, как правило - менеджеры разных отделов не хотят сотрудничать и идти навстречу (на словах при этом все за общее дело, естественно). Ресурсы команды руководители часто считают своими, направленными на их личные цели, а не на цели менеджеров соседних отделов. Это третье.

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

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

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

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

Направление работы важнее усилий. Часть 1 - история.

Однажды в одной компании в очередной раз сменился техдир (происходило это примерно раз в квартал). И так совпало, что был я там в этот момент деливери менеджером )

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

Рассказал мне, что у нас какой-то полный бардак в бэклоге, и что тут требуется backlog refinement (процедура, в ходе которой либо product owner, либо PO вместе с командой анализируют и структурируют бэклог, так, чтобы с ним в дальнейшем можно было удобно работать). Проблема очевидна - очередь задач огромна, в ней есть что-то начатое и не законченное, приоритет задач между собой непонятен, мусорка какая-то в общем, из которой вообще непонятно, чем команда разработки должна будет заниматься, что из этого актуально и т.п.

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

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

За следующие пару дней я разгреб бэклог из 200+ задач, структурировал их все в таблицу - какие закрыть, какие сложить в очередь задач по приоритетам, в каких требуются уточнения и у кого, ну и список с десятками action points (необходимых действий по каждой задаче, которые чем-то заблокированы).

Так вот, это все была присказка, а самое главное - то, что я обнаружил в этом бэклоге.

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

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

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

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

Что может превратить работу менеджера в ад.

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

Вы когда-то задавались вопросом - что самое сложное в работе менеджера? Что может превратить любую организационную работу в ад? Мой опыт показывает, что ни слишком сложные задачи, ни нарушение work-life balance, ни работа в условиях неопределенности, ни зп ниже рынка для конкретной роли не оказывает такого разрушительного эффекта на психику и ощущение (не)удовлетворенности от работы, как один фактор, который может показаться менее значительным на первый взгляд.

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

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

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

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

То есть вас БУДУТ окружать такие люди. Вопрос лишь в количестве и в том, доминирует ли в конкретном коллективе такая культура и модель поведения.

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

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

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

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

Быть сговорчивым менеджером - это хорошо... или все-таки нет?

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

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

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

Если очень сильно упростить, то это похоже на модель из теории игр "ястребы и голуби".

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

Чем может кончиться, если вы слишком сговорчивы в силу страхов и избеганий?

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

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

И лучше всего в конфликт вступать легко и непринужденно - часто негативную окраску ситуации несогласия дает именно то, что этому придается большое значение. Чем более просто и непосредственно оно выражается ("я думаю, так делать не стоит, потому что A, B, и C" или "мы так делать не будем, потому что...") - тем менее вероятно, что это приведет к личной неприязни.

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

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

Увольнение из-за софт-скиллов - история.

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

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

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

И у меня есть показательная история на эту тему - она рассказана одним из подписчиков.

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

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

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

Но это еще не конец - руководство посчитало нужным собрать IT-департамент и потратить пару часов на разъяснение причины увольнения и ответы на вопросы. Там подробно объяснили, что вне зависимости от заслуг и профессиональных навыков никто не может так общаться и создавать проблемы для других. Короче, то самое софт-скиллы >> хард скиллы.

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

Вспомнили, как у вас был какой-нибудь "незаменимый", который отравлял жизнь многим людям? ) А после увольнений кто-то кому-то что-то вообще объяснял?

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

Что такое плохой менеджмент?

Иногда чтобы понять "как лучше" можно пойти от обратного и попробовать разобраться - а что такое плохо?

Какой эффект на компанию, на команду может оказать плохой менеджер?

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

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

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

Что было на практике:
➖Фаворитизм к одним членам команды, негатив по отношению к другим (в основном к тем, кто позволяет себе критику, даже конструктивную и полезную)
➖Увлеченность внедрением технических изменений и искусственное откладывание продуктовых проектов, и, как следствие, ущерб потребностям бизнеса (будем делать интересные технические фичи, а не то, что нужно)
➖Вовлечение других членов команды в свои проекты, которые делаются просто потому что хочется (по нормальному нужно так: вместе с продактом или другими представителями бизнеса решается на что потратить усилия команды)
➖Создание иллюзии перегруженности команды и убеждение руководства в необходимости дополнительного найма (хотя на самом деле никакой потребности у бизнеса в этом не было, наоборот был оверстафф, то есть слишком много людей, больше, чем нужно для реализации бэклога)
➖Избегание любой ответственности и самоустранение от организации работы (как результат - на других сотрудников, которые даже не тимлиды, ложится работа по организации каких-то базовых вещей)
➖3 из 3 людей, которые попробовали себя на позиции тимлидов в этой команде (а в команде с таким вакуумом организации работы это действительно было нужно), перестали быть тимлидами
➖Личное нежелание выполнять DevOps функции и убеждение своей команды в том, что это не их работа (в противовес другим отделам, где это спокойно делали)
➖Сексистские оскорбления в офисе, которые в нормальной ситуации как минимум должны приводить к серьезному разговору с HR
➖Игнорирование фактов крайне низкого перформанса и отказ от принятия решений увольнять людей за плохую работу (но не за плохие отношения с собой)
➖Ухудшение репутации команды вплоть до того, что люди из других департаментов имеют предвзятость по отношению к ее работе (зачастую несправедливую)

Общий ущерб бизнесу от такой кадровой политики, введения продактов в заблуждение о капасити команды и растрата ее ресурсов на свои хотелки (даже не беря такие факторы как атмосфера в команде и связанные с ней издержки) я бы оценил навскидку примерно в дипазоне $500k-$1m за несколько лет работы в компании. Часть этой суммы - несколько сотен тысяч - это просто чистый кэш, потраченный на сотрудников, которые объективно не были нужны, остальное - не нацеленный на потребности бизнеса труд части команды, не целевое расходование средств.

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

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

Можно было бы накинуть еще десяток-другой пунктов, но и так сойдет.

Как можно было бы доказать, что все перечисленное связано именно с плохим менеджментом? Практически все эти пункты исчезли при замене менеджера:
➖Фаворитизм уступил место меритократии, часть людей было уволено за низкий перформанс, топовые ребята начали расти быстрее
➖Конфликты были потушены (некоторые отношения остались плохими, но с этого момента все решалось спокойным обсуждением на 1-1)
➖Команда смогла сфокусироваться на выполнении продуктового бэклога, что привело в результате к тому, что он через полгода кончился, и встала новая проблема - не хватает задач )
➖Работа была налажена, в том числе с помощью 2 новых тимлидов
➖Разрабы спокойно взяли на себя функции DevOps и успешно их освоили на нужном уровне
➖Репутация команды сменилась до того уровня, что топ менеджеры других департаментов приходили спрашивать о том, за счет чего удалось так хорошо наладить работу

Ну и так далее.

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

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

Мне попалось в тему крутое видео, предлагаю всем кто интересуется менеджментом, даже не в HR сфере. Кстати, фигурируют многие ошибки и принципы, которые мы тут уже обсуждали https://youtu.be/jRcJIFFgaXo

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

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

Кстати, кому интересна тематика трудоустройства на западном рынке, собесы-linkedin вот это все - рекомендую посмотреть его другие видосы тоже.

Прежде чем я напишу свое мнение, интересно было бы узнать, кто что думает по данному кейсу?