powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Форумы / Управление процессом разработки ИС [игнор отключен] [закрыт для гостей] / Мерить объем работы и производительность
41 сообщений из 41, показаны все 2 страниц
Мерить объем работы и производительность
    #34764261
Tolja
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Добрый день!

Я-программист, с некоторыми обязанностями (10-20 % рабочего времени), которые традиционно воспринимаются как обязанности руководителя проекта.

Все программисты в компании, где я работаю разбиты на группы. Каждая группа работает с определенным клиентом. "Моя" группа, как мне кажется выгодно отличается от все остальных в смысле эффективности (производительность, низкое кол-во "багов" и т. д.). Однако, все это лишь слова, если их не подкрепить фактами.

Например, если сказать, что мы выполнили столько-то часов работы из которых клиент заплатил за 90%- это конечно один показатель. То есть лишь 10% процентов времени было потрачено на исправление ошибок, за что клиент не платит- вроде неплохо, так?

С другой стороны, если мы за все это время написали 100 строк кода, то вроде и объем работы невелик, а мы потратили, ну скажем 500 часов. Могли бы за тоже время написать 200 строк (добавить еще больше фукциональности) и получить плату за 1000 часов, хотя фактически потратили 500 часов. Тут получается, что мы вовсе неэффективны. Это просто пример.

В связи с этим ВОПРОСЫ:
1. Как собственно мерить объем выполненной работы на душу населния?? Зафиксировать сколько строк было добавлено за определенный отрезок времени (проект)? Кол-во ошибок в этом объеме нового кода? Еще какие-то показатели?
2. Как профессионально показать, что "мой" проэкт управляется и выполняется более эффективно, чем другие?

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

С уважением,
Анатолий.
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34764361
Фотография maxim_caban
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Что мы у себя отслеживаем:
1. Совпадение плана фактического и базового. (Насколько не укладываемся в планы).
2. Динамику изменения кода
3. Количество ошибок, найденных при тестировании
4. Количество ошибок, найденных при приемочном тестировании заказчиком
5. Количество ошибок, найденных при эксплуатации системы
6. Динамику выполнения запросов на изменения (новый функционал и изменение существующего)
7. Соблюдение принятых внутренних процедур (стандарты кодирования, конфиг. управления, просмотры кода и т.д.)

Плюс время от времени можно проводить независимый аудит планов работ. Т.е. проверять их "адекватность" (что то что можно сделать за 2 дня не планируется на 2 недели)

В идеале надо каждую работу стандартизовать (при поддержке больших промышленных систем это вполне реально) и ввести нормы на каждую задачу. Тогда все еще проще.

Но основной вопрос - а зачем мерить то? Если просто "захотелось" - нафиг оно надо. А обосновать что-то руководству можно "подгоном" данных под ответ.

"если вы не измеряете, вы не можете управлять
если вы не измеряете, вы не можете улучшать
если вы не измеряете, вам, вероятно, все равно
если вы не можете влиять, то не стоит и измерять"

Автора не помню :)
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34764521
Tolja
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maxim_cabanЧто мы у себя отслеживаем:
1. Совпадение плана фактического и базового. (Насколько не укладываемся в планы).
2. Динамику изменения кода
3. Количество ошибок, найденных при тестировании
4. Количество ошибок, найденных при приемочном тестировании заказчиком
5. Количество ошибок, найденных при эксплуатации системы
6. Динамику выполнения запросов на изменения (новый функционал и изменение существующего)
7. Соблюдение принятых внутренних процедур (стандарты кодирования, конфиг. управления, просмотры кода и т.д.)

Плюс время от времени можно проводить независимый аудит планов работ. Т.е. проверять их "адекватность" (что то что можно сделать за 2 дня не планируется на 2 недели)

В идеале надо каждую работу стандартизовать (при поддержке больших промышленных систем это вполне реально) и ввести нормы на каждую задачу. Тогда все еще проще.

Но основной вопрос - а зачем мерить то? Если просто "захотелось" - нафиг оно надо. А обосновать что-то руководству можно "подгоном" данных под ответ.

"если вы не измеряете, вы не можете управлять
если вы не измеряете, вы не можете улучшать
если вы не измеряете, вам, вероятно, все равно
если вы не можете влиять, то не стоит и измерять"

Автора не помню :)

"2. Динамику изменения кода"- а это как измерять? Что это такое?
"6. Динамику выполнения запросов на изменения (новый функционал и изменение существующего)" Что такое "новый функционал и изменение существующего" я понимаю. А что такое динамика оного? И как ее мерить? И если ее много, то это хорошо или плохо?

Зачем мерить? У нас дуют ветры перемен и шефы решили стандартизировать все процессы согласно "ИТИЛ", слышали о таком? http://]http://en.wikipedia.org/wiki/ITIL

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

Любому программисту, который выполняет полный цикл разработки, а именно обсуждение требований с заказчиком, помощь заказчику в формулировании оных, дизайн, возвращение к работе на требованиями, изменения требованией, прототип, обратно к требованиям и дизайну, разработка, заказчик вдруг добавляет новые требования и изменяет старые, опять прототип, заказчик доволен, разработка, поставка, поддержка и т.д. Так вот, любому програмисту ясно что модель (типа "waterfall"), где все четко разбито на фазы и все черно-белое это в сегодняшней индустрии програмного обеспечения ПОЛНЫЙ БРЕД и доказательство наличия отсутствия компетенции. "Мой" проект работает по модели "Agile" и в течении более чем 3 лет (обновление ПО новыми "фичами", которые заказываются каждые полгода) клиент был доволен и продолжает активно заказывать и платить.

