Знаете, снижение роста ВВП с 7% до 6% не особо роляет, если у вас второе место в мире по объему производства, а лидер тормозит со своим жалким ежегодным приростом в 2%
Ну вот мне на ум ничего такого сходу не приходит, что в Китае НЕ производится. Швейцарцы еще немного посидят на попе ровно, и китайцы их обгонят по количеству произведенных докторов наук на душу населения.
Хорошо бы еще привести цифры в единицах произведенной продукции на душу населения. А то получается сравнение швейцарского брегета за $100500 c вагоном китайских будильников.
Так ответ сообщением выше: мы не разрабатываем прототип проекта, мы делаем прототип продукта. Для меня проект и продукт даже близко не синонимы. Проект (со всеми его подготовительными и промежуточными фазами) — это лишь способ решения, а вовсе не ответ на поставленную задачу. Я не вижу смысла разрабатывать проекты ради разработки проектов. Вы — видите.
В этом наше с вами ключевое/концептуальное различие, и именно поэтому лезть дальше в дебри терминологии смысла нет.
Терминология иногда заводит в дебри. Мы не разрабатываем прототип проекта, мы делаем прототип продукта.
Если новые пожелания заказчика противоречат готовой архитектуре, то заказчику следует подробно разъяснить проблему. Хорошо проинформированный заказчик обычно не склонен ломать несущие стены.
Спасибо, теперь понятно, в чем мы расходимся.
Я-то всю сознательную трудовую жизнь считаю, что концепция вырабатывается (и объясняется исполнителю!) еще до начала работы руками. Прототип начинают делать после того, как определились с концепцией. Т.е. «автомобиль с рулем под капотом», с учетом вашей поправки, это и есть концепция = условие задачи = «как надо». Если разработчик понимает, что заказчику нужна киллер-фича, то результат будет такой, какой нужен заказчику. А если разработчик не понимает смысла того, что от него требуют, то результата может не быть вовсе (руль будет где просили, но авто ехать перестанет, например).
С другой стороны, сержантский метод руководства («отставить разговорчики и выполнять приказ!») тоже вполне эффективен. Разве что слабо применим, когда от исполнителя требуется думать головой.
И еще одно разночтение: Качество кода важнее скорости его написания. Я всеми руками за то, чтобы разработка велась максимально быстро, но не в ущерб же качеству кода! А то как в анекдоте: «Я печатаю со скоростью 600 знаков в минуту. Тааакая фигня получается!»
Стандартный пример — разработка прототипа. Категорически несовместима вообще ни с чем из этого манифеста.
Я вообще-то мимокрокодил, но поясните, пожалуйста, что вы этим хотите сказать? Потому что имхо не просто совместимо, а ну как иначе-то? Концепция важнее новых требований — да. Если взялись разрабатывать автомобиль, то на выходе должен быть автомобиль, а не летающая субмарина. Качество важнее скорости — да. Прототип автомобиля должен ездить, и пока он не ездит работа не закончена — жесткие сроки на невозможны. Делать как надо важнее, чем делать как просят — да. Если заказчик требует установить руль под капотом, то следует игнорировать эти требования.
«не будь мудаком» ведь в обе стороны работает, не так ли?
Адекватный работодатель отдает себе отчет в том, что работнику, конечно, банкротство не выгодно, но в большинстве случаев не фатально. Если работодатель не дает работнику ощутить удовлетворение от собственного труда, то такой работодатель сам себе злобный буратино — хуже фрустрированного работника только разочарованная жена.
Знаете, снижение роста ВВП с 7% до 6% не особо роляет, если у вас второе место в мире по объему производства, а лидер тормозит со своим жалким ежегодным приростом в 2%
Поклеп! =)
В этом наше с вами ключевое/концептуальное различие, и именно поэтому лезть дальше в дебри терминологии смысла нет.
Если новые пожелания заказчика противоречат готовой архитектуре, то заказчику следует подробно разъяснить проблему. Хорошо проинформированный заказчик обычно не склонен ломать несущие стены.
Я-то всю сознательную трудовую жизнь считаю, что концепция вырабатывается (и объясняется исполнителю!) еще до начала работы руками. Прототип начинают делать после того, как определились с концепцией. Т.е. «автомобиль с рулем под капотом», с учетом вашей поправки, это и есть концепция = условие задачи = «как надо». Если разработчик понимает, что заказчику нужна киллер-фича, то результат будет такой, какой нужен заказчику. А если разработчик не понимает смысла того, что от него требуют, то результата может не быть вовсе (руль будет где просили, но авто ехать перестанет, например).
С другой стороны, сержантский метод руководства («отставить разговорчики и выполнять приказ!») тоже вполне эффективен. Разве что слабо применим, когда от исполнителя требуется думать головой.
И еще одно разночтение: Качество кода важнее скорости его написания. Я всеми руками за то, чтобы разработка велась максимально быстро, но не в ущерб же качеству кода! А то как в анекдоте: «Я печатаю со скоростью 600 знаков в минуту. Тааакая фигня получается!»
Я вообще-то мимокрокодил, но поясните, пожалуйста, что вы этим хотите сказать? Потому что имхо не просто совместимо, а ну как иначе-то?
Концепция важнее новых требований — да. Если взялись разрабатывать автомобиль, то на выходе должен быть автомобиль, а не летающая субмарина.
Качество важнее скорости — да. Прототип автомобиля должен ездить, и пока он не ездит работа не закончена — жесткие сроки на невозможны.
Делать как надо важнее, чем делать как просят — да. Если заказчик требует установить руль под капотом, то следует игнорировать эти требования.
Адекватный работодатель отдает себе отчет в том, что работнику, конечно, банкротство не выгодно, но в большинстве случаев не фатально. Если работодатель не дает работнику ощутить удовлетворение от собственного труда, то такой работодатель сам себе злобный буратино — хуже фрустрированного работника только разочарованная жена.
«Стокгольмский синдром»?