Есть ли хорошие метафоры для объяснения сложности проекта не-программисту?

Ответ 1

Некоторые метафоры...

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

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

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

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

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

Нейл ссылается на эссе Джима Уолдо, Software Engineering и Art of Design, в котором он указывает

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

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

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

Изменить: вы указали на относительную сложность между вашим проектом и "элементы управления рисованием в форме". Возможно, вы могли бы ответить на замечание Сикстинской капеллы, сказав "это правда". Однако, если трехмесячный веб-проект - это небольшой сарай за вашим домом, эта система управления грузовыми перевозками Rogers Centre.

Ответ 2

Спикер почти наверняка действительно означал "покраску Сикстинской капеллы [потолок]". Есть ли значимые параллели?

У Микеланджело были некоторые проблемы с лесами, предложенными оригинальным архитектором. Он конструировал свои собственные рамки.

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

Папа Юлий II первоначально хотел 12 рисунков, написанных апостолами. Микеланджело договорился о свободной раздаче по выбору предмета и поставил сцены Ветхого Завета, изображающие более 300 фигур. Он сам сделал всю картину.

В проекте постоянно кончались деньги (потому что папа продолжал вести войну с окружающими государствами).

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

Ответ 3

Я бы вспомнил старый анекдот, который я когда-то слышал:

Автомеханик спрашивает хирурга: "Почему вы так много зарабатываете? Что вы могли бы сделать так сложно? Моя работа с двигателями выглядит очень сложной и сложной для меня, и я в этом хорош! исправить что-то, что не так с движком!"

Затем хирург переходит, зажигается и запускает машину. Затем он смотрит на механика: "Ну, теперь исправьте это".

Ответ 4

Это не ракетная хирургия.

Ответ 5

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

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

Ответ 6

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

Для бухгалтера вы можете сказать что-то вроде: "Это похоже на то, что вы сами делаете калькулятор и проверяете Федеральный резерв США"

Ответ 7

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

Сначала он должен научиться ходить. Ходьба подпрограммы. Я не буду вдаваться в подробности, но он должен поставить ноги перед другим и сбалансировать его вес. Вы должны управлять исключением, где он падает или сталкивается с препятствием.

Затем ему нужна географическая спецификация по местонахождению супермаркета.

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

Если он найдет супермаркет, он должен найти морковь, используя алгоритм разведки моркови. Он должен сравнить каждый объект с 3D моделью моркови от его банка данных. Повторное время ожидания (или тайм-аут).

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

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

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

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

Затем наступает худшая часть. Вы не можете держать руку ребенка в течение всего процесса. Вы убедитесь, что у него есть все и отпустить его. 2 возможных результата: все работает отлично от начала до конца, как ожидалось (никогда не бывает), или ребенок сидит где-то посреди своей задачи, плачет, и вы не можете спросить его, что пошло не так. Он просто плачет и не останавливается. И затем начинается отладка.

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

Ответ 8

Нет.

Честно говоря, нет.

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

Ответ 9

Метафора, которую я часто использую с мирянами, заключается в том, что создание программного обеспечения не похоже на создание моста:

• Если вы строите мост, вы можете купить I-балки и заклепки, и вы можете налить стандартный бетон. Если вы строите программное обеспечение, вы должны сделать свои собственные I-лучи и заклепки, и вам, возможно, придется изобретать нестандартный бетон.

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

• Вы можете сказать, когда мост завершен наполовину. Вы не можете сказать, когда программное обеспечение выполнено наполовину.

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

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

Ответ 10

Прокрутите тысячи строк кода очень быстро для них. Скажем: "Если один персонаж ошибается, все это не сработает".

Другой:

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

Ответ 11

Я не могу с собой поделать, но я просто должен опубликовать это видео с этого Mitchell и Webb Look:

мозговой хирург - это Митчелл и Вебб Посмотрите, Серия 3 - BBC Two

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

