У кого как организован процесс оценки работ по разработке?

Question

[Дмитрий Горячев]

Добрый вечер, всем!
Задался вопросом, как организован процесс оценки работ по разработке в разных организациях.
У нас оценивает dev lead, а у вас кто, и как построен этот процесс?

Интересует оценка не в денежном эквиваленте, а как и кем у вас происходит расчет необходимого времени и трудозатрат на разработку того или иного функционала.

Comments

[Алексей Уколов]

Что для вас "оценка работ"? Предварительная оценка трудозатрат? Оценка качества реализации? Мотивоционные аплодисменты в конце спринта?

[Дмитрий Горячев]

Интересует оценка не в денежном эквиваленте, а как и кем у вас происходит расчет необходимого времени и трудозатрат на разработку того или иного функционала.

Answer 1

[Сергей Протько]

Зависит от того что оценивается. В контексте начальной оценки может делать как тимлид так и кто-то из членов команды. Делигирование и все такое.

Ну и сами задачи оценивают разработчики которые будут их делать.

Answer 2

[xmoonlight]

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

Есть 2 вида оценки работ:
1. Прогнозируемая
2. Фактическая (по времени и тому, что было сделано)

Абстрагируясь на аналогию (максимально упрощённый тех.процесс):
Представьте, что Вы строите кирпичный дом.
1. Перенос одного кирпича - стоит 5р (5сек)
2. Покрыть раствором поверхность - 3р (3сек)
3. Положить кирпич на поверхность, покрытую раствором - 1р (1сек)
4. Убрать лишний раствор - 2р (2сек)

Теперь, предположим, что часть рабочих носят по-одному кирпичу, а один - по 10 сразу.
Стоит ли тому, кто носит сразу по 10 кирпичей - платить 5*10?
Или же "украсть" у него кровно заработанные деньги, если он делает это быстрее?
Т.е. разговор идёт о сложности алгоритма (вложенность, рекурсии и т.д.)

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

1. Прогнозируя изначально и получив фактически выполненную работу - можно сравнить и на основе этой разницы скорректировать алгоритм прогноза.
2. Оплата всегда ведётся по прогнозируемым трудозатратам вместе с разработчиками.
3. Если что-то требует исследовательской работы - это делается в первую очередь и стоимость этой работы оговаривается заранее.

Comments

[kazmiruk]

"Оплата всегда ведётся по прогнозируемым трудозатратам вместе с разработчиками." А Вам не кажется, что такой подход приведет к тому, что рабочий, который может нести 10 кирпичей за раз будет искусственно занижать свои способности, так как если он вдруг споткнется и уронит кирпичи, то Вы ему не оплатите ничего, хотя споткнувшись он нашел давно потерянные другими рабочими грабли?
Прогнозы хорошо, но если Вы мне покажете человека, который может с точностью до часа сказать сколько у него займет решение задачи, то я очень удивлюсь и захочу его себе в команду :) А если кто-то будет всегда вынужден неспрогнозированные затраты оплачивать самостоятельно, то его мотивация быстро сойдет на нет и человек попросту уволится.

[xmoonlight]

kazmiruk:
1. Про рабочего - это его личные условия, на которые он согласился с собой.
2. "если Вы мне покажете человека, который может с точностью до часа сказать сколько у него займет решение задачи, то я очень удивлюсь и захочу его себе в команду"
А у вас хватит мотивации и харизмы?! )))

[Сергей]

xmoonlight: возможно вы имеете ввиду небольшие шаблонные проекты-тут действительно можно без проблем показать заказчику конкретную сумму и срок выполнения,но!!! Если вы начинаете работать с типичным шаблоном,где до вас уже костыли накрутили или с большим проектом или с большим проектом,где до вас уже костыли накрутили-ваш подход будет неэффективен

[xmoonlight]

Сергей: я смогу сделать сравнение что было, и что добавили и по-кирпичикам - посчитать трудозатраты. Т.е. согласен на 50%: здесь только по ФАКТИЧЕСКОЙ работе уже.

[Сергей]

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

[xmoonlight]

Сергей: Да ни в кой мере! Спасибо!
Я и так пытаюсь сокращать затраты заказчика на аналитику за счет наработанных шаблонов оценки примитивных операций. Заказчики - разные...

[kazmiruk]

xmoonlight: честно не совсем понял Ваш "вброс" ) "его личные условия, на которые он согласился с собой" - сегодня согласился, завтра понял, что сглупил и нашел другую работу. Надо создавать комфортные условия для работника, чтобы у него сохранялась мотивация работать с тобой.
"А у вас хватит мотивации и харизмы?! )))" лучше спросить у моей текущей команды, но пока никто не жаловался ;)

[xmoonlight]

kazmiruk: да. немного не поняли)
Работник стал таскать 10 кирпичей, зная что если он не справится: уронит, не поднимет и т.д. - он принял для себя такие условия и с ними согласился (т.е. это его личная организация труда). Оплату он получит только за перенесённые кирпичи, которые он использовал, чтобы строить дом (т.е. за выполненный этап работы).
Важен - результат, на который договорились заранее. Если он видит, что не успевает - он может нанять других рабочих и/или грузовик, которые помогут ему нагнать упущенное время и достигнуть требуемый результат работы.
Этот случай - называется "кусок не по зубам". Т.е. вроде как я сейчас за несколько минут всё перетаскаю и буду отдыхать, пока другие будут работать и таскать по-одному и денег "срублю".
Однако, не всегда это удаётся, т.к. тратятся силы гораздо быстрее.
Так работают "профессионалы" на фрилансе почти в 100% случаев.

[kazmiruk]

xmoonlight: а почему "профессионалы" в кавычках ) Фриланс это предпринимательская деятельность в миниатюре со всеми вытекающими. А вот если работник у Вас в штате, то перекладывать на него свои риски неправильно и неэффективно.
"Работник стал таскать 10 кирпичей, зная что если он не справится" - вот именно про это я и говорю. Работник в среднем может таскать даже 12! кирпичей, но он знает, что если что-то случится (форс-мажор пусть даже и не по его вине) и он вместо 12 принесет меньше, то ему меньше заплатят. Получается, что работник заинтересован сказать, что может носить 8 кирпичей (коллега ведь таскает 8 и ничего) и получать за это не напрягаясь свои деньги. А ведь при правильной организации работы Вы могли получить сотрудника в 1.5 раза более эффективного, чем его коллеги.

[xmoonlight]

kazmiruk: а я так и делаю)))
https://sitecoder.blogspot.ru/2015/12/cost-calcula...

[kazmiruk]

xmoonlight: флаг Вам в руки ) Но как уже говорили выше - или Вы делаете шаблонные проекты, где это применимо, или пока еще не набили свои шишки (судя по дате публикации прошло всего чуть более полгода)

[xmoonlight]

kazmiruk: У меня нет шаблонных проектов. У меня есть технология оценки трудозатрат, которая работает более 3-х лет без сбоев на разных проектах.
И, да: флаг я держу крепко! )

[mydarck]

Увы все переросло в банальные понты.

Answer 3

[Сергей]

Вопрос в лоб- по каким методологиям разработки проектов вы работаете? Если все сводится к показу dev'у задачи и его оценки, после 20 минутного ковыряния в inspector-это одно,если вы работаете по допустим agile-это другое. Можно создать стек задач со временем исполнения (приблизительным конечно) и отслеживать эффективность выполнения задач допустим по той же диаграмме Ганта

Comments

[Дмитрий Горячев]

Это точно не agaile, что-то похожее на RUP

[Сергей]

Дмитрий,я просто оставлю это здесь
https://ru.atlassian.com/software/jira/agile

Answer 4

[Елизавета Борисова]

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