Как растянуть создание проекта на пару лет или искусство эффективного планирования

:) Да ничего... лучше напишите, если не сложно, как относитесь к этим двум моделям. Просто интересно, может можно эффективно использовать модель сверху вниз - может, есть какие-то подходы правильной работы при такой стратегии? Интересно было бы узнать мнение хабролюдей :)

Согласен, но это и есть реализация второго подхода. Когда есть такие люди (project manager-ы).
По личному опыту... Раньше работал именно с таким человеком, которому поступала просто инфа о том, что надо сделать, он это всё разбивал на части и предоставлял чёткую поэтапную работу. С другой стороны, работал в довольно крупной IT компании, в которой такой человек был, но все проекты предоставлялись к работе сотрудникам в первозданном (если можно так сказать :) ) виде - т.е. по первому подходу. Возможно, человек ждал проявления какого-то креатива... И это в некоторых моментах хорошо, но черевато проблемами, о которых я говорил выше... ИМХО :)

считаю этот комментарий максимально приближенным к правильному, имхо :
1) если не видеть картину в целом, то нет смысла разрабатывать "что-то там", что есть часть от целого. ведь в процессе разработки необходимо принимать решения, на которые влияет общая архитектура, цели и т.д.
2) как можно знать при подходе "снизу-вверх", что результат приближается к заказываемому?? т.е. "сейчас мы реализуем прикольную фичу, а потом подумаем зачем она нам нужна"?
3) часто заказчик сам слабо представляет себе "как оно должно работать". и понимание/видение картины в целом - избавляет от необходимости каждую мелочь уточнять с заказчиком.
4) согласен, что не обязательно каждый из разработчиком обязан "видеть картину целиком". но ведение проекта(управление/проектирование/управление требованиями) требует этого.
5) еще один "плюс" в пользу метода "сверху-вниз" - возможность на раннем этапе определить противоречие в архитектуре или выбрать наиболее оптимальное решение.

Кстати, да... О реализации подхода этого в жизни, наверное, стоит отдельно написать :) Пожалуй, тут сложнее даже, чем в работе. Потому что ты сам "заказчик" и "исполнитель". И очень часто хочется сразу конечного результата, а терпения/выдержки/усилий не хватает, чтобы дойти поэтапно до желаемого :(

Имел опыт работы в команде разработчиков, занимающихся созданием достаточно крупного и масшабного web-проекта. Почти все части работы приходили от project manager-а в виде презентации с детальным описанием буквально каждой страницы(читай - функциональности), иногда эти части даже поражали своей элементарностью (возникал даже вопрос - для чего так?), иногда были достаточно сложные кусочки проекта, занимавшие около недели рабочего времени... Такие части рассылались каждому человеку в команде, по завершению проекта, почти вся команда, смотря на готовый продукт про себя говорила "да, если бы нам сразу сказали, что реализовать придётся ТАКОЕ, возможно, поставили бы гораздо большие сроки или отказались от проекта вообще".

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

Если предложите какой-то альтернативный пример построения работы - было бы интересно :)

Да, при большой сложности и взаимозависимости частей проекта именно так и происходит. Я не знаю ни одного такого проекта, в котором Супер-Архитектор сумел разделить (спроектировать) систему так, чтоб потом новые связи оказывались возможными и не глючили.
Может быть, это специфика именно нашей компании - но это так. Waterfall ни разу не сработал, у наших заказчиков слишком короткие сроки и ресурсы :)