Исследовательские работы, скажем так, наиболее сложно прогнозируемы. На основе опыта, чутья можно выделить определенный ресурс.
ничего, кроме ответа «нет, в этом направлении мы идти не будем»
Это не верно. Нужно сделать статью для внутреннего использования. Через год-два вы вновь вернетесь к этой проблеме и уже никто не будет помнить почему не стоит идти в этом направлении. По результатам у вас должен быть детальный отчет что именно вы проверили и почему не подошло.
Потраченное время никому не нужно, всем (почти всем) нужен результат.
Именно!
А платят за время.
Это ваше мнение, реальной статистики у вас, наверняка, нет. Вот, есть люди, которые искренне верят, что все пишут сайты на PHP. И говорят что по их статистике это так. Но просто они вращаются в таких кругах, вот и личная статистика их такова.
В любом случае если платят за время, то все равно кто-то периодически оценивает результат. Иначе люди будут ничего не делать, умело обосновывая почему «неделю провозился с одной ерундой, которая не выгорела».
Я пока не встречал компаний, платящих по-коммитно, но интересно узнать.
По итерациям, когда внесен новый отлаженный функционал. Сначала смотрим адекватность и качество кода. Потом метрики кода. Это намного лучше часов.
в то время как я говорю о работе, которая будет сделана, о плане.
Планирование и разработка — вещи разные. Можно быть плохим планировщиком и при этом быть хорошим разработчиком. Более того — здесь конфликт интересов — разработчику выгодно написать как можно больший срок для каждой из задач. Причин почему он не станет этого делать — практически нет.
И если вы не отвечаете за план, совсем неуместно учить планировать тех, кто за него отвечает.
С разработчика нужно снять как можно больше стрессовых факторов, в т.ч. ответственность за планы и прочие бизнес-дела. Просто сделал — и ответственен за результат. Что вы там напланировали — меня не касается.
Посудите сами — вы хотите всю ответственность свесить на разработчика. Но здесь кроется и великая лажа — разработчик не дурак и будет в планах для каждой из задач писать как можно больше часов. Что ему помешает?
И если другой разработчик напишет меньше часов, если дать оценить двоим — то не факт что он прав, может просто недооценил. Кто будет решать?
На практике будет очень просто — выше описано как это работает. Для задачи на 5 мин. пишем 2 часа, времени для точной оценки нет. А там как повезет. Все это фигня, как ни крути.
Если вы свесите ответственность на других — то эти другие за вас «и есть будут».
Потому, что это должен быть очень крутой специалист во всем.
Есть люди, которым сейчас около 40 и которые около 20 лет занимались только разработкой. После 40-ка как раз самое время занять лидирующие позиции и кода писать все меньше, оставляя себе только лакомые куски.
Если разработчик будет длительное время только проверять, и ничего не писать, он перестанет быть крутым разработчиком.
Читать чужой код да еще и делать ревью, указывать направление — это даже сложнее чем писать самому. Да, этот чел. в последнее время пишет мало — оставляет себе только наиболее сложное.
это делает только 1 человек, и его мнение влияет на оплату…
А это, по сути, один из немногих рабочих вариантов. Причем этот один чел. должен быть лично заинтересован в успехе компании, т.е. является ее совладельцем.
Можно так же сказать и о FP, будет Вася оценивающий в меньше FP и все его будут ненавидеть )
Еще раз: FP не влияют на оплату.
У вас все упирается в мистического специалиста, могущего оценить результат работы. Но оценивать результат работы, это как оценивать график колебаний курса доллара. Все понятно, постфактум, но наперед все равно никто предсказать не может.
Почему мистического? Просто хорошего специалиста, который может понять нет ли раздувания кода, нет ли велосипедов, насколько код качественен (может провести ревью) и может запустить статические анализаторы для получения метрик. Да, не каждый это сможет сделать, а все-равно берутся оценивать непонятно что.
Я потратил 2 дня на баг, поменял 2 строчке в коде. Придет ваш спец. человек, посмотрит, скажет, ну все понятно тут. 2 строчки поменялось, 2 дня чем занимался?
Это значит что система плохо спроектирована, нет документации и пришлось разбираться, прежде чем смогли внести изменения. Результатом должны быть не только 2 строчки кода, но и дока.
Проверяющий сам работал более десятка лет и все это знает лучше вас. Более того, увидит что у вас затык и, при необходимости, подскажет.
Приходит задача, а для ее выполнения нужно настроить дополнительное окружение, или погрузится в предметную область.
Настроенное окружение — это результат. Хотя, обычно это делают не разработчики, но если пришлось — то, конечно, не бесплатно.
Аналогично погружение в предметную область — примерно ясен объем статей для изучения, есть статистические данные сколько времени это обычно занимает, зная ваш уровень. Но это нужно не каждый день, скорее в редких случаях.
Для этого нужен эксперт, а не просто чел. с улицы, который смотрит в код и видит фигу, ничего кроме как считать часы не умеет. Это называется экспертная оценка.
Если тупо считать строки кода — ничего хорошего не будет. Так, в проекте появится много мусора и левого кода.
И как учитывать время потраченное на раздумья вне рабочего места?
Не нужно вообще время считать — смотрите результат.
С часами чтобы заработать больше — работать больше не нужно. Твоя задача — просто оценивать задачу как можно в большее количество часов. Все! Потом просто неспеша делаешь и получаешь деньги за часы.
Ну да, возможен вариант, что в команде будет некий условный Вася, который будет находить переоцененные задачи и говорить, что я бы мог сделать это не за 12 часов а за 3. Но если он так будет делать — другие разработчики будут его ненавидеть и, при случае, вставлять ему палки в колеса.
Это уж как договоритесь. Если вы договорились, что 10 FP можно делать от 1 до 3 недель, то да.
Плановую оценку в FP дает одна сторона, реальную работу делает другая сторона. А уже кто допустил ошибку — планировщик или исполнитель — смотрим по результату работы.
Тоже самое для FP. В чем разница с часами? Если у вас FP оценивает менеджер, то кто виноват, что 10 FP делается три недели?
Разница в том, что деньги разработчик получает не за выполненные FP а результат работы, то есть код. Вы этой простой, но очень важной идеи, понять не можете.
У вас нет компетентных специалистов, которые могли бы оценить код и сказать сколько денег стоит эта работа. А если таких спецов нет — то какой бы ты дуристикой не занимался — все равно фигня получается.
Когда спец. есть — то смотрим на результат работы, на конкретный код. И имеем точный ответ — делалось 3 недели по причине усталости/депрессии разработчика или же там действительно много работы, просто была дана неверная оценка.
Хорошо, баг оценили в 1 FP, а делали неделю. Денег вы получите как за 1 FP или по количеству отработанных часов?
Разработчик денег получит не на основе FP и не на основе часов — а на основе проделанной работы. Смотрится коммит, анализируется что именно было сделано — и на основе этого оплата.
Так, у разработчика есть мотивация не просто просиживать часы а зарабатывать. Можно заработать больше, работая больше.
Вместо 1 FP привычно пишут 5. В чем разница? В том, что FP пишет менеджер?
В том, что две стороны с разными интересами. Это как если бы разработчики работали без тестеров. Когда вводим тестирование как отдельное звено — получаем разницу интересов — тестеру выгодно найти как можно больше багов, а разработчику как можно меньше допускать.
Менеджеру писать 5 вместо 1 не выгодно — т.к. если по факту окажется, что работы будет меньше — видны его огрехи планирования. Оценивается же реальная работа по итогу и все станет ясно.
Он о том, в чем преимущество FP перед часами.
Оплата не за FP а за результат работы. А FP нужны только для планирования — этим занимаются менеджеры.
Если ты знаешь, что можешь сделать больше и заработать больше — то у тебя повышается мотивация.
С часами чтобы заработать больше — работать больше не нужно. Твоя задача — просто оценивать задачу как можно в большее количество часов. Все! Потом просто неспеша делаешь и получаешь деньги за часы.
У вас есть FP? Сколько FP вам нужно сделать в этом месяце? Или такого плана у вас нет?
План — это для менеджеров. Это их проблемы. Оценка моей работы по результату — то есть качество кода и его объем.
Угадали они с планом или нет — это их проблемы — я за это не отвечаю.
Отмечу, что проблема «как узнать, что он не просто отсиживает время» точно так же существует и для FP.
FP используются только для планирования и получения ориентировочных данных. План может в 3 и более раз отличаться от фактического объема работы.
Для оценки реальной работы нужно смотреть результат — для разработчика это написанный им код. Без этого получается дуристика. Не можешь оченить результат, т.е. код — будет фейл.
В моей практике оценку задачи всегда делает программист. Так что косяк всегда его — он плохо оценил.
Исполнитель работы тогда может раздувать оценку, делать её с хорошим запасом, чтобы точно хватило.
Просто если похожие задачи он оценивает в 20 часов, а его коллега — в 5, то вряд ли ему стоит рассчитывать на повышение оплаты.
Нет, это так не работает. Если чел. бывалый — он не враг себе и просто будет вписываться существующий «болотный» темп работы.
Вот вам пример, как чел. описывал свой опыт работы по идиотской схеме «Укладываться в собственную оценку трудозат»:
Было такое, что хотя ошибка выглядела как обычный баг, решаемый костылем за пять минут (оцененная в два часа для менеджеров), а по факту оказалось, что предыдущие разработчики не написали реализацию редкой ситуации. А это неделя работы. Менеджер 'сжалился' над мной и заплатил мне как за 2,5 дня работы
Т.е. исполнитялям по такой схеме приходится подыгрывать идиотам-менеджерам, которые не способны оценить реальную работу и думают что они что-то там контролируют. Ну да, вместо 5 мин. — они привычно пишут 2 часа. И так делает вся команда — это все очень быстро понимается даже без слов. Норм. человек в такое болото влазить не будет или быстро уйдет, а кулики могут там сидеть.
Если организация более-менее адекватна, то будут проверять результат и исходя из него повышать/понижать стоимость часа
Но это не лучший метод, т.к. все скатывается в усредненное болото. Т.е. все смотрят друг на друга и стараются не слишком нарягаться, т.к. оплата все равно за час. Главное не опускаться до некого минимума, после которого уж очень явно все станет и могут понизить.
Как не крути — а без умения оценить результат — управлять IT-проектами будешь посредственно.
Именно примитивную работу можно измерить по другим критериям, потому что эти критерии легко придумать
Сложную работу так же можно измерять, только сделать это сложнее и точность ниже.
На стойках очень часто платят по-месячно.
Платят помесячно многим, но объем работ все-равно проверяют. Т.е. если чел. станет работать мало — на него начнут давить или даже уволят. Как узнать мало работает или нет, если вы измеряете работу в часах? Жопочасы он отприсутствовал — и все, достаточно?
Представим, нужно добавить на сайт платежную систему. Объем работ вы в чем измеряете, в каких единицах?
При планировании — в FP. Но опять таки — нужно учитывать и риски. При оплате за работу — экспертная оценка сложности кода, его применимости к задаче (а то вдруг код вобще не нужен был, сделан свой велосипед) и статический анализ кода. А как иначе?
Зачем? Какая разница вообще, сколько строк?
Нужно не просто считать строки, это уже дело второе. См. абзац выше.
А оценка нужна для поощрения работника, чтобы оплать справедливую оплату. Если будете платить тупо за часы — то бездельники, работающие медленно — будут в самом выгодном положении, ни так ли? И это приведет к тому, что все эту фишку просекут и лишь будут изображать видимость кипучей деятельности.
Есть фича — добавить платежную систему. Есть оценка из опыта, сколько нужно времени её сделать.
А если в плат. системе свои особенности/нюансы, которых не было в прошлых плат. системах? К примеру, есть разница — подключить Bitcoin или подключить Yandex.Money. Вы посчитаете что Bitcoin подключить займет столько же времени и круто обломаетесь. И что потом? Кто будет нести ответственность — разработчик или тот кто ошибся в сроках планирования?
К примеру, решили что добавите поддержку Bitcoin за 4 часа а по факту оказалось что нужно несколько дней. Как узнать — разработчик медленно работает или планировщик дал неверный прогноз?
А с функциональными точками я верно вас понял, что вы можете написать за следующую неделю 5 тыс строк и вы просто набираете задач, которые по вашей оценке в сумме потребуют написания именно такого количества кода?
FP помогают в планировании, но не дают уж очень высокой точности. Это тоже на основе опыта, только на основе множества проектов и команд.
Главное разделять план и факт. Т.е. по плану вы думали, что задача на 3 FP и займет день. По факту оказалось что заняла неделю. Способность оценивать результат даст вам точную причину — то ли разработчик медленно работал, то ли оценка была дана неверно.
У вас на самом деле так на работе устроено или это предположение, что так можно сделать, но у вас не так?
Сейчас так работаю, пришел к пониманию что это лучший вариант для всех сторон. Но действительно мало где способ применим, т.к. для оценки результата нужна компетенция.
Кстати, а что делать с задачами, в результате которых строк стало меньше, чем было до?
Это не так тупо считается. Вы думаете просто разницу в строках кода что было и что стало :)
Так же как у моляров главный не метр, а покрашенная стена.
Стена стене рознь. Стена в туалете на 5 квадратов и стоит, скажем, $10. А другая стена на 1000 квадратов и стоит $2000. Так количество стен определяет или метры?
сделанная задача
И тут — задача задаче рознь. Можно написать 1 задачу, которую будешь делать несколько лет. Считать количеством задач не выйдет.
А длительность задачи в часах
Проблема начинается тогда, когда плановые часы расходятся с реально затраченными. Как вы будете решать эту проблему?
огромное количество программистов получают зарплату за время
Т.е. вы думаете, что чел. сможет просто отсиживать жопо-часы и получать оплату? Если организация более-менее адекватна, то будут проверять результат и исходя из него повышать/понижать стоимость часа или вообще увольнят, если работы сделано слишком мало.
На самом деле для России 4-х дневная неделя неприменима.
Знал чела, который был готов делать что угодно, лишь не находиться дома. Записывался на разные курсы или обучения, лишь бы не «бороться с многоголовым змием — родственниками».
Не знаю, нужно проводить соц. опрос. Быть может не так много желающих сокращать, может быть уже привыкли.
Еще как уместен. Даже такую примитивную работу как малярство — никто не будет измерять часами — смысла нет. Иначе чем медленнее чел. работает — тем дороже стоит его труд.
Можно проверить (условно) качество кода.
И качество, и сложность, и объем работ. Все можно проверить — это и есть оценка работы. А за день написал или за месяц — зависит не только от уровня квалификации/опыта, но и от состояния чела. Т.е. даже один и тот же чел. в разные жизненные периоды будет иметь сильно разную скорость работы.
Но как вы можете это использовать в ответе на вопрос, планировать в следующем месяце релиз двух фич или трёх?
Вопрос планирования и вопрос оценки уже готовой работы — вещи разные. План это одно а реальная работа — другое.
Для планирования есть метод функциональных точек, к примеру. На основе количества FP по таблице смотрите сколько будет строк кода для конкретного языка. Зачем изобретать велосипед — все придумано до нас.
Но опять же — это лишь примерная оценка, реальная работа может отличаться довольно сильно и уметь ее оценить — это ключевой навык.
Если будете тупо в часах — то работники будут либо работать медленно, чтобы меньше напрягаться и получать столько же (умело обосновывая почему заняло дольше). Либо же будут выгорать, т.к. не успевают то что там кто-то напланировал или даже что сами напланировали. И не будет критерия понять где проблема — то ли плановые сроки имеют неверную оценку то ли исполнители медленно работают.
Вы знаете, сколько строк напишете на следующей неделе?
Есть такая статистика для моего языка. Считаем количество отлаженных строк кода, но это даже не за неделю а среднее на более длительном промежутке.
И знаете, сколько строк нужно для решения задачи Х?
Есть таблица, где для разных ЯП можно посмотреть кол-во строк кода на 1 FP. Но это, не точно, конечно. Планы и не могут быть слишком точными — просто закладывать риски. И все равно нет гарантии успеха. Уметь планировать, учитывать риски, чувствовать — это целое искусство.
По-моему это намного хуже для планирования, чем оценка в часах.
Если в часах — то вам нужно знать какой объем работы чел. выполняет за час. Т.е. вы все равно считаете не часы а объем работы конкретный, т.е. те же строки кода отлаженного.
Если просто тупо час — то ваши исполнители тем более будут вами цениться, чем медленне они работают. Вы можете возразить, мол, если слишком медленно работают — то я это увижу. Но как? Какой критерий? Все равно ведь получается не час а реальная работа во главе угла!!! Неужели сложно понять?
Маляры, к примеру, измеряют в метрах квадратных, к примеру. А уже скорость работы разнится как у разных спецов так и у одного и того же спеца в разном состоянии (усталость и пр.).
Моя работа по написанию кода наиболее точно измеряется статическим анализом (Maintainability Index, KLOC, проверка на дублирование и др.) в комплексе с проверкой на адекватность и соответствие требованиям.
Не обязательно — интеллектуальная работа не линейна во времени, т.е. ее тупо часами не измерить — многое зависит от настроения, состояния мозга (отдохнул или нет) и т.д.
Попытка измерять часами — от низкой компетенции, когда чел. не имеет тех. квалификации для оценки реальной работы а делать видимость некого контроля нужно. Ну и исполнителю в таком случае приходится подыгрывать.
Просто 10 минимум а скорее 15+ лет чел. привыкает жить в режиме, когда ему говорят что делать и контролируют его время. Этого нельзя просто так игнорить. Пропал контроль — чел. не знает как жить, тревога и пр. Сравните домашнюю кошку и дикую — домашняя уже не сможет жить самостоятельно, даже если вернуть ее в лоно природы.
Для примера, посмотрите «Побег из Шоушенка», там ярко продемонстрировано как ведут себя освобожденные, проведшие десятки лет в тюрьме. В какой-то мере, чего греха таить, мы все вышли из одной «тюрьмы» под названием школа. Эти годы просто так не вычеркнешь.
TFS многие не любят и осуждают (не попробовав) за недружелюбность, однако эта проблема там решена из коробки. Есть два уровня: требования с т.з. заказчика/пользователя и разбиение этих требований на конкретные задачи, которые понятны разработчику.
Запрет подогревает интерес и повышает значимость. Более того — будет нарастать внутренее противоречие, если супер-эго как бы запрещает а эго — хочет и тайно смотрит. Обойти блокировку ведь все равно смогут.
Интересно, понимают ли это запрещатели и если да, то какие цели преследуют?
Эта ассоциация возникает только в вашей голове. Пример с актером — актер может, играя роль, корчиться от боли. Но будет ли ему больно на самом деле? По вашей гипотезе — да, т.к. все что выглядит как испытывающее боль — испытывает боль. Но, очевидно, гипотеза ошибочна и по детски наивна.
Это не верно. Нужно сделать статью для внутреннего использования. Через год-два вы вновь вернетесь к этой проблеме и уже никто не будет помнить почему не стоит идти в этом направлении. По результатам у вас должен быть детальный отчет что именно вы проверили и почему не подошло.
Именно!
Это ваше мнение, реальной статистики у вас, наверняка, нет. Вот, есть люди, которые искренне верят, что все пишут сайты на PHP. И говорят что по их статистике это так. Но просто они вращаются в таких кругах, вот и личная статистика их такова.
В любом случае если платят за время, то все равно кто-то периодически оценивает результат. Иначе люди будут ничего не делать, умело обосновывая почему «неделю провозился с одной ерундой, которая не выгорела».
По итерациям, когда внесен новый отлаженный функционал. Сначала смотрим адекватность и качество кода. Потом метрики кода. Это намного лучше часов.
Планирование и разработка — вещи разные. Можно быть плохим планировщиком и при этом быть хорошим разработчиком. Более того — здесь конфликт интересов — разработчику выгодно написать как можно больший срок для каждой из задач. Причин почему он не станет этого делать — практически нет.
С разработчика нужно снять как можно больше стрессовых факторов, в т.ч. ответственность за планы и прочие бизнес-дела. Просто сделал — и ответственен за результат. Что вы там напланировали — меня не касается.
Посудите сами — вы хотите всю ответственность свесить на разработчика. Но здесь кроется и великая лажа — разработчик не дурак и будет в планах для каждой из задач писать как можно больше часов. Что ему помешает?
И если другой разработчик напишет меньше часов, если дать оценить двоим — то не факт что он прав, может просто недооценил. Кто будет решать?
На практике будет очень просто — выше описано как это работает. Для задачи на 5 мин. пишем 2 часа, времени для точной оценки нет. А там как повезет. Все это фигня, как ни крути.
Если вы свесите ответственность на других — то эти другие за вас «и есть будут».
Есть люди, которым сейчас около 40 и которые около 20 лет занимались только разработкой. После 40-ка как раз самое время занять лидирующие позиции и кода писать все меньше, оставляя себе только лакомые куски.
Читать чужой код да еще и делать ревью, указывать направление — это даже сложнее чем писать самому. Да, этот чел. в последнее время пишет мало — оставляет себе только наиболее сложное.
А это, по сути, один из немногих рабочих вариантов. Причем этот один чел. должен быть лично заинтересован в успехе компании, т.е. является ее совладельцем.
Еще раз: FP не влияют на оплату.
Почему мистического? Просто хорошего специалиста, который может понять нет ли раздувания кода, нет ли велосипедов, насколько код качественен (может провести ревью) и может запустить статические анализаторы для получения метрик. Да, не каждый это сможет сделать, а все-равно берутся оценивать непонятно что.
Это значит что система плохо спроектирована, нет документации и пришлось разбираться, прежде чем смогли внести изменения. Результатом должны быть не только 2 строчки кода, но и дока.
Проверяющий сам работал более десятка лет и все это знает лучше вас. Более того, увидит что у вас затык и, при необходимости, подскажет.
Настроенное окружение — это результат. Хотя, обычно это делают не разработчики, но если пришлось — то, конечно, не бесплатно.
Аналогично погружение в предметную область — примерно ясен объем статей для изучения, есть статистические данные сколько времени это обычно занимает, зная ваш уровень. Но это нужно не каждый день, скорее в редких случаях.
Для этого нужен эксперт, а не просто чел. с улицы, который смотрит в код и видит фигу, ничего кроме как считать часы не умеет. Это называется экспертная оценка.
Если тупо считать строки кода — ничего хорошего не будет. Так, в проекте появится много мусора и левого кода.
Не нужно вообще время считать — смотрите результат.
Ну да, возможен вариант, что в команде будет некий условный Вася, который будет находить переоцененные задачи и говорить, что я бы мог сделать это не за 12 часов а за 3. Но если он так будет делать — другие разработчики будут его ненавидеть и, при случае, вставлять ему палки в колеса.
Плановую оценку в FP дает одна сторона, реальную работу делает другая сторона. А уже кто допустил ошибку — планировщик или исполнитель — смотрим по результату работы.
Разница в том, что деньги разработчик получает не за выполненные FP а результат работы, то есть код. Вы этой простой, но очень важной идеи, понять не можете.
У вас нет компетентных специалистов, которые могли бы оценить код и сказать сколько денег стоит эта работа. А если таких спецов нет — то какой бы ты дуристикой не занимался — все равно фигня получается.
Когда спец. есть — то смотрим на результат работы, на конкретный код. И имеем точный ответ — делалось 3 недели по причине усталости/депрессии разработчика или же там действительно много работы, просто была дана неверная оценка.
Разработчик денег получит не на основе FP и не на основе часов — а на основе проделанной работы. Смотрится коммит, анализируется что именно было сделано — и на основе этого оплата.
Так, у разработчика есть мотивация не просто просиживать часы а зарабатывать. Можно заработать больше, работая больше.
В том, что две стороны с разными интересами. Это как если бы разработчики работали без тестеров. Когда вводим тестирование как отдельное звено — получаем разницу интересов — тестеру выгодно найти как можно больше багов, а разработчику как можно меньше допускать.
Менеджеру писать 5 вместо 1 не выгодно — т.к. если по факту окажется, что работы будет меньше — видны его огрехи планирования. Оценивается же реальная работа по итогу и все станет ясно.
Оплата не за FP а за результат работы. А FP нужны только для планирования — этим занимаются менеджеры.
Если ты знаешь, что можешь сделать больше и заработать больше — то у тебя повышается мотивация.
С часами чтобы заработать больше — работать больше не нужно. Твоя задача — просто оценивать задачу как можно в большее количество часов. Все! Потом просто неспеша делаешь и получаешь деньги за часы.
План — это для менеджеров. Это их проблемы. Оценка моей работы по результату — то есть качество кода и его объем.
Угадали они с планом или нет — это их проблемы — я за это не отвечаю.
FP используются только для планирования и получения ориентировочных данных. План может в 3 и более раз отличаться от фактического объема работы.
Для оценки реальной работы нужно смотреть результат — для разработчика это написанный им код. Без этого получается дуристика. Не можешь оченить результат, т.е. код — будет фейл.
Исполнитель работы тогда может раздувать оценку, делать её с хорошим запасом, чтобы точно хватило.
Нет, это так не работает. Если чел. бывалый — он не враг себе и просто будет вписываться существующий «болотный» темп работы.
Вот вам пример, как чел. описывал свой опыт работы по идиотской схеме «Укладываться в собственную оценку трудозат»:
Было такое, что хотя ошибка выглядела как обычный баг, решаемый костылем за пять минут (оцененная в два часа для менеджеров), а по факту оказалось, что предыдущие разработчики не написали реализацию редкой ситуации. А это неделя работы. Менеджер 'сжалился' над мной и заплатил мне как за 2,5 дня работы
Т.е. исполнитялям по такой схеме приходится подыгрывать идиотам-менеджерам, которые не способны оценить реальную работу и думают что они что-то там контролируют. Ну да, вместо 5 мин. — они привычно пишут 2 часа. И так делает вся команда — это все очень быстро понимается даже без слов. Норм. человек в такое болото влазить не будет или быстро уйдет, а кулики могут там сидеть.
Но это не лучший метод, т.к. все скатывается в усредненное болото. Т.е. все смотрят друг на друга и стараются не слишком нарягаться, т.к. оплата все равно за час. Главное не опускаться до некого минимума, после которого уж очень явно все станет и могут понизить.
Как не крути — а без умения оценить результат — управлять IT-проектами будешь посредственно.
Сложную работу так же можно измерять, только сделать это сложнее и точность ниже.
Платят помесячно многим, но объем работ все-равно проверяют. Т.е. если чел. станет работать мало — на него начнут давить или даже уволят. Как узнать мало работает или нет, если вы измеряете работу в часах? Жопочасы он отприсутствовал — и все, достаточно?
При планировании — в FP. Но опять таки — нужно учитывать и риски. При оплате за работу — экспертная оценка сложности кода, его применимости к задаче (а то вдруг код вобще не нужен был, сделан свой велосипед) и статический анализ кода. А как иначе?
Нужно не просто считать строки, это уже дело второе. См. абзац выше.
А оценка нужна для поощрения работника, чтобы оплать справедливую оплату. Если будете платить тупо за часы — то бездельники, работающие медленно — будут в самом выгодном положении, ни так ли? И это приведет к тому, что все эту фишку просекут и лишь будут изображать видимость кипучей деятельности.
А если в плат. системе свои особенности/нюансы, которых не было в прошлых плат. системах? К примеру, есть разница — подключить Bitcoin или подключить Yandex.Money. Вы посчитаете что Bitcoin подключить займет столько же времени и круто обломаетесь. И что потом? Кто будет нести ответственность — разработчик или тот кто ошибся в сроках планирования?
К примеру, решили что добавите поддержку Bitcoin за 4 часа а по факту оказалось что нужно несколько дней. Как узнать — разработчик медленно работает или планировщик дал неверный прогноз?
FP помогают в планировании, но не дают уж очень высокой точности. Это тоже на основе опыта, только на основе множества проектов и команд.
Главное разделять план и факт. Т.е. по плану вы думали, что задача на 3 FP и займет день. По факту оказалось что заняла неделю. Способность оценивать результат даст вам точную причину — то ли разработчик медленно работал, то ли оценка была дана неверно.
Сейчас так работаю, пришел к пониманию что это лучший вариант для всех сторон. Но действительно мало где способ применим, т.к. для оценки результата нужна компетенция.
Это не так тупо считается. Вы думаете просто разницу в строках кода что было и что стало :)
Стена стене рознь. Стена в туалете на 5 квадратов и стоит, скажем, $10. А другая стена на 1000 квадратов и стоит $2000. Так количество стен определяет или метры?
И тут — задача задаче рознь. Можно написать 1 задачу, которую будешь делать несколько лет. Считать количеством задач не выйдет.
Проблема начинается тогда, когда плановые часы расходятся с реально затраченными. Как вы будете решать эту проблему?
Т.е. вы думаете, что чел. сможет просто отсиживать жопо-часы и получать оплату? Если организация более-менее адекватна, то будут проверять результат и исходя из него повышать/понижать стоимость часа или вообще увольнят, если работы сделано слишком мало.
Качество и объем написанного за спринт кода.
Знал чела, который был готов делать что угодно, лишь не находиться дома. Записывался на разные курсы или обучения, лишь бы не «бороться с многоголовым змием — родственниками».
Не знаю, нужно проводить соц. опрос. Быть может не так много желающих сокращать, может быть уже привыкли.
Еще как уместен. Даже такую примитивную работу как малярство — никто не будет измерять часами — смысла нет. Иначе чем медленнее чел. работает — тем дороже стоит его труд.
И качество, и сложность, и объем работ. Все можно проверить — это и есть оценка работы. А за день написал или за месяц — зависит не только от уровня квалификации/опыта, но и от состояния чела. Т.е. даже один и тот же чел. в разные жизненные периоды будет иметь сильно разную скорость работы.
Вопрос планирования и вопрос оценки уже готовой работы — вещи разные. План это одно а реальная работа — другое.
Для планирования есть метод функциональных точек, к примеру. На основе количества FP по таблице смотрите сколько будет строк кода для конкретного языка. Зачем изобретать велосипед — все придумано до нас.
Но опять же — это лишь примерная оценка, реальная работа может отличаться довольно сильно и уметь ее оценить — это ключевой навык.
Если будете тупо в часах — то работники будут либо работать медленно, чтобы меньше напрягаться и получать столько же (умело обосновывая почему заняло дольше). Либо же будут выгорать, т.к. не успевают то что там кто-то напланировал или даже что сами напланировали. И не будет критерия понять где проблема — то ли плановые сроки имеют неверную оценку то ли исполнители медленно работают.
Есть такая статистика для моего языка. Считаем количество отлаженных строк кода, но это даже не за неделю а среднее на более длительном промежутке.
Есть таблица, где для разных ЯП можно посмотреть кол-во строк кода на 1 FP. Но это, не точно, конечно. Планы и не могут быть слишком точными — просто закладывать риски. И все равно нет гарантии успеха. Уметь планировать, учитывать риски, чувствовать — это целое искусство.
Если в часах — то вам нужно знать какой объем работы чел. выполняет за час. Т.е. вы все равно считаете не часы а объем работы конкретный, т.е. те же строки кода отлаженного.
Если просто тупо час — то ваши исполнители тем более будут вами цениться, чем медленне они работают. Вы можете возразить, мол, если слишком медленно работают — то я это увижу. Но как? Какой критерий? Все равно ведь получается не час а реальная работа во главе угла!!! Неужели сложно понять?
Маляры, к примеру, измеряют в метрах квадратных, к примеру. А уже скорость работы разнится как у разных спецов так и у одного и того же спеца в разном состоянии (усталость и пр.).
Моя работа по написанию кода наиболее точно измеряется статическим анализом (Maintainability Index, KLOC, проверка на дублирование и др.) в комплексе с проверкой на адекватность и соответствие требованиям.
Не исключено. Вот когда попробуют ввести на постоянной основе, а не в качестве эксперимента — тогда и посмотрим.
Попытка измерять часами — от низкой компетенции, когда чел. не имеет тех. квалификации для оценки реальной работы а делать видимость некого контроля нужно. Ну и исполнителю в таком случае приходится подыгрывать.
Для примера, посмотрите «Побег из Шоушенка», там ярко продемонстрировано как ведут себя освобожденные, проведшие десятки лет в тюрьме. В какой-то мере, чего греха таить, мы все вышли из одной «тюрьмы» под названием школа. Эти годы просто так не вычеркнешь.
Интересно, понимают ли это запрещатели и если да, то какие цели преследуют?
Интересно какие там ножки — такие же как и на первых моделях, которые быстро ломались? А так же как с доставкой…