Весна постепенно набирает обороты. Март уже заканчивается и скоро наступят солнечные (мы искренне надеемся) апрель с маем. Мы запланировали много событий на эту весну. Что же вас ждет?

29 марта состоится 14-ая встреча «Клуба анонимных разработчиков». Мы смело можем назвать ее одной из самых интересных встреч – ведь будет рассматриваться «горячая» тема облачной разработки. На суд участников будут представлены доклады о разработке на облаке Amazon и Windows Azure. Поэтому каждый найдет для себя что-то интересное. Встреча пройдет в уютном офисе ДатаАрт по адресу Бехтеревский переулок 14Е. Начало в 19:00.

6-7 апреля состоится новый тренинг «Инженерные практики в Agile». 2 тренера (Николай Алименков и Алексей Солнцев) в течение 2-ух дней познакомят участников с 8-ью современными инженерными практиками. Будут затронуты вопросы внедрения, поддержания и пользы от этих практик. Все практики будут демонстрироваться на реальных примерах и включают в себя многолетний опыт использования наших тренеров. Это один из лучших наших тренингов. Группа почти набрана, осталось всего 5 мест.

13-14 апреля мы впервые проведем новый тренинг Дмитрия Ефименко под названием «Практики эффективного, но экономного проектирования». Дима вложил в этот тренинг весь свой опыт по проектированию программного обеспечения. Тренинг отлично сочетает в себе информацию о процессах разработки и проектирования, работу с требованиями, инженерные практики и подходы, анализ и управление рисками, а также несколько интересных практических заданий. Участники даже будут писать реальный код. Группа еще формируется и не поздно присоединиться к составу участников.

21-22 апреля состоится важное событие в мире тестирования – международная конференция SQA Days 11. Наш тренер Николай Алименков выступит на конференции с докладом «А вы знаете что тестируют ваши тесты?». В докладе речь пойдет о связывании тестов с самыми важными артефактами вашего проекта – требованиями и кодом. Николай на практических примерах продемонстрирует как полностью контролировать что и как тестируют ваши тесты. Помимо этого, 20 апреля мы проведем популярный тренинг «QA в Agile». Этот тренинг позволит участникам познакомиться с ролью тестировщика в Agile процессах, грамотно настроить процесс QA в Agile команде, разобраться с ролью автоматизации тестирвания и современными веяниями в мире тестирования. Тренинг будет полезен как менеджерам, так и обычным тестировщикам.

В апреле проходит еще несколько интересных конференций в России и Украине, но побывать везде просто не хватает времени. Вот некоторые из них: CodeFest 2012, Cloud Foundry Open Tour 2012, Software People’12, РИТ++, Quality Assurance Day’12, Fun ConfeT&QA. Мы также постараемся провести очередную бесплатную онлайн конференцию IT Brunch. Тема еще окончательно не выбрана, но в этот раз мы планируем сделать ее более технической.

28 апреля пройдет еще один наш новый тренинг «Успешный старт проекта». Сергей Поволяшко подготовил этот тренинг на основании своего многолетнего опыта управления проектами. На тренинге вы сможете узнать какие активности стоит проводить на стадии инициирования проекта, какие риски есть и как с ними бороться, как оценивать проекты с финансовой и временной точек зрения, что необходимо включить в контракт и как это сделать. Если вы менеджер и ваша работа связана со стартом новых проектов, то этот тренинг для вас!

27-28 апреля Александр Белецкий проведет свой новый тренинг «Веб-разработка с использованием ASP.NET MVC». Этот тренинг рассчитан на программистов, знакомых с концепциями ASP.NET, возможно уже имеющие опыт с Web Forms, но желающих приобрести практические навыки с новой, популярной технологией ASP.NET MVC. Тренинг очень насыщенный и на нем будут рассмотрены практически все аспекты разработки современных веб приложений с использованием ASP.NET MVC.

