​🏆 Бессмысленные пузомерки

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

В этом есть хоть какой-то смысл для очень простых работ, типа копания ям. Экскаваторщик Иннокентий вырыл в октябре траншею на 30% длиннее, чем все его коллеги. Ладно, вот ему на 30% больше денег.
Но с какого перепуга эта идея укоренилась в головах офисных людей? Что такое "лучший разработчик июля"? Почему этот аналитик во втором квартале попал на доску почета?
Единственное объяснение — непроходимая тупость тех, кто отвечает за развитие и поощрение сотрудников на уровне компании.

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

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

А навязанное ранжирование сотрудников на коротких временных интервалах — нежизнеспособная и вредная туфта.

​🖨 Технарям о текстах

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

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

Вот вам несколько дельных советов. Годятся и для технических документов, и для писем клиентам или коллегам.

1. Не пишите текст с первого раздела. Начинайте с самой важной мысли. Даже если это последние пять строк документа. Введение напишете потом, когда основная мысль будет отточена и завершена. Если начинать писать текст так, как его будут читать, то потратите кучу времени на «Общие положения» и тому подобное. А потом все равно придется переписывать.

2. Вы не стилист уровня Чехова или Довлатова. Вы не сможете написать сразу так, чтобы читатель подпрыгивал от восхищения. Ни-ко-гда. Начните писать, как думается: корявенько, не подбирая слов, путаясь в предложениях и мыслях. Если легче с матом — материтесь. Вывалите на бумагу страшненькую кучку своих мыслей. И только потом начинайте искать верные формулировки и подходящие слова, разгребайте ее, делайте из кучи конфетку. Сразу написать хорошо не выйдет.

3. Запомните: чем короче, тем лучше. Для текста это точно справедливо. ) Не пишите длинных предложений. Если получилось длинное, разбейте на несколько коротких.

4. Не пишите в пассивном залоге. Для тех, кто не в курсе: это фразы типа «тестирование системы было проведено специалистами заказчика». Надо так: cпециалисты заказчика протестировали систему.
Меньше пассивного залога — лучше текст.

5. Проверьте документ перед отправкой. В нем не должно быть ошибок, опечаток, несогласованных частей предложения, лишних скобок и кавычек. Не уверены в своей грамотности — пользуйтесь автоматическими средствами проверки орфографии. Если в документе есть ошибки, то и к автору документа, и к его компании, и к его продукту отношение как к … ну, вы поняли. Я уж молчу про ошибки в интерфейсе.

Еще раз: тексты — это важно.

​🛋 Задача к утру

Как отличить опытного сотрудника от неопытного? Неопытный всегда на все согласен:
– Сделаешь эту задачу ко вторнику?
– Да!
– А давай лучше завтра к утру?
– Конечно!

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

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

И тот уже как-то съеживается и растворяется.  

А ночью спать надо.

​Спрашивали — отвечаем 30

“Сергей, я начинающий стартапер. Дело идет мало по малу, продукт развивается, появились первые наемные сотрудники. Вопрос к Вам: как побороть в себе страх отдать кому-то задачу? Иногда остро очевидно что проще потратить десять минут и сделать задачу самому, чем потратить пол часа на объяснения.”

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

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

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

​​​🚦 Установить границы и дать свободу

Еду я на такси, выскакиваем мы на МКАД, проезжаем знак, как на картинке внизу. Я спрашиваю у таксиста, знает ли он, что сие означает. Он признался, что толком не помнит. Но сказал, что, судя по форме и цвету, этот знак ничего не запрещает. Просто о чем-то информирует.

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

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

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

Знать, чего делать не нужно, важнее, чем иметь подробную инструкцию или план.

🦗 Тренажер для менеджеров и не только 966-839

Вы — руководитель департамента в ИТ-компании. У вас в подчинении почти сто человек: РМы, разработчики, аналитики, тестировщики. Вы в компании уже 11 лет, пришли сюда еще на четвертом курсе  универа и очень быстро стали сначала менеджером проектов, а потом линейным руководителем.

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

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

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

​В боте @trenmen_Bot@trenmen_Bot более пятидесяти управленческих кейсов из реальной жизни. И все сделаны так, чтобы тренировать менеджерские навыки.

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

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

Стартуйте: @trenmen_Bot@trenmen_Bot

​🐸 Комментарии к задачке 966-839

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

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

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

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

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

​🏹 Держать руки свободными

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

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

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

Захотелось вспомнить былое и написать пару скриптов за разработчика? Решили за сотрудника обновить план и смастерить отчет? Думаете, что сильно поможете дизайнеру, нарисовав за него несколько картинок?

Не надо. Держите руки свободными.

​🖍 Хотел бы

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

Некоторые опускают “бы”, и получается еще хуже.
“Я хотел предложить...”
“Я хотел напомнить...”
Так предлагай и напоминай, не просто хоти.

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

​👽 О чем спрашивать на интервью

На интервью кандидату задают вопросы двух типов: «Кто ты такой?» и «Как ты решаешь задачи?»

Вопросы первого типа мы все просто обожаем:  
«Расскажите о себе!»
«Кем вы видите себя через пять лет?»
«Какие ваши самая сильная и самая слабая стороны?»
«Как вы справляетесь со стрессом?»
«Почему вы хотите работать именно в нашей компании?»

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

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

Не надо только идиотских задач типа «сколько парикмахеров в Бердянске?» или «как из пяти спичек выложить икосаэдр?» Кейсы должны быть про те задачи, которые кандидату придется решать в рабочей жизни. Вот рабочая ситуация, как вы будете действовать? А если начальные данные изменились? А вот такой конфликт как разруливать будете?  

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

А вы подумайте, не задаете ли вы на интервью дурацких вопросов.

​🎯 Ставьте задачу

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

1. Первое правило хорошо поставленной задачи — начните ее с глагола, а не с существительного.  
Плохо (отглагольное существительное):
Тестирование модуля Х.
Разработка функции Y.
Хорошо (глагол):
Протестировать модуль Х.
Разработать функцию Y.

2. Больше конкретики – конкретную задачу легче делать и проще контролировать. Задача создается, чтобы ответить на вопрос «что сделать?», а не «что делать?».
Плохо (неконкретно):
Обдумать риски в проекте А.
Наметить дальнейшие шаги в проекте В.
Хорошо (конкретно):
Составить реестр рисков в проекте А.
Создать план проекта В.

3. Каждой задаче нужен срок исполнения. Нет дедлайна — нет стимула делать. Дедлайны дисциплинируют и помогают планировать.
Плохо (нет срока):
Создать документ D.
Хорошо (есть срок):
Создать документ D к 15.12.2021.

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

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

Можете проверить по этому чек-листу задачи, которые вы ставите.

​🍰 Огилви о менеджерах проектов

Великий Огилви говорил:

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

Как он прав...)

​📞 Чтобы было кому позвонить

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

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

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

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

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

Из этой истории я сделал вывод: любой конфликт обязательно идет по нарастающей. Если первый человек начал говорить со вторым раздраженно, то второй ответит еще более раздраженно. Первый повысит голос — второй закричит. Люди получают сигнал: «Мне тоже так можно» и усиливают его.

А еще очень нужно, чтобы был человек, которому можно позвонить.
Наверное, это самое важное.

​🖥 Дистанционное

Диалог двух менеджеров:

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

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

🕹 Тренажер для менеджеров и не только 967-840

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

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

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

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