Сторонние работы веду только с почасовой оплатой.
Оценку делаю сам. Далее каждые 16-20 часов работы отсылаю репорт.
Заказчик принимает предложение по дальнейшему направлению работ. Если сказал стоп, то работа завершена.
Часто бывает, что свой коллектив трудный на подъем и мотивация в виде не дешевого внешнего специалиста поджигает свечи у своих.
Если заказчику не нравиться часовой тариф, то умножаю свою оценку на 3 и выставляю как цену.
А по факту ТС: жадничал и не заплатил оставшуюся половину (30 из 60), получил результат. Иногда лучше авансом купить время на саппорт, чем потом кусать себя.

Похоже, Ваше мнение оспаривает то, что сказал Fat Robot в сообщении Похоже, что в этой ветке в основном оттоптались т.н. фрилансеры-теоретики

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

Я скорее на стороне Fat Robot

1. В общем случае у меня нет намерений разделять риски заказчика. Его задача, его риск (финансовый, временной).
1.1 Есть исключения - когда хорошая команда (по рекомендации или давно знаю) и надо было вчера, то могу помочь разделить временной риск. Например плотно поработать после 24.00 или на выходных.

2. Интересные задачи - если за них платят деньги. Если заказчику мои условия не подходят (см п1), я не расстраиваюсь.

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

4. Интересный феномен Open Source, вроде без денег, а задачи иногда затягивают.

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

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

Вывод такой, что знакомство с заказчиком и состояние проекта - несколько разные вещи

Почитал обсуждение.
Большинство не видят разницы между Заказчиком и научным руководителем. Думают что Заказчик должен всё разжевать и в рот положить. Заказчик, он на то и Заказчик, что бы ни чего не знать и не понимать. Вытягивать из Заказчика крупицы информации это работа Исполнителя. Исполнитель должен в итоге составить целостную картину задачи и грамотно оценить её трудоёмкость. Объяснять Заказчику в чём разница между "стоимость зубочистки" и "стоимость разработки зубочистки" то же работа исполнителя. Кто не согласен - пусть отправляется к врачу или юристу , которые всё сказанное пациентом понимают буквально.

Трудового подвига Tahoe вышесказанное ни как не отменяет.

В теме поднята важная проблема.
Во многих случаях понять во что вырастет проект в процессе доведения до законченного продукта в начале пути невозможно. Вижу выход в том что бы изначально обговорить, что бюджет и сроки относятся в точности к тому что написано в ТЗ, буква в букву.
А всё остальное , что появится в процессе поиска решения, пусть даже самое очевидное, в бюджет и сроки не входит.

Почитав тему решил написать.
Вопросы поднятые в теме имеют место быть при разработке.
Занимаюсь разработками давно.
Для себя выработал такой подход к проведению разработок.
1. Первый контакт - просто разговариваю с заказчиком пытаясь понять , что он хочет.
2. Если это не моя тема или это противозаконно - сразу категоричный отказ.
3. Отправляю заказчика поискать другие способы получения того что он хочет (купить готовое, немного изменить свои требования и опять использовать то что уже есть) плюс советую погуглить интернет.
4. Беру неделю на обдумывание вариантов решения его задачи.
6. Снова разговариваем. Учитываем возможности по развитию изделия
7. Еще неделю готовим примерное ТЗ.
8. Месяц готовлю макет который выполняет основной алгоритм, или основной функционал изделия.
9. По итогам макетирования корректировка ТЗ.
10 Вот теперь и заказчик и исполнитель в теме разработкии можно приступать к проработке изделия
Ну и если дошли до этого значит вы с заказчиком и или исполнителем понимаете друг друга, можете сотрудничать, Значит двигаемся дальше

Стараюсь браться только за те разработки, по которым у меня уже есть достаточный опыт.
К примеру вот эта разработка потребовала примерно год и раза три корректировали ТЗ , пока не получили то что хотели.
видео можно посмотреть здесь http://www.youtube.com/watch?v=tFamGt1IhQ0...;feature=relmfu
описание http://www.youtube.com/user/drummysh/video...grid&view=0