Однако, чтобы оспаривать "мудрые решения" руководства, которое хочет стандартизировать процессы (это хорошо), но ни х..я не смыслит в том, кто это должен реализовывать (это плохо) необходимо критиковать и делать это профессионально (не называя неких лиц разными словами). Необходимы факты, объяснение современных теорий и практик управлениями проэктами разработки ПО (например Agile) и разумные аргументы. Вот чем я собственно и занимаюсь в свободное время..
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34766807
Так_забежал_просто
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maxim_cabanНо основной вопрос - а зачем мерить то? Если просто "захотелось" - нафиг оно надо. А обосновать что-то руководству можно "подгоном" данных под ответ.
+1. ИМХО, измерять, по-хорошему, нужно "полезность" команды разработчиков. А что такое "полезность"? А чёрт его знает. "Полезность" - она только на уровне субъективных ощущений бывает. Можно проводить опрос общественного мнения, например. Но тоже не показатель - пользователи могут быть не заинтересованы во внедрении системы.
Так как руководство-то убедить? Да чёрт его знает, опять-таки. Измерения тут вряд ли помогут. Это работа больше для политика и психолога, чем для учёного.
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34780326
belugin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мне очень понравилась книжка экстремальное программирование планирование

Есть программка XPlanner , которая это поддерживает.
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34782531
Так_забежал_просто
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
beluginМне очень понравилась книжка экстремальное программирование планирование

Есть программка XPlanner , которая это поддерживает.
Автору, может быть, это и поможет делать реалистичные предсказания сроков, но вряд ли это само по себе может убедить руководство, что команда работает лучше других. Предсказание сроков - это одно, а выполненная работа делить на срок - это совсем другое. Выполненную работу никак не измеришь...
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34782566
belugin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ага не вчитался. Тогда надо мерять некоторую прибыль от проекта, наверное. Руководству оценить полезность проекта, а потом измерить сколько на него угрохано
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34811575
Tolja
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Так_забежал_просто beluginМне очень понравилась книжка экстремальное программирование планирование

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

Привет!

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

Далее имеется кол-во программистов в группе. Здесь уже можно как-то косвенно считать производительность и сравнивать с другими проэктами. Эти "другие" проекты, естественно имеют
те же составные. Кол-во заказанных новых функций и штат программистов/менеджеров.

Я (шестым чуством) чуствую, что моя группа в два раза как минимуму эффективнее. Как только я вышеупомянутые показатели переведу на бумагу это уже будет не "шестое чуство", а факт.

Пока что не перевел, но начал..
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34813536
belugin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
еще есть некая методика под названием function point analysis для оценки объема функционала.
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34818508
Фотография Big17
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
beluginеще есть некая методика под названием function point analysis для оценки объема функционала.
Данная методика предназначена для оценки трудоемкости проекта перед его реализацией на основе бизнес-модели...
Tolja же говорил о сравнении эффективности работы разработчиков... это немного другое... здесь более уместны рекомендации maxim_caban
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34822715
Так_забежал_просто
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ToljaОдин из показателей (измеряемый) это естественно количество этих добавленных возможностей.
Что такое новая возможность? Это новая кнопочка? Новая формочка? Или новый модуль?
Если сделали формочку, но все пользователи стонут, что работать с ней невозможно - это новая возможность или нет?
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34822716
Так_забежал_просто
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ToljaЯ (шестым чуством) чуствую, что моя группа в два раза как минимуму эффективнее. Как только я вышеупомянутые показатели переведу на бумагу это уже будет не "шестое чуство", а факт.

Пока что не перевел, но начал..
Лучше то же самое время потратить на доказательство делом...
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34827689
Tolja
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Так_забежал_просто ToljaОдин из показателей (измеряемый) это естественно количество этих добавленных возможностей.
Что такое новая возможность? Это новая кнопочка? Новая формочка? Или новый модуль?
Если сделали формочку, но все пользователи стонут, что работать с ней невозможно - это новая возможность или нет?

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

За формой или кнопочкой "лежит" разумеется определенная функциональная возможность, которая может быть больше или меньше по объему и сложности реализации.

Насчет "доказать делом" это через чур расплывчато и не измеряемо. Представте себе два клиента и две команды которые работают на них. Оба клиента довольны и хотят продолжать сотрудничество. Но одна команда в 5 раз больше другой. Как сравнить кто эффективнее? Тут "доказательство делом" не поможет. Надо как-то мерить и сравнивать.
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34869779
Tolja1.Я-программист, с некоторыми обязанностями (10-20 % рабочего времени), которые традиционно воспринимаются как обязанности руководителя проекта.
2."Моя" группа, как мне кажется выгодно отличается от все остальных в смысле эффективности (производительность, низкое кол-во "багов" и т. д.). Однако, все это лишь слова, если их не подкрепить фактами.
3.Как профессионально показать, что "мой" проэкт управляется и выполняется более эффективно, чем другие?
4.У нас дуют ветры перемен и шефы решили стандартизировать все процессы согласно "ИТИЛ", слышали о таком?
5.Необходимы факты, объяснение современных теорий и практик управлениями проэктами разработки ПО...
6.Я (шестым чуством) чуствую, что моя группа в два раза как минимуму эффективнее. Как только я вышеупомянутые показатели переведу на бумагу это уже будет не "шестое чуство", а факт.
7.Но одна команда в 5 раз больше другой. Как сравнить кто эффективнее? Тут "доказательство делом" не поможет. Надо как-то мерить и сравнивать.Сначала большая ложка дегтя:
1."которые традиционно воспринимаются" - что за чушь?! Для начала определитесь сами! Вы или руководите людьми, или стоИте сбоку...
2.Аффтар жжот! Если вы не можете определиться руководите ли вы своей группой, то откуда у вас умение сравнить ее с другими?!
3.Для начала прекратите писать слово проЕкт через "Э"!!! А то скоро начнете заказчикам говорить непередаваемо-рязанское "ОУКЭЙ"
4.Вообще-то ITIL - это скорее стандарт организации сервис-менеджмента (если крайне примитивно - качественной техподдержки), а не процесса разработки. То, о чем вы говорите, это скорее управление проектами - ссылайтесь на PMBOK, MOF и т.п. Почитайте книгу имени моего ника... ;)
5.См. п.3 и п.4.
6.Интуиция для РМ-а очень важна, но только если она подкрепляется знаниями. ПРостите, но в вашем случае я слегка сомневаюсь.
7.Супер вопрос. Сравнивать надо так, чтобы ваши аргументы были понятны начальству!
Итого рисуется образ ребенка, который уверен, что он самый замечательный, но не знает, как доказать это окружающим...

