Метрики эффективности спринта.

Летом 2024 года, когда все были в отпусках, у меня выдалось две относительно свободные недели. Передо мной стояла задача подумать над тем, как можно оценить работу команд, которые делают Ecom в ЗЯ. Не с целью найти слабых, а скорее понять, что где как поломано, работает плохо или не работает вообще. Не помню как, но сначала я наткнулся на этот плагин для grafana, а затем на эту статью от Skyeng на Habr. И понеслось...

Я загорелся идеей на основе непосредственных данных из базы Jira построить ряд дешбордов для оценки как классических метрик типа TimeToMarket / LeadTime / CycleTime, так и метрик эффективности спринта.

Что такое вообще метрики эффективности спринта? Опять же, есть множество способов измерить спринт. На эту тему мне очень нравится вот этот доклад на PodlodkaTeamLeadCrew#12 от Avito. Но если не погружаться в академические тонкости, и строить что-то свое на коленке, то это % того, что команда сделала относительно того, что она обещала сделать.

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

На скрине спринт одной из команд, где я ВРИО тимлида, команда запланировала 12 сторей (целей), закрыла за сам спринт 9, то есть 75%. Уже чуть позже, в самом начале следующего спринта, еще 2 стори, то есть 91%. Но итоговый результат мы считаем 75%.

Если говорить о каких-то выводах, то основное, и, наверное, в чем-то стыдное и банальное, — это фокусировка команды на целях спринта, оформленных так, чтобы это было визуально максимально понятно и прозрачно видно на Scrum-доске, например, в виде swimlane'ов.

Нашел в своих старых заметках опросник, через который я прогонял кандидатов в свою команду во время работы в ostrovok.ru. Спустя 8 лет некоторые вопросы всё ещё кажутся актуальными.

Что ты будешь делать, если задача, поставленная перед тобой, плохо описана?
1. спрошу у лида
2. верну задачу обратно в пул со статусом need info
3. отвечу на свои вопросы сам и сделаю так, как считаю правильным
Ожидаемый ответ: 1 или 1/3

Что ты будешь делать, если у тебя кончатся задачи в спринте?
1. ничего
2. займусь самообучением/самообразованием
3. возьму сам задачи из бэклога
4. спрошу у лида
5. посмотрю, что у нас с техническим долгом, и постараюсь закрыть его
Ожидаемый ответ: 3 или 4 или 5

Если тебе что-то непонятно, то ты спросишь у лида или попробуешь разобраться сам?
1. буду стараться разобраться сам, пока не сдамся
2. попробую быстро разобраться сам, если не получится, спрошу у лида
3. сразу спрошу у лида, тк это будет быстро и эффективно
Ожидаемый ответ: 1 или 2

Для разработки фичи нужна помощь разработчика из другой команды. Сегодня он работает удаленно, а фичу хочется начать делать уже сегодня. Что делать?
1. постараюсь четко сформулировать свой вопрос и задать его в корпоративном мессенджере. Буду надеяться, что получу полный ответ
2. предложу пообщаться с коллегой голосом в Skype
3. дождусь завтра, когда он будет в офисе, а пока займусь другими задачами
4. спрошу у лида
Ожидаемый ответ: 1 или 2

Собрали релиз, в который вошло множество фич, багфиксов и рефакторинга. Поняли, что в релизе есть новый баг, который затрагивает менее 1% пользователей. Что делать?
1. будем фиксить, снова все тестировать, в итоге отложим релиз на 1–2 дня, а возможно и больше
2. катим, но сразу фиксим и готовим новый релиз
Ожидаемый ответ: 2

Как лучше поступить при написании новой фичи в текущем большом проекте?
1. начну сразу делать фичу, после ее разработки/внедрения буду рефакторить проект
2. проведу небольшой рефакторинг, потом сразу буду делать фичу
3. буду рефакторить, пока не пойму, что код новой фичи хорошо ложится в текущий проект
Ожидаемый ответ: 2 или 3

