Как стать автором
Обновить

Комментарии 74

>6) Всякое ТЗ, каким бы сложным оно ни было, может быть описано формулой S = k1*t1 + k2*t2 +… kn*tn, где t1, t2 и т. д. — временные промежутки, а k1, k2 и т. д. – коэффициенты сложности за данный временной промежуток.

Изначально это проблематично сделать, а после уже не нужно, когда все сроки просраны и деньги проедены.
это верно. хотя по-моему имелось ввиду, что уже после того, как сроки просраны, как раз и надо рассказывать про то, какая непростая была задача.
НЛО прилетело и опубликовало эту надпись здесь
если разбирать данный пример, то тут написано: «Наконец, спустя пять часов, «плёвое дело» сделано»

рассматривается ситуация, когда дело уже сделано и подошли к вопросу оплаты. Т.е. не «КОГДА!?!?», а «СКОЛЬКО!?!?»
А тут очень просто: сказал что сделаешь за 20 минут — получи за это деньги.
Поэтому важно сообщать о всех возникающих затыках сразу же. Это позволит изменить план, сдвинув сроки. Т.е важно, чтобы менеджер был всегда в курсе происходящего.
Да, такой план лучше всего в процессе стараться делать.
План на то и план что должен быть составлен заранее.
Это в идеале. В реальности же всё равно не всё предусмотришь и план корректируется.
Ето называется управление рисками. И это надо закладывать в план. Да, в итоге на мелких задачах Вася из зажопинска будет делать быстрее. Но как только будет что-то сложное — Вася сядет в лужу как прогаммист из поста.
Программисты из Москвы, в отличие от зажопинских, знают все на свете возможные движки, включая самописные?
1. Причем тут таки москва
2. Любой нормальный программист вне зависимости от местоположения вначале разберется в том что ему нужно делать и нормально оценит.
к сожалению, часто работа программиста и админа — это как раз тот случай, когда "$1 за удар кувалдой, $999 за то что знаю куда ударить". Чтобы разобраться в проблеме-задаче, нужно 90% времени. Написание кода — это мелочь — посчитайте сколько там знаков, и разделите на скорость набора средней машинистки.
Насчет 90% на разобратсья я все же бы поспорил. Обычно — не более 30% времени.
// 1. Причем тут таки москва

К слову пришлось в ответ на высокомерное «Вася из зажопинска». При том же, при чем и зажопинск.
Ага — подшипник напрямую не откручивается. Значит, понадобиться +10 минут на то чтобы найти хитрую отвертку. Пишем менеджеру («проект будет сдан на 10 мин позже»). Через 10 мин нашли отвертку, 5 мин потыкались ей — никак. Надо отвинтить что-то. Пишем менеджеру («проект будет сдан еще на 10 мин позже»). Потом поняли что еще надо 30 мин на что-то потратить и может быть потом уже все будет готово. Но потом еще и еще и еще.

И менеджер раз или два в час будет «в курсе», что все «вот вот сейчас уже готово будет». Зачем ему писать тогда письма про это? Давайте ему на стену повешаем плакат «будет готово через час», и вместо репортов от программистов — он будет на него смотреть — там та же информация примерно. И через два дня она там же будет и будет по прежнему верна :-)

Если исполнитель видит, что система какая-то незнакомая, у него в голове должно щёлкнуть, что предсказать сроки будет проблематично. И говорить «сейчас всё будет готово» в таком случае совершенно не надо.
В статье довольно простой пример взаимодействия двух разных специальностей в компании. По моему, на самом деле все немного сложней: взаимодействие зачастую идет на уровне: менеджер-аналитик-разработчик-тестировщик-заказчик. Причем почти всех и со всеми. Уже закладываем время в формулу на согласование этих групп. Далее идут риски, внепроектная активность и даже время на обеды. Итого к заложенному времени на разработку проекта постепенно добавляется от 30 до 120%. Вот в рассмотренном примере времени ушло вообще в разы больше.
может стоило для начала посмотреть, что надо сделать, а потом уже оценивать.
а то скажут 1 час, а потом сами охуевают и людей подводят.
Согласен. В этом случае программист сам виноват. Сначала нужно было посмотреть систему.
Мне интересно, мнение какой профессии вы представляете?

Я как программист не могу оценить что-там-вылезет-еще даже в средине работы над проектом. Это что-то еще может быть пробелом в знаниях, ошибочным мнением, новыми требованиями… мало ли чем.
А ты позвони заказчику и скажи — прошу пардона, но тут такое дело… и объясни, что за фигня.