Теперь по делу.
Вы не знаете, в чем считать? ПРИДУМАЙТЕ!!! Самое банальное - посчитайте, сколько денег принесла конкретно ваша группа за месяц. Чем не критерий? А теперь посчитайте "прибыль на одного члена группы". А теперь сравните полученную прибыль с ФЗП группы фактически вы получите "коэффициент возвращения инвестиций". Возьмите те же самые показатели, но за год. Постройте их динамику по месяцам. Посмотрите, скольких клиентов конкретно ваша группа обслуживает. И сколько денег эти клиенты дают в общей прибыли. Так же рассмотрете динамику их числа. Придумайте другие вариации на эту тему. Обычно самые "доступные" для шефов критерии - сугубо денежные... Можете рискнуть ввести оценку сложности кода, отказоустойчивости, удовлетворенности клиентов и т.п. - но боюсь вы это не потянете. Да и бесполезно вводить эти критерии, если вы не проходите по главному - по деньгам. Никто не захочет за свой счет удовлетворять любопытство "группы крутых профи". ИМХО.
Дальше - вы хотите СРАВНИТЬ себя с другими? А готовы ли к этому они?! То есть вы вообще понимаете, что подобные сравнения должны проводить абсолютно третьи люди?! Или же сравнение должно проводиться на основе общедоступных фактов (а это снова деньги/ФЗП/численность команды) и ТОЛЬКО по ОБЩЕМУ согласию. Иначе вас любая другая группа пошлет нах - и будет права. И вообще это можно делать ТОЛЬКО по приказу руководства!
И заодно прикиньте - а готова ли к результатам этого сравнения вы лично и ваша группа?! Если вдруг выяснится, что вы ХУДШИЕ?! Назад ведь дороги не будет!!! Не повесят ли они тогда инициатора сравнения на первом же столбе????
ЗЫ. Считайте изложенное ИМХО, но стиль, в котором вы задали вопрос.... Он ИМХО выдает некоторый недостаток знаний/опыта/возможно уровня...
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34872681
Фотография Big17
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
почитайде "ДедлайнСначала большая ложка дегтя:
1."которые традиционно воспринимаются" - что за чушь?! Для начала определитесь сами! Вы или руководите людьми, или стоИте сбоку...

Человек же конкретно написал, что он занимается руководством коллектива на 10-20% своего рабочего времени. Всем это было понятно.


почитайде "ДедлайнСначала большая ложка дегтя:
2.Аффтар жжот! Если вы не можете определиться руководите ли вы своей группой, то откуда у вас умение сравнить ее с другими?!
3.Для начала прекратите писать слово проЕкт через "Э"!!! А то скоро начнете заказчикам говорить непередаваемо-рязанское "ОУКЭЙ"

