AhAnya

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

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

Еще небольшой нюанс: сроки, указанные программистами, часто бывают слишком оптимистичными, потому нужно учесть риски - умножить их на 1,7 и добавить 2 недели. 2 недели - это срок, за который даже если программист до того ничего не делал, может в режиме 24/7 сделать готовый презентабельный продукт.

Какой идеальный алгоритм ведения проекта?

Не существует.

Как правильно вести проект

* Договор с заказчиком
* Предоплата итерации 0 в полном размере.
* Итерация 0: ТЗ. ТЗ должно быть максимально подробным. В его составлении могут участвовать все члены команды. Не используйте абстрактные слова/словосочетания и их производные в ТЗ: плохой, красивый, хороший, такой же, другой, простой. Словосочетания без уточнений: параметры, настройки, информация. Вместо этого: параметры: А, Б, В. Настройки: цена (вещественное[0,∞]),...
* Подписанное обоими сторонами ТЗ.
* Предоплата итерации 1 в полном размере.
* Итерация 1: дизайн. Как только заказчик скажет "да, я хочу именно это"
* Заказчик получает на руки копию дизайна, как результат первой итерации.
* Предоплата итерации 2 в полном размере.
* Итерация 2: верстка. Как только заказчик скажет "да, я хочу именно это"
* Заказчик получает на руки копию сверстанного сайта, как результат второй итерации.
* Предоплата итерации 3 в полном размере.
* Итерация 3: программирование. Как только заказчик скажет "да, я хочу именно это"
* Заказчик получает на руки копию свое сайта И установку его на сервере, как результат третьей итерации.
* Итерация 4: поддержка. Ее инициатором является заказчик. Условия сотрудничества обговариваются отдельно.

чтобы гарантированно его не завалить

Вы работаете с людьми, какие могут быть гарантии?))

сдать проект через месяц

Воу-воу-воу, сроки определяются на основании ТЗ, а не прихоти.

Вот, кстати, да. Давно у меня нет понимания четкого понимания где какой из методов использовать (благо, что я не по web-у специализируюсь).

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

Но вот для чего может понадобиться в классической форме method="get"? Ведь форма всегда (!) подразумевает именно отправку информации. Тем не менее, такая возможность есть. Или это просто неправильное использование средств, которыми мы выстреливаем себе в ногу?

www.komtet.ru/lib/tech/apache/razlichie-mezhdu-met...

https://www.google.ru/search?q=POST+и+GET+оличия#n...