Для большинства Microsoft – это “Гигант из Redmond”, компания, которая производит windows/office, в которой работают одни программисты. Для более ITшных товарищей лицо Microsoft — это бывшие евангелисты Microsoft, рассказывающие со сцены о прекрасном мире. Для кого-то этим лицом являются Microsoft Student Partners в своих вузах, коим и я когда-то давно был. Но среди этих лиц есть такое, которое видит очень ограниченный круг.

Вы, конечно, можете найти официальное объявление о работе Premier Field Engineer с официальными требованиями. Может, даже нагуглите что-нибудь, но я буду рассказывать так, как я бы сам себе объяснял что делаю. Я проработал 4 года в роли Premier Field Engineer по разработке (Development) по большей части из Москвы и т.к. на мое место сейчас ищут замену, то решил рассказать про работу PFE.

Всем, кому интересно, читаем ниже.

Начать надо с того, что в Microsoft далеко не все сотрудники — программисты и далеко не все работают в Redmond. Есть много персонала, который отвечает за продажи на местах. А еще есть много людей, которые занимается поддержкой тех, кто что-то у Microsoft купил. Я работал в организации, которая на верхнем уровне называлась Enterprise Services. В ней 3 больших блока: Consulting (ребята, которые делают проекты), Reactive Support (те, кто получают запросы на support и отрабатывают, когда все уже плохо. Support Engineers) и мы – Premier Field Engineers, которые были посередине (посередине – не значит, смесь ежа с ужом.).

PFE (как и остальные) – это те люди, с которыми 99% компаний в реальной жизни никогда не встретятся, т.к. компании нужен контракт Premier support (максимально высокий уровень поддержки, который есть очень мало у кого). Когда Вы звоните активировать windows – это совсем другой уровень support. Если вам не ответили по поводу блокировки учетной записи Skype – это тоже не мы. Даже когда Вы компания Microsoft Partner – это тоже, скорее всего, никак не связано с PFE/Premier Support.

Что делают PFE

Они выполняют много разных задач в диапазоне между большими проектами (которые делают в консалтинге) и когда все уже горит и тушить надо прямо сейчас (то, что делают Support Engineers), хотя иногда участвуют и в вышеперечисленном. При этом PFE инженеры хоть и привязаны к стране, но могут быть в командировке во многих других странах. Об этом я еще расскажу ниже на примерах из личного опыта.

Давайте перечислять что обычно делают PFE:

• Assessment реализации решения на базе продуктов Microsoft. Т.е. компания внедрила условный SharePoint, но что-то он часто ломается. Инженеры приходят, смотрят, собирают данные и рассказывают что и как надо было делать по-другому, а потом пишут план как это делать.
• Работают в качестве DSE (Designated Support Engineer – выделенный инженер), т.е. человек ходит к Вам офис и делает практически любую работу по продуктам Microsoft, которые есть в компании.
• Починка-конфигурация, когда системе уже плохо, но еще не все умерло (если сравнить с медициной — это помещение в стационар, а не срочная реанимация)
• Чтение тренингов, которые входят в портфолио Premier Support.
• Много разных других задач, которые очень сильно зависят от Domain.

PFE – это высоко квалифицированный инженер со многими годами опыта работы со своей технологией.

Кто такие PFE Dev

Только что я упомянул слово Domain. Domain- это организация внутри сервисной организации, которая объединяет инженеров по сходным технологиям и направлениям. Пару примеров: все инженеры по Windows Platform сведены в домен Secured Infrastructure; инженеры по Skype for Business и Sharepoint/Exchange сведены в домен Business Productivity; товарищи по SQL сведены в домен Data&AI.

А есть еще мой Domain – это Applications (сначала он назывался Modern Apps, но его решили-таки переименовать в просто Apps). Для каждого домена есть свои уникальные работы, которые делают только они в дополнении к assessments/чтению тренингов/DSE и т.п.

• Ну, например, Code Review. Его, конечно, можно сделать и для Sharepoint и в Dynamix CRM/Axapta и это будет в компетенции других доменов, но просто code/architecture review приложений на .net – это все к PFE DEV.
• Можно Proof Of Concept сделать – это когда силами Microsoft делается мини пилот и на выходе получается пример кода, который показывает, как такой проект делать в принципе на технологиях Microsoft (но не production ready код).
• Ну и, конечно же, разработка под Microsoft Azure – это тоже к нам, хотя частями лежит в других доменах.

Таким образом, PFE Dev – это инженеры-разработчики умеющие писать код, читать код, критиковать код, говорить как надо, дебажить приложения, читать тренинги и т.п.

Что не делают PFE DEV

• PFE DEV не самый дешевый ресурс, поэтому забивать гвозди им не надо. Написать простенький вебсайт-визитку — это точно без PFE DEV.
• Плохо работает VBS в Excel 2003 – тоже мимо.
• Помочь с Java на Linux? Ну, только если это все в Azure ;)
• Разработка больших проектов — если Вы не знаете, куда девать деньги, то можно попробовать. Но в целом, PFE DEV такое не делают, и надо идти в консалтинг или к кому-нибудь попроще.

Какие навыки важны для PFE (PFE DEV)

Я бы назвал PFE – фрилансеры с бейджиками Microsoft, т.к. требования к личным качествам примерно такие же, как у фрилансеров.