Ответ 12

Основная цель бизнес-приложения - часто помогать коммуникации внутри организации. Поэтому, когда я пытаюсь описать сложность бизнес-приложения, я часто склонен нарушать повседневную деловую связь между человеком X и Y. И распылять его!

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

Надеюсь, это поможет =)

Ответ 13

Вы можете сравнить с предыдущими проектами программного обеспечения.

Помните, что старый проект X, и что это заняло около 6 месяцев? Ну, новый проект Y примерно такой сложный.

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

Еще лучше, если вы можете найти инженерные проекты, которые ваша компания сделала в качестве основы для сравнения, конечно, это зависит от их отрасли.

Ответ 14

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

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

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

Если у вас есть модульные тесты, возможно, выполните однострочный тест, а затем покажите им результаты ваших тестов (которые должны пройти все), а затем с красной полосой после красной полосы. "Там, вы можете указать. Посмотрите на все, что сломало одну строку кода. Мне нужно все время исправлять". Конечно, это придуманный пример.

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

Ответ 15

Это одна из моих любимых метафор для описания разработки программного обеспечения:

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

• Теперь представьте, что вы не строите дом, вы строите небоскреб со 100 этажами офисов. Как планы будут отличаться от планов дома? Каким образом материалы должны быть разными? Какие факторы необходимо будет тщательно рассмотреть?

• Теперь представьте, что вы сами не строите небоскреб, вы строите робота, который будет летать на Луну и строить там небоскреб. Теперь, как планы должны быть разными? Каким образом материалы должны быть разными? Вы видите, почему последствия каждого решения должны быть тщательно продуманы?

Вы можете заменить "небоскреб" на "систему управления грузом", если хотите, и я думаю, что метафора по-прежнему будет полезна.

Ответ 16

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

Цифры более понятны.

У вас есть число

• Элемент списка
• Использование футляры
• требования
• участвовали разработчики в подобных проектах
• компании или необходимые сторонние продукты
• Пользователь
• Сайты
• ...

Вам нужна синхронизация? Также полезно найти метафоры.

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

В чем сложность программирования ОС - я знаю, как ее использовать:) Недействительный ответ, правильно?

Удачи.

Ответ 17

Когда вы доставляете проект поздно из-за хромого управления проектами, создавая нереалистичные оценки... тогда полномочия, которые говорят

"Если мы добавим еще несколько программистов в проект, вы думаете, что со временем это получится?"

Вы можете ответить

"У моей жены есть ребенок, врач сказал, что это займет 9 месяцев, я спросил, использовали ли мы еще двух женщин, которые мы могли бы сделать в 3 раза?"

Рич

Ответ 18

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

Разве вы не знали, что ничего не сделали для жизни?

edit: Я получил голосу без всякой причины...

Ответ 19

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

• Найти свойство
• Ставка на собственность
• Купить недвижимость
• Возьмите строительную бригаду, чтобы построить корпус, похожий на другие McD's
• Найти и купить необходимое оборудование
• Установка оборудования
• Получить компьютеры
• Напишите торговое программное обеспечение.
• Поставьте компьютер в окно подъема и напишите код на xmit заказы на гамбургеры
• Записать программное обеспечение для карт времени
• Напишите программное обеспечение для расчета заработной платы.
• Установка и автоматизация системы безопасности
• Аренда квалифицированного экипажа
• Поезд экипажа
• Покупать акции
• Написать программное обеспечение для отслеживания запасов.
• Напишите программное обеспечение для прогнозирования заказов на акции.
• Etc.

Вы получаете идею. В развитии есть много вещей, которые средний Джо не понимает. Макдональдс выглядит как магия. Но там много чего происходит, когда вы запускаете (и сохраняете).

Ответ 20

