Распространенные проблемы при управлении проектами (Web)

Неплохо, довольно точно

По суммам
1 за 1000-1500 сайт сделает средняя студия (конечно не супер-качество, но все таки)
2 десятки и сотни тысяч за сайт (за САЙТ!) явление нечастое даже для западных компаний. Я имею в виду бюджет >10K.

В целом статья неплохая, но немного устарела. Сейчас вряд ли кто-то начинает проект не подписав договор, в котором четко прописано что и в какие сроки хочет клиент. Как только фирма перерастает объем в 4-5 человек, вводиться Project & Time Mangement.

Не обижайтесь, но читать неинтересно. Меня не хватило даже на половину статьи.

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

Хорошая статья.
А вы слышали про прием "экстремального программирования" (ХР)? Я прочитал книгу Кента Бекка запоем, забив на учебу на некоторое время...
ПС. Есть в .pdf, если интересно.

По-моему основная проблема веб-девелопмента не в незрелости, а в желании применять методологии, которые используются для разработки enterprise приложений, и соврешенно неприемлемы для веб. Молодые специалисты, многие из которых занимались разработкой преимущественно веб-приложений, используют agile методики и успешно справляются со всеми описанными в статье проблемами.

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

Хорошая статья, но вообще для управления проектами давно уже существует такие вещи как Унифицированный процесс разработки ПО от IBM Rational Rose. Там и управление требованиями, и управление рисками, и итерационность процесса, и много-много еще разных радостей. УП (унифицированный процесс) можно настроить (подобрать совокупность методик и софта для управления) под любой проект, причем как с использованием инструментов Rational Rose, так и без них. Помимо этого УП можно использовать как в больших командах (там будет чувствоваться вся его сила), так и индивидуально (уницифрованный процесс в одну рабочую силу).
Советую в это плане вот эту отличную книгу: Rational Unified Process - это легко. Руководство по RUP для практиков от товарищей Пера Кролла и Филиппа Крачтена

А вот мне не понятно почему автор данной статьи вместо того, чтобы решить свою проблему, рассусоливает ее, и путает молодое неопытное поколение... Дисциплину "административное управление" (или как это сейчас новомодно называется?) никто в ВУЗах не отменял...

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

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

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

А банальный промо-сайт или визитку действительно в большинстве случаев сделает мелкая студия или десяток студентов в приемлимые сроки и с устраивающим клиента качеством. Никто же не идет заказывать программку для печати бланка на дельфях в компанию Microsoft. Это нецелесообразно.

Перечитал массу статей на эту тему. Везде пишут одно и то же, но своими словами.
Важно то, что проблемы в управлении проектами нет. Есть проблема взаимоотношений между участниками проекта. Стоит это понять, как все становится на свои места.

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

Потом возникает ситуация, когда менеджер ушел в отпуск, разработчик заболел, на проект подключили третьего человека, а он вообще не в курсе. А может и в курсе общих вещей, но без деталей. А ведь четкого ТЗ тут нет.. И начинаются проблемы. Но это уже больше к форсмажорам можно отнести. Но и они случаются, клиента это не волнует. ОН УЖЕ ОБЪЯСНИЛ ВАСЕ ПУПКИНУ все, какого болта он еще раз кому-то должен объяснять.

Ну а почему нет ТЗ - причин на самом деле куда больше, чем просто лишняя купюра в кармане.

Спасибо автору.

В статью я бы добавил один важный пункт относительно требований:

Требования должны тестироваться

Очень хорошо, что была затронута проблема "сбора требований" (относительно головы или icq или e-mail). В статье - это вершина айсберга. Я добавил бы как сделать этот процесс системным и правильно документировать требования, с интересом бы и прочел эти решения. :) Прибыль проекта напрямую зависит именно требований.

Адаптированный перевод SW-CMM и стандарт ГОСТ Р ИСО 12207 - в них есть вся основа для управления разработкой любого софта. Зачем перетирать одно и то же 10 тысяч раз разными словами, теряя по дороге частицы смысла?

Статья отличная. А комментарии были бы хороши, если бы мы вместе обсуждали, как с такими проблемами кто справляется. Ну не верю я, что в крупных студиях все отлажено. Совершенно согласна, что у нормальных компаний, у которых есть клиенты постоянно и хорошие, всё не находится в режими аврала.
Не видела адекватных тренингов по управлению веб-проектами. Чему угодно учат, а этому нет. Надо учиться друг у друга, на своих и на чужих ошибках.