• Тяжело работать в опен спейсе! А начинать рабочий день еще тяжелее!

    Posted on July 19th, 2010 Александр Орлов 10 comments

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

    “Служебный роман” - вообще фильм про работу в офисе, как ни крути. Тут тебе и опен спейс, и поднятие визибилити, и интриги… :)

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


    Отличный, отличный фильм, надо его на тренингах показывать. :)

    Fun, Аудио/Видео, Производительность команды

  • Человеческие проблемы ИТ менеджеров

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

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

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

    Аудио/Видео, Производительность команды, Эксперты

  • Вбок-вбок это хорошо, но вверх-вниз еще лучше

    Posted on May 7th, 2010 Александр Орлов 6 comments

    Влад Балин начал публикацию заметок по брошюре Ag;)e Checklist, которую Асхат Уразбаев с коллегами легкомысленно раздавали на конференции Software People. С интересом читаю эти заметки, потому то Влад пишет, как всегда, блестяще.

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

    Но сейчас не об этом. В заметке о роли скрам мастера Влад приводит чудесный пример:

    В некоторых подразделениях IBM уделялось очень большое внимание ликвидации «вертикального расслоения» - сокращению дистанции и борьбы с недоверием между менеджментом и инженерами. Меры в частности включали в себя обязательную ротацию — каждый инженер обязан провести как минимум один проект в роли менеджера.

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

    Меры IBM нацелены в корень данной проблемы, суть которой составляют человеческие отношения. Они нацелены на формирование единой команды менеджмент-подчиненные, и укреплению доверия.

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

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

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

    И в финале беседы, я не мог отказать себе в удовольствии, и сказал: «видишь, Андрей, у нас каждый инженер разбирается в управлении проектами лучше, чем любой из твоих менеджеров». Я немного слукавил, конечно, но был не так далек от истины. Инженер с нашей стороны был, угадайте кто? Сергей Зефиров.

    И это замечательно. Пробуйте ротацию. Она творит чудеса.

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

    Причина №1. Непонятно, как это продать заказчику. Заказчик привыкает общаться с одним человеком, а тут ему что - каждую неделю к новому человеку привыкать. Более того, за проджект менеджера заказчик платит специальную ставку, а тут у него возникнет непонимание - за что он платит и кому. Учитывая, что в нашей отечественной индустрии доля заказной разработки высока, как там устраивать полноценную ротацию как в IBM - вообще непонятно.

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

    Но более распространенная причин, это конечно:

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

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

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

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

  • Окно бессрочности

    Posted on April 30th, 2010 Александр Орлов 11 comments

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

    Это “Маньяна” (Manana). Суть в том, что у каждого человека есть свое окно срочности. И если дедлайн по задаче лежит в окне срочности, то человек начинает оживленно задачу делать. Если же дедлайн пока еще не попал в окно, то человек задачу откладывает “на потом”.

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

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

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

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

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

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

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

  • Каждому проекту - свой офис!

    Posted on April 4th, 2010 Александр Орлов No comments

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

    Скорость коммуникаций различна. Одно дело у нас команда говорит на одном языке, другое дело - у нас в команде индусы, китайцы мексиканцы и русские. Если все кроме индусов по-английски говорят не очень здорово, то так или иначе придется записывать все, о чем договорились. Чтобы участники совещания могли прочитать, о чем они там на самом деле поговорили. :) Ну и так далее.

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

    Если же у вас проект более спокойный - то в нем не будет стольких коммуникаций. Когда мы работали в проекте Apache Harmony - что там было много коммуницировать? Спецификация того, что мы писали, существовала уже несколько лет. Вначале, конечно, собрались, обсудили, кто и что будет делать. А потом поделили куски работы - и пошло наращивание мяса согласно спеке. Я не хочу сказать, что там совсем не было коммуникаций - конечно, были. Но на порядки меньше, чем в случае стартапа с бешенным владельцем.

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

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

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

    Но иногда, когда коммуникаций в проекте становилось больше, и мне приходилось бегать с 3-го этажа на 4-ый и обратно, какие-то смутные подозрения начинали меня посещать. :) Фактически же получалось, что команда, сидящая в разных кабинетах - это распределенная команда. Со всеми вытекающими бедами от низкой скорости коммуникаций.

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

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

    То есть, можно нарисовать какую-то такую матрицу:

    Бурлящий проект Спокойный проект
    Новички в команде Сидят все вместе Новичок сидит в кабинете у опытного
    Опытная команда Сидят все вместе Сидят в кабинетах

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

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

  • Питер Хрущка о человеческих проблемах программной инженерии

    Posted on March 18th, 2010 Александр Орлов 5 comments

    Проекту Happy-PM.com удалось взять эксклюзивное интервью у Питера Хрущки, одного из со-авторов Тома Демарко и Тима Листера по книгие “Балдеющие от адреналина и зомбированные шаблонами”. Предлагаем его (интервью, не Питера) вашему вниманию.

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

    А еще Питер собирается прочесть семинары в Москве, Питере и Минске. Что интересно, как мне рассказали организаторы, существует отдельная опция “билет на Software People и семинар” (3 дня). До конца марта опция стоит 15 000 рублей, что имхо довольно интересно.

    Энциклопедическая справка. Доктор Питер Хрущка – учредитель Atlantic Systems Guild, международно известной группы экспертов (www.systemsguild.com) , в которую входят Том ДеМарко и Тим Листер;

    • Автор многочисленных статей и 9 книг по программной инженерии и человеческому фактору, в том числе соавтор знаменитой «Балдеющие от адреналина и зомбированные шаблонами»
    • Основатель Agile-сообщества в Германии;
    • Один из разработчиков шаблона архитектурной документации систем ARC42;
    • Первопроходец в области инструментов моделирования для структурных и объектно-ориентированных методологий;
    • Входит в редакционный совет IT журналов, в том числе учредитель и член Международного Совета по Разработке Требований (IREB) и Международного Совета по Квалификации Архитектуры Программного обеспечения (ISAQB).
    • Частый спикер на IT конференциях, консультант, среди его клиентов многие компании из списка Fortune 500.

    Но вернемся, собственно, к интервью.

    Питер, добрый день! Спасибо, что согласились дать интервью проекту Happy-PM.com. Давайте сразу перейдем к вопросам. Ежегодно Standish Group публикует отчеты с красноречивым названием «Хаос», которые не показывают существенного увеличения доли успешно завершающихся проектов. На ваш взгляд, почему проекты все так же проваливаются, несмотря на все методологии, которые мы имеем сейчас.

    За более чем 20 лет прогресс в методах обозначал скорее техники, инструменты и процессы. Только с началом распространения гибких методологий в начале 2000-х постепенно повышается внимание к действительным факторам успеха проектов - людям и нетехническим навыкам (soft skills). (Конечно, Atlantis Systems Guild продвигала эти идеи с середины 80-х годов, еще до публикации книги Тома Демарко и Тима Листера «Человеческий фактор».)

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

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

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

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

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

    Каковы самые типичные ошибки начинающих менеджеров, и как они могли бы этих ошибок избежать?

    В нашей книге мы играем с выражениями «иметь власть» и «быть авторитетом» (игра слов - “to have an authority” и “to be an authority” - прим. А.О.). Менеджеры должны не только стремиться обладать властью (которая у них обычно изначально есть), они также должны стремиться быть авторитетами.

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

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

    Может ли менеджер быть лидером проекта, если он не имеет технического опыта? Как в этом случае он может приобрести авторитет у членов команды, которые технически сильнее его?

    В малых командах (от 3 до 7 человек) - это может быть проблематично, поскольку каждый должен делать ту или иную часть технической работы. В таких небольших командах роль менеджера не отнимает целый рабочий день. Обычно менеджер там также общается с клиентом по поводу требований, пишет спецификации, может быть, даже кодирует самые критичные вещи и т.д.

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

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

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

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

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

    Питер, спасибо за интереснейшее интервью!

    (P.S. Большое спасибо компании Career Lab и лично Елене Арсеневой за организацию интервью.)

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

  • Техника времяуважения

    Posted on March 1st, 2010 Александр Орлов 1 comment

    Вероятно, многие знают о знаменитой матрице Эйзенхауэра “Срочность-Важность”. Для тех, кто не знает - в двух словах, что это такое.

    Все дела, которые мы делаем в течение дня, можно разделить на 4 типа:

    • Важные и срочные: тушение возникающих пожаров, спасение релиза, срочная замена только что уволившегося сотрудника и пр.
    • Важные и не срочные: планирование релиза, управление рисками, кправление качеством, разговоры с сотрудниками один на один и т.д.
    • Не важные и срочные: ответить на звонок коллеги, срочно созванное совещание на тему, как устроить 8-е марта на работе и т.д.
    • Не важные и не срочные: посмотреть фильм “Наша Раша. Яйца судьбы.”, посмотреть новости по теле-ящику и пр.

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

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

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

    Рассмотрим два средства рабочей коммуникации: e-mail и телефон.

    E-mail, вообще говоря, предназначен для решения не срочных вопросов. Нельзя, послав человеку e-mail, ожидать, что он его тут же прочтет и ответит. Человек может работать с закрытым почтовым клиентом. Требование работать все время с открытым почтовым клиентом не поможет, потому что человек может быть на совещании, на обеде или в туалете.

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

    В реальности же что происходит на работе? Допустим, менеджер пишет какой-нибудь отчет, ему становятся нужны какие-то данные. Он звонит сотруднику (или просто вламывается на его рабочее место) с вопросом: “Серега, сколько там ты дефектов закрыл на прошлой неделе?” В итоге, Серега отвлекается от работы, выпадает из контекста, чтобы ответить менеджеру на его вопрос. Вопрос этот не всегда срочный. (Что мешало менеджеру послать Сереге письмо днем раньше?)

    Вторая ситуация: менеджер пишет сотруднику письмо: “Вася, через 2 минуты пришли мне, пожалуйста, точные данные по твоему модулю”. Вася в этот момент курит с коллегами, обсуждая архитектуру этого самого модуля. После чего, через 15 минут открывает свой почтовый клиент и видит, что он уже опоздал с посылкой данных менеджеру. Менеджер затаивает злобу, хотя виноват исключительно он сам. Что мешало запросить данные заранее? Или позвонить по телефону, если срок задачи истекает через 2 минуты?

    Ситуация третья: приходит один сотрудник в комнату и тут же оглашает комнату громким кличем: “Хей, чуваки, а кто вчера смотрел Лигу Чемпионов?” Все отвлекаются, выпадают из контекста работы и давай обсуждать футбол. Что мешает обсудить этот безусловно важный вопрос на обеде, если ты заходишь в комнату и видишь, что коллеги работают?

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

    • Срочные вопросы надо решать по телефону (мессенджеру) или приходя к человеку лично.
    • Не срочные вопросы - по e-mail’у или в отдельно выделенное время (обед, кофе, курилка)

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

    Уважайте свое и чужое время.

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

  • Пылесос и мясорубка. Но пылесос главнее.

    Posted on February 11th, 2010 Александр Орлов 2 comments

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

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

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

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

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

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

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

    Подъем зарплаты. Что делает компания, которой надо срочно расшириться, а соответствующего имиджа нет? Поднимает зарплаты. В итоге получает себе на работу людей, которые готовы сменить компанию из-за плюс 10-20% к зарплате. Компания, привлекающая сотрудников только деньгами, получает сотрудников, которых привлекают только деньги. Если через полгода рядом кто-то объявит свой набор с плюс 10-20% к зарплате - вашей компании придется туго.

    «А пусть менеджеры за найм отвечают.» Ответственность за то, что к дате X должно быть нанято Y сотрудников, возлагается на менеджера. Нанял нужное количество сотрудников - выполнил задачу, молодец. Не нанял - не молодец. Менеджер кровно заинтересован в том, чтобы заполнить позиции к старту проекта. Внимание вопрос: насколько менеджер мотивирован потом уволить человека с испытательного срока? То есть, признать, что он, менеджер, ошибся в процессе найма. И снова оголить позицию? Зачастую менеджер не готов признать, что он поспешил. И тут он начинает работать с теми, кто оказался в команде, изучая науку педагогику и принимая напиток корвалол.

    Объявление hiring bonus’ов. Иногда своим сотрудникам предлагают большие деньги за каждого приведенного в компанию человека. Большие деньги - это порядка месячной зарплаты человека. Большие деньги - большая мотивация. :) Некоторые сотрудники воодушевляются настолько, что начинают приглашать в компанию всех, кого ни попадя. Горячо убеждая менеджеров, что «может быть, технически человек пока не очень, но зато командный игрок, надежный, ответственный человек, он точно разберется…» И менеджер попадает в небольшую ловушку:

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

    И снова нанимаем тех, кто есть. Все это помогает на короткий период времени. Чтобы можно было отчитаться перед топ-менеджментом, или заказчиком о заполнении позиций. А дальше - дальше менеджер начинает много работать. J Хвататься то за кнут, то за пряник, то за сердце. А надо было просто настраивать пылесос заранее.

    P.S. Заметим, что настраивать пылесос может и сам менеджер. А как именно его настраивать - когда-то давно была такая статья, сильно перекликающаяся с аналогичными материалами товарища Джоэла Спольски.

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

  • “С моей стороны баги вылетели…”

    Posted on February 8th, 2010 Александр Орлов 8 comments

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

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

    - Ну что, Петров, два.

    - Почему два.

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

    Студент берет бинокль, смотрит: «Ну, не знаю, с моей стороны все пули вылетели…»

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

    Вот, например, есть такая активность - верификация дефектов. Стандартная ситуация в проекте: тестировщики дефекты выставляют (например, в Bugzilla), разработчики героически дефекты исправляют (переводят в состояние FIXED). А проверять то, что дефект действительно был разрешен (перевести его в состояние VERIFIED) - это уже можно сделать перед самым релизом.

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

    То есть, одни дефект выставили (с их стороны пули вылетели), другие фикс положили в пространство кода (с их стороны пули тоже вылетели) - и все. J

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

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

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

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

    Posted on February 1st, 2010 Александр Орлов 2 comments

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

    Опытные: Статистические Значения

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

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

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

    В книге Тома Демарко и Тимоти Листера Peopleware есть история забастовки под названием работай-по-правилам. В ней рабочие букввально следовали формально навязанным правилам (процедурным руководствам), и, разумеется, прогресс сильно застопорился. Знание, когда правилам следовать, а когда нет, очень важно для эффективной работы. Вот, где опыт играет главную роль.

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

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

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

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

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