Микросервис, с которым взаимодействует твой проект, изменил что-то в текущей интеграции по API, тем самым сломав ее. Изменения небольшие, и ты можешь сам пофиксить проблему на своей стороне. Что делать?
1. напишу ребятам, что они все сломали, и пусть чинят
2. напишу ребятам, что они все сломали, но починю у себя, тк это быстрее
Ожидаемый ответ: 2

Буквально вчера вышла новая версия языка, на котором написан твой проект. В ней есть множество киллер-фич, которые тебе очень нужны, но просто так обновиться нельзя, так как есть легаси-библиотеки, которые ее не поддерживают. Что делать?
1. всё, пора! Хватит это терпеть! Буду просить у лида время на обновление до новой версии
2. 5 лет терпели и еще 5 потерпим, а потом уже и работу сменю
Ожидаемый ответ: 1

Пока кто-то сокращает, мы нанимаем, открываем новые направления и рынки для бизнеса.

Новости на этой неделе.
- На рынке говорят о том, что крупные компании сокращают штат IT-шников. А ритейлер «Золотое Яблоко», наоборот, рассказал о планах нарастить пул таких специалистов.
- С массовыми сокращениями не всё так плохо — обнаружил, что в Золотом Яблоке открыто 30 вакансий, на которые планируют нанять 150 (!) человек.
- "Золотое Яблоко" планирует расширить штат IT-специалистов на 25%. Кажется, ритейлер готовится к серьёзному усилению в диджитале.
- «Золотое Яблоко» расширяет ИТ-штат на 25%
- «Золотое Яблоко» на четверть увеличит штат IT-специалистов

Чтобы вам было проще, вот мои вакансии в Ecom или пишите мне (@arxell) c ссылкой или c файлом на ваш CV, я перешлю кому надо.
- ios / android
- Middle .NET developer / Senior .Net developer
- Middle Fullstack QA / Senior Fullstack QA
- Системный аналитик
- Frontend developer Vue

Также ищем TeamLead'ов команд разработки, которые отвечают за delivery-процесс в своей команде по доставке ценностей для клиентов, метрики, планирование т.д. и т.п. что описано тут.

Про гигиенический минимум.

Мне раньше было смешно, когда я видел в резюме у кандидатов среди навыков пункты Jira/Confluence. Что же такого особенного надо уметь, чтобы заявлять это как навыки в своём резюме, — думал я.

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

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

Сейчас, на фоне сокращений в РФ, я точно убеждён, что время кодеров прошло — они никому не нужны, как те самые валенки в углу. Нужны инженеры, которые умеют ставить себе задачи, описывать их, программировать их, писать к ним тесты, оставлять в каком-то виде после себя документацию, проверять, что happy-кейсы проходят, и релизить в prod.

Принцип «Швейцарского ножа» актуален как никогда.

Гибко или строго?

Вроде бы простой вопрос. В такой формулировке гибкость звучит как очевидный правильный ответ, тк гибкость подразумевает скорость. Так ли это? Всегда ли гибкость дает скорость, а строгость замедляет?

Если задуматься об этом вопросе на примере конфигурации backend-сервисов, где есть скажем два варианта:
A) динамическое конфигурирование сервисов в runtime
B) конфигурирование через YAML-конфиги с последующим деплоем
то кажется, что динамическая конфигурация в runtime будет быстрее.

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

Попробую, попытаюсь объяснить. В IT уже давно решён вопрос хранения кода. Кстати, вот отличная статья на эту тему. Сейчас разработчик всегда может посмотреть историю жизни каждой строчки кода в своем проекте, так как git всё помнит. Всегда можно откатиться к предыдущей версии, понять, что было тогда, что было где-то посередине, и как всё выглядит сейчас. Понятно кто/что/как/когда изменил, есть связь с задачей в таск-трекером, а CI/CD обеспечивает проверку каждого этапа изменения и связи изменения с номером сборки и релиза. Это в совокупе дает максимальную прозрачность и явность в изменениях. Конфигурация — это такой же "код", как и код, написанный на условном Python/Golang/C#/Java/..., если к конфигурации относиться как к коду, то на долгой дистанции это уменьшает количество тупых багов, инцидентов и неконтролируемых изменений, которые съедают кучу времени у команды разработки.

