3D.ru

Коллеги, подскажите как быть.

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

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

jet_aleks писал(а): По описанию я озвучил сумму на разработку. Но у него нет конкретного ТЗ и он хочет подписать контракт.

А в чем проблема вам самому набросать по быстрому ТЗ? Вы же уже озвучили сумму, значит в голове у вас должен уже быть примерный план разработки. Просто расставьте все точки над i с заказчиком, что вы делаете такую-то работу по пунктам, за такую-то оплату.

В моем понимании Тз - это до мелочей расписанный док, по которому четко не отступая ведется разработка. Меня пугает в этом всем, что когда его(ТЗ) нет, начинается путаница, куча правок по не законченным пунктам. Плюс к этому всему понимание разработки игр у заказчика отсутствует. О юнити он в первые слышат и предлагает что бы далекий от этой области человек курировал.

jet_aleks писал(а):В моем понимании Тз - это до мелочей расписанный док, по которому четко не отступая ведется разработка.

Эх )) Как бы мне хотелось увидеть хоть раз в живую такое вот ТЗ. В реальности такого никогда не бывает и ТЗ выглядят примерно так:
"нужно написать программу расчета зарплаты и чтобы была кнопка красная, на неё нажимаешь и ВЖЖЖУХ! И чтобы поняши розовые по экрану а в уголке зеленый листик"

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

Как в таком случае заключать контракт и какие пункты будут важными, что бы в случае чего, мне не сказали что я работу не выполнил в полном объеме ?

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

это вы пишете как заказчик, причем знающий что хочет и понимающий что такое разработка игры. максимум что вы потеряете -это пара сотен баксов на аванс.
а топикстартер находится по другую сторону договора , а вместо вас у него заказчик "хочу сам не знаю чего". в такой ситуации самое разумное - набросать ТЗ, насколько возможно полное, а последним пунктом прописать что мол по вопросам не уточненным в данном ТЗ решение о способе реализации принимает разработчик. кроме того, лучше указать - кто и в какие сроки будет принимать работу (и лучше сдавать ее поэтапно, чтобы вовремя можно было увидеть расхождения по целям и задачам), в каком виде передается работа.
а подписывать рамочный контракт с человеком который сам не знает чего хочет - это глупость. в лучшем случае отдашь время и силы и не получишь ничего, а в худшем еще и должен останешься .
лучше потерять несколько дней на написание ТЗ, чем потерять несколько месяцев не получив нихрена. объема ТЗ в 5-10-15 страниц для небольшого проекта вполне хватит.
если заказчик серьезный, то он оценит ваш подход и подождет, потому что ТЗ поможет ему лучше понять что он получит в итоге.
И самое главное- при сдаче каждого этапа или работы в целом получайте бумажный документ, что вы работу: а) передали для приемки , и б) работа принята.

Торжественно вангую - хлебнет проблем автор с этой работой.

А вообще - правильно написали - практически никогда не бывает ТЗ составленного и расписанного до мелочей.

Торжественно вангую - хлебнет проблем автор с этой работой.

в том то и проблема, для того и создал эту тему, что бы подсказали как быть, и сам уже тогда пойму стоит вообще браться=))

Вообще то ответ получил. Всем спасибо!!!=))

Valentinus писал(а):

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

это вы пишете как заказчик, причем знающий что хочет и понимающий что такое разработка игры. максимум что вы потеряете -это пара сотен баксов на аванс.
а топикстартер находится по другую сторону договора , а вместо вас у него заказчик "хочу сам не знаю чего". в такой ситуации самое разумное - набросать ТЗ, насколько возможно полное, а последним пунктом прописать что мол по вопросам не уточненным в данном ТЗ решение о способе реализации принимает разработчик. кроме того, лучше указать - кто и в какие сроки будет принимать работу (и лучше сдавать ее поэтапно, чтобы вовремя можно было увидеть расхождения по целям и задачам), в каком виде передается работа.
а подписывать рамочный контракт с человеком который сам не знает чего хочет - это глупость. в лучшем случае отдашь время и силы и не получишь ничего, а в худшем еще и должен останешься .
лучше потерять несколько дней на написание ТЗ, чем потерять несколько месяцев не получив нихрена. объема ТЗ в 5-10-15 страниц для небольшого проекта вполне хватит.
если заказчик серьезный, то он оценит ваш подход и подождет, потому что ТЗ поможет ему лучше понять что он получит в итоге.
И самое главное- при сдаче каждого этапа или работы в целом получайте бумажный документ, что вы работу: а) передали для приемки , и б) работа принята.

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

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

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

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

Лучше, конечно, беги. Такой тип заказчиков - крайне неприятный.

не совсем понял с чего Вы сделали такой вывод. Контракт?
Объясните, что бы на будущее имел введу.

"Это не то, что я хотел, давай сделай еще вот эти пару правок на пару месяцев, иначе не заплачу, потому что работа по контракту не выполнена"

Woolf писал(а):
Товарищ, вы путаете, ТЗ должен составлять заказчик, а не исполнитель )) Это же заказчик должен написать, что конкретно ему надо. .

я ничего не путаю, я просто внимательно читаю что пишет топикстартер и советую исходя из его ситуации: если ему хочется заключить контракт, но заказчик не способен написать ТЗ, то почему бы не написать его. В области ОКР, например, нормальная практика, когда Исполнитель на первом этапе работ разрабатывает полное ТЗ, согласовывает его с Заказчиком, и кстати берет за это деньги.