11-12 мая в Москве состоится очередная конференция для разработчиков Application Developer Days-3. На протяжении двух дней участники смогут посетить множество совершенно разных докладов на тему разработки, а также пообщаться с коллегами. Николай Алименков выступит с докладом «Разработка распределенных приложений на AWS», в котором поделится своим опытом (более 2-ух лет) в разработке приложений в облачной среде. Николай рассмотрит сервисы, предоставляемые Amazon (самым популярным облачным провайдером на данный момент) и даст множество полезных советов тем, кто начинает или только задумывается над переездом в облака.

19 мая мы уже во второй раз соберем Java разработчиков в Киеве на большую конференцию для Java практиков – JEEConf 2012. В этот раз мы собрали еще более интересную программу. Докладчики приедут в Киев с разных стран и будут освещать различные инструменты, методики и практики из мира Java. Николай Алименков выступит на конференции с докладом «За что я ненавижу Hibernate?», в котором рассмотрит недостатки одного из популярных ORM решений и способы их обхода. На данный момент уже более 300 участников изъявили свое желание участвовать в конференции. Это будет действительно яркое событие наступающей весны.

Перед конференцией мы организуем ряд тренингов, посвященных Java разработке: «JavaScript for Java developers», «TDD в Java», «Introduction to Java EE 6″. Все тренинги проводятся опытными профессионалами индустрии. Группы наполняются очень быстро, поэтому поторопитесь занять себе место в составе участников.

Завершит весеннюю гонку конференция AgileBaseCamp CREW DRILL в Харькове 26-27 мая. Это два дня, насыщенных докладами экспертов, воркшопами и вдохновляющими блицами. Панельные дискуссии и Open Space, демонстрации от практиков и два полномасштабных мастер-класса. Наши тренеры Александр Белецкий, Дмитрий Ефименко и Николай Алименков готовятся выступить с докладами. Программа конференции еще формируется.

А еще на апрель и май у нас запланированы корпоративные тренинги в Киеве, Днепропетровске, Воронеже и Москве. Приглашайте нас в свой город и мы с радостью приедем!

Вот такая интересная выдалась весна. Будем рады видеть вас на перечисленных мероприятиях!

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

Итак, первый тип «плохих» кандидатов – так называемые бегунки. Это люди, которые постоянно меняют работу и не могут проработать на одном месте больше полугода. Когда таких места 2 или 3, это еще не вызывает подозрения. В этом случае можно сослаться на неудачный опыт, быстрый карьерный рост, короткие проекты и т.д. Но если кандидат за 4 года сменил 6-8 проектов, то для меня это практически красный флаг. 

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

Приведу несколько примеров почему такие кандидаты встречаются. Наиболее распространенный типаж – «я работаю работу там где больше платят и лучше живется». Это значит, что при появлении на рынке более «жирной» вакансии этот человек может не раздумывая «подать на развод». 

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

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

В любом случае, с таким типом кандидатов лучше не рисковать. Я встречал их очень много и каждый раз оказывался прав. Некоторые заранее имели свои планы на работу в компании, дожидаясь выезда за границу. Другие начинали играть на проблемах и интересах проекта. Для себя я точно решил, что риск в подобных случаях совершенно неоправдан. Кандидат может оказаться адекватным, но ошибка будет стоить гораздо дороже.

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

Часто создается ощущение, что человеку эта работа вообще не так уж и нужна. Он может задавать встречные вопросы наподобие «а зачем мне это знать» или «почему мне задают такие вопросы». Из моего опыта точно так же кандидат будет относиться и к работе в вашей компании – не утруждать себя приходить вовремя на важные мероприятия, не заморачиваться детальным пониманием системы и технологий, выполнять только работу, за которую по его мнению ему платят. Работать с таким человеком в одной команде сложно. Мы работаем далеко не за маленькие деньги в IT индустрии и стоит нанимать только тех людей, которые хотят работать и понимают ответственность этой работы.

Удачного вам найма!