Другое дело, что если CI/CD медленный или нет возможности самостоятельно раскатывать свои backend-релизы, то разработчики по пути наименьшего сопротивления будут искать лазейки, чтобы менять конфиги динамически, без изменения их в YAML-файлах. Это уже вопросы к зрелости инфраструктуры, DevOps-процессов и качеству CI/CD. Иными словами, если у меня, как у разработчика, от мержа ветки с изменениями в master до раскатки на prod-стенд проходит 3–5 минут, то о динамической конфигурации мне и думать нет смысла.

P.S.: фичефлаги и АБтесты это не конфигурация!

6 месяцев с iPhone

Так получилось, что я всегда пользовался Android: HTC Hero -> HTC Legend -> Nexus 5/5X -> Samsung S19/S20/S22. Наверное, было что-то еще, но я уже не вспомню, а история с iPhone у меня как-то не завелась еще с ВУЗа. Я давно хотел iPhone, но отсутствие USB-C мне не давало покоя, и я ждал. Дождался, этим летом (2024) мне подарили iPhone 15 Pro Max, и это стало разочарованием.

Если отбросить весь текущий контекст санкций и отсутствие удобного способа установки банковских приложений, VPN и Apple Pay, мне все равно непонятны две вещи: нет нормальной кнопки «Назад» и долгие анимации там, где они не нужны. Еще я так и не смог разобраться с заменой клавиатуры Apple на Gboard, она вроде как работает, но периодически все равно открывается стандартная клавиатура Apple, которая меня жутко бесит (субъективно, конечно, но все же).

В итоге я вернулся на новый Samsung S25 и бесконечно этому рад. Видимо, это как вопрос кошек и собак, яблок и груш, красного и белого, темного и светлого, те каждому свое.

Про выбор адреса.

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

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

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

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

В зависимости от региона – разное качество данных
- МЕ: у некоторых адресов в раскладке отсутствует населенный пункт, т.е. здания принадлежат уровню выше (например, региону), также из-за специфики региона;
- KZ (Google): многие дома не определяются, некорректная нумерация домов (на других картах адрес ведет в другое место), старые данные в наименованиях (с 2006 года уже есть новые сведения);
- АЕ (Google): новые районы города (Дубай) не определяются по подсказкам, обратному геокодированию;
- SA (Google): по некоторым областям со спутника видны пустыри в чертах населенного пункта, но на схеме оказывается район с домами. Медленная скорость актуализации геоданных;
- SA (Mappable): по тем же областям с пустырями есть соответствие спутника и схемы, т.е. зданий реально нет, там пусто;
- РФ (Dadata): точность ФИАС до улицы при наличии дома и координат до дома (при этом адрес реально существует) – по ФИАСу адреса восстановиться может только до улицы; можно придумывать названия домов, строений, корпусов – Dadata выводит такое как реальную подсказку, однако точность координат и ФИАСа падает уже, например, до улицы; в Dadata один тип улицы, в Яндексе другой (например, станция против улицы). У Dadata источником являются местные органы самоуправления, предоставляющие адресную информацию.

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

Выступаю сегодня на пик айти

Про профили технических менеджеров.

Наконец-то добрался до описания, что такое TeamLead и что такое тимлид тимлидов (ClusterLead) в рамках своего субъективного понимания этой проблемы. База, конечно же, взята из Avito playbook, тк считаю, что ничего лучше в этом плане на просторах рунета нет.

