А Миша не подготовился — не подумал, о чем важно спросить: например, как оплачивают работу или по каким принципам ведут проекты.
Точно не подготовился - спрашивать о порядке оплаты нужно на собеседовании, а не на онбординге.
В итоге он генерировал вопросы на ходу, что задержало разговор на 20 минут, а тимлид волновался, как бы успеть на следующие запланированные встречи и обед.
Становится очевидно, что Миша это медведь - тимлид боится слово сказать, лишь бы не нервировать его.
Через несколько дней после провального созвона Миша снова отличился. Он неправильно написал код автоматического тестирования, которое должен был провести в четверг. И до пятницы молчал, пытаясь самостоятельно разобраться с проблемой.
На задачу с жёстким и близким дедлайном ставится новичёк. Более того, ход выполнения задачи не контролируется. Но тимлид всегда может отправить заказчиков задавать вопросы напрямую Мишане - вряд ли они будут очень настойчивы в общении с медведем.
А жив ли вообще?
И тимлид и команда стараются лишний раз в берлогу не заглядывать - зима на носу, вдруг Миша спать залёг, а его потревожат.
«... Был на трех встречах с командой, обсудили кучу полезных тем». У тимлида выступили вены на лбу и полопались капилляры в глазах.
Судя по всему Миша единственный, кто остался из команды после этих встреч, если до тимлида только сейчас дошёл факт его коммуникации с остальными.
Это всё шутка, но статья демонстрирует крайне странные процессы в команде, куда попал Миша.
Онбординг это не встречи вопросов и ответов, а процесс контролируемого погружения новичка в работу. Контролируется оно либо самим тимлидом, либо опытным сотрудником, которому тимлид может делегировать эту обязанность. Здесь нет разумной возможности выйти за регламентное время встречи.
Одна из обязанностей тимлида - иметь представление о том, что происходит с задачами, которые выполняет команда. Это можно реализовать либо ежедневными встречами команды (дейли-митинги) либо, если команда не хочет собираться каждый день на 10-20 минут, ежедневным обновлением в таск-трекере задач с записью актуального состояния. Но в любом случае, независимо от того, какой процесс принят, новичёк требует повышенного внимания - онбординг не завершается одной встречей.
Новичку в общем случае нельзя давать задачи с близким и жёстким дедлайном - у него не может быть знания кодовой базы проекта, в котором ему нужно работать.
Программист не должен быть проактивным в вопросах бизнеса - он должен быть проактивным в вопросах разработки в проекте, куда он пришёл. Но на начальном этапе трудно быть обоснованно проактивным по объективным причинам. И на общие обеды ходить он не обязан - у него может быть свой особый график питания или диета. И ожидание помощи от того, кто только-только попал на проект, странно - это ему нужно помогать поскорее влиться в команду.
"Главное — заранее обговорить формат встречи: если рабочий — готовим цифры и факты, а если личный — завариваем кофеек." Вспоминается Шелдон Ли Купер с его соглашениями об отношениях. На работе взаимодействия должны быть рабочими. Личные взаимодействия могут происходить между людьми, которые являются коллегами, но не могут быть частью рабочих процессов.
У отсылки к тексту правил FIDE в контексте рассматриваемого вопроса есть один, но фатальный методологический недостаток - он приводится на английском языке и не может служить основанием для суждений относительно применения термина "фигура" в русском языке (ср. случай с "queen" и "ферзь"). Этим же недостатком страдает и отсылка к исходному коду.
Впрочем, главное заключается в том, что правила FIDE никак не затрагивают вопросы шахматной мысли, в то время как "пешка - не фигура" относится именно к этому контексту, а не к контексту правил игры. Достаточно вспомнить общепринятое деление на тяжёлые и лёгкие фигуры, которое никак не фигурирует в правилах, и которое явно исключает из числа фигур пешки (и короля, кстати).
Таким образом, можно одновременно утверждать, что "пешка - не фигура" (в тактическом смысле), и что "пешка - фигура" (как часть игрового инвентаря).
Не уверен в том, что это легко. Возможно у нас разное понимание бизнес-задач. Было бы любопытно увидеть пример бизнес-задачи, контекст которой можно полностью сформулировать за пять минут.
Я, когда провожу собеседования (PHP), задаю обычно довольно древний вопрос о разнице между абстрактным классом и интерфейсом. С одной стороны для ответа на этот вопрос не требуется знание внутренностей PHP, с другой - это неплохая стартовая точка для начала разговора об архитектуре. Таким образом я выясняю несколько вещей сразу: насколько соискатель является действительно опытным разработчиком, насколько хорошо он может коммуницировать с другими (доносить свою точку зрения) и насколько мне будет комфортно с ним взаимодействовать.
Реальные бизнес-задачи практически всегда сильно связаны с контекстом бизнес-процессов компании, которые практически невозможно транслировать за ограниченное время собеседования.
Непонятно почему ситуация с инженером Петей представлена как конфликт, в котором главными действующими сторонами представлены тимлид и Петя.
Очевидно, что "намёки" о том, чего хотелось бы Пете, делались до того, как Петя стал ходить на собеседования.
Хотя деньги не были основным мотивом хождения по собеседованиям, отказ от оффера с повышением зарплаты на 50% (при прочих равных) крайне маловероятен. И вот в этот момент деньги становятся решающим фактором, о чём честно сообщил Петя тимлиду. А в exit-интервью он сообщил об исходной мотивации (тоже честно).
Из этой ситуации можно сделать вывод, что в компании отсутствуют прозрачные, максимально деперсонифицированные процессы роста, смены ролей, личного развития (ещё хуже, если они формально есть, но не соответствуют реальности). Иначе Пете не пришлось бы намекать тимлиду о своих желаниях.
Итого: тимлид здесь не является активной стороной конфликта. Здесь скорее конфликт между Петей и компанией. И тимлид может только предложить внести соответствующие изменения в корпоративную политику, чтобы не допустить (или свести к минимуму) подобные случаи.
Как может дойти до того, что члены команды пившие друг с другом пиво по пятницам, стали разговаривать друг с другом сквозь зубы? Если это не следствие личных взаимодействий (например, один увёл жену у другого), то при правильно выстроенных процессах такое практически невозможно.
Например, если Вася не пропускает код Пети на код-ревью, это повод для арбитража со стороны того же тимлида. Причём Пете совершенно не нужно за ним обращаться - тимлид на очередном дейли-митинге (или аналогичном мероприятии) должен сам запросить информацию о текущем состоянии дел и предпринять соответствующие действия (желательно обосновав своё решение). Здесь нет места для внезапного конфликта между Петей и Васей.
"Расскажите, в чем проблема? Что мы можем придумать, чтобы вы договорились, а я смог поработать в тишине?" Это точно обращение к детям, которые настолько малы, что неспособны сами понять, что мешают работать?
"Вася, почему ты переложил ответственность за коммуникацию?" Выглядит, как знаменитое: "Рядовой Петров, разве ты не видишь, что льёшь расплавленное олово на голову своему товарищу?"
Статья весьма теоретическая. Очень не хватает реальных примеров (характерно, что самый живой из представленных - о запившем сотруднике).
Точно не подготовился - спрашивать о порядке оплаты нужно на собеседовании, а не на онбординге.
Становится очевидно, что Миша это медведь - тимлид боится слово сказать, лишь бы не нервировать его.
На задачу с жёстким и близким дедлайном ставится новичёк. Более того, ход выполнения задачи не контролируется. Но тимлид всегда может отправить заказчиков задавать вопросы напрямую Мишане - вряд ли они будут очень настойчивы в общении с медведем.
И тимлид и команда стараются лишний раз в берлогу не заглядывать - зима на носу, вдруг Миша спать залёг, а его потревожат.
Судя по всему Миша единственный, кто остался из команды после этих встреч, если до тимлида только сейчас дошёл факт его коммуникации с остальными.
Это всё шутка, но статья демонстрирует крайне странные процессы в команде, куда попал Миша.
Онбординг это не встречи вопросов и ответов, а процесс контролируемого погружения новичка в работу. Контролируется оно либо самим тимлидом, либо опытным сотрудником, которому тимлид может делегировать эту обязанность. Здесь нет разумной возможности выйти за регламентное время встречи.
Одна из обязанностей тимлида - иметь представление о том, что происходит с задачами, которые выполняет команда. Это можно реализовать либо ежедневными встречами команды (дейли-митинги) либо, если команда не хочет собираться каждый день на 10-20 минут, ежедневным обновлением в таск-трекере задач с записью актуального состояния. Но в любом случае, независимо от того, какой процесс принят, новичёк требует повышенного внимания - онбординг не завершается одной встречей.
Новичку в общем случае нельзя давать задачи с близким и жёстким дедлайном - у него не может быть знания кодовой базы проекта, в котором ему нужно работать.
Программист не должен быть проактивным в вопросах бизнеса - он должен быть проактивным в вопросах разработки в проекте, куда он пришёл. Но на начальном этапе трудно быть обоснованно проактивным по объективным причинам. И на общие обеды ходить он не обязан - у него может быть свой особый график питания или диета. И ожидание помощи от того, кто только-только попал на проект, странно - это ему нужно помогать поскорее влиться в команду.
"Главное — заранее обговорить формат встречи: если рабочий — готовим цифры и факты, а если личный — завариваем кофеек." Вспоминается Шелдон Ли Купер с его соглашениями об отношениях. На работе взаимодействия должны быть рабочими. Личные взаимодействия могут происходить между людьми, которые являются коллегами, но не могут быть частью рабочих процессов.
У отсылки к тексту правил FIDE в контексте рассматриваемого вопроса есть один, но фатальный методологический недостаток - он приводится на английском языке и не может служить основанием для суждений относительно применения термина "фигура" в русском языке (ср. случай с "queen" и "ферзь"). Этим же недостатком страдает и отсылка к исходному коду.
Впрочем, главное заключается в том, что правила FIDE никак не затрагивают вопросы шахматной мысли, в то время как "пешка - не фигура" относится именно к этому контексту, а не к контексту правил игры. Достаточно вспомнить общепринятое деление на тяжёлые и лёгкие фигуры, которое никак не фигурирует в правилах, и которое явно исключает из числа фигур пешки (и короля, кстати).
Таким образом, можно одновременно утверждать, что "пешка - не фигура" (в тактическом смысле), и что "пешка - фигура" (как часть игрового инвентаря).
У футболистов нет таких пунктов в контрактах. После истечения срока трудового договора, они вольны устроится в любой клуб.
Не уверен в том, что это легко. Возможно у нас разное понимание бизнес-задач. Было бы любопытно увидеть пример бизнес-задачи, контекст которой можно полностью сформулировать за пять минут.
Я, когда провожу собеседования (PHP), задаю обычно довольно древний вопрос о разнице между абстрактным классом и интерфейсом. С одной стороны для ответа на этот вопрос не требуется знание внутренностей PHP, с другой - это неплохая стартовая точка для начала разговора об архитектуре. Таким образом я выясняю несколько вещей сразу: насколько соискатель является действительно опытным разработчиком, насколько хорошо он может коммуницировать с другими (доносить свою точку зрения) и насколько мне будет комфортно с ним взаимодействовать.
Реальные бизнес-задачи практически всегда сильно связаны с контекстом бизнес-процессов компании, которые практически невозможно транслировать за ограниченное время собеседования.
Непонятно почему ситуация с инженером Петей представлена как конфликт, в котором главными действующими сторонами представлены тимлид и Петя.
Очевидно, что "намёки" о том, чего хотелось бы Пете, делались до того, как Петя стал ходить на собеседования.
Хотя деньги не были основным мотивом хождения по собеседованиям, отказ от оффера с повышением зарплаты на 50% (при прочих равных) крайне маловероятен. И вот в этот момент деньги становятся решающим фактором, о чём честно сообщил Петя тимлиду. А в exit-интервью он сообщил об исходной мотивации (тоже честно).
Из этой ситуации можно сделать вывод, что в компании отсутствуют прозрачные, максимально деперсонифицированные процессы роста, смены ролей, личного развития (ещё хуже, если они формально есть, но не соответствуют реальности). Иначе Пете не пришлось бы намекать тимлиду о своих желаниях.
Итого: тимлид здесь не является активной стороной конфликта. Здесь скорее конфликт между Петей и компанией. И тимлид может только предложить внести соответствующие изменения в корпоративную политику, чтобы не допустить (или свести к минимуму) подобные случаи.
Как может дойти до того, что члены команды пившие друг с другом пиво по пятницам, стали разговаривать друг с другом сквозь зубы? Если это не следствие личных взаимодействий (например, один увёл жену у другого), то при правильно выстроенных процессах такое практически невозможно.
Например, если Вася не пропускает код Пети на код-ревью, это повод для арбитража со стороны того же тимлида. Причём Пете совершенно не нужно за ним обращаться - тимлид на очередном дейли-митинге (или аналогичном мероприятии) должен сам запросить информацию о текущем состоянии дел и предпринять соответствующие действия (желательно обосновав своё решение). Здесь нет места для внезапного конфликта между Петей и Васей.
"Расскажите, в чем проблема? Что мы можем придумать, чтобы вы договорились, а я смог поработать в тишине?" Это точно обращение к детям, которые настолько малы, что неспособны сами понять, что мешают работать?
"Вася, почему ты переложил ответственность за коммуникацию?" Выглядит, как знаменитое: "Рядовой Петров, разве ты не видишь, что льёшь расплавленное олово на голову своему товарищу?"
Статья весьма теоретическая. Очень не хватает реальных примеров (характерно, что самый живой из представленных - о запившем сотруднике).