Где вы находите пунктуальных программистов для своих проектов?

Возможно эта ваша "осведомленность" и отталкивает... :)

WebJunior, это ирония?

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

TF-Studio, с каждым программистом встречался лично, и имели неплохие работы,это не фрилансеры,а целые конторы,которые делаю вместо месяца полгода...

Нет. Это я "теоретизирую".

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

...ну и схалтурить нельзя... может избалованы они заказчиками которые не в состоянии проверить качество реализации.

Вот им и делают, а вас стороной обходят :)

WebJunior, многие программисты наоборот жалуются,что ТЗ не информативным бывает,поэтому я решил,что лучше так)

--MINAD--,

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

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

Кроме того, если деньги вы заплатили (через СБС), то можете и требовать работы через системы контроля версий - так будете видеть, что работа идёт. При этом нужно ставить условие, что минимум, например, 3 коммита в день. Через некоторое время можно сказать, что вы - программер и понимаете, что некоторые коммиты сделаны "абы были", нужно устранить такое недоразумение.

Кроме того, ведите разработку в "гибком" стиле - я выбрал для себя Канбан-методику (через trello.com работаем) - ставится ограниченное количество тикетов, которые нужно реализовать (остальные вносятся на неосновную доску и я с ними работаю предварительно сам). Чем меньше тикетов в To Do - тем меньше отвлечения внимания и меньше "паники" у программиста.

В один момент одним программистом может исполнятся только один тикет, он его может передать на тестирование или вернуть назад в To Do, если что-то непонятно в реализации. После перенесения в Testing функционал проверяется уже не программистом и в комментарии карточки-тикета заносятся новые пожелания, сама карточка "переезжает" в To Do и ставится на нужное место в зависимости от приоритета. Это если появились новые нюансы или баги. Если же все ок - карточка переезжает в Done.

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

Функционал постоянно наращивается и при этом вы делаете то, что нужно, а не то, что жестко прописано в ТЗ.

Ключевое, как по мне показать программисту, что вы - не враг и то, что вы программист - это наоборот плюс, в случае проблем можно находить общее решение. Также просите, чтобы если возникли какие-то тупики - не зависали, а писали об этом. Часто проблема быстро решается, по причине того, что у человека просто глаз замылился и сторонний взгляд быстро выводит из тупика.

Прикиньте сколько вы готовы платить в месяц и рассчитывайте на эту сумму, а не сумму за весь проект. В этом моменте возникают проблемы с тем, что при СБС нужен договор в котором желательно внести ТЗ, а гибкие методологии они частично расходятся с жестким ТЗ.

Поэтому, наверное, придется описать саму схему работы и то как она должна оцениваться.

Если работать по жесткому ТЗ, то программист должен проставить конкретные даты для всех этапов и миниэтапов работы - это хоть как-то подстёгивает, заодно такой план можно внести в договор при заключении сделки в СБС.

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

p.s. Сейчас у меня по вышеописанной схеме уже работа не через СБС идёт, взаимное доверие наработано.