Архивы для Ноябрь, 2011

В субботу 12 ноября мы проводили первую онлайн конференцию на платформе IT Brunch. Называлась она «В гостях у Agile практиков» и собрала докладчиков, практикующих Agile подходы из России и Украины. Отчет о самой конференции можно прочитать на сайте, а больше понять как оно происходило – в ленте Twitter.

Я помимо организации был одним из докладчиков. Тема моего доклада была «Небольшие гипер-продуктивные команды». Я уже выступал с этим докладом в формате PechaKucha, но там было достаточно мало времени рассмотреть детальнее эту интересную тему. Пересказывать содержание доклада нет смысла. Вы можете сами его послушать, если не пожалеете 30 минут своего времени:

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

Вопрос: Один разработчик в проекте, даже если лид, это серьезно по вашему мнению?
Ответ: Я думаю, что очень важен контекст проекта. Если на проекте нет больше работы, чем на одного человека, то раздувать команду искусственно не стоит. С другой стороны, один разработчик на проекте – это очень большой риск. Все знания хранятся в одной голове, может проявляться однобокий взгляд на архитектуру и дизайн приложения, некому посоветовать и сделать code review, тяжело решать проблемы и т.д. Поэтому я бы не назвал это «серьезным проектом», так как риски слишком высоки.

Вопрос: Как построить идеальную команду, учитывая дефицит кадров? Не проще инвестировать в рост кадров в случае долгосрочного проекта?
Ответ: Да, дефицит кадров очень сильно влияет на возможность построить классную команду. Но не стоит забывать о правильной мотивации, которая может во многих случаях играть немаловажную конкурентную роль при выборе потенциальным сотрудником места работы. При прочих равных условиях вы при сборе небольшой эффективной команды имеете преимущества перед большими бюрократическими командами. Для «правильных» людей конечно. Инвестировать в рост при долгосрочном проекте можно и нужно. Вот только делать это нужно с умом и без спешки. Не стоит брать толпу джуниоров и тратить кучу времени команды на их воспитание. Тем более учитывая какой «неблагодарный» у нас рынок. Лучше растить по одному или же использовать отдельный центр повышения квалификации, если есть на это средства.

Вопрос: Если джуниоры никому не нужны в командах, то как они вырастут?
Ответ: Этот вопрос перекликается с предыдущим. Они нужны, с этим никто не спорит. Но у разных компаний могут и должны быть разные стратегии развития. Небольшая команда для эффективной работы должна фокусироваться на разработке, а не на обучении персонала. И далеко не каждый опытный разработчик может быть хорошим тренером. А это означает, что и он будет тратить много времени и джуниор расти будет медленно. Если команда хочет и может взять «на попечение» джуниора, видит в себе силы и не потеряет значительно в скорости, то в этом есть смысл. В противном случае лучше инвестировать в развитие через специализированные тренинг-центры или внутренний центр повышения квалификации. Это будет дешевле и эффективнее.

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

Вопрос: По Вашему опыту возомжно ли в будущем в нашей стране построение таких команд в высоко бюрократических компаниях, например банках?
Ответ: В сильно бюрократических компаниях не думаю, что такое станет возможно в ближайшее время. В них достаточно жестко прописываются роли, должности и правила. Я даже в некотором роде вижу противоречие слова «команда» и «штат сотрудников». Настоящая команда – это не просто люди, которые работают вместе. И добиться построения эффективной команды, не позволяя изменять жесткие должностные рамки, врядли получится.

Вопрос: Команде из 3-х человек не нужен менеджер. А нужен ли менеджер (владелец) продукта? Тот, кто будет отвечать за успех продукта в целом?
Ответ: Обязательно нужен. Он будет как раз той недостающей частью, которая позволяет команде показать свою эффективность. Сама команда не может отвечать за продукт (его функциональность, важность и прибыльность). А без этой информации команде тяжело сделать то, что будет названо «классным продуктом».

Вопрос: Может ли владелец продукта быть членом команды и скрам-мастером?
Ответ: Я некоторое время назад писал на тему кто может быть ScrumMaster-ом на проекте. ScrumMaster и Product Owner – это роли, которые налагают определенные зоны ответственности и правила работы. Определить кто удачнее подходит для какой роли можно в каждом конкретном случае. Если новая роль не конфликтует с уже существующими для этого человека ролями, то он является хорошим кандидатом.

Вопрос: Как выявить ключевые мотивационные факторы в команде? Можете ли посоветовать распространенные практики?
Ответ: Я уже писал о своем взгляде на мотивацию сотрудников. По поводу конкретных советов – я бы дал только один, не смотря на то, что он похож на совет КО. Поставьте себе задачу по-настоящему докопаться до истинных мотивирующих факторов для каждого члена вашей команды. А дальше можно применять множество техник. Говорите с ними, задавайте правильные вопросы, пытайтесь узнать такие факторы в чужой для вас команде и перенести на свою, делайте изменения и смотрите на реакцию и т.д. Но не отступайте от своей цели. Иначе можно легко придумать правильный ответ, который на самом деле очень далек от реалий.