новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts

Быстрыйнаймразработчиков

Помню обещал сделать отдельный блог-пост на тему быстрого найма на работу. Опишу свой опыт экстремального найма, когда нам надо было быстро (за месяц с небольшим) удвоить аджайл команду из 8 человек. Само собой основная цель была не просто увеличить поголовье разработчиков, а быстро увеличить продуктивность существующей команды. Описанный метод хорошо скалируется, так что, если Вам надо нанять 50 человек и больше, можете так же им воспользоваться. В нашем случае, все протекало примерно так:

Отбор кандидатов

Первый шаг, вполне обычный, мы попросили HR найти как можно больше потенциальных кандидатов. Были задействованы обычные для этого средства: объявление о приеме на работу в средства массовой информации, выставки, базы рекрутинговых агенств и тп. На все про все было отведено 3 недели. Основная цель собрать как можно больше резюме для предварительного отсеивания. Основные вещи, которые мы хотели увидеть в присланных резюме (по Джеку Велшу):

Через три недели у нас было отобрано на основании  резюме 30 потенциально интересных нам людей.

Приглашение на собеседование

Все кандидаты разговаривали с представителями HR по телефону, во время разговора им сообщалось, что они приглашаются на необычное 4-х часовое собеседование, где они встретятся со всеми остальными претендентами на наши вакансии и вкратце была обрисована структура собеседования, чтобы не подвергать людей шоку. Всех кандидатов пригласили на первое собеседование в одно и тоже время и место.

Участие команды в процессе найма

Одним из ключевых моментов успеха, на мой взгляд, является участие самой команды в процессе найма. Ведь в конце-концов это им предстоит в дальнейшем работать каждый день плечо к плечу с новичками. И если люди сами выбирают себе будущих членов команды, процесс ассимиляции новых членов так же пойдет быстрее.

Мы собрали существующую команду и вместе обсудили предстоящий процесс, где подчеркнули некоторые важные факторы. К примеру, было сказано, что не надо пытаться оценивать кандидатов по существующим техническим навыкам, гораздо важнее, насколько быстро человек может освоить новые технологии. Им также предстояло пытаться высмотреть в новичках насколько хорошо они будут дополнять уже существующих членов команды (и тут Вам пригодится “звездная карта“), расширяя своими знаниями наш общий командный набор (растить “звездную карту” в ширину).

Тестовые задания

Также, предварительно, пришлось вместе с существующей командой разработать и разобрать тестовые задания для собеседования, само собой созданные на основании реальных задач из жизни команды. Основная идея придумывать задания, которые бы смогли погрузить кандидатов в условия, максимально приближеные к тем, в которых мы на самом деле работаем. К примеру, у нас были задания о груминге и оценке новых элементов бэклога (grooming), задания на непосредственную разработку в парах, как в парах новичков, так и в паре с кем-либо из существующих членов команды.

Собеседование

Цель собеседования – идентифицировать кандидатов с отличными навыками командной работы и межличностных отношений. Для проведения такого масштабного собеседования на 30 человек была захвачена столовая компании, единственное большое помещение в здании. В ней были расставлены 5 круглых столов, поскольку всем кандидатам предстояло работать в командах. Кстати, из 30 человек пришло на собеседование вовремя 26 кандидатов. Ровно в 16:00 мы закрыли двери столовки. Опоздавшие – мимо кассы.

Пришедших попросили рассесться за столы, за каждым из которых уже сидели представители нашей существующей команды и сходу было дано первое задание: Познакомиться поближе друг с другом, и результатом их знакомства должна стать 3х минутная презентация их новой команды перед остальными командами.

Была также озвучена вводная на целый день: “Сегодня тут основным критерием оценки будут не ваши технические знания и навыки, а ваши способности думать неординарно, задавать хорошие вопросы и ваша способность сделать так, чтобы члены вашей команды выглядели на высоте”.

После этого задания, я как начальник отдела разработки рассказал собравшимся, зачем мы собрались, каков будет распорядок дня дальше. Представил нашу компанию и мою существующую команду, рассказал о том, как мы работаем: про скрам, про парное программирование, про тестирование, и тп. Тут же провели небольшой раунд вопросов и ответов и перешли к следующему заданию.

Представители нашей команды играли за каждым столом роль Product Owner-а. А командам надо было обсудить детали, декомпозировать на задачи и оценить по несколько элементов нашего реального бэклога (мы взяли старые пользовательские истории, которые были закончены в последние спринты).

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

