Так вот, самая скользкая тема в нашей работе – оценка трудоемкости задач. И гадость в том, что, какую бы оценку мы не давали, она будет казаться нечестной.
Вся гадость кроется в сути работы программиста 1С на небольших задачах по доработке. Если вы не в курсе, я кратко поясню.
Задачу, обычно, надо решить в какой-то конфигурации 1С. Это большая программа, написанная или фирмой 1С, или каким-то из ее партнеров. Клиенту надо изменить поведение какого-то механизма – или чутка, или нормально так, или совсем. А бывает, что заранее не известно, надо ли менять программный код или структуру данных – возможно, задачу можно решить средствами настройки, уже заложенными в конфигурации.
Вот в этом «возможно» и зарыта собака. Можно исходить из аксиомы, что всех способов решения задачи не знает никто, даже разработчик конфигурации – просто потому, что некоторые задачи решаются организационно, вне контекста ПО.
Один программист знает один способ, другой – два способа, третий – четыре, и т.д. Лютый программист не знает ни одного способа, но уверен, что, если покопаться, найдет десять.
Один способ – одна строка кода, второй – десять, третий – проект на полмиллиона, четвертый – организационные изменения бизнеса заказчика, покупка нового сервера, консалтинговый проект. И т.д.
Поэтому вариативность в решении задач очень высокая, начиная с направления решения, заканчивая использованием типовых (написанных фирмой 1С) стандартных подсистем vs написания кучи собственного говнокода.
Вернемся к теме. Допустим, есть некая задача. Пусть это будет выгрузка данных из базы 1С в формате JSON по списку, перечисленному заказчиком (контрагенты, отгрузки, долги и т.д.) – каждый кусок в своём формате, с разным уровнем вложенности и т.д.
Обычно происходит так – задачу дают на оценку предполагаемому исполнителю, или некоему эксперту, или обоим сразу, для верности. Допустим, получается 8 часов. Оценка согласовывается с клиентом, и специалист приступает к работе.
Зная оценку, приличный специалист стремится решить задачу быстрее, чем за 8 часов. Допустим, у него получилось за 6. Нечестно? Ну да.
Мы специалиста ругаем, говорим, что он не прав, завысив изначальную оценку, и надо было сразу ставить 6 часов. И в следующий раз чтоб ни-ни!
Специалист обижается, и в следующий раз тупо отказывается делать работу с этим клиентом или менеджером, ссылаясь на занятость. Задача уходит, допустим, стажеру, с оценкой в 6 часов.
А стажер, к сожалению, не знает, что такое JSON. И что такое выгрузка представляет себе слабо. Не говоря уж о метаданных конфигурации, из которой надо получить данные. И отборы никогда не видел. А данные умеет только в эксель выгружать, мышкой. В итоге, просидит с задачей все 32 часа. А клиент заплатит за 6. Опять нечестно! Только на этот раз мы угорели, а не клиент.
Ок, плюем на предварительные оценки. Пусть специалист просто решает задачу, а часы, выставляемые клиенту, возьмем по факту. Честно же? Увы, ни хрена.
Стажер просидит те же 32 часа. Если выставить такую сумму клиенту, он будет писать кипятком и орать, что это нечестно.
А если просидит толковый специалист, сколько часов получится? Скорее всего, 8, потому что столько, по его мнению, и стоит эта задача. А может, и все 12 – он ведь знает, сколько с задачей просидел бы стажер. Опять нечестно.
А через некоторое время приличный специалист начнет возмущаться, что его квалификация, умение планировать свое время, колоссальный опыт и знания пропадают даром. Какой отныне смысл стараться, если получишь столько, сколько просидел? Сама суть, цель его работы меняется – надо не сделать хорошо и быстро, а лишь подольше ПРОСИДЕТЬ. Но просидеть дольше, чем рабочий день, сложно. Нафиг идут личная жизнь, семья, выходные – специалист будет сидеть по 12 часов, потому что это время ему оплачивается.
Клиент, узнав об этом, скажет – нечестно! Особенно, если увидит фотографию рабочего дня.
А бизнесу каково? Любой бизнес ведь только и думает, что об эффективности. Эффективность, я напомню – это отношение полученного результата к приложенным усилиям. Когда результат – это решенная задача, то появляется поле для снижения объема приложенных усилий. А когда результат – это потраченное время (ведь именно оно продается), то получается, извините, бордель с почасовой оплатой. Единственный способ роста доходности борделя – увеличение масштаба, т.е. точек зарабатывания денег. Увеличение штата, короче говоря.
Знатоки борделей скажут – фигня. Можно повышать квалификацию, и продавать специалистов по разной стоимости часа. Прекрасная идея! Пусть час работы специалиста для клиента стоит впятеро дороже, чем час работы стажера!
Звучит заманчиво, но для клиента-то ничего не изменится. Специалист делает за 6 часов, стажер – за 32. Сумма к оплате получается одинаковая. Уже не нечестно, конечно, а просто никак.
Но может быть и нечестно, специалисты ведь не равны. Если два человека имеют опыт по 10 лет, они всё равно будут решать задачи с разной скоростью и трудоемкостью. Причем, разница может быть в 2-3 раза.
Можно начать извращаться, определяя ставку специалиста не исходя из его квалификации, а исходя из его способности решить конкретную задачу. Например, программист со стажем 10 лет будет решать задачу по расчету зарплаты дольше, чем консультант по расчету зарплаты со стажем 2 года. Получается, нужна динамическая (очень динамическая!) корректировка стоимости часа, исходя из задачи. Для ее вычисления придется нанять пару толковых диспетчеров.
Есть совсем извращенные способы, вроде определения стоимости работ по альтернативным издержкам. Например, чтобы клиенту работать с внешними подрядчиками было выгоднее, чем с собственными специалистами. Если сравнить чисто стоимость часа, то внутренний фикси – выгоднее. Если же объем работ в целом не такой большой, чтобы загрузить человека на 100 %, то аутсорс – выгоднее. При таком способе расчеты также будут сложными, контекстно-зависимыми и динамическими. И нечестными, т.к. будут сравниваться понятия, которые сравнить сложно – цена конкретной работы и неспособность к грамотному управлению внутренними сотрудниками.
Да и клиенты все разные, и никакой способ оценки не будет одинаково честным или нечестным для всех. Один считает каждую копейку, и готов часами сидеть с секундомером над душой у программиста, и обязательно на территории работодателя, чтобы его не накололи. Другой вообще не приемлет никакой почасовки, фактической оценки и вероятностей. Ему нужна конкретная стоимость и четкий срок, которые он согласует с руководством, внесет в бюджет, пройдет сложную процедуру утверждения заявки на расход денег, а сколько уж уйдет по факту — его вообще не колышет.
Цена, которую клиент готов заплатить за конкретную работу, очень сильно зависит от контекста, условий конкретного момента. Например, от того, насколько клиенту больно, пока задача не решена. Если в розничном магазине алкоголя легла касса и ЕГАИС, то клиенту очень больно. Если бухгалтер хочет кнопочку, которая заполнит два поля в документе, которые он успешно заполнял руками, то не больно совсем.
Если у вас болит зуб – так, что не помогают никакие обезболивающие, невозможно ни есть, ни пить, ни спать, ни работать, то вы побежите в первую попавшуюся стоматологию, чтобы снять боль. Если же вы хотите сделать гигиену полости рта, то вполне подождете и пару месяцев, тщательно выбирая клинику, специалиста и поджидая какой-нибудь акции. И то, и другое будет вам казаться честным, несмотря на серьезную разницу в цене.
Так что, какую бы оценку не получила задача, честности в ней не будет. Абсолютной, идеальной, белой и пушистой честности, про которую пишут в детских книгах. Тут нет черного и белого, есть только оттенки серого.
Лично мне больше нравится предварительная оценка, потому что она дает не только возможность, но и мотивацию к повышению собственной эффективности. Оценка по факту – напротив, убивает стремление к эффективности напрочь, превращая человека в «каменную задницу» (так называли Молотова), желающую лишь подольше просидеть.
Предварительная оценка – отличный стимул для роста стажера. Если он знает цену работы заранее, и видит, что просидел в пять раз дольше, то объективно понимает свою тупость. А видя другого специалиста, который, хотя бы, уложился в оценку, стремится стать таким же.
Для клиента, если разобраться, честной может быть только одна цена – ноль. Частенько она сопровождается аргументацией «я и так купил вашу программу, почему я должен еще за что-то платить?».
Но на деле, мне кажется, критерий честности для клиента один: он готов заплатить указанную цену. Если не готов, надо торговаться, как за башмаки на рынке. Граница снижения определяется, как в любом бизнесе, финансовыми и политическими целями и показателями обеих сторон.
А как оценивать работы? Мне близка оценка по Джону Доу (так в США называют неизвестного подозреваемого). Джон Доу – это некий средний программист. Круче, чем стажеры, но хуже, чем опытные специалисты. Некий средний.
Стажеры должны стремиться стать Джоном Доу, что в цифрах означает, например, конверсию, равную 1, при отсутствии потерь между задачами и входящем потоке работы, обеспечивающем стопроцентную загрузку. Такого потока обычно нет, поэтому можно снизить планку – пусть Джон Доу делает в день по 6 часов. В месяц получится примерно 126 часов. Ни много, ни мало. Джон Доу. Напомню, речь о небольших задачах, а не проектной загрузке.
Толковый специалист, догнав и перегнав Джону Доу, может зарабатывать намного выше среднего. Его квалификация, компетенции, умение быстро вникать, писать код, как Бог, своевременное изучение новых механизмов и инструментов, проактивная работа с клиентами, грамотно политически выстроенная работа с менеджерами, четкое соблюдение сроков – всё то, что делает его толковым специалистом – наконец, начнет приносить ему доход.
Иначе какой смысл становиться толковым специалистом, при одинаковой для всех часовой ставке? Или при оценке работ по факту? Инвестиции в себя должны окупаться, иначе нет смысла их делать.
Как оценивать по Джону Доу? Сразу скажу – не знаю. Это приходит с опытом. Спросите какого-нибудь опытного специалиста, как он оценивает работы. Просто смотрит на задачу, и называет оценку. Всё. Нет никакого алгоритма, есть опыт, представление о стоимости работ, накопленная внутренняя статистика.
Голова просто выдает ответ на вопрос «сколько такую работу будет делать средний специалист».
С одной стороны, это мистика. С другой, я несколько раз в жизни проверял, и каждый раз убеждался, что метод работает.
Например, мы независимо с разными специалистами, с опытом 8-15 лет, оценивали работы, и почти всегда получались предельно близкие цифры. Однажды, несколько лет назад, я оценивал большой перечень работ, который в сумме вышел на 2000 часов. Потом дал своему коллеге, чтобы тот оценил по-своему, не глядя на мой результат, и у него вышло 1990 часов. Магия, не иначе.
Оценка по Джону Доу, конечно, тоже не честная. Как и любая другая. Просто поймите, примите и используйте: честных оценок не бывает. Вообще.
Оценка – это инструмент, которым можно пользоваться, достигая разных целей.
Для менеджера оценка – это способ получить клиента. Или привязать клиента. Или переманить клиента. Или заработать денег. Или заработать больше денег. Или раскрутить клиента.
Для специалиста оценка – это цель, мотив для роста квалификации, причем – разносторонней. И программировать быстро, и вникать в незнакомые конфигурации и механизмы, и общаться с клиентом, и спрашивать помощи, и получать ее, и использовать чужие решения.
Для компании оценка – это инструмент управления. Понятный, прозрачный, элемент системы мотивации. Он позволяет управлять, не управляя.
Краткое содержание
Честной оценки стоимости решения задачи не бывает.
Любая оценка зависит от контекста.
Контекст включает специалиста, который решает задачу, менеджера, который ее продает, клиента, который за нее платит, конкретного представителя клиента, который должен оценку согласовывать, и т.д.
Предварительная оценка может быть ошибочной, т.к. в нее заложены риски.
Оценка по факту может быть ошибочной, т.к. не известно, с какой скоростью движется исполнитель — реальной или «чтоб подольше просидеть».
Нормирование — вообще невозможно.
Наиболее перспективной кажется оценка по Джону Доу — сколько эту задачу решал бы средний программист.
Получается всё-таки предварительная оценка, но не по конкретному специалисту, а по вымышленному среднему.
Стажеру есть куда стремиться — он работает хуже, чем Джон Доу.
Опытному есть куда стремиться — он работает лучше, чем Джон Доу.
Когда оценка известна заранее, есть и цель, и мотив к повышению эффективности и ее применению.
Комментарии (45)
Stas911
10.12.2019 03:47Ни разу не работал на проектах, где бы продавали прямо единицы часов. А на больших проектах размером в сотни и тысячи часов настолько большая флуктуация и непределенность (а если у заказчика еще и несколько подрядчиков на проекте — то что может пойти не так, в самом деле?), что кроме весьма общих фраз («сделать чтобы было круто, а некруто не было») и суммы денег, часов и количества консультантов в SoW вообще ничего толком нет.
Politura
10.12.2019 06:04Зная оценку, приличный специалист стремится решить задачу быстрее, чем за 8 часов. Допустим, у него получилось за 6. Нечестно? Ну да.
Мы специалиста ругаем, говорим, что он не прав, завысив изначальную оценку, и надо было сразу ставить 6 часов. И в следующий раз чтоб ни-ни!
Ужас какой-то, ругать человека за то, что сделал быстрее, чем планировал.
Chagevare
10.12.2019 09:03+1Мы специалиста ругаем, говорим, что он не прав, завысив изначальную оценку, и надо было сразу ставить 6 часов. И в следующий раз чтоб ни-ни!
Кто «мы»?!? Ни разу еще не видел, чтобы ругали за завышение цены. Только хвалят. Ну и я тоже не могу понять, зачем нужны эти «часы», особенно для клиента. Воспринимаю их просто как «у.е.», которые в результате все равно конвертируются в конкретную сумму в рублях.
Virgo_Style
10.12.2019 11:32+1Не за то, что сделал быстрее, а за то, что оценил дороже. А менеджер из-за этого отказался от двухчасовой задачи, которая тоже принесла бы деньги, но из-за завышенной оценки в план не вписалась.
При определенных условиях — вполне жизненная проблема.
Neikist
10.12.2019 12:51+5Угу, т.е. риски и резервы это не наше, набьем в план работ пока утрамбовывается, и если из за любой проблемы в любой из задач план поедет — «не ожидали, ругаем разработчика что не осилил в срок», а если проблем оказалось меньше чем планировалось — «не ожидали, ругаем разработчика что можно было еще больше утрамбовать, а мы и не знали». Вам не кажется такой подход немного нелогичным?
Virgo_Style
10.12.2019 12:55Кажется, конечно. Но, к сожалению, мое мнение оказывает крайне слабое влияние на данную нам в ощущениях реальность %)
gennayo
10.12.2019 08:14Понятия «честно/нечестно» для бизнеса как-то не очень, а вот если заменить на выгодно/не выгодно…
sigo73
10.12.2019 08:47+2КМК, Вы настолько сильно привязались к способу оплаты по часам — что не можете выйти за рамки и увидеть другие решения. Попробуйте представить что в магазине Вам продают молоко исходя из длительности процесса по его изготовлению. Или зубной врач Вам лечит зуб и берёт оплату не за сам факт излечения (удаления, установки пломбы,...), а пропорционально длительности лечения. За часы берут там, где есть стандартные работы, которые нормированы и их длительность подтверждена «владельцем процесса». Для примера — сервисные центры автомобильных производителей: там есть нормо-часы, и по ним оценивается работа.
vis_inet
10.12.2019 08:57А как правильнее оценивать?
sigo73
10.12.2019 09:28+1Не знаю как «правильнее», ибо в таком случае нам придётся давать определение правильности. Нужно разделить оценку стоимости наружу (для клиента) и внутри — вознаграждение сотруднику.
Стоимость наружу — это маркетинг и продажи, за сколько Вы сможете убедить заказчика купить Ваше решение — за столько и продавайте, ведь он покупает не часы — он покупает дополнительный функционал в своей информационной системе, который позволит ему тем или иным образом повысить эффективность своих бизнес-процессов. Возможно Ваше решение поможет ему заработать дополнительные 10млн.рублей прибыли в год, а стоить для него оно будет всего 100 тыс.рублей.
Оценка внутри — это вопрос соответствия Ваших ожиданий от сотрудника. Можно оценивать выполнение задач — соответствие фактического выполнения планам (кол-во задач, сроки выполнения). Можно оценивать результаты работы — соответствие реализованного функционала техническому заданию. Можно получить от заказчика обратную связь по реализованному проекту/задаче и это тоже использовать в качестве оценки результата работы сотрудника. Можно включить в процедуру оценку и менеджера по продажам, который обращается к программисту в ходе взаимодействия с заказчиком. В компании, где я работал одно время — бэкенд (поддержка продаж) состоял из инженеров и программистов. Их з/п зависела от их квалификации (оклад + ежемесячная/квартальная премия). Программист/инженер — не продавец, в первую очередь он обеспечивает выполнение задачи качественным образом. Если менеджер не смог продать решение, то это вина менеджера и «страдать» должен он.vis_inet
10.12.2019 09:40Заказчик обычно спрашивать «сколько стоит», «из чего сложилась стоимость» и «почему так дорого».
Определив «стоимость наружу», как вы ему это обоснуете?sigo73
10.12.2019 09:50+1Во именно в этом и заключается работа менеджера по продажам. Например, я бы (в роли менеджера по продажам) попробовал сравнить стоимость разработанного функционала со стоимостью системы навигации или системы климат-контроля для его автомобиля. Ведь заказчик покупая дополнительный функционал для автомобиля не спрашивает у производителя авто — из чего сложилась стоимость климат-контроля, системы навигации, системы автоматической парковки, задней камеры. Я понимаю что за прошедшие годы так сложилось что всё время продавали часы, и даже заказчики стали «думать часами».
vis_inet
10.12.2019 09:56Вероятно, так сложилось из-за того, что оценка стоимости по трудозатратам (часам) немного более поянтна и обоснуема, чем «по ценности для заказчика».
sigo73
10.12.2019 10:03+1Ну вот «благодаря» этому и пришли к тому, что имеем. Только ценности продаются успешнее и с большей маржинальностью.
lotse8
10.12.2019 12:11Продавать надо не часы, а решения.
vis_inet
10.12.2019 12:23Часто встречающийся пример: дополнение какой-то типовой печатной формы несколькими колонками или полями.
Как вы её оцените?lotse8
10.12.2019 13:56Да в таком случае Вам уже давно надо было прайс-лист на все типовые задачи (доработки) сделать, и всем клиентам сразу после инсталляции вручать, чтобы и Вам мозги не парили, и Вы себя калькуляциями на каждый чих не мучили.
vis_inet
10.12.2019 14:22А колькуляция сильно зависит от того, что именно нужно вывести.
Где-то это просто реквизит текущего документа, а где-то нужно сделать выборку каких-то доп. данных.
Поэтому нельзя сделать прайс «добавление одной колонки» — 1000 руб.lotse8
10.12.2019 15:44Судя по всем Вашим комментариям, у Вас ситуация «не могу живет на улице не хочу». Потому что кто хочет, тот ищет решения, а кто не хочет — причины.
В любом прайс-листе можно указать цены «от...» и это уже какая-то точка отсчета для клиента.vis_inet
10.12.2019 19:56Просто из опыта.
А цена «от» — это вообще ни о чём, минимальный квант работы, 1 час, к примеру.dth_apostle
10.12.2019 20:14Цена «от» — эта самая цена, из-за которой вам не влом просто поднять руку/пятую точку/оторвать взгляд от социальной сети.
dth_apostle
10.12.2019 15:14Определив «стоимость наружу», как вы ему это обоснуете?
«Оно столько стоит», «Сложившаяся стоимость на рынке». Блин, уже выше же привели пример — вы молоко/хлеб покупаете только выяснив, сколько времени потратили все участники на произ-во?vis_inet
10.12.2019 20:07Молоко и хлеб — это массовые продукты.
А многие доработки дл каждого клиента свои.
Как в таком случае убеждать, что это именно «Сложившаяся стоимость на рынке»?dth_apostle
10.12.2019 20:13В таком случае — решение, не имеющее аналогов. У продавца нет необходимости _обосновывать_ цену. Он конкурирует с другими продавцами. И все. Если спрос на товар неэластичный, то еще и диктует прямым образом цену покупателю. Если наоборот, но конкурентов нет, то падает до _приемлемого_ спроса (а не до какой-то обоснованный цены). В Сахаре мороженное будет стоить дорого вовсе не потому, что в него бриллиантов накрошили.
trueMoRoZ
10.12.2019 11:15в 1С как раз множество типовых мелких задач, по которым ценность для клиента только одна — дешевле.
sigo73
10.12.2019 15:30Предложите клиенту абонемент — ежемесячная плата за возможность доработок. Вы получите стабильный ежемесячный доход и возможность загрузить отдел поддержки продаж (программисты+инженеры) в периоды «застоя». Клиент получит ценность в виде возможности обратится несколько раз в месяц за получением решения по возникшей задаче. Создайте прайс-лист на типовые задачи и посчитайте сумму абонемента.
trueMoRoZ
10.12.2019 16:43Там даже подписку ИТС не хотят покупать, которая нужна для обновлений, а вы про абонентку на задачи. Многие хотят просто разово заплатить за какую-то задачу и всё.
dth_apostle
10.12.2019 18:11+1а вот про ИТС я хорошего не скажу. Тот факт, что из-за частых изенений законодательства 1С подсадила всех клиентов на ИТС, к-рые еще и включает часто безграмотных спец-тов франчайзи, во многом дискредитировал идею подписки.
Да еще и нынешние веяния той же Jet Brains — «продукты мы продавать не будем, вам же нужен сервис. А если вам не нужен наш сервис (впаривание услуги), нам не нужны вы». В общем, есть у клиентов реальные причины подозрительно относиться к идеи услуги.
vis_inet
10.12.2019 20:14ИТС, да, пример не показательный.
Абонентка иногда имеет место быть.
Но, даже и при ней, возникают вопросы об объёмах задач — «А почему эта задача такая большая, мы думали ещё и другие в этом месяце сделать, а время уже закончилось...».dth_apostle
10.12.2019 20:20Ну, если вы будете ошибаться каждый раз при оценке в Х раз, клиент просто перестанет вам доверять. Тут дело не в стр-ре цены, а просто его вере в ваш профессионализм. Либо ему придется брать ваши риски на себя (то есть закладывать всегда в Х раз больше, чем сказали вы). В случае 2х юр лиц это уже сложно, проще найти более точного или осторожного.
sigo73
11.12.2019 08:22Скупой платит дважды. Такие клиенты точно не моя целевая группа.
P.S. я не про ИТС если что.
CDCrom
10.12.2019 09:01А как же оценка стоимости по функциональным точкам?
Т.е. даете оценку количества функциональных точек, даете на её основе оценку стоимости.
После выполнения работ подтверждаете реализацию задачи за отведенное количество точек. Если сделали больше, постараться уговорить заказчика оплатить доп работы, если меньше либо предложить доработку другого куска кода, либо сделать скидку.
Или к доработке это не применимо?vis_inet
10.12.2019 09:12Думаю, такое малоприменимо.
CDCrom
10.12.2019 10:22Почему? При использовании функциональных точек как раз присутствует исключение таких факторов как:
— квалификация исполнителя
— состав группы, и это может быть хоть 1 человек, хоть 20 человек
— количество требуемого кода (если кто-то использует такую меру)
Получается более универсально и заказчик и разработчик делают то, о чем договорились. Да время еще будет иметь значение, но при составлении соглашения его можно только ограничить т.е. если пройдет 10 дней, будем считать пени, но конкретно на стоимость оно влиять не будет.
Ну или может, но только в части: «успеете за один день, получите +20%»vis_inet
10.12.2019 10:59Мне показалось, что метод функциональных точек мало применим к 1С, про которую пишет автор.
К тому же требует значительного времени для оценки задачи.
Drakosh
10.12.2019 10:28-2А как насчет того чтобы оценивать "сколько эта доработка принесёт бизнесу?"
Подключение кассы к егаис сэкономит 10 тыс штрафа- берем 8 тыс за 5 минут работы и спим спокойно.
Заполненные два поля спасут бухгалтеру 5 минут работы в год? — так мы еще клиенту доплатить должны за то, что бухгалтера оторвали от работы пока обновление ставили.sigo73
10.12.2019 10:38Это хороший подход, но чтобы убедить в этом заказчика — вы должны будете понять как работает его бизнес и правильно ли рассчитаете этот экономический эффект. Но если рассчитаете правильно и заказчик тоже это увидит, то сможете и продать дороже чем просто за часы. Об этом чуть выше я и писал, продавать нужно ценности, а не часы.
Panda_sama
10.12.2019 12:26+1вы забываете, что есть другая сторона: клиент стремится снизить оплату
поэтому даже если ваша доработку принесет/сэкономит клиенту миллион, и вы предлагаете сделать её, скажем, за полмиллиона (а внутренние затраты на это будут 100 тысяч) — то может найтись другой человек, который предложил сделать эту же доработку за 200 тысяч, и сам оставшись с прибылью, и клиента сильно не ободравdth_apostle
10.12.2019 15:16вот как раз кривая спроса и предложения. Обратите внимание, в вашем возражение часы трудозатрат не упомянуты ни разу
sigo73
10.12.2019 15:34Конкуренция неизбежна, нужно либо снижать цену, уходить в другой сегмент клиентов (премиальный/средний+) или добавлять в свой «продукт» дополнительные фишки, которых нет у конкурента (гарантия на решение N-месяцев, скидка на следующий заказ, .....). Это опять же маркетинг, молоко «Домик в деревне» стоит дороже конкурентов, но его тоже покупают.
SergeyTitkov
10.12.2019 11:07Когда оценка известна заранее, есть и цель, и мотив к повышению эффективности и ее применению.
ДеМарко в человеческом факторе доказал обратное и доказал насколько это плохо.
mad_nazgul
10.12.2019 12:45Оценить время затраченное на задачу для конкретного специалиста — не возможно.
Одну и ту же задачу конкретный человек может решать с разбросом до 4 часов (сам видел).
Тут как в квантовой физике измерение (наблюдатель) оказывает влияние на результат.
Grigorenkovic
10.12.2019 16:06Сегментация задач и статистика по выполненным проектам/задачам. Если задачу ранее не выполняли и даже в гугле нет — то это проект с плановой оценкой и закладанием рисков по времени и другим ресурсам.
korolevdd
11.12.2019 14:57| Спросите какого-нибудь опытного специалиста, как он оценивает работы. Просто смотрит на задачу, и называет оценку.
Разные специалисты, с одинаковым стажем работы и одним грейдом, называет свою оценку, которая может расходиться вдвое.
Например, два сеньора могут видеть одну и ту же задачу и называть сроки, в которые он уложится. Один за 6 часов, второй за 10-15 часов. Вроде оба сеньора, у обоих одинаковая зарплата и опыт работы, но видят задачу по-разному. Но оба могут с задачей справиться быстрее\медленнее. Сложно определить.
Считаю что оплата за труд программиста должна зависеть от нужд бизнеса.
Например, есть задача создавать каждую неделю отчет в один клик. У менеджера\бухгалтера создание этого отчета занимало час рабочего времени, и стоил этот час, допустим 500р. За год это 24000р. Двум сеньорам подкинули задачку. Первый сделает за 20 часа, второй за 40 часов. У обоих з\п одинаковая, допустим 1000\ч. Думаю, во втором случае, вы задумаетесь, а нужен ли будет этот отчет через год.
somebody4
Чем больше задача, тем точность оценки ниже. Из скрама — task можно оценить довольно точно, story — более-менее, а с epic можно 20% ресурсов затратить только на попытку сделать правильную оценку. Поэтому для внутренней оценки epic пойдёт SWAG, а для внешней больше зависит конкретного клиента и текущей ситуации в компании.
Иногда выгодно дать цену заведомо ниже себестоймости. Потому что опеределение целей звучит как «максимизация прибыли или минимизация убытков». Т.е. даже если что-то убыточно, это всё равно может быть выгодно для нас.
Ну и ещё можно успользовать вариант «Джон Доу» — «Джон Доус», т.е. используем разновидность planning poker, для оценки (несколько экспертов дают свою оценку, лучше всего с примерами предыдущих задач похоже сложности)