Придираетесь к человеку за несущественную ошибку, а сами говорите на "албанском". Прочитайте правила (http://sql.ru/forum/rules.aspx) - на этом форуме это запрещено! С легким сердцем я могу вас за это просто забанить.


почитайде "Дедлайн
Теперь по делу.
Вы не знаете, в чем считать? ПРИДУМАЙТЕ!!! Самое банальное - посчитайте, сколько денег принесла конкретно ваша группа за месяц. Чем не критерий? А теперь посчитайте "прибыль на одного члена группы". А теперь сравните полученную прибыль с ФЗП группы фактически вы получите "коэффициент возвращения инвестиций". Возьмите те же самые показатели, но за год. Постройте их динамику по месяцам. Посмотрите, скольких клиентов конкретно ваша группа обслуживает. И сколько денег эти клиенты дают в общей прибыли. Так же рассмотрете динамику их числа. Придумайте другие вариации на эту тему. Обычно самые "доступные" для шефов критерии - сугубо денежные... Можете рискнуть ввести оценку сложности кода, отказоустойчивости, удовлетворенности клиентов и т.п. - но боюсь вы это не потянете. Да и бесполезно вводить эти критерии, если вы не проходите по главному - по деньгам. Никто не захочет за свой счет удовлетворять любопытство "группы крутых профи". ИМХО.
Дальше - вы хотите СРАВНИТЬ себя с другими? А готовы ли к этому они?! То есть вы вообще понимаете, что подобные сравнения должны проводить абсолютно третьи люди?! Или же сравнение должно проводиться на основе общедоступных фактов (а это снова деньги/ФЗП/численность команды) и ТОЛЬКО по ОБЩЕМУ согласию. Иначе вас любая другая группа пошлет нах - и будет права. И вообще это можно делать ТОЛЬКО по приказу руководства!
И заодно прикиньте - а готова ли к результатам этого сравнения вы лично и ваша группа?! Если вдруг выяснится, что вы ХУДШИЕ?! Назад ведь дороги не будет!!! Не повесят ли они тогда инициатора сравнения на первом же столбе????
Способ, который вы предлагаете - считать денежки - больше подходит для оценки работы менеджеров по формированию портфеля заказов. А с точки зрения реализации, более дорогой проект по трудоемкости может быть гораздо меньше, чем более дешевый. Соответственно оценка не будет отвечать поставленным автором топика требованиям...


почитайде "Дедлайн
ЗЫ. Считайте изложенное ИМХО, но стиль, в котором вы задали вопрос.... Он ИМХО выдает некоторый недостаток знаний/опыта/возможно уровня...
Поэтому человек и обращается за советом в форум и ждет именно совета, а не подобных высказываний...
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34875479
Big171.Человек же конкретно написал, что он занимается руководством коллектива на 10-20% своего рабочего времени. Всем это было понятно.
2.Придираетесь к человеку за несущественную ошибку, а сами говорите на "албанском". Прочитайте правила (http://sql.ru/forum/rules.aspx) - на этом форуме это запрещено! С легким сердцем я могу вас за это просто забанить.
3.Способ, который вы предлагаете - считать денежки - больше подходит для оценки работы менеджеров по формированию портфеля заказов. А с точки зрения реализации, более дорогой проект по трудоемкости может быть гораздо меньше, чем более дешевый. Соответственно оценка не будет отвечать поставленным автором топика требованиям...
4.Поэтому человек и обращается за советом в форум и ждет именно совета, а не подобных высказываний...
Ну давайте для начала я принесу извинения автору, если его обидел, и лично Вам, если Вас это задело. Теперь по порядку.
1.Человек написал полную неуверенности фразу, из которой ничего конкретно не следовало. Можно уделять руководству и 5% времени - но при этом стоит быть уверенным, что ты РУКОВОДИШЬ, а не выполняешь "некоторые обязанности, которые традиционно воспринимаются как...". ИМХО при таком самоопределении даже не стОит соваться в "передел приоритетов" между группами. Что своими дальнейшими вопросами автор ИМХО и показал.
2.Если честно, то бана я не хочу. Да вроде и не вижу особо, за что. ""Коверканье" слов русского языка. "... Тогда прошу прощения. Честно. Давайте будем считать, что у меня на ноутбуке просто клавиатура слегка плохая - то есть была опечатка? Хотя Вы ведь сами сказали, что это был не русский, а "албанский" - так что я это правило вроде не нарушал . Но! Если "типа руководитель" группы ПОСТОЯННО пишет "проЭкт" (посчитайте сами) - я бы усомнился в его компетенции и грамотности! Уж извините. Да еще учтем, что ITIL - это теперь, оказывается, стандарт организации разработки ПО...
3.Автор топика никаких требований к оценкам не поставил. В любом случае, своими силами он в состоянии посчитать лишь денежные критерии. К тому же кроме денег я указал и критерии подсчета по клиентам из соображений их значимости и т.п. А все остальное должно считаться централизованно, по одобренным всеми участниками методикам и явно не автором. Согласны? Да и неужели Вы оспорите факт, что практически 99% руководителей не будут давать повышения людям, которые делают мегасложные вещи, но не приносят денег?! Сразу оговорюсь - факт того, что эти вещи критически важны для имиджа фирмы, для работы других отделов, для удержания ключевых клиентов и т.п. должен учитываться отдельно.
4.Совет ИМХО я ему дал. Самый первый совет - а готов ли он сам и его команда к результатам такого оценивания?! И есть ли у него силы и права это инициировать и провести, раз он всего лишь "выполняет то, что традиционно считается ..."? Второе - пусть сначала сам посчитает самое "лежащее на поверхности". И третье - без готовности руководства к таким оценкам даже волну поднимать не стоит. А то засунут автора туда, куда ....ну вы все поняли.
ЗЫ. Еще раз извиняюсь, если обидел Вас или автора.Считайте все ИМХО.
ЗЗЫ. не надо бана
ЗЗЗЫ. а у нас делают модераторами после 370 высказываний? Из которых в модерируемой ветке 40? не воспримите как оскорбление, просто действительно интересно.
ЗЗЗЗЫ. см.ЗЗЫ
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34876664
Фотография Big17
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Tolja
...традиционно воспринимаются как обязанности руководителя проекта....

...В связи с этим ВОПРОСЫ:
1. Как собственно мерить объем выполненной работы на душу населния?? Зафиксировать сколько строк было добавлено за определенный отрезок времени (проект)? Кол-во ошибок в этом объеме нового кода? Еще какие-то показатели?
2. Как профессионально показать, что "мой" проэкт управляется и выполняется более эффективно, чем другие?

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

Думаю, автор не совсем корректно назвал себя - мне видится, что он не руководитель проекта, не менеджер и не аналитик, а ведущий программист (или тим-лидер, или архитектор и т.п.). Можно предположить, что ему больше интересна оценка эффективности на локальном уровне - как на уровне команды, так и на уровне конкретного специалиста. Вряд-ли тут имеет смысл говорить об эффективности управления проектом в целом - слишком много влияющих факторов - начиная от бизнес-моделирования и проработки требований к системе и заканчивая умением конкретного руководителя распределять задачи с учетом индивидуальных наклонностей (или "отклонений" :) ) конкретных разработчиков.
Поэтому, для оценки эффективности работы команды я бы еще раз согласился с предложением maxim_caban'а:
maxim_caban
1. Совпадение плана фактического и базового. (Насколько не укладываемся в планы).
2. Динамику изменения кода
3. Количество ошибок, найденных при тестировании
4. Количество ошибок, найденных при приемочном тестировании заказчиком
5. Количество ошибок, найденных при эксплуатации системы
6. Динамику выполнения запросов на изменения (новый функционал и изменение существующего)
7. Соблюдение принятых внутренних процедур (стандарты кодирования, конфиг. управления, просмотры кода и т.д.)

А если внедрена система управления изменениями (Rational ClearQuest, Borland StarTeam или т.п.) - то подобная статистика получается очень просто. Например, можно рассмотреть оценку количества ошибок...
Допустим по результатам тестирования какой-нибудь альфа-версии в двух командах было выявлено и зарегистрировано по 10 дефектов... Однако у одной команды - это мелкие недочеты, а у другой - серьезные дефекты. В том же ClearQuest'е легко построить сравнительную диаграмму с учетом "серьезности/строгости" дефектов (и в ClearQuest'е и в StarTeam'е - это поле "Severity") - наглядно будет видно, какая команда допускала более серьезные промахи в реализации, при одинаковом количестве выявленных ошибок... Это один из примеров, но он показывает, как можно пусть и в "штуках", но все таки посчитать эффективность разработчиков.
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34876671
Фотография Big17
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
почитайте Дедлайн
ЗЫ.
ЗЗЫ.
ЗЗЗЫ.
ЗЗЗЗЫ.
Насчет бана не волнуйтесь - считайте это за призыв к конструктивному общению без излишних эмоций и мелочных придирок.

А по поводу модераторства... - это же самая молодая ветка форума, сообщений здесь еще не очень много (60 тем). Да и не количеством сообщений заслуживается модераторство - просто это была наша (maxim_caban и big17) инициатива к руководству форума по организации отдельной ветки. А переехали мы сюда с almportal'а ( http://almportal.ru/servlet/public/index?page=forums/thread/index?id=894 ).

Надеюсь, что нашими совместными усилиями эта ветка превратиться в серьезный информационный ресурс.
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34877462
Бывалый ЗЫ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
>почитайте Дедлайн

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

ЗЫ: Знания - сила. Все гениальное - просто.
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34878236
Big171.Насчет бана не волнуйтесь...
2.А по поводу модераторства...
3.Надеюсь, что нашими совместными усилиями эта ветка превратиться в серьезный информационный ресурс.1. Считайте это шуткой. Нельзя же все время делать умное лицо
2. За пояснение спасибо. Просто было интересно.
3. Хотелось бы. Хотя и есть на этот счет опасения... Просто элеменарные вопросы будут здесь не особо интересны (как ближайший пример пример - мое отношение к автору "проЭктов", "выполняющему нечто, традиционно воспринимаемое некоторыми как...", который пытался как-то непонятно посчитать что-то неизвестное...). Хотя начинающим это конечно и будет школой, не спорю. А серьезные... ну они обычно настолько серьезны, что не всякий ими поделится Может, потому большинство из тем и сводится к особенностям программ контроля версий и т.п.? Авось изменится, конечно. И всем нам этого желаю!!!
ЗЫ. Лично я бы конечно предпочел пообсуждать здесь именно особенности управления проектами и архитектурных подходов к построению КИС.
ЗЗЫ. нечто подобное есть на хедхантер.ру/лив, кажется. Но там оно ИМХО несколько вялое...
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34878278
Бывалый ЗЫ1.Согласен, со второй половиной "Теперь по делу".
2.И критерии (мультипликатры) в денежном выражении подобраны верно. В деньгах наглядно будет для любого руководства:)
3.ЗЫ: Знания - сила. Все гениальное - просто.1.Боюсь, что и в первой половине я тоже был прав
2.Подозреваю, что других критериев вы просто и не подберете. Или же они будут высосаны из пальца. И уж абсолютно точно вы не сможете оценить по этим "суррогатно-самостийно-наукообразно-замудренным" критериям чужие проекты. Или же эту вашу оценку оппоненты из других команд разобьют в пух и прах за 30 секунд (даже если вы будете правы).
А в деньгах для всех наглядно. Ведь и разработчика не удержишь на месте одним только пением про гениальный и интересный проект - он требует денег! А чем его директор хуже?!
3.Согласен. За "гения" - спасибо!
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34879397
AlexTheRaven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Прибыль от проделанной работы - это, конечно, самый лучший индикатор. Но иногда он является слишком дискретным (поэтапная оплата), становится доступен слишком поздно (после выпуска продукта) или недоступен вообще (при работе с внутренними заказчиками).
Но есть функциональные точки, трудозатраты в "идеальном" времени, % реализованной функциональности.
Количество строк кода - IMHO вообще самый плохой индикатор. Изменение объёма исходников, в Кб, и то лучше!
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34879417
just_nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlexTheRavenПрибыль от проделанной работы - это, конечно, самый лучший индикатор. Но иногда он является слишком дискретным (поэтапная оплата), становится доступен слишком поздно (после выпуска продукта) или недоступен вообще (при работе с внутренними заказчиками).
Но есть функциональные точки, трудозатраты в "идеальном" времени, % реализованной функциональности.
Количество строк кода - IMHO вообще самый плохой индикатор. Изменение объёма исходников, в Кб, и то лучше!Смотрим самый первый пост - автор собирался в общем-то тайком посчитать и сравнить показатели своей и других групп. Думаете, ему кто-либо безоговорочно предоставит адекватные данные о "функциональные точки, трудозатраты в "идеальном" времени, % реализованной функциональности"(с) для других групп?! Особенно, если эти группы и правда хуже?! А потом, Вы считаете, автор сможет защитить свою точку зрения перед начальством, на напроверенных-то данных?!
В то время как финансовые показатели для разных групп хоть как-то найти реально (кто-то проболтался, где-то подсмотрел, что-то просто не скрывалось и т.п.)
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34879921
Так_забежал_просто
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1. Насчёт прибыли от проделанной работы. Товарищ Друкер об этом забавно пишет. Предположим, был у компании лояльный заказчик. Пришёл менеджер, решил содрать с него денег побольше. А просто так. Обещая при этом существенное улучшение качества, через какое-то время. Прошёл год. Прибыль от проекта "зашкаливает", менеджер получает премию и линяет. После чего компания остаётся наедине со злым заказчиком.
2. Насчёт количества функциональных точек. Тоже, в общем-то, сомнительный критерий качества. Ну да, допустим, программисты что-то пишут. Какие-то точки. Но точки "мёртвые", пользователи никогда по этим веткам кода не ходят. Работа кипит, но все недовольны. Т.е. при оценке полезности точки нужно суммировать с неким весом. Где взять вес?
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34879981
Так_забежал_просто1. Насчёт прибыли от проделанной работы. Товарищ Друкер об этом забавно пишет. Предположим, был у компании лояльный заказчик. Пришёл менеджер, решил содрать с него денег побольше. А просто так. Обещая при этом существенное улучшение качества, через какое-то время. Прошёл год. Прибыль от проекта "зашкаливает", менеджер получает премию и линяет. После чего компания остаётся наедине со злым заказчиком.
2. Насчёт количества функциональных точек. Тоже, в общем-то, сомнительный критерий качества. Ну да, допустим, программисты что-то пишут. Какие-то точки. Но точки "мёртвые", пользователи никогда по этим веткам кода не ходят. Работа кипит, но все недовольны. Т.е. при оценке полезности точки нужно суммировать с неким весом. Где взять вес?А "товарищ Друкер" больше ничего не пишет? Хоть забавного, хоть нет. В частности о том, что приходит менеджер проекта, открывает книгу "товарища Друкера", видит в ней, что вес для функциональных точек взять неоткуда, а прибыль сегодня на самом деле может означать убытки послезавтра - после чего забивает на подсчет хоть каких-то показателей работы. И проект благополучно загибается от того, что нет возможности контролировать ход работ по нему...
Я это все к чему... Оспорить можно любую идею. Но тогда предложите свою. Еще раз предложу "в ответ" почитать "товарища ДеМарко". Особенно место, где он пишет, что менеджер может измерять производительность работ хоть "галуподах". Лишь бы этот критерий давал реальные данные. А чему ТОЧНО равен один "галупод" - можно вычислить и позже. Только учтите следующую тонкость - с термином "галупод" нельзя идти к директору. Особенно в САМОСТОЯТЕЛЬНОЙ попытке как-то возвысить свою группу над остальными. К директору надо идти с терминами "деньги", "прибыль", "число клиентов" и т.п.
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34880036
belugin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Так_забежал_простоНо точки "мёртвые", пользователи никогда по этим веткам кода не ходят. Работа кипит, но все недовольны. Т.е. при оценке полезности точки нужно суммировать с неким весом. Где взять вес?

