​​⚖ Комментарии к задачке 930-803

Вариант А обычно выбирают те, кто хоть раз делал проект за свои. Не “за свои лишние”, а “за свои кровные” — вкладывая все время, все знания и навыки, все деньги и силы в свой стартап, проект, продукт. Для них вообще других вариантов не существует: уволить, ибо правила одинаковы для всех, и правила эти были четко озвучены. Еще раз: правила четко сформулированы и донесены до всех.

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

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

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

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

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

Так что сначала уволить. А потом, конечно, простить.

​​⚙ Плодотворные встречи

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

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

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

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

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

Но это никого не расстроило. "Классно поговорили, правда?", — спросил меня потом один из менеджеров. "У нас так плодотворно все встречи проходят!"

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

​​⛳️ Немой укор как мотивация

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

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

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

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

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

​​💂‍♀ Идеальная продажа

Одна из моих любимых притч о продажах.

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

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

Тот объяснил новым рекрутам, что такое страховка, а затем сказал:

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

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

Надо только поискать.

​​🛰 Проектные и операционные страны

Страны (народы) бывают проектные и операционные. Проектные страны известны яркими, выдающимися, но единичными победами — военными, научными, техническими. Операционные страны известны хорошими дорогами, вкусным кофе и развитым туристическим бизнесом.

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

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

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

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

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

Проектный способ существования ничем не лучше и не хуже операционного.

​​🪒 О ритмичности управления и театральном совете

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

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

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

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

Есть старый совет из мира театра, который я услышал от историка моды Александра Васильева: делайте неудобное привычным, привычное — повседневным, повседневное — родным.

Лучше и не скажешь.

​​🚢 Высыхают голубые океаны

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

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

Нет потребности — нет рынка. Ваш продукт никому не нужен. Нет непрямых конкурентов — тот же вывод.

Нет прямых конкурентов — проверьте юнит-экономику еще раз. Скорее всего, она не сходится.

Нет конкурентов — нет денег на рынке. По сути, нет самого рынка.

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

Голубые океаны хороши только тем, что там никого нет.

​​🍡 Польза от менеджера

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

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

Менеджер нужен не для того, чтобы объединять. Он нужен для выставления приоритетов задач: “Эта задача сейчас для продукта важнее, чем та”. Он нужен, чтобы помогать с синхронизацией: “Эта задача нужна в понедельник, эта не позже среды, а та — когда Вася обновит дизайн”.

Еще менеджер должен помогать устранять административные барьеры.

Объединять никого и ничего менеджер не должен.

​​🧚 Некому писать

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

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

Налицо дефицит технических писателей. И я понимаю, почему.

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

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

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

При этом войти в профессию и быть в ней успешным совсем не трудно. Надо быть грамотным и внимательным. И уметь просто и понятно писать о сложном. Все.  

И платят за это вполне пристойно. А там, глядишь, и на UI-писательство перейти можно, вообще шоколадная история.

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

Давайте уж, спасайте ИТ-отрасль. )

​​🥌 Узнать что-то личное

Люди гораздо интереснее ролей и функций.

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

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

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

Конечно, каждый менеджер должен такую фишку рассказать и о себе.)

Вы о каждом в команде знаете что-то личное?

​​📈📲 О формате отчета и важных мелочах

Много лет назад работал я руководителем проектов в банке Хоум Кредит.

Каждую неделю мы писали руководству и всем стейкхолдерам отчеты о статусе проектов. Содержание было обычным для такого рода документов: картинка-светофор, сколько денег потратили, какие задачи решили за неделю, что будем решать в ближайшее время, какие риски и проблемы имеем. А форма была необычной: отчеты делали в Power Point. Если у менеджера было четыре проекта, то уже получалась презентация из четырех слайдов.

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

Но была одна проблема: эти отчеты никто не читал. Главное, что их не читали спонсоры проектов — члены правления банка. Они должны были помогать нам устранять административные преграды, принимать важные решения по бюджету. А они не читали. Для менеджера проекта это означало проблемы. Для проекта это тоже ничего хорошего не означало.

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

Я решил, что все дело в тяжести формата Power Point. Просто открыть и читать неудобно, надо перейти в режим просмотра слайдов. А если человек захочет сразу открыть последний отчет из списка? Возможно, решил я, им это лень делать. И предложил использовать Excel. Очень удобно: редактировать несложно, можно связать отчеты за несколько недель общими формулами, построить сводные таблицы по нескольким проектам. Мы попробовали так делать. Не помогло. Не начали читать наши отчеты.

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

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

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

Мы перешли на небольшой текстовый документ, который высылался в теле письма на почту боссу. "Шапку" в каждом отчете сделали информативной, и босс сразу понимал — изучать дальше детали или нет.

