КаБа

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

У меня тут возникла потребность оценить эффективность работы руководителей проектов. Задача решалась долго и по-разному, но одинаково бесперспективно. А вот на днях как-то само собой придумалось. Постановка задачи Необходимо оценить эффективность работы руководителей проектов, выполняющихся по схеме time & material. Сразу оговорюсь, что на мой взгляд предлагаемая методика подходит и для схем fixed coast. Цель оценки – понять, кто успешно ведет проект самостоятельно, а за кем надо попристальнее присматривать. Критерии успешности хода проекта: • Соблюдение бюджета • Соблюдение плана выполнения проекта • Отсутствие критических проблем, способных зааффектить бюджет и календарь • Удовлетворенность Заказчика (субъективно, по отзывам) В чем идея  Идея основывается на еженедельной оценке хода проекта по трехбальной системе: красный (проект идет неуспешно), желтый (есть риск завалить проект в красную зону) и зеленый (проект идет успешно). Успешность проекта оценивается...

Тема всплыла на форуме UML2.ru . Я за форумом на этом сайте не слежу, тем более в нем не участвую (не потому, что он плохой, а потому, что времени нету), но по этой теме попытаюсь высказаться, поскольку близка она, эта тема.   Я б русский бы выучил только за то... Когда человек говорит, что хочет оценить коэффициент возврата инвестиций, то я могу предположить, что он просто хочет узнать, будет ли привлечение аналитика экономически оправданным. Но задаться таким вопросом человека мотивируют (на мой взгляд) две вещи: непонимание пользы от привлечения аналитика и желание численно (а потому наглядно) выразить эффект от участия аналитика в проекте. Зачем нужен аналитик на проекте, кто такой аналитик - это вопросы, объем обсуждения вокруг которых сопоставим разве что с темой про жизнь на Марсе. Ответов на эти вопросы ровно столько, сколько народу ими задавалось, поэтому выскажу свое личное мнение. Итого, если мы говорим об аналитике, как специалисте, знающем предметную область...

С метриками есть две засады: внедрение метрик, их сбор и анализ требуют определенных усилий, а соответственно – затрат; неправильно выбранные метрики приводят к неправильным решениям. Поэтому прежде, чем кидаться во все тяжкие с расчетами и анализом, необходимо для себя понять, действительно ли ситуация на проекте такова, что необходимо вводить более жесткий контроль. И если так оно и есть, то надо определиться, что именно необходимо ставить под контроль.

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

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

Продолжение… Начало темы тут: Оценка эффективности работы аналитика - предпосылки Если кому-то придет в голову спросить аналитика, чем он занимается. то он получит отличную возможность нарваться на долгий рассказ про процессы as is и to be, сценарии использования, требования, логические модели данных, прототипы пользовательских интерфейсов, шаблоны отчетов, алгоритмы конвертации чего-нибудь в кого-нибудь и т.п. Но ведь это всего лишь перечисление артефактов, над которыми работает аналитик! – воскликнешь ты и будешь совершенно прав. И это не те знания, которые помогут нам понять, как оценить эффективность работы аналитика и по возможности научиться управлять аналитикой не только по планам, но и по фактам.

Как оценить эффективность работы разработчика или тестировщика мне, положим, более не менее понятно. Но как быть с аналитиком - до последнего времени оставалось загадкой. Тем не менее на днях как-то вечером снизошло озарение и возникла пара идей, которыми я хочу поделиться с вами. Единственный момент – я не хочу просто вывалить идею, поэтому постараюсь расписать, как к ней пришел. С одной стороны это даст мне возможность ее переосмыслить, с другой – вы посмотрите на нее с изнанки и может предложете что-то более интересное. Но прежде, чем продолжить развивать мысль далее, предлагаю определиться с тем, что мы понимаем под термином “эффективность” и зачем нам ее оценивать. Итак, под эффективностью работы аналитика предполагается понимать способность специалиста выявить требования к продукту и донести их до команды таким образом, чтобы команда смогла в оговоренные сроки и с утвержденным бюджетом выпустить продукт, предельно отвечающий ожиданиям (не требованиям!) Заказчика. Оценка эффекти...