Как это принято, в конце года нужно подвести итоги проделанной работы, успехов и достижений. Этот год стал для нас действительно очень насыщенным. Даже не верится, что все удалось успеть. Итак, обо всем по порядку.

Мы провели первую в мире конференцию по Selenium – Selenium Camp. Участие в конференции смогли принять более 300 участников. Конференция получилась действительно международной, не смотря на то, что подавляющее большинство участников было из СНГ. Мы принимали гостей из Чехии, Эстонии, Молдавии, Великобритании, России, Беларуси и Украины. 17 докладчиков из различных стран представили вниманию участников 3 мастер-класса и 15 докладов. Эта конференция дала нам очень много опыта в организации масштабных мероприятий.

Вторым нашим достижением уходящего года стала международная конференция для Java практиков JEEConf. Эта конференция получила широкое признание, в том числе со стороны Oracle, и собрала более 400 участников из 8 стран. Конференцию посетили 6 докладчиков мирового уровня, среди которых авторы или ключевые разработчики популярных инструментов и библиотек для разработки на Java. В общей сложности участники могли посетить 2 мастер-класса и 17 докладов. Это было действительно успешное мероприятие. Мы получили немало позитивных отзывов от участников и докладчиков.

На JEEConf зародилось очередное наше начинание – «Клуб анонимных разработчиков». Это регулярные встречи разработчиков в неформальной обстановке. На каждом мероприятии обязательными атрибутами являются пиво, пицца или другие закуски, а также место для свободных дискуссий и общения. Формат клуба, прежде всего, направлен на то, чтобы каждый участник чувствовал себя комфортно, но в то же время получал полезную информацию из полноценных докладов, мастер-классов, подготовленных дискуссий, совместных разработок, обзоров инструментов и технологий. За полгода мы успели провести 10 встреч. Более 200 человек посетили клуб за время его существования.

Следующий проект мы запустили совместно с Тимофеем Евграшиным и назвали его IT Brunch. IT Brunch – это практические онлайн конференции, каждая из которых посвящена определенной теме из сферы IT. Brunch является производным от BR(eakfast) и (l)UNCH, то есть это приём пищи, объединяющий завтрак и ланч, можно назвать поздний завтрак в выходной день. Это время отлично подходит, чтобы провести его с пользой и узнать что-то новое. Чтобы принять участие в любой конференции IT Brunch вам не потребуется ничего, кроме компьютера, интернета и наушников. Вы можете участвовать в конференциях из дома, из офиса, в отпуске, на природе, вам не надо никуда ехать. Конференции проходят по субботам, один раз в 2-3 месяца, каждая онлайн встреча длится максимум 4-5 часов. Мы успели провести одну конференцию на базе IT Brunch под названием «В гостях у Agile практиков», в которой приняли участие около 200 человек.

Еще один небольшой проект IT Sport также был запущен в этом году. Пока он только развивается и направлен на развитие спорта среди специалистов из мира IT. Мы хотим, чтобы спортивные мероприятия в IT сообществе заняли свое почетное место. Ведь это интересное и живое общение, возможность получать настоящие эмоции, а также способ проявить себя. Пока мы провели только один шахматный турнир среди специалистов IT, в котором приняли участие 17 шахматистов. Дальше мы планируем развивать и другие виды спорта.

В завершение года мы провели еще одну масштабную и очень интересную конференцию XP Days Ukraine, целиком посвященную Agile инженерным практикам. Тематика инженерных практик и подходов выбрана не случайно. Ведь большую часть процесса разработки составляет именно написание кода. XP Days Ukraine – это больше чем просто конференция. В первые два дня конференции прошли 5 тренингов и 3 встречи с опытными иностранными разработчиками. Основной день конференции посетили около 300 участников, вниманию которых было представлено 19 докладов и 6 мини-докладов. Мы непременно продолжим развивать этот проект, потому что на наш взгляд у него большое будущее.

