"Встречают по одежке" или Артефакты Первого Контакта

Добрый день!

Когда задумываюсь, почему в компанию не так легко привлечь классных программистов, в первую очередь начинаешь вспоминать свои собственные оценки компаний по первому впечатлению. Новая работа, новая машина, новое знакомство - все это подвержено эффекту первого впечатления и если на входе в XXX-Soft ты столкнулся с ковыряющимся в носу програмером в затертых домашних тапках и грязной чашкой с кофе в руках, то вот не станешь ты там работать (ну это я про себя :) - у всех разные пунктики).
А вот если в вашей компании есть практика интервью в несколько этапов, когда сначала кандидат пишет тестовое задание(кодит), общается с HR, заполняет анкету и лишь на следующем этапе сталкивается со своими будущими товарищами по оружию, то что для него (кроме затертых тапочек) важно? Что дле него - лицо компании-работодателя?

1. Имидж компании - то, что он знал до прихода на интервью. Он либо есть, либо его нет. Для многих софтверных компаний со штатом менее 200 человек его почти что нет. За исключением ярких продуктовых компаний для которых узнаваемость бренда для кандидатов - это побочный эффект от работы отдела маркетинга и рекламы, направленной на совсем другую целевую аудиторию.
   
   
   
2. HR-отдел - саааамое первое, что кандидат узнает о компании, это то как ее рекрутинг пишет письма и разговаривает по телефону. HR бывают девочки и мальчики. Девочки привычнее, так что когда с тобой связывается HR-мальчик, то сразу как-то становится интересно, что это за контора такая? :) Но в целом, в меру профессиональный HR который способен общаться на удовлетворительном деловом уровне и представляет себе область в которой он работает имеет скорее нейтральный pH. То есть воодушевить кандидата ему вряд-ли удастся, поэтому основная задача рекрутера в компании - найти кандидата и бережно передать дальше.
   
   
   
3. Артефакты первого контакта - сайт компании, документы о компании, которые высылает HR для кандидатов, анкета, тестовое задание, офис компании, точнее несколько его ключевых (для первого контакта) мест:
   
   - бизнес-центр, где размещается компания, точнее его фасад и холл
   - коридоры компании
   - кабинет, в котором проводится собеседование с HR
   - кабинет, в котором проводится выполнение тестового задания и заполнение анкеты
   - кабинет, в который тоже захочется сходить, особенно если интервью затянется
   
   Ужас! До чего я договорился - "Сортир - лицо компании!" :) Шутки-шутками, но для меня, например имидж Microsoft был несколько подпорчен тем, что в их офисах в Редмонде перегородки между кабинками едва достигают подбородка.
   Впрочем, думаю, что это суровые американские принципы секьюрити направленные на защиту мирных граждан от угрозы мирового терроризма. Иначе что заставило уважаемую компанию превратить свои "места отдохновения" в прототип игры "Убей Крота!" (по крайней мере это очень похоже на нее когда ты моешь руки в умывальнике и вдруг видишь в зеркало как у тебя за спиной из-за перегородки появляется чья-то голова...а потом еще одна - по соседству :)
   

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

1. Бизнес-центр (или Ваше здание) - серьезный замах. Думаю, что эту тему мы сейчас не будем даже затрагивать, так как для многих компаний это данность, изменить которую в контексте работы с кандидатами несколько нерентабельно
   
2. Коридоры _вашего_ офиса - ага! Уже ближе! Это уже территория компании и бюджет для интерьерных изысков выглядит более адекватно, чем переезд в бизнес-центр класса А+. Тем более, что в этом аспекте гораздо важнее творческий подход и свежесть идей нежели кисти с бахромой и золотые канделябры. Достаточно вспомнить впечатления господина А. Орлова увековеченные в его статье. Тут главное - отодвинуть подальше бубнил и зануд, призывающих к серьезности и умеренности - большая часть штата IT-компании - молодые ребята, которым эта серьезность в печенках сидит.