Еще в 1982 году я проектировал новую ядерную электронику для тестовых машин для Intel. Это было для тестирования микроконтроллерных чипов (семейства микроконтроллеров 8X4X). Меня спросили, почему он так долго занимался парнем в разработке продуктов (я был в инженерной технике). Но за этим стоял вопрос. В то время я был всего один год из колледжа.

Я спросил его: "Вы когда-нибудь проектировали тестовую машину?"

Он быстро понял проблему с его вопросом.

Надеюсь, что это поможет.

JR

Ответ 21

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

Код - это выражение идей; разработчик, таким образом, имеет больше общего с тем, чтобы быть автором, чем быть инженером. Как уже упоминалось в других ответах, аналогия построения дома (или автомобиля или моста) не соответствует задаче. Мы, как люди, выбивали эти образцы на протяжении веков; мы разрабатывали программное обеспечение только на протяжении 60 лет (как отрасль для ~ 25). Если бы инженерия была твердой аналогией для разработки программного обеспечения, у нас не было бы проблем, связанных с оценками.

Ответ 22

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

Например, они считают, что отчет о количестве отправленных контейнеров довольно прост, потому что они просто выбирают диапазон дат и число. Расскажите им о том, как код должен искать контейнеры, которые еще не достигли пункта назначения, он должен проверить, не были ли контейнеры отправлены отправителю, если контейнер хранился таможней, потому что он выглядел подозрительным, тогда вам нужно подключитесь к веб-службе Таможенного ведомства, чтобы проверить статус контейнера, вам нужно игнорировать контейнеры, которые были отменены, контейнеры, которые были потеряны в море, потому что затонувшее судно считается отправленным, но только если судно затонуло более 120 морских миль от побережья США, Великобритании, Франции, Японии или Китая или в 30 морских милях от побережья любой другой страны, контейнеры, уничтоженные во время дорожно-транспортного происшествия, подсчитываются, если водитель грузовика не виноват, контейнеры, которые просто пропавшие без вести, не учитываются до тех пор, пока они не будут потеряны в течение как минимум 6 месяцев и т.д.

Это дает людям представление о подавляющем числе "мелких деталей", которые должен учитывать программист, даже в явно простых программах.

Ответ 23

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

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

Ответ 24

Возможно, вы не можете сказать, почему это сложно, но вы можете ссылаться на труд по сложности.

вы можете сказать, что он настолько сложный, что 10 человек должны работать над этим проектом 2 года?

Ответ 25

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

Ответ 26

Я мог бы избежать метафоры дома. Когда мы построили наш дом 3 года назад, мы были в ужасе от того, насколько он отличается от инженерного проекта. Я клянусь водопроводчиком, и один из плотников-плотников, должно быть, был пьян.

Покажите этому парню свои функциональные спецификации. Он начнет понимать, сколько деталей связано с созданием приложения.

Ответ 27

Программирование включает в себя множество условий и действий, расположенных сверху друг друга. Если одно условие не соответствует 100%, программа может выполнить неправильное действие. И компьютеры не прощают.

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

По мере роста проекта шахматная доска растет, а необходимость совершенствования становится экспоненциально сложнее для одного программиста.

Ответ 28

В одном из интервью я помню, как Моби говорил что-то о влиянии...

Иногда мне кажется, что я должен перефразировать "Все неправильно" на "Все сложно".

Это программное обеспечение.

Или они действительно читают, дайте им:

Я пою Body Electronic: Год с Microsoft на границе мультимедиа, которая, вероятно, является лучшей книгой, которую я прочитал, которая могла бы дать непрофессиональное понимание развития программного обеспечения. (На самом деле, как не основной CS, это была одна из книг, которые заставляют меня оставаться с программным обеспечением).

Ответ 29

В некоторых проектах мне кажется, что я пытаюсь поместить осьминога в маленькую коробку. И с некоторыми проектами я чувствую, что собираю головоломку из бегущего фильма. Наверное, не метафора для объяснения чего-либо клиенту, хотя:)

Ответ 30

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

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