Мы де программистов оцениваем, а не все вместе? Если на запорожце Шумахер доехал до питера, а я на мерсе врезался в столб - это же не значит, что мерс хуже запорожца?
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34880137
beluginМы де программистов оцениваем, а не все вместе? Если на запорожце Шумахер доехал до питера, а я на мерсе врезался в столб - это же не значит, что мерс хуже запорожца? Думаю, что:
1.В данном случае лучше оказалась СИСТЕМА "шумахер+запор", чем "вы+мерс". И сравнивать при таком подходе ТОЛЬКО машины абсолютно некорректно. Да и в какой момент сравнивать: ДО того, как мерс разворотили о столб, или ПОСЛЕ?! Тогда я пожалуй выберу запор - нафига мне куча металлолома вокруг столба на питерской трассе?
2.Полный дурак был тот манагер, который для оценки ТОЛЬКО машин решил устроить поездку до питера, да еще при этом и посадил на них настолько разных водителей.
ИТОГО: пример ИМХО некорректен. Если какие-то "ветки кода" были НАВЯЗАНЫ пользователям данной группой разработчиков (или вообще написаны "по собственной инициативе"), хотя пользователям это и нафиг не нужно - это значит, что плоха именно ГРУППА РАЗРАБОТЧИКОВ, так как не умеет думать головой и адекватно оценивать реальные бизнес-потребности заказчика. А вот если разработчики сумели развести пользователей на оплату написания этих ненужных веток кода - ну что ж.... Чисто по-человечески некрасиво, конечно - но респект!
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34880794
belugin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
почитайте Дедлайн
2.Полный дурак был тот манагер, который для оценки ТОЛЬКО машин решил устроить поездку до питера, да еще при этом и посадил на них настолько разных водителей.