Кроме этого за год мы успели провести 27 тренингов, которые в общей сложности посетили более 300 человек. В этом году наш тренерский состав расширился и на данный момент состоит из 5 тренеров. Наши тренеры подготовили и провели 35 выступлений на различных конференциях, встречах сообществ и групп. А это очень неплохой результат.

В целом, этот год прошел удачно. Нам есть чем гордиться, но и есть к чему стремиться. Хотим пожелать вам успехов, удачи и всяческих благ в Новом Году!

Многие уже полным ходом готовятся к новогодним праздникам. И правильно – осталось ждать совсем немного. Первая половина января 2012 года однозначно пройдет в праздничной эйфории. Что же готовит нам вторая половина января?

28 января в Киеве пройдет очередная конференция AgileBaseCamp, на этот раз посвященная продуктовой разработке и имеющая название «From Idea To Product».

Экспорт ресурсов и создание продуктов – две полярные ментальности в сфере программной разработки. Аутсорсинг помогает отрасли идти в ногу с мировыми технологиями и подходами в работе. Однако, организаторы хотели бы сфокусироваться именно на продуктовой разработке, как процессе создания ценности.

Для кого эта конференция?

• Разработчиков, тестировщиков, специалистов по UI-UX, QA
• Менеджеров продуктов и топ-менеджеров продуктовых компаний
• Гиков и технологических предпринимателей

Какие темы будут затронуты в программе?

• Формирование идеи продукта
• Изучение пользователей и проектирование взаимодействия
• Инженерные и технологические аспекты разработки
• Построение команды и процесса создания ценности

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

Что делает этот кемп не похожим на другие?

• Организаторы пригласили спикеров с опытом создания продуктов, участия в стартапах или ведения собственного бизнеса
• Проводилось исследование интересов аудитории конференции для того, чтобы осветить популярные темы и ответить на острые вопросы

На данный момент еще есть возможность зарегистрироваться на конференцию по цене ранней регистрации – 750 гривен.

На конференции выступит один из наших тренеров, Александр Белецкий, с докладом «Continuous Delivery в продуктовой разработке». Continuous Delivery стал краеугольным камнем современной веб разработки и является современным трендом в высококлассных командах и компаниях. Это практический доклад, который будет интресен .NET разработчикам, а так всем заинтересованным в вопросах непрерывной поставки.

В преддверие конференции, 27 января, мы запланировали тренинг «QA в Agile». Это один из моих любимых тренингов, на котором тестировщики смогут лучше понять свою роль и подходы к работе, которые используются в Agile методологиях. Также им будет предложены несколько рабочих QA процессов в командах, работающих по Scrum. Много интересных презентаций, различные полезные практики и игровые симуляции делают этот тренинг очень познавательным и полезным. Вы можете узнать больше о тренинге и ознакомиться с отзывами в детальной программе тренинга. Регистрация на тренинг уже открыта и количество мест ограничено.

Таким образом, конец января получится достаточно интересным. Будем рады вас видеть!

Мы подготовили совершенно новый тренинг «Метрики: команды, проекты, процессы и код», который впервые пройдет в Киеве 10-11 февраля. Этот тренинг посвящен одному из наиболее важных инструментов в руках любого руководителя – метрикам. Ведь еще Том Демарко говорил: «Невозможно управлять тем, что нельзя измерить».

С чем зачастую сталкиваются проектные команды, отделы и целые компании?

• Непредсказуемость сроков окончания проекта
• Наличие только лишь экспертной оценки объема работ, которая не всегда точна
• Регулярное пожаротушение определенных проблем, а не устранение источников их происхождения (почему много дефектов? где наибольшая проблема? требования, планирование, коммуникации или что-то еще?)
• Применение метрик без цели или их неправильная интерпретация
• Несоответствие используемых метрик тому, что действительно нужно конкретному проекту, по конкретному контракту, конкретному заказчику
• Кажущиеся сложность внедрения измерений и бюрократичность процедур измерений
• Невозможность прогнозирования качества и количества работы
• Принятие решений, основанное на субъективных ощущениях

