Глупые мысли об IT

Привет, народ!

Время немножко оживить блог :) В основном я активен на персональном блоге, сюда как-то перестал писать. Но сейчас хочу поделиться своим необычным опытом – с другой стороны поиска работы.
Так получилось, что я сейчас помогаю своему менеджеру нанимать новых сотрудников в отдел. Решение о найме, конечно же, принимаю не я, но моя рекомендация учитывается в конечном решении.
Что меня поразило: оказывается, очень тяжело найти людей с нужными знаниями и опытом в пределах разумной заработной платы. Естественно, если искать кандидатов на зарплату в £1,000,000 в год, то найти их будет легко :), но не каждая компания может это себе позволить. Мы тоже пытаемся “нащупать тонкий баланс” между зарплатой, которую мы обещаем и положением на рынке труда. Скажем так – наше предложение в плане денег имеет большой диапазон, но в целом выглядит вполне разумным.
Несмотря на это, КПД процесса крайне низок:

• За два месяца мы провели телефонные интервью со ~150 кандидатами и с теми, кто прошёл его, персонально встречались или общались через Skype for Business. Результат: предложили позицию 5-ти(!) кандидатам, из них 4-ре приняли предложение о работе. Т.е. “выход” ~3%. И это не считая отдела кадров, которые “просеивали” первичные резюме;
• Среднее время, затраченное на телефонное интервью – ~30 минут;
• Среднее время на второе интервью либо при личной встрече, либо через Skype - ~1 час.

Можно легко посчитать трудозатраты на этот процесс, принимая во внимание то, что телефонное интервью проводит один человек, а второе – три (менеджер и два технических специалиста). Только “прямые расходы” на одного человека могут достигать ~£1,000! Это наше суммарно затраченное время, переведённое в фунты.
Что я для себя выяснил, потратив кучу времени на интервью:

• Абсолютно необходимо интервью первого уровня (по телефону), главной целью которого будет выяснить, насколько соискатель “приукрасил” свои знания и умения в резюме и отобрать кандидатов на второй уровень интервью. Если подходить формально и отбирать на основе резюме – куча времени будет тратиться впустую на кандидатов, не соответствующих требуемому уровню (“Все врут”);
• Задача второго интервью – узнать уровень технических знаний кандидата, понять, насколько он может “вписаться” в команду и перспективы роста будущего специалиста. Может случиться, что человек понравился, но на именно “эту” позицию он или она сейчас не “тянет”, но есть потенциал и кандидата можно всё-таки можно взять с “прицелом” на будущее.

