Архив рубрики: управление проектами

DevOps — cкорость? Да, скорость

Если посмотреть на девяностые годы прошлого века, то они дали большое количество методологий (если кому больше нравиться фреймворков) разработки программного обеспечения: FDD (Feature driven development), Scrum, Rup, XP. Но самыми востребованными оказались не технические подходы, а ориентированные на людей. В 2001 году это все привело к появлению Agile-манифеста. Не надо нам качества, не надо нам поддержки изменений, дайте нам быстро то, на что можно посмотреть, а уж мы примем решение, что делать дальше. В настоящее время складывается ощущение, что социальные факторы себя исчерпали и для дальнейшего повышения скорости их уже не хватает. Подход, включающий не только «про людей», но и «про технологии», получил название DevOps. Давайте посмотрим на чем еще мы можем выиграть в скорости поставки полезности.

Продолжение статьи на Хабре.

Кто все эти люди?

На форумах MSDN задали вопрос "Поясните, пожалуйста, с примерами, чем junior и middle отличаются от senior?". Ответ на этот вопрос будет или субъективным, или очень формальным. Многие организации идут по второму пути. Вводят что мидла должен соответствовать критериям А, Б; миддл критериям В, Г; а синьор должен еще и Д и Е. За такими формальными штуками в эти организации. Под катом мое субъективное мнение никого ни к чему не обязывающее.



Junior - разработчик с небольшим опытом на применяемой платформе. С хорошим качеством может решать похожие задачи. Задачи с которыми раньше не сталкивался вызывают существенный перерасход по времени и выполняются с низким качеством (здесь могут быть как откровенные баги, так и архитектурные ошибки). Практически никогда не думает об альтернативных возможностях работы кода.
Middle - разработчик с опытом реальной разработки на платформе от года и выше. С хорошим качеством и в приемлемые сроки решает как повторяющиеся так и новые задачи. Архитектурные вещи, как правило, косячит. При написании кода предусматривает альтернативные сценарии (контроль входных данных, обработка ошибок).
Senoir - разработчик с очень хорошим знанием платформы. Может не только решать задачи, но и видит когда их можно не решать, может предложить альтернативные способы реализации лучше удовлетворяющие функциональным или нефункциональным требованиям. Полностью с приемлемым качеством может разрабатывать архитектуру средних и крупных программных систем. В зависимости от того к чему лежит душа в дальнейшем или все больше занимается архитектурными вещами и переходит в архитекторы, или больше занимается проработкой требований, обучением коллег и переходит в тимлиды.

Planing Poker

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

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

Время идет, ничего не меняется


Это самое ужасное рассуждение: если я не могу всего — значит, я ничего не буду делать.
 -- Лев Николаевич Толстой

Вот здесь, несколько картинок и рассуждений по Chaos Report 2015. Кому интересно, можно пойти и посмотреть в оригинале. Пару картинок которые мне показались интересными, я утащил под кат.

Первая картинка самая говорящая и именно она послужила причиной такого заголовка у этой заметки. Действительно, за последние 5 лет особо заметных изменений нет (картинки кликабельны):
Как была полностью успешна треть проектов, так и остается. Ровно половина проектов завершается со срывом сроков, запланированного объема работ или бюджета. И почти пятая часть от всех проектов так и не доходит до пользователей.
Вдумайтесь, за эти пять лет прошли тысячи конференций, выпущены миллионы книг и все это про то как писать код, управлять требованиями, проектировать архитектуру и в целом управлять проектами. В этот же период на смену четвертому PMBook вышел пятый. А воз и ныне там. Может мы не тем занимаемся?
Еще интересная картинка:
Из всех успешных проектов за 5 лет 62% это маленькие проекты! Т.е. если запускаешь средний или больше проект, шансы уложиться в срок и деньги составляют менее 7%. Одна пятнадцатая. Шансы вообще его хоть как-то выпустить в этом случае составляют 25%. Четверть! Впечатляет.
Ну и последняя картинка. Какие факторы наиболее важны для попадания в треть счастливчиков:
Как видно из картинки успех проекта на 60% состоит из поддержки руководства, эмоциональной зрелости (насколько люди хорошо взаимодействую друг с другом), вовлеченности пользователей и оптимизации процессов (в том числе, разбиением крупных проектов на мелкие).
Самое забавное, это Agile находящийся на 7 позиции. А анекдот здесь в том, что именно Agile говорит что надо взаимодействовать с пользователями, выпускать продукт инкрементально (в виде небольших проектиков закрываемых за две недели и поставляемых пользователю), а уж оптимизация процессов в Agile это один из ключевых моментов. Но ладно пусть будет седьмое место.
Вот так и живем...

