Здравствуйте, Sinclair, Вы писали:
S>Да, верно. Надеюсь, теперь понятно, откуда заказчик берёт требования к срокам, быстродействию, и стоимости железки?
Вот и отлично. Заказчик тут меня мало интересует, с ним понятно. А вот с исполнителем все сложнее, и возвращаемся к исходной теме обсуждения — свойствам программ.
Итак, заказчик определил максимальную стоимость как 100 некоторых единиц.
1. Исполнитель может заявить, что задача не решается ни за 100, ни за 100000. Тут все ясно.
2. Исполнитель может заявить, что задача не решается за 100, но за 500 он ее сделает. Тут торг и уточнение параметров. Если не договорятся, то расходимся, иначе (3)
3. И заказчик и исполнитель согласны на 100. Вариант, когда исполнитель считает в душе, что хватит и 10, не обсуждаем, он выходит за рамки темы.
Итак, исполнитель согласен на 100. Пусть из этих 100 80 уйдут программистам, а 20 — накладные расходы. Соотношение не так уж важно.
20 не оптимизируешь, с ними все ясно.
А вот 80 можно распределить несколькими способами
Обращаю внимание на то, что во всех этих вариантах предполагается, что результат заказчика удовлетворит по ТЗ. Все будет сделано и будет работать.
1. Нанять 4 сеньоров , дать каждому по 20. Они сделают все качественно.
2. Нанять 3 сеньоров , дать каждому по 20, и двух юниоров, дать каждому по 10. Сеньоры будут делать основное, а юниоры будут на подхвате, им будет поручено то, что некачественно сделать трудно, Ну а если все же сделают некачественно, сеньоры их ткнут и скажут переделать.
3. Нанять 1 сеньора , дать ему 20, и шесть юниоров, дать каждому по 10. Сеньор будет тимлидом, а писать в основном будут юниоры.
Если у нас жесткие технические ограничения по памяти и быстродействию машины , то вариант 3 просто не проходит. Они не смогут написать код, чтобы уложиться в эти 16 Мбайт. А больше взять неоткуда — машин с большей памятью просто нет.
А вот если такие ограничения отсутствуют, то и команда-3 сделает продукт. Только памяти он займет в 10 раз больше, чем для команд 1-2, и работать будет в 10 раз медленнее, чем для них же.
А все равно работает. Заказчик доволен. Он теперь вполне знает, сколько за подобный продукт можно просить. И главное, он теперь знает, какие требования к железу и ПО можно предъявлять. Памяти нужно M Гбайт. Раньше он не знал, а теперь знает. Вот же продукт, он требует M, значит, для задачи такого рода меньше быть не может. Быстродействие — аналогично.
Дальнейшее.
Члены команды 1 будут работать надо следующим проектом, с ними все хорошо.
Сеньоры команды 2 будут работать надо следующим проектом, с ними все хорошо. Юниоры команды 2 чему-то научатся, и если не в следующем, то через пару проектов сами станут грамотными сеньорами.
А вот с командой 3 все намного хуже. Сеньор добиться качественного кода всех 6 юниоров не сможет. Увидит что-то один раз — поправит. Второй раз — поправит. А потом махнет рукой. Работает же, требованиям заказчика удовлетворяет, ну и ладно.
Закончен проект и они разойдутся. Юниоры — в уверенности, что так код писать можно, и вообще качественный код — это код, который удовлетворяет заказчика. Других требований к нему не может быть.
А сеньор, глядя на все это , и сам подумает : а не зря ли я писал качественно. Вот сделали проект черт те как, но все работает, заказчик доволен.
Юниоры через некоторое время станут сеньорами, вполне уверенными, что сорить памятью и применять неэффективные алгоритмы — это норма.
И когда через некоторое время заказчик попросит сделать новую работу стоимостью в 200, поручат ее бывшей команде 3. А они потребуют 500, так как с их пониманием что требуется для чего, надо памяти раз в 5 больше или процессор в 5 раз быстрее. На 300 сойдутся, и сделают, с тем же качеством.