Что делать?

Во-первых, хорошо разобраться в том, а зачем мы вообще что-то хотим измерять в конкретной компании или в конкретном проекте? Какая польза от измерений?

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

В-третьих, и это, наверное, самое важное, должна быть «политическая» воля со стороны руководства компании или проекта по внедрению и поддержке измерений.

Обычно, в том или ином виде, измерения применяются и развиваются, но происходит это довольно долго, и не всегда эффективно.

Поэтому, основная идея тренинга – помочь компании или проекту быстрее понять, зачем и какие измерения нужны, как их внедрить и интерпретировать. Тренинг структурирует теоретическую подготовку в области измерений и вырабатывает эффективный подход к практическому применению измерений. Что важно, вырабатывается понимание выгод измерений для бизнеса, заказчика, проектной команды. Общая направленность на практическое применение. Интерактивное изложение теории и практическая работа в группах, множество практических заданий и кейсов из реальной жизни. Тренинг направлен на практическое применение измерений (метрик) при разработке ПО в проектных командах.

На тренинге будут рассматриваться различные виды метрик: проектные, процессные, качества и кода. Участники смогут получить представление о том, какие метрики стоит использовать в современных Agile методологиях (Scrum, Kanban), а также как и когда их собирать и анализировать. Качество кода также не будет забыто и участникам будут предложены разнообразные методики и инструменты для сбора и контроля метрик кода, не позволяющих проекту «скатываться» на уровень «говнокода».

Вести тренинг будут Сергей Поволяшко и Николай Алименков. Стоимость участия – 1700 гривен за участника (обед включен). При групповой регистрации возможна скидка. Регистрация уже открыта и количество мест ограничено. Торопитесь занять себе место на этом полезном тренинге!

Я решил поучаствовать в разборе кейса, описанного Тимофеем Евграшиным в его блоге. Сначала начал писать комментарий, но потом понял, что он будет слишком большим. Поэтому оформляю в виде отдельной статьи. Вкратце проблема выглядит так – команда никогда не заканчивает все задачи в итерации, перенося их на следующую. В итоге итерации получаются размазанными.

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

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

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

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

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

Теперь разберемся, что же со всем этим делать. Задачи понятны. Я бы посоветовал реализовать следующие подходы:

• Планируйте ровно на столько, сколько вы можете полностью закончить в итерацию. Не тратьте время на планирование остального. Это и сэкономит вам время и не будет никому давать несбыточных обещаний. Лучше возьмите еще работы, если все закончите в срок. Это будет гораздо приятнее и команде и заказчику, чем в очередной раз получить часть обещанного не готовым.
• Для более плотной командной работы над задачами и инкрементальности внутри итерации установите лимиты на количество задач, которые находятся в прогрессе. Причем жесткие и непоколебимые лимиты. Они будут вас заставлять помогать друг другу, делить большие задачи на маленькие, автоматизировать ручную работу и не распыляться на много задач сразу. Это повысит вашу эффективность.
• Для решения проблем с циклом тестирования внедряйте активно автоматизацию. Причем не просто автоматизацию, а различные вариации TDD (Test Driven Development). Чем больше тестов будет написано до завершения реализации задачи, тем меньше времени уйдет на тестирование. Еще одна практика, которая очень сильно может помочь – Slicing Development. Не разрабатывайте по несколько дней целиком готовую фичу. Вместо этого выкатывайте несколько промежуточных реализаций с урезанной функциональностью и отдавайте на тестирование.
• Ну и последний совет очевиднее всех – проведите ретроспективу и разберитесь в том, что происходит. Если команда или руководство не понимают зачем это все нужно, то все предыдущие усилия будут просто бесполезны. Возможно, в результате разбора окажется, что Scrum в вашем случае совершенно не подходит. Такое тоже бывает. Scrum – не серебряная пуля.

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

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

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

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

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

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

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

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

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

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

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

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

