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

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

Проблемы возможного обобщения и усложнения задачи в будущем надо решать на стадии создания технического задания. Тут нужно действительно глубоко продумывать перспективы. А после этого — читаем статью! Избавляемся от всего, от чего возможно. Но! Методами, учитывающими перспективы. На практике переусложнение встречается все же реже, чем недоучет.

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

Извините, если вопрос — тупой. А есть ли альтернатива free-lance.ru по СБР? Данная ситуация — не суперстрашная, но вляпаться в подобное не хочется. А минимальная конкуренция заставила бы «Сервис» тщательнее прорабатывать систему сдачи-приемки (ох, больная, больная тема!) и доводить свои наработки до своих клиентов.

Судя по рисунку, скафандр — специальный, видно (если присмотреться), что дым просачивается сквозь стекло. Так что не переживайте — во втором «Крафте» скафандры землян — просто дань традиции. Они все уже мутировали с помощью протосовских ментальных технологий.

Полностью согласен, FessAectan!
>>“Мы не собираемся становиться одним из вагонов этого нанопоезда. У нас хватит сил стать его локомотивом”>> — классический пропагандистский лозунг. Заканчивать им статью — демонстрировать, то что история учит только тому, что никого ничему не учит. Нет у нас пока средств что-то там возглавлять.
Нанотехнологии скоро будут пронизывать нас: одноэлектронные транзисторы, транзисторы на одной молекуле, препараты, сплавы, покрытия, чьи свойства определяются более поверхностными эффектами кластера, чем объемными свойствами материала. И развивать эти технологии необходимо. И успехи какие-никакие — будут.
Но я бы не стал радоваться тому, что в этом процессе принимает участие этот законченный (хоть и, безусловно, очень умный) мерзавец. Слишком много государственных денег уйдет «налево».

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

Flex25, в крупных компаниях действительно данный метод используется. Но его имеет смысл использовать как дополнительный. Тестировщики, которые общаются с программистом нужны в любом случае. Именно при налаженном взаимодействии есть возможность быстро протестировать продукт на основные баги, на наиболее вероятные баги, в срочном порядке что-то быстренько подправить и т.п. А необходимость таких срочных действий в процессе работы возникает постоянно. Да и глубоко лежащие ошибки порой легче отловить, зная, с кем имеешь дело :-)=

По делу статья написана. Главное в создании ПО — действительно командная работа. И вся ответственность по организации этого лежит на менеджере проекта. Именно он задает ориентировки, согласует условия проекта с заказчиком и т.п. А если мы наткнулись на клинический случай, и специалист по-прежнему упрямо твердит: «Это не баг» или «Я ошибку нашел, дальше — не моя проблема», с таким специалистом, увы, нужно прощаться.

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

Рисуя такие графики, хорошо было бы отмечать, что по осям отложено. Ну, годы понятно, а что там по ординате? Может число сотрудников? Количество пользователей на сайте? Доход топ-менеджера?

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