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

Компьютер будет делать то, что вы ему сказали, а не то, что вы хотите, чтобы он делал.

Любая форма абстракций должна быть переведена в точные детали.

Источник http://c2.com/cgi/wiki?TeachMeToSmoke

Teacher: "It's hard to express ourselves clearly. You're a smoker, right? 
Are you pretty good at it? [Student nods.] 
Let's pretend I'm a man from Mars and you are going to teach me to smoke. 
Do you have a fresh pack? Let's start with that. 
[Takes pack.] OK, now tell me what to do." 


Student: "Tear open the pack."

T: [Tears pack to shreds. Cigarettes fly everywhere.] 
S: "No, no, tear off the top of the pack!" 
T: "OK, sorry, do you have another pack? No? OK, let's just start with this cigarette. [Picks one up.] 
S: "Put it in your mouth." 
T: [Puts whole cigarette in mouth.] 
S: "No, no, just put the end in your mouth!" 
T: "Sorry." [Tears filter off, puts whole filter in mouth.] 
S: "No, no, don't tear the cigarette, just hold it between your lips!" 
T: "Oh, sorry, give me another one." [Places new cig sideways between lips.]

... и так далее. Вы можете играть в эту игру в течение длительного времени. Трудно дать четкие инструкции, даже если вы знаете домен. Программирование будет длиться очень долго. -- RonJeffries

У меня был друг, который мог сделать кубик Рубика за считанные секунды.

Это заставило меня подумать о том, как объяснить моему менеджеру, почему наш последний проект провалился! Оливье занимает в среднем 10 секунд, чтобы полностью отсортировать все цвета кубика Рубика 3x3, посмотрев на него в течение приблизительно 5 секунд. Если вы попросите его оценить, сколько времени займет сортировка, вы даете ему куб, запускаете часы, и через 5 секунд он скажет:

" хорошо, как только как только я начну, я буду готов через 10 секунд "

Ты улыбаешься и говоришь: "начинай!" Через 3 секунды вы просите его остановиться.. дайте ему еще один кубик Рубика и скажите.. лучше разберись вот с этим...

Через 4 секунды после того, как он начнет второй кубик Рубика, как вы думаете, сколько времени ему потребуется, чтобы снова отсортировать первый?

Если вы ответили приблизительно на 7 секунд, поздравляю: вы-высший управленческий материал!

(и Оливье имел бы полное право заставить тебя съесть это блюдо. кубики)

Я согласен с Simucal в том смысле, что менеджеры, как правило, делают лучше, когда вы разбиваете проблему на часы, а не на задачи программирования. Например, вы говорите своему боссу: "это займет около двух часов, но у меня есть еще несколько дел, которые я должен завершить в первую очередь, поэтому я должен передать их вам к завтрашнему дню."это намного полезнее, чем сказать:" Ну, сначала я должен разработать интерфейс для связи между объектами, а затем создать классы для реализации интерфейса, и так далее."Менеджеры понимают, что они могут видеть, поэтому в любое время, когда вы можете объяснить свою задачу с точки зрения конечных пользователей, вы, вероятно, будете иметь больший успех.

С учетом сказанного, не позволяйте своему менеджеру запугивать вас, заставляя давать обещания, которые вы не можете выполнить. Возможно, вы знаете, что все, что они хотят услышать, это: "я получу его к концу дня.но если вы знаете, что это невозможно, не говорите, что это возможно, надеясь, что если вы сделаете это в ближайшие пару дней, то это будет "достаточно близко". Если вы начнете учитывать время на проектирование и тестирование и давать им соответствующие оценки, в конце концов они начнут понимать, сколько времени требуется для выполнения определенных типов задач, и перестанут ожидать, что все будет сделано к вчерашнему дню. Я также заметил, что ощутимые результаты на этом пути, как правило, успокаивают их нервы (по крайней мере, временно). Мой босс начинает требовать готовых результатов, когда он начинает паниковать по поводу того, будет ли задача выполнена вовремя. Однако, когда он способен" видеть " шаг за шагом прогрессию, тогда он с большей вероятностью поймет, что мы, фактически, делаем прогресс, даже если он еще не в готовом продукте. Кроме того, когда вы начинаете этот процесс, постарайтесь взглянуть на вещи с их точки зрения и понять, что до тех пор, пока вы не достигнете точки, где вы можете потратить необходимое количество времени, вам, возможно, придется найти золотую середину. В моем опыте наступил момент, когда мне нужно было разработать кэш и хотя я бы с удовольствием потратил несколько недель на разработку и реализацию настраиваемого и расширяемого кэша, который мог бы быть широко распространен среди нескольких приложений, мне пришлось ограничиться этой задачей. Просто убедитесь, что если вы решили сократить масштаб или выполнить недальновидный проект, убедитесь, что он хорошо документирован, чтобы вы могли вернуться и исправить его, когда у вас будет время (или чтобы другой разработчик мог подхватить ход мысли, который вы не смогли закончить). Кроме того, не жертвуйте хорошими стандартами и стилем кодирования, так как это также облегчит поддержание и обновление вашего кода должным образом в будущем.

Удачи!

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

Сновидение в коде: два десятка программистов, три года, 4732 ошибки и один Поиск Трансцендентного программного обеспечения

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

Возможно, поможет разбивка задачи на подзадачи и предоставление им оценок.

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

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

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

И я полностью согласен с" это зависит " выше.