В свой playbook добавил личное представление о том, что такое TeamLead платформенной команды и ClusterLead платформенного кластера, в частности их связь с гильдиями.

#playbook

Про разницу отношения к работе.

Я сейчас нахожусь в отпуске в Австралии, приехал посетить русскую свадьбу друга.

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

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

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

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

Про чувство собственности в IT.

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

На мой взгляд, есть несколько причин, почему так говорят.

Первая возможная причина — боязнь, что сломают. Люди дорожат своей проделанной работой и боятся, что кто-то со стороны может случайно ее испортить. Я понимаю такой аргумент, но все мы состоим из плоти и крови, все мы можем заболеть, и всех нас может сбить автобус. Закрывать все на себе — плохо, тк это значит, что после вас с высокой вероятностью все развалится. Вспоминаем историю Генри Форда про отпуск для своих топ-менеджеров.

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

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

"А кто его будет обучать?" (с) ...

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

Существует модель обучения 70/20/10, её ещё иногда называют моделью обучения Дженнингса.
70% — решение рабочих задач. Работа с реальными кейсами и задачами, работа над собственными ошибками и формирование выводов.
20% — общение с коллегами. Получение обратной связи, обмен опытом с коллегами, работа с наставником или коучем.
10% — формальное обучение. Прохождение корпоративного обучения, курсов, вебинаров, тренингов и лекций.

С моделью обучения 70/20/10 совершенно необязательно, чтобы у линейного инженера был руководитель, который превосходит его в hard-навыках. В условиях современного интернета, когда количество бесплатных курсов/подкастов/конференций/семинаров превышает количество свободного времени, нуждаться в прямом наставнике, который должен обучать сотрудника, означает признание этого сотрудника в нежелании заниматься самообразованием. Например, если ваш инженер уровня middle+ просит помочь ему стать senior, просто дайте ему радикально более сложную задачу и позвольте ему справляться с ней самостоятельно.

Полезные ссылки:
- Модель «70:20:10» — доказанная практика, серьёзная теория или просто популярный миф?
- Как управлять талантами в большой корпорации
- Что такое модель обучения Дженнингса (70:20:10)
- 702010institute.com

P.S.: для джуна ситуация может быть чуть иной, тк джуну на старте всё-таки нужен наставник.

Про заметки.

Где вы храните заметки?

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

Потом я познакомился с Notion, и это, конечно, был своего рода прорыв. Записная книжка контактов, вопросы для собеседований, личный и семейный бюджет, документы больничных анализов — всё-всё можно было круто организовать в Notion. Знаю, что многие компании его используют как аналог Jira/Confluence, тк его функциональность действительно может их заменить. Но, к сожалению, лично меня Notion заблокировал, когда началась история с санкциями и Cancel Culture.

Если интересно погрузиться в этот дивный мир, то вот сравнения сервисов между собой.
- Универсальность против конкретики. Какой сервис заметок и баз знаний подойдет именно вам?
- ТОП-15 лучших приложений для заметок
- Лучшие приложения для заметок на 2024 год

А что сейчас? Сейчас я многие заметки веду в ТГ в Saved Messages (оно же избранное). Не знаю, почему так получилось, как-то само собой все заметки перетекли туда, особенно это стало актуально, когда ТГ сделал теги у сообщений и поиск по ним в Saved Messages.

Многие рекомендовали попробовать Obsidian, типа он как Notion, но лучше. Да? Стоит?

Детская задачка ...

у дочки в 4-м классе в аттестационной работе по итогам года.

Учитель предложил четырём ученикам несколько задач. Каждую задачу
решили только трое. Известно, что Оля решила больше всех — семь задач,
а Гоша решил меньше всех — четыре задачи. Сколько всего задач предложил
учитель?

Я не решил, chatgpt и deepseek выдают разные и достаточно противоречивые друг от друга результаты.

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

Про разные треугольники.