Вовлеченность топовых стейкхолдеров в проекты очень сильно выросла, чего и добивались.

Не бывает в управлении проектами неважных мелочей.

​​🚿 Так много воды 

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

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

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

На ум приходит аналогия с работой переводчика. Чем плохи решительно все компьютерные переводчики от Google Translate до Deepl и дальше? Тем, что они тупо заменяют слова одного языка на слова другого по своему глоссарию.

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

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

Вы хотите перевести фразу “ну все, сейчас ты получишь”.  
Софтина: опиши ситуацию.
Вы: “школьники ссорятся”, сообщение: угроза.
Софтина выдает английский аналог.  

или

Вы хотите перевести фразу “ну все, сейчас ты получишь”.  
Софтина: опиши ситуацию.
Вы: “мать готовит обед, сын голоден”, сообщение: нейтральное обещание.
Софтина выдает английский аналог.

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

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

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

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

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

🎛 Тренажер для менеджеров и не только 17-13

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

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

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

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

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

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

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

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

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

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

C. Менеджер сам исправил ситуацию, он молодец. Все совершают ошибки, вы тоже не идеальны. Кстати, а почему у вас в отделе такой бардак? Так что наказывать менеджера не стоит. Проект признать успешным, но разобрать ситуацию всем отделом необходимо.

D. Менеджер – профессия, связанная с рисками. Это вполне нормальная рабочая ситуация, когда проект балансирует на грани. Клиент остался доволен, а компания заработала больше, чем рассчитывала, так что проект надо признать успешным, а менеджера наградить дополнительным бонусом. Не стоит рассказывать об этом случае коллегам Константина.

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

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

​​🛡 Комментарии к задачке 17-13

Разбираем историю с забывчивым менеджером.

Вариант А плох: нельзя так сурово наказывать за несистематические ошибки. Уволив Константина, вы пошлете остальным менеджерам ясное сообщение: «Здесь у нас не работа, а минное поле. А вы – саперы». Вы убьете их лояльность, если она была. И они будут не работать, а обреченно ждать своего последнего дня в компании. Если вам это безразлично, то хотя бы тоже подготовьтесь к оттоку кадров. Ну и про себя не забудьте.

Вариант Е – это паранойя, граждане. Да, бывает все, и все возможно. Но тогда лучше вам трудиться в СК РФ или какой-то подобной организации. ) Работать, подозревая всех и каждого, вредно для психики. Эффективно работать при таком подходе к делу невозможно.

Вариант D плох тем же, чем плох вариант А, только с противоположным знаком. При таком подходе легко сделать разовые ошибки систематическими.

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

Почему я за вариант С? В кейсе определяющее не только то, что Костя хороший сотрудник, все осознал и работал над исправлением ситуации. Важно также учесть, что вы не проектный менеджер, а руководитель проектного департамента, линейный менеджер. А у линейных менеджеров задача не совсем такая, как у проектных – добежать и не упасть по дороге. Линейные менеджеры должны ориентироваться на развитие своих сотрудников. Вариант С в большей степени стимулирует у Кости и его коллег желание исправлять ошибки. А культура “я не боюсь ошибиться, но все сделаю, чтобы ошибку исправить” – это то, к чему надо стремиться.

В жизни менеджер выбрал вариант В: формально наказал за ошибку, лишив проектного бонуса, и наградил формально бонусом за второй контракт. С одной стороны, никто сильно не пострадал, с другой – все вынесли что-то из этой истории.

Ну а какой вариант, В или С, выбрать вам – решать вам самим.

​​🥊 Бегать и пинать

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

Куда там. Главный инструмент менеджера — ноги. Голова тоже не повредит, но ноги важнее.

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

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

Голова нужна только чтобы не бегать лишнего и не убежать не в ту сторону. Еще чтобы пинать именно того, кого надо. Сначала качаем ноги, потом голову.
Бегать и пинать.

Слишком примитивно звучит, да? Не хватает бирюзовости, вовлеченности, владельческого подхода и всего остального?

Что ж, все управленческие истины очень просты. )

​​🥕 Краткосрочная и долгосрочная мотивация

Самой лучшей мотивацией проектной команды в краткосрочной перспективе является страх.

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

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

Самой лучшей мотивацией в долгосрочной перспективе является интерес к выполняемой работе.

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

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

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

​​🎯 Как менеджер проектов характер воспитывал

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

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

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

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

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

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

​​🎢 О проектах и жажде оптимальности

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

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

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

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

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

Это знание позволяет менеджеру спокойно воспринимать его последствия. И стимулирует развитие культуры управления рисками.