Советник быстро(1-5 часов) за 10$.Скрипт за 5$. - страница 9

 
granit77 писал(а) >>

Практика показала, что самореклама убила уже не одну такую ветку. Могу только посоветовать разумный порядок поиска программиста. ИМХО.

1. Прочитать статью "Советник на заказ. Инструкция для трейдера" легендарного komposter'а, это практическая инструкция по составлению ТЗ.

2. Прошерстить форум в поисках программистов (а не объявлений о приеме заказов), почитать дискуссии, посмотреть кто как себя ведет.

3. Составить список приглянувшихся кандидатов (вызывающих симпатию, грамотно и корректно изъясняющихся, имеющих стаж на форуме с большим списком опубликованных серьезных скриптов/статей).

4. Составить ТЗ и связаться по личке с кандидатами, после предварительного согласия выслать ТЗ для оценки стоимости.

5. Выбрать одного, остальных поблагодарить.

По моему опыту безусловными авторитетами являются komposter и Integer (прошу прощения у остальных профи, просто не сталкивался).

Алгоритм хороший, только одно но: чем "безусловней" автоитет, тем дороже его услуги :) Вот и пытаешься найти разумный компромис.

Хотя наверное есть доля истины и в том, что скупой платит много раз...

 
rid писал(а) >>

Несколько раз с моим скромным опытом программирования соглашался выполнить заказы на простейшие, элементарные конструкции.

Впечатление осталось однозначное. Как правило, заказчики оч. плохо представляют, что они хотят получить в итоге.

А уж чтобы добиться от них толково изложенного тех/задания, - это занимает порой больше времени, чем само написание советника! Тех/задание (без иронии) порой приходится чуть ли не клещами вытягивать!

Как правило заказчик сам полностью непонимает чего хочет...

Из одного "ТЗ": Когда график линии А чуть-чуть недоходит до линии Б...

Дальнейшее обшение голосом:

Я: чуть-чуть - это сколько и в чём ?

Зак: Вы что - идиот, не знаете что такое чуть-чуть ?

 
Echkidag >>:

Алгоритм хороший, только одно но: чем "безусловней" автоитет, тем дороже его услуги :) Вот и пытаешься найти разумный компромис.

Хотя наверное есть доля истины и в том, что скупой платит много раз...

Алгоритм проверенный поколениями. Даже из этой ветки видно, что "беспорядочные связи" приводят к бОльшим потерям и денег, и нервов.

А экономить надо умело: простые вещи делать самому, необязательные заказывать за умеренную плату, а уж потенциальные граали отдавать грандам.

Они грамотно, аргументированно и корректно покажут вам, что вы снова заблуждаетесь и вы очень хорошо запомните урок, потому что он стоил хороших денег.

 

А не проще сразу сообщать, в месте с тех. заданием, сколько готов заплатить

за работу программиста.

 
"Не гонялся бы ты поп за дешевизную". Дешево и хорошо бывает редко, недолго и не для всех. Предложение было нереально "щедрое"...
 
JavaDev писал(а) >>

Как правило заказчик сам полностью непонимает чего хочет...

Из одного "ТЗ": Когда график линии А чуть-чуть недоходит до линии Б...

Дальнейшее обшение голосом:

Я: чуть-чуть - это сколько и в чём ?

Зак: Вы что - идиот, не знаете что такое чуть-чуть ?

не адресный, но-таки совет - - если вы по общению видите, что заказчик сам не знает чего хочет, будьте терпимее: сразу предложите на выбор несколько вариантов. пусть выбирает из них!

 
Shu >>:

не адресный, но-таки совет - - если вы по общению видите, что заказчик сам не знает чего хочет, будьте терпимее: сразу предложите на выбор несколько вариантов. пусть выбирает из них!

Дык так и делаю кодеры ... 2-3 варианта а уже заказчик решает. 

Мож и есть кому даж заморачиваться не охота " клещами тянет ТЗ"

 
Shu >>:

не адресный, но-таки совет - - если вы по общению видите, что заказчик сам не знает чего хочет, будьте терпимее: сразу предложите на выбор несколько вариантов. пусть выбирает из них!

Однозначно, - не следует так делать!

"Ибо" при любом "сливном" результате (а другого не будет) виноватым всегда окажется программист.

Со всеми вытекающими...

 
rid писал(а) >>

Однозначно, - не следует так делать!

"Ибо" при любом "сливном" результате (а другого не будет) виноватым всегда окажется программист.

Со всеми вытекающими...

вы не поняли! ;-) если заказчик не может сам сформулировать условие, то можно просто предоставить ему на выбор несколько вариантов (исходя из вашего опыта разработки, формализации). а он уже пусть САМ скажет - соответствует это его "путаному описанию" или нет. если скажет, что какой-то вариант соответствует, то и пусть! а вот если вы начнёте писать, не формализовав задачу однозначно (с точки зрения соответствия "словесному пон описанию заказчика"), то тут - да, полностью с вами согласен - как бы ни написал программист, всё равно это будет плохо, придётся переделывать 2-3-4-5 раз.

 

Эхх, трудно все-таки быть кодером. И заказчику тоже трудно общаться с кодером, если он (кодер) "такой идиот, что не знает, что такое "чуть-чуть"". А самый прикол в том, что для корректной формулировки ТЗ у заказчика и мозги должны быть повернуты примерно так же, как у этого идиота кодера.