Комментарии 45
НЛО прилетело и опубликовало эту надпись здесь
Ни разу не работал на проектах, где бы продавали прямо единицы часов. А на больших проектах размером в сотни и тысячи часов настолько большая флуктуация и непределенность (а если у заказчика еще и несколько подрядчиков на проекте — то что может пойти не так, в самом деле?), что кроме весьма общих фраз («сделать чтобы было круто, а некруто не было») и суммы денег, часов и количества консультантов в SoW вообще ничего толком нет.
Зная оценку, приличный специалист стремится решить задачу быстрее, чем за 8 часов. Допустим, у него получилось за 6. Нечестно? Ну да.
Мы специалиста ругаем, говорим, что он не прав, завысив изначальную оценку, и надо было сразу ставить 6 часов. И в следующий раз чтоб ни-ни!
Ужас какой-то, ругать человека за то, что сделал быстрее, чем планировал.
Мы специалиста ругаем, говорим, что он не прав, завысив изначальную оценку, и надо было сразу ставить 6 часов. И в следующий раз чтоб ни-ни!
Кто «мы»?!? Ни разу еще не видел, чтобы ругали за завышение цены. Только хвалят. Ну и я тоже не могу понять, зачем нужны эти «часы», особенно для клиента. Воспринимаю их просто как «у.е.», которые в результате все равно конвертируются в конкретную сумму в рублях.
Не за то, что сделал быстрее, а за то, что оценил дороже. А менеджер из-за этого отказался от двухчасовой задачи, которая тоже принесла бы деньги, но из-за завышенной оценки в план не вписалась.
При определенных условиях — вполне жизненная проблема.
При определенных условиях — вполне жизненная проблема.
Угу, т.е. риски и резервы это не наше, набьем в план работ пока утрамбовывается, и если из за любой проблемы в любой из задач план поедет — «не ожидали, ругаем разработчика что не осилил в срок», а если проблем оказалось меньше чем планировалось — «не ожидали, ругаем разработчика что можно было еще больше утрамбовать, а мы и не знали». Вам не кажется такой подход немного нелогичным?
Понятия «честно/нечестно» для бизнеса как-то не очень, а вот если заменить на выгодно/не выгодно…
КМК, Вы настолько сильно привязались к способу оплаты по часам — что не можете выйти за рамки и увидеть другие решения. Попробуйте представить что в магазине Вам продают молоко исходя из длительности процесса по его изготовлению. Или зубной врач Вам лечит зуб и берёт оплату не за сам факт излечения (удаления, установки пломбы,...), а пропорционально длительности лечения. За часы берут там, где есть стандартные работы, которые нормированы и их длительность подтверждена «владельцем процесса». Для примера — сервисные центры автомобильных производителей: там есть нормо-часы, и по ним оценивается работа.
А как правильнее оценивать?
Не знаю как «правильнее», ибо в таком случае нам придётся давать определение правильности. Нужно разделить оценку стоимости наружу (для клиента) и внутри — вознаграждение сотруднику.
Стоимость наружу — это маркетинг и продажи, за сколько Вы сможете убедить заказчика купить Ваше решение — за столько и продавайте, ведь он покупает не часы — он покупает дополнительный функционал в своей информационной системе, который позволит ему тем или иным образом повысить эффективность своих бизнес-процессов. Возможно Ваше решение поможет ему заработать дополнительные 10млн.рублей прибыли в год, а стоить для него оно будет всего 100 тыс.рублей.
Оценка внутри — это вопрос соответствия Ваших ожиданий от сотрудника. Можно оценивать выполнение задач — соответствие фактического выполнения планам (кол-во задач, сроки выполнения). Можно оценивать результаты работы — соответствие реализованного функционала техническому заданию. Можно получить от заказчика обратную связь по реализованному проекту/задаче и это тоже использовать в качестве оценки результата работы сотрудника. Можно включить в процедуру оценку и менеджера по продажам, который обращается к программисту в ходе взаимодействия с заказчиком. В компании, где я работал одно время — бэкенд (поддержка продаж) состоял из инженеров и программистов. Их з/п зависела от их квалификации (оклад + ежемесячная/квартальная премия). Программист/инженер — не продавец, в первую очередь он обеспечивает выполнение задачи качественным образом. Если менеджер не смог продать решение, то это вина менеджера и «страдать» должен он.
Стоимость наружу — это маркетинг и продажи, за сколько Вы сможете убедить заказчика купить Ваше решение — за столько и продавайте, ведь он покупает не часы — он покупает дополнительный функционал в своей информационной системе, который позволит ему тем или иным образом повысить эффективность своих бизнес-процессов. Возможно Ваше решение поможет ему заработать дополнительные 10млн.рублей прибыли в год, а стоить для него оно будет всего 100 тыс.рублей.
Оценка внутри — это вопрос соответствия Ваших ожиданий от сотрудника. Можно оценивать выполнение задач — соответствие фактического выполнения планам (кол-во задач, сроки выполнения). Можно оценивать результаты работы — соответствие реализованного функционала техническому заданию. Можно получить от заказчика обратную связь по реализованному проекту/задаче и это тоже использовать в качестве оценки результата работы сотрудника. Можно включить в процедуру оценку и менеджера по продажам, который обращается к программисту в ходе взаимодействия с заказчиком. В компании, где я работал одно время — бэкенд (поддержка продаж) состоял из инженеров и программистов. Их з/п зависела от их квалификации (оклад + ежемесячная/квартальная премия). Программист/инженер — не продавец, в первую очередь он обеспечивает выполнение задачи качественным образом. Если менеджер не смог продать решение, то это вина менеджера и «страдать» должен он.
Заказчик обычно спрашивать «сколько стоит», «из чего сложилась стоимость» и «почему так дорого».
Определив «стоимость наружу», как вы ему это обоснуете?
Определив «стоимость наружу», как вы ему это обоснуете?
Во именно в этом и заключается работа менеджера по продажам. Например, я бы (в роли менеджера по продажам) попробовал сравнить стоимость разработанного функционала со стоимостью системы навигации или системы климат-контроля для его автомобиля. Ведь заказчик покупая дополнительный функционал для автомобиля не спрашивает у производителя авто — из чего сложилась стоимость климат-контроля, системы навигации, системы автоматической парковки, задней камеры. Я понимаю что за прошедшие годы так сложилось что всё время продавали часы, и даже заказчики стали «думать часами».
Вероятно, так сложилось из-за того, что оценка стоимости по трудозатратам (часам) немного более поянтна и обоснуема, чем «по ценности для заказчика».
Ну вот «благодаря» этому и пришли к тому, что имеем. Только ценности продаются успешнее и с большей маржинальностью.
Продавать надо не часы, а решения.
Часто встречающийся пример: дополнение какой-то типовой печатной формы несколькими колонками или полями.
Как вы её оцените?
Как вы её оцените?
Да в таком случае Вам уже давно надо было прайс-лист на все типовые задачи (доработки) сделать, и всем клиентам сразу после инсталляции вручать, чтобы и Вам мозги не парили, и Вы себя калькуляциями на каждый чих не мучили.
А колькуляция сильно зависит от того, что именно нужно вывести.
Где-то это просто реквизит текущего документа, а где-то нужно сделать выборку каких-то доп. данных.
Поэтому нельзя сделать прайс «добавление одной колонки» — 1000 руб.
Где-то это просто реквизит текущего документа, а где-то нужно сделать выборку каких-то доп. данных.
Поэтому нельзя сделать прайс «добавление одной колонки» — 1000 руб.
Определив «стоимость наружу», как вы ему это обоснуете?
«Оно столько стоит», «Сложившаяся стоимость на рынке». Блин, уже выше же привели пример — вы молоко/хлеб покупаете только выяснив, сколько времени потратили все участники на произ-во?
Молоко и хлеб — это массовые продукты.
А многие доработки дл каждого клиента свои.
Как в таком случае убеждать, что это именно «Сложившаяся стоимость на рынке»?
А многие доработки дл каждого клиента свои.
Как в таком случае убеждать, что это именно «Сложившаяся стоимость на рынке»?
В таком случае — решение, не имеющее аналогов. У продавца нет необходимости _обосновывать_ цену. Он конкурирует с другими продавцами. И все. Если спрос на товар неэластичный, то еще и диктует прямым образом цену покупателю. Если наоборот, но конкурентов нет, то падает до _приемлемого_ спроса (а не до какой-то обоснованный цены). В Сахаре мороженное будет стоить дорого вовсе не потому, что в него бриллиантов накрошили.
в 1С как раз множество типовых мелких задач, по которым ценность для клиента только одна — дешевле.
Предложите клиенту абонемент — ежемесячная плата за возможность доработок. Вы получите стабильный ежемесячный доход и возможность загрузить отдел поддержки продаж (программисты+инженеры) в периоды «застоя». Клиент получит ценность в виде возможности обратится несколько раз в месяц за получением решения по возникшей задаче. Создайте прайс-лист на типовые задачи и посчитайте сумму абонемента.
Там даже подписку ИТС не хотят покупать, которая нужна для обновлений, а вы про абонентку на задачи. Многие хотят просто разово заплатить за какую-то задачу и всё.
а вот про ИТС я хорошего не скажу. Тот факт, что из-за частых изенений законодательства 1С подсадила всех клиентов на ИТС, к-рые еще и включает часто безграмотных спец-тов франчайзи, во многом дискредитировал идею подписки.
Да еще и нынешние веяния той же Jet Brains — «продукты мы продавать не будем, вам же нужен сервис. А если вам не нужен наш сервис (впаривание услуги), нам не нужны вы». В общем, есть у клиентов реальные причины подозрительно относиться к идеи услуги.
Да еще и нынешние веяния той же Jet Brains — «продукты мы продавать не будем, вам же нужен сервис. А если вам не нужен наш сервис (впаривание услуги), нам не нужны вы». В общем, есть у клиентов реальные причины подозрительно относиться к идеи услуги.
ИТС, да, пример не показательный.
Абонентка иногда имеет место быть.
Но, даже и при ней, возникают вопросы об объёмах задач — «А почему эта задача такая большая, мы думали ещё и другие в этом месяце сделать, а время уже закончилось...».
Абонентка иногда имеет место быть.
Но, даже и при ней, возникают вопросы об объёмах задач — «А почему эта задача такая большая, мы думали ещё и другие в этом месяце сделать, а время уже закончилось...».
Ну, если вы будете ошибаться каждый раз при оценке в Х раз, клиент просто перестанет вам доверять. Тут дело не в стр-ре цены, а просто его вере в ваш профессионализм. Либо ему придется брать ваши риски на себя (то есть закладывать всегда в Х раз больше, чем сказали вы). В случае 2х юр лиц это уже сложно, проще найти более точного или осторожного.
Скупой платит дважды. Такие клиенты точно не моя целевая группа.
P.S. я не про ИТС если что.
P.S. я не про ИТС если что.
А как же оценка стоимости по функциональным точкам?
Т.е. даете оценку количества функциональных точек, даете на её основе оценку стоимости.
После выполнения работ подтверждаете реализацию задачи за отведенное количество точек. Если сделали больше, постараться уговорить заказчика оплатить доп работы, если меньше либо предложить доработку другого куска кода, либо сделать скидку.
Или к доработке это не применимо?
Т.е. даете оценку количества функциональных точек, даете на её основе оценку стоимости.
После выполнения работ подтверждаете реализацию задачи за отведенное количество точек. Если сделали больше, постараться уговорить заказчика оплатить доп работы, если меньше либо предложить доработку другого куска кода, либо сделать скидку.
Или к доработке это не применимо?
Думаю, такое малоприменимо.
Почему? При использовании функциональных точек как раз присутствует исключение таких факторов как:
— квалификация исполнителя
— состав группы, и это может быть хоть 1 человек, хоть 20 человек
— количество требуемого кода (если кто-то использует такую меру)
Получается более универсально и заказчик и разработчик делают то, о чем договорились. Да время еще будет иметь значение, но при составлении соглашения его можно только ограничить т.е. если пройдет 10 дней, будем считать пени, но конкретно на стоимость оно влиять не будет.
Ну или может, но только в части: «успеете за один день, получите +20%»
— квалификация исполнителя
— состав группы, и это может быть хоть 1 человек, хоть 20 человек
— количество требуемого кода (если кто-то использует такую меру)
Получается более универсально и заказчик и разработчик делают то, о чем договорились. Да время еще будет иметь значение, но при составлении соглашения его можно только ограничить т.е. если пройдет 10 дней, будем считать пени, но конкретно на стоимость оно влиять не будет.
Ну или может, но только в части: «успеете за один день, получите +20%»
А как насчет того чтобы оценивать "сколько эта доработка принесёт бизнесу?"
Подключение кассы к егаис сэкономит 10 тыс штрафа- берем 8 тыс за 5 минут работы и спим спокойно.
Заполненные два поля спасут бухгалтеру 5 минут работы в год? — так мы еще клиенту доплатить должны за то, что бухгалтера оторвали от работы пока обновление ставили.
Это хороший подход, но чтобы убедить в этом заказчика — вы должны будете понять как работает его бизнес и правильно ли рассчитаете этот экономический эффект. Но если рассчитаете правильно и заказчик тоже это увидит, то сможете и продать дороже чем просто за часы. Об этом чуть выше я и писал, продавать нужно ценности, а не часы.
вы забываете, что есть другая сторона: клиент стремится снизить оплату
поэтому даже если ваша доработку принесет/сэкономит клиенту миллион, и вы предлагаете сделать её, скажем, за полмиллиона (а внутренние затраты на это будут 100 тысяч) — то может найтись другой человек, который предложил сделать эту же доработку за 200 тысяч, и сам оставшись с прибылью, и клиента сильно не ободрав
поэтому даже если ваша доработку принесет/сэкономит клиенту миллион, и вы предлагаете сделать её, скажем, за полмиллиона (а внутренние затраты на это будут 100 тысяч) — то может найтись другой человек, который предложил сделать эту же доработку за 200 тысяч, и сам оставшись с прибылью, и клиента сильно не ободрав
вот как раз кривая спроса и предложения. Обратите внимание, в вашем возражение часы трудозатрат не упомянуты ни разу
Конкуренция неизбежна, нужно либо снижать цену, уходить в другой сегмент клиентов (премиальный/средний+) или добавлять в свой «продукт» дополнительные фишки, которых нет у конкурента (гарантия на решение N-месяцев, скидка на следующий заказ, .....). Это опять же маркетинг, молоко «Домик в деревне» стоит дороже конкурентов, но его тоже покупают.
Когда оценка известна заранее, есть и цель, и мотив к повышению эффективности и ее применению.
ДеМарко в человеческом факторе доказал обратное и доказал насколько это плохо.
Оценить время затраченное на задачу для конкретного специалиста — не возможно.
Одну и ту же задачу конкретный человек может решать с разбросом до 4 часов (сам видел).
Тут как в квантовой физике измерение (наблюдатель) оказывает влияние на результат.
Одну и ту же задачу конкретный человек может решать с разбросом до 4 часов (сам видел).
Тут как в квантовой физике измерение (наблюдатель) оказывает влияние на результат.
Сегментация задач и статистика по выполненным проектам/задачам. Если задачу ранее не выполняли и даже в гугле нет — то это проект с плановой оценкой и закладанием рисков по времени и другим ресурсам.
| Спросите какого-нибудь опытного специалиста, как он оценивает работы. Просто смотрит на задачу, и называет оценку.
Разные специалисты, с одинаковым стажем работы и одним грейдом, называет свою оценку, которая может расходиться вдвое.
Например, два сеньора могут видеть одну и ту же задачу и называть сроки, в которые он уложится. Один за 6 часов, второй за 10-15 часов. Вроде оба сеньора, у обоих одинаковая зарплата и опыт работы, но видят задачу по-разному. Но оба могут с задачей справиться быстрее\медленнее. Сложно определить.
Считаю что оплата за труд программиста должна зависеть от нужд бизнеса.
Например, есть задача создавать каждую неделю отчет в один клик. У менеджера\бухгалтера создание этого отчета занимало час рабочего времени, и стоил этот час, допустим 500р. За год это 24000р. Двум сеньорам подкинули задачку. Первый сделает за 20 часа, второй за 40 часов. У обоих з\п одинаковая, допустим 1000\ч. Думаю, во втором случае, вы задумаетесь, а нужен ли будет этот отчет через год.
Разные специалисты, с одинаковым стажем работы и одним грейдом, называет свою оценку, которая может расходиться вдвое.
Например, два сеньора могут видеть одну и ту же задачу и называть сроки, в которые он уложится. Один за 6 часов, второй за 10-15 часов. Вроде оба сеньора, у обоих одинаковая зарплата и опыт работы, но видят задачу по-разному. Но оба могут с задачей справиться быстрее\медленнее. Сложно определить.
Считаю что оплата за труд программиста должна зависеть от нужд бизнеса.
Например, есть задача создавать каждую неделю отчет в один клик. У менеджера\бухгалтера создание этого отчета занимало час рабочего времени, и стоил этот час, допустим 500р. За год это 24000р. Двум сеньорам подкинули задачку. Первый сделает за 20 часа, второй за 40 часов. У обоих з\п одинаковая, допустим 1000\ч. Думаю, во втором случае, вы задумаетесь, а нужен ли будет этот отчет через год.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Грани честности и Джон Доу