Разбираем кейс: как оценить задачу от клиента, сколько выставить денег и кто платит за перерасход
Negligence-2: продолжение с ответами
Разбираем кейс: как оценить задачу от клиента, сколько выставить денег и кто платит за перерасход
Фото с сайта: deviantart

На днях был пост, вызвавший кучу комментов со здравыми мыслями. Теперь наша версия. Подсчитаем убытки баллы.

ВОПРОС № 1: сколько выставлять денег

Тут все просто, но зависит от того, как вы договорились с клиентом. Два варианта:

Первый вариант — почасовая ставка. Если вы работаете с клиентом на почасовой ставке, все риски на себя берет клиент. Вы говорите предварительную оценку, выставляете авансовый счет. Если начинаете не укладываться — предупреждаете клиента, а он уже решает, продолжать ли работы. Так работает, вероятно, большинство служб технической поддержки.

Ваша ответственность минимальная и, скорее всего, «правильный» ответ — 8 часов. Если вы ответили 4 часа — у вас будут проблемы. Всегда лучше успеть чуть-чуть раньше сделать (клиент будет доволен), чем передвигать сроки (все будут недовольны). 12,56 выдает в вас опытного ПМ-а, знающего про число ПИ (впрочем, ответ мог быть и 10,7 часа, иногда можно применять число e ;-)).

Вариант второй — сдельно (FIX). Если договорились на фиксированный объем работ — у вас больше ответственность и риски. За это надо брать деньги, это честно.

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

8 часов говорят о том, что вы оптимист. 12,56 — реалист. 4 часа — вон из профессии.

ВОПРОС № 2: стоит ли договариваться на почасовую оплату

Существует множество ситуаций, когда клиенту выгодно иметь почасовую оплату или когда это единственно возможный путь:

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

Мне нравится ответ 1 (почасовая оплата, списать фактически потраченное время — 6 часов). Но ответ «8 часов при любом раскладе» — тоже не плох, так как это может покрыть в будущем риски, а в 6 часов может не входить менеджерская работа и всякие бухгалтерские издержки.

Ответ 2 — спрятать 2 часа, но в случае перерасхода начать выставлять перерасход клиенту — несколько неадекватно, но иногда применяется.

ВОПРОС № 3: За чей счет будем работать

Итак, ключевой для всей ситуации вопрос: «Является ли ошибка в оценке программиста халатностью». И тут все не так просто. Когда я прошу сообщить разработчика то время, которое он планирует затратить на задачу, я по сути прошу его предсказать будущее.

Да, оценка базируется на его опыте. Но в разработке ПО очень мало задач, которые повторяются из проекта в проект без изменений. Если такие есть — то их давно пора автоматизировать. Для программиста почти каждый проект — это решение полностью новой задачи. Это происходит потому, что решать задачу старым способом — не всегда оптимально, а новым способом — непрогнозируемо по времени.

Поэтому оценка на основе предыдущего опыта:

  1. будет заведомо неточной;
  2. ничего не гарантирует.

Хитрые менеджеры научились в большинстве случаев преодолевать эту ситуацию. Зарезая творчество на корню и склоняя в сторону решения бизнес-задач. Закладывая буферы время и деньги, умножая оценки программистов на коэффициент жадности и невезучести или ведя статистику и вычисляя среднюю реальную производительность конкретного программиста.

Таким образом, в работе по фиксированной стоимости, если риски заложены, то их берет на себя сторона-разработчик. В работе за фиксированную стоимость — мой выбор 2 — устранить проблему за свой счет.

Естественно, брать на себя риски, связанные с потерей «потенциальной прибыли» на стороне клиента из-за ошибки в ПО — это отдельная договоренность. И со стороны разработчика было бы глупо под такое подписываться, не имея дополнительных финансовых плюшек и рычагов влияния на клиента. Никто еще никогда не сказал, что он потерял «чуть-чуть денег» из-за чужой ошибки ;-).

Тем не менее, есть сферы, в которых вариант «полной компенсации» 4 может быть прописан в контракте. В этому случае ценник должен быть в разы выше. Та сторона, которая берет на себя риски, должна получать за это деньги. Это справедливо.

Я слышал, что вариант 3 (исправить за счет личного времени разработчиков) практикуется в некоторых компаниях. Лично я категорически против — в долгосрочной перспективе овертаймы могут здорово деморализовать команду. Я люблю людей, рядом с которыми каждый день работаю, чуть больше. Извините ;-).

Прятаться, теряться — ответ 5 — какой-то совсем уж стремный выбор.

Если же проблема с халатностью у разработчика — системная, и ничего не помогает (обучение, тестирование, контроль и т.п.) — честнее с ним расстаться.


Самый сложный случай, когда между разработчиком и клиентом есть договоренность о работе по часам (Time+Material). Клиент может продавить минимальную почасовую ставку, взяв риски на себя (дав понять, что он понимает риски). Но если/когда риск сработает — отказать оплачивать дополнительное время. Доводы будут ОЧЕНЬ рациональные:

  • почему я должен платить за ваши ошибки? вам выгодно делать ошибки, потому, что я за них плачу! мы не просили вас сделать эту ошибку, почему мы должны за нее платить??
  • мы считали, что вы — профессионалы и вы все предусмотрите.
  • ошибка — или наша, или ваша. Мы никак не могли повлиять на ваши ошибки, т.к. ничего не понимаем в программировании. Поэтому ошибка — ваша, и отвечаете за нее тоже вы.
  • нас не волнует, что ошибка была в каком-то стороннем бесплатном ПО! Это ПО поставили ВЫ, и поэтому вы несете финансовую ответственность за ваше решение. Вы профессионалы, и вы должны были предусмотреть и предупредить нас!
  • я вас нанял, чтобы вы решали мои проблемы. А не создавали новые.
  • я вас нанял за те знания, которые вы знаете. А не за то, что вы не знаете.
  • если я найму маляра за 20 $ в час, и он прольет мне краску на ковер — он по-любому у меня этот ковер купит. Даже если этот ковер стоит 200 $, а он заработал за 3 часа 60 $. Тут — то же самое!

Эти доводы, конечно, звучат разумно. Но и ПО без ошибок — увы, почти не бывает. Особенно если клиент настаивает на «по-быстренькому» и «подешевше». Общего решения, похоже, нет. Только переговоры.

Разрабочики ПО/сайтов должны иметь эти доводы в виду. Особенно, работая с проектом, код которого они унаследовали. И предвидеть такие варианты поведения клиента заранее. А так же фиксировать степень ответственности в контрактах. И чем выше эта ответственность, тем дороже ее нужно продавать.