• Культуры программных проектов: часть 7

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

    (все выложенные на текущий момент части – здесь)

    Игра по другим правилам

    Действительно ли мир полон дурных боссов? Проекты полны некомпетентных работников? Технические ребята всегда зацикливаются на своих гиковских штучках в ущерб общему успеху проекта?

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

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

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

    А откуда люди берут эти свои разные правила? Похоже, что ответ зависит от опытности человека.

    Начинающие: Предписанные правила

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

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

    В качестве примера такой группы правил, названной методологией, давайте заглянем в книгу Unified Software Development Process (USDP), от Booch, Jacobson и Rumbaugh, опубликованную Addison Wesley в 1998. Вот некоторые случайно выбранные правила:

    Страница 19: «При назначении ресурсов менеджер проекта должен минимизировать передачу артефактов из одних рук в другие так, чтобы ход процесса был максимально гладким.»

    Страница 34: «Разработчики начинают работу со сбора требований заказчика в виде юзкейсов. Затем они анализируют и разрабатывают систему так, чтобы она соответствовала юзкейсам, создав сперва аналитическую модель, а потом и имплементацинную модель.»

    Страница 76: «Архитектура создаётся архитектором заранее (во время фазы детализации требований). Это требует существенных предварительных затрат времени.»

    В книге сотни таких правил, а сама книга – это всего лишь подмножество более полного Rational Unified Process (RUP), который доступен по подписке.

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

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

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

    Получается, что методики, нацеленные на начинающих, предписывают авторитарные правила, которым надо следовать, авторы которых обещают: «эти правила работали для меня, и если вы будете им следовать, как положено, они и для вас сработают».

    Продолжение следует…

  • Что влияет на продуктивность инженеров? Внешние факторы.

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

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

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

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

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

    Конечно, в заключении надо сказать большое спасибо компании R-Style за предоставление помещения под наши семинары.

  • Возможности != Желание

    Posted on December 2nd, 2009 Александр Орлов No comments

    Заметил интересный феномен. Когда начинаешь разговаривать с менеджерами о том, что правильный сотрудник должен обладать двумя качествами, завещанными нам Джоэлом Спольски: Smart + Get thing done, то многие менеджеры закатывают глаза к небу и говорят:

    • “Ооо, ааа, а кто же тогда будет делать рутинную работу…”
    • “Наберешь суперзвезд, они идей нагенерят, а кто тогда будет напильником дотачивать…”

    Вот интересно, в Google, судя по всему, набирают весьма толковых инженеров. Как же они избегают этих проблем?

    Имхо, тут все достаточно просто. В голове менеджеров присутствует небольшая путаница. Smart и Get thing done – это вообще говоря, о возможностях человека. То, что по своим возможностям он является зрелым профессионалом. Или не является, то есть еще не дорос, а может, никогда и не дорастет.

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

    • Хочется вместе с коллегами сделать супер-проект. И человек готов делать все, что угодно, лишь бы этот проект сделать. Вот нравится человеку быть членом героической команды, которая делает успешные проекты. Это ему нравится даже больше, чем генерить идеи, делать прототипы и архитектуры.
    • Человеку нравится заниматься неспешной работой по доточке того, что другие наворотили. При этом, человек и Smart, и Get things done.
    • У человека изменились жизненные приоритеты. В студенчестве были интересны технически сложные задачи, алгоритмы, еще что-то. А теперь он женился, завел детей и ипотеку, кредит на машину. И человеку хочется проводить на работе не более 8 часов в день, и вообще интересны в жизни и другие вещи. Но при этом он Smart и Get things done. Умный, то есть. И если уж взялся за дело, то сделает.

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

  • Продажа второго монитора начальству

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

    Результаты опроса про количество мониторов у сотрудников немного удручают. На текущий момент в опросе поучаствовали больше 200 человек. Что мы видим:

    • 59% – один монитор
    • 29% – два монитора
    • 2% – три и более мониторов

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

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

    • Менеджер не смог убедить начальство выделить денег на вторые мониторы
    • Менеджер опасается, что второй монитор людям дашь, а производительность не вырастет

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

    Способ №1. Вычисление ROI. Мы считаем, сколько времени инженер тратит на переключение между окнами. Предположим, у нас получается 20 минут в день. 20 минут в день – это 440 минут в месяц, говорим мы. А это, подумать только! семь с лишним часов рабочего времени в месяц. В год человек простаивает почти 12 дней. Монитор стоит дешевле. Давайте, купим ему монитор – это окупится уже в первый год!

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

    (Заметим, что Сергей Мартыненко когда-то давно в своей статье приводил еще больше плюсов от количества мониторов.)

    Способ №2. (Этот способ мне недавно подсказала слушательница на одном из корпоративных тренингов. И я пришел от него в восторг. :) ) Тут тоже нужна подготовка. Берем две детские картинки из серии “найди 10 отличий”, например вот такую. Одну картинку распечатываем на одной стороне листа. Вторую на второй. После чего происходит примерно такой диалог:

    - Саша, ну вот объясни мне, зачем твоим ребятам второй монитор? Ведь нормально же работают на одном. Уже давно работают.

    - Нормально? Я вот вам сейчас покажу…

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

    Этот способ может подействовать на начальников, которые в специфике процессов разработки и отладки понимают не очень. Для многих сам компьютер – уже роскошь. Мы еще помним времена, когда 486-й с 15-дюймовым монитором был предметом зависти! А тут два монитора…

    Надеюсь, способы помогут кому-нибудь таки продавить идею омониторивания. :)

    P.S. Кстати, коллеги, если кто-то использовал другие интересные способы – поделитесь. Думаю, многим будет интересно.

  • Сколько мониторов у ваших сотрудников?

    Posted on November 18th, 2009 Александр Орлов 25 comments

    В свете моего грядущего выступления в MO PMI (анонс будет попозже) про внешние факторы влияния на производительность сотрудников, проведем небольшой опрос:

    Сколько мониторов у каждого из ваших сотрудников?

    View Results

    Loading ... Loading ...

    (Если у всех разное количество мониторов, пишите про большинство. Сколько мониторов у большинства сотрудников?)

  • Time & Materials: удовлетворяем заказчика за мало денег

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

    На прошлой неделе мы говорили о необходимости супер-продуктивных сотрудников. И, казалось, пришли к очевидному выводу – продуктовая разработка и работа в аутсорсинге по модели fixed-price стимулирует владельца компании к поиску и найму талантов. А работа по модели time & materials способствует найму низкозарплатных инженеров.

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

    Модель 1. Потемкинские инженеры. Заказчику выставляют счет за пятерых программистов, а реально работу делают два супер-продуктивных человека. Справедливости ради, надо сказать, что эта модель встречается редко, потому что долго скрывать истину обычно тяжело.

    Модель 2. Ледоколы и катерки. Команда состоит из пары супер-толковых людей (ледоколов), которые работают за пятерых, и трех дополнительных ребят (катерков), которые делают оставшиеся 10% работы. В случае недовольства заказчика ледоколы чуть прибавляют хода и начинают работать за шестерых. Катерки хода не прибавляют, а если прибавляют, то это все равно не так заметно.

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

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

    В любом случае, менеджеру проекта, работающему по time & materials, приходится нелегко. Ему приходится танцевать между удовлетворением заказчика, интересами владельца компании сэкономить на зарплате людей и, собственно, руководством людьми. Лозунг «нанимайте лучших и все будет отлично!» тут не очень работает.

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

    Модель №5. “Только для вас” (увидена Яковом Сироткиным). Толковые инженеры работают на нескольких проектах, а заказчик думает, что они у него в эксклюзиве. Иногда бывает пишут письма не тому заказчику.

  • Всегда ли нужны таланты?

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

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

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

    Та же картина наблюдается в аутсорсинге, работающем по модели fixed price. Там тебе платят фиксированную сумму – и чем быстрее ты сделаешь, тем лучше. Потому что чем дольше делаешь, тем больше денег ты платишь в виде зарплаты программистам. Здесь владелец тоже спит и видит у себя в команде ребят с 10-кратной производительностью труда.

    Кстати, именно эта картина определяет рынок фриланса. Да, там есть много средних программистов. Но там есть очень много профессионалов, которые супер-производительны. Если удается их найти (мне, признаюсь честно, удавалось :) ), то результаты ребят просто поражают.

    Однако вернемся к аутсорсингу. Кроме fixed price есть еще модель time & materials (подробнее о моделях разработки вы можете почитать в статье “ИТ-такси”). Здесь заказчик платит за часы работы. Так же как и в модели ODC (offshore development center), когда на стороне аутсорсинговой компании на окладе сидят три программиста, постоянно работающие на заказчика.

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

    Так вот, если вы как менеджер приходите к владельцу и говорите ему: “Иван Петрович, а давай наймем супер-звезд!”, то Иван Петрович автоматически понимает, что вы предлагаете ему людей по среднему рэйту $15 в час. То есть его прибыль сокращается на $5 в час. От того, что в проекте time & materials будут работать супер-звезды заказчик платить больше не станет.

    Поэтому Иван Петрович предлагает свой вариант: “Давай лучше возьмем Машу и Катю из проекта ABC, они как раз освобождаются.” Или: “Давай растить подрастающее поколение. Я вчера был в университете, познакомился там с тремя толковыми ребятами.” В любом случае, у владельца нет никакой мотивации, чтобы в проекте работали супер-звезды.

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

    Поэтому, предварительный вывод такой: в продуктовой разработке и fixed price аутсорсинге, безусловно, нужны таланты. В time & materials талантов не ждут. Если только молодых.

    Конечно, это не все нюансы. Про остальные поговорим на следующей неделе.

  • Макс Крайнов: работа в команде

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

    Почему-то я думал, что уже делился этими ссылками, а оказалось, что еще нет. Надо это срочно исправить. Сейчас буду цитировать то, как Макс Крайнов пересказал то, что ему рассказали и чему его научили в Лас Вегасе три безымянных инструктора под руководством Patrick Lencioni, автора книги “The Five Dysfunctions of a Team”.

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

    Работа в команде или зачем я ездил в Лас Вегас. Часть 1

    Работа в команде или зачем я ездил в Лас Вегас. Часть 2

    Работа в команде или зачем я ездил в Лас Вегас. Часть 3

    Процитирую начало:

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

    • Отсутствие доверия между членами команды. Члены команды не хотят быть уязвимыми перед другими, не хотят признавать собственные ошибки и не хотят просить помощи. Без этого доверия в команде добиться невозможно, а именно доверие является объединяющим фактором для команды.
    • Боязнь конфликта. Без доверия между членами команды невозможно добиться продуктивной дискуссии (или конфликта). Причины две:
      • задавленный конфликт увеличивает вероятность возникновения деструктивной подковёрной борьбы
      • задавленный конфликт ведёт к нерациональному процессу принятия решений, т.к. команда не может полностью воспользоваться потенциалом своих членов (из-за этого у нас появилось выражение: “спасибо тебе за твой конструктивный конфликт“).
    • Отсутствие обязательств. Без конфликтов члены команды вряд ли будут поддерживать разнообразные решения, т.к. будут считать, что при принятии решений мнение этих людей не спросили. Это очень часто создаёт атмосферу непонятности и необязательности в компании, что сводит с ума всех – особенно хороших работников.
    • Избегание ответственности. Когда команда не может решиться на чёткий план действий, ответственность членов друг перед другом сильно страдает. Даже самые ответственные и талантливые сотрудники не будут призывать к порядку своих сильно менее продуктивных коллег, потому что будут считать, что не было твёрдого уговора, что такие коллеги должны сделать что-то конкретное.
    • Отсутствие внимания к результатам. Когда члены команды не требуют от других исполнения оговоренных обязательств, они увеличивают шанс того, что эгоизм и желание выделиться у индивидов станут более важными, чем коллективный результат. Когда это происходит, бизнес начинает страдать, и команда начинает распадаться.
  • Человеческий фактор: о чем забывают менеджеры

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

    Вырвавшись из тесных объятий конференции Software People,выкладываю свой доклад с предыдущего события – Software Engineering Forum.

  • Бесплатные онлайн книги по программированию

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

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

    Что это значит для менеджера? Это значит, можно не добиваться одобрения финансового директора на покупку книг, попридержать пока деньги из собственного кошелька. И:

    Ознакомиться с каталогом!

    (Подсмотрено на www.it4business.ru)