Модель принятия решений Врума-Йеттона

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

В 2002 году у меня появились первые подчиненные. Само-собой, была куча ошибок, не очень удачных решений, но что-то и получалось. Часть на уровне интуиции, часть подсмотрев поведение других руководителей.
Если пользоваться классификацией психотипов предложенной Адизесом, то я "производитель". И видимо этим объясняется, что самым сложным в освоении навыком управления для меня было отдать принятие решений другим людям. Под катом упоминаемая в предыдущей статье модель, позволяющая на основе если-то понять, какой вид лидерства наиболее применим в текущей ситуации.
Как я уже написал выше, делегировать было для меня очень тяжело, ведь мне нравиться делать самому, а еще и психотип бубнит в уголочке, что я один знаю как правильно. И здесь очень важно без перегибов в ту или иную сторону. В каких-то случаях принятие решение должно остаться прерогативой руководителя, в других решения могут и должны приниматься командой или ее членами. Модель Врума-Йеттона как раз про это. Начнем с описания какие варианты поведения предлагает модель. Их всего пять:
Стиль AI. Вы сами решаете проблему или принимаете решение, используя имеющуюся у вас на данный момент информацию.
Стиль АII. Вы получаете необходимую информацию от своих подчиненных, и затем сами решаете проблему. Получая информацию, вы можете сказать или не сказать своим подчиненным, в чем состоит проблема. Роль ваших подчиненных в принятии решений - представление необходимой информации, а не поиск и оценка альтернативных решений.
Стиль CI. Вы излагаете проблему индивидуально тем подчиненным, кого это касается, и выслушиваете их идеи и предложения, но не собираете их вместе в одну группу. Затем вы принимаете решение, которое отражает или не отражает мнение ваших подчиненных.
Стиль СII. Вы излагаете проблему группе ваших подчиненных, и весь коллектив выслушивает все идеи и предложения. Затем вы принимаете решение, которое отражает или не отражает мнение ваших подчиненных.
Стиль GII. Вы излагаете проблему группе ваших подчиненных. Все вместе вы находите и оцениваете альтернативы и пытаетесь достичь согласия касательно выбора альтернативы. Ваша роль фасилитатора. Вы не пытаетесь влиять на группу, чтобы она приняла «ваше» решение, а хотите принять и выполнить любое решение, которое вся группа сочтет наиболее приемлемым.
Как видно, весь спектр, от авторитарного решения в одиночку, до передачи принятия решения группе. Для определения какой из этих стилей поведения применять, служат восемь вопросов:
1) Требование к качеству (QR): Насколько важно техническое качество решения?
2) Требование к приверженности (CR): Насколько важна приверженность подчинённых принятому решению?
3) Информация, доступная лидеру (LI): Имеешь ли ты информацию, достаточную для принятия самостоятельного решения?
4) Структура проблемы (ST): Является ли проблема хорошо структурированной (т.е. она ясно определена, ясна, ограничена во времени и так далее)?
5) Вероятность приверженности (CP): Если бы ты принял решение самостоятельно, достаточно ли очевидно, что твои подчинённые будут поддерживать это решение?
6) Конгруэнтность цели (GC): Разделяют ли подчинённые цели организации, которые должны быть достигнуты решением этой проблемы?
7) Конфликт подчинённых (CO): Вероятен ли конфликт между подчинёнными по вопросу предпочтённого решения?
8) Информация подчинённых (SI): Имеют ли подчинённые достаточно информации для принятия высококачественного решения?
Ну и смотрим на картинку которая описывает модель Врума-Йеттона (взята здесь):
Как этим пользоваться. Начинаем с первого вопроса и дальше, в зависимости от ответа, идем по стрелкам пока не дойдем до стиля поведения. Например, стоит вопрос, куда выбраться всей командой на выходные, чтобы поесть шашлыку на природе в хорошей компании. Поехали:
Первый вопрос: насколько важно техническое качество решения? Здесь сразу очевидный ответ, что техническое качество как таковое отсутствует и поэтому требования к нему низкие. Переходим по нижней стрелке ко второму вопросу: Насколько важна приверженность подчинённых принятому решению? Здесь тоже ситуация очевидна, если подчиненные не будут привержены принятому решению, то вместо приятного отдыха, будет обязаловка которая не принесет абсолютно никакой пользы. Значит выбираем ветку высокой важности.
По нижней стрелке переходим к пятому вопросу: Если бы ты принял решение самостоятельно, достаточно ли очевидно, что твои подчинённые будут поддерживать это решение? Нет, не очевидно что подчиненные будут привержены моему решению с выбором места и формата, может будут другие предложения, которые всех привлекут, например, съездить пострелять в пейнтбол или еще что-то. Перейдя по нижней ветке "Нет" мы приходим к модели поведения GII. Собираем мнения, помогаем договориться, но решение оставляем целиком на команде.
Ну а теперь о печальном.
Во-первых, если вопрос тривиален, то вместо принятия одного решения, может выясниться что надо принять от трех до восьми решений, а в конце может выясниться что и первоначальное решение надо принимать самостоятельно.
Во-вторых, кто сказал, что качество технической организации пикника имеет низкую важность? А что если мясо будет порезано неудачными кусками? А что если уголь будет некачественный? А что если шампуры не будут нормально держаться и будут прокручиваться на один бок и мясо прожариться не равномерно? И это пикник. В серьезном вопросе таких вопросов будет возникать еще больше и есть очень большой риск постоянно скатываться к авторитарному решению.
В общем, модель интересная, но больше как способ подумать над проблемой. Когда проблема достаточно серьезна чтобы потратить на ее обдумывание 10-15 минут (а может и больше), то почему бы не отдать ей должное и не подумать в рамках ее вопросов о том, кто будет принимать решение о том, как разбираться с проблемой.

