Просто навеяло и захотелось написать о ...

О программистах, менеджерах и вахтерах ...

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

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

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

Вопрос этот, как впрочем и все вопросы, относящиеся к живым людям, - штука сложная. Тут нет простых рецептов или правил, иначе множество толстых книг по HR менеджменту давно бы заменила тоненькая брошюрка из 4-5 страниц под названием "Как за 10 минут раздать всем задания и отправиться спокойно смотреть футбол" (пока же, к сожалению, на ум скорее приходит что-то типа "Как сделать так, чтобы все приходили вовремя? Как завершать проекты в срок? Как отучить людей часами болтать по аське? Об этом и множество других интересных вещей читайте в нашем журнале "А х.. его знает!").

Чтобы у вас не было предубеждений еще до начала чтения (хотя возможно именно сейчас они и появятся), давайте пройдемся по паре очень распространенных стереотипов.

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

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

Эту историю одни рассказывают как анекдот, другие - как реальный случай. Однажды корпорация Sony (в ту пору бывшая еще не такой крупной корпорацией) пригласила консультантов для оценки эффективности работы ее сотрудников. После завершения работы они дали в целом положительную оценку. - Однако, -заметил один из консультантов,- вам стоит уволить вон того парня. По моему он никогда не бывает занят делом, всякий раз, когда я его видел, он сидел на стуле, закинув ноги на подоконник и смотрел в окно. - Знаете,- ответил консультанту Акио Морита, - однажды он предложил идею, которая сэкономила фирме сотни тысяч долларов. Наколько я помню, в тот момент его ноги занимали такое же положение.

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

Если вы подумали "Вот здорово" или недоверчиво скривились, вспомните, что все имеет свою обратную сторону. Какие бы свободные условия работы не были в Microsoft, когда некоторые проекты (например разработка приложений из пакета MS Office) входили в завершающую фазу, разработчик мог быть поднят в 3 часа ночи, если по его вине не строился daily build. И все для того, чтобы остальные программисты могли приходить на работу не задумываясь о том, что когда они прийдут, что-то может не работать.

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

Во сколько начинать рабочий день?
А что делать, если люди будут опаздывать?
А как сделать, чтобы они не отвлекались? Может запретить ICQ или интернет?
А вот знакомый рассказывал, что у них все приходят вовремя, потому что за опоздания штрафуют.
А что тогда считать опозданием?
А если они выходят покурить минут на 15 каждый час?
И как быть с пропущенными днями? Пусть приносят справки от врача?
Или все равно они за деньги любую справку достанут, а из-за 1-2 дней вызывать врача очень не удобно.

Я слышал много ответов на эти вопросы и все они каким-то образом обосновывались. Вот только проблема в том, что ответы были прямо противоположные. В одной крупной киевской фирме рабочий день начинается в 8:30 утра. За день у вас есть возможность пообедать (на это дается 40 минут) и дважды по 10 минут отлучиться покурить (по крайней мере так было год назад). А вот в другой (не менее крупной) вы можете приходить с 9 до 11, как вам удобнее. А хотите - пообщайтесь с начальством и вам могут разрешить один день в неделю работать дома. А есть еще одна, больше похожая на первую. И еще три, похожие на вторую. И все они считаются серьезными и успешными. Разница конечно есть, но для того чтобы ее найти, нужно как следует покопаться в отчетности по выполненным проектам. И поговорить с ребятами, которые там работают. И посмотреть на процент увольнений. А всю эту информацию очень не любят выносить из избы, то есть из офиса.

Так что прийдется нам думать самим. С чего начнем? Знаете, как-то Дмитрий Давыдов рассказал в своем блоге о первом вопросе, который задает Дэн Кеннеди¹ клиентам, которые хотят заказать у него рекламу чего-бы-то-ни-было. Это вовсе не "какие примущества именно у вашего предложения?" или "кто ваши главные конкуренты?". Вот этот вопрос: "Скажите, почему вы занялись этим бизнесом?".

Вот и мы попробуем раскрутить цепочку с самого начала.

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

Чем же в первую очередь определяется успех проекта?

Используемой методологией? RUP, XP, MSF, Crystal, SCRUM или PSP? Алистер Коуберн изучил более трех дюжин проектов - с количеством участников от нескольких человек до нескольких сотен, длившихся от нескольких месяцев до нескольких лет. Кто-то имел СММ 5-го уровня и использовал PSP/TSP², ну а где-то процессы вобще не были определены. Главные выводы?

• Практически любую методологию можно с успехом применять в каком-нибудь проекте
• Любая методология может привести к провалу проекта

Применяющимися технологиями? Геральд Вайнберг писал свою "The Psychology of Computer Programming" ("Психология программирования"), основываясь на тех проектах, которые он исследовал в 60-е годы. Используемые технологии успели смениться не один раз, однако его выводы остаються справедливыми и полезными и сейчас, более 30 лет спустя.

Чтобы поискать ответ на этот вопрос, давайте-ка перенесемся на 5 лет назад в горы Юты на лыжный курорт The Lodge at Snowbird. Именно там, в феврале 2001 года, семнадцать человек собрались, чтобы пообщаться, покататься на лыжах, расслабиться, попытаться прийти к общему знаменателю и, конечно же, поесть. Что получилось в результате, знает наверное каждый. Еще не сообразили? Давайте по другому. Кент Бек, Алистэр Коуберн, Вард Каннингем, Мартин Фаулер, Рон Джеффрис, Роберт К. Мартин ...
Да, именно, Agile-манифест. Его не нужно перечитывать полностью, в первых же строках стоит:

Люди и их взаимодействие важнее чем процессы и средства

Еще более лакончино выразился Коуберн: "Главное в любом проекте - люди, они решают все".

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

Вы еще здесь? Ну хорошо, тогда я вкратце расскажу вам общую идею, а статьи потом вы все таки прочтите, идет?

Итак, существуют три метода управления людьми:

Метод номер один: командный

Смысл понятен по названию. Результат - не работает. Причина? Дело в том, что разработчики:

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

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

Метод номер два: экономическая мотивация

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

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

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

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

Роберт Остин (Robert Austin) в своей книге "Измерение и управление производительностью в организациях" (Measuring and Managing Performance in Organizations) пишет, что существует два этапа внедрения новой метрики для измерения производительности. Сначала вы получаете то, что хотели, потому что никто пока не понял, как обмануть систему. На втором этапе вы получаете нечто худшее, чем то, с чего начинали, потому что все будут обманывать систему, чтобы максимизировать измеряемый показатель, даже рискуя погубить компанию.

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

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

Метод номер три: Метод отождествления

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

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

Вот только потом этот энтузиазм может постепенно уменьшаться и уменьшаться. Словно ржавчина, его потихоньку разьедает безразличное отношение лидера, приходящего на работу вовремя, но и уходящего ровно в 18:00. Или штраф, за то что он опоздал на 15 минут. А может фразы, обращенные ни к кому "ну что, мы как всегда выбились из графика?". И даже несколько раз выданная премия может убить остатки энтузиазма. Как? Все дело в том что люди быстро привыкают к хорошему и потом уже воспринимают это как само собой разумеющееся. Один раз получить премию - приятная неожиданность. В следующий раз ты уже думаешь - а выплатят ли ее опять? Заплатили - ок, все нормально. Заметьте - уже просто нормально. Хуже всего получается в третий раз, когда премию ты ожидаешь и мало того, почему-то на нее рассчитываешь. И если ее не дадут - ты поймешь, что все считают, что ты плохо работаешь. "Ну и ладно",- думаешь ты, - "раз они так считают и не собираюсь я больше стараться!" А ведь ситуация ничем не отличается от той, что была три месяца назад, когда премий просто не было.

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

---