Работа, свежая работа!

работаВ стране кризис, а сталбыть, мы снова нанимаем ;)

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

  • Специалисты по информационной безопасности. Не администраторы безопасности, скорее, системные администраторы, увлекающиеся безопасностью, не считающие её скучной.
  • Специалист по серверному оборудованию и системам хранения (IBM, Lenovo, Cisco UCS, и так далее).
  • Люди с глубоким знанием MS SQL.
  • Администраторы общего профиля (Windows, AD, IIS, etc.). Потом специализироваться придётся, но пока как-то так.

Заниматься придётся не только тем, что я написал, но и обычным operations: релизы, изменения, поиск багов и так далее. То есть отсидеться в стиле «я управляю сиквелом, а что там в Оси происходит не знаю и нафиг мне ваш керберос не нужен» не удастся.

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

Что мы будем требовать:

  • ответственности за свой сервис и за компанию в целом. Локальные оптимизаторы и «с моей стороны пуля вылетела» нам точно не нужны.
  • Понимание потрохов Windows, сети, умение траблшутить разнообразные ошибки. Мы гордимся тем, что большая часть наших обращений в поддержку оказывается багами софта, а не нашими ошибками. «Специалисты» а-ля «а я поставил exchange в прошлой конторе next-next-next и всё работает, нафиг мне знать, что такое Hub Transport» нам тоже не нужны.
  • Неуёмное желание учиться. Это ИТ, детка. Не хочешь учиться, иди руководить, как я =)
  • Уважение к коллегам и умение решать проблемы, а не создавать их тоже необходимо.

У нас интересно, приходите ;)

Резюме и прочие вопросы слать в KLHire@outlook.com, комментарии, любые из моих точек присутствия в социальных сетях.

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

Решения, решения…

clip_image002[1](2*beer) V !(2*beer)

Уильям Шейксбир

Я не очень-то верю, что ещё существуют люди, которые не «знают», что подходящий стиль лидерства должен определяться ситуацией, в которой вы находитесь. В каких-то ситуациях руководитель сам решает, что делать дальше и снабжает своих подчинённых пошаговой инструкцией. В других – обрисовывает какого решения мы ждём, позволить команде обсудить его и принять, что они решили. А в каких-то (моя любимая ;) ) нужно просто расслабиться и не вмешиваться: они всё одно справятся лучше без твоего участия. Хых… Возможности, возможности.

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

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

В итоге, ты просто смотришь на задачу, задаёшь себе вопросы (смотри граф модели чтобы следить, как я пришёл к решению):

1) Насколько важно техническое качество решения? – не очень (то есть, low);

2) Насколько важна поддержка решения подчинёнными? – не очень (снова low);

3) Вуаля – вот мы и достигли узла «автократичное решение» модели: Лидер решает проблему самостоятельно, используя информацию, которая доступна ему.

clip_image004[1]

Рис.1: Модель Врума-Йеттона (взял тут: http://faculty.css.edu/dswenson/web/LEAD/vroom-yetton.html)

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

1) На некоторые из вопросов часть людей просто не в состоянии дать ответ «нет». Скажем, первый же: «высоки ли требования к качеству?». Да ты шутишь? Что значит «бывают ситуации, в которых высокое качество не обязательно»???!!! В мире больше перфекционистов, чем я могу представить!

2) Я не уверен, что я могу найти правильный ответ на все эти вопросы. Нет, ну правда, откуда ты знаешь, что твоё решение, если ты его примешь полностью самостоятельно, будет нормально воспринято всеми подчинёнными? Да, да, да, я знаю все эти мантры «хороший менеджер знает своих людей», но давай будем честны: люди есть люди. И они будут удивлять тебя время от времени. Ну и все остальные вопросы тоже подвержены той же проблеме: никогда нельзя быть уверенным, что твой ответ – правильный.

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

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

Вопросы:

1) Требование к качеству (QR): Насколько важно техническое качество решения?

2) Требование к приверженности (CR): Насколько важна приверженность подчинённых принятому решению?

3) Информация, доступная лидеру (LI): Имеешь ли ты информацию, достаточную для принятия самостоятельного решения?

4) Структура проблемы (ST): Является ли проблема хорошо структурированной (т.е. она ясно определена, ясна, ограничена во времени и так далее)?

5) Вероятность приверженности (CP): Если бы ты принял решение самостоятельно, достаточно ли очевидно, что твои подчинённые будут поддерживать это решение?

6) Конгруэнтность цели (GC): Разделяют ли подчинённые цели организации, которые должны быть достигнуты решением этой проблемы?

7) Конфликт подчинённых (CO): Вероятен ли конфликт между подчинёнными по вопросу предпочтённого решения?

8) Информация подчинённых (SI): Имеют ли подчинённые достаточно информации для принятия высококачественного решения?

Модели:

Стиль принятия решений Описание
Autocratic l (Al) Лидер решает проблему самостоятельно, используя информацию, доступную ему.
Autocratic ll (All) Лидер получает дополнительную информацию от членов группы, потом принимает самостоятельное решение. Группу можно уведомлять или нет.
Consultative l (Cl) Лидер делится проблемой с членами группы индивидуально, запрашивает информацию и оценку. Члены группы не встречаются все вместе, и лидер принимает решение самостоятельно.
Consultative ll (Cll) Лидер делится проблемой со всей группой, но принимает решение самостоятельно.
Group ll (Gll) Лидер встречается с группой, чтобы обсудить ситуацию. Он фасилитирует обсуждение, но не навязывает свою волю. Группа принимает финальное решение.

Отчёт vs. таск-трекер

clip_image002Тут в комментариях к одному моему блогу был микрообмен мнениями по вопросу замены отчётов таск-трекингом. В целом я и сам с удовольствием бы избавился от отчётов и даже сделал так однажды без особого вреда для дела. Какое-то время перед очередным повышением, с инженеров отчёт я собирал только по отдельным проектам и голосом (если попутал, пусть ребята поправят). Сначала на планёрке, а потом и вовсе в режиме «привет, как дела» (мне кое-кто сказал, что отчёт на планёрке напрягает. Спасибо, кое-кто ;) ). То есть отчёт в виде большой простыни в этой команде писал только один человек – я.

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

Мысль №1: задачи, они мелкие. Ну там поставить сервер, настроить роль, изменить настройки, расследовать инцидент. То, что подавалось от меня наверх, оно, хоть и задача, но выглядит уже совсем по-другому: создать новый экземпляр сервиса Х. Обеспечить телефонной связью офис Y.

Мысль №2: задачи, как таковые, вообще никого не интересуют. Вот такое вот откровение. Простите, друзья-инженеры. Но наше с вами «мы установили обновления на систему Z» вообще никому не интересно. Подозреваю, также, что моё «Обеспечить телефонной связью новый офис» тоже через пару уровней управления уже не интересно. И точно знаю, «создан новый экземпляр такого-то сервиса» не интересен уже даже мне – всего-то руководителю отдела.

Мысль№3: а вот бы инженеры писали так, чтобы было интересно даже генеральному. Хых… Мечты.

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

Получается, что основных направлений работы два:

1) Сделать так, чтобы каждое нижестоящее звено писало Эзоповым слогом так, как нужно следующей ступени управления. Я вот учусь. Тяжело даётся. Но оно того стоит.

2) Делать так, чтобы отчётов было не нужно. Но вот тут я вообще пока не продвинулся. Я слышал идеи вроде холакратии, но пока не видел вживую ни одной более-менее крупной организации, где это бы работало у меня на глазах (чем там дело в Кнопке закончилось, BTW?). И тем более, есть сомнения, что холакратию можно построить в отдельно взятом подразделении большой компании. Может, я заблуждаюсь? Расскажете?

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

· Какое конкретно направление перегружено?

· Насколько?

· Как долго это потенциально будет продолжаться?

· Нужно ли бежать и предупреждать всех заинтересованных, что все SLA поползут или это просто флуктуация и можно пока не беспокоиться?

В общем, тоже очень нужная штука. У неё ещё много применений. Но вот отчёты по ней строить у меня не получается. У кого получается, делитесь, как делали. (товарищ kabal375 уже поделился парой примеров. Спасибо, буду думать).

Книга: Не работайте с мудаками.

clip_image002

«У всех есть своя история о мудаке Стиве Джобсе»

Из книги.

В оригинале assholes, на обложке «м*даками». Хотя зачем «запикивать» это слово на обложке, если в книжке на каждой странице оно случается не раз и не два? Если вся книжка про них, про очередные деструктивные наклонности. Но это детали. Главное: не работайте с мудаками. И не будьте ими сами. Это тоже важно.

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

Для создания безмудачных организаций автор предлагает 10 шагов, которые вполне разумны, только выполняют их далеко не все. А жаль, я за последние 8 лет оценил работу в компании, где почти нет этих «прелестных» людей, и уж вовсе мало тех, у кого есть сертификат. Впрочем, я не обладаю Козлометром Анмола Мадана из MIT, который с коллегами создал продукт (жаль, не продающийся), способный определить, что одна из сторон, участвующих в телефонном разговоре, мягко говоря, неправильно себя ведёт, так что мои измерения ненаучны.

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

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

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

Легко ли читать: легко. Я не уверен, что перевод полностью качественный и все концепции переводчиками переданы правильно (Brutal bosses and their prey = Брутальные боссы и их жертвы, ага ;)), но читается хорошо.

Ну и да, будьте няшами. ;)

clip_image003

Книга "Не работайте с м*даками. И что делать, если они вокруг вас" Роберт Саттон - купить на OZON.ru книгу The No Asshole Rule: Building a Civilised Workplace and Surviving One That Isn't Не работайте с м*даками. И что делать, если они вокруг вас с доставкой по почте | 978-5-00057-617-5 Книга «Не работайте с м*даками. И что делать, если они вокруг вас» Роберт Саттон — купить на OZON.ru книгу The No Asshole Rule: Building a Civilised Workplace and Surviving One That Isn’t Не работайте с м*даками. И что делать, если они вокруг вас с доставкой по почте | 978-5-00057-617-5

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

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