О принятии решений

Есть две одинаково удобные позиции: либо верить во все, либо во всем сомневаться; то и другое избавляет от необходимости думать.
-- Анри Пуанкаре

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

Начнем с того, с чем я согласен. Во-первых, надо экономить мышление. Исследования показывают, что наш ресурс на принятие решений ограничен. Причем, батарейка этого ресурса общая с силой воли, что тоже хоть как-то но связано с принятием решений, но она еще связана и с памятью. Т.е. неважно думаем мы над чем-то, просто запоминаем что-то это приводит к расходу энергии. Во-вторых, я категорически согласен, с тем, что если есть несколько достаточно удачных решений, то надо не пытаться найти максимально верное решение, самое правильное решение, решение с наименьшими рисками. У меня на эту тему даже вот такая картинка рядом с рабочим местом висит:
И здесь проблема не только в обезьянке Тима Урбана. Мы не можем предсказывать будущее, от слова совсем. Никто и никогда не узнает как работает то или иное решение, к каким последствиям приведет, какие риски реализуются. И здесь действительно, чем раньше мы начнем действовать, тем больше вероятность получить результат, ну или понять, что этот вариант нас к нему не приведет.
Теперь о том, с чем не согласен. Здесь вот какая штука. Если нам не нравиться какая-то наша модель поведения, то да, привычки это 100% выход ее изменить. Про это как-нибудь отдельно, но основная идея в том, что не надо заставлять себя правильно питаться, должна быть привычка правильно питаться. Не надо заставлять себя что-угодно (мыть руки, читать инструкцию перед тем как сломать, заниматься спортом), а должна быть привычка. И это позволяет экономить пусть будет по Максу "мыслетопливо". Но у привычек есть и другая сторона. Как только мы переводим деятельность в бессознательное, т.е. решения принимаем "быстрой" подсистемой мозга, так тут-же качество этих решений ухудшается. То что было хорошо в той ситуации когда привычка вырабатывалась (нами осознанно или внешними обстоятельствами неосознанно), может оказаться не так эффективно, а зачастую и вредно в той ситуации в которой привычка пытается выстрелить.
Еще одним существенным минусом наличия привычек является отсутствие возможности потренировать мозг в принятии простых решений. В книге "Сила воли. Как развить и укрепить" даже одно из упражнений на тренировку силы воли и осознанности, когда мы боремся с привычкой. А тут нам говорят - забей, неосознанное супер.
Что же тогда с этим делать?
Первое и самое главное, это экономить мыслетопливо. Думать над задачей один раз, фиксировать принятые решения в системе учета задач и т.д.
Второе, для ситуаций когда решений больше одного понятно, но что делать с ситуациями с которыми не понятно? А здесь как раз упоминаемые вскользь в статье схемы если-то. И чем на большее количество таких схем будет настроен мозг, тем лучше. Кстати, это хорошая привычка прогонять по таким схемам все непонятно.
Ну и пара примеров на эту тему, а то в статье какой-то мутный.
Классика жанра, разбор входящих:

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

