Good/Cheap/Fast: Какие два?

Question

Я слышал фразу: «Хорошо, дешево и быстро: выберите два».

Для проектов программирования обычно есть «лучшие два?».

Answer 1

Это полностью зависит от ваших клиентов.

Если они готовы платить, хорошо и быстро всегда предпочтение ...

Answer 2

Хорошо и быстро!

Answer 3

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

Я думаю, что частая ошибка, которую люди совершают, заключается в том, чтобы пойти «дешево», не учитывая общую стоимость жизненного цикла проекта, включая поддержку и обслуживание. Если первоначальные предложения включали эти дополнительные предметы (которые я предлагаю гораздо более дорогостоящим для «дешевых» проектов, чем не дешевые проекты), дешевый вариант часто выглядит менее привлекательным (и часто является самым дорогим в долгосрочной перспективе).

Просто некоторые мысли из моего опыта ...

Answer 4

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

Answer 5

Я предпочитаю хорошо и быстро ... Бизнес всегда выбирает дешевый и быстрый

Answer 6

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

Answer 7

, если вы не хотите тратить деньги хорошие и дешевые лучше

Answer 8

Это просто проще утверждение бюджета в зависимости от времени против объема. Два фиксированных, один является переменным.

Проблема заключается в том, что они почти всегда хотят, чтобы все 3 ...

Answer 9

Это зависит от проекта и имеющиеся ресурсы, которые клиент имеет. Нет единого ответа.

Answer 10

Хорошо, субъективно идти дешево и быстро. По крайней мере, если это плохо (это то же самое, что и у кого-то хорошего), вы можете выбросить его с минимальной суетой.

Answer 11

Другой способ взглянуть на это состоит в том, что в основном существуют четыре переменные, которыми вы можете управлять в большей или меньшей степени.

• Качество
• Область
• Ресурсы
• Время

Из этих четырех, как правило, вы хотите, чтобы исправить высокое качество, хотя есть исключения. Ресурсы лучше всего добавлять заранее, и поэтому они также исправно устраняются, если ваша временная шкала не очень длинная. Таким образом, компромисс обычно находится между областью действия (что) и временем (как долго). Мое предпочтение заключается в сокращении объема и соблюдении сроков, если то, что я могу доставить, по-прежнему имеет ценность.Часто это происходит в контексте конкретной итерации, и отброшенные функции будут добавлены позже, возможно, увеличивая общее время проекта.

В вашем пантеоне, я полагаю, это будет означать хорошее и быстрое.

Answer 12

Эмпирически, я бы сказал, что большинство проектов имеют тенденцию идти дешево и быстро. Доля Хорошего программного обеспечения я видел в своей жизни исчезающе мала ...

Answer 13

лучше 2 - хорошее & быстро

реальность - быстрые & дешевых

Answer 14

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

Это не только программное обеспечение. Если вы окажетесь хорошим механиком, кто-то, кто наслаждается работой, они всегда будут пытаться заставить вас исправить вещи справа. Например, они будут настаивать на работе двигателя на 600 долларов на старом подержанном автомобиле, чтобы исправить кучу медленных утечек масла, которые не будут стоить вам около 600 долларов США в течение всей своей жизни. Раньше я думал, что все они хотят меня обмануть, но это совсем не так. Они просто хотят сделать работу правой.

Понимание того, что наши клиенты и не-инженерные боссы смотрят на нас так же, как мы смотрим, что автомеханик - это начало мудрости.

Answer 15

Мой опыт показывает, что только один из них на самом деле можно

Answer 16

Open Source => Хорошо & Дешевые

Answer 17

Как и все остальные, я предпочел бы хорошо и быстро.

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

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

Answer 18

Субъективный, не программируемый вопрос, который не закрывался. Кто бы мог подумать, что такое возможно ...

редактировать - Данг, похоже, что я вошел в мой пост слишком рано ...

Answer 19

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

Answer 20

Клиенты хотят все, вчера, бесплатно.

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

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

Как насчет того, когда нет возможности?

В попытке выбрать 2 Добра, быстрый или дешевый, я использую простой тест:

1) Насколько это важно? 2) Насколько это сложно? 3) Сколько времени потребуется, прежде чем вы подумаете, что можете сделать это быстрее?

На основе этих ответов, я пытаюсь бороться за следующее:

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

- Это сложно? Действительно? Если это так важно и необходимо, вы уверены, что не занимаетесь разработкой?

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

Просто некоторые идеи, надеюсь, что это некоторая пища для размышлений.