Вот кстати формула "или совсем дурак или совсем даже не дурак" (с) прямо-таки просится.
Конечно, речь о том, кто утвердил эту вакансию в штатном расписании футбольного клуба 😀

Минутка рефлексии.
Многим известны 6 стилей лидерства по Д.Гоулмэну: авторитарный, демократический, дружественный, наставнический, эталонный, визионерский.

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

Иногда приходится быть авторитарным, но это для меня - менее комфортно.

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

Хотелось бы послушать мнения, как эти побочные эффекты уменьшить.

#ПроМеня

👆 Теперь я знаю, как это называется по-научному

Алгоритм страуса.
Стратегия избегания проблемы в расчете на то, что она скорее всего не произойдет.
Используется тогда, когда с точки зрения трудозатрат или затрат вообще проще дать проблеме случиться, чем работать над ее предотвращением.

Ну, то есть:
не
мне не хочется тратить на это время,
а
к этому риску предлагаю применить алгоритм страуса 😄

Постправда.

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

Важно не это, а то, как случившееся воспринимают лица, принимающие решения.
Ибо именно эта версия послужит почвой для принятия решений, и она же распространится затем по корпорации или среди других ЛПР.

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

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

Постправду нельзя откатить назад в правду, как и фарш нельзя провернуть назад в мясорубке.
Но из фарша можно сделать вкусную котлету.

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

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

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

Менеджерский костылинг.

Для менеджеров мем с картинки подходит даже больше, чем для кодеров.

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

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

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

Костылей никто не хотел - костыли были неизбежны.

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

Когда сложная интеграционная задача есть, а менеджера у нее - нет.

С большинством тезисов, описанных в этом посте уважаемого Г. Михеева согласен.

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

Мы

Смех смехом, а как-то я лично участвовал в проекте с совмещенными фазами "Анализ"-"дизайн"-"разработка"-"запуск".

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

Дело было в 2005 году.
Scrum как фреймворк тогда только-только зародился, а вот scrum.org еще не было. И это - в США, а в России статьи и размышления на эту тему воспринимались примерно как Sci-Fi про далекую галактику. У нас в те времена и проектная-то методология была внедрена совсем даже не везде.

В Билайне тогда работал.
Правда не РП, а - аналитиком. Давно дело было, в РП я еще не умел :)

И вот в год объявления громкого и оглушительного ребрендинга, вот когда вместо 🐝 на синем фоне появились желто-черные полоски, в маркетинге Билайна зародилась идея поддержки бренда, в виде акции "От подарка не убежишь".
Срок запуска - сразу после НГ, с 15 января.
Требования? Ну так-то были, но заказчик же - маркетинг!
Поэтому идеи генерились каждый день новые.

☠️ Приоритет задачи - умри, но сделай.

🕺💃 Перед лицом общей угрозы ИТ объединились с бизнесом.
Каждый день собирались, обсуждали новые требования: вот это сделать за 2 месяца можем, а вот это - ну никак.
Враждовавшие на уровне подразделений аналитики бизнеса и ИТ дружно думали над ТЗ и Change-реквестами, а затем проталкивали каждый из них на ручном приводе.
Маркетинг мило щебетал с коммутаторщиками и иными железячниками.
РП проводил по 6-8 встреч, то с маркетингом, то с начальством, то с ИТ.
Напомню, ни о каком Agile тогда никто не слышал. ⬇️

#СлучилосьСоМной