Процес рождения устройства - это всегда обаюдное желание , согласие и возможности как разработчика так и работодателя

С таким чудоюдным жеванием за 3(три) дня ничего не построишь

Точно! проверено на практике при работе с крупным концерном

Если заказчик такой умный, что нанимает три узких спеца, то чего же ТЗ и программу Приемки не составит сам?
Почему спецы должны разделять его фин. риск?
А если не умный (сам не может), пусть нанимает компанию на изделие "под ключ". Там все три будут вариться до результата.

Я бросил писать и согласовывать полное ТЗ с заказчиками (мне проще с ними не работать).
Пишу только для проверенных людей, когда проект 110% мой.
Заказчики не готовы оплачивать этап подготовки ТЗ до заключения полного договора. А нормальное ТЗ и программа приемки это минимум 25% результата.
Работаю только итерациями (на общих ТЗ) и на доверии заказчика ко мне. Так и он быстро может понять что ему и за сколько стоит, и мне ясно чего ожидать.

Согласен. Я уже писал немного выше об этом.
в таком случае дело не заходит так далеко как у тС и в начале работы над проектом становится понятным "кто есть кто" Как в отношении заказ чика , так и исполнителя.
Мне проще сказать на начальном этапе , что я не потяну этот проект, или это займет много времени и сил и средств, заказчик тоже может поменять свою тактику, ну или вообще пойти искать другого исполнителя.
Мне нравится принцип: Пусть ваше ДА будет ДА, а НЕТ словом НЕТ, а все что не подпадает под это как раз и вызывает разногласия, непонимание и взаимные претензии.

Фигасе. 25%? Как это возможно? Только на микроскопических проектах, для которых сама работа не больше месяца занимает.

Потому что если проект занимает человеко-год, вы что, 3 месяца с утра до ночи пишите ТЗ? Да не поверю ни в жисть. За три месяца я столько напишу, что 10 человек за 10 лет не сделают


Имхо, год и три ревизии ТЗ на светомузыку в одном экземпляре - это очень и очень долго.

А у Вас сколько? на "немикроскопических"?

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

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

Скорее всего у Вас типичный случай нелегальной работы за бугром с многочисленными нарушениями "ихнего" законодательства. Поэтому Вы делаете все что скажет заказчик без возражений...
Это не бизнес в нормальном понимании, а выживание иммигранта. И подсовывать нам сюда эту лажу не надо. Попробуйте обсудить на канадских форумах эту тему. Думаю Вы не успеете дописать свой пост, как на Вас стуканут куда следует... Мне вообще не нравятся уезжанты, которые потом отттуда начинают задвигать идеи. Уехал, значит уехал, вот и живи новой жизнью и радуйся. Чего сюда то лезть с советами оттуда, как нам тут жить. Непонятно...

Все что следовало после этого - набор безумных предположений.

И вдруг у меня появилась цель в жизни: создать оружие, избирательно уничтожающее людей, придающих какое-либо значение этому б**дскому словечку "бизнес". Так, чтобы чел гнил дотла.
Спасибо за триггер!

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

Это, наверное, возможно.
Хотя нет, не смогу. Рука не поднимется делать непонятно что. все равно напишу проект и попрошу заказчика подтвердить что он именно это хочет что я написал.

Дело в том, что все ТТХ во всех ньюансах можно прописать, только если делаешь какой-то блок который встроится в уже существующую систему. А если делаешь функционально законченное изделие с 0, то это всегда "непонятно что". Заказчик как правило сам не знает что ему нужно, и 10 раз изменит требования когда увидит что получилось. Единственный выход, который я нашёл - это однозначно обговаривать, что на данном этапе работ делается ровно то что удалось написать в ТЗ. А все остальные доводки и переделки - уже обсуждаются отдельно.

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

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