Вы не поверите, но около 60%-70% телефонных интервью заканчивались тем, что я не рекомендовал дальше связываться с кандидатом. В основном преувеличивалось участие и роль в проектах. Например, в резюме было указано, что человек мигрировал Exchange в Office365, а на самом он просто “нажимал кнопки” на портале. Некоторые настолько злоупотребляли “фильтром-бьютификатором”, что практически всё в резюме оказывалось неправдой. Один человек прислал такое резюме, что я сказал своему начальнику: “Либо он немеряно крут, либо отчаянный врун”. Последнее оказалось истиной :). Верите ли, но в резюме был указан опыт программирования на C++/C# и когда я его попросил рассказать об этом подробнее, парень мне сказал, что он создал портал на GitHub для разработчиков, а потом сидел рядом! К коду его не пускали! Т.е. он “сидел там, где курили” и далее по смыслу :)
Как я проводил телефонное интервью: сначала просил рассказать о себе, чтобы немного расслабить и разговорить человека. Спрашивал о хобби и других вещах, не связанных с работой. Потом расспрашивал о проектах, в которых кандидат принимал участие. Главные вопросы при этом – “Какая Ваша роль была в этом проекте?”, “Чем конкретно Вы занимались?”, “Какой был результат Вашей работы?”. Как правило, уже на этом этапе можно было почувствовать насколько резюме соответствует или не соответствует реальному положению дел. Дальше я спрашивал технические вопросы, для ответа на которые достаточно концептуальных знаний о технологиях, ничего сложного. Например, какие есть опции миграции Exchange в Office365. Но даже на таком типе вопросов люди “зарывались”. Один сертифицированный специалист в Azure не смог мне назвать, какие есть варианты сетевого подключения серверного центра (ЦОД) к Azure. Как я уже сказал, вопросы были вполне базовые, я не собирался делать людям “больно”, просто надо было отсеять “левых” кандидатов :)
“Больно” мы соискателем делали на втором интервью :) Здесь важно было проверить технические знания, опыт работы и подход к решению различных проблем. Иногда интервью превращались в цирк: некоторым людям удавалось “уболтать” интервьюера во время телефонного интервью и выйти на второй раунд, но при “перекрёстном допросе” двух технических специалистов они начинали эпически “сыпаться”. Пример из жизни: когда человеку объяснили формат интервью, он тут же испуганно заявил, что не рассчитывал на это! В дальнейшей беседе оказалось, что он не был архитектором решений, а просто руководил проектами, поэтому технических знаний он не имеет. Когда же его спросили, почему в резюме у него написано, что он эксперт в “…” технологиях, а так же был вовлечён в “архитектуру, дизайн и внедрение” кандидат ответил, что это перепутали в агентстве и нам выслали неправильное резюме. Мы попросили прислать “правильное” резюме и больше от этого человека мы ничего не слышали :)
Подход к второму интервью зависел от того, искали ли мы инженера или архитектора. Для инженера задавали больше вопросы по технологиям, больше углублялись в тонкости программных продуктов. В случае архитекторов я предпочитал интервью проводить основываясь на каком-то сценарии: проблема, требования бизнеса, функциональные и не-функциональные требования – вперёд! Естественно, не существует одного правильного решения, задачей было понять, насколько кандидат соответствует позиции: как он подходит к решению проблемы, учитывает ли все требования, какие варианты предлагает (если предлагает вообще), как отвечает на вопросы и т.п. Архитекторы в нашей департаменте общаются с клиентами, поэтому умение правильно изложить свою точку зрения очень важно. Технические знания, с моей точки зрения, здесь менее важны по сравнению с подходом к решению проблемы. Я рекомендовал несколько людей основываясь именно на этом, несмотря на то, что технически они были ограничены в знаниях чисто своими позициями на текущей работе. Нельзя требовать от человека глубоких знаний продукта если он занимается поддержкой инфраструктуры (BAU).
Как правило, процент положительных отзывов после второго уровня интервью выше (~40%-50%), но после этого начинается “торговля” с отделом кадров о зарплате и на этом этапе очень много людей решает отказаться от позиции. Некоторые “просят” слишком много и мы сами им отказываем. Печально. Изначально мой менеджер планировал набрать в отдел около 20 человек, сейчас мечтает, чтобы удалось нанять 10 :))

Засим раскланиваюсь,
Рустам.

Привет, народ!

Не уверен, писал ли я на эту тему или нет, но мне кажется она важной: как документировать проблемы при работе над проектом. Формально - это одна из обязанностей менеджера проектов (МП), технический специалист (ТС) не должен вести подобного типа документацию. Но иногда бывает, что МП по каким-либо причинам этого не делает, поэтому я самостоятельно начинаю документировать различные проблемы для своей же безопасности.
Не секрет, что часто большие проекты не всегда идут гладко: то возникают какие-то проблемы (в худшем случае – проект приходится закрывать), то происходить выход за границы бюджета, либо отставание по срокам. Вот тут-то начальство и другие люди, участвующие в проекте, начнут искать, на кого “повесить всех собак”. Как раз для эти случаев у меня наготове обычно два документа: “Incident log” (“журнал проблем”) и “Lessons learnt” (“выученные уроки”). Сразу же подчеркну: содержание этих документов должно “тонко подстраиваться” под каждую конкретную ситуацию! Т.е. то, что с вас потом будут спрашивать. Вы сможете потом подтвердить документально все факты и так же их “количественные” и “качественные” характеристики.
По моему опыту, в случае проблем/инцидентов всех интересуют следующие вещи:

