Для видения делается аналитика, где виден размах всего проекта. Я это описывал в прошлой статье: http://secl.com.ua/article-serjoznoe-proektirovanie-serjoznix-saitov.html

На самом деле, прототип не до конца завершенный, не все этапы пройденный. Это ж просто пример.

Это уже целая серия статей) По выбору технологий будет следующая статья, через неделю. Тоже самый полный сборник информации по теме в рунете.

За ошибку спасибо, сейчас исправлю.

Нет, почему? Можно продумать небольшую часть системы (этап).

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

Но в целом я согласен, нужно делать все итеративно. Однако, этапы разработки не отменяют проектирование. Оно просто разбивается на этапы.

Судя по комментарию — вы программист. И еще, видно что прототипы тех ресурсов, на основе которых вы сделали вывод, делались либо просто дизайнером, либо без QA. И в этом проблема. Я тоже видел теоретические прототипы, которые вообще не могли работать на живых пользователях. Но все они делались дизайнерами и без QA. При правильном подходе переделываться должно минимум, в этом и есть цель проектирования. И если эта цель не достигнута — проектирование хреновое и проектировщика вместе с менеджером нужно уволить.

Java, на основе которой они сделали собственный фрейморк, если я правильно помню. Также как их Алиэкспресс, тоже на Java. Но это больше исторически так сложилось

Java

Что такое ЯП?

Скоро еще будут, новые статьи) У нас в запасе есть интересное

Я писал в начале, что проектирование не исключает аджаила. Можно проектировать частями. Ну и проектировать нужно думая, конечно. Кто ж заставляет проектировать с недостатками? :)

Коллеги, думаю написать такую же статью про дизайн. Этого же проекта и с примерами всех страниц. Скажите, на сколько она будет интересна сообществу? Можно выразить желание плюсом или комментом)

Да, верно

Очень большой процент таких пользователей приходится на Facebook и подобные развлекательные сайты. Факт интересный, но примерим не ко всем проектам.

Все же, в каждом случае необходим индивидуальный подход.

Постоянное объяснение пользы от внедрения может в некоторых случаях сопровождаться бонусными решениями, а в некоторых определенными штрафными санкциями.

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

Соглашусь, что контроль дело всегда непростое. Но, насколько мы смогли убедиться, такой подход упрощает проведение кодревью. Гораздо проще разобраться в маленькой функции, или классе. Просто читая названия методов и бегло просматривая их содержание можно проследить за ходом мысли программиста. Если нить теряется, или смысл трудно уловить значит, что-то нетак, и код требует более детального изучения. Из нашего опыта очень помогают периодические разборы полетов с обзором возможных решений.
Внедрение новой технологии, тем более новых ограничений в команде может осложниться непониманием и неприятием особенно со стороны более старших коллег. Это может иметь различную степень выраженности. Подходы и решения таких ситуаций для разных коллективов могут значительно отличаться. Это широкое поле для диполаматической работы с сотрудниками, формальными и неформальными лидерами.

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

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

Вы подняли очень важную и интересную тему из области статистики программных продуктов. На мой взгляд, вопросы грамотного учета и сбора статистических данных в рамках работы с кодом — исключительно необходимый и, часто, недооцененный фактор. Особенно это касается молодых и не очень больших компаний, где оценка даже менеджерской информации может вызывать затруднения. Решение может заключаться в целенаправленной унификации сбора данных по различным параметрам работы коллектива. И даже педантичная оценка последствий внедрения новой методики в рамках не очень большого коллектива не даст репрезентативной выборки, элемент субъективности будет оставаться. Я бы с удовольствием почитал о таких исследованиях. Вот, что я имею ввиду.

Да, вы совершенно правы, это субъективная оценка. Мы в свое время поверили специалистам из SIG, которые опирались, с их слов, на соответствующий объем статистических данных. И, по нашему субъективному мнению, их расчеты оказались верны. Любой стандарт — это правила и ограничения, призванные унифицировать какие-либо положительные тенденции. Вышеописанные принципы находят свое подтверждение и обоснование в трудах многих уважаемых авторов.
Я уверен, что вы вполне можете предложить свои подходы, описать их в подобной статье со своими критериями. Тогда мы с большим интересом обсудим результаты.