Вчера посмотрел запись Сергея Бережного «Путь овертаймов» и понял, что изложить свои мысли по этому поводу в виде короткого комментария не получится. Мое личное отношение к овертаймам менялось по ходу развития карьеры в IT. Об этом я и расскажу в данной статье.

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

Все дело в том, что почасовая оплата не настраивала на благородство и дармовое сидение в офисе до тех пор, пока не уснешь за клавиатурой. Овертаймы оплачивались по полуторной ставке, что для студентов было как манна небесная. Можно было при желании получить денег гораздо больше, чем все знакомые студенты. А это в том возрасте была та еще мотивация. Определенную положительную роль играл свободный график. Забежал в субботу с утра часа на 4-5, а остальной день свободен. В воскресенье заехал на пару часов после обеда, в будние остался на несколько часов попозже и т.д. Организм то молодой и восстанавливается очень быстро. Усталость практически не накапливалась и продуктивность не падала. В итоге оставались довольны и волки и овцы (не буду говорить кто есть кто ). Стоит отметить, что такие мини-авралы были непродолжительными – 2-3 недели максимум.

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

Но, что более интересно в данном случае, овертаймили тогда на энтузиазме. «Мы же команда…», «мы сможем, мы же профессионалы…», «поднажмем и выручим заказчика…» – эти фразы вселяли уверенность в собственных силах и мотивировали нас на свершение подвигов. Это очень похоже на ситуацию, которая описана в записи Сергеем. Полностью согласен, что заказчику выгодно не думать и не вмешиваться в происходящее. Ведь ребята молодцы и сами вызвались «помочь». А менеджерам выгодно выбивать из команды максимум для поднятия своего рейтинга. В качестве дополнительных целей они просто видят возможность не париться сложными переговорами по поводу объема выполняемых работ, при этом добиваться поставленных целей и оправдывать свои зарплаты. А платит за это кто? Да никто! Ведь за энтузиазм можно только получить бонусы, а они вовсе необязательны. Могут быть, а могут и не быть. Уже после пары таких овертаймов я серьезно задумался над правильностью такой модели.

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

• Если планы делаются и утверждаются «на небесах», то я не буду овертаймить даже за деньги из принципа. Ведь мои овертаймы и потраченные силы, время и нервы будут идти на поддержку старой модели планирования, в которую я не верю и считаю ущербной. Планы должны проваливаться, чтобы никто не мог оправдывать свои неправильные подходы и внедрялись изменения.
• Никакого энтузиазма и идеализма! Овертаймить можно только за деньги и только тогда, когда есть желание и время. В современном мире ваши отношения с компанией-работодателем строятся исключительно на взаимовыгодных условиях. Как только вы станете невыгодны компании, она от вас избавится. И не надо думать, что вы особенный. В аутсорсе особенных не бывает. Никто не купит вам потом свободное время с друзьями, семьей и родственниками. Его просто не вернешь.
• Продуктивность при овертаймах реально падает, причем в разы. Усталость дает о себе знать, экспоненциально растут ошибки, эффективность падает все больше и больше. В итоге люди ругаются, злятся и нервы не выдерживают. И вы входите в «колесо плохого качества», когда вы все больше работаете, но все меньше делаете полезного для проекта.
• Надо иметь смелость сказать «нет». «Мы команда» и прочие пропагандируемые менеджментом принципы нечестны. Они в основном давят на слабых и поддающихся влиянию членов команды. И не стоит смотреть что делает большинство. У каждого своя позиция. Если вы хорошо делаете свою работу, за которую вам платят деньги, то это ваше право отказаться от работы сверхурочно. И стоит научиться этим правом пользоваться.

Резюмируя, хочу сказать, что овертаймы не всегда являются злом и на коротком отрезке могут выручить вашу команду. Особенно в случае, когда кто-то заболел или ушел в отпуск. Но не стоит бороться за мифическую победу или цель, за которую никто не готов платить. Это мое мнение и я вам его не навязываю. Просто призываю задуматься…