Это еще удивительно терпеливый менеджер попался, сам не спросил. =) Видать, не настолько все горело…
Позвонить в любом случае лучше, чем не позвонить, ежели есть проблемы :)
Не согласен. Когда я беру проект, я сразу пробегаюсь по нему и исходя из своего опыта получаю представление о структуре данной системы. Многие системы имеют ряд схожих конструкций. А проще говоря, идентичны. Поэтому не составляет особого труда определить степень емкости работы.
Жаль, что Вы не можете определить, что там еще вылезет.
В качестве примера недавно пришлось разбираться в движке локализации из-за того, что он оказывается кодировал строки в свой формат, как я понял, для ускорения производительности. Из-за этого в нем не получалось добавить юникодом новые тексты.
Гм, я вообще за правило взял никогда не брать на задачу меньше суток. Ну т.е. я могу взять одну задачу на сутки, могу и десять, но в любом случае — до завтра, увидимся. Неужели есть такая срочность, что подождать один день не могут??

Т.е. для меня работает примерно такая формула:
ВРЕМЯ = (константа) + (число задач) * (сложность задачи)
В простых случаях это возможно, но опять же требует дополнительного времени.
Часто легче сразу же и сделать, когда уже ясно как делать.
А когда ясно, но не до конца, в этой концовке обычно и заключается хитрость.
> Всякая работа должна оплачиваться по формуле S = k*t, где S – денежный эквивалент
У нас такая схема будет плохо применима. Программист из Луганска будет каждый раз говорить, что задание сложное, требуя много денег. Это как таксисты на вокзале, которые иногородних на соседнюю улицу везут через пол города по счетчику.

Можно решить при наличии какой-нить проги, которая установлена у программера и собирает скриншоты (и многое другое) раз в 3 минуты, которые сразу может просмотреть менеджер. Но и эта система далека от идеала.
Тут обсуждается сложность задачи, а не честность сотрудника.
Мы предполагаем, что программист честно сидит и разбирается с задачей.
А большинству менеджеров просто не под силу оценить сложность работы по скриншотам.
Большинству менеджеров, ей Богу, не до того, чтобы каждые три минуты смотреть на скриншоты. Дел у них хватает и других. А так да, мы исходим из того, что сотрудник честен, разумеется. Как иначе?
Если менеджер будет оценивать сложность работы по скриншотам, его нужно увольнять. Причем в этот же день. Это не его задача и ему не за это платят деньги. Он должен так организовать работы по оценке сложности, которые будут выполнять специалисты, чтобы получить приемлемый результат.
Вы не поняли. Менеджер не оценивает сложность работы по скриншотам — он оценивает, что программист действительно работает над проблемой а не на хабре сидит.
Как можно понять с моих слов, я обсуждал не справедливость зарплаты, а применимость этого метода. Против такой формулы я слова не сказал. Она мне очень даже нравится.

> Тут обсуждается сложность задачи, а не честность сотрудника.
Вы же не против, если я тут поговорю о системе оценивания оплаты труда?
Работу мозга можно заскриншотить? =)
Конечно. Можно заставить программистов работать подключенными к аппарату МРТ головного мозга.
А вот это было бы круто. Я б на свой посмотрел )
Вообще-то менеджер сам должен разбираться в вопросе. Если не успел влезть в движок, то ответить заказчику:

— Заменить иконку: 20 минут, если конечно там нет непредвиденных сложностей, мы ведь еще не смотрели движок.

А если посмотрел, и ничего не понял, то дал программисту покопаться.

Автор приводит слова Фенмана, а я вспоминаю слова Фредерика Брукса (недословно):

— Менеджер − этот тот же программист, который занят больше общением. Менеджер и программист должны меняться в разных проектах местами.
Согласен.
И самому в реальном режиме поинтересоваться у исполнителя в случае задержки, как дела идут, а не сидеть и нервничать.
C автослесарями (в нормальных сервисах) все гораздо проще. Он лезет в базу данных норм рабочего времени для определенной модели авто, там находит пункт «замена подшипника такого-то» — 1 нормочас, к этому пункту автоматически цепляются (исходя из конструкции автомобиля) дополнительные работы — «съем/установка двигателя» — 4 нормочаса, а если там еще какие хитрости — так и коэффициент сложности есть… выходит, он сразу может сказать клиенту — сделаем за 5 часов, стоить будет столько-то.
Еще раз оговорюсь, это в нормальных сервисах, а не у дяди Васи в гараже.

