Здравствуйте, joker6413, Вы писали:

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

J>Здравствуйте, Anton Batenev, Вы писали:

AB>>Ну вот и началось приблежение к реальности...

>>> Проект как правило не точный,

AB>>Это, простите, как? Клиент не знает чего он хочет?
AB>>Разработайте и предложите.

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

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

J>Скажешь плохой проект они не подпишут? Конечно подпишут, они же в нем нифига не понимают, иначе сами бы сделали...

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

>>> требования заказчиков изменяются уже в момент реализации.

AB>>Суешь им контракт под нос, где данный пункт оговорен отдельно и
AB>>переделываешь проект.

J>Тебе говорят — дополнительных денег нет и не будет, на контракт они класть хотели т.к. по моим наблюдениям затягивать с оплатой заказчики могут неограничено. Плюс к тебе и твоей коноре сразу теряют интерес и ни одного заказа, я не говорю о поддержке ты от них не получишь. Тебя не будут рекомендовать другим потенциальным заказчикам, плюс будут отговаривать всех своих знакомых вести с тобой дела.

Вопрос сложный. Полностью зависит от того, у кого понтов больше.
К примеру, я в свое время встречал очень много людей из мелких компаний, ругающих компанию Рарус (самый крупный внедренец 1С). Только Рарус от этого заметно хуже жить не стал — понтов у них хватит, чтобы всех недовольных мелких клиентов заткнуть.

>>> Кодеры лажают и плодят ошибки.

AB>>Каждому модюлю соответствует набор тестов, подготовленный постановщиком.
AB>>Ошибка модуля прошедшего все тесты — ошибка постановщика. Ошибка модуля
AB>>не прошедшего тест — ошибка кодера. Лишите зарплаты + неустойки в
AB>>соответствии с контрактом (его иногда еще называют трудовым договором) и
AB>>такое положение дел быстро прекратиться.

J>И на следующий день ты остаешься в гордом одиночестве, а такое положение дел не прекратится т.к. возникновение ошибок — неразрывно связано с процессом разрабоки. Кстати в этом плане каждый сам себе пример, ошибки есть у всех!

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

>>> Заказчики требуют завершать этапы раньше срока (чтобы им отчитаться).

AB>>Согласно ТЗ.

J>См. результат сувания под нос проекта.

Бред. То же самое, что требовать от супруги родить малыша не за 9 месяцав, а за 6. Типа по стахановски!
В таких ситуациях здравая аргументация охладит любого нормального заказчика. А если заказчик — псих, то это уже вопрос из другой области.

>>> Людей не хватает.

AB>>Объявление "Приму на работу", кадровые агенства... Людей не может не
AB>>хватать (если офис, конечно не находится посреди тайги). Вот ограниченый
AB>>бюджет, при котором нанять новых людей проблема — это да... Но это
AB>>ошибка менеджера (см через пункт выше).

J>А работать когда? Кто с людьми будет общаться, кто их будет тестировать? Или отдельного человека нанимать, это сразу доп. деньги?

Верно. Увольнением все проблемы не решишь. Тем более, если у конторы большая текучка кадров, значит с ней есть проблемы. В такую компанию не любой человек захочет пойти работать.

>>> Тестирование поверхностное.

AB>>Все этапы тестирования проходят согласно проектной документации.

J>Проект изменяется даже без участия заказчика. Чтобы поддерживать проектную документацию тебе нужны доп. люди, которые к тому же ДОЛЖНЫ дергать программеров, чтобы вносить добавления и изменения в проект. Доп. деньги + время программеров расходуется впустую. Сами программеры серьзно документацию обновлять не будут — много работы, тут тоже каждый сам себе пример.

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

>>> Сроки затягиваются.

AB>>Оговорено в контракте с клиентом — платишь неустойку...

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

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

>>> Тестовых примеров — не сформулировано.
AB>>То же самое, что "поверхностное тестирование".

J>Проект писал ты сам, помнишь? Бизнес тесты которые придумал ТЫ, не обязательно совпадают с РЕАЛЬНЫМИ бизнес тестами проекта. А в бизнесе заказчика ты досконально не разберешься, не хватит времени.

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

>>> Этап приема проекта не оговорен.

AB>>Ошибка менеджера. (см. выше)

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

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

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

>>> Кадры заказчика не обучены...

AB>>Согласно контракта.

J>Заказчик ведет свой бизнес как считает нужным он, а не ты. Что ты напишешь в контракте по поводу кадров заказчика? У него работают те кто нуже ему... Не думаю чтобы заказчик стал нанимать людей потому что тебе этого хочется...

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

>>> Продолжать можно много.

AB>>Консультация у юриста стоит 300 руб в час. Квалификации подобного юриста
AB>>хватит, чтобы в течении 2-4 часов оговорить все детали всех договоров.

J>Отлично, ты все юридически правильно описал, от всего застраховался... Но это все зря, т.к. такой контракт заказчик не подпишет. Он ничего не понимимает в IT, все что ты там написал про отладку, про тестирование — для него филькина грамота. Что ему нанимать человека, чтобы он все это растолковал? Тратить время и силы непонятно на что (другие IT конторы так клиентов не мучают)?

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