Но когда уже началась работа над цифровой обработкой - возник резонный вопрос и предложение сделать универсальный выход, так появился ДМХ512 выход для управления светом на 24канала.
Так как заказчик музыкант , он решил что было бы хорошо сделать МИДИ выход, что бы выводить в этот порт сигналы об ударных инструментов и генерить звуки уже отдельным синтезаторм.
Далее последовало следуещее предложение иметь в устройстве еще и МИДИ вход, для того чтоб управлять светом с МИДИ клавиатуры. В итоге и это сделали.
Так как настроек стало очень много и они вводились с энкодера и кнопок с индикацией на двухстрочном дисплее, была бонусом добавлена возможность настройки девайса через встроенный ВЕБ интерфейс.
И когда уже девайс отправил заказчику и он остался всем доволен, возникло пожелание сделать метроном для тренировок. Заказчику была отправлена новая прошивка и детально объеснено куда и как подключить метроном.
Вот такая история о цветомузыке с эволюцией в течении года

Прекрасно. Это я и имел в виду в посте 30 минутами выше.

Мой комментарий относился к случаю когда наняли три спеца, а результат ноль. Менеджера проекта в топку надо гнать.

Как раз это выполняется для больших проектов (более 1 чг.).
Заказчик (и тем более инвестор) готов платить за ОКР. И не желает платить за НИР или НИОКР.
ТЗ на ОКР и программы испытаний пишутся по результатам НИОКР либо по опыту/результату других работ.
Большинство НИР - "визга много, шерсти мало". Но каждый НИР (даже не успешный) дает опыт и знания для последующих работ.

Так само собой, понимаю и согласен. А как иначе? Ну невозможно посчитать время и деньги, если непонятно что нужно сделать.

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

да, у меня все очень неформально... Конечно, после встречи и обсуждения на пальцах идет обмен емайлами, в которых некоторые детали проговариваются. мощность, длина поводов, итд. С испытаниями беда, конечно, я их умоляю писать тест план, пока безрезультатно В результате начал писать сам, за их счет, конечно, благо они мне доверяют, что все, что я делаю, необходимо. В одном случае, сказал им, что в софте есть баг, но не буду его исправлять пока они его сами не найдут

Вообще у меня нормальные заказчики, они привычны к тому, что разработка - процесс итеративный, и спокойно относятся к изменениям.

мне тоже такие нормальные попадаются.

Вот только делал для концерна разработку и получилась такая история ...
Люди владеощие финансами концерна, видя что разрабтки длятся годами , обратились в качестве пробной меры к сторонним разработчикам. ТЗ составлено очень толково, полно и грамотно.
Мы выполнили все пункты ТЗ и даже сделали бонусом некоторые фичи, как то настройка девайса через ВЕБ, и вдобавок к GPRS передаче данных , сделали передачу и по проводным сетям.
Минуя испытания лабораторий концерна мы поставили изделие в нескольких экземплярах на опытную эксплуатацию. Получили хорошие отзывы.
И теперь решили сдавать наш проекти ой сколько мы натерпелись .... видя все это руководство было в шоке. Как готовый к продаже продукт тормозили разные службы концерна.

У концерна есть имя?

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

Есть конечно.
Не сочтите за рекламу, по этой причине и выложил на сайте описание системы http://www.yakorev.com.ru/asuno.html
Погуглите если сильно надо.

Неистово плюсую!

Что в этом слове плохого? Ну переводите его как "дело" а бизнесмена как "делового человека" - не очень бл**ско надеюсь?

А кто нибудь имеет возможность разместить пример грамотного ТЗ и программы испытаний ?

Имеет. Только не боевые, а учебно-тренировочные. И не на железо, а на софтину. Хотя по структуре разницы практически никакой.
В минимально возможной связке "ТЗ - руководство - ПМ". Работу сдать можно запросто.