Так закончилось время отведенное на практические упражнения. Последней активностью мы поблагодарили всех пришедших за их время, подарили всем по книжке про скрам, и устроили пол часа нетворкинга, мол кто хочет может остаться поболтать о разных около-аджайльных темах.

Оценка кандидатов

По мере того как команды работали над заданиями с самого начала собеседования, члены нашей команды перемещались между столами и получили возможность наблюдать все команды и всех кандидатов. Через пол часа, после того как мы проводили всех кандидатов, к нам прибыла пицца и мы начали разбор полетов всей командой.

На стикерах по горизонтали на одном уровне вывесили имена всех кандидатов на стене (с хорошим расстоянием между ними) и попросили команду перенести свои записи, которые они делали по ходу сеанса о тех или иных кандидатах под соответствующим именем кандидата. Зеленый стикер, положительные наблюдения, красный стикер отрицательные.

Осмотрели и изучили в подробностях стену. В процессе опустили “на ряд ниже” людей, о которых совсем не было или было мало заметок. Это те, которые оказались анонимными, и никак себя не проявили. По оставшимся кандидатурам прошлись dot-voting-ом (голосовали цветными точками за тех, кого бы ты хотел поддержать, каждый член команды получил 3 точки). После чего отвесили на “этаж” ниже еще несколько кандидатов, по результатам голосования. На этой стадии картина уже начала вырисовываться.

Осталось обсудить все вживую. Члены команды получили возможность поделиться с другими информацией, кто что заметил о кандидатах. Основной упор на инициативность, умение модерировать и направлять командную работу, конструктивно спорить, выслушивать других и тд и тп, все то, что вы обычно хотите видеть в представителе аджайл команды.

Забавно, что многим понравились одни и те же люди, и у нас почти не возникало споров, кого мы хотим видеть у себя в команде, а кого нет.
По результатам этого собеседования мы сделали 6 предложений, 5 из которых были приняты кандидатами. Все хорошо вписались в команду и по прошествии 3х лет все еще работают вместе. А как вы набираете к себе на работу? Поделитесь хорошими советами в комментариях.

Сергей Дмитриев Cовладелец Unusual Concepts

Плюсануть
Поделиться
Отправить
Класснуть
Линкануть
Вотсапнуть
Запинить
Ещё по теме
Студент Unusual Concepts делится ценными советами по сдаче экзамена PSM и PSPO 1. Цена попытки — 200$, но лучше сходить на тренинг Unusual Concepts. Рекомендую! Выйдет в четыре раза дороже, но оно того стоит. 2. Внимательно и вдумчиво изучить scrum guide на английском (!) языке. Что угодно делайте, чтобы понять и запомнить всё, что там написано. Мне лично помогло рисовать mind maps. Кому-то помогает внимательно прочесть 3 раза. 3. Пройти open assessments на сайте scrum.org (open, product owner, developer). Nexus не надо. Здесь задача в том, чтобы понять логику того, кто эти тесты делал (эта же самая логика используется и в сертификационном экзамене). Проходить советую вдумчиво, читая то, что написано. Не советую тупо запоминать вопросы и ответы на них, т.к. хотя в экзамене и есть copy-paste из open assessment, их, во-первых, всего лишь около половины, а во-вторых, это вам только помешает понять суть. Из этих же соображений советую тренироваться по одной попытке на каждый open assessment и потом перерыв. Потом опять по одной на каждый и опять перерыв. Идеально, если чередовать с изучением scrum guide. Обязательно читаем результаты теста! Там годные комментарии к ответам. Добивайтесь устойчивого 100% результата. 4. Если у вас с английским языком проблемы — то советую подтянуть. Лучший способ, на мой взгляд, делать всё, что я тут описал, но со словарём. Добиваемся, чтобы весь scrum guide и все open assessments были понятны без словаря. Во время экзамена словарь держите под рукой — попадаются непонятные слова, но целиком полагаться на него не стоит (один товарищ пытался загонять все вопросы в он-лайн переводчик, и в результате получил 53% правильных ответов). 5. Сертификационный экзамен сдаётся на сайте scrum.org, где другой интерфейс, чем у тестовых экзаменов. Это может добавить мандража, если станет неожиданностью. Но существенных отличий там нет. Разве только можно закладки ставить. 6. Перед сдачей самого экзамена убеждаемся, что у нас есть час времени, когда точно никто не будет отвлекать и интернет точно не отвалится. Я перестраховывался 3g модемом, но, слава Богу, не пришлось. 7. Во время экзамена ни в коем случае не надо париться над сложными вопросами! Если вопрос сложный, то выбирайте то, что вам кажется верным, ставьте на вопрос закладку (bookmark) и идите дальше. Большинство вопросов (около 60 из 80), при условии что всё вышеописанное вами сделано добросовестно, вы отобъёте за 30 минут. Оставшиеся 30 минут можно потратить, чтобы внимательно и вдумчиво разобрать все закладки. У меня даже получалось в интернете поискать варианты в это время. 8. Не надо ставить закладку на все вопросы, в которых у вас есть сомнения. Ставьте закладку только там, где вы вообще не уверены. Иначе получится неприятная картинка, когда сначала вы закладки ставили на средне-сложные вопросы, а потом стали ставить только на очень сложные, и в результате под конец теста у вас не 20 закладок, а 40, и времени в обрез. 9. Помните — это экзамен. Не надо быть самоуверенным, а то завалить его проще простого. Но и мандражить сильно не надо. Просто тщательно подготовьтесь, и всё будет хорошо. Оригинал поста в Фейсбуке
Андрей Толмачев рассказывает, как разрешить взаимное недовольство Владельца Продукта и Команды Разработки.