3. Помещение для собеседования с HR. Итак, это первое помещение, в которое попадает кандидат. Если мы говорим о разработчике (программист, тестер, дизайнер...), то он понимает, что это помещение - не его рабочее место, но по тому, как оно организовано, можно сделать первые выводы о компании. Например (если это - комната для совещаний):
   - Наличие этой самой комнаты. Ведь когда в компании нет комнаты для совещаний, то это первый признак экономии на сотрудниках. К счастью, в большинстве компаний сейчас таковая имеется.
   - Обстановка (мебель) в комнате. Ага, смотрите - в переговорную притащили поломанные стулья со всей конторы, разваливающийся стол и сгнивший фикус, а на стене висит грязная доска метр на полтора! Как вы думаете, кто-нибудь в этой компании думает о том, что бы сотрудникам было комфортно работать здесь?
   - Мелочи (канцелярия). Воистину прекрасны компании и совершенен офис-менеджмент если Вы видите в комнате для совещаний вдоволь маркеров для доски, стопки бумаги для записей, карандаши и ручки. Сразу предупрежу. Это - колоссальная редкость, признак серьезных компаний обычно западного капитала.
   - Оборудование. Стационарный проектор, оборудование громкой связи или теле/видео-конференции, powered-table (стол с разводкой всяких кабелей и прочее). Это - признак супер-крутости компании в части заботы о рабочем месте сотрудника...или просто стремление руководства к пафосу "как в микрософте".


4. Помещение для выполнения тестового задания.
   Здесь кандидат, скорее всего, столкнется уже с чем-то, что возможно, позволит ему представить свое будущее рабочее место. Рабочий стол, кресло, компьютер - то, что окружаем разработчика 8 и более часов в день. Поэтому, когда его приводят в комнату площадью 2 квадратных метра и сажают за замызганный комп на шаткий стульчик, то темная сторона начинает одолевать даже самых продвинутых джедаев. Вот несколько советов, как заставить медихлорианы в мозгу кандидата крутиться в нужном направлении:
   

   
   
   • Выделите нормальное помещение для работы кандидатов. Как вариант - установите нормальный комп (или выделите лэптоп) в комнате для переговоров. В идеале это помещение должно говорить кандидату у том, какое у него будет рабочее место
     
   • Поставьте туда классную мебель (может даже получше чем на рабочих местах) - стеклянный стол, удобное дорогое кресло на колесиках
     
   • Компьютер должен быть адекватной производительности и конечно же с хорошим TFT-монитором не менее 21". Клавиатура и мышь должны быть новыми и чистыми. Всегда.
     
   • Подсказки. Возможно, у кандидата во время выполнения задания появятся какие-то бытовые вопросы или он закончит раньше времени. Составьте яркий короткий мини-хелп (с контактами HR, расположением туалета, кофе-машины и т.д.) на ламинированной бумаге и оставьте его на кандидатском рабочем месте.
     
   • Мелочи(канцелярия). Все то же самое, что и о помещении для собеседования с HR.
     

   
   

Ну и все же обратите внимание, есть ли в туалете туалетная бумага...а то ведь неловко будет...

Наша работа

Нашел весьма жизненный микро-комикс о работе IT-шников...

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

О "троллях" в команде

Всем привет!

Позволю себе небольшой копипаст из своего доклада на AgileDays'09. Речь пойдет о так называемых "троллях". Как известно, "тролль" в agile-энциклопедии - это член команды, который преследует цели, конфликтующие с целями команды в целом. Обычно, это человек с явно деструктивных характером поведения, влияние которого и на проект и на остальных членов команды негативно. Например, команда стремится сделать проект качественно и в срок (ну вот так вот абстрактно :) ) а этот "нехороший человек" каждые полчаса громко жалуется "ну что за г@вняный проект у нас", "ну когда уже мы, наконец завалим этот проект". Так же он может саботировать сессии планирования, ретроспективы да и что там говорить, при попустительстве со стороны остальной команды(или менеджера) он реально способен убить проект и/или команду.

Так что же делать, если вы наблюдаете рядом с собой подобный персонаж? Уважаемые гуру от Agile здесь весьма категоричны (что, обычно, им не свойственно) и едины. "ГНАТЬ ИХ К ЧЕРТОВОЙ МАТЕРИ!" - вот чему нас учат... видимо, когда agile-доки сталкиваются с такими "диверсантами", у них уже просто лопается терпение и они выходят из своего коуч-образа, становясь, наконец, обычными людьми :)

И в этом они, на мой взгляд, неправы! Такой подход ведь противоречит всему, что нам рассказывают о правильном agile-менеджменте. Ведь когда кто-то тупит и говорит "я не знаю как делать эту задачу" мы же не орем на него типа "ты идиот, Тауб! Это же аутоимунное!"...неееет! Мы начинаем его коучить, и коучим его пока он сам не придумает как таки сделать задачу. Для чего - что бы люди росли и развивались и были self-managed и мир вокруг был полон весны...

Так давайте вспомним о терпимости и в ситуации, когда мы сталкиваемся с троллями! Тем более, что настоящих natural borned троллей - единицы. Их просто обычно не нанимают и они заканчивают свои дни ненужными никому неудачниками. Или, если они достаточно умны, они получают должность главы отдела диагностики в больнице Принстон-Плейсборо. Остальные проявления троллизма - это симптомы некоей "болезни" профессионального или личного характера. Может, от кого-то ушла жена или программист недоволен своим менеджером или проектом.

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

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

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

Многие знания - многие беды. О собеседованиях

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

Забавно, что сегодня как раз интервьюировал кандидата на позицию Java разработчика. Надо сказать, что я программировал на Java последний раз лет эдак 6 назад :)

Естественно, что знания у меня о данном предмете остались весьма поверхностные. Но ведь вот в чем штука: мы уложились ровно в два часа (это, поверьте, немного)! И решение мы приняли вполне взвешенное! Удивительный эффект.

В чем сила XP-2

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

Помимо того, что некоторые элементы процесса приносят в него дополнительную ценность, существует второй аспект, который может потребовать введения того или иного принципа или инструмента. Некоторые элементы не только приносят конкретную ценность в проект, но и поддерживают другие практики процесса. Давайте продолжим препарировать XP, раз уж начали, тем более, что все эти принципы и практики по отдельности - все из области Agile, что делает данную статью не столь сильно привязанной к XP.

• Onsite Customer
• Pair Programing
• Collective Code Ownership
• Planing Games
• Coding Standards & Conventions

Перечисленные элементы образуют коммуникационную среду проекта, реализуя принцип Agile "меньше документации - больше кода". Сказать, что это некая ценность я не берусь, так как Agile сам по себе не является таковой с точки зрения проекта. В то же время мы понимаем смысл и предназначение этого набора и можем отдавать себе отчет в том, какие функции выполняют эти элементы. Нельзя, конечно, сказать что это полный набор средств коммуникации (даже напротив - для нормального процесса, на мой взгляд, этого мало :)), однако, надо понимать, что если вы начинаете из этого набора что-то выкидывать, то скорее всего вам придется заплатить за это дополнительной писаниной (переписка по e-mail, wiki, etc).

• Рафакторинг

Рефакторинг с одной стороны поддерживает TDD (который без него просто не работает), с другой стороны(как уже было сказано в первой части этого поста) позволяет привести в порядок код, написанный в концепции KISS, YAGNY и прочий "simple design". То есть, не дай бог у вас в проекте по XP вы начинаете экономить на рефакторинге - иначе готовьтесь получить отсутствие TDD и абсолютно не сопровождаемый код.

• Pair Programing

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

Эта статья (обе ее части) - это, по сути, обобщенное упражнение по анализу процесса. Здесь я постарался показать, как могут быть связаны элементы вашего процесса и о чем стоит помнить, добавляя или удаляя элементы из него.

Спасибо!

Лучшая презентация

Всем привет!

Несколько месяцев назад, перед проведением AgileDays'09 организаторы решили провести скайпференцию для докладчиков-новичков дабы помочь им в подготовке к выступлению. Мы говорили о том, какой должна быть хорошая презентация и само выступление.

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

1. Короткий

На сегодняшний день мой опыт говорит мне, что за 1 час можно сказать почти все :) То есть этого времени гарантированно достаточно, что бы для каждого слушателя в лекции была явная ценность. Что бы выйдя из аудитории каждый мог сказать: "Я не зря потратил время!".

Самый сложный предмет действительно _возможно_ декомпозировать на короткие лекции. Проверено на практике! Иногда бывает очень жалко резать собственную презентацию, выкидывая оттуда яркие, интересные, но ненужные слайды, но в результате Вы получаете настоящий бриллиант - лекцию, насыщенную материалом, без "воды" и сфокусированную на определенной проблеме.

2. Яркий

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

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

И наконец, используя яркие образы Вы можете контролировать эмоциональное состояние аудитории. Дело в том, что даже при такой небольшой продолжительности доклада как 1 час половина слушателей может заснуть. Хороший способ не дать им сделать это - постоянно "раскачивая" их эмоциональное состояние. На мой взгляд, нужно использовать тактику периодических нерегулярных всплесков. Т.е. в начале лекции даем сильный толчок каким-нибудь ярким образом, затем - просто загружаем информацию в слушателей. Но при этом необходимо периодически, раз в 10-15 минут повторять такие вспышки. Тогда слушатели будут в нужной кондиции все время лекции.

3. Структурированный

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

4. Анимированный

Спасибо PowerPoint за чудо анимации! Благодаря этому инструменту даже абсолютно проавльный слайд из 10 "буллетов" можно спасти. Просто сделайте, что бы каждый "буллет" вылетал по вашей команде - это сделает слайд "живым" и избавит вас от ситуации, когда аудитория уже прочитала ваш слайд целиком и, зевая, слушает как вы читаете с экрана. Помимо этого, используя анимацию, Вы можете показать работу каких либо процессов. Меня вот, например, торкнуло и я заанимировал алгоритм работы Taskboard для Scrum и для Kanban - получилось просто феерически + наглядно, что гораздо выигрышнее последовательности статичных слайдов с вашими комментариями о том как тут все должно двигаться.

В чем сила XP

Хотя чистый XP сейчас и мало кто использует, в основном, комбинируя практики из XP с другими процессами, я все же хочу немного разобраться с тем, из чего, собственно состоит Экстремальное Программирование. Итак, вот основные практики, принципы и правила XP:

1. Onsite Customer
2. Small Iterations
3. Simple Design
4. Continuous Integration
5. Refactoring
6. TDD
7. Coding Standards & Conventions
8. Pair Programing
9. Collective Code Ownership
10. Planing Games

А теперь давайте посмотрим, какую функцию выполняет тот или иной компонент XP в процессе. Итак:

1. Onsite Customer + Small Iterations + Simple Design

Распишем, что это значит: команда имеет возможность взаимодействия с заказчиком "на-лету" для получения новых/измененных требований и предоставления результатов работы на ревью. При этом за счет коротких итераций ставятся близкие задачи, результат работы над которыми обсуждается с заказчиком и принимаются меры по корректировке курса. А за счет простых технологических решений команда может выдавать конкурентоспособный темп.

Итого:

Onsite Customer + Small Iterations + Simple Design = Maximum Agility

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

2. Continuous Integration + Refactoring + TDD + Coding Standards

Максимальная гибкость, которую мы реализовали с помощью практик из пункта 1, к сожалению, чревата проблемами с качеством. Да и в принципе в любом технологическом процессе должны быть инструменты для контроля и обеспечения качества. И вот за счет чего мы гарантируем качество в XP:

Непрерывная Интеграция позволяет быстро выявлять и исправлять ошибки кодирования. Рефакторинг приводит в порядок тот код, который появляется под флагом "Simple Design", да и для TDD он необходим как воздух. Сам TDD позволяет поддерживать принцип "SimpleDesign". Стандарты кодирования помимо положительного влияния на качество, так же необходимы для другого принципа XP, который будет упомянут ниже - Совместное Владение Кодом.

Итого:

Continuous Integration + Refactoring + TDD + Coding Standard = Quality Assurance

3. Pair Programing + Collective Code Ownership + Planing Games

Это значит, что вся команда вместе планирует задачи, по ходу уточняя и разъясняя для каждого суть задачи и особенности ее реализации (да-да-да...и убивая часа по 2-4 на Planing Session в каждой итерации). А потом вся команда дружно программирует, меняясь парами и осуществляя перекрестное Code Review. За счет этого нам становятся не страшны такие вещи как неожиданная болезнь ключевого разработчика, отпуск, перемещение на другой проект, увольнение ( :) ) и прочая фигня, которая иногда так некстати сливает все планирование в унитаз. Так же мы снижаем затраты на ввод новых разработчиков в команду.

Таким образом:

Pair Programing + Collective Code Ownership + Planing games = Reliable Process

Итак, мы определили, что заявленные компоненты XP дают нам следующие ценности:

1. Высокая Гибкость
2. Высокое Качество
3. Высокая Надежность Процесса

В следующем посте мы рассмотрим, какие еще существуют взаимосвязи между элементами XP, например, за счет каких практик мы можем минимизировать объем документации.

Скованные одной цепью

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

1. Каждый элемент процесса приносит в него новую уникальную ценность.

Попробуйте проверить элементы Вашего процесса - каждый, по очереди, взять, осмотреть и спросить себя и остальную команду: "А зачем нам это?". Возможно, вы найдете "5-е колесо", а может, поймете, что у каждого члена команды свое видение процесса, по которому вы работаете :)

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

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

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

3. Проводите такие упражнения регулярно.

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

Веселые аналогии

Работая над одним докладом я задумался о красочных аналогиях и метафорах, которые так необходимы если я хочу сделать лекцию о Scrum интересной для аудитории, которая живет не в низовьях Амазонки, а в дельте Невы и про "этот Scrum и прочий Agile" уже слышавшая более чем достаточно.
И вот какие образы у меня получились:
1. Скрам-мастер - это малыш Фродо Бэггинс. Милый парнишка с большими голубыми глазами и бойкими кудряшками. Свой парень в деревне и вообще душка. Но вместе с тем он несет бремя ХРАНИТЕЛЯ! Тут аналогия становится совсем полной - у Фродо есть Кольцо, а у Скрам-мастера даже больше:

• С одной стороны Скрам-мастер - хранитель КОМАНДЫ. Он помогает ей решать внутренние проблемы, сам решает внешние проблемы и устраняет препятствия для своих друзей-хоббитов.
• С другой стороны Скрам-мастер - хранитель ПРОЦЕССА. Начиная с проведения всех митингов и заканчивая контролем выполнения решений принятых командой на ретроспективе.

2. Product Owner - аналогия из другого мира - футбольный тренер. Да-да-да... знаю! Аналогия не свосем точная и полная, зато выпуклая. Смотрите:

• Тренер определяет цель и стратегию работы команды на протяжение длительного периода: определяет график тренировок, готовит команду к успеху как в каждой игре, в сезоне в целом и в дальнейшей перспективе.
• Тренер определяет цель и тактику работы команды в течение одной игры, дает рекомендации игрокам. Причем делает он это во время перерывов (ретроспектив).
• Хороший тренер не говорит Аршавину как переставлять ноги чтобы бегать быстрее. За реализацию цели игры отвечают сами игроки.
• Тренер определяет приоритеты для команды. Например, он не напрягает своих ребят на чемпионат Европы ради того, чтобы лучше подготовиться к кубку UEFA.

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

Спасибо!