Я слышал очень много нареканий в сторону Agile подходов по поводу стремления к кроссфункциональности в командах. Обычно в критических материалах приводятся достаточно идиотические примеры. Вот парочка из них:

• «Ага! Давайте задействуем уборщицу! Она будет у нас заниматься базами данных по совместительству!»
• «Ну и как, скажите мне пожалуйста, тестировщик сможет заменить разработчика? Он же не умеет программировать!»
• «Ну-ну! Интересно что натворят junior разработчики в базе данных…»

Я расскажу о своем взгляде на эту проблему. Каждый из нас обладает определенным рядом навыков и опытом их применения. В зависимости от этих навыков мы можем делать различную работу с разным уровнем эффективности. Для меня кроссфункциональная команда характеризуется прежде всего возможностью членов команды делать некоторую часть работы вне своей основной зоны компетентности. Не факт, что эффективно. Не факт, что супер-качественно. Но может. Я даже не пытаюсь добиться полной замены других членов команды. Зачастую это просто невозможно. И я тоже не верю в то, что каждый тестировщик может писать код достаточного качества напрямую в production. Но любая работа состоит из частей. И не все части одинаково важны и требуют мега-навыков.

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

Работа HTML верстальщика также состоит из нескольких частей (снова грубое деление): верстка базовой версии HTML страницы, прикручивание основных стилей, хаки и правки под разные браузеры. И снова та же история. Только последняя активность требует критических навыков. Первые две активности достаточно адекватно может сделать и веб-разработик (в моем понимании не только может, но даже обязан уметь их делать).

Еще один мифический персонаж – DBA. У него вообще огромное число возможных активностей (и опять я груб): раздача прав на базы, создание схем, тюнинг запросов, модификация и миграция данных и т.д. Большая часть из них относятся к административной работе и может быть автоматизирована. Или выполнена разработчиком с последующим ревью DBA.

Но зачем все это нужно? Я вижу 3 цели у кроссфункциональности в моем понимании этого термина:

• Возможность балансировать нагрузку между членами команды, чтобы избежать простоев и затыков в работе
• Возможность частично заменить члена команды, который ушел в отпуск или банально заболел, и не останавливать процесс разработки
• Дать возможность членам команды сменять на некоторое время сферу деятельности, что стимулирует профессиональное развитие и делает работу разнообразнее

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

Многие очень сильно ругают аутсорсинг и любят сравнивать его с продуктовыми компаниями, видя в последних просто райский уголок для разработчиков. Я решил стать на защиту аутсорсинга и напомнить всем, что мы получили благодаря ему и каких проблем избежали на рынке IT. Сразу хочу предупредить, что все изложенные мысли в данной статье основываются на моем личном восприятии увиденного и услышанного во время посещения мероприятий (конференции, встречи, тренинги) в различных городах и странах, а также на опыте работы в Украине и Беларуси. Прошу не воспринимать все сказанное на свой счет и тем более не обижаться.

Начнем! Почему все таки аутсорсинг? Тут все просто. Мы находимся на первом «рубеже обороны» между Европой и огромной территорией «Востока» (Россия, восточные и азиатские страны). Поэтому мы отлично подходим для ведения IT бизнеса: недалеко расположены, близки по менталитету (по сравнению с «Востоком») и достаточно недороги (были когда все только зарождалось). Еще у нас достаточно неплохое образование и низкий уровень жизни, что делает профессию IT специалиста действительно престижной (далеко не самой, но все же). Именно поэтому в наши страны ломанулись западные компании. Сейчас ситуация немного меняется, но очень медленно. Мы дорожаем, образование ухудшается, но мы по-прежнему недалеко расположены и хватает специалистов «старой закалки». Поэтому аутсорсу в наших странах еще жить и жить. Я имею ввиду Беларусь и Украину. Хорошо ли это или плохо? Давайте разберемся!

