Педиатр-программист: Как я попал в Майкрософт | " Работа в Майкрософт Бинг изнутри", часть 7 из 7 (пост 2)
Часть 1:
Часть 2:
Часть 3:
Часть 4:
Часть 5: Интервью
Часть 6: Практика в Майкрософт Бинг в Сан-Франциско
Часть 7: Работа в Майкрософт Бинг изнутри (пост2) (пост3)
Для связи используйте мой ник здесь и Гугл.
---------
Если ты вынужден прийти на работу позже, сделать паузу, чтобы сходить к врачу или в какое-то учреждение, уйти пораньше, или просто хочешь сегодня работать из дома, то важно до начала рабочего дня прислать короткое письмо менеджеру и команде, где ты об этом пишешь. Объяснять причину в нашей команде не нужно, достаточно просто сказать «буду к 12 часам» или «работаю из дома, с10 до 12 буду в клинике делать прививки» и все. За все время работы никаких документальных подтверждений того, был ли я в клинике, от меня никто не просил, хотя в больнице каждый раз формально спрашивают – вам нужно подтверждение для работы – и я каждый раз его беру (раз дают).
За этой большой свободой, однако, стоит и большая ответственность. К примеру, недавно у нас администраторами было сделано некоторое изменение в групповых политиках. Это изменение привело к тому, что часть серверов перестала быть видимой в локальной сети, что привело к нарушению работы порядка 40 из 80 наших серверов. К сожалению, проблема была замечена одним и пользователей только ближе к вечеру, по крайней мере именно в 9 часов я получил письмо с проблемой. Пользователь сначала пытался решить проблему сам (он сам старший разработчик, «пользователем» для меня он является только в контексте того, что он использует нашу систему для своих задач), и он даже смог решить ее для своего компьютера, но из-за небольшого бага все-таки был вынужден обратиться ко мне, как ответственному за работу всей системы. В результате с 10 вечера (когда я добрался до компьютера и смог войти в систему) до примерно двух часов ночи, когда я написал автоматический скрипт, анализирующий проблему на каждой из наших машин и переписывающий ряд конфигураций для того, чтобы решить эту проблему, мне пришлось работать внепланово. Подобного рода проблемы случаются обычно раз в 2-3 месяца, один раз мне даже пришлось проработать всю ночь и лишь в 6 утра я смог немного поспать перед новым рабочим днем. Зато пользователи, пришедшие на работу к 8-9 утра, могли работать без проблем и практически не заметили нарушения работы системы, что длилось почти 12 часов…
Выбор задач, над которыми ты работаешь, определяется тобой совместно с менеджером. Менеджер обычно выполняет роль «заказчика», составляя требования к тому, что должно быть сделано. Однако эту роль он играет либо в новых проектах, либо на начальных этапах, когда разработчик присоединяется к команде, работающей над существующим проектом. По мере набора опыта и изучения проекта ты становишься все более и более автономен, сам определяя, что является наиболее важным в текущий момент времени, а также составляя список задач и функционал, который нужно добавить или улучшить в средней и длительной перспективе.
Обычно раз в неделю менеджер неформально приходит к тебе в офис, чтобы спросить тебя о том, чем ты сейчас занимаешься и что примерно следует ожидать по итогам работы на этой неделе. Это не какое-то официальное мероприятие, и иногда оно длится просто секунд 20-30. Иногда же, бывает, ты сидишь по 4-5 часов с менеджером, защищая своё решение и обсуждая возможные за и против. При этом менеджер, если он предлагает какое-то решение, также старается технически обосновать свой выбор. Практически не бывает случаев, когда менеджер пытается навязать тебе решение без достаточного его обоснования и обоюдного согласия о том, что данное решение является лучшим. Однако даже это случается не часто, обычно предложенное тобой самим решение – если оно достаточно разумно и воплощаемо в жизнь – просто принимается без слов и критика идёт в основном деталей реализации или архитектуры.
Менеджер ни в коем случае не контролирует твою работу. То есть даже будучи на рабочем месте, ты не должен все время изображать бурную рабочую деятельность. Достаточно, чтобы ты решал поставленные перед тобой задачи в определенные сроки: то есть если задача стоит ASAP (as soon as possible), то предполагается что ты безотлагательно решаешь задачу пока е решишь. Но в большинстве случаев ты просто должен сделать что-то к концу месяца или недели. Поэтому сотрудники без проблем общаются из офиса по Скайпу с родными, совершают какие-то краткие поездки в магазин (если нужно), пишут что-то в социальные сети. Однажды я случайно открыл фейсбук (я там вообще редко бываю с работы, а тут просто ссылку прислали) и тут же зашел мой менеджер что-то обсудить. Увидев фейсбук, он сказал «а, Алекс, я не знал что ты отдыхаешь» и тут же вышел. Я даже ничего сказать не успел от неожиданности.
Примерно раз в неделю у нас проходит встреча всей команды, где обсуждается чей-то проект. Обычно здесь члены команды показывают, чем они заняты в настоящий момент или что было сделано в последние две-три недели и один-два проекта обсуждаются более подробно, с возможными вариантами решения. Тут также обсуждаются и темы, не имеющие непосредственного отношения к работе – кто какие доклады видел недавно, кто что интересного нашел в сети, что-то из внутренних новостей компании и прочего.
Кроме основного проекта есть возможность работать над хобби проектами. Для этого в один из дней недели (обычно вторник или среда) проходит так называемая SLC (Stay Late and Code, «останься допоздна и программируй»), где встречаются люди с хобби-проектами и вместе сидят, работая над проектами и помогая друг другу. Часто в начале таких встреч проходят короткие доклады на новые интересные темы, например, о трехмерной печати.
Где-то раз в полгода необходимо делать доклад о своей работе на внутреннем семинаре. Обычно это происходит после достижения важного срока сдачи, когда новые функции и возможности уже доступны командам, но они о них еще не очень много знают. Целью таких докладов является повышение видимости проектов (чтобы соседние команды знали, над чем ты работаешь) и их использования (часто одни и те же задачи возникают в разном виде в командах, работающих над сходными проблемами).
Существует также формальный процесс оценки, выражаемый в регулярном заполнении специального формуляра, где ты описываешь, что тобой сделано из ранее запланированного, что запланировано дальше и что стоит изменить на основании полученных результатов. Менеджер добавляет свои комментарии по каждому из пунктов и визирует текст, который становится формальным требованием к тому, что нужно выполнить и как в данной итерации.
Раз в год, для определения бонуса, возможного повышения зарплаты и повышение в карьере этот процесс еще более формализируется, тогда к нему подключаются те люди, что работают с тобой. Здесь уже происходит более детальный анализ того, насколько твоя работа полезна для все команды, насколько просто и эффективно работать с тобой внутри команды и другим командам и по итогам собранных оценок (от членов твоей команды и представителей других команд, что работают с тобой) менеджер решает, какой бонус (=премию) ты получишь и стоит ли тебя сейчас повысить или не стоит.
В любой момент ты можешь перейти в другую команду. Для этого нужно только согласие другой команды принять тебя. Внутри компании есть портал, где публикуются объявления о различных интересных вакансиях, и ты можешь подписаться на новые вакансии, которые соответствуют твоим критериям. Я, например, подписан на вакансии, связанные с работой с F# и каждую неделю получают отчет о новых вакансиях где встречается это ключевое слово.
(Окончание в третьем посте)
Часть 2:
Часть 3:
Часть 4:
Часть 5: Интервью
Часть 6: Практика в Майкрософт Бинг в Сан-Франциско
Часть 7: Работа в Майкрософт Бинг изнутри (пост2) (пост3)
Для связи используйте мой ник здесь и Гугл.
---------
Если ты вынужден прийти на работу позже, сделать паузу, чтобы сходить к врачу или в какое-то учреждение, уйти пораньше, или просто хочешь сегодня работать из дома, то важно до начала рабочего дня прислать короткое письмо менеджеру и команде, где ты об этом пишешь. Объяснять причину в нашей команде не нужно, достаточно просто сказать «буду к 12 часам» или «работаю из дома, с10 до 12 буду в клинике делать прививки» и все. За все время работы никаких документальных подтверждений того, был ли я в клинике, от меня никто не просил, хотя в больнице каждый раз формально спрашивают – вам нужно подтверждение для работы – и я каждый раз его беру (раз дают).
За этой большой свободой, однако, стоит и большая ответственность. К примеру, недавно у нас администраторами было сделано некоторое изменение в групповых политиках. Это изменение привело к тому, что часть серверов перестала быть видимой в локальной сети, что привело к нарушению работы порядка 40 из 80 наших серверов. К сожалению, проблема была замечена одним и пользователей только ближе к вечеру, по крайней мере именно в 9 часов я получил письмо с проблемой. Пользователь сначала пытался решить проблему сам (он сам старший разработчик, «пользователем» для меня он является только в контексте того, что он использует нашу систему для своих задач), и он даже смог решить ее для своего компьютера, но из-за небольшого бага все-таки был вынужден обратиться ко мне, как ответственному за работу всей системы. В результате с 10 вечера (когда я добрался до компьютера и смог войти в систему) до примерно двух часов ночи, когда я написал автоматический скрипт, анализирующий проблему на каждой из наших машин и переписывающий ряд конфигураций для того, чтобы решить эту проблему, мне пришлось работать внепланово. Подобного рода проблемы случаются обычно раз в 2-3 месяца, один раз мне даже пришлось проработать всю ночь и лишь в 6 утра я смог немного поспать перед новым рабочим днем. Зато пользователи, пришедшие на работу к 8-9 утра, могли работать без проблем и практически не заметили нарушения работы системы, что длилось почти 12 часов…
Выбор задач, над которыми ты работаешь, определяется тобой совместно с менеджером. Менеджер обычно выполняет роль «заказчика», составляя требования к тому, что должно быть сделано. Однако эту роль он играет либо в новых проектах, либо на начальных этапах, когда разработчик присоединяется к команде, работающей над существующим проектом. По мере набора опыта и изучения проекта ты становишься все более и более автономен, сам определяя, что является наиболее важным в текущий момент времени, а также составляя список задач и функционал, который нужно добавить или улучшить в средней и длительной перспективе.
Обычно раз в неделю менеджер неформально приходит к тебе в офис, чтобы спросить тебя о том, чем ты сейчас занимаешься и что примерно следует ожидать по итогам работы на этой неделе. Это не какое-то официальное мероприятие, и иногда оно длится просто секунд 20-30. Иногда же, бывает, ты сидишь по 4-5 часов с менеджером, защищая своё решение и обсуждая возможные за и против. При этом менеджер, если он предлагает какое-то решение, также старается технически обосновать свой выбор. Практически не бывает случаев, когда менеджер пытается навязать тебе решение без достаточного его обоснования и обоюдного согласия о том, что данное решение является лучшим. Однако даже это случается не часто, обычно предложенное тобой самим решение – если оно достаточно разумно и воплощаемо в жизнь – просто принимается без слов и критика идёт в основном деталей реализации или архитектуры.
Менеджер ни в коем случае не контролирует твою работу. То есть даже будучи на рабочем месте, ты не должен все время изображать бурную рабочую деятельность. Достаточно, чтобы ты решал поставленные перед тобой задачи в определенные сроки: то есть если задача стоит ASAP (as soon as possible), то предполагается что ты безотлагательно решаешь задачу пока е решишь. Но в большинстве случаев ты просто должен сделать что-то к концу месяца или недели. Поэтому сотрудники без проблем общаются из офиса по Скайпу с родными, совершают какие-то краткие поездки в магазин (если нужно), пишут что-то в социальные сети. Однажды я случайно открыл фейсбук (я там вообще редко бываю с работы, а тут просто ссылку прислали) и тут же зашел мой менеджер что-то обсудить. Увидев фейсбук, он сказал «а, Алекс, я не знал что ты отдыхаешь» и тут же вышел. Я даже ничего сказать не успел от неожиданности.
Примерно раз в неделю у нас проходит встреча всей команды, где обсуждается чей-то проект. Обычно здесь члены команды показывают, чем они заняты в настоящий момент или что было сделано в последние две-три недели и один-два проекта обсуждаются более подробно, с возможными вариантами решения. Тут также обсуждаются и темы, не имеющие непосредственного отношения к работе – кто какие доклады видел недавно, кто что интересного нашел в сети, что-то из внутренних новостей компании и прочего.
Кроме основного проекта есть возможность работать над хобби проектами. Для этого в один из дней недели (обычно вторник или среда) проходит так называемая SLC (Stay Late and Code, «останься допоздна и программируй»), где встречаются люди с хобби-проектами и вместе сидят, работая над проектами и помогая друг другу. Часто в начале таких встреч проходят короткие доклады на новые интересные темы, например, о трехмерной печати.
Где-то раз в полгода необходимо делать доклад о своей работе на внутреннем семинаре. Обычно это происходит после достижения важного срока сдачи, когда новые функции и возможности уже доступны командам, но они о них еще не очень много знают. Целью таких докладов является повышение видимости проектов (чтобы соседние команды знали, над чем ты работаешь) и их использования (часто одни и те же задачи возникают в разном виде в командах, работающих над сходными проблемами).
Существует также формальный процесс оценки, выражаемый в регулярном заполнении специального формуляра, где ты описываешь, что тобой сделано из ранее запланированного, что запланировано дальше и что стоит изменить на основании полученных результатов. Менеджер добавляет свои комментарии по каждому из пунктов и визирует текст, который становится формальным требованием к тому, что нужно выполнить и как в данной итерации.
Раз в год, для определения бонуса, возможного повышения зарплаты и повышение в карьере этот процесс еще более формализируется, тогда к нему подключаются те люди, что работают с тобой. Здесь уже происходит более детальный анализ того, насколько твоя работа полезна для все команды, насколько просто и эффективно работать с тобой внутри команды и другим командам и по итогам собранных оценок (от членов твоей команды и представителей других команд, что работают с тобой) менеджер решает, какой бонус (=премию) ты получишь и стоит ли тебя сейчас повысить или не стоит.
В любой момент ты можешь перейти в другую команду. Для этого нужно только согласие другой команды принять тебя. Внутри компании есть портал, где публикуются объявления о различных интересных вакансиях, и ты можешь подписаться на новые вакансии, которые соответствуют твоим критериям. Я, например, подписан на вакансии, связанные с работой с F# и каждую неделю получают отчет о новых вакансиях где встречается это ключевое слово.
(Окончание в третьем посте)
"Увидев фейсбук, он сказал «а, Алекс, я не знал что ты отдыхаешь» и тут же вышел. Я даже ничего сказать не успел от неожиданности. " это предложение вызвало улыбку, и стало немного грустно от осознания того как различны наши подходы к работе. У нас бы сделали выговор, или штраф, или просто наорали бы .
Блин, повезло тебе, ни в коем случае не завидую, но сам бы хотел работать в команде с подобным взглядом на работу, всегда раздражали места где не смотря ни на что нужно было сидеть до определенного времени- даже если работы попросту нет, так же раздражали кадры которые курят весь день, а при начальстве разводят бурную деятельность- мерзкие пережитки, собственно поэтому и работаю на себя, но в норм. Команду пошёл бы, удачи тебе- цени что имеешь и двигайся вперед.
Увидев фейсбук, он сказал «а, Алекс, я не знал что ты отдыхаешь» и тут же вышел.
А в "Проектмашприборе" в Москве за такое бы влепили штраф на 5-10% от зарплаты
Круто) Хотя, в принципе, такая схема работы (плавающий график, свободный отдых и т.п.) сейчас основная почти во всех ИТ-компаниях. И оценка твоей работы, после которой может быть бонус или повышение, и слабый контакт с менеджерами.
А в общем вся серия постов - супер!) Взял для себя несколько полезных вещей (структура и вид резюме, подготовка к собеседованию и прочее) :)
Хотел спросить: есть ли у вас в командах QC или QA? Если да, то какие требования к ним предъявляются? Я имею в виду, что допустим для девелопера обязанность и задание - код. По какому принципу работают у вас тестировщики?