О кнуте и прянике


Я понимаю, что особенность российского менеджмента в том, чтобы бить пряником, но тут попались на глаза два интересных исследования, одно официальное, другое на уровне байки... Эффекты мне показались интересными, поэтому прошу под кат.
Я уже как-то поднимал вопрос о применении наказаний, но вот в чем загвоздка. Если наказание становится плановым и ожидаемым, то оно может спровоцировать на негативное поведение.
Итак первый эксперимент описан вот здесь. Для тех кто лениться читать много букв по ненашенски, краткая суть. Есть проблема, что родители опаздывают забирать детей из детских дошкольных учреждений. Была выдвинута гипотеза, что если ввести штрафы, то ситуация улучшится. Штраф ввели в размере 20 новых шекелей (эксперимент, если что, был в Израиле), что составляет порядка $5. Нужно понимать, что при постоянных опозданиях сумма может выйти в месяц к $100. Т.е. достаточно существенной. Результат оказался противоположным. Детей стали забирать позже:
Черный график это по садам где был введен штраф, белый - контрольная группа. Как такое может быть? Очень просто. Мы люди животные социальные. И в процессе эволюции был выработан такой замечательный механизм как совесть (социальная чуткость, если хотите). Мы научились ставить себя на место других. И когда из-за нашего опоздания задерживается воспитатель, нас это гнетет. Но достаточно ввести за это материальную ответственность, как совесть выключается и мы начинаем поступать так, как нам удобнее. Самое интересное, кстати, было потом, когда штрафы отменили. Совесть обратно не включилась. Нет, эффект при отказе от штрафов был, но к первоначальному значению опозданий так и не вернулись.
Второй, неверно, не эксперимент, а интересный опыт практикуется в компании Boing. Я по ключевым словам первоисточник не нашел, поэтому на уровне байки. Если кто найдет, буду признателен за ссылку. Здесь тоже пойдет речь про опоздания, но вот только не с детьми и детскими садами, а с опозданиями на работу. Каждый сотрудник компании Boing проходя через проходную до официального начала рабочего дня получает лотерейный билет. По которым проводилась ежемесячная лотерея. Не все билеты были выигрышными, поэтому чем больше у тебя билетов (читай чем чаще ты приходишь на работу вовремя), тем больше шансы выиграть неплохой приз, вроде как разыгрывалась бытовая техника. После внедрения такого новшества количество опозданий сократилось на 70%.
Так что, не всегда наказания позволяют изменить поведение, а вот всякие трюки геймификации действуют на нас, наемных сотрудников, весьма неплохо. Правда у меня есть подозрение, что эффект будет не очень долгосрочным и стимулы придется менять.

Персики, лимоны, рынок вакансий в IT и как все это связано

Эта статья подготовлена для блогов журнала PCWeek.
В 2001 году Джордж Акерлофа получил нобелевскую премию по экономике за анализ рынков с ассиметричной информацией. Ходит байка, что когда он впервые отправил статью про персики и лимоны в экономический журнал, ее отклонили, посоветовав такие статьи отправлять в журналы по садоводству. Что же за понятия персиков и лимонов ввел Акерлофа, и какое отношение они имеют к рынкам с ассиметричной информацией? И вообще, причем здесь вакансии в IT? Вот об этом и предлагаю поговорить.