• Самое важное — это быть экспертом в своем деле. Эксперт чего-то может не знать, но должен понимать куда копать.
• Человек должен быть самоорганизованным и самостоятельным. Нужно самому про себя рассказывать внутри организации, самому следить за своим рабочим временем (и отдыхом тоже), самому заботиться о своих навыках-знаниях и их актуальности-релевантности и т.п.
  
  
  • Мои менеджеры последние 2.5 года были вне России (Дубай, Лондон, Анкара), у них куча народу в подчинении и заниматься babysitting с Вами никто не будет.
  • Вы знаете технологию А, но ее выводят из эксплуатации — это Ваша задача научиться чему-то новому и востребованному. Востребованность важнее, чем новизна. Вы не востребованы — у менеджера не будет долго голова за Вас болеть.
  • Хотя Microsoft организует обучение своих инженеров, и я, например, ездил в Redmond к Jeffry Richter по Azure Service Fabric, не надо ждать что вас 1.5 года будут учить перед первой поездкой к клиенту (лица убраны, т.к. чужую privacy надо уважать).
  
  
• Знание английского – тут все понятно
  
  
  • Хотя если работать только в России с местным менеджером, можно и не разговаривать, а только читать-писать.
  • Но если захотите поехать в командировку тренинг почитать – тут нужен именно разговорный.

С другой стороны, я бы сравнил работу PFE с работой такого компьютерного персонажа как Hitman. (Вот вам фотография цели, примерные координаты цели, вот вам неделя на работу. Остальное на ваше усмотрение.) У PFE есть примерное описание задачи, есть адрес клиента и его контакты, есть неделя (бывает больше или меньше) на проведение работ и может быть немного времени на подготовку. Не успел за неделю — плохо (тут много вариантов от доделывание в авральном режиме до переноса на следующий визит), не знаешь, как делать задачу — плохо (но всегда можно от такой отказаться).

Личный опыт

Меня позвал хороший знакомый, который сам уходил в google. Но не надо думать, что это междусобойчик, т.к. все процессы типа background check, техническое интервью или interview на английском будет нужно пройти. Лично я пришел за месяц до своего 25летия, года через 2.5 после формального окончания вуза (хотя работать программистом начал официально еще с 3 курса, поработав в известных компаниях). Я был одним из самых молодых PFE в России (мои коллеги в России меня лет на 5-15 были старше) на тот момент, а уж на фоне среднестатистических (50летних) PFE из Италии, так вообще казался просто ребенком, хотя в данном случае возраст коррелирует с опытом не линейно.

Командировки

За свои 4 года, я побывал по работе во многих странах и городах.

• UK/Германия/Франция/USA на обучение
• На работах бывал в Албании, Болгарии, Бельгии, Чехии, Польше, Румынии, Латвии, Эстонии, Финляндии, Казахстане, Армении, Азербайджане, Грузии, Саудовской Аравии, Сербии, Дании, Украине, Беларуси, Кипре (вроде никого не забыл).
  
  
  
  Если перечислять по городам, то сильного длинный список получится, но, понятное дело, в основном в столицах.

Хотя, если добавить удаленную работу, то можно, наверное, всю Европу закрасить и весь богатый Ближний Восток.

Были предложения поехать в командировку в Афганистан, Нигерию, Норвегию, Швецию, Фарерские острова, Египет, Иорданию, Алжир. Но где-то я не захотел, где-то не сложилось. Мои коллеги были и в Пакистане, и в Центральной Африке, и даже в Малайзии кто-то был. Про набор мифов, которые могут сложиться по поводу командировок я расскажу в отдельной статье.

Проекты

Я прочел много тренингов по Веб-разработке на asp.net/asp.net core, по разработке под Azure и инфраструктуре в ней; провел какое-то количество debug session и даже code review; писал и дописывал материал тренинги, которые потом другие pfe читали по всему миру; написал прототипы с десятка систем; помогал строить процессы работы в Azurе; занимался технически presale и т.п. Но важно понимать, это опыт лишь одного из 4 инженеров в нашей команде. Опыт остальных 3 — совершенно другой, я с ними по технологиям почти не пересекался, как и по типам активностей (ну не умею я читать тренинги по windows kernel debugging)

В общем, много чего интересного, но сейчас 90% проектов я даже не вспомню, т.к. проекты обычно недельные, а за 4 года – это 100+ разных работ (это не я не умею умножать, это поправка на проекты, которые делались более недели).

При этом я многому научился за эти 4 года. Из самого понятного — до MS слово debugging у меня ассоциировалось с Visual Studio и browser dev tools, и я считал себя неплохим специалистом, а после — уже скорее с windbg/perfview/perfmon/wireshark и я считаю, что сейчас про debug мало чего знаю.

Мой вывод: если Вы чувствуете себя достаточно опытным в разработке на платформе Microsoft, при этом дисциплинированны, готовы к самообучению и к командировкам — можно подавать резюме на роль PFE DEV. Это первая позиция за 4 года в России в PFE DEV и когда откроется следующая — вопрос нетривиальный. По всем вопросам пишите stasus, он взял на себя эту ношу.

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

P.S. По поводу финансовых условий – все мы подписываем NDA, который покрывает много чего.

P.P.S. Вопрос «почему ушел и куда?» Я бы переформулировал так: не ушел из Microsoft, а пришел в EPAM в роли Solution Architect (Azure/Microsoft Stack). Почему? Краткий ответ — в EPAM предложили хорошие условия и интересные задачи, а в Microsoft RUS я достиг своего потолка. Развернутый ответ с анализом всех вариантов у меня занял 10 страниц текста в Word. Не думаю, что его стоит сюда публиковать.

Напоследок, хочу рассказать о некоторых распространенных мифах и непонимании, которое образуется после рассказов о работе PFE.

Выделено в отдельную статью, т.к. текста там в 2-3 раза больше.