• Жизнь через упражнения

    Posted on May 13th, 2009 Александр Орлов 5 comments

    Где-то через несколько месяцев после поступления в Интел нас вывезли в Ирландию. На обязательный для всех Интеловских менеджеров тренинг – Managing Through People. Тренинг проходил 5 дней в старом добром ирландском отеле. Где в фойе стояла старинная на вид мебель, а доброжелательный частично украинский персонал с готовностью наливал хорошего Гиннесса. Которого мне попробовать не довелось, потому что на тот момент шел как раз третий год моего личного сухого закона. Но вернемся к делу…

    Идея тренинга была проста – собрали около сотни Интеловских менеджеров, и всех разбили на команды. Причем разбили так, чтобы в одной команде ни у кого не было знакомых. Командам предстояло провести вместе 5 дней, чтобы в различных упражнениях пройти все стадии модели Такмана: Forming -> Storming -> Norming -> Performing. Тренинг, в общем, был примечательный, надо про это будет как-нибудь отдельно написать. А сегодня я хотел написать про то, как у нас сложилось с одним из упражнений.

    Целый день был посвящен упражнению, которое называлось Dress Rehearsal. Идея, вкратце, была следующая. Каждой команде давалось игровое поле, набор карточек и листики с правилами игры. Листики причем давались разные каждому члену команды. Нужно было расположить карточки на поле. Правила же определяли начисление очков за разложенные карточки. Цель команд была – разложить карточки так, чтобы количество очков в результате было максимальным.

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

    На первый взгляд задание – тривиальное. Однако. Правила были довольно запутанные. Они были распределены по одному среди разных членов команды. А в команде было порядка 12 человек. При этом за нарушение некоторых правил вычитались штрафные очки. Довольно большие. Ошибиться стоило дорого.

    Не знаю, как там с моделью Такмана за 5 дней, но мы прошли все стадии за два часа. :) Вначале, конечно, громко спорили, кто за что будет отвечать. Поле было поделено на три части, поэтому выделили по под-команде на каждую часть. В каждой под-команде были пара инженеров и один QA (!) инженер, который проверял, что расклад не противоречит карточкам, и с нас не снимут очков.

    Потом были споры, как лучше раскладывать, потому что правила были раскиданы по всем участникам. потом была суета с раскладыванием. Потом у участников начали случаться инсайты “а вот так можно было бы сделать еще лучше!” В общем, все как в жизни. :)

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

    Киевский парень отогнал всех от стола и сам за 10 минут разложил все карточки как надо. Мы с еще одним москвичом выступили в роли QA. Все карточки были разложены идеально. Остальные 10 членов команды, включая менеджера :) , стояли в стороне. Наша команда набрала абсолютный максимум.

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

    1. Пока у кого-то одного в голове не сложится четкой картинки, всегда будет суета и бардак.

    2. В начале проекта четкой картины обычно нет в голове ни у кого.

    3. Один-два грамотных человека могут сделать больше, лучше и быстрее, чем один-два грамотных человека в команде с пятью не так быстро соображающими. :)

    4. Менеджеру тоже иногда нужно отойти в сторону, чтобы не мешать. :)

    5. …

    Производительность команды

  • Что почитать тестировщику

    Posted on May 4th, 2009 Александр Орлов 10 comments

    Когда-то я уже писал о том, что почитать программисту, а также менеджеру (часть 1, часть 2). Теперь настала очередь тестировщиков. :) Тем более, что на заседании круглого стола об образовании тестировщиков в рамках конференции SQA Days, как раз был составлен этот секретный список.

    Итак, чтобы сделать из обычных тестировщиков команду высокомотивированных профессионалов, нужно начать с того, что подарить им следующие книги:

    Производительность команды

  • Матрица компетентности программиста

    Posted on April 22nd, 2009 Александр Орлов 5 comments

    Недавно бывшие коллеги поделились ссылкой на матрицу компетентности программиста.

    Матрица состоит из 5 больших категорий (для каждого пункта в категориях есть градация по степеням продвинутости):

    1. Computer Science

    • Структуры данных
    • Алгоритмы
    • Программирование систем

    2. Software Engineering

    • Контроль версий исходного кода
    • Автоматизация сборки
    • Автоматическое тестирование

    3. Программирование

    • Декомпозиция проблем
    • Декомпозиция систем
    • Коммуникабельность
    • Организация кода внутри файла
    • Организация кода между файлами
    • Организация дерева исходников
    • Читабельность кода
    • Защитное программирование
    • Обработка ошибок
    • IDE
    • API
    • Фреймворки
    • Требования
    • Скрипты
    • Базы данных

    4. Опыт

    • Языки в которых есть профессиональный опыт
    • Профессиональный опыт в платформах
    • Стаж профессионального опыта (в годах)
    • Знания в области

    5. Знания

    • Знание инструментов
    • Повседневно используемые языки
    • Знание существующей базы кода
    • Знание новых технологий
    • Внутреннее устройство платформы
    • Книги
    • Блоги

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

    P.S. Англоязычный оригинал матрицы находится здесь.

    P.P.S. Автор русского перевода: http://omega-it.blogspot.com/, за что ей большое спасибо!

    Производительность команды

  • Чувство сопричастности в распределенных проектах

    Posted on April 17th, 2009 Александр Орлов 2 comments

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

    Собственно, в чем выражается то, что на той стороне появились “козлы”. Выражается оно в том, что ребята на той стороне перестают прислушиваться к мнению ребят на этой. Ну, по крайней мере, нашим так кажется. У наших теряется чувство сопричастности к проекту.

    “Да чего им объяснять, все равно они все по-своему сделают!”

    “Да чего с ними говорить, они же не понимают ни фига!”

    Слышали такие фразы? Ну, значит, чувство сопричастности к проекту пропало.

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

    А почему наши устали? А потому что объяснять архитектуру по телефону никакого терпения не хватит. А потому что спорить с поликомом скучно. А потому, что сложно что-то объяснить носителю английского языка, когда в твоем словаре 200 слов. Так и получается: “Ну что, они совсем идиоты? Не понимают элементарных вещей…”

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

    Мотивация сотрудников, Производительность команды

  • От Чингисхана до наших дней

    Posted on March 20th, 2009 Александр Орлов 9 comments

    На выходных побывали в кинотеатре. Давали “Тайну Чингис Хаана” – совместный российско-монгольско-американский фильм. Кинофильм оказался весьма созерцательным. В том смысле, что Чингисха достает, допустим, стрелу. Вот он ее минуту достает, потом еще минуту на нее значительно смотрит. Потом то же самое повторяется с мечом.

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

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

    Как так справлялся? Есть такое подозрение, что это потому, что ценности у участников команды были одинаковые. И какой-нибудь хан Чебурей, стоя посреди среднерусских лесов, понимал, что и как ему надо делать.

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

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

    И так, в общем, и происходило довольно долго и не только у монголов.

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

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

    [загробным голосом] Коллеги, откройте глаза… Оглянитесь вокруг. Сколько в мире всего понапридумали уже. Что-то вам наверняка подойдет.

    P.S.Если у кого есть любимые инструменты для работы в распределенной команде – поделитесь с коллегами своим опытом в комментариях.

    P.P.S. Если вам некогда смотреть вокруг и читать комментарии, приходите 11-12 апреля на Эффективные Коммуникации, мы все расскажем, покажем и дадим попробовать. :)

    Производительность команды

  • Распределенные проекты: идем дальше

    Posted on March 6th, 2009 Александр Орлов 6 comments

    К посту про важность продвинутого мышления в рапределенных проектах хороший комментарий оставил Данила Ковалев. Комментарий настолько хорош, что его надо процитировать. :)

    Хочется добавить следующее
    1) Из изложенного в посте ясно, что сильно возрастает потребность в чёткости коммуникаций. Продумайте и зафиксируете, как вы будете общатся с удалённой командой. Общая рекомендация такая:
    а) для знакомства рекомендуется 1 Vidoconference (подумайте о ресурсах – тех. средствах), крайне желательно все _критичные_ проблемы также разбирать на Video status meeting еженедельно. Смысл тут такой – проще решать конфликты и недопонимания, когда есть невербальная обратная связь (не забываем, что мы не native-speakers, и, скорее всего навыки общения (и fluent язык) развиты только у менеджера, что прискорбно, но обычно).
    b) для обсуждения текущих проблем – ежедневные (регулярные, зависит от итераций или project tracking points) phone conf. Состав участников – минимальный. (Важно, чтобы кол-во часов проводимых в конференциях, не перебивало кол-во часов для работы, не более 1 конференции в день. Для переговорщиков – не более 2-х)
    c) основные коммуникации – письменные. Обсудитье и согласитесь с общими положениями реагирования на mails (приоритеты) и следуйте им, чётко обсудите обязательные для заполнения поля в bug tracking system. Возможно, (в начале) делайте ревью багов перед assign (это касается как Dev так и QA) на удалённую команду.

    2) Все решения тактического порядка (не говоря уж о стратегических) должны быть доведены до удалённых команд. (Документирование процесса, однако тут важно не переборщить).

    3) С каждой стороны должен быть 1 переговорщик с публично и жёстко закреплённым графиком availability. Опять же – если вам дан моб.телефон, не стоит беспокоить человека в 2 часа ночи по его времени. Имейте совесть.
    Основной смысл переговорщика – не “козёл отпущения”, а наделённый опред. полномочиями коллега, который _помогает_ _ВАМ_ добиваться результата. Основная его обязанность – довести информацию до ответственного человека. Проблему решаете вы с этим человеком. Переговорщик вас с ним свёл – всё. Это необходимое, но не достаточное условие. Переговорщик должен быть в курсе проекта и участвовать в нём. (Это моё мнение, я считаю, что внешний человек тут не эффективен).

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

    Я бы добавил еще пару пунктов.

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

    • Различием в часовых поясах. Фактически, у двух сторон проекта может быть пересечение только на час. А то и не быть вовсе.
    • Способом коммуникации. Общение – не личное, и обычно даже не видео-конференция, а банально – телефонная конференция.

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

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

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

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

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

    3. Личные встречи. Это очевидный пункт, но по-моему мы его упустили. Давайте его здесь для порядка тоже упомянем. Знакомиться посредством видео-конференций можно, но налаживать отношения довольно сложно. Неотвратимо появятся “козлы” на обеих сторонах.

    Список пунктов продолжает расти. :)

    Производительность команды

  • Почему не апгрейдятся компьютеры

    Posted on March 4th, 2009 Александр Орлов 6 comments

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

    Смотрите:
    Visual Studio – одно из наиболее распространенных сред разработки под Windows. Переход на новую версию – VS2005, произошел довольно быстро. Но вот переход на новое железо почему-то задержался. Во многих фирмах можно увидеть 512 MB на машине разработчика. Работа с таким объемом памяти в VS 2005, да еще с запущенным решарпером и еще парой фоновых задач способна довести до истерики. Но оставим в стороне душевное здоровье. Просто посчитаем финансы.

    • Разработчик должен приносить фирме хотя бы 50-100$ тысяч в год. Увеличение его производительности на 1% – это 500 – 1000$.
    • Будем считать, что вложения в IT окупающиеся за год имеет смысл рассматривать.

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

    Статья вообще отличная, крайне рекомендуется к прочтению. А начинает ее Сергей вот с чего:

    К.Маркс: “При 25% прибыли капитализм оживляется! При 100% прибыли – он готов положительно на все!! При 300% прибыли – нет такого преступления, на которое он бы не пошел…”

    Ах, как жестоко ошибался классик. Порой даже ради 1000% капитал не чешется.

    Мне кажется, я догадываюсь, почему капитал не чешется. :) Ну, действительно, что может мешать начальству потратить, скажем $3,000, чтобы купить команде программистов по второму монитору? Если речь идет о маленькой сумме, то там обычно проблем особых нет. Показал ROI, получил одобрение, все купил. Но если сумма побольше, то тут уже есть некоторые проблемы.

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

    Причина №2. Отсутствие уверенности в том, что за Investment’ом последует Return. Банально – что затраты окупятся. На бумаге все это выглядит красиво, но люди – инструменты крайне нелинейные. У программиста производительность зависит от того, в каком тоне ему написал заказчик, поругался он или нет с коллегой, и вообще от того, с какой ноги он встал. И нет никакой гарантии, что после покупки ему 30-дюймового монитора, человек начнет производить на сколько-то там процентов больше. Вероятно, больше. Но может так оказаться, что и меньше. А может быть, вообще уйдет, а на его место придет низко-производительный товарищ.

    Короче говоря, Investment – вещь понятная и фиксированная. А Return – носит крайне изменчивый и вероятностный характер.

    Причина №3. Всем покупать не хочется. Директор смотрит на команду и понимает: “Ага, ну вот Серега и Федор – да, они и так все рвут, по форумам не сидят. У них-то производительность явно возрастет. Им легко можно купить мониторы побольше. Но что, и остальным тоже надо покупать?!! Они же работают ровно столько, сколько просят, ровно в 6 часов бегут с работы домой, а во время работы норовят посидеть в аське.”

    Короче говоря, тратить деньги на низко-производительных и средне-производительных сотрудников крайне не хочется. Есть такое подозрение, вернее затаенная надежда, что их производительность может подняться и на текущем оборудовании. :) А покупать только избранным сотрудникам нехорошо – остальные обидятся.

    И что со всем этим можно сделать? Ну, первая причина, безусловно финансовая. Там, думаю, советы не нужны.

    Вторые две – человеческие. И связаны они именно с качеством людей, которые у вас работают. А если быть совсем точным, то с вашим мнением о том, как работают ваши люди. Несколько советов:

    Совет №1. Обратите, наконец, внимание на то, как вы нанимаете людей. Если сквозь сито отбора проходят низко-производительные или же средне-производительные люди, то вы так и будете с ними мучиться. Оборудование – это только одна из проблем. Потом что ни возьмете – ой, а что-то для этих сотрудников делать ничего не хочется, потому что бесполезно… Ну так, зачем было их нанимать?

    Совет №2. Займитесь перформанс менеджментом “отстающих сотрудников”. Вполне может так оказаться, что люди и не подозревают, что они в ваших глазах отстающие. Возможно, вы чего-то не видите. Поговорите с ними, дайте им понять, где они находятся в ваших глазах. Покажите, что вы от них ждете. Дайте им понять, что вы на них рассчитываете. Если произойдет сдвиг в положительную сторону – хорошо. Этому человеку можно будет купить новый монитор – это его дополнительно простимулирует. Если сдвига в положительную сторону нет, то надо думать о том, как человеку дать уйти с минимальными потерями.

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

    Вот такой вот неожиданный конец статьи про апгрейд оборудования. :)

    Производительность команды

  • Не будите программистов

    Posted on February 24th, 2009 Александр Орлов 7 comments

    Давно видел эту ссылочку, но текст казался очень длинным, поэтому осилить не удавалось. Тут таки осилил – просто-таки отлично товарищ alexthunder написал. Зря, в общем, раньше-то не прочел.

    Про то, что я в своей книжке называю “работуном”, товарищи психологи “состоянием потока”, а зарубежные коллеги понятием “in the zone”. Отлично написано, образно и очень доходчиво. Настоятельно рекомендуется к прочтению.

    Вот в отпуске побывал впервые в жизни… а некоторые так за всю жизнь ни разу там и не бывают как я подозреваю.

    Не знаю полезно это или нет – отвлечься вот так от работы на почти целый месяц. Я пока не понял какой это возъимеет эффект на производительность труда. Зато во время отпуска я понял кое что о чём много раньше думал и никак не мог осознать.

    Меня всегда мучал вопрос – как объяснить людям никогда не занимавшимся такого рода трудом, каким занимаюсь я то что вот происходит у меня и у таких как я в голове когда мы работаем. Как НЕ программисту представить себе работу программиста и понять наконец чего же происходит и как вообще с этим быть.

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

    Read the rest of this entry »

    Производительность команды

  • Развитие развивающихся – дело самих развивающихся

    Posted on February 23rd, 2009 Александр Орлов 39 comments

    В комментариях к посту про то, почему не работают системы развития сотрудников, был интересный комментарий от Dennis’а:

    Согласен со многим.
    С избирательным развитием сотрудников есть только одна проблема.
    Представь что ты послал Петю на семинар по каким-то кунштукам №1. Взял и послал, и об этом пост-фактум узнали все. И начинаются:
    1) вопросы “а почему не я”
    2) претензии “опять обманули” и “где же ваша хваленая открытость”
    3) обиды “всё, меня не любят”
    А ты им и говоришь “я, мол, развиваю только правильных людей” :) вот тут и начнутся колоссальные процессы в бессознательном программистов (а оно бездонно).

    Есть простой чукотский способ, который у меня давно сидел в мозгу, но помочь его осознать помогла в свое время книга товарища Клауса Кобьёлла “Motivaction” (по-русски называется “Мотивация в стиле Экшн”). Он там приводит пример компании Macy’s (кто не бывал в Штатах, это такие здоровенные магазины):

    В универмаге Macy’s в Нью-Йорке руководящих работников всегда искали на стороне. У собственных сотрудников никогда не спрашивали, есть ли у них желание занять эти должности. Тогда сотрудники объединились и возмутились. Руководство магазина извинилось и сказало: “Вы правы, мы делаем вам следующее предложение: каждый вторник и четверг после окончания работы у вас будет проходить полуторачасовое обучение. Это мы будем делать в течение года, приглашая лучших инструкторов Нью-Йорка, для вас это будет бесплатно, а затем вы можете продвинуться по службе и занять руководящие посты”. И что вы думаете, сколько процентов сообщили о своем желании участвовать? Три процента! Остальные сказали: “Минутку, вы должно быть нас неправильно поняли, мы хотим быть менеджерами, а не учиться в половине седьмого; в это время я уже на диване с бутылкой пива в руке и смотрю телевизор.”

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

    Не думаю, что это большая проблема нарушения баланса работы и личной жизни – потратить один уик-энд в квартал. Скорее, проблема чисто психологическая. Все проще. Человек либо хочет развиваться (и за счет своего времени тоже), либо не хочет. Либо ему это интересно, либо не интересно. Вот и все.

    Мотивация сотрудников, Производительность команды

  • Думать на ход вперед

    Posted on February 20th, 2009 Александр Орлов 4 comments

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

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

    Каждый, кто играл когда-либо в шахматы, знает о пользе такого навыка, как думать на несколько ходов вперед. Хотя бы на один ход. На один ход вперед обычно думают даже 5-летние шахматисты, набирающие 4-й разряд. Товарищи гроссмейстеры могут прикидывать комбинации ходов этак на 7 вперед, а то и круче. Кто думает вперед дальше, тот обычно выигрывает. Тот, кто не думает вообще, получает детский мат.

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

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

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

    Поэтому, начиная распределенный проект:

    • Обратите внимание на то, насколько зрелые люди в нем участвуют. Зрелые – в плане думать на ход вперед.
    • Приготовьтесь к задержкам и непониманию. Это нормально. Но каждый такой случай – это комбинация, которая должна быть зафиксирована в памяти людей. Чтобы в следующий раз они про нее вспоминали.

    Хорошая новость: играть на уровне 4-го разряда могут все. :) Если захотят. А почему могут не захотеть – думается, тема отдельного поста. :)

    Производительность команды
  • « Older Entries
    Newer Entries »