Беседа о вашей работе

[sukhanchik]

Цитата:

Сообщение от axtalk

Подкрепим примером. Нанимаем землекопателя (живой экскаватор). Задача: нужно выкопать яму/траншею объемом 2 куб. метра. Известно, что в среднем темпе работы средний человек выкапывает в «средней» почве за 1 день (9 часов) 3 кубических метра – это нормально. Условно средний норматив 1 кубический метр за 3 часа.

Пример не очень удачный. Предугадать наличие в земле плиты не сможет никто (ну разве только копатель уже конкретно в этом месте копал, что практически невозможно). При этом копатель может выполнить часть работы и уйти. Следующий копатель без исследования того, как копал предыдущий копатель - может просто продолжить работу. А заказчик может измерить процент выполнения работ первым копателем и оплатить ему только за его работу несмотря на то, что вся работа не выполнена (потому что заказчик знает, что второй копатель не будет копать с нуля).

В случае программирования тут не так. "План местности" доступен всем и каждый может с ним ознакомиться (=залезть в код). Опытность специалиста как раз и заключается в знании, где лежат "плиты" и умении прокопать с минимальными затратами и максимальной эффективностью для заказчика. При этом если программист захочет прервать работу, то заказчик не сможет в общем случае оценить процент выполненных работ. А следующему специалисту потребуется время на изучение уже выполненных работ с неясным финалом (может все придется переделать с нуля).

Поэтому, чтобы "не обмануться" - задачу не оценивают по предварительной оценке, а оценивают глубоко и серьезно. Но время, потраченное на оценку - включают в стоимость задачи. Мелкие задачи можно оценить и не обмануться, а уже для крупных - процедура оценки и согласования должна входить в стоимость задачи.
В консалтинговых компаниях этот этап называется "Дизайн проекта".
Другое дело, что можно глубоко проработать задачу, но потом заказчик возьмет и ее не станет делать / отдаст другому разработчику. В этом случае нужно просто договориться с заказчиком о схеме работы. Либо крупные задачи не брать, либо их делать не за фиксированную сумму, либо "коней на переправе не меняют". Один из вариантов - это выделение проработки задачи в отдельную задачу, хотя тут весьма сложно будет оценить полноту результата задачи