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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


>> Литература, корорая попадалась мне на глаза была двух типов:

AB>Edward Yourdon. "Death March". The Complete Software Developer's Guide
AB>to Surviving "Mission Impossible" Projects
AB>Prentice Hall, 1997, ISBN 0-13-748310-4

AB>Эдвард Йордан. "Смертельный марш". Полное руководство для разработчика
AB>программного обеспечения по выживанию в безнадежных проектах
AB>Перевод с англ. А.М. Вендрова

AB>(180Kb RAR) Мне в свое время ее оказалось достаточно.


>> 2. Описывается идеализированный подход к созданию систем. Учебники по
AB>менеджменту, пособия по планированию и.т.д. Вот только 80% факторов,
AB>влияющих на проект там не рассматривались...

AB>По причине их отсутствия.

Учебников? Ну так в книжном магазине спроси, сейчас их много.

>> Короче, ты вообще работал где нибудь?

AB>А сюда просто так на огонек заглядывают?

Конечно, студенты код просят на курсовик, ну и так понтуются....

Игорь