Поспорю, что показали. Вы накидали множество фраз, которые больше говорят в пользу статьи, чем опровергают ее. Кажется, вы просто не поняли суть статьи и спорите с самим собой. Впрочем, цели кого-то убедить у меня нет. Я приглашаю вас просто посмотреть кругом, если будет возможность, то пообщаться с кем-то заграницей. На мой взгляд сложно не увидеть совпадений.
Но вы ведь не будете спорить с тем, что получаемая вами зп не больше, чем себестоимость товара, в производстве которого вы участвуете. И если да, то какая сложность может это нивелировать?
А можете, пожалуйста, сначала привести аргументацию? Если это дичь, тем более лютая, то вам не составит труда логически или эвристикой какой-нибудь ее опровергнуть.
И раз уж вы не согласны со статьей, то, очевидно, знаете правильный ответ на вопрос, откуда берётся прибыль, если наёмные работники не могут купить нужный для прибыли объём товаров, так как их суммарный размер ЗП меньше суммарной себестоимости товаров. Очень интересно узнать.
Оценка в SP это не оценка времени, это оценка объёма задачи. Пример с глубиной ямы, которую надо выкопать, является хорошей аналогией. Нужно понять, какую глубину нужно прорыть, чтобы запланировать, кто будет копать и сколько у них на это уйдёт времени. Землекопа спрашивать за сколько будет вырыта яма не очень правильно, потому что у разных земплекопов на это уйдёт разное время, а глубина - это объективная неизменная величина.
Менеджер берёт оценки в SP не для того, чтобы напихать задач и люди больше работали. Для этого как раз оценки не нужны. Можно по беспределу пихать задач, пока команда берёт и прогибается, грозя увольнением.
А оценки в SP как раз наоборот нужны, чтобы команду оградить от лишнего стресса. Они нужны, чтобы 1. сказать примерные сроки заказчику, не привлекая в этот процесс команду и не нервируя её лишний раз дедлайнами. 2. правильно управлять зависимостями задач друг от друга, понимая где задача жирная, а где нет.
Есть проекты, где неопределённость - это данность, например, в стартапах или в принципе при запуске нового продукта. Но там и не используются метрики и оценки. Там просто делаем, пока есть инвестиции и силы.
Но если речь идёт не про стартап, то почему должен быть высокий уровень неопределённости? Ведь можно значительно забороть её системным и бизнес анализом или через предварительный RnD, когда разработчик заранее пробует задачу на зуб, но без углубления в детали.
Есть принципиальные отличия от часов. Главные причины, зачем оценивается в SP:
SP даёт команда, а сроки лучше всего руководителю определять самому. Почему так: во-первых, сроки зависят не только от объёма, но и от много чего ещё, на что влияет именно руководитель, а, во-вторых, потому что сроки - это лишнее психологическое давление на команду, которое совсем не помогает ей работать.
Оценка в SP более устойчива к когнитивным искажениям, чем оценка в часах. Если человек определяет сроки в часах, то он может стесняться дать верную оценку, занижая её, либо может перезакладываться намеренно, чтобы поменьше работать.
Оценка в SP не зависит от исполнителя. Имея такую оценку можно на планировании выбрать исполнителя без переоценки задачи, вычислив сроки.
Пример с ямой в статье показателен. При оценке работ мы ведь не оцениваем глубину ямы в часах. Нужна глубина в метрах, а уже на её основе прораб думает кто будет копать и чем.
Оке, давай тогда подумаем, что нужно ,чтобы сделать pull вместо push? Если ты гугл, то можешь себе позволить нанимать только крем-де-ля-крем и они будут драйвить, получая минимум 300k $ в год. Но мы не гугл, а значит нанимаем средних инженеров с медианной зп.
Они в целом-то классные инженеры, умеют писать хороший код. Но они работают за зп, у них есть семьи, личные дела и желание прото писать код, чтобы их не особо трогали. Какие ваши предложения по превращению этих в общем-то отличных сотрудников в тех, кто добровольно взваливает на себя ещё и организаторские дела? Оставим за скобками, что они могут не иметь нужных навыков для этого и будем рассматривать только вопрос желания.
Ну, камон… сейчас товарищу К. Марксу было обидно…
Обожаю Стругацких, поэтому осуждаю, что используете их не к месту.
А как это опровергает статью?
Поспорю, что показали. Вы накидали множество фраз, которые больше говорят в пользу статьи, чем опровергают ее. Кажется, вы просто не поняли суть статьи и спорите с самим собой. Впрочем, цели кого-то убедить у меня нет. Я приглашаю вас просто посмотреть кругом, если будет возможность, то пообщаться с кем-то заграницей. На мой взгляд сложно не увидеть совпадений.
А что это меняет? Можете пожалуйста объяснить.
Фамилии это все что вы усвоили из статьи? Если так, то это в первую очередь вас характеризует. Давайте лучше по сути статьи пообщаемся.
А как бы назвал статью эксперт по австрийской экономической школе?
Вовсе нет, просто хочу продемонстрировать, что вы бросаетесь словами, которые не понимаете.
А что такое «успешность» в вашем вопросе?
Но вы ведь не будете спорить с тем, что получаемая вами зп не больше, чем себестоимость товара, в производстве которого вы участвуете. И если да, то какая сложность может это нивелировать?
А можете, пожалуйста, сначала привести аргументацию? Если это дичь, тем более лютая, то вам не составит труда логически или эвристикой какой-нибудь ее опровергнуть.
кажется, вы невнимательно читали статью)
И раз уж вы не согласны со статьей, то, очевидно, знаете правильный ответ на вопрос, откуда берётся прибыль, если наёмные работники не могут купить нужный для прибыли объём товаров, так как их суммарный размер ЗП меньше суммарной себестоимости товаров. Очень интересно узнать.
А можете, пожалуйста, объяснить, как то, что вы перечислили опровергает проблематику, описанную в статье?
Да, вопрос только в реализации, устойчивой во времени.
Заказчик (солидный дядя в пиджаке) не даёт задачу вырыть яму 10 метров. Он говорит, что надо построить красивое здание.
Оценка в SP это не оценка времени, это оценка объёма задачи.
Пример с глубиной ямы, которую надо выкопать, является хорошей аналогией.
Нужно понять, какую глубину нужно прорыть, чтобы запланировать, кто будет копать и сколько у них на это уйдёт времени. Землекопа спрашивать за сколько будет вырыта яма не очень правильно, потому что у разных земплекопов на это уйдёт разное время, а глубина - это объективная неизменная величина.
Менеджер берёт оценки в SP не для того, чтобы напихать задач и люди больше работали. Для этого как раз оценки не нужны. Можно по беспределу пихать задач, пока команда берёт и прогибается, грозя увольнением.
А оценки в SP как раз наоборот нужны, чтобы команду оградить от лишнего стресса. Они нужны, чтобы
1. сказать примерные сроки заказчику, не привлекая в этот процесс команду и не нервируя её лишний раз дедлайнами.
2. правильно управлять зависимостями задач друг от друга, понимая где задача жирная, а где нет.
Есть проекты, где неопределённость - это данность, например, в стартапах или в принципе при запуске нового продукта. Но там и не используются метрики и оценки. Там просто делаем, пока есть инвестиции и силы.
Но если речь идёт не про стартап, то почему должен быть высокий уровень неопределённости? Ведь можно значительно забороть её системным и бизнес анализом или через предварительный RnD, когда разработчик заранее пробует задачу на зуб, но без углубления в детали.
Есть принципиальные отличия от часов. Главные причины, зачем оценивается в SP:
SP даёт команда, а сроки лучше всего руководителю определять самому.
Почему так: во-первых, сроки зависят не только от объёма, но и от много чего ещё, на что влияет именно руководитель, а, во-вторых, потому что сроки - это лишнее психологическое давление на команду, которое совсем не помогает ей работать.
Оценка в SP более устойчива к когнитивным искажениям, чем оценка в часах.
Если человек определяет сроки в часах, то он может стесняться дать верную оценку, занижая её, либо может перезакладываться намеренно, чтобы поменьше работать.
Оценка в SP не зависит от исполнителя.
Имея такую оценку можно на планировании выбрать исполнителя без переоценки задачи, вычислив сроки.
Пример с ямой в статье показателен. При оценке работ мы ведь не оцениваем глубину ямы в часах. Нужна глубина в метрах, а уже на её основе прораб думает кто будет копать и чем.
Оке, давай тогда подумаем, что нужно ,чтобы сделать pull вместо push?
Если ты гугл, то можешь себе позволить нанимать только крем-де-ля-крем и они будут драйвить, получая минимум 300k $ в год. Но мы не гугл, а значит нанимаем средних инженеров с медианной зп.
Они в целом-то классные инженеры, умеют писать хороший код. Но они работают за зп, у них есть семьи, личные дела и желание прото писать код, чтобы их не особо трогали.
Какие ваши предложения по превращению этих в общем-то отличных сотрудников в тех, кто добровольно взваливает на себя ещё и организаторские дела? Оставим за скобками, что они могут не иметь нужных навыков для этого и будем рассматривать только вопрос желания.