Условия задачи

Представьте такую ситуацию. Вы — новый Скрам-мастер. Ваша Команда Разработки состоит из системного аналитика, двух разработчиков и двух специалистов по тестированию. Длина Спринта — две недели. Команда работает со сложной системой на старой платформе, поэтому для каждого элемента Бэклога Продукта аналитика, разработка и тестирование попадают в отдельные Спринты. В течение последнего Спринта Команда не успела сделать работу, взятую в Спринт, поэтому на Ретро Владелец Продукта допытывается, кто чем занимался в течение Спринта. Владелец Продукта жалуется, что Команда работает очень медленно. Члены Команды жалуются, что бизнес контролирует и микроменеджит их. Как разрешить взаимное недовольство Владельца Продукта и Команды Разработки? Давайте разбираться.

Что происходит

Для каждого элемента Бэклога Продукта аналитика, разработка и тестирование попадают в отдельные Спринты — это означает, что элемент будет готов к выпуску только через три Спринта. В таком случае истинная длина Спринта равна шести неделям — это больше, чем допускает Руководство по Скраму.
Максимальная продолжительность Спринта — один календарный месяц. При большем сроке планирования возможны изменения целей, увеличение сложности и рост рисков.
Руководство по Скраму Когда Команда редко поставляет готовый Инкремент, то редко получает обратную связь от стейкхолдеров и клиентов. В результате:
  • возрастает риск сделать не то, что надо. Способность реагировать на изменения падает;
  • стабильность процесса падает, прогнозировать работу сложно. Например, тестирование выявляет дефекты через недели после разработки. Баги обнаруживаются поздно, поэтому объём «поддержки» будет меняться от Спринта к Спринту;
  • рабочий процесс перестаёт быть прозрачным.
По этим причинам Команда Разработки теряет доверие Владельца Продукта и стейкхолдеров, следовательно, давление возрастает и начинаются конфликты.

Решение

Скрам-мастер не может решить проблему самостоятельно, но может помочь своей Команде следующим образом:
  • объяснить описанную выше системную динамику и её вредные последствия. Скрам-команда должна понимать, что правило Скрама про Done Increment каждый Спринт — это естественное системное решение их проблемы;
  • помочь сформулировать или пересмотреть минимальный DoD, который может быть выполнен в течение Спринта и который обеспечит готовность Инкремента к релизу;
  • научить Команду Разработки правильно декомпозировать элементы Бэклога. Небольшие элементы в Бэклоге Продукта способствуют ранней поставке, оптимизации ценности Продукта и улучшению потока работы;
  • помочь договориться взять в следующий Спринт хотя бы один небольшой элемент Бэклога, но довести его до состояния Done;
  • визуализировать поток работы. Прозрачность — залог успеха;
  • устранить простои в работе. Для этого Скрам-мастер обучает Команду хорошим инженерным практикам, например, общему владению кодом, стимулирует развитие T-shaped или E-shaped людей в Команде, заключает командные соглашения;
  • объяснить Владельцу Продукта, что причина задержек — технический долг и убедить его выплатить.