В 2014 году, когда был бум крафтового пива в Москве, существовал так называемый московский крафтовый треугольник 🍻. Это был барный маршрут между тремя барами, которые тогда были амбасадорами крафтовой культуры в Москве. Бары еще существуют, поэтому маршрут все еще актуален.

Сейчас, спустя 11 лет, на Аравийском полуострове тоже есть свой треугольник, только в сфере красоты 💅🏻! Мы (ЗЯ) официально открыли свои офлайн-магазины в трех самых крупных странах полуострова: Катар, Эмираты, Саудовская Аравия. Вы можете придти своими ножками в любой из магазинов в Доха/Джидда/Дубай или сделать онлайн заказ через МП и сайты goldapple в этих странах.

Осень-зима-весна 24/25 были не самыми простыми для нашей команды, спасибо всем, кто принимал непосредственное участие, вы все молодцы 🤝🚀🔥

Про цвета в календаре.

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

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

Вырезка из моего протокола

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

Рекомендую покрасить свой календарь, потом пройти тест и сравнить то, что получится. Интересно в рамках саморефлексии и самоанализа.

Про кодогенерацию

Я очень люблю кодогенерацию. Первый раз я с ней столкнулся где-то в 2020 году, когда, еще будучи разработчиком, увидел, как из OpenAPI спеки получился полностью готовый к работе HTTP-клиент сервиса на Go. Уже в Магните ОМНИ мне удалось на самом старте заложить в инженерную культуру департамента подход генерации как клиента, так и сервера из OpenAPI и Proto спецификаций для Golang стека, aka spec first подход. Для Python было чуть иначе: там из кода генерировалась спецификация сервера, aka code first подход, но HTTP-клиент сервиса также генерировали из спеки. Вот, кстати, этот инструмент, можете его попробовать для Python стека. Частично обо всем этом я рассказывал в Moscow Python Podcast. Про генерацию кода.

Важно отметить, что генерация кода имеет ценность только в связке с линтерами соответствия кода спеки и спеки кода на уровне соответствующих шагов CI/CD, то есть:
- обновил код руками - красный pipe
- обновил спеку, но не обновил код - красный pipe
- обновил спеку, обновил код, но при этом внес обратно несовместимые изменения в API - красный pipe
- обновил спеку, обновил код, но изменения не соответствую внутренним договоренностям внутри компании типа Snake Case VS Camel Case VS Pascal Case VS Kebab Case - красный pipe
- ...

Но оставался вопрос: кто пишет сами спеки, чтобы потом из них сгенерировать сервер и клиент? При мне в Магните ОМНИ это делали сами бэк-разработчики, тк они проектировали API сервисов, сами договаривались между собой о контрактах и с этим не было проблем. Но, по идее, это могут делать системные аналитики (далее – SA).

Тогда, например, в том же GitLab можно тонко настроить codeowners, чтобы за спеки отвечали SA, а за код – разработчики. Тогда может получиться интересный тандем для совместной работы на уровне MRов. Мы сейчас в ЗЯ стараемся двигаться в этом направлении, надеюсь у нас все получится.

Про демократуру.

Около 5-6 лет назад, когда я решил, что хочу двигаться в сторону CTO, я начал искать литературу, способную приблизить меня к этой цели. Не помню точно, как это произошло, но я нашёл подборку книг - Список книг для тимлидов и CTO. Данный список остается актуальным и по сей день, и я считаю, что многие из упомянутых в нём книг обязательны к прочтению для любого руководителя.

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

Сейчас я читаю (на самом деле слушаю) одну из его следующих книг — Управление изменениями без потрясений и конфликтов. Книга частично повторяет то, что было в "Идеальном руководителе", да и в целом в книгах Адизеса очень много повторений и воды, но это не суть. В данной книге меня зацепил термин "демократура". По Адизесу, демократура — стиль управления, в котором сочетается демократия в принятии решений и диктатура в их осуществлении.

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