Прав ли заказчик ТЗ?

Цитата ("iWoodman"):

Ну так что, общий вывод - заказчик- ссзб все подтверждаем?

Видимо Вы уже прошли путь от "ссзб" раз теперь в профиле такое описание условий сотрудничества?

Цитата ("OlegVakulenko"):

В чем смысл каждый раз акцентировать на том, что это "черновой вариант"?

Мы обсуждаем именно его.

Цитата ("OlegVakulenko"):

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

У нас свои методы работы. А срок работы над ТЗ был не месяц, гораздо меньше.

Цитата ("OlegVakulenko"):

Или заказчик должен Вас направлять и следить за всеми такими моментами?

Клиент сам предпочёл приостановить работу, хотя в 3м варианте вообще-то предполагалось учесть замечания относительно конкретного его проекта.

О, как это знакомо! "Мы должны были сдеать всё так, как вы хотели, как раз в том варианте, который вы не приняли!"
Заказчик, конечно, сам виноват, что выбрал малокомпетентного исполнителя. Но это не отменяет малоокомпетентности исполнителя.
Я вообще ни разу не программист, я с текстами работаю. Поэтому, может, я чего-то не понимаю, ну да тогда старшие товарищи меня поправят.
Но мне кажется, что "черновик" - это такой набросок проекта. То есть, если говорить языком текста, черновик сочинения - это наброски по указанной теме. То есть в черновике сочинения про Андрея Болконского не может содержаться набросков про Татьяну Ларину. А если в черновике нет даже намёка на требования, выдвинутые заказчиком, то это не черновик данного проекта. Черновик, имхо, не может только в третьей версии учитывать пожелания именно этого конкретного заказчика.
Я считаю, что малокомпетентный исполнитель в данном случае нанёс вред фрилансу в целом. Потому что заказчик на основании этой истории составит мнение о фрилансерах в целом. Негативное мнение. И наличие среди нас массы профессионалов может не помочь
Заказчику же я бы посоветовала сначала походить по форумам фриланс-порталов и спросить, сколько такое стоит. И если разброс цен будет значительным (например, от 25 до 2500 долларов), то считать приемлемой цену скорее из верхней трети, потому что сейчас во фрилансе масса демпингующей молодёжи, которая ничего не умеет, зато работает почти даром. Качество соответствующее. Если же разброс цен будет не очень большим (скажем, от 300 до 550 долларов) - значит, вас ориентируют правильно.

Цитата ("immito_manager"):

У нас свои методы работы. А срок работы над ТЗ был не месяц, гораздо меньше.

Если не затруднит, можно немного подробнее про "свои" методы работы?
На каком этапе работы над черновиком ТЗ там должны появится страницы админки, смысловые элементы и взаимодействия, нормальная (а не из типичного интернет магазина) структура базы данных и т.п.?
Я могу ошибаться, но сроки сдачи ТЗ был указан Вами, а не заказчиком.

Цитата ("immito_manager"):

Клиент сам предпочёл приостановить работу, хотя в 3м варианте вообще-то предполагалось учесть замечания относительно конкретного его проекта.

Может попросим ТС настоять о завершении работы над ТЗ, а затем обсудим весь документ, чтобы понять стоит работа денег или нет?
Но учитывая, что ни на один мой вопрос по сути проекта не было дано ответов, может быть проще признать, что ваша компания не имеет опыта ни подобной разработки, ни даже для написания ТЗ для него?

Цитата ("MariaV"):

О, как это знакомо! "Мы должны были сдеать всё так, как вы хотели, как раз в том варианте, который вы не приняли!"

Комментарии Клиента были приняты к сведению (!).
Цитата ("MariaV"):

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

Извините, но в этом Вы совершенно не правы.
Цитата ("MariaV"):

Заказчик, конечно, сам виноват, что выбрал малокомпетентного исполнителя. Но это не отменяет малоокомпетентности исполнителя.

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

Цитата ("immito_manager"):

Извините, но в этом Вы совершенно не правы.

Может, я и неправа, я же не вижу всей картины. Но меня привели к этому выводу комментарии в этой теме и пояснение заказчика. На конкретные его слова о том, что некоторые его требования появились лишь во втором варианте, а некоторые так и не появились, Вы так и не дали аргументированного возражения.
Что касается выполненных проектов - простите, но вас там много. Вполне возможно (чисто теоретически), что в ваши ряды затесался не слишком компетентный сотрудник, или что вы весьма компетентны и высокопрофессиональны в других областях. Но даже я, весьма слабо разбирающаяся в теме, прочтя замечания, высказанные участниками дискуссии к вашему ТЗ, вижу их обоснованность. А от вас не вижу внятных комментариев, почему было сделано именно так. Вы лишь повторяете: "это был черновик". Но разве должен черновик содержать тезисы, вовсе неприменимые к данному проекту? На мой взгляд, лучше было предоставить клиенту некий кусок работы, но подогнанный к его требованиям.
Что касается вашего утверждения, что комментарии клиента были приняты к сведению, - либо они были приняты к сведению, но не учтены в ТЗ, то есть содержались как бы "в уме", то ли мы чего-то не понимаем. Ведь заказчик чётко указал на расхождения между высказанными им с самого начала пожеланиями и тем, что вы написали.
Кроме того, мне хотелось бы понять, в чём именно я неправа. Вы утверждаете, что черновик проекта вовсе не обязательно должен содержать требования заказчика? А чем тогда черновик одного проекта отличается от черновика другого проекта? Зачем заказчику некий абстрактный сферический черновик в вакууме? Ему нужен черновик его проекта и никакой другой.
Возможно, мы по-разному понимаем, что такое "черновик"?

Цитата ("immito_manager"):

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

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

Цитата ("OlegVakulenko"):

Но учитывая, что ни на один мой вопрос по сути проекта не было дано ответов,

1) Таблица "Users. Пользователи".
Почему для Пароля указано поле string(255), если предусматривается хранить md5-значение, которое имеет фиксированную и меньшую длину?

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

2) Не хотелось бы делать лишнюю связку "один ко многим". Данный тип связки сильно понижает производительность при довольно больших запросах. Решение сделать фиксированное количество свойств относится больше к начальной оптимизации проекта, и позволяет несколько снизить требования к хостингу. Если же делать такую связку, то все равно предется переделывать некоторые формы и запросы.
3) Настроить ежемесячное резервное копирование переписки с компаниями. При разработке ТЗ данный аспект нами не был предусмотрен, поскольку Клиентом не было уточнена активность и объемность переписки.
4) Аналогично пункту 2. Если хранить свойства для компаний и объектов в отдельной таблице, это снизит производительность сайта и повысит требования к хостингу.
5) Вполне эффективно, данный запрос будет понятен любому сразу. При наличии таблицы, где хранятся свойства и таблицы со списком свойств, запрос усложнится и сразу программист не сможет понять смысл запроса, плюс вышеупомянутая повышенная нагрузка на сервер.
6) Можно заключать текст который может содержать разделитель в блок CDATA где ... - сам текст.

Что ж, давайте попробуем продолжить...

1) Таблица "Users. Пользователи".
Почему для Пароля указано поле string(255), если предусматривается хранить md5-значение, которое имеет фиксированную и меньшую длину?

Цитата ("immito_manager"):

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

То что есть тип поля Varchar это, как бы, понятно. Зачем указывать 256 байт, если максимум в поле будет храниться 16 (если не ошибаюсь) байт? (На самом деле этот пункт совершенно не принципиален, он просто показывает отношение к деталям)

Цитата ("immito_manager"):

2) Не хотелось бы делать лишнюю связку "один ко многим". Данный тип связки сильно понижает производительность при довольно больших запросах. Решение сделать фиксированное количество свойств относится больше к начальной оптимизации проекта, и позволяет несколько снизить требования к хостингу. Если же делать такую связку, то все равно предется переделывать некоторые формы и запросы.

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

Цитата ("immito_manager"):

3) Настроить ежемесячное резервное копирование переписки с компаниями. При разработке ТЗ данный аспект нами не был предусмотрен, поскольку Клиентом не было уточнена активность и объемность переписки.

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

Цитата ("immito_manager"):

4) Аналогично пункту 2. Если хранить свойства для компаний и объектов в отдельной таблице, это снизит производительность сайта и повысит требования к хостингу.

Может не стоит так явно показывать свою некомпетентность?

Цитата ("immito_manager"):

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

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

Цитата ("immito_manager"):

6) Можно заключать текст который может содержать разделитель в блок CDATA где ... - сам текст.

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

Если принципиально, то можно продолжить более предметное обсуждение по этим и другим моментам предоставленного документа, если конечно есть уверенность, что Вы в состочнии дать компетентные ответы.

Уважаемые фрилансеры!
Дискуссии можно продолжать бесконечно и ошибаться в деталях (не 16, а 32). Стоит ли? Мы стоим на своем мнении. Как договориваилсь изначально, так и работали. На форум могут придти ещё сотни программистов и каждый из них будет видеть проблему так, как понимает он. В основном, как мы поняли, программисты фриланса против дешевых проектов.

Цитата ("immito_manager"):

В основном, как мы поняли, программисты фриланса против дешевых проектов

так вы ничего и не поняли...

Цитата ("immito_manager"):

Уважаемые фрилансеры!
Дискуссии можно продолжать бесконечно и ошибаться в деталях (не 16, а 32). Стоит ли? Мы стоим на своем мнении. Как договориваилсь изначально, так и работали. На форум могут придти ещё сотни программистов и каждый из них будет видеть проблему так, как понимает он. В основном, как мы поняли, программисты фриланса против дешевых проектов.

Снова без ответов...
Может будет проще, если Вы доделаете ТЗ, раз деньги уже получены, а заказчик сможет его отдать разработчику?

Цитата ("OlegVakulenko"):

Снова без ответов...
Может будет проще, если Вы доделаете ТЗ, раз деньги уже получены, а заказчик сможет его отдать разработчику?

+1000.
Единственно верный выход в этой ситуации, без привлечения сторонних лиц. Заказчик уплатил - исполнитель выполнил. Исполнитель не выполнил - вернул заказчику оплату.

А все остальное "добрым молодцам урок", т.е. лирика...

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

Цитата ("MariaV"):

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

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

Жаль, что заказчик не получил нормальное ТЗ. Ну ничего страшного, на ошибках учатся, приобретают опыт... Цена, конечно, мала для такого проекта...
iWoodman, а вот грубить нехорошо... Вы со всеми так общаетесь?