1. Когда это произошло. Если проблема не решается быстро, надо знать, как долго она тянется. Либо, если решение проблемы не зависит от вас, как долго вы ждёте действий от кого-то другого;
2. Относится это напрямую к области вашей ответственности или нет. Вполне возможно, что кто-то “спихнул” проблему на вас и вы кучу времени потратили на “разруливание ситуации”, на которую вы не должны были тратить время. Но это же забирает время и ресурсы!? Такая классификация позволяет в дальнейшем доказать, что задержки были вызваны не непосредственно вашими действиями, а внешними факторами. Из последнего моего проекта 11 из 23 проблем не относились к тем изменениям, которые я и моя команда сделали. Порядка 55 часов было потрачено, чтобы решить проблему и доказать, что она возникла не из-за нас. Это огромная цифра;
3. Краткое описание ситуации и проблемы – тут важно правильно всё написать, чтобы потом избежать “переопределения” ситуации и разговоров о том, что было “это”, а не “это”;
4. Влияние на проект (“критическое”, “среднее”, “малое”, “незначительное” и т.п) – для установки приоритетов для решения проблем;
5. Влияние на бизнес (“критическое”, “среднее” и т.п.) – иногда вышестоящие менеджеры не в курсе, насколько значительно происшествие. Категоризация позволит избежать “получения по шапке” за малозначимое событие;
6. Статус инцидента – “закрыт” или всё ещё “открыт”;
7. Причина/что вызвало происшествие – краткое описание как можно в более простых терминах причины события. Более детальная и “техническая” информация заносится (так, по крайней мере, я делаю) в другой документ – “Lessons learnt” (“Выученные уроки”). Об этом чуть позже;
8. Сколько времени потребовалось на диагностику причин проблемы, причём это не включает в себя время, потраченное на устранение. Во время последнего проекта это время колебалось между 1 часом и 1 днем. Суммарно потратили 152 часа (на все инциденты), среднее время для нахождения причины – 7 часов. Это время надо учитывать особенно в том случае, если проблема была вызвана не вами. А вот решение проблемы может практически и не занять много времени;
9. Время, потраченное на устранение инцидента и его последствий – максимально точное время потраченных усилий. Опять же, из последнего проекта – 39 часов суммарно, 2.5 часа в среднем на проблему. Разница существенная между диагностиком и устранением. “Дельта” показывает начальству, куда ушло время. Особенно, если оно было зря потрачено на “бодание” между различными командами. В нашем случае так часто и было;
10. Действия, предпринятые для устранения проблемы в короткий срок – что было сделано, чтобы вернуть какой-либо сервис в нормальную работу. Вполне возможен “костыль”, если надо что-то сделать очень быстро. Но это должно быть описано и задокументировано. Инцидент может быть не закрыт, если бизнес не удовлетворён решением проблемы;
11. Действия для недопущения проблемы в будущем. В отличие от предыдущего пункта, после этого инцидент можно формально будет считать закрытым.

Как я уже сказал, содержимое этого документа определялось вопросами от вышестоящего начальства по поводу проблем в процессе внедрения проекта. Вполне возможно, что что-то можно добавить, а что-то можно удалить. “Документ” – понятие вполне “живое” содержимое может меняться со временем.
По п.11: в него можно добавлять ссылки на документ “Lessons learnt”, но об этом чуть позже.

Засим раскланиваюсь,
Рустам.

Привет, народ!

Недельки две назад “добил” последний экзамен на гордое звание MCSE: Windows Server 2012. Я решил сдать этот экзамен за день отъезда в командировку, поэтому пришлось срочно искать центр тестирования у которого была свободна эта дата. Немного пострадал из-за доверия к MS: когда я выбирал экзамен, мне было сказано, что этот экзамен доступен для сдачи издому! Т.е. запускаешь у себя на компьютере программу, которая мониторит тебя через вебкамеру и микрофон и сдаешь себе экзамен в тепле и уюте домашней обстановки. Поэтому я и не торопился с датой. Но когда уже начал записываться на экзамен, то получил дулю в виде сообщения, что в моей стране опция домашней сдачи недоступна. Из-за этого и была вся чехарда и спешка. Для меня в пределах доступности был только один центр тестирования в Рединге. Меня удивило, что в нём была куча свободных слотов. Но когда добрался к этому центру, я понял, что это не учебный центр, а так, пара классов для сдач экзаменов. Там даже £1 пытались брать за посещение туалета, но я их обманул :)
Сам экзамен, как мне кажется, будет немного легче 70-413. Может быть, из-за того что сетевым вопросам (RRAS, NPS и т.д.) почти не уделялось внимания. Основной упор: кластеры, виртуализация, т.е. высокая доступность серверов и восстановление после сбоев. Формат такой же, как и в 70-413: дается сценарий, потом шесть вопросов. Затем совершенно другой сценарий и вопросы. После может идти пачка вопросов с выбором ответа из списка. Основная сложность экзамена – в количестве информации в сценариях и неоднозначности. Мне кажется, что в некоторых вопросах возможно было выбрать два правильных ответа. Например, было сказано, что у компании есть два главных серверных центра и два резервных. В главных развёрнуты Hyper-V кластера. Надо развернуть серверы для приложения. Где это сделать? Я долго мучился с выбором, просто не видел разницы между главными центрами. Судя по баллам, которые я набрал, отвечал я правильно. Может, мне повезло и я угадал в некоторых местах. Но набрал я 833 балла из 1000 при проходном 700. Сам удивился :)
А теперь я готовлюсь сдать два экзамена на MCSE Desktop. Честно – сам не понимаю, когда это закончится. Я уже даже не надеюсь обновить VCP и CCEA, мне бы успеть обновить сертификацию MS до того, как снова выйдут новые версии :)

Засим раскланиваюсь,
Рустам.