Я, где-то с 2005 года, с перерывами, работаю в компаниях, которые решают задачи за деньги. Ну это когда клиент приходит, просит чего-то ему запрограммировать, мы делаем, и он нам платит. Там есть и проекты, но в тексте – только про разовые задачи. Да, это про 1С. Не про какую-то конкретную компанию – проблема одна для всех, нигде ее не решили нормально.
Так вот, самая скользкая тема в нашей работе – оценка трудоемкости задач. И гадость в том, что, какую бы оценку мы не давали, она будет казаться нечестной.
Вся гадость кроется в сути работы программиста 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 часов. Магия, не иначе.
Оценка по Джону Доу, конечно, тоже не честная. Как и любая другая. Просто поймите, примите и используйте: честных оценок не бывает. Вообще.
Оценка – это инструмент, которым можно пользоваться, достигая разных целей.
Для менеджера оценка – это способ получить клиента. Или привязать клиента. Или переманить клиента. Или заработать денег. Или заработать больше денег. Или раскрутить клиента.
Для специалиста оценка – это цель, мотив для роста квалификации, причем – разносторонней. И программировать быстро, и вникать в незнакомые конфигурации и механизмы, и общаться с клиентом, и спрашивать помощи, и получать ее, и использовать чужие решения.
Для компании оценка – это инструмент управления. Понятный, прозрачный, элемент системы мотивации. Он позволяет управлять, не управляя.
Краткое содержание
Честной оценки стоимости решения задачи не бывает.
Любая оценка зависит от контекста.
Контекст включает специалиста, который решает задачу, менеджера, который ее продает, клиента, который за нее платит, конкретного представителя клиента, который должен оценку согласовывать, и т.д.
Предварительная оценка может быть ошибочной, т.к. в нее заложены риски.
Оценка по факту может быть ошибочной, т.к. не известно, с какой скоростью движется исполнитель — реальной или «чтоб подольше просидеть».
Нормирование — вообще невозможно.
Наиболее перспективной кажется оценка по Джону Доу — сколько эту задачу решал бы средний программист.
Получается всё-таки предварительная оценка, но не по конкретному специалисту, а по вымышленному среднему.
Стажеру есть куда стремиться — он работает хуже, чем Джон Доу.
Опытному есть куда стремиться — он работает лучше, чем Джон Доу.
Когда оценка известна заранее, есть и цель, и мотив к повышению эффективности и ее применению.
прочитал бы все , но некоторые слова вызвали отвращение
вообще цензура существует в мире инфостарта ?
(1) исправил, перечитывайте.
(2)
спасибо.начало интересное и тема также
спасибо за понимание
Особенно, если увидит фотографию рабочего дня*****************
да это будет шок , даже если увидит лютого программиста 🙂
Оценка по факту — есть желающие на такой сюрприз ?
что-то не очень хочется…..
«я и так купил вашу программу, почему я должен еще за что-то платить?»
аргумент еще тот 🙂 ******************************
прожект на 2000 часов …..я понимаю , что ваш уровень выше Джона Доу.
********************************************************************************************
а Бог знает все…Он сотворил человека и дал ему ум…и право выбора , которые мы не всегда используем правильно…к сожалению.
*******************************************************************************************
интересная статья.
Ну почему же? Есть честная оценка труда. И она самая точная.
Я ставлю задачу программисту, он ее делает, например, за 8 рабочих часов.
Далее, я прошу решить ту же задачу, но повторно.
Он ее делает за 45 минут.
Результат: на решение такой-то задачи необходимо 45 минут.
Получается, конь в вакууме, но это реальная оценка.))
Разумно написано и разложено по полочкам. Но нет упоминаний об управлении рисками. А оно предполагает еще 10-30% накидывать к оценке по времени.
(5) в первом случае специалист потратил время на изучение..
во втором случае ему тратить не пришлось он уже знал куда и что писать…
А зачем опытному специалисту делать 6 часовую задачу за 6 часов если ее можно продать за 8 ? он в данном случае так же как и вы продает свое время.
Бизнес живёт своей жизнью, а программист своей.
Статья поднимает интересные вопросы. Например привлекательность профессии по Эйнштейну.
Если программист сидит с чашкой кофе рядом с красивой девушкой-клиентом, то его биологические часы идут в обратную сторону, а если с неприятным субъектом — то со значительным ускорением.
Выходишь от клиента через два часа с чувством что постарел на 10 лет. Какой секундомер клиента это зафиксирует?
И какое отношение это имеет к опыту программиста или к оценке задачи?
Например, у нас есть правовая база данных Гарант, Консультант Плюс и т.д. Есть ли такая база для других стран? Наверняка есть. Сможет ли клиент ею воспользоваться без программиста как переводчика с французского? Если нет, то что он вообще делает в бизнесе.
Честная оценка — это когда клиент согласен получить нужный ему результат через N дней и будет стоить ему М рублей.
С другой стороны, исполнитель-программист согласен выполнить и сдать заказчику эту работу через N дней и получить K рублей.
Это согласие и есть честность.
Сколько там было внутри часов совершенно сторонам сделки не интересно, я считаю. Дурацкая идея с часами, не знаю почему она родилась.
(5)
это если программист у вас в штате,
только зачем делать одну работу два раза ?
или это теория ?
вы так делали ?
(5) Пациент у зубного врача
— Сколько стоит вырвать зуб?
— 100 долларов
— Так много за 1 минуту работы?!
— Если хотите, я могу час его вырывать!
(11) это практика. Так приходилось пояснять своим коллегам о стоимости их работы. Это было, отдаленно, некой мотивацией на развитие — ты работаешь 8 часов, тебе заплатят, как за n — часов (по акту). Либо ты выполнишь работу за 1 час и получишь те же n-часов. Эта практика не самая хорошая, даже наоборот, но как есть.
(13)
есть же разный уровень программистов и сложность работы.
(5) решить второй раз одну и ту же задачу — через неделю — да, будет 45 мин, а через 2 года? я думаю с наработками, которые надо найти , вспомнить механизм, может и 2 ч….
(6) когда в команде, риски увеличиваются в зависимости от кол-ва участников…
(9) Анна, ничего не понял — можете по-простому мысль изложить?
(10) иногда сам не знаешь, за сколько сделаешь, а оценку дать и сроки озвучить надо….
вот как тут оценить?
(17) Есть клиенты, которые приглашают программиста решить конкретную задачу.
А бывает программист, у которого есть определенный круг общения, ряд его клиентов, но он в силу загруженности не успевает следить за новинками в 1с, что снижает его рыночную стоимость и создаёт реальную угрозу потерять клиентов.
И тогда один из клиентов оплачивает специалистов, оборудование и т.п. для того, чтобы их программист подтянул свои навыки и осчастливил этим других клиентов своего круга.
Стоимость услуг специалистов на такие разовые бесперспективные работы на чужом рынке выше, чем новичка в процессе освоения и наработки клиентской базы.
Как определить намерения клиентов до начала работ? Например, когда в штате программист уже есть.
(18) Говоришь клиенту, что для оценки возможности выполнения задачи и определения адекватной стоимости требуется провести подготовительные работы… ну как аналог диагностики в ремонтных мастерских (а там ещё кроме стоимости работ ещё возможно требуется стоимость запчастей, и разброс по сумме может быть огромный, менять прокладку за 10 копеек или двигатель за XXX.000 рублей)
Нормальные люди обычно договариваются, неадекваты отсеиваются.
(12)
а что будет делать зубной врач целый час ?
рассказывать забавные истории или ждать , когда подействует обезбаливающее и приниматься за работу
обычно люди со стороны не ценят работы других, если за нее надо платить…не знают о временных и финансовых затратах исполняющей стороны.
(10) ну по идее, когда тебе нужно в квартире ремонт сделать, то естественно, оговариваешь общий срок (срок роекта) и сумму. Все, по идее, сколько каждый специалист (сантехник, маляр, плиточник, штукатур и т.п.) отработал — дело бригадира (РП).
Любая оценка — есть угадывание.
Ты можешь угадать или нет.
Проще угадать, когда сам будешь исполнителем, труднее — когда исполнителями будут другие.
Чем больше ты умеешь придумать потенциальных правдоподобных сложностей и подводных камней до озвучивания оценки заказчику, тем лучше сможешь затраховаться. По факту ты не попадешь на ЭТИ камни, но попадешь на другие. Но у тебя будет страховка и уложишься в срок.
Когда ты начинаешь озвучивать сложности уже во время выполнения задачи, то это показывает твою некомпетентность. И с тобой уже мало хочется иметь дело.
(19) если у них есть свои 1с-ники, то лучше не браться вам за работу для них…их 1с-ник перехватит инициативу, и вам не заплатят.
(20) иногда не знаешь, за сколько сделаешь, а оценивать некогда — бывает по три проекта оцениваешь в неделю — и ничего не сделал и не заработал — а клиенты с новыми проектами сливаются…поэтому иногда оценка с неба необходима….
или ожидания не оправдались — простую работу делал весь день — клиент не виноват, обстоятельства так сложились…. выкатывать полную стоимость — значит сказать клиенту «До свидания!»
1. Текст не структурирован. Т.е. половину текста о том, как может быть и кто тут будет обделен, а потом вывод о том, что всегда кто-то будет обделен.
2. Ну и 6 часов против 8-ми — это какая такая контора так работает? Зачем клиенту вообще говорить, что получилось 6 часов? Да ему плевать — он готов заплатить за 8, ему важен результат. Если у конторы такие мелочные клиенты, то есть шанс такой конторе вообще сдохнуть в ближайшее время.
3. Или автор не знает (в чем я сомневаюсь), или намеренно умолчал о SCRUM и покере планирования для задач спринта, где на первом шаге идет слепая оценка задачи всеми разработчиками, на втором — открытие цифр, а на третьем интервьюирование тех, кто сильно не сошелся с трендом (мало ли они знают что-то, что другие не приняли во внимание). Этот механизм позволяет достаточно «честно» и «объективно» оценить задачу, приведя аргументы на этот счет в случае, если оценка отдельных членов команды отличается от «в среднем по больнице».
(26) если я правильно поняла, речь идёт в статье команде с количеством разработчиков = 1. Аналитики, руководители и пользователи в покере планирования не участвуют, поскольку покер это именно «я сделаю это за 8/6 часов» и все это уже после того, как пользователи, руководитель и аналитики все что можно найти нашли и все что можно купить посмотрели и сказали что нужен разработчик.
Соответственно, и покер планирования не работает.
(27)
Просто контора работает по принципу инцидентов с SLA типа 24 часа, которые рулятся не в команду разработчиков, а первому свободному. Т.е. там нет гибкого подхода, поэтому данная схема в принципе нежизнеспособна для сколь-угодно серьезного подхода к причинению весомого добра клиентам. Фактически организация на нулевой-первой стадии зрелости процессов по .
И даже если что-то и фиксируется, то на основании этой фиксации не делается никаких выводов. Нет процесса ретроспективы…
Спрос и предложение… На то и рынок существует. Можно придумать много вариантов оценки и способов выполнения работ. Как только появляется сбалансированный вариант, всегда находятся хитрые участники, способные сделать меньше за больше денег.
(21) Думаю в данном контексте, он будет именно час тянуть зуб. И без обезболивающего. Пошатал, подёргал, передохнул, снова взялся. А когда капризный клиент уже потеряет сознание от болевого шока, тогда можно и за две минуты выдернуть.
(30)
а сколько времени работал бы вообще этот врач, если его можно так назвать ?
не хотел бы я обращаться к вам , если вы так мыслите.
(23) Когда ты начинаешь озвучивать сложности уже во время выполнения задачи, то это показывает твою КОМПЕТЕНТНОСТЬ.
Потому что дилетант трудностей не видит. Прочитайте про Эффект Даннинга — Крюгера.
(31) Вообще-то человек анекдот рассказал. Вы проявили отсутствие чувства юмора, я попытался исправить ситуацию, а вы навесили на меня ярлык и сложили мнение обо мне как о специалисте. Позволю себе сделать вывод, что вы просто троллите.
(33)
да ладно…
будете договариваться с заказчиком
а потом он вам скажет , я пошутил , так подходит ?
или я попал на квартал-95 ….
да что-вы , я же пошутил , а вы приняли всерьез….
я думаю здесь форум об 1с , а не смешарики играют.
(33)
чувство юмора это когда с вами «пошутили»
а вы хотите еще
что бы вам так сделали
не вы — а вам …
вы о каком чувстве говорите ?
(33)
Тро́ллинг — форма социальной провокации или издевательства в сетевом общении, использующаяся как персонифицированными участниками, заинтересованными в большей узнаваемости, публичности, эпатаже, так и анонимными пользователями без возможности их идентификации
в чем с моей стороны есть такие действия ?
(36) подумайте над этим
(32) возможно мы имеем ввиду разное.
Я под трудностями в данном случае понимаю факторы, которые незапланированно добавляют трудоемкость и на которые приходится тратить часы, которые ты в оценку не заложил.
Часто это детали, о которых ты узнаешь только в процессе выполнения задачи, но о которых заказчик не мог тебе сообщить заранее, т.к. не является техническим специалистом.
А компетентность — это когда ты обозначил срок и укладывваешься в него, не смотря на такие трудности, которые возникают почти в каждом проекте.
При этом ты четко понимаешь, что средний специалист по факту потратит не меньше времени, чем ты оценил
(18) Разбивать проект на этапы — обрисовываем первый этап, что в него будет входить, делаем примерную оценку, все остальные этапы описываем и оцениваем по завершению или в процессе реализации предшествующего, это в случае, если нет возможности охватить и оценить весь проект целиком — в этом случае риски минимальны и для заказчика и для исполнителя — для заказчика тем, что он не потратит все деньги на проект сразу и по результату первого этапа поймет на сколько хорош исполнитель в деле; а для исполнителя тем, что у него не будет необходимости тратить время и силы на оценку всего проекта сразу и в процессе реализации первого этапа поймет насколько заказчик адекватен и платежеспособен
(38) контора работает по SLA вся или только дежурный отдела автоматизации?
Если программисту в час ночи требуется принять решение по алгоритму А или Б он как правило реализует оба варианта и добавляет константу выбор пользователя. Даже если понимает что один из них никогда не будет востребован.
Программист обычно не звонит уточнить как надо, чтобы не тратить лишнее время. А жаль.
Поэтому удобно когда рядом с разработчиком сидит сотрудник с телефоном и выясняет срочные нюансы, а есть у него секундомер или нет это мелочи, на результат не влияющие.
Вот и получается что 8-6 два часа впустую.
Работу более-менее опытного программиста можно вполне оплачивать по фактическим часам, как работу хорошего юриста или врача. Если задача известная и понятная, он и так сделает ее в нормальном темпе, без оценок. А различие уже идет по стоимости часа того или иного специалиста, как-то так.
В статье не упомянута ситуация, с которой я очень часто сталкиваюсь, когда на решение задачи уходит 1 час а на выяснение всех нюансов и «подводных камней» 10 часов — т.к. в 90% случаев техническое задание отсутствует как таковое или очень абстрактное. И что бы решить задачу надо сделать 100 звонков, написать 100 бумажек — отдельная тема выбить тестовую базу т.к. на демо базе все работает а у заказчика выходит ошибка.
(5) Это работает только если задача один в один повторяет такую же. Но в реальности такое большая редкость. Всегда есть нюансы, которые все меняют и увеличивают (или уменьшают) стоимость разработки.
Даже банальная печатная форма может быть написана по-разному на одной и той же конфигурации. К примеру если сама конфигурация изменилась и старые данные стали недоступны. Базу разделили и теперь надо делать com-содинение, чтобы получить данные для печатной формы (утрированный пример, но возможный)
И даже если задачи одинаковы это не меняет сути конфликта работы специалиста и стажера.
(42) а в крупных госконторах 2 недели
(33) Если почитать его комментарии, то у него всегда так тяжело доходит.
(38) Да, не уловил вашу мысль. Вы имели ввиду, что оценить задачу достаточно низко, а потом рассказывать заказчику о всё новых и новых проблемах которые внезапно всплывают, и повышать оценку — не компетентно.
С этим, да, полностью согласен!
В наших автосервисах есть свой джондоу под названием нормо-час. Например, снять-установить коробку это 4 нормо-часа. Стажер сделает за 8 часов, крутой дока за 2, но клиент заплатит за стандартные 4 нормо-часа.
Все придумано до нас, Джон Доу избыточен.
(47) Если речь идет о типовых, стандартных, повторяющихся операциях, то нормо-часы конечно помогают, а если речь идет о проекте, который у каждого клиента индивидуален в силу особенностей его бизнеса или сферы, в которой он работает, то применить нормо-часы к такому проекту не получится до тех пор, пока он не будет разбит на небольшие участки, которые можно будет уже называть «типовыми операциями» и появится возможность присвоить каждому из них определенное кол-во нормо-часов, в противном случае оценка будет являться оценкой «пальцем в небо», которую применяют чтобы был хоть какой-то ограничитель по срокам (лучше что-то, чем ничего), ну и для того, чтобы не упустить клиента, ведь его не устроит ответ «хрен его знает», а платить за анализ и предварительное ТЗ многие клиенты не любят или не могут, как то так 🙂
(41) Обычно заказчику интересно сколько это будет стоить и в какой срок будет сделано, сколько фактически на это потратит время разработчик для него уже не столь важно, для него важны предложения на рынке по решению его проблем
Как я понял, в статье речь идет о небольших разовых работах.
На мой взгляд, оценка трудоемкости такого рода работ не критична ни для исполнителя, ни для заказчика. Не те деньги. С точки зрения масштабов бизнеса заказчика, те плюс минус пара-тройка тысяч рублей никакой роли не играют, с точки зрения программиста — исполнителя, если он прокидается на пару тройку часов, то никакой трагедии не случится и он не обеднеет.
Для заказчика — лучшая цена — это бесплатно. Наш человек больше всего на свете любит халяву. А исполнителя поджимает, то что он работает в рынке и вынужден отслеживать ценовые предложения конкурентов.
Еще у исполнителя есть возможность повторного использования своего кода и чужих разработок (например с Инфостарта), что может сщественно снизить трудоемкость. И у конкурентов могут быт под рукой такие же заготовки.
Поэтому здесь нужно заниматься лояльностью клиента не за счет цены, а за счет его удовлетворенностью взаимоотношениями с исполнителем. А чтобы степень удовлетворенности была высокая, надо плотно работать с ожиданиями заказчика. Он должен сам осознать, что «с деньгами нужно расставаться легко, без стонов».
(5)
а теперь берем и набиваем решение телеграфисткой и получается 10 минут.
«Можно сделать быстро, но плохо, а можно — медленно, но хорошо. Через некоторое время все забудут, что было быстро, но будут помнить, что было плохо. И наоборот.»
Сергей Королёв, конструктор
«Я могу сделать эту работу:
— быстро
— дешево
— качественно.
Выберите ДВА любых пункта.»
Народное
В действительности почасовая оценка это такая фикция. Клиенту вообще все равно — есть задача он готов платить определённые деньги. При этом за одну и ту же задачу разные клиенты готовы заплатить разные деньги, что зависит от лояльности, платежеспособности, актуальности, ожиданий.
Поэтому, как ни странно для обывателя, но в конторах про которые рассказывает топик стартер толковому разработчику делать нефиг — ценятся не качественные специалисты, а те, которые способны превратить пустяковую задачу в миллионный проект.
(5)Едрить, Вы «эффективный менеджер»!
Сколько времени уйдет выучить У лукоморья дуб зеленый?
2 часа.
А повторить?
3 минуты.
Вывод Выучить можно за 3 минуты.
Человек существует и свинья существует. Вывод Человек — свинья.