Выделены два подхода, которые потенциально позволяют дать объективную оценку того, насколько работа разработчика над проектом соответствует требованиям качества, сроков и бюджета.
Управление проектом — это организация процесса для успешного, т. е.
в отведенное время и без превышения выделенного бюджета, достижения поставленной цели.
Конечный продукт должен иметь изначально заданные свойства и быть приемлемого качества.
Во многих случаях необходимо найти баланс между ограничениями времени, стоимости и объема проекта.
Очень наглядной иллюстрацией является треугольник дизайна (изображение, на котором три стороны треугольника соединены, и изменение на одной стороне влияет как минимум на одну из двух других сторон, демонстрируя процесс балансировки ограничений).
В качестве примера можно рассмотреть ситуацию, когда необходимо сократить сроки сдачи проекта.
Это может потребовать увеличения вашего бюджета и использования большего количества ресурсов, чтобы выполнить тот же объем работы за меньшее время.
Если увеличение бюджета недопустимо, необходимо сократить содержание проекта, так как при имеющихся ресурсах невозможно выполнить весь запланированный объем работ за меньшее время.
Создание в отведенное время и в рамках заданного бюджета качественного программного обеспечения, удовлетворяющего реальные потребности заказчика, — это процесс, который можно и нужно описать языком управления проектами.
Разработчик играет одну из ключевых ролей в этом процессе.
Мне кажется, принципиально можно оценить профессионализм разработчика, если систематически оценивать результаты его работы с позиции того, насколько они соответствуют тройному ограничению.
В идеале каждая задача, поставленная перед разработчиком, должна быть решена так, чтобы:
- время работы не превышало времени предварительной оценки продолжительности данной работы,
- качество кода соответствовало заранее определенным критериям и стандартам,
- стоимость решения этой проблемы не превышала выделенной на это части бюджета.
(Но обсуждение этого вопроса выходит за рамки данной статьи, и мы по умолчанию считаем, что каждая задача, по которой оценивается профессионализм разработчика, поставлена правильно и не имеет крайне завышенных требований).
Зачем нам это надо?
- Повышение эффективности HR.
Объективные, насколько это возможно, критерии профессионализма разработчиков могли бы, например, помочь HR-менеджеру подобрать для конкретного проекта исполнителей, наиболее соответствующих требованиям, предъявляемым к этому проекту.
Сами разработчики, имея возможность объективно сравнивать свои способности со способностями коллег, могли бы более четко осознавать качества, над которыми им следует работать, чтобы повысить востребованность своего труда, повысить его темп.
- Довольный клиент.
Кроме того, внедрение использования объективных критериев профессионализма выгодно и заказчику, поскольку с его точки зрения повышает качество управления материальными и трудовыми ресурсами, тем самым улучшая общее качество управления бизнесом.
- Низкие затраты относительно ожидаемого эффекта.
Цена, которую придется заплатить, не слишком обременительна: повышенные требования к дисциплине и тщательному сбору и обработке данных.
На данный момент у нас запланировано два пути.
Они различаются подходами к двум из трех сторон треугольника управления проектами: графику и бюджету.
Прежде чем перейти к этим различиям, мы очень кратко опишем идею, лежащую в основе нашего подхода к оценке качества.
Помимо стандартных методов контроля качества, ожидается получение показателей качества кода с помощью статических анализаторов, таких как СонарКуб .
Я думаю, что эти данные можно соотнести с результатами работы каждого разработчика в проекте, а также оценить любые части проекта и проект в целом.
Не исключено, что дополнительным параметром оценки качества работы разработчика станет соотношение времени, затраченного на решение данной задачи, ко времени, затраченному на исправление ошибок, связанных с этой задачей.
Теперь о двух возможных подходах к деньгам и времени
Первый взгляд на эту проблему исходит из того, что не в каждом случае можно рассчитывать на наличие всех исходных данных..
В целом для расчета показателей, связанных с соблюдением сроков, необходимо:
- оценка задачи в часах разработчика, который будет ею заниматься (предварительно согласовывается с самим разработчиком);
- данные о том, сколько часов реально было потрачено на эту задачу (для этого нужен трекер времени);
- срок, к которому задача должна быть готова.
Подробное исследование всех этих вопросов заслуживает отдельной статьи, но самое главное то, что при таком подходе все величины, которые можно измерить в часах, днях и т. д., относятся к показателям времени.
Что касается характеристик бюджета, то данный подход рассматривает три варианта проекта с точки зрения ценового подхода:
- Проект с фиксированной стоимостью не предполагает отклонений от сметных характеристик в принципе.
- Проект «Время и материалы» означает, что стоимость линейно связана с затраченными часами, а это означает, что отклонение от бюджета идентично отклонению от сроков.
Таким образом, в этих вариантах фактически отсутствуют бюджетные показатели.
- В проекте с нестрогой фиксированной стоимостью, в котором есть возможность координировать изменения бюджета, потенциально неясно, какая часть изменения бюджета должна быть отнесена на счет «заслуги» конкретного разработчика.
В целом такой подход означает, что в треугольнике управления проектами для отдельного разработчика показатели бюджета не могут быть адекватно отображены, и остаются только метрики качество/график.
Сроки выполнения здесь измеряются с использованием календарных дат: дата начала, дата выполнения, фактическая дата.
В частности, показатель крайнего срока можно измерить как количество пропущенных сроков для задачи или как соотношение разностей между датой начала/датой выполнения и датой выполнения/фактической датой.
Показатель бюджета основан на предварительной оценке времени и времени, фактически затраченного на выполнение задачи.
Расхождение бюджета здесь предполагается рассчитывать как среднее отклонение затраченного времени от времени оценки.
В связи со всем вышеизложенным возникает несколько закономерных вопросов:
Во-первых, Какой из двух подходов, на ваш взгляд, лучше характеризует профессионализм разработчика в контексте соблюдения сроков/бюджета/качества? А какие варианты, кроме конструктивного треугольника, можно было бы использовать? Во-вторых , хотелось бы понять, можно ли соотнести бюджеты в деньгах с оценками и реальными часами, затраченными на выполнение задач? Что такое сроки и относятся ли они к оценкам или датам начала и срокам выполнения? Можно ли учитывать различия проектов по подходу к ценообразованию (фиксированная стоимость, время и материал, другие параметры) при расчете бюджетной метрики для конкретного застройщика или для него имеет смысл только подход с фиксированной стоимостью? Третий Интересно, насколько корректно использовать модель, иллюстрирующую объективные ограничения, возникающие в управлении проектами, для количественного описания профессионализма разработчика? Буду рад услышать ваше мнение по этому поводу! Теги: #Управление проектами #управление проектами и командой #разработчики #оценка качества #оценка персонала #Управление разработкой #Управление проектами-
Ибп - Виджет Рабочего Стола
19 Oct, 24 -
Google Заботится О Нас
19 Oct, 24 -
Демпинг Как Сигнал
19 Oct, 24
