Корректная постановка задачи

[levi-de]

Корректная постановка задачи

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

Может на будущее подскажет кто-нибудь, есть ли какие-нибудь отлаженные методики корректной постановки задачи? И вообще, как это всё делают опытные программисты?

 

[jer]

составляется и согласуется ТЗ (Техническое Задание). и работа начинается только после его утверждения.

 

[levi-de]

не, ну это ясно. А о самом процессе где то объяснено поподробнее?

 

[Dennys]

Процесс выполнения работы будешь согласовывать непосредсвенно с самим заказчиком!
Определенных правил нету!

С заказчиком можно определить сроки выполнения заказа в целом либо разбить всю задачи на подзадачи и исходя из этого составить ЧЕТКИЙ график сдачи + оплата (предоплата если боишься, что он тебя может кинуть) ну и т.д.!
А уже исходя из самого заказа в целом оценишь его сложность и обЪяснишь заказчику (далекому от программирования) за какой срок и за какую плату ты смог бы его выполнить.

А на счет ТЗ тебе верно говорят ... если там эта мелочь оговорена а ты ее не выполнил то это твой косяк а если там ничего об этом не сказано то можешь смело заказчику кинуть предЪяву ... Конечно заказчик может и отказаться тогда от дальнейшей разработки проекта, но если ты взял с него предоплату то по крайней мере ты окупишь свою затрату времени на это!
Вот!

 

[jer]

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

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

Клиенту важна (для понимания) наглядность, так что можешь сделать макет из статических html-к. Еще помогает когда заказчик показывает другие ресурсы которые ему нравятся.

Еще описываются требования по безопасности, юзабилити, требования к ресурсам для работы системы, перспективы развития. + возможности Back-Office ...

Это упрощенный вариант. Написание грамотного ТЗ для более-менее серьезного проекта само по себе стОит как небольшой сайт.

несколько сумбурно объяснил, но такое вот мнение....

ps: грамотных ТЗ на разработку веб-сайтов на русском языке в сети не находил, хотя как-то пытался найти.

 

[levi-de]

Большое спасибо за внимание к моему вопросу.

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

 

[HEm]

Прими за данность, что такие "мелочи" будут возникать все время и думай о структуре программы так, чтобы никакая мелочь не заставляла бы тебя переписывать всю прогу заново.

 

[nw]

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