Так вот, по хорошему, тот, кто пишет ТЗ, должен поступать так же, вот только не всегда есть такая база с нормами работ для разработчиков, дизайнеров и т.д.
у вас есть пример хоть одного проекта (web-ориентированного) для которого присутствует ТАКАЯ хорошая документация? с готовыми оценками сроков, сложности и т.д. имхо бред нереальный.

P.S. в данном топике программист выдал сроки, не проведя предварительный анализ того что уже есть, понадеявшись на то что 'все программисты делают так как я'.
только такой базы не может быть в принципе, если у клиента самописное неизвестно что (не обязательно на коленке, просто свое)
Боюсь это больше теория, нежели практика.
отличная схема — вот только у каждого заказчика — самодельный автомобиль уникальной конструкции. :-)
Очень редко нормочас получается в итоге часом реального времени.
Да, проблема сложная и острая. Честно говоря, оценивать задачи в 20 минут по незнакомой системе я перестал уже давно. Другое дело, если система знакомая, и ты знаешь, что и как нужно сделать, но даже тогда нужно в оценку вкладывать риски. Поэтому аналогия с квантовой механикой не вполне удачна — объяснить, чем и как вы занимаетесь можно, а вот оценить задачу сложнее.

Скажите, что выполните задачу за два часа. Выполните за час — вы молодец. Как только понимаете, что задача займет больше времени, сразу же докладывайте менеджеру, и дальше решайте, что делать.

Стоит понимать, что ни один продукт не выходи в срок с запланированным набором свойств. При реализации возникают моменты, которые изменяют планы разработчиков, и один набор функций может исчезнуть или уступить место другому.
Это все верно и правильно. Но мне кажется, что тут речь шла, в основном, о том, что было бы неплохо объяснять менеджерам возникшую проблему на пальцах. А не вскипать «Куда он лезет, что он в этом понимает?!», а потом пить пиво с друзьями и ругать его на чем свет стоит.
Оттуда и аналогия с квантовой физикой
Если проблема ставиться так, то да, аналогия понятна. Но тогда возникают сомнения в компетентности работника или в его коммуникативных навыках.

Как говориться «Назвался груздем? Полезай в кузов!».

В таком аспекте виноват работник, но зачастую бывает так, что вина лежит и на менеджере и на работнике.
Менеджера должен насторожить фраза про 20 минут, а если он ещё знает, что система незнакомая для этого работника, то точно должен переспросить.
Слава богу, когда я начинал, мои руководители говорили: «20 минут? Значит час-два.» То есть они понимали мой энтузиазм, да и были тертыми калачами, которые не раз обожглись на таких оценках.
Программисту прежде чем озвучивать свои сроки, следовало бы заглянуть в код «неизвестной» ему системы.

Вообще, странный подход, когда программиста просят пару иконок перетасовать. Обычно такими вопросами занимаются верстальщики. Да, у каждой компании свой технологический процесс…
Был случай, когда меня менеджер попросил оценить сроки «допиливания» проекта. Я полез в код «неизвестной мне системы». Потратив на это рабочий день, я озвучил свой эстимейт. Этот срок не понравился заказчику и проект нам не дали. Итого — потраченный день.
Ну бывают такие случаи, но это скорее исключения.
У меня были случаи, когда один и тот же проект дважды просили озвучить по объему работ. Например, хотел клиент свой проект (самописный движок) пересадить на нормальный CMS с сохранением всего функционала. Соответственно менеджеру для осмечивания проекта нужно было от меня получить объем человеко/часов :) Я это сделал, видимо итоговая смета клиенту не подошла — договора не было… Проходит пол года, уже другой менеджер приходит ко мне с таким же вопросом… Договора не последовало.
>Итого — потраченный день.
Зря вы так. Да, заказчику не понравились сроки, но вы же его не наебали, да? Это стандартная торговля за сроки, от нее никуда не деться.
Пункт №3 в выводах ой какой неоднозначный. Из этой формулы следует, чтобы получить максимальный доход программист должен оценить свой труд в миллион попугаев трудности и выполнять эту работу всю свою жизнь.
Ваша история с подшипником очень правдоподобна. У меня гибридный автомобиль и в автосервисах примерно так всегда и происходит с ним :)
Да что там автомобили, и в компах такое случается, я однажды простой вентилятор на одном mATX час менял. (В обычных корпусах 2 болта на крышке и 4 на вентиляторе, а тут попался с виду обычный, а как два болта раскрутил оказалось что надо чуть ли не всё вынимать чтоб хотя бы увидеть где у него крепления...)
После того как программист выяснил, что надо снимать двигатель следовало сказать об этом менеджеру. Он бы это объяснил, и возможно договорился бы на другую цену.
    Самое интересное во всех пунктах это таинственный коэффициент «k».