Интересная тема. Несколько лет назад от внезапно возникшей нищеты взял заказ тут на форуме. И выступил в качестве такого непорядочного исполнителя. Три ошибки, которые совершил:
1. Мотивация падает быстрее, чем кажется.
2а. Недооценка сложности.
2б. Переоценка своих сил.

Деньги были небольшие, а мороки очень много.

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

Мои советы такие.
Фрилансеру:

Хорошо подумать, называть реальные сроки.
Никогда не отключать телефон, снимать трубку, и все проблемы обсуждать с заказчиком.
Как показывает опыт, заказчик всегда входит в положение и идет на компромиссы.
И мне поэтому удивительно, что кто-то защищает Tahoe. Ибо абстрагируясь от технических вопросов, на лицо непорядочность. Тем более, комично читать фразы типа «Tahoe пахал на Вас целый год за эти деньги». Свежо предание, но верится с трудом.

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

Ну и тут много говорилось, могу только поддержать: как задача ставится, так она и исполняется.
Все условия должны быть зафиксированы на бумаге.

UPD: Самое главное забыл добавить. Мотивировать исполнителя, как хорошо известно, можно двумя способами. Морковкой спереди, и морковкой сзади.
В контексте обсуждаемой темы исполнитель практически лишен возможности мотивировать работника вторым способом. Поэтому никогда не стоит платить вперед. Может быть небольшой аванс.

UPD2: Наверное, поторопился наехать на Tahoe, не прочитав тему. Надо всегда услышать вторую сторону.

А когда можно будет посмотреть? Потому как самому стало интересно посмотреть на пример грамотного ТЗ (причина: возможно светит и мне этим занимать).

Выберите какую-нибудь одну сторону Cилы

Комично читать не «за эти деньги», а «пахал весь год». Я не изображал бурную деятельность. И не «пропадал».

Если Вам все равно, тогда чего жалуетесь? Нанимайте себе в штат разработчика и платите ему деньги. А так получается - заказчик нанимает неадекватного исполнителя и еще не доволен его работой.
Сколько раз сталкивался с ТЗ в начале заказа одно, в конце уже исправленное другое, а как выясняется хотели третье...
Ознакомтесь с СИСТЕМОЙ УПРАВЛЕНИЯ КАЧЕСТВОМ и 6 сигма.

Интересно. кто-нибудь из исполнителей пытается предварительно убедить заказчика в своей неадекватности?

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

В работе с подчинёнными важна степень регулярности морковки сзади.

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

Начинающий же работник - это скорее исполнитель. Ему нужен "тимлидер" с понедельным контролем. Буквально руко-водитель, т.е. кто-то водящий его рукой и контролирующий каждый шаг.

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

все верно.
Кроме чисто профессиональных знаний фрилансеру нужен опыт, навыки руководителя.
Руководить самим собой - не так просто, как может сначала показаться.

Мне кажется начинающему фрилансеру нужно сначала поработать с рекламщиками. Суммы небольшие и сроки малые, но палитра ситуаций за короткое время научит основным принципам фриланса. А вообще всегда нужно по совести. Договорился - делай. Не можешь - не берись. Техническую сторону нужно уточнять сразу. Вот с рекламщиками это быстро приходит. Дают задачу: контроллер на три канала по 1 А на канал. Сколько? 5 у.е. Потом присылают видео как должно мигать и раз уж договорился сидишь часа два и высматриваешь мигание на видео за одно промеряя временные интервалы. Это входит в 5 у.е.? Нет конечно, но уже договорился и надо делать. Так что ТЗ и поточнее. За это видео нужно еще бы два раза по 5 у.е. но заказчик не поймет и будет считать непорядочностью это требование. Так что...

Думаю, есть общий закон :
"Любая задача, решение которой ещё не поставлено на поток, требует многократно больших вложений, чем кажется изначально". Закон одинаково работает и на стороне исполнителя, и на стороне заказчика.