Можно рассматривать это, как полосу препятствий, а можно как процедуру взаимного знакомства. Можно готовиться, заучивая заготовки — а можно, обдумывая, как лучше сформулировать свой ответ.
Я все же думаю, что это не совсем так. Вы — активный участник Хабра, интересуетесь технологией, у вас блог, аккаунт на Гитхабе… Я почему-то не думаю, что вас интересуют в работе только деньги :)
А почему вы думаете, что есть какой-то один ожидаемый ответ? У вопросов, как правило, есть смысл; есть люди, которые смысл понимают и дают нормальный человеческий ответ. Есть также люди, которые смысл не понимают, но готовы сыграть по правилам и дают заготовленный ответ. Заготовка, кстати, как правило прекрасно видна. И, наконец, есть люди, которые смысла не понимают, склонны непонятное априори считать глупостью и это так или иначе выражают в своем поведении и ответах. Таких людей я, например, предпочитаю не брать — в большой команде и большой компании есть много чего, что сразу может быть непонятно, и такой подход кострктивным не будет.
Руководитель далеко не всегда ждет от работника желания роста. Нормальному руководителю хочется избежать ситуации, когда человек попадает на неподходящее место. Чтоб далеко за примером не ходить, я не далее как месяц назад, принимая нового человека в команду, специально уточнял, что у него нет желания карьерного роста в ближайшее время, поскольку у меня для него этой возможности не предвидится. Да, наверняка есть куча HR, которые задают эти вопросы просто потому, что так принято. Но в основе эти вопросы вполне понятны и разумны.
Задача состоит в том, чтобы находить не просто хороших, а нужных работников. К примеру, рассмотрим пресловутый вопрос о том, кем вы себя видите через 5 лет. Я ниже нписал, что на этот вопрос возможны разные варианты ответов. Например, «Вижу себя руководителем команды из 5-10 человек». Или «Вижу себя работающим с супер-современными технологиями». Или «архитектором проекта». Или «Ведущм разработчиком нового фреймворка»… Теперь, к примеру, рассмотрим такую ситуацию: я — руководитель команды, и у меня есть место для одного старшего разработчика. Я сам планирую через год-другой подняться на ступеньку повыше, и мне нужен человек, которого можно будет поставить на мое место. При прочих равных (еще раз: при прочих равных!) я отдам предпочтение тому кандидату, который сам предполагает расти, а не тому, у кого карьерный рост вызывает зевоту и отвращение. Или, наоборот, я четко знаю, что в близайшие два-три года роста не будет — тогда я, напротив, поостерегусь брать человека, настроенного на быструю карьеру.
Такой подход означает, что вы не знаете ответа на этот вопрос. В этом нет ничего страшного или плохого; но есть люди, которые этот ответ знают. Например, «Через 5 лет я вижу себя руководителем команды в 5-10 человек». Или «Я вижу себя главным архитектором». А некоторые скажут «Я вижу себя работающим над супер — интересным проектом». Этот вопрос, например, дает некоторое представление о том, хочет человек продвигаться по административной линии, по технологической или еще не определился. А может, он вообще больше никуда расти не хочет — я встречал и таких.
Нет, дело не только в готовности к переменам. Agile — под которым я имею в виду появившуюся в начале 2000-х идеологию разработки — подразумевает итеративность процесса и его адаптивность. Это прекрасно работает для определенного класса проектов, в которых короткие итерации позволяют успевать адаптироваться к стремительно меняющемуся рынку, а неполная версия продукта имеет смысл: бизнес-разработки, enterprise, разработки игр, веб… С другой стороны, есть классы проектов, для которых подобный подход нехорош, поскольку предполагает динамическое формирование цели. Я, правда, в этом не специалист, но думаю, что для разработки встроенного ПО, систем управления технологическими процессами и т.п. такого рода методологии не годятся.
Теперь давайте конкретно про Скрам. Он очень хорошо работает, когда основная работа состоит в разработке. Если же параллельно с разработкой идет активная поддержка, или если речь идет о часто меняющихся приоритетах, то Скрам начинает сбоить, по причине необходимости на ходу менять спланированный спринт. Канбан гораздо лучше приспособлен к таким ситуациям, поскольку плана никакого нет, а есть просто ограниченная по размеру очередь задач. В моей команде, например, мы пришли к гибридному варианту типа Скрамбана — Канбан с наложенными двухнедельными циклами релизов и планирования.
Нельзя забывать, что Скрам подходит далеко не всем и далеко не всегда. В определенных случаях подходят другие Agile-методики (Канбан, Скрамбан); в других случаях Agile вообще не подходит.
Увидел в вашей классификации «быдло», и дальше читать не стал. Если в вашем анализе людей присутствует такое понятие, это означает, что у вас еще недостаточно понимания людей и мира, чтобы делать какие-либо выводы.
Эффективнее тем, что позволяет разработчику увидеть, что именно вызывает недовольство. В напоминалках как таковых ничегои особо плохого нет — плохо, когда они становятся чересчур назойливыми.
Ну, проще всего, наверное, будет на личном примере. Я работаю в компании, которая занимается технологией интернет-рекламы, в отделе видео-рекламы. Конечно, когда я набираю себе в команду людей, меня очень интересуют их профессиональные навыки (ну, скажем, JavaScript или Java) и их обучаемость. Но, помимо этого, мне хочется, чтобы мои сотрудники разобрались в том, как работает бизнес интернет-рекламы. Например, чтобы они понимали, как считаются и что из себя представляют основные аналитические показатели. Мои ребята интересуются этим бизнесом, понимают что и как — и, в результате, моя группа получила новый проект, связанный с аналитикой. Если бы им всем был безразличен бизнес, а интересовали их только хитроумные детали кодинга на JavaScript'e, я бы не смог взять на себя такую задачу.
Человек, заинтересованный в работе в данной конкретной компании всегда имеет преимущество перед тем, кому совершенно все равно, где работать. Мне хочется взять на работу человека, которому будет интересно, который будет готов сам двигаться вперед и расти, который легко выйдет за рамки той ниши, в которую изначально он попадет. Кодер, не видящий ничего дальше своего куска — не очень ценный сотрудник. Это приемлемо на низких позициях, но не годится для более ответственных. Исключения, конечно, есть, но их, в общем, немного.
В этой ситуации ничего особо интересного нет, кроме одного маленького факта: это происходило в Гугле. Может, это такой звоночек — количество таки перешло в качество, и Гугл начинает из необыкновенного места превращаться в самую обычную компанию.
Если человек на собеседовании начинает критиковать компанию или ее специалистов и проверять, насколько технически подкован человек, проводящий собеседование, то, на мой взгляд, у этого человека есть большие проблемы с пониманием рабочих взаимоотношений и своего места в компании, и нанимать его не нужно.
http://bolk.livejournal.com/402923.html
Теперь давайте конкретно про Скрам. Он очень хорошо работает, когда основная работа состоит в разработке. Если же параллельно с разработкой идет активная поддержка, или если речь идет о часто меняющихся приоритетах, то Скрам начинает сбоить, по причине необходимости на ходу менять спланированный спринт. Канбан гораздо лучше приспособлен к таким ситуациям, поскольку плана никакого нет, а есть просто ограниченная по размеру очередь задач. В моей команде, например, мы пришли к гибридному варианту типа Скрамбана — Канбан с наложенными двухнедельными циклами релизов и планирования.
И это будет самое правильное, что можно сделать с этой статьёй.