Он не может посадить специально для оценки. Они едут, чтоб доехать. Но по результатм поездки узнать, у какой машины лучше мотор.
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34880988
beluginОн не может посадить специально для оценки. Они едут, чтоб доехать. Но по результатм поездки узнать, у какой машины лучше мотор.А теперь спустимся с небес на землю, то есть к нашей специфике. Вы посадите человека на "чистом" T-SQL писать сетевое приложение? Соревнуясь с "шарпеем" и "1Сником"? "Просто чтобы написать"(с). А по результатам узнать, какой язык лучше...
Так же и запорожец навряд ли предназначен для дальних междугородных поездок. ИМХО. Поэтому в данном конкретном случае менеджер просто обязан был не выпускать запор из города (при отсутствии на это каких-то особых "политических" причин). А в случае приведенных вами автомобилей "моторы" сравнимы даже чисто визуально. А также по звучанию. Если лень полезть в техталон :) И это не касаясь того, что кроме двигателя грают роль ходовая, подвеска, общая масса, управляемость, тормозная система и много чего еще...
В общем я снова возвращаюсь к мысли, что ДАННЫЙ КОНКРЕТНЫЙ пример некорректен. Мы сравниваем теплое с мягким...
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34881837
AlexTheRaven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
just_nick<...>Смотрим самый первый пост - автор собирался в общем-то тайком посчитать и сравнить показатели своей и других групп.<...>
А... Ну, тогда надо выписать все доступные количественные показатели для своей группы и для других (в т.ч. кол-во отработанных человеко-часов, написанных строк, созданных моделей, нарисованных экранов, произведённых сборок, исправленных ошибок). Найти те, в которых группа более всего отличается от "средней", и самому написать наукообразный индикатор на их основании, сославшись на пяток невнятных томов на английском. Главное только самому в это состряпанное не поверить :) .

just_nickВ то время как финансовые показатели для разных групп хоть как-то найти реально (кто-то проболтался, где-то подсмотрел, что-то просто не скрывалось и т.п.)
Человеку, являющемуся ПМом, такие данные относительно других проектов точно недоступны. Да и от своего - не все и не всегда. А отчёт, опирающийся на информацию, полученную в обход корпоративной этики, политики безопасности и иногда - закона, чревато увольнением.
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34882199
just_nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlexTheRavenА... Ну, тогда надо выписать все доступные количественные показатели для своей группы и для других (в т.ч. кол-во отработанных человеко-часов, написанных строк, созданных моделей, нарисованных экранов, произведённых сборок, исправленных ошибок). Найти те, в которых группа более всего отличается от "средней", и самому написать наукообразный индикатор на их основании, сославшись на пяток невнятных томов на английском. Главное только самому в это состряпанное не поверить :) .
Человеку, являющемуся ПМом, такие данные относительно других проектов точно недоступны. Да и от своего - не все и не всегда. А отчёт, опирающийся на информацию, полученную в обход корпоративной этики, политики безопасности и иногда - закона, чревато увольнением.В общем-то согласен... Но ИМХО судя по уровню вопроса автор навряд ли сможет изобрести велосипед из "отработанных человеко-часов, написанных строк, созданных моделей, нарисованных экранов, произведённых сборок, исправленных ошибок" и т.п. Тем более для проектов других групп! В то время как деньги хотя бы примерно узнать представляется мне более реальным. К тому же необязательно говорить директору "ФЗП соседней группы равен хх рублей уу копеек". Можно сказать "ну оценочно у них ФЗП должен быть порядка....".
В любом случае своими фактами Вы еще раз подтвердили мою начальную фразу: подобные вещи должны инициироваться или руководством "насильственно", или всеми участниками при общем согласии.
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34882815
AlexTheRaven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
just_nickВ любом случае своими фактами Вы еще раз подтвердили мою начальную фразу: подобные вещи должны инициироваться или руководством "насильственно", или всеми участниками при общем согласии.
Полностью с Вами согласен. Самодеятельность в этой области скорее всего будет воспринята начальником, как попытка вмешиваться в его вотчину - распределение денег, а это чревато. В лучшем случае ответом будет "не лезь не в своё дело".

Вряд ли подобное целесообразно вводить в сколько-нибудь крупной компании, выросшей из "семейной".
Допустим, за продажу продукта компания получила после уплаты налогов $2 млн.
$200 тыс. получил в качестве премии продавец из отдела маркетинга - возможно, за пару звонков и душевную пьянку с представителем заказчика, но - трудовой договор у него такой.
$400 тыс. взяли акционеры.
$400 тыс. начислили себе начальники - у них появилось желание сменить старые "Мерседесы" на новые "Лексусы".
$400 тыс. ушло на оплату рекламы, бухгалтерии, охраны, помещения, оборудования, расходников, обедов и всяческих других корпоративных прелестей.
$400 тыс. - ФЗП толпы талантливых студентов, которая пока не сделала продукта, но занимается новым перспективным направлением, которое в будущем может очень хорошо "выстрелить".
И только $200 тыс. - на следующие полгода ФЗП тех разработчиков, которые сделали продукт.
Внимание, вопрос: какова будет мотивация у разработчиков, если сказать им, что от прибыли они получили "жалкие" 10%, и при этом их продукт ещё и плохой, т.к. из-за багов продать его удалось всего за $2 млн., а не за $4 млн., потому что функциональность не вся, которую хотел покупатель, баги и GUI некрасивый.

Но вообще-то мне кажется, что чтобы доказать, что ты и твоя команда полезнее других (и достойна больших денег) - нужно не плести интриги, чтобы присвоить часть чужих денег, а просто хорошо работать. Если начальство не понимает - работать лучше или менять начальство. Можно всей командой. Идеализм, конечно...
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34884569
Так_забежал_просто
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AlexTheRavenНо вообще-то мне кажется, что чтобы доказать, что ты и твоя команда полезнее других (и достойна больших денег) - нужно не плести интриги, чтобы присвоить часть чужих денег, а просто хорошо работать. Если начальство не понимает - работать лучше или менять начальство. Можно всей командой. Идеализм, конечно...
+1 :)
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34884577
Так_забежал_просто
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
почитайте ДедлайнЯ это все к чему... Оспорить можно любую идею. Но тогда предложите свою.
Так давно уже предлагаю. AlexTheRaven хорошо про это сказал - см. предыдущий коммент.
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34884616
Так_забежал_просто
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
belugin Так_забежал_простоНо точки "мёртвые", пользователи никогда по этим веткам кода не ходят. Работа кипит, но все недовольны. Т.е. при оценке полезности точки нужно суммировать с неким весом. Где взять вес?
Мы де программистов оцениваем, а не все вместе? Если на запорожце Шумахер доехал до питера, а я на мерсе врезался в столб - это же не значит, что мерс хуже запорожца?
Насколько я понял, Вы молчаливо предполагаете, что все без исключения программисты - это животные, на которых ездят. Это не так. Программистов даже можно оценивать по этому критерию - способен ли он ездить самостоятельно (т.е. решать проблемы), или же им надо "рулить". Я бы очень не хотел работать с программистом, которым надо "рулить" - это как раз тот случай, когда быстрее написать самому.
Плюс человек говорил об оценке именно команды, а не одного программиста.
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34885106
belugin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Так_забежал_просто
Насколько я понял, Вы молчаливо предполагаете, что все без исключения программисты - это животные, на которых ездят. Это не так. Программистов даже можно оценивать по этому критерию - способен ли он ездить самостоятельно (т.е. решать проблемы), или же им надо "рулить".

Как я понял, проблемы перед программистом ставятся такие "заработай-ка нам побольше денег а как-твои проблемы".

Я как-то не втречал таких команд (только читал про стартапы где программеры, маркетоиды владельцы и руководители - это одно-два лица, да и то народ говорит, что обычно какой-нибудь Аллен кодирует, а какой-нибудь Гейтс продает). Обычно на каком-то уровне программистами все-таки рулят.
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34885308
just_nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
beluginКак я понял, проблемы перед программистом ставятся такие "заработай-ка нам побольше денег а как-твои проблемы".
Я как-то не втречал таких команд... Обычно на каком-то уровне программистами все-таки рулят.ну так я вам уже писал, что как раз из таких "денежных" соображений создание неиспользуемых веток в коде - это серьезнейший просчет архитектора->РМ-а->программиста (смотря кто в проекте есть). Еще раз повторюсь - если создание этих НЕИСПОЛЬЗУЕМЫХ веток было заказчиком отдельно оплачено - то респект продажникам. А если программисты написали эти ветки "просто так" и без доплаты - то позор архитектору системы.
Программистами конечно рулят. Но "рулить" ведь тоже можно по-разному! Мне кажется, что Так_забежал_просто имел виду следующее: садясь в такси, вы предпочтете назвать конечный адрес, а не "включаем левый поворот, смотрим в зеркало, если там дорога свободная, то левой ногой до конца выжимаем сцепление, правой рукой мягко включаем первую передачу, это ручку влево и вперед, потом плавно снимаем правую ногу с тормоза и слегка давим ею на газ, теперь плавно отпускаем сцепление, добавляя газу...." и т.п.
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34885515
belugin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
just_nickТак_забежал_просто имел виду следующее: садясь в такси, вы предпочтете назвать конечный адрес, а не "включаем левый поворот, смотрим в зеркало, если там дорога свободная, то левой ногой до конца выжимаем сцепление, правой рукой мягко включаем первую передачу, это ручку влево и вперед, потом плавно снимаем правую ногу с тормоза и слегка давим ею на газ, теперь плавно отпускаем сцепление, добавляя газу...." и т.п.

Согласен. Тогда переформулирую аналогию. Сравнивать по деньгам, все равно что сравнивать таксистов по принципу успели вы на самолет или не успели. В принципе можно, но надо проследить, чтобы прочие условия были одиаковы - количество пробок в данное время дня в городе, время которое было предоставлено и т.д.
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34885886
just_nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
beluginСогласен. Тогда переформулирую аналогию. Сравнивать по деньгам, все равно что сравнивать таксистов по принципу успели вы на самолет или не успели. В принципе можно, но надо проследить, чтобы прочие условия были одиаковы - количество пробок в данное время дня в городе, время которое было предоставлено и т.д.Ну как сказать....
Думаю, "количество пробок" должны были учесть продажники при заключении договора. Типа "шеф, я опаздываю - если довезешь в срок, получишь два счетчика". Иначе если они сложнейший проект продадут по цене разработки "Сапера" - ОНИ некомпетентны. Так что эти факторы все равно выльются в деньги при условии адекватности прочих звеньев в жизни проекта.
Насчет "предоставленного времени" - а вот это как раз будет характеристика команды. Т.е. какими ресурсами она сумела реализовать проект и заработать деньги. Конечно, все при условии, что сроки были реальные, а не "завтра мне нужна новая ОС, которая будет не хуже виндыХР как минимум"... Типа не ситуация "шеф - даю пять счетчиков, но через 10 минут мне надо в аэропорт, который отсюда в 50км". Т.е. когда есть время на "не сильно стрессовую" работу - и вопрос только в количестве и КПД ресурсов. Ведь если вы и ваш друг в одно время в одном месте сели на два разных такси, но он успел на самолет, а вы нет - вы будете считать это достаточным критерием для оценки таксистов? Думаю, да!
Вообще я не думаю, что выбранные Вами "автомобильные" аналоги - это хорошая идея. Что-то второй пример - и снова я нахожу его мало применимым ;).
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34885948
belugin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
just_nickДумаю, "количество пробок" должны были учесть продажники при заключении договора.

А если продажники сами являются пробкой?
...
Рейтинг: 0 / 0
Мерить объем работы и производительность
    #34885972
just_nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
belugin just_nickДумаю, "количество пробок" должны были учесть продажники при заключении договора. А если продажники сами являются пробкой?Как говорил один армейский офицер-преподаватель: "а морскую баллистику изучают на флоте - поэтому не парьте мне мозги!!!"(с)
То есть если в компании автора все НАСТОЛЬКО глючно - то я вообще удивляюсь, как он в этом бардаке вообще додумался что-то захотеть считать. Давайте вернемся к Вашему же тезису: "мы оцениваем конкретно проектную группу программистов". Поэтому давайте считать, что все-таки проект был адекватно оценен, нормально продан и т.п.? Иначе автору стОит подойти к директору с вопросом "почему моей группе дают задания, трудоемкость которых абсолютно неадекватна цене? А на что мы тогда все живем?".
...
Рейтинг: 0 / 0
41 сообщений из 41, показаны все 2 страниц
Форумы / Управление процессом разработки ИС [игнор отключен] [закрыт для гостей] / Мерить объем работы и производительность
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]