recoder: (masked)

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

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

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

В оригинале Гудхарт, будучи экономистом, писал: "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". Впоследствии, для тупых, история повторилась ещё несколько раз - с отловом крыс во Вьетнаме, истреблением воробьёв в Китае, и т.д. Поговаривают, что средневековый чумной мор - тоже следствие истребление котиков, считавшимися дьявольскими созданиями, да вот только закончилось это скрепное начинание крысиным раздольем. Но это уже начало совсем другой истории...

recoder: (masked)

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

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

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

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

software management

recoder: (masked)

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

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

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

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

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

management

recoder: (masked)

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

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

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

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

via [livejournal.com profile] avva via Ycombinator

» buzz management

recoder: (masked)

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

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

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

» buzz management

Freeriders

Apr. 14th, 2010 07:53 am
recoder: (masked)

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

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

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

management

recoder: (masked)

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

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

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

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

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

management

recoder: (masked)

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

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

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

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

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

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

management

recoder: (masked)

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

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

management

recoder: (Default)
- Товарищ радист, почему ваше рабочее место не убрано?
- Хорошо вам, товарищ прапорщик, рот закрыл - рабочее место убрал...

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

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

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

management

recoder: (masked)

На прошлой неделе на Хабре коллега ZakharS в очередной раз поднял вопрос "Что делать когда достигнут потолок зарплаты". Дескать, способный программер за несколько лет быстро упирается в карьерный "стеклянный потолок", с которым непонятно что делать. Варианты есть, но они все весьма неприглядны.

Grumble, grumble... )

career management

recoder: (Default)

Отец [livejournal.com profile] gaperton написал крайне занятную статью "Читай код" о том, что лучшая документация - это хороший код. И в своём посте высказывает ещё много интересных идей (с которыми я однозначно соглашусь):

Читай код! )

Главная мысль такова: если код в порядке и есть умные люди - то документация не нужна. А если нету первого или второго - то документация уже не поможет. Вывод для многих неочевидный.

Читай код, сука! )

coding management

recoder: (masked)

Наткнулся сегодня у гениального [livejournal.com profile] gorba на подтверждение своей старой мысли. Или ты делаешь всё Правильно™ (сначала 20%, потом 80%, а потом всё остальное), или ты встаёшь на скользкий путь, в конце которого - выращивание марихуаны, как самый экономически рентабельный бизнес. Или зубами держишься за вернхюю планку, или идёшь на компромиссы с совестью. Всё остальное - осетрина второй свежести.

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

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

management

recoder: (Default)

Коллега [livejournal.com profile] white_bars не так давно изложил печальную ситуацию о программистском карьрном росте:

[...] IT перестала быть индустрией, где можно сделать карьеру просто честно работая, проявляя себя и от этого поднимаясь по служебной лестнице. На размышление меня сподвиг ряд обстоятельств, в том числе история одной моей давней знакомой, которая много лет безуспешно пыталась получить повышение, очень сильно переработала, сошла с ума, уволилась, вылечилась, вернулась и после этого получила таки небольшое, но повышение.
Ну и вот… Оглядевшись вокруг и присмотревшись к карьерам друзей и знакомых, что я вижу?
  1. Блуждание. Переход из одной фирмы в другую. Наиболее частый и успешный вариант. Если у тебя есть потенциал и репутация, то чем больше переходишь, тем выше поднимаешься. Вариант хорош, но у него есть естественные пределы (бесконечно переходить невозможно) и темноватая карма (как правило, поднимаешься, переходя в более мелкую фирму).
  2. Отскок. Разновидность предыдущего варианта: уходишь в другую фирму, потом возвращаешься с повышением. Как правило, после возвращения надолго застреваешь на новой должности: статистически шанс на очередное повышение примерно равен шансу того, что ты просто вылетишь.
    Можно еще уходить в другое подразделение (если структура позволяет) и возвращаться. Тоже работает.
  3. Размен. Работает с создателями мелких фирм, ушедшими с программерских должностей: раскручиваешь собственную фирму, пашешь как слон, честно делаешь себе имя, продаешься с потрохами какой-нибудь корпорации, разменивая гордое “CEO and Founder” на  “Technical Fellow” и на постоянную высокую зарплату. На карьеру это тянет.
  4. Высиживание. После 8-12 лет работы инженером тебя вдруг высочайшей милостью назначают каким-нибудь начальником. Реальной власти не дают, зарплату поднимают на копейки, а спрашивают по полной. Иногда кричат на тебя по телефону и лично, чтобы напомнить, кто ты есть на самом деле. К сожалению, это - основной вариант для моих бывших чешских коллег…
Вариант с добавлением к слову “программист” слова “главный” я не рассматриваю: это не карьера, это - подачка.

Комментарии тоже поучительны (и резонируют с моими взглядами на текущее положение дел):

  • [livejournal.com profile] aceler: Самый главный пункт — перестань наконец быть программёром, сисадмином и вообще специалистом и стань менеджером. У специалистов, особенно в IT, потолок очень близкий и сразу. У менеджеров потолка считай, нет.
    • [livejournal.com profile] white_bars: Я так понимю, то это - довольно распространенное заблуждение. По многим причинам. Но начать можно с того, что некогда писал незабвенный Филип Су. Ну, и я могу по опыту подтвердить, что он таки прав :)
    • [livejournal.com profile] white_bars: Ситуация всегда и везде одна и та же: народ массово ломится в менеджеры, там создается "высокое давление" и никакой взможности для карьерного роста - ОСОБЕННО если ты действительно обладаешь способностями хорошего менеджера. Обычно все "болезни" корпоративного уровня начинаются именно там: куча людей, не понимающих, что они делают, конкурируют друг с другом с целью доказать собственную нужность. Не то что карьеру делать - там просто обитать невозможно. Собственно, корпоративная среда, которую есть за что ненавидеть - это ровно оно и есть. Кончается это всегда одинаково плохо.
      • [livejournal.com profile] aceler:Если народ начал массово ломиться в менеджеры и перестал писать код, значит, или вы набрали не тех людей, или они занимаются не тем делом. Или те менеджеры, которые только что вылупились из девелоперов — хреновые менеджеры.
        Другое дело, что если вы хороший девелопер и хреновый менеджер, вам лезть некуда, а если наоборот?
        • [livejournal.com profile] white_bars: "Не те" люди - это реальность в ЛЮБОЙ крупной айтишной корпорации, живущей разработкой, внедрением и/или продажей софта. То есть, совсем любой.
          Корпорации вынуждены иметь дело не с тем, с кем хочется, а с тем, кто есть. Расширение почти однозначно эквивалентно росту пирамиды. Пока она растет - почти не имеет значения, кто ее наполняет: места хватает всем, и только от тебя зависит, насколько высоко тебя занесет. И, пока есть рост, наверх забрасывает наиболее энергичных, талантливых, продвинутых: собственно, писать о том, что IT в этом отношении была индустрией возможностей, я не стал - это подразумевается.
          Но рост фирм неизбежно замедляется, структура костенеет и превращается в корпорацию - всегда. А корпорации не нужны индивидуальности ("те люди"), корпорации нужна процедура. Ты энергичен? - Тем больнее биться об стену. Ты талантлив? - Это не требуется: надо писать код. Ты продвинут? - Будешь исправлять код после других. И даже на этом этапе еще все неплохо. Проблемы начинаются тогда, когда денег начнает не хватать. Кризис, там, или еще чего... И в этих условиях "не те" всегда побеждают: я не видел исключений. Начинается политика (не имеющая отношения к технологиям) и побеждают демагоги с длинными зубами. А тот ты человек или не тот, определяется твоими личными отношениями с начальником.

статистика друзей management

recoder: (Default)

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

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

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

Так и живём...

management

recoder: (Default)

Прошлым летом я почему-то не уделил должного внимания очередному крайне увлекательному эссе Пола Грэма "You Weren't Meant to Have a Boss". А на исходе года опять перечитал и много обдумывал, отрабатывая в офисе christmas bogus с 5 января.

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

Долгие размышления на заданную тему )

В общем, есть о чём подумать холодными зимними вечерами...

management

recoder: (Default)

Очень полезная статейка "Оценки софтверных проектов или равно ли целое сумме слагаемых?" (via [livejournal.com profile] fed_nik) про то, что...

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

Вообще - сказано много умных слов и сделаны практичные выводы:

  1. Оценка – это не то, когда проект будет сделан. Это время в которое он уложится с заданной вероятностью. Даже если менеджер или инженер этого не знают, она все равно есть и зависит от оптимизма инженера и агрессивности менеджера к отстающим.
  2. Менеджмент вносит на порядок большие ошибки в оценки проекта, складывая оценки отдельных шагов, нежели инженеры, оценивая эти индивидуальные шаги.
  3. Даже небольшие ошибки в оценках индивидуальных шагов могут значительно снизить надежность оценки всего проекта.
  4. И как обычно, калькулятор не заменяет мозгов, а Microsoft Project – искусства менеджмента.
  5. О, да, еще одно: Не сотвори себе кумира. В том числе и из модных методик.

Bonus: заметки на тему Корпоративные Паразиты © Eldar. Updated: [livejournal.com profile] eldarm: Корпоративные Паразиты

management

recoder: (Default)

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

via bash.org.ru

management

recoder: (Default)

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

Этапы Большого Пути )

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

  1. Предпринимательская стадия
    Акценты - на создании продукта и выживании на рынке. Управление неформально, что и становится первым кризисным моментом.
  2. Стадия коллективизма
    В компании образуются лидеры, но общение неформальное. Кризис роста начинается из-за отсутствия структуры с делегированием полномочий.
  3. Стадия формализации
    В компании вводятся строгие формальные процедуры, из-за чего и начинается бюрократизация компании. С ростом бюрократии уменьшается свобода участников процесса, что снижает эффективность.
  4. Стадия совершенствования
    Компания либо справляется с бюрократизацией (или реорганизацией, или делением на независимые подразделения), либо находит другие способы повышения конкурентоспособности, либо разоряется.

Более того - под всем этим лежит совсем серьёзная теория Competing Values Framework. Теория применяется для оценки эффективности компаний и индивидуальных ролей. Но там начитается такой суровый менеджменториал, что мне это становится недоступным.

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

management

20% Blues

Jun. 26th, 2007 07:17 pm
recoder: (Default)

Беда Правила 80/20 состоит в том, что он рассматривается исключительно в аспекте самоуправления (одного работника, отдела или всей корпорации). А проблема в том, что в цепочке «заказчик—исполнитель» каждый рассчитывает отдать 80%, а получить все 100%. N'est pas?

На деле же в конечном результате получается (0.8N)*100% от изначальных требований. А поскольку редко это закладывается в планы и очень редко кто-то желает идти на компромиссы, то обычно начинается процесс ассенизации после успешного аврала, который ко всеобщему неудовольствию имеет тенденцию занягиваться навсегда.

А вы - перфекционизм, перфекционизм...

Part2: Why You Won't Fix It Later.

management

April 2017

S M T W T F S
      1
23 456 78
9101112131415
16171819202122
23242526272829
30      

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 22nd, 2017 06:44 pm
Powered by Dreamwidth Studios