recoder, posts by tag: management - LiveJournal

mood: thoughtful

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

Закон Гудхарта

Любая метрика, принимаемая целью, перестаёт быть хорошей метрикой.

В оригинале Гудхарт, будучи экономистом, писал: "As soon as the government attempts to regulate any particular set of financial assets, these become unreliable as indicators of economic trends."

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

А в качестве байки на закуску - я бы напомнил историю про отлов кобр в Индии. В колониальные времена в Индии англичане решили что ядовитых кобр развелось слишком много и неплохо бы было уменьшить их популяцию. Недолго думая, они назначили небольшую награду за голову убитой кобры. Индусы начали массово истреблять змей, а когда их поголовье начало уменьшаться настолько что доходы змееохоты пошли вниз - основали фермы по разведению кобр. Белые люди фишку просекли, премии отменили, фермы были распущены, кобр стало ещё больше чем было, а всю историю нарекли "The Cobra Effect". Впоследствии, для тупых, история повторилась ещё несколько раз - с отловом крыс во Вьетнаме, истреблением воробьёв в Китае, и т.д. Поговаривают, что средневековый чумной мор - тоже следствие истребление котиков, считавшимися дьявольскими созданиями, да вот только закончилось это скрепное начинание крысиным раздольем. Но это уже начало совсем другой истории...

location: Омерика

mood: relieved

Помнится, когда-то я ненадолго угодил в менеджмент и начал пытался как-то отстраивать процессы в своём отделе. Сверху тогда настоятельно порекомендовали всё планировать в MS Project'e, типа "шеф терпел - и нам велел". И вот с того знакомства с этим продуктом я пока не встречал тех кто, приручая MS Project, не проводил бы долгие часы в борьбе с его внутренним эго. То он задачи по-своему разложит, то приоритеты пересчитает в самый неожиданный момент, то у него ресурсы внезапно перестанут сходиться. Честно говоря, все эти проблемы в конце концов решались (всё-таки мы же неглупые люди), но спустя некоторое время опять возвращались в самый неподходящий момент.

Когда же мы (уже на новой работе) затеяли планировать очередной релиз и на горизонте замаячил призрак MS Project'a, мы приготовились к новой бесконечной битве и загрустили. От печали и отчаяния пошли искать современные альтернативы этому динозавру, но как-то всё было либо криво, либо слишком абстрактно, либо наоборот на уровне багтрекера. Удобного инструмента для нормального менеджера всё не появлялось...

...пока совершенно случайно мы не наткнулись на Liquid Planner. Он внезапно оказался именно тем, что было нужно. Это такой правильный онлайновый project management, который позволяет гибко распланировать и вести проект именно так как мы обычно и делаем: ставим дедлайны, раскладываем проект на атомарные задачи, развешиваем их по исполнителям, те оценивают их (в лучшем и худшем вариантах) и ежедневно отмечают свои успехи. Менеджеру остаётся только смотреть на это, причём можно даже в ретроспективе через baselines, и принимать свои менеджерские решения. При надлежащей ответственности в ведении задач, можно даже автоматически timesheets делать. А редкой породе менеджеров умеющих кодить - есть REST API для доступа ко всем внутренностям - скриптуй сколько влезет.

В общем, замечательная вещь! Все пострадавшим от MS Project'a - настоятельно рекомендую!

mood: thoughtful

В дополнение к Методике Трёх Гвоздей народная мудрость ещё хранит басню о Трёх Конвертах:

Уходящий менеджер оставляет своему преемнику три запечатанных конверта и говорит:
- Когда на работе будут неразрешимые проблемы - открывай по одному конверту!

Прошло время, наступила первая жопа, молодой менеджер вскрывает первый конверт и читает: "Вали всё на меня". Так и сделал - переложил ответственность, остался в седле.

Прошло ещё время, случилась жопа посерьёзнее, и был вскрыт второй конверт. Там лежала бумага с советом: "Устрой глобальную реорганизацию". Молодой менеджер засучил рукава и приступил к масштабным проектам. Всё завертелось, процесс пошёл...

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

mood: cynical

Нашёл правильное правило 80/20 в интерпретации Дугласа Хофштадтера (не путать с Леонардом Хофштадтером, названого в честь физика Роберта Хофштадтера):

Я большой поклонник правила 80/20: никакой проект не занимает менее 80 часов и как бы вы не оценивали его продолжительность - умножьте это на 20.

что является следствием основного закона Хофштадтера:

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

via avva via Ycombinator

mood: amused

Помнится, когда-то я писал про оценки софтверных проектов и дополнением упомянул статью Эльдара eldarm Мусаева о "корпоративных паразитах".

Оказалось, eldarm - матёрый человечище! Наш человек, менеджирующий в Microsoft'e, который за прошедшие годы столько всего занимательного опубликовал: и про тех самых паразитов, и про менеджмент, и про экономические эффекты, и прочее. Конечно, не всё однозначно, со многим можно поспорить, но в общем и целом - мега-занимательно.

Коллегам - френдить обязательно!

» buzz

mood: disappointed

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

Интересно, что подобные эффекты я вижу и вокруг себя в программерской среде. В новый проект врывается на коне лихой менеджер-налётчик, не мудствуя лукаво срубает свои халявные 20% и оставляет остальное как "тривиальные технические детали". После чего весь в белом удаляется, а толпа народу долго и мучительно достраивает оставшиеся 80%. Проходит время, и это направление опять становится привлекательным для налётчиков.

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

mood: thoughtful

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

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

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

И отсюда проистекают несколько на мой взгляд важных выводов:

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

Вот примерно как-то так.

mood: disappointed

Недавно на ХабраХабре опубликована сатирическая статья "3 простых правила, которые сделают из вас Суперзвезданутого Программиста":

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

Правило 2: Пишите код быстро. Затроньте наибольшее количество файлов, и не забудьте включить каждый из них в ChangeLog. Не беспокойтесь о случайном создании трудно находимых ошибок; они помогут вам в будущем, потому что их, на самом деле, трудно найти. Избегайте создания тривиальных ошибок.

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

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

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

mood: thoughtful

Мой архитекторский опыт показывает, что проекты обычно пишутся два раза - сначала быстро, потом хорошо. Часто проекты останавливаются на черновой стадии - когда случается достижение стадии "20% are good enough". А вот все попытки написать сразу быстро и хорошо обречены на epic fail.

Ибо правила компромиссов никто не отменял.

mood: anxious

music: Podcast - Sick & Wrong

Пол Грэм опять выдал замечательное эссе "Maker's Schedule, Manager's Schedule" - на этот раз о различии рабочих графиков менеджера и программиста.

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

Вот такую очевидную вещь толкает старина Пол. И ведь прав, собака!