С чего нужно начинать разработку?

[Warn]

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

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

ТЗ составляется в 1-2 страницы где прописано то что должно быть в конечном продукте.

Это основное требование к ТЗ?
К ТЗ может что-то прилагаться (рисунки, текст…)?
Может где есть доступный пример для ознакомления?

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

[Kostia]

ТЗ - Техни́ческое зада́ние wiki
С ним не все так просто. На вики приведено описание классического ТЗ которое относится не только к разработки программного обеспечения, а в целом.
Приходилось работать с ТЗ примерно в ~100 страниц, это непомерный гемор под конец разработки сверять то, что уже готово и тем что есть в ТЗ, которое в течении самой разработки менялось по несколько раз(дописывались пункты, некоторые убирали...).
Сейчас многие забугорные и наши компании разрабатывающие ПО работают по несколько другому алгоритму. ТЗ содержит только основные моменты и описывается в 1-2 страницы, при встрече с заказчиком все пункты объясняются в устной форме, выставляются сроки и оплата в месяц. После утверждения на разработку это ТЗ отдается программистам.
ТЗ такого рода никак не стесняет программиста. Изначально при разработки отдельных блоков предполагается их расширяемость или же полное переписывание без существенного переписывания остальных(это нормально по 3-4 раза с нуля переписывать отдельные блоки или же весь проект на ранних стадиях)
После написания частично функционирующего продукта подключается заказчик(люди которые будут работать с ПО) непосредственно в разработку =). Заказчик говорит что нужно добавить, что поправить, что изменить или удалить, ну или вы ему предлагаете, а он либо соглашается либо нет.
Таким образом разработка становится:
1. Проще и интереснее для разработчика, он не стеснён строгими пунктами толстенного ТЗ
2. Заказчик непосредствен.но принимает участие в разработки, он сам видит прогресс(это часто впечатляет), ну и куча вытекающих последствий от участия заказчика

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

Идея -- концепт фокус – концепт – дизайн документ – требования заказчика – конкретные задачи

Если идея ваша и вы ее воплощаете в реальность, то требования какого заказчика? Хотя если вы сотрудничаете с издателем, то они могут попросить изменить некоторые вещи в ПО, и тогда этот пункт нужно перенести в самый конец, когда уже можно будите показывать что-то рабочее.
По сути то ТЗ, про которое я писал, в случае разработки игры это есть концепт-документ(концепт).
Диздок желательно подготовить перед тем как пойти к издателю, а еще лучше приложить демку. Это поможет договориться с издателем.
по ДД можно почитать тут http://www.lki.ru/text.php?id=192

[Warn]

Если идея ваша и вы ее воплощаете в реальность, то требования какого заказчика?

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

Тогда если вновь подытожить, процесс можно представить так:
Идея --> Гейм-фокус –-> Концепт –-> Дизайн документ( Техническое задание) --> Конкретные задачи

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

[Виталий Желтяков]

Сейчас многие забугорные и наши компании разрабатывающие ПО работают по несколько другому алгоритму. ТЗ содержит только основные моменты и описывается в 1-2 страницы, при встрече с заказчиком все пункты объясняются в устной форме, выставляются сроки и оплата в месяц. После утверждения на разработку это ТЗ отдается программистам.
ТЗ такого рода никак не стесняет программиста. Изначально при разработки отдельных блоков предполагается их расширяемость или же полное переписывание без существенного переписывания остальных(это нормально по 3-4 раза с нуля переписывать отдельные блоки или же весь проект на ранних стадиях)
После написания частично функционирующего продукта подключается заказчик(люди которые будут работать с ПО) непосредственно в разработку =). Заказчик говорит что нужно добавить, что поправить, что изменить или удалить, ну или вы ему предлагаете, а он либо соглашается либо нет.

Это схема работает, когда нет ограничений в отношении работы художника. У нас же в России с нормальными художниками худо, поэтому схема не прокатывает.