⬆️ Часто доводилось в своих проектах слышать об ограничениях, которые логически объяснить невозможно.

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

Моя рекомендация - потратить чуть время и копнуть.
Почему так? А чья это позиция? Чем он объясняет?
В общем, "метод 5 почему".

Что можно приобрести: выяснить, что это ограничение - миф:
- когда-то кто-то посчитал, что ему так проще
- у кого-то когда-то не было ресурсов
- какого-то инструмента не было, а теперь появился...

Что можно потерять: от одного до нескольких часов на выяснения. Да и то в результате получить объяснение для себя почему так - и успокоиться.

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

Хотя исходно принцип KISS - Keep It Simple Stupid был придуман для инженеров, буквально

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

в менеджменте этот принцип работает даже еще более явно.

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

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

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

Немного о себе и о мотивации.

⚽️В юности я играл в футбол. Много, часто. Дорос до любительских чемпионатов на большом поле, с судьями и экс-профи в командах. В общем, вот так как-то.

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

Перерыв.
Погода противная, игра у команды не клеится.
Подводит тренер футболистов к трибуне - а на трибуне ровно один болельщик, с флагом.
- Видите вон того одинокого болельщика? Вот для него мы и играем.

Вот и с телеграм-каналом как-то так :)

#ПроМеня
@ManagersThinks

Шикарнейшую мысль прочитал у В. Мараховского. Приведу полностью, с моим выделением.

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

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

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

Увы, мы не то что редко признаёмся в наличии таких предохранителей — мы даже не всегда о них знаем. Это затрудняет и их преодоление.

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

Но на самом деле это - актуально для любого человека, включая меня и читателей этого канала.
До какого-то момента человек стремится добиться успеха - будь-то социальный лифт, карьерный рост, достижение личных целей.
А потом считает, что дальше рвать жилы и не обязательно - и так не плохо.
Для объяснения себе этого подхода каждый человек выбирает комфортные для себя формулировки:
"work-life-balace,
мне нужно больше времени уделять семье,
всех денег не заработаешь,
хочу больше пожить для себя,
хочу сократить уровень стресса в своей жизни..."

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

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

Делегировать не задачу, а идею.

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

А вот если ты делегировал идею, то зрелый чел будет ставить нужные задачи себе и другим сам.
И решит.

Как делегировать идею?

1. Найти "бесхозную" идею.
Но не "внедрить проект качественно", а, например:
"продумать как раскатать новое решение не сразу на всю клиентскую базу, а по частям, и по каким + план отката"

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

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

4. Профит.

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

#Пятничныймем

О принципе "не я - так никто" в корпорациях

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

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

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

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

Означает ли это, что инициативность - это плохо?
Ни в коем случае.
Просто в какой-то момент необходимо свою работу передать тому, кто за этот функционал отвечает.

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

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

Когда не знаешь, какое проектное решение принять и обратился за помощью к проектной методологии

#Пятничныймем

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

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

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

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

Бывает, что делегирование заканчивается примерно так (и не только у дев 😜).

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

Понятно, что когда команда большая - есть много вариантов как этого избежать.
В порядке буллитов выше, как пример:
- собрать участников, рассказать идею, заинтересовать, продать идею "добровольцу";
- поставить задачу тим-лиду, чтобы дальше ее поставил от себя;
- поставить тому, чьи hard и soft скиллы позволяют решить задачу лучше.

Что делать, у тебя всего 1-2 человека?
Два слагаемых: взаимное доверие и консенсус в направлении развития чела.
Он доверяет тебе в постановке задачи и корректировке.
Ты - доверяешь ему в способности расти, в выборе решения и даешь право на ошибки.

Иначе - SMART +детальный контроль, что для меня первый шаг к вежливому расставанию.

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

В таких задачах у РП есть два больших вызова:

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

2. Неочевидный.
Так как задача - на несколько трайбов, а то и организаций,
то рано или поздно выясняется, что всем недостает описания сквозного процесса или хотя бы зафиксированных еnd-to-end бизнес-требований (БТ).
А нет их потому, что с внедрением Agile в компаниях исчезла как класс роль бизнес-аналитика.
Аналитик любой из команд знает функционал своего продукта и может быть еще пары своих соседей. А если команд, скажем, 15, то требований как должен работать новый процесс в целом - писать просто некому.

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

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

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

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

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

#Пятничныймем
@ManagersThinks

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

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

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

3. Disrupt-проект, порожденный в disrupt-подразделении (лаборатории инноваций, департаменте перспективных разработок и т.д.) по принципу "сначала внедрить - потом найти заказчика"
В таких случаях у заказчика проекта есть лютая уверенностью, что бизнес-заказчик уж точно появится, потому что мы реализуем такое крутое решение, что уууххх!
Ну и нюансы внедрения в пром того, что за неделю сделали в лабораторных условиях не всегда всем очевидны.

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

Зачем я написал, если у РП как правило нет выбора?
Потому, что предупрежден - значит вооружен 👆
Когда понятны риски - понятно как ими управлять.

Рубрикатор (техническое обновление от 02 апреля)

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

📌 чуть-чуть про себя и для чего веду канал

📌 о том, почему решения надо продавать и что бывает, когда продать не получается

📌 почему тот, кто дает блокирующие замечания к проекту - не враг, а иногда союзник

📌 до какой глубины менеджеру имеет смысл погружаться в детали своего проекта

📌 о том, что на практике управлять проектными рисками гораздо проще, чем обычно пишут в методиках, начиная с PMBOK

📌 какие мягкие навыки для руководителя проекта это - база

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

📌 как работать в токсичном проекте и почему это - еще и возможность

📌 почему стресс в менеджерской работе неизбежен и как с этим справляться

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

📌 Как не дать разовой коммуникации с незнакомым коллегой сделать обратную связь от руководителя негативной

📌 О том, что каждое слово при докладе Top-руководителям может стать последним

📌 Как вести себя менеджеру, если попал в неприятную ситуацию

📌 Как воспринимать прилет от руководства, даже если считаешь, что не по делу.

📌 Как писать протоколы встреч и зачем

📌 Что мне помогло вырасти как менеджеру

📌 Принцип Keep It Simple Stupid как база для менеджеров

📌 Почему выгоднее делегировать не задачу, а идею

📌 Почему принцип не я - так никто не работает в корпорациях

📌 Чем еще должны заниматься РП в Agile кроме своих основных задач

📌 Какие проекты для меня самые некомфортные

📌 Почему ты - это то, как ты выглядишь

📌 Wishful-thinking-планирование.

Многим менеджерам найдется что вспомнить…

#Пятничныймем