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

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

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

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

Создание, за отведённое время и в рамках заданного бюджета, качественного программного обеспечения, которое удовлетворяет реальным потребностям заказчика — это процесс, который можно и нужно описывать на языке управления проектами. Разработчик — одна из ключевых ролей в этом процессе. Мне кажется, принципиально возможно оценить профессионализм девелопера, если систематически оценивать результаты его работы с позиции того, насколько они соответствуют тройственной ограниченности.

В идеале каждая задача, которая поставлена разработчику, должна быть решена так, чтобы:

1. время работы не превышало времени предварительной оценки длительности этой работы,
2. качество кода удовлетворяло заранее определенным критериям и стандартам,
3. стоимость решения этой задачи не выходила за рамки выделенной для неё части бюджета.

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

Зачем это нам нужно?

1. Повышение эффективности работы HR.
   Объективные, насколько это вообще возможно, критерии профессионализма разработчиков могли бы, к примеру, помочь HR-менеджеру, подобрать для конкретного проекта исполнителей, которые наилучшим образом соответствуют предъявляемым к данному проекту требованиям. Сами разработчики, имея возможность объективного сравнения своих способностей со способностями своих коллег, могли бы яснее осознавать те качества, над которыми им следует работать, чтобы увеличить спрос на свой труд, и повысить свой рейт.
2. Довольный заказчик.
   Кроме того, внедрение использования объективных критериев профессионализма выгодно и заказчику, поскольку с его точки зрения это повышает качество управления материальными и трудовыми ресурсами, повышая тем самым общее качество управления бизнесом.
3. Небольшие затраты, относительно ожидаемого эффекта.
   Цена, которую придётся заплатить, не слишком обременительна: повышение требования к дисциплине и аккуратный сбор и обработка данных.

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

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

Теперь о двух возможных подходах к деньгам и ко времени

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

• оценка задачи в часах того разработчика, который будет ей заниматься (предварительно согласованная с самим разработчиком);
• данные о том, сколько часов реально было потрачено на эту задачу (для этого необходим тайм-трекер);
• срок, due date, к которому задача должна быть готова.

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

Относительно бюджетных характеристик этот подход рассматривает три варианта проектов с точки зрения подхода к ценообразованию:

1. Fixed cost проект не предполагает отклонения от бюджетных характеристик в принципе.
2. Time and Material проект означает, что стоимость линейно связана с затраченными часами, из чего следует, что отклонению от бюджета тождественно отклонению от сроков. Таким образом, в этих вариантах фактически отсутствуют бюджетные метрики.
3. При нестрогом же fixed cost проекте, в котором есть возможность согласовывать изменения бюджета, потенциально не ясно, какую часть изменения в бюджете следует отнести к «заслуге» конкретного разработчика. В целом, этот подход означает, что в треугольнике управления проектом для отдельного разработчика показатели бюджета адекватно отобразить невозможно, и остаются лишь метрики качества/сроков.

Второй взгляд предлагает часть метрик времени пересчитать на бюджетные показатели. Попадание в сроки здесь измеряется с использованием календарных дат — Start date, Due Date, Actual Date. Конкретно метрика срока может измеряться как количество сорваных сроков на задачу, или же как соотношение разниц между Start date/Due Date и Due Date/Actual Date. Показатель бюджета — строится на основе предварительной оценки времени и реально затраченного на задачу времени. Бюджетное расхождение здесь предполагается рассчитывать как среднее отклонение затраченного времени от времени оценки.

В связи со всем изложенным выше, возникает несколько естественных вопросов:

Во-первых, какой из двух подходов, на ваш взгляд, лучше описывает профессионализм разработчика в контексте попадания в сроки/бюджет/качество? И какие варианты, кроме проектного треугольника, можно было бы использовать?

Во-вторых, хотелось бы понять, можно ли соотнести бюджеты в деньгах с эстимейтами и реально потраченными часами в задачах? Что такое сроки и относятся ли они к эстимейтам или же к Start date и Due Date?

Возможно ли учесть различия в проектах с точки зрения подхода к ценообразованию (fixed cost, time and material, другие варианты) при расчёте бюджетной метрики для конкретного разработчика, или для него имеет смысл только fixed cost подход?

В-третьих, интересно, насколько корректно использовать модель, которая иллюстрирует объективные ограничения, возникающие при управлении проектами, для количественного описания профессионализма разработчика?

Буду рад услышать ваше мнение на этот счет!

Автор:

Источник