Для сравнения я возьму Россию. Причины просты: мы территориально соседи, тот же менталитет, были когда-то единым государством. Глупо брать Англию и пытаться сравнивать достижения в IT бизнесе с Украиной.

Первый плюс аутсорсинга – это знание английского языка. Это колоссальное преимущество. Почему? Да потому что знание английского языка тянет за собой очень много других плюсов. Дело в том, что все основные современные тенденции в разработке создаются и устанавливаются в Европе и США. Все современные книги о разработке пишутся на английском языке. Практически все современные инструменты для разработки делаются тоже на англоязычный рынок. В России очень много продуктов делается на локальный рынок. И это понятно – огромная страна, в которой огромное количество направлений бизнеса. Но это означает русскоговорящих заказчиков и менеджеров. Что в свою очередь совершенно не требует знания иностранного языка. А он, как известно, без практики очень быстро погибает. И быстро приходит ситуация, когда подавляющее число разработчиков совершенно не знает английского. А это очень сильно бьет по самообразованию. Многие проекты и даже компании начинают жить в замкнутом мирке, время от времени в который попадает лучик света с какой-нибудь конференции или тренинга.

Очень показательным примером является язык для слайдов на конференциях. В России это на 99% русский язык. В Украине это на 70% английский язык. Даже на тех конференциях, на которых подавляющее большинство русскоговорящих. И это правильно. Потому что слайды презентации могут быть опубликованы и просмотрены человеком из любой страны мира. Вы можете получить на порядок больше обратной связи. Вам не нужно извращаться и переводить непереводимое (ведь многие термины не имеют аналогов в русском языке).

Второй плюс аутсорсинга – это общение. Много общения. Оно и логично. Ведь зарубежные компании очень сильно хотят быть в курсе как идет работа тут, в центре аутсорсинга. Ведь мало кто может сразу начать доверять совершенно незнакомым людям, да еще и находящимся далеко от вас. А общение порождает обмен мнениями, техниками, проблемами, решениями, практиками, подходами и т.д. А все это очень сильно развивает индустрию IT. В России ситуация совершенно другая. Очень много государственных проектов. А там всем плевать на общение. Основная задача – «окучить бюджет». Говорю не по наслышке, так как долгое время принимал участие в разработке системы документооборота для мэрии Москвы. ТЗ, море аналитиков, тотальный контроль, отсутствие конечного заказчика – вот характеристики таких проектов.

Третий плюс – внедрение Agile подходов. Не секрет, что Agile сообщества в Европе и США развиты на порядок лучше, чем у нас. Практически все основные методологии были придуманы и описаны там. Agile принципы распространяются очень быстро и приходят к нам с каждым новым проектом, с каждым новым заказчиком. В России с этим очень туго. Локальные заказчики очень далеки от Agile. Реально оооочень далеки. Я, приезжая на конференции в Россию и общаясь с участниками, попадаю в совершенно новый мир. Их проблемы просто неведомы нам. Многие компании и проекты работают просто по диким методикам и непонятно как умудряются хоть что-то выпускать. А то, что они выпускают, непонятно как можно использовать.

Ярким примером тут может случить банальный вопрос – «А вы пишете модульные тесты?». У нас их пишут или хотя бы хотят писать почти все. В России очень мало человек. Реально, есть целые компании, где не пишут модульных тестов в принципе. Нет смысла даже лезть в более глубокие сравнения. Этого вполне достаточно.

Четвертый плюс – это бешеный спрос на рынке. Этот спрос, с одной стороны, дает нам возможность жить спокойно и быть уверенным в завтрашнем дне. А с другой стороны, он дает нам большие возможности роста и саморазвития. Требования к кандидатам растут и появляются все новые и новые варианты для действительно талантливых разработчиков зарабатывать очень достойные деньги. Рынок постоянно находится в постоянном движении.

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