Одним из очень ярких примеров рынка персиков и лимонов является рынок подержанных автомобилей. Под персиком на нем понимается хороший автомобиль, под лимоном - автомобиль, только выглядящий как хороший, но таковым не являющийся. Покупатель, в отличие от продавца, не владеет информацией о том, какой автомобиль перед ним. Это и есть рынок с ассиметричной информацией. Из-за такой асимметрии продавец персика не может запросить цену выше, чем стоящий рядом продавец лимона. Ведь в этом случае покупатель купит лимон, поскольку при осмотре персик и лимон выглядят одинаково.
Теперь от рынка подержанных автомобилей перейдем к вакансиям в IT. На рынке труда ситуация очень похожа. Кандидатов можно условно разделить  на две группы: лимоны (вроде что-то и умеют, но работать и учиться особо не хотят) и персики (может, не всегда много знают, но много и продуктивно работают, хотят обучаться, расти). Понятно, что кандидаты, как правило, адекватно оценивают себя, а вот рекрутеры не всегда. Отличить лимон от персика, особенно, когда лимон уже прошел несколько собеседований, а персик пришел только на первое-второе, практически невозможно. Ситуация усугубляется еще тем, что рекрутер, возможно, и хочет персик, но, имея «лимит по цене», готов взять и лимон, лишь бы закрыть вакансию. А выбирая лимон, он еще и деньги «сэкономит». Сэкономит в кавычках, так как после покупки лимона компании в достаточно краткосрочной перспективе придется его увольнять, открывать вакансию и снова начинать круг поиска.
Давайте взглянем на эту ситуацию с точки зрения теории игр. Рассмотрим атомарную игру, в которой рекрутер предлагает оффер, а кандидат принимает или отклоняет его. Для простоты, пусть лимон приносит компании 50 единиц прибыли, а персик 200. В случае, когда лимон и персик не знают своей стоимости, выставив цену в 125 единиц, набирая одинаковое количество лимонов и персиков, на каждом лимоне мы будем терять 75 единиц, а на персике получать 75 дополнительных. Глядя на существующий рынок труда, мало кто согласится, что количество лимонов и персиков на нем одинаковое. Получается, что даже в условии симметрии информации ( когда ни рекрутер, ни кандидат не знают, кто он - персик или лимон) мы остаемся на нуле только при одинаковом количестве лимонов и персиков на рынке. Но, если цена всех будет одинакова, то персики с рынка будут вымываться: зачем учиться, если все равно будешь стоить 125?
Ситуация становится еще хуже, когда информация асимметрична. Персик, получив предложение в 125, от него откажется, ведь он знает, что его цена 200. А вот лимон, услышав 125, согласится, ведь он-то знает, что его красная цена 50. К чему же это приводит:
  1.      . Лимоны переоценены
  2.      . Персики недооценивают, становиться ими нет резона и…
  3.      . Рынок персиков исчезает

Собственно за эти выводы Джордж Акерлофа и получил нобелевскую премию по экономике.
Как же можно предотвратить исчезновение рынка персиков? Самое главное - это не соглашаться на лимон, если вам нужен персик. Очень показательный пример описан в одном из номеров  Harvard Business Review Россия в заметке "Во что обойдутся низкие зарплаты", где сравнивается стратегия Wal-Mart, проявляющаяся, в частности, в жестком ограничении зарплат сотрудников, и его прямого конкурента Costco, у которого относительные затраты на персонал существенно выше, а число сотрудников во столько же раз меньше. Показано, что в долгосрочной перспективе Costco получает надежный и эффективный персонал, а также низкую текучесть кадров. Ведь наличие талантов в организации в конечном итоге намного важнее размеров их оплаты труда.
Внимательный читатель задаст вопрос: «А как же отличить персик, ведь у нас рынок с ассиметричной информацией?» А вот это второй шаг. Должен быть изменен подход к рекрутингу IT-персонала. Сейчас на первом собеседовании соискателя на вакансию встречает, как правило, молодая девочка без существенного опыта за плечами. Она задает типовые вопросы и предлагает типовую ставку. Как на это реагируют лимоны и персики, можно посмотреть в описании игры выше. Да, это дорого - проводить первичные собеседования высококвалифицированным, опытным сотрудником. Но здесь возникает вопрос: «А не дорого ли нам обходится регулярный найм лимонов, и что мы будем делать, когда рынок персиков окончательно схлопнется?»

