Архив за месяц: Ноябрь 2015

“Спустить на тормозах”

imageНадо было не тормозить, а на тормоз жать!

Неизвестный водитель.

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

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

На первый взгляд всё, вроде бы отлично. Если задачей никто не интересуется чуть ли не полгода, то нам-то что беспокоиться о ней? На самом деле, поведение, в большинстве случаев деструктивное. А меньшинстве случаев, мы просто упускаем возможность что-то улучшить в наших отношениях с заказчиком/руководителем. Или их мнение о нас.

Собственно, минусы этого сценария:

1) Формальный минус: эй, тебе начальник что сказал? «Разобраться с вопросом X». Или, не дай боже, «вопросом Y». Ты разобрался? Нет, ты «спустил на тормозах». У тебя нет информации, у тебя нет понимания, реально ли проблема не стоила времени, которое на неё пришлось бы потратить.

2) Реальный сценарий, который мне встречался:

· Через полгода клиент, не дождавшийся твоего письма (Ну в спам упало. Или протерял в 5000 непрочитанных писем), начинает бить во все колокола, уведомляет CEO о том, что в IT запороли проект;

· CIO грозно вопрошает «какого хрена?»;

· Ты показываешь письмо, и вроде бы даже не виноват.

Да, формально ты виноват только в п.1, а заказчик виноват кругом: это его проект, его ПМ должен всё это «пушить» и «драйвить». Проблема только в том, что проект реально не сделан, а был нужен. И заказчик, сознающий свою вину, редко станет тебе лучшим другом. И пилюлей за первый пункт всё равно тебе могут выписать (и правильно).

Что я стараюсь делать в таких случаях (не всегда получается, я же тоже человек, и не идеальный, понятное дело – простите, пацаны, если подвожу =) ):

· Любыми способами добиться от клиента определённого ответа. Написать ещё раз. Попробовать позвонить на рабочий телефон, потом на мобильный, зайти к нему на рабочее место, как только он в коммуникаторе засветится зелёным, оповестить всех людей, сидящих рядом с ним, что я его ищу, и так далее. Обычно останавливаемся максимум на пункте «позвонить на мобильный», потому что эти люди ещё ни разу на моей памяти не скрывались. Они просто теряли мои письма по какой-то причине или были настолько заняты, что не успевали на него ответить. Вру, была пара случаев, когда они были не конечными заказчиками и так же пытались спустить мой запрос на тормозах ;)

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

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

Реклама

Книга: Лайфхак на каждый день.

clip_image002

«Если вы случайно плеснули кофе на клавиатуру и несколько клавиш вышли из строя – это не повод выбрасывать ноутбук».

Авторы книги.

Если вы так делаете, не делайте больше. Что бы ни писали в книгах.

Автор блога.

Книжка от издательства МИФ в квадрате: один из авторов – тот самый Манн. Собственно, не книжка, а сборник лайфхаков, пролистать, выписать что-нибудь интересное и забросить. Наверное, с тем же успехом можно походить по сайтам лайфхакеров, только бесплатно. Хотя за книги этого издательства я и так редко плачу – почти все мне предоставляются даром, за что огромное спасибо им и моему работодателю ;)

Только по сайтам шляться мне лень, а книжка у меня была и на неё убить несколько часов не жалко. В общем, почти и нечего больше сказать, но я всё равно продолжу. Как и с любым сборником лайфхаков, часть всегда уже изобретена самостоятельно, часть получена из других источников, а часть приходится кстати. Есть, конечно, и та часть, которая, хоть и полезна в общем, но вот лично тебе не нужна от слова «совсем». Ну или вот прямо сейчас не нужна, может, когда-нибудь потребуется. Хотя в целом, всё более-менее полезное, не зря с авторами одни и те же книги читаем ;)

Есть пара моментов, которые заставили улыбнуться, например, описание техники помидора. Все её почему-то упрощают до уровня не то что карго-культа, а вообще каких-то не нужных нафиг рекомендаций, которые ни к чему путному не приведут. Хотя читали же наверняка. Ну или если из той же оперы брать привет, то «мегасовет», о вреде которого я уже писал: выполнять любую двухминутную задачу сразу же. А с фразы, вынесенной в эпиграф, хотелось уже просто ржать в голос. В России все именно так и делают, конечно, да и не только у нас =)

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

Купить:

Книга "Лайфхак на каждый день" Игорь Манн, Фарид Каримов - купить на OZON.ru | 978-5-00057-779-0 Книга «Лайфхак на каждый день» Игорь Манн, Фарид Каримов — купить на OZON.ru | 978-5-00057-779-0

Заказ на персонал.

clip_image002 «Птица счастья завтрашнего дня

Прилетела, крыльями звеня…

Выбери меня,

Выбери меня,

Птица счастья завтрашнего дня».

Песня про чайка-менеджмент (или про твиттер).

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

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

В чём же плюсы?

1) Всяко, предоставить требуемое сразу и без выпендрёжа – вполне годная стратегия в краткосрочной перспективе. И заказчика удовлетворил, и напрягаться не нужно. Если из двух абсолютно одинаковых наборов скиллов заказчик выбирает какой-то один и готов за это «платить» больше – почему бы и нет? А уж если он выбирает того, кто обладает даже меньшим набором умений, то и вовсе прекрасно ;)

2) Второй плюс… А фиг его знает. Я и придумать даже не смог. Помогите, люди добрые. Вспомнил. Дочитайте до конца, там есть.

Минусы? Тут легко, обгадить это не похвалить:

1) Ну вот реально: сегодня, скажем, ноябрь. Кто-то правда может на свою зарплату поспорить, что нужный человек к следующему июню не будет занят, не найдёт работу получше, не заболеет или вообще не станет вашим боссом? И понятное дело, что объяснить такую подставу перемену планов заказчику удастся, но есть подозрение (ничем не обоснованное), что на взаимное доверие с заказчиком это, если и отразится, то вовсе не положительным образом.

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

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

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

c. Заказчик строит своё мнение о нашем подразделении по одному человеку. Это бывает, наверное, неплохо, но что-то в этой идее мне не нравится.

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

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

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

Большие отчёты — в массы!

agenda-153555_640«Первые 90% кода отнимают первые 90% времени разработки. Оставшиеся 10% кода отнимают вторые 90% времени разработки»

А. Купер. Психбольница в руках пациентов

Я думаю, каждый, кто сталкивался с любым проектом (от ремонта, до запуска корабля на Плутон (хотя, зачем туда лететь, он же даже не планета!), знаком с подобной ситуацией:

Неделя Y проекта: осталось 3 недели.

Неделя Y+1 проекта: осталось три недели.

……..

Неделя Y+k проекта: осталось ну никак не больше трёх недель.

Ну, или вот есть две задачи. Завершённость одной – 80%. Второй – 80%. Трудоёмкость обоих одинакова. Они одинаковые? А вот фиг там. Одна из них завершится уже сегодня, вторая вообще под угрозой. Да ещё мой начальник понимает 80%, как «осталось 20% работы», а мой подчинённый, как «осталось 20% задач». А я, как типичный передаст, просто транслирую циферки.

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

· Что сделано за истёкший с последнего отчёта период?

· Каков текущий статус задачи

· Проблемы

· Что сделано в целом

· Когда планируем завершить задачу в целом

· Что делаем дальше, и когда

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

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