Комментарии 6
Простите, а зачем? Любая мат.модель описывает реальность приблизительно. Есть зп разработчика и его компетенции. Смотрим рынок труда. Если зп разработчика на уровне зп в рынке — то всё ок, даже можно премию дать.
А по Вашей системе будет два варианта (сразу не угадаешь) — либо первый расчет будет выше рынка, тогда возникнет желание срезать административным путем.
Либо ниже, чем разработчик получал ранее
В обоих случаях у него появится стимул поменять работу…
«заказчик всегда чувствовал подвох, ему казалось, что злобный(а на самом деле добрейшей души человек) бородатый тимлид, давший свою оценку, только и видит, как вписать туда процентов 50 лишних часов, не утруждаясь уложиться в SL и получить мотивацию по KPI» — так в результате-то что получалось? ЗП за месяц была выше или ниже рынка для должности разраба и его компетенций?
А по Вашей системе будет два варианта (сразу не угадаешь) — либо первый расчет будет выше рынка, тогда возникнет желание срезать административным путем.
Либо ниже, чем разработчик получал ранее
В обоих случаях у него появится стимул поменять работу…
«заказчик всегда чувствовал подвох, ему казалось, что злобный(а на самом деле добрейшей души человек) бородатый тимлид, давший свою оценку, только и видит, как вписать туда процентов 50 лишних часов, не утруждаясь уложиться в SL и получить мотивацию по KPI» — так в результате-то что получалось? ЗП за месяц была выше или ниже рынка для должности разраба и его компетенций?
Собственно, вы ничего нового вообще не придумали. Оценка трудоемкости задачи до начала разработки всегда так и происходила — если вы не можете интуитивно оценить трудоемкость большой задачи, вы декомпозируете ее на мелкие, для которых уже можно достаточно точно сказать, что вот эта задача решается за 4 часа. И потом тупо складываете. Ну или умно складываете — нарисовав диаграмму Ганнта, например. Но суть все равно та же самая.
И все это работает… ровно до тех пор, пока:
а) задачи остаются типовыми, которые после декомпозиции можно оценить (и вообще можно декомпозировать на что-то, из чего наверняка можно собрать решение общей задачи),
б) до тех пор, пока ваши (обычно отфонарные) коэффициенты производительности для джунов, миддлов и сьньоров имеют хоть какое-то отношение к реальности.
Для нетиповых задач это бывает совсем не так — а именно, та задача, которая для синьора окажется непростой, и займет скажем в 2 раза больше времени, джуниор разработчик такую вообще не решит ни за какое разумное время. То есть, разница между ними будет не в три раза, как у вас, а скажем на два порядка. И еще нетиповые задачи вы не сможете декомпозировать (забудете что-то важное), и даже оценка результатов декомпозиции не будет точной, потому что будут задачи, которые дальше не декомпозируются, и которые вы никогда не решали, и опыта не имеете.
И все это работает… ровно до тех пор, пока:
а) задачи остаются типовыми, которые после декомпозиции можно оценить (и вообще можно декомпозировать на что-то, из чего наверняка можно собрать решение общей задачи),
б) до тех пор, пока ваши (обычно отфонарные) коэффициенты производительности для джунов, миддлов и сьньоров имеют хоть какое-то отношение к реальности.
Для нетиповых задач это бывает совсем не так — а именно, та задача, которая для синьора окажется непростой, и займет скажем в 2 раза больше времени, джуниор разработчик такую вообще не решит ни за какое разумное время. То есть, разница между ними будет не в три раза, как у вас, а скажем на два порядка. И еще нетиповые задачи вы не сможете декомпозировать (забудете что-то важное), и даже оценка результатов декомпозиции не будет точной, потому что будут задачи, которые дальше не декомпозируются, и которые вы никогда не решали, и опыта не имеете.
С одной стороны, кажется, Вы изобрели стори поинты. С другой стороны, приведенный пример задачи и декомпозиции в решение вот так с наскоку выглядит архитектурным ужасом. Надеюсь, это просто пример плохой. :)
Люди — не роботы. Завтра разработчик придет на работу взвинченным, потому что ему нахамили в трамвае, и его производительность упадет на полдня. Через неделю другой разработчик узнает, что его маму положили в больницу с неясным диагнозом, и его производительность просядет на месяц.
А у вас разница в ЗП между джуном и синьором в 3 раза? Допустим, условный джун получает на руки 40к, а синьор 120к?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как оцифровать разработчика или коротко о том, как сделать работу разработчиков более прозрачной для Компании