О KPI и мотивации

Эта статья подготовлена для блогов журнала PCWeek.

«Наиболее важные факторы, необходимые для управления любой организацией, как правило, неизвестны и количественно неопределимы»
Э. Деминг, "Выход из кризиса"
Открывая новый проект, запуская изменения в существующем процессе, мы придумываем метрики и задаем KPI. И, как правило, за достижение этих KPI назначаются ответственные, которые получат бонусы или будут наказаны за несоответствие реальности целевым индикаторам. Предполагается, что наличие таких показателей должно стимулировать исполнителей. Но как на самом деле все это работает? В большинстве случаев – странно.

Если бизнесом организации не является разработка программного обеспечения или аутсорсинг IT-услуг, то практически невозможно привязать показатели подразделений IT к ее экономическим результатам. Например, бизнес запускает новый вид услуг, IT внедряет соответствующую инфраструктуру, но прибыль запущенная услуга не приносит. Кто виноват? IT или экономическая ситуация на рынке? Или другой пример: IT повысило надежность предоставляемых бизнесу сервисов с 95% до 98%. Бизнес получил прибыль на 10% больше по сравнению с предыдущим годом. Это достижение IT или особенность все той же экономической ситуации? В результате, появляются KPI, не имеющие никакого отношения к полезности IT для бизнеса. Сотрудники не понимают, зачем требуются такие показатели. А все то, что люди не понимают, или вообще не делается, или делается спустя рукава. А раз делается плохо, то вводится материальная мотивация. И тут возникает вторая проблема – локальные экстремумы.
В IT, в связи с производственными особенностями, работают умные люди. Поэтому, когда необходимость KPI не понятна, а за несоответствие показателю будут наказывать рублем (да, неполучение премии - это наказание), сотрудники начинают искать локальный экстремум. В нем KPI должен быть выполнен, а вот работы на это должно быть затрачено по минимуму. Как это проявляется? Допустим, мы ставим KPI программистам по количеству багов. В этом случае обнаружение каждой ошибки в тестировании будет выливаться в целое представление. «Нет, это не ошибка! Нет, это не моя ошибка, а ошибка внешней библиотеки!» А через какое-то время может выясниться, что разработчик договорился с тестировщиком, и тот сообщает об обнаруженных ошибках неофициально. В итоге в багтрекере багов нет, а в продукте есть. Конечно, такие KPI дают эффект на первом этапе, но потом дела будут идти все хуже и хуже, так как все будут стремиться обмануть систему, чтобы соответствовать именно требуемому показателю, пусть даже в ущерб компании. Хуже всего то, что менеджеры, в надежде избежать такой ситуации, добавляют третью проблему – избыточную сложность.
«Ах, вы научились обманывать KPI? Давайте добавим еще вот эту, а потом вот эту метрики». И тогда мало того, что начинается «гонка щита и меча» между метриками и теми, кто пытается их обмануть, так еще и на поддержание этой системы тратятся огромные ресурсы. Бывает, что это заканчивается коллапсом системы, так как через достаточно небольшое время уже никто не понимает, что считается, как считается, как проверяется.
Что же делать? Во-первых, не применять KPI, не понятные команде. Необходимо создавать систему, в которой люди могут делать свою работу. Ведь мы их приглашали на работу именно потому, что они могут и, самое главное, хотят работать, развиваться, расти. Во-вторых, не нужно придумывать метрику под KPI. Должна быть поставлена некая цель и подобраны практики, позволяющие ее достичь. Должна быть выбрана максимально простая и прозрачная метрика, позволяющая измерить эффективность применения практики. Должны быть назначены понятные и достижимые целевые значения метрики. И только тогда все это соберется в KPI. В-третьих, KPI должен быть принят исполнителями, они должны понимать, как его выполнение улучшит именно их работу.
Если эти пункты кажутся слишком сложными, то есть путь проще: открываем http://kpilibrary.com, вводим ключевое слово и берем верхний KPI из результатов поиска. На сайте десятки тысяч KPI, почему бы и не взять из них первый попавшийся?