Используйте Ретроспективу, чтобы найти лучшие решения по устранению препятствий. Помните, что эти решения — эксперименты, не факт, что они принесут ожидаемый эффект. Поэтому инспектируйте результаты прошлых решений и адаптируйте решения на следующих Ретроспективах.

Итоги

Готовый Инкремент в конце Спринта — это важнейшие правило Скрама, которое помогает избежать роста рисков, потери предсказуемости и гибкости. Описанные причинно-следственные связи полезно знать, чтобы понимать, почему Скрам требует соответствующий DoD, готовый к релизу Инкремент каждый Спринт. Следующие действия могут помочь в достижении этой цели:
  • декомпозиция работы на небольшие PBI;
  • визуализация потока работы в Спринте и поиск основных узких мест;
  • устранение «простоев» работы с помощью командных соглашений, хороших инженерных практик и развития T-shaped или Е-shaped людей;
  • планомерная ликвидация технического долга.
Комментарии
» Выбранный эволюцией Блог о проактивном бизнесе, 19 ноября 2014

[…] Дайте членам команды играть ключевую роль в найме новых сотрудников. Удивительно наблюдать, насколько часто командам навязываются отдельные люди, при этом команда даже не имеет права голоса. Ведь, в конце концов, это им предстоит в дальнейшем работать каждый день плечом к плечу с новичками. И если люди сами выбирают себе будущих членов команды, процесс ассимиляции новых членов так же пойдет быстрее. Подробнее об этом можно почитать в блог-посте «Быстрый найм разработчиков». […]

Сергей Дмитриев, 14 ноября 2011

Мне тоже кажется более верной политика с наймом людей желающих учиться, нежели остановившихся в развитии экспертов.
А еще лучше эксперты желающие учиться дальше.

Сергей Дмитриев, 14 ноября 2011

Соглашусь насчет перегретого рынка Украины. Однако, времена меняются, это раз :).
А два, давайте создавать такие рабочие места, куда люди Хотят и Рвутся идти работать, и не хотят ни к кому другому. На сегодняшний день эта позиция на рынке Украины открыта :), и тот кто ее займет, окажется в выигрыше.

Рубрика «Полезное чтиво». Выпуск 10 « XP Injection, 14 ноября 2011

[...] Быстрый найм разработчиков – как стоит нанимать в команду в идеальном мире [...]

Alexandr Demchenko, 13 ноября 2011

Согласен с Николаем то что время на собеседование 4 часа в реалиях Украинского рынка просто не возможны, но с стороны своего опыт скажу, что да если вы хотите набрать команду супер профессионалов задача который будет состоять выполнить проект и уйти и которые вам обойдутся в круглую сумму денег да еще и огромного количества нервных клеток после определенного времени работы, и при этом вы можете себе позволить искать такую команду к примеру пол года - то действительно можно следовать максимально усложненному отсеву на собеседование что бы выловить те частицы которые идеально подойдут вашему проекту. Но на мой вгляд это все гипотетика, сейчас реальные люди для проекта - это не те кто уже все знает или много знает, а те кто стоят уверено на пути к познанию, и как итог в команду потребуется 1-2 профессионала и остальная часть команды на уровне активного обучение в разной стадии. Из своего опыта скажу, что программист который активно учится доходит до уровня профессионала за 2-3 месяца, при этом рассходы в разы ниже на набор такой команды и самое важное эта команда будет максимально хорошо притерта друг к другу.

Николай Алименков, 13 ноября 2011

Сергей, спасибо за отличный пост о твоем реальном опыте. Я полностью согласен, что команда в идеале должна участвовать в отборе людей. Это позволяет подобрать тех, кто идеально впишется в команду. Вопрос только в том, на каком рынке это делается. Рынок Украины так перегрет, что толковые специалисты если и придут на собеседование в назначенное время, то уж точно не потратят 4 часа на собеседование. Они просто не видят в этом смысла. Ситуация вывернулась наизнанку - не людям нужна работа, а компаниям нужны люди. Спрос сильно превышает предложение.
Я некоторое время назад пытался отбирать кандидатов с обязательным практическим заданием в паре на собеседовании. В результате большая часть вообще ничего не могли сделать, а оставшиеся не хотели потратить достаточно времени на подобное собеседование. Поэтому приходится подстраиваться под рынок. :(