Как известно, Аристотель, стоявший у истоков всей современной науки, написал однажды, что у мухи 8 ног. Так все и думали, пока несколько столетий спустя не пересчитали.
Доказательство истинности методом сравнения авторитетности (сейчас это называется «пиписьками меряться») — самый худший способ доказательства.
Это уже моя проблема — учесть риски и добавить к оценке подушку. Это, собственно, классика. Заказчик получает уже итоговую — после учета рисков — оценку.
Суровая правда жизни состоит в том, что существуют методики оценки объемов работы и они дают вполне приемлемую точность (60-80%) для сработанной стабильной команды. К примеру, методика оценки Usecase points вполне подходит для того, чтобы показывать результаты оценки заказчику.
А если не оценивать, то лично мне вообще непонятно, как назначать цену.
А как это решает проблему? Может, Вы путаете с поэтапной оплатой по календарному плану?
В случае просто почасовой оплаты Вы в конце проекта даете Заказчику итоговую раскладку по часам и стоимости, он говорит «Не верю» и все вместе идете в Арбитраж с еще более мутными условиями.
С первым я не согласен — при правильно построенном взаимодействии Заказчик всегда осознает, что происходит, сколько осталось и каких денег будет стоить.
Но по второму пункту Вы правы — это никак не помогает, если Заказчик просто не хочет платить.
0. Избегать СБР и не передавать заказчику результаты работы до получения денег.
Именно так всегда и делаю: полноценное решение деплоится на собственной площадке и дается на «порулить» заказчику без доступа к исходникам. Нравится — платим и забираем. Не нравится — прощаемся.
За все время (примерно 8 лет использования этой методики) был 1 случай, когда заказчик сказал, что он хотел другое. Получил от меня контактный e-mail того, кто может предложить это «другое» и мирно расстались. И 1 случай, когда заказчик посмотрел и… пропал. :) В обоих случаях код был в течении года заюзан в других проектах.
… или, в стиле пожеланий этой статьи, заставим на каждый помидор лепить стикер «употребление помидоров может нанести вред вашему здоровью» и в СМИ проводить кампании по информированию населения о вреде помидор.
Не думаю, что акцию непосредственно организовывали японцы. С вероятностью 99.9% за конкретную реализацию в России отвечает персонал российского представительства.
Японцу после такого действительно пришлось бы сделать сеппуку. :)
Доказательство истинности методом сравнения авторитетности (сейчас это называется «пиписьками меряться») — самый худший способ доказательства.
Время прямого обращения по индексу не зависит от длины массива, соответственно это O(1).
А если не оценивать, то лично мне вообще непонятно, как назначать цену.
В случае просто почасовой оплаты Вы в конце проекта даете Заказчику итоговую раскладку по часам и стоимости, он говорит «Не верю» и все вместе идете в Арбитраж с еще более мутными условиями.
Но по второму пункту Вы правы — это никак не помогает, если Заказчик просто не хочет платить.
Что касается СБР, то я планировал воспользоваться этим сервисом, но в ТАКОМ виде он мне нафиг не сдался.
Именно так всегда и делаю: полноценное решение деплоится на собственной площадке и дается на «порулить» заказчику без доступа к исходникам. Нравится — платим и забираем. Не нравится — прощаемся.
За все время (примерно 8 лет использования этой методики) был 1 случай, когда заказчик сказал, что он хотел другое. Получил от меня контактный e-mail того, кто может предложить это «другое» и мирно расстались. И 1 случай, когда заказчик посмотрел и… пропал. :) В обоих случаях код был в течении года заюзан в других проектах.
И в 2009, и в 2011 — непременно на «Селигер-2010»? Интересная традиция.
Японцу после такого действительно пришлось бы сделать сеппуку. :)
Поскольку уже в этом случае руки постоянно лезут в кадр, если держать за корпус.