• Телеконференция 2.0

    Posted on January 30th, 2009 Александр Орлов 14 comments

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

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

    • 5 человек сидят вокруг поликома, например, в Питере
    • 3 человека вокруг поликома в Китае
    • 5 человек вокруг поликома в Америке
    • И еще 4 человека звонят на конференцию каждый из своего дома

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

    Понятное дело, что говорить по очереди не очень эффективно. Например, начинает говорить один человек. А то, что он говорит, относится только к половине участников митинга. За это время другая половина вполне могла бы обсудить свои проблемы.

    Что и происходит во время личных встреч. Идет, например, сессия группового планирования. Висит там большая временнАя карта на стене. И народ ходит туда-сюда со стикерами, друг с другом что-то обсуждает. Когда, что и куда синхронизуется и так далее. Потом, конечно, всю картину все участники взором окинут, но до этого общаются друг с другом так как наиболее эффективно – там группа из 3-х человек, тут из 5-ти, а вот там из 2-х.

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

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

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

    Обсуждаете там что-то. При этом слышите издалека голос докладчика – вдруг он там что-то важное начнет говорить. Тогда можно будет вернуться в кружок.

    То есть, банально идея:

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

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

    P.S. В качестве продолжения идеи – виртуальная конференция, где можно подходить к разным группам и слушать, чего там говорят. :)

  • Почему не работают системы развития сотрудников

    Posted on January 28th, 2009 Александр Орлов 14 comments

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

    А как это сделать? А вот как – прочесть всем тренинг по развитию и составить каждому инженеру индивидуальный план развития. Personal Development Plan. В руководстве почему-то считают, что если сделаны эти два шага – то всё, 100% сотрудников придут в поступательное движение и таки вырастут в лидеров.

    Поскольку я сам проходил через таковые тренинги, процедуру внедрения Personal Development Plan’ов и, вообще говоря, занимаюсь смежной темой :) , то я могу объяснить, почему это не срабатывает. И как делать правильно.

    Причина №1. Не всех сотрудников можно развить. Более того, не всех нужно. Очень редко встретишь компанию, где подобрались сплошь правильные программисты. Обычно в компании есть некоторое количество классных сотрудников, которые делают, условно говоря, 80% работы. Есть группа серядняков, которые делают 30% работы. И есть группа балласта, которая делает -10% работы. -10% – это отнимает время первых двух групп своими косяками, глупыми вопросами и прочей несуразицей.

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

    Причина №2. Недоверие к менеджеру. В процессе развития, ключевую роль играет менеджер человека. Он помогает составлять план развития, он дает обратную связь, он помогает с движением по плану. Короче говоря, менеджер играет роль наставника. И успешно играть эту роль он может только в одном случае. Если инженер воспринимает его как наставника.

    То есть, банально, должно быть хотя бы доверие инженера к менеджеру. Если доверия нет, если инженер считает, что ему просто промывают мозги, потому что “у менеджера работа такая”, то никакой Personal Development Plan не сработает.

    Причина №3. Общее недоверие к массовым инициативам компании. Любое изменение неминуемо встречает сопротивление. В частности, любая инициатива сверху, которая предлагает человеку не получать больше денег, а делать что-то дополнительно. :) К тому же редко какая компания зарекомендовала себя изнутри исключительно здравыми инициативами. Большинство инициатив снизу выглядят довольно дурацкими. “Ну вот теперь всем развиваться надо. Господи, когда уже это кончится, и дадут, наконец, поработать…”

    Причина №4. Недоверие к системе. Довольно часто тренинги по развитию карьеры читаются специалистами широкого профиля. Которые аналогичные программы читают для продажников в “Эльдорадо”, производителей сгущеного молока и работников туристического бизнеса. Программисты, естественно, считают себя исключительными людьми, на которых общие методы развития не действуют.

    Иногда читают западные тренеры, которые не могут понять “душу отечественного инженера”. “У них там на Западе все на голову ударенные в плане карьеры. У нас все по-другому.”

    На все это накладывается недоверие к инструктору. Иногда тренинги по развитию карьеры для программистов читает HR специалист, которого научили читать этот тренинг. Это не работает. Если бы тренинг читал Джэймс Гослинг или там Линус Торвальдс – тогда да, тот же материал воспринимался бы по-другому. Парни бы еще примеры из своей жизни на него наложили – и получилось бы вообще отлично. А HR специалист обычно не воспринимается программерами как лидер, которому можно доверять.

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

    Резюме. Системы развития инженеров работают. Работают хорошо. Но не всегда и не со всеми. Чтобы от всего это был какой-то толк, нужно сначала:

    • Обратить внимание на процессы найма. Чтобы в компанию рвались работать толковые люди, и только они и проходили сквозь сито отбора. Правильные люди к тому же имеют ярко выраженную склонность к саморазвитию. Они и без тренингов по развитию движутся вперед ого-го как.
    • Сократить балласт. Кризис -  довольно удачный момент для того, чтобы отпустить тех людей, для которых программирование – это не их дело. Освободившиеся позиции сейчас будет довольно легко занять.
    • Вкладываться в развитие менеджеров. Это те люди, которые осуществляют процесс найма. Это те люди, которые имеют массу рычагов влияния на инженеров. Это те люди, которые должны уметь завоевывать доверие команды и быть лидерами. Линейные менеджеры – это ключевые игроки во всей этой схеме.
    • Приглашать экспертов и не допускать чтения того же материала не-экспертами и людьми, которые не вызывают уважения инженеров.
  • Голосование по сертификатам – кому шашечки, кому машина?

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

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

    Итак голосуем! Высшее образование, к.т.н, BrainBench и пр. – что нужно иметь инженеру, чтобы вы взяли его на работу? Какие, понимаешь, условия, являются необходимыми, чтобы человек попал в вашу компанию?

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

    P.S. Голосовалка также находится на странице справа – между секциями Pages и Archive.

  • Как из читателя стать писателем? (Конкурс inside!)

    Posted on January 27th, 2009 Александр Орлов 3 comments

    Как из читателя стать писателем? Очень просто. Надо на время перестать читать, сесть и что-нибудь написать. :) А вот и повод.

    Коллеги-тестировщики на портале software-testing.ru объявили конкурс на лучший отзыв о книге по тестированию и смежным областям.

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

    призы от проекта Happy PM: футболки, книжки, блокнотики

    Главным же призом в конкурсе выступает кистевой тренажер, примерно такой, который всегда находится в руке Алексея Баранцева, главного редактора software-testing.ru. :)

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

    Правила участия в конкурсе

    P.S. Конкурс на чтение менеджерских книг будет чуть попозже. И правила будут немного другие. :)

  • Цитата недели (Фред Аллен)

    Posted on January 27th, 2009 Александр Орлов No comments

    A committee is a group of men who individually can do nothing, but as a group decide that nothing can be done.

  • Страховка от провала

    Posted on January 26th, 2009 Александр Орлов 8 comments

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

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

    Какое там управление рисками, какое снижение рисков?… По моему опыту технику “риск план как оберег” использует подавляющее большинство менеджеров проектов, особенно начинающих. Почему так происходит? Думается, по не скольким причинам.

    Во-первых, мы все неисправимые оптимисты. Ну, то есть, интуитивно снижаем вероятность рисков до нуля. Надеемся, что пронесет.

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

    В-третьих, сроки обычно давят. И заносить в план то, что отнимает время, менеджер как-то стесняется.

    В-четвертых, по историческим причинам. “У нас так никто не делает”. Ну, не делает, и ладно.

    В-пятых, по причинам анти-бюрократическим. Риск план воспринимается, как документ бюрократический, необходимый для, скажем, получения бюджета на проект. Так же как Softare Quality Plan, Market Requirements Document и пр., и пр. Бюджет получен, бюрократия откладывается в сторону, начинается “реальная” работа.

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

  • Sunday Fun: Берегите девелоперов

    Posted on January 25th, 2009 Александр Орлов 1 comment

    Берегите их, да:

    Fun
  • Со скоростью разбитой телеги

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

    В комментариях к посту про одиночек, которые круче команд, у нас произошел интересный диалог с коллегой ИльейШ. Коллега написал:

    Наоборот всегда старался сделать команду как можно более разную, диверсифицированную. Один – быстро схватывает, но ленив; второй – тормозит долго, но пробивает все (я называю таких шахматистами); третий – просто начинающий, на все готов, но многого не понимает, не стабилен; четвертый – суперзвезда, все умеет и может, но мелочевка ему не интересна.
    Самое сложное – это раздать задачи каждому свои и увязать возможности команды с планом работ. Точнее – даже сделать так, чтобы заказчику всегда нужны были все стороны и в случае желания перекосить задачу “продать” симметрию.
    И команда всегда считала себя командой именно из-за того, что каждый делал что-то, что другой не делал. И та же суперзвезда не хочет заниматься всякой “фигней” – ты ее звезде и не даешь.
    Сделать так, чтобы все нормально друг с другом общались непросто, но и не надо, чтобы люди чувствовали себя равными. Как раз неравенство порождает желание учиться и развиваться. А чтобы появились человеческие отношения надо в процессе собеседования смотреть не только ( и не столько ) на знание программирования, а в основном на человеческие качества.

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

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

    И эта команда работала! Мы делали все, что от нас требовалось и были на неплохом счету у начальства. Вопрос: почему? Мой ответ на это – потому что не было давления. Сроки были отдаленные, область не менялась годами, все было привычно и неспешно.

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

    Товарищ Джоэл Спольски когда-то сформулировал два критерия правильных людей: умные (smart) и доводят дело до конца (get things done). Когда в команде:

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

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

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

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

  • Интервью с Артемом Бойцовым, Google

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

    Небольшая история. Где-то в начале осени мы пересеклись Вконтакте с моим однокурсником Артемом Бойцовым. Я внезапно обнаружил, что он работает в Google в Силиконовой долине, и спросил: “Тема, а с каким менеджером у вас можно было бы сделать интервью?” На что Тема мне ответил, что с менеджерами делать интервью не надо, потому что Google – очень engineer-centric компания. Поэтому, говорит, лучше делать с инженерами. :) Ну и мы решили с Темой и поговорить. Тем более, что той же осенью он был в Москве и занимался интеграцией в сделке с Begun, которую наша российская анти-монопольная служба в итоге не одобрила.

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

    • История питерского инженера, который мечтал работать в Microsoft :)
    • Как “понты” помешали устройству в Amazon
    • Чем полезна служба в армии
    • Что означает engineer-centric компания
    • Самоуправляемые и самоорганизующиеся команды – это не такой и миф
    • Недостаток культуры коллективной работы в России
    • Система аттестаций и повышений зарплат и распределения бонусов в Google
    • Принципы проведения интервью в Google

    P.S. Алексей Лупан у себя в блоге перегнал в текст кусочек интервью про тестирование. За это Алексею спасибо!

    P.P.S. Файл заменен на отредактированный. Сергею Печеркину спасибо за редактуру. Благодаря его потрясающей работе файл еще и похудел на четверть. :)

  • Прямая связь с Богом

    Posted on January 21st, 2009 Александр Орлов 6 comments

    Когда-то давно меня поразила история про то, как Эрик Шмидт вытаскивал из одного места компанию Novell. Эрик Шмидт, вообще фигура эпическая. Он работал в Sun Microsystems, Inc., руководил разработкой Java и доруководился до поста CTO компании. После чего в 1997 году ушел в Novel на пост CEO, где, собственно и произошла история. А в 2001 он ушел на пост CEO Google.

    История вкратце такая. В 1997, когда товарищ Шмидт стал директором, компания Novell была в глубоком кризисе. Вскоре после своего назначения Эрик летел на самолете и случайно услышал разговор двух инженеров Novell. Они обсуждали какую-то техническую проблему, и сразу было видно, что ребята – очень толковые. То, что называется top talent. Эрик с ними познакомился и попросил их назвать других таких же грамотных людей в компании. Они выдали какой-то список. Он поговорил с теми людьми и попросил их тоже назвать наиболее толковых людей в компании. И так далее.

    Через короткое время круг замкнулся. :) У товарища Шмидта на руках оказался список из 100 самых толковых инженеров компании. Он поговорил один на один с каждым инженером, чтобы выяснить его взгляд на технологические вопросы, корпоративные процессы и пр., и пр.

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

    В этой истории интересно что? Большинство высоких руководителей стараются отгородиться от проблем снизу. Особенно это касается компаний в нашей культуре, на постсоветском пространстве. У генерального директора должен быть отдельный кабинет, кожаное кресло, а все вопросы – пожалуйста, через секретаршу, а лучше через своего непосредственного начальника. В западных конторах присутствует чуть больше демократии, там теоретически любой сотрудник может попробовать устроить встречу 1:1 с большим начальством, когда оно приезжает. Но по факту, с большим начальством встречаются, в основном, менеджеры. А толковые сотрудники сидят на местах и тихо бурчат. :)

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

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

    P.S. Какова, спросит меня читатель, роль линейного менеджера в этой статье? :) Ясно какая – поговорить с руководством на ближайшей встрече один на один. :)