[life.photo] Несколько фотографий из весеннего леса

Дабы привыкнуть к углу обзора 35-мм объектива решил воспользоваться замечательной весенней погодой и выбрался с фотоаппаратом в лес. Несколько снимков счел достойными демонстрации публике. Карточки под катом. Правда, художественный вкус у меня отсутствует своеобразный, так что... ;)

[management.book] Владимир Тарасов, Искусство управленческой борьбы

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

Сначала небольшое отступление. Лично для меня наиболее полезны книги, которые построены по принципу: сначала небольшое объяснение основного механизма, затем простые примеры работы этого механизма, затем чуть более глубокое погружение в теорию, затем более сложные примеры. Таких книг вообще мало, навскидку вспоминается замечательная книга по программированию "Programming Ruby". Ну или тот же самый "Peopleware", он же "Человеческий фактор". Менее полезны книги, построенные только на примерах, без описания принципов, на основе которых эти примеры работают. К таким я отношу рабочие материалы того же Стратоплана. Т.е. сути вещей из них не поймешь, но каких-то приемов, которые можно будет применить на практике или же творчески развить, можно будет нахвататься. И совершенно бесполезны книги, в которых, автор пытается что-то объяснять и чем-то свои мысли иллюстрировать, но читатель (т.е. я) не понимает, ни что пытаются объяснить, ни каким боком к объяснениям относятся приведенные примеры.

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

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

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

[work.thoughts] Вновь KPI: подмена понятий и погоня за краткосрочным эффектом (часть третья)

Заключительная часть (см. часть первую и вторую).

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

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

• организация эффективного рабочего процесса с прозрачным определением сильных и слабых "звеньев цепи". Т.е. посредством введения KPI компания пытается диагностировать, где у нее есть проблемы с персоналом, кем нужно заняться очень плотно (вплоть до расставания), а кого нужно повышать и продвигать;
• организации прозрачной системы финансовой мотивации сотрудников, основанной на трансформации показателей KPI в проценты от максимальной квартальной/полугодовой/годовой премии.

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

---

Организация эффективного рабочего процесса без KPI

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

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

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

Не должно быть людей, которые находятся "не в теме". Разработчики (тестировщики, внедренцы, техписатели и т.д.) совершенно не уважают тех, кто не понимает, чем и как живет разработка. Разработчик может признавать формальную власть менеджера, который не понимает, что такое написание и отладка кода, не разбирается в предметной области и не знает особенностей продуктовой линейки компании. Но доверия и нормальных отношений с таким менеджером не будет. Однако, если разработчик знает, что менеджера "на мякине не проведешь", что даже ТОП-овый руководитель может задать серию уточняющих вопросов, отвечая на которые разработчику придется с головой погрузиться в самые непролазные дебри кода... Если руководитель с полуслова понимает, почему новое решение нужно собирать вот из этих компонентов... Если не нужно тратить рабочий день на объяснение того, почему нельзя за неделю поднять производительность на 150%... В общем, если на всех уровнях управляющей цепочки находятся грамотные, полностью погруженные в тему специалисты, то рабочий процесс оказывается действительно рабочим, а не процессом.

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

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

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

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

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

Компактное размещение (все люди в шаговой доступности) и возможность прямого общения (внезапный разговор с руководителем на кухне). Чем меньше барьеров, чем проще найти и очно пообщаться с любым разработчиком или менеджером, тем лучше. Сложно передать, как много полезной информации можно получить от разработчика, которого менеджер встретил в коридоре и случайно чем-то поинтересовался. Сложно переоценить вклад в открытость и прозрачность компании возможность рядового сотрудника задать любой вопрос руководителю на офисной кухне или в спортзале. Насколько же проще становится жизнь, когда тебе не жалуются, что начальник сидит за тридевять земель и не может оценить объем проделанной работы, а судит о работе сотрудника на основании двух-трех телефонных звонков в неделю. Невозможно переоценить возможность размещения молодого специалиста рядом с опытными сотрудниками, когда он получает возможность учиться не только работая над порученными ему задачами, а просто находясь в подходящей творческой атмосфере, ежедневно наблюдая за работой "старичков", сидящих за соседним столом. В общем, территориальная разнесенность офисов и удаленная работа -- это может быть продиктовано жизнью и приносить свои плоды. Но когда есть возможность разместить весь коллектив компактно и предоставить ему достаточно условий для рабочего и нерабочего общения не мешая работе остальных (open space must die!), то нужно это сделать.

Небольшие команды. Чем меньше команда, тем эффективнее она работает. Меньше коммуникаций, быстрее обмен знаниями и идеями. Но, в контексте данного разговора, намного важнее степень прозрачности, которая существует в небольшой команде. В отделе из 50 человек наверняка найдутся 2-3 сотрудника, которые позволяют себе работать спустя рукава. В команде из 5 человек все на виду и если кто-то филонит или не справляется со своей работой, то это сразу же заметно всем.

Реальная ориентация на качество. Любые разговоры об эффективной организации труда, нацеленности на результат, приоритете качества и пр. разбиваются в пух и прах одной простой фразой: "Да и хрен с ним, давайте по-быстрому слепим вот так, а потом разберемся!" Вы не заставите людей работать хорошо, если после правильных разговорах о сроках, качестве, мотивации, процессах и пр., вы будете демонстрировать, что на качество можно "забить" из-за сроков или стоимости. Что производительностью или функциональностью можно пожертвовать ради плана. Что к развитию проекта вернемся когда к тому возникнут предпосылки (т.е. когда жареный петух клюнет из-за невозможности справится с нагрузкой или слишком большой стоимостью очередной доработки). Если вы хотите качественной работы от своих сотрудников, то наглядно продемонстрируйте им, что качество востребовано. Что этапность плана можно подкорретировать, если что-то нужно довести до ума. Что над развитием проекта кто-то работает постоянно (пусть даже всего один-два дня в неделю). Что в поиске компромиссов между бизнесом и технологией далеко не всегда победа достается бизнесу. Что вы помните о какашечках, которые пришлось наложить в проекте техническом долге и находите время на его оплату, а не тратите силы в очередном релизе на красочную упаковку для старой какашечки.

---

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

---

Финансовое премирование без KPI

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

Работают проектные премии. Сдали проект или большой этап проекта вовремя и с должным качеством -- проектная команда (а так же те, кто находились рядом с ней) получили проектную премию. Не сдали, не обеспечили качества -- не получили. Все просто.

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

Еще в ряде случаев, на небольших временных интервалах, может работать штрафная система. Т.е. проектной команде объясняется, что их зарплата состоит из двух частей: фиксированной N и переменной M. По итогам каждого месяца от M могут отниматься некоторые суммы, если к работе сотрудника были претензии. Например, выкатил билд с большим количеством багов, т.е. не потратил достаточного количества своего времени -- вместо (N+M) получил (N+M/2). Пообещал что-то сделать, но не сделал -- лишился M вообще и получил только N. Это не простая схема, и работает она при соблюдении важных условий. Во-первых, важно выдерживать принцип уменьшения зарплаты при плохой работе (это совсем другое дело, чем премирование за хорошую работу). Во-вторых, обоснование уменьшения переменной части должно быть максимально объективным, схема перестанет работать, если сюда будут вмешиваться личные отношения. Поэтому здесь хорошо работает фиксация целей/обещаний, количественные оценки (количество ошибок, частота возникновения отказов в эксплуатации и т.д.), перекрестные оценки работы (например, работу программиста оценивают другие программисты, тестировщики, внедренцы, техписатели). В-третьих, сроки применения такой схемы должны быть небольшими и ограниченными (например, такая система может быть введена при вытаскивании проекта, оказавшегося в жопе в сложной ситуации, или при серьезном обновлении/запуске нового сервиса).

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

---

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

[life.photo] Пойман на фотоохоте :)

Редкий случай, когда я оказался в кадре во время съемок на 2-м этапе Кубка Гомеля по МТБ. Спасибо Алексею Голубеву за снимок (исходный кадр был взят из этого альбома, я только чуть-чуть подкропил и подшарпил его).

PS. Глядя на себя со стороны ловлю на мысли, что D700 для меня слишком маленькая по размеру камера. Видимо, нужно собирать на D4s, чтобы солиднее выглядеть :)

[work.thoughts] Вновь KPI: подмена понятий и погоня за краткосрочным эффектом (часть вторая)

Продолжение, первая часть здесь.

Еще одной серьезной проблемой KPI является ограниченный временной интервал, на котором производится "съем параметров". Например, существуют квартальные и годовые показатели эффективности, итоги по которым подводятся в конце квартала и в конце года.

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

Много лет назад мы с другом занимались проведением олимпиады по программированию в местном университете. Среди прочих была несложная задача по поиску оптимального плана дозаправки автомобиля. Автомобиль должен проехать из пункта A в пункт B, одной заправки автомобиля на этот путь может не хватить. Но по дороге расположены автозаправки с разной стоимостью топлива. Нужно найти оптимальный план заправки автомобиля, чтобы стоимость заправок по дороге из A в B оказалась минимальной. Известен объем бака, расход топлива на милю пути, но при этом на заправке можно заполнять бак только до полного объема (т.е. если в бак можно залить 15л топлива, то нужно именно 15л и залить, меньше нельзя).

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

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

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

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

Допустим, компания отметила свой 5-й день рождения. И для сотрудников определяются KPI на 21-й квартал. На двадцать первый! Т.е. этот временной отрезок уже составляет всего лишь 1/20 от времени жизни компании.

А если компании не 5 лет, а 15? Очередной квартал для нее будет всего лишь небольшим отрезком в 1/60 от общей продолжительности ее жизни.

А если не 15, а 30? Не 30, а 60?...

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

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

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

Так что это еще одна очень большая проблема KPI: концентрация на краткосрочных выгодах вместо долгосрочных.

Возможно, долгосрочные перспективы сейчас никого и не интересуют. Вроде как по статистике, изрядная часть компаний умирает не достигнув и 3-х летнего возраста, а подавляющее большинство живут не более 13-14 лет. Немногие пережившие 15-летний рубеж доживают до 50-60 лет, но все равно исчезают. И лишь считанные единицы продолжают жить после 60-летней отсечки.

Однако, если посмотреть на тот же Microsoft (компания основана в 1975-м, почти 40 лет назад) или Oracle (1977-ой)... Или даже на Google (1998-й) или Facebook (2004). Или основанные на просторах бывшего СССР: 1C (1991-й), EPAM Systems (1993-й), Лаборатория Касперского (1997-й), то окажется, что успешных софтверных компаний с более чем десятилетней историей не так уж мало.

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

[work.thoughts] Вновь KPI: подмена понятий и погоня за краткосрочным эффектом (часть первая)

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

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

Итак, проблема первая: что же сейчас выдают за KPI?

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

Суть проблемы в том, что KPI (т.е. ключевые показатели эффективности или производительности) должны показывать эффективность сотрудника по отношению к каким-либо установленным в организации нормативам или к другим сотрудникам. Например, если Петя и Вася клеят коробки для спичек и за 8 часов рабочей смены Петя склеивает 500 коробок, а Вася всего 400, то производительность Пети объективно выше производительности Васи. Если мы добавим сюда еще процент брака, производимого Петей и Васей, их зарплаты (а так же больничные, отгулы и пр.), то можно будет более-менее объективно оценить эффективность работы каждого из них.

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

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

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

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

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

По мнению эффективных менеджеров есть. Это -- сам факт выполнения сотрудником поставленной перед ним задачи. Например, если стоят перед Петей задачи по журналированию операций списания средств, пополнения и просмотра баланса по банковской карточке, то почему бы не объявить выполнение этих задач его KPI? Т.е. сделал за отведенное время все три задачи, значит его KPI -- 100%. А если сделал только одну -- значит всего 33%. Вот, казалось бы, и решение, которое дает какую-то объективную цифирь.

Да только все это фигня. По меньшей мере по двум причинам.

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

Во-вторых, разработка ПО -- это недетерминированный процесс. Рецептов, гарантирующих качественное решение задачи в точный срок и в рамках бюджета, до сих пор, насколько я знаю, не найдено. Слишком много здесь неопределенностей, зависимостей, случайностей и пр. неконтролируемых факторов. Может Петя и рад был бы сделать вовремя журналирование, но технический отдел не смог оперативно собрать тестовый стенд с нужным железом, объемами памяти, с соответствующим ПО. Поэтому, когда пришло время проверять работоспособность на больших объемах данных, то узкие места обнаружились слишком поздно. Или же Петя потратил слишком много времени на сбор информации от партнеров, которые должны были предоставить актуальное описание протоколов своей АБС и вовремя дать тестовый доступ к АБС, но не сделали этого и пришлось задействовать серьезный административный ресурс и ждать результатов разборок "в верхах". Или же Петя был отвлечен на устранение жесткого факапа на другом проекте, где он раньше работал и где срочно потребовалась его экспертиза. Или же внезапно заболел тестировщик, который должен был заниматься интеграционным тестированием написанных Петей модулей и на момент расчета KPI не известно, работают ли Петины модули или же в них баг на баге сидит и багом погоняет...

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

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

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

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

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

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

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

[life.photo] Весенняя велогонка по пересеченной местности в Гомеле

Сегодня в Гомеле прошла очередная велогонка по пересеченной местности. Такую же гонку я фотографировал осенью 2013. Тогда мне понравилось. Решил повторить эксперимент.

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

Получившиеся фотографии можно посмотреть в этом альбоме, либо же в слайд-шоу:

либо же забрать в виде zip-архива отсюда (фотографии 800px по длинной стороне).

Снимков, которые нравятся лично мне, практически нет. Те же, которые я считаю хоть сколько-нибудь ценными для себя, можно увидеть под катом. Кстати говоря, все снимки сделаны всего двумя мануальными объективами -- 35mm и 85mm (большинство с помощью 85-ки). Брал с собой еще и автофокусный 80-200, но он так и остался лежать в сумке.