Мало того, что правила назначения этого коэффициента очень размыты, будь то «сложно» или «просто», да и кто его будет назначать?
    Если его назначает программист то вот что из этого вышло? Коэффициент к = «Плёвое дело», «20 минут», а в итоге — «спустя 5 часов».
    Если менеджер далек от программирования исходя из «Трудно объяснить непрограммеру, но попытаюсь», хотя я лично не могу такое представить, как менеджер проектов по программированию вообще не в курсах о програмировании, хотя возможно речь идёт о простом менеджере, который сидит как прослойка между заказчиком и прграммером, тогда он тем более не может установить этот коэффициент и время.
     Так этот коэффициент ещё и меняется в процессе работы. По неясным законам.

    Я работая менеджером по проектам часто сталкивался с такой ситуацией, да честно спрашиваю за сколько это человек сделает, да мне отвечают, но зная по собственному опыту, сдача в срок согласно данному времени происходит очень редко. Всегда слышу что там, «пошло не так», что «мы не предусмотрели», что «а там вот как на самом деле». Небольшой выход из этой ситуации я нашел как:
  •     1.Не требовать с программиста ответ сразу, а дать некоторое время на анализ задачи. Я сам был программистом и знаю как это всё происходит.
  •     2.Работая с людьми, и ведя проекты, я ориентировочно вижу погрешность людей в их оценке, и корректирую сроки согласно погрешности. Причем это легко видно на диаграмме Ганта, тем более работая с людьми долгое время. В итоге можно скорректировать время.
  •     3.Учитывать риски, работая с незнакомой CMS, с незнакомой библиотекой, всё это определяет возможные проблемы, которые также влияют на время.
    Складывается такое впечатление, что пост больше от программиста чем от менеджера, и что менеджеры такие плохие, мыслят временем а не задачами. В посте также много фигурирует такой коэффициент $, если программист работает на окладе, его по сути вообще не должны волновать такие вопросы, единственное что важно, это вовремя уведомить менеджера об изменениях…

P.S. Я считаю что работать менеджером, это находить баланс, между программистами (дизайнерами, контентом и т.д.) и заказчиками, будь то это ген. директор, или заказчик со стороны. Если все проекты и задачи задерживаются, это проблема управления. Если все проекты выполняются быстрее запланированного, это проблема управления. Правильный учёт рисков и тайм менеджмент главные друзья менеджера…
А мне показалось, что писал менеджер :-)
Виноват-то оказался программист, которые обещал выполнить задачу за 20 минут, а выполнил за 5 часов.
Хотя вина обоюдная.
    Полностью обоюдная, потому как менеджер не учёл риски…
    Не хочу обижать программистов, сам им был, но просто принять время работы программиста, не добавив сколько нибудь времени на риски, это прямая ошибка менеджера. Увеличивая сроки менеджер не говорит программисту, что «ты не сделаешь это за 1 час», он просто страхует и программиста от непредвиденных обстоятельств, чтоб потом не было объяснений почему задержался проект, и заказчика от задержек, и самого себя находясь так сказать между двумя огнями.
    Программист же в данной ситуации сказал не оценив трудности...
    Если каждому из участников стараться просчитывать, и соблюдать некие правила, у каждого возможно они свои, то возможно такой вражды не будет, а то Колизей, гладиаторы… :)
Виноват менеджер. Если он работает с этим человеком не первый день то примерно должен представлять себе коэффициент вранья программиста.
Ну и кроме того он не поставил процесс доработки. Почему программист не сообщил ему о возможных задержках? Да потому что по всей видимости это было у них не принято — косяк манагера
А вот как пример, один дизайнер талантливый кампилятор, за 30-50 минут делает макет буклета из фотостоков и клипартов, другой — все сам, ручками, просит что бы фотосессия была, студия, постановочные кадры… Соответственно сроки разные, а результат — субъективное восприятие заказчика «нравится-не нравится». Как и какой коэффициент применить?
НЛО прилетело и опубликовало эту надпись здесь
вы потрясающе проницательны
В аналогии, приведенной программистом, исходная предпосылка неверна. Человек, который «Я автослесарь, с хорошим опытом, много чего переделал» — никогда не оценит в 15 минут работу по машине, которой в глаза не видел.
Да прям-таки…

Для большинства машин существуют таблицы с количеством нормо-часов для различных операций.
Поэтому, когда прибегает начальник со словами «там надо поменять подшипник, скажи мне точно за сколько времени ты его поменяшь?» — автослесарь, помня примерно эти таблицы, скажет «1 час». Потому как ни в одной машине ему не встречалось более одного нормо-часа (меньше — да, но он выберет максимально).

А потом ему притащат ржавого экзота — и танцуй как хочешь.
>Автослесарь, помня примерно эти таблицы, скажет «1 час». Потому как ни в одной машине ему
>не встречалось более одного нормо-часа.

Ну, если не встречалось, значит это врядли можно назвать «хорошим опытом».
Я, поработав подростком в автомастерской, насмотрелся на подобное. Был у нас, например, доморощенный гений Вова по кличке Эйнштейн — мужичок лет 35, хорошо шаривший в электронике и занимавшийся этим не первый год — на вид типичный гик.
Привезли, значит, на лямке аппарат(вроде бы АльфаРомео какой-то был, уже не помню). Дым из-под панели, ничо не работает. Вова чота пошуршал — ну и такой говорит — похоже на то-то и то-то, но я не уверен, давайте я поковыряюсь и скажу попозже более конкретно по срокам/стоимости и т.д.
Заказчику было невтерпеж, он давай Эйнштейна мучать — ну мне надо, ну скажите хотя бы примерно. Вобщем, уговорил и Вова ему таки сказал — ну к вечеру сделаю. И клиент уехал.
Вова лазил-лазил, и в какой-то момент понял, что сел в лужу — чота там толи сгорело, чему замены быстро не найти, толи еще что, не знаю.
Вобщем, делали неделю.
А Вова больше не поддавался на подобные уговоры и говорил сроки только после ознакомления с задачей(если, конечно, не встречался ранее).
Вот это, по моему мнению, и есть «хороший опыт».
Спасибо за интересный, легкий и важный материал.

Позволю себе немного позанудствовать:
> где t1, t2 и т. д. — временные промежутки, а k1, k2 и т. д. – коэффициенты сложности за данный временной промежуток.
где t — временной промежуток, а k– коэффициент сложности за соответствующий временной промежуток

> требовать у менеджера необходимости повышения S в связи со внезапно обнаружившимся k
требовать у менеджера необходимости повышения S в связи со внезапно обнаружившимся повышением k
Странно. Нет объективного способа измерить коэффициент сложности.
Например. Сидит мега-гуру Василий и стажёр Петька. Им говорят, ребята, за сколько времени и сложности иконки замените? Василий (опытный!) говорит: «час, чтоб запас был. Может, меньше. Коэффициент сложности… Ну, 2». Петька (смелый) говорит: «фигня, 20 минут. Но я никогда не работал с этой технологией, так что коэффициент 6». Противоречие видно. У каждого свой коэффициент, разные оценки времени… Получается в целом, что коэффициент ваш это мера риска увеличения сроков. Тогда непонятно, отчего оплата задачи должна быть ему пропорциональна…

Что же касается описанной ситуации, программер молодец, что может объяснить. (Хотя я бы и не заявлял первой фразой о том, что «сложновато вам, непрограммерам, нас понять». Могут и обидеться)
Но программер был бы дважды молодец, если бы не через 5 часов написал, что всё плохо вот поэтому. А через 20 минут. В духе «возникли такие-то сложности, я сейчас оцениваю оставшееся время в три часа. А может, и больше выйдет». А менеджер смог бы уже решить, нужны ему те иконки за три с половиной часа (а может и больше) денег или нет.
Странно. Нет объективного способа измерить коэффициент сложности.
Например. Сидит мега-гуру Василий и стажёр Петька. Им говорят, ребята, за сколько времени и сложности иконки замените? Василий (опытный!) говорит: «час, чтоб запас был. Может, меньше. Коэффициент сложности… Ну, 2». Петька (смелый) говорит: «фигня, 20 минут. Но я никогда не работал с этой технологией, так что коэффициент 6». Противоречие видно. У каждого свой коэффициент, разные оценки времени… Получается в целом, что коэффициент ваш это мера риска увеличения сроков. Тогда непонятно, отчего оплата задачи должна быть ему пропорциональна…

Что же касается описанной ситуации, программер молодец, что может объяснить. (Хотя я бы и не заявлял первой фразой о том, что «сложновато вам, непрограммерам, нас понять». Могут и обидеться)
Но программер был бы дважды молодец, если бы не через 5 часов написал, что всё плохо вот поэтому. А через 20 минут. В духе «возникли такие-то сложности, я сейчас оцениваю оставшееся время в три часа. А может, и больше выйдет». А менеджер смог бы уже решить, нужны ему те иконки за три с половиной часа (а может и больше) денег или нет.
мне всё таки кажется, что программист поступил опрометчиво, сказав «20 минут», не разобравшись в сложности. И хорошо ещё, что вообще справился, а если б выяснилось, что «двигатель не снимается вообще»? Это имхо, индусский подход – изначально занижать цену/длительность/сложность задачи, чтобы не отпугнуть клиента.
хороший специалист и честный человек сделает хотя бы оговорку, что «20 минут» это если не возникнет сложностей. хотя могу себе представить, что программист эту оговорку делает, а менеджер в разговоре с клиентом её умалчивает.
М-да…
Инога всё-таки надо делать инвестигейт перед эстимейтами, чтоб не профакивать потом эстимейты в 15 (пятнадцать!) раз.
Эх, если б формула была такой простой. В жизни посложнее будет
В «Гладиаторов» играете? :)
Упрощение ситуации без потери смысла:

назвал ответственному оценку для «типовой» задачи (1).
Возник ряд форс-мажоров (2),
с которыми исполнитель справился (3),
затратив на порядок больше ресурсов (4).
В ходе работы он ответственному о проблемах не сообщал (5),
а тот, видя перерасход ресурсов, не пытался узнать причину (6).
+ возможно, не был оговорен сам срок сдачи работы ответственному (7) — контрольная точка.

(1) предварительно оценивай любую задачу — лучше сначала называй срок на оценку;
(2) форс-мажоры могут возникнуть всегда, независимо от наличия оценки — при форс-мажоре обязательно проведи переоценку, и глубже — с большей уверенностью, даже если с меньшей точностью (!)
(3) мог и не справиться, и это была бы не только проблема исполнителя — о форс-мажоре сообщи ответственному
(4) форс-мажор может открыть варианты, о которых ты не знаешь — например, овчинка уже не стоит выделки, или результат уже не нужен, а исполнитель видит ограниченный набор решений — при форс-мажоре переоцени и… сообщи ответственному
(5) см. (3), (4)!
(6) менеджер, отвечай за ресурсы — держи руку на пульсе
(7) менеджер, расставляй контрольные точки
и немного банальностей:

1. для любителей математики и абстракций: пусть S — стоимость работы, H — цена единицы ресурса (в данном случае — часа работы исполнителя), P — «средняя производительность» ресурса, V — номинальный объем работы, K — «коэффициент расхода» для конкретного ресурса (во сколько раз для данной работы возрастает расход выбранного ресурса), D — «относительная сложность» работы, T — количество ресурсов, необходимое для выполнения работы

Очевидно:
S = H * T, T = K * V, P = P (H), K = K(P, D) => S = H(P) * K(P) * V

В упрощенном «идеальном» случае: P ~ H (P пропорциональна H), K ~ D, D ~ 1 / P, =>
S ~ (P) * (1/P) * V = V — не зависит от K,

т.е. за сложность не платим.
— 2. Еще банальности (сорри, приближенные формулы уже лениво писать, и можно разные варианты — суть не меняется) — для реального случая и «ресурсов»-людей:

1) при правильном выборе (из множества «непереоцененных» ресурсов) производительность ресурса растет быстрее его стоимости => более дорогой специалист сделает в результате работу дешевле

2) в работе всегда есть потери — текучка, простои и т.п., снижение которых происходит медленнее роста производительности => невыгодно на относительно простую работу направлять относительно дорогого исполнителя;

3) еще скрытые потери — затраты на менеджмент и обслуживание ресурса (в основном, из-за п.2) => можно сэкономить, отдавая на аутсорсинг (если менеджмент аутсорсинга менее затратен); но возрастают риски + нет ресурса для той самой текучки

4) люди — «ресурс» привередливый, и чем дороже, тем привередливее: на относительно простую (скучную) работу придется привлекать завышенными ставками

лениво удалять все эти перлы — авось пригодится кому.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий