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

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

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

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

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

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

Во многом как мастер-шахматист предвидит ходы своих оппонентов, задача программиста - предвидеть каждый сценарий и учитывать его в коде.

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

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

Разве вы не знали, что ничем не зарабатываете на жизнь?

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

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

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

Это программа.

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

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

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

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

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

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

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

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

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

Он быстро осознал проблему, возникшую в его вопросе.

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

JR

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

1. Найти недвижимость
2. Сделать ставку на собственность
3. Купить собственность
4. Заставить строительную бригаду построить здание из каркаса, похожее на другие McD
5. Найдите и купите необходимое оборудование
6. Установите оборудование
7. Получите компьютеры
8. Напишите программное обеспечение для точек продаж
9. Поместите компьютер в окно подъезда и напишите код, чтобы отправлять заказы на ласты для бургеров
10. Написать программное обеспечение для тайм-карт
11. Напишите программное обеспечение для расчета заработной платы
12. Установите и компьютеризируйте систему безопасности
13. Наймите компетентную команду
14. Обучайте команду
15. Купите запасы
16. Напишите программное обеспечение для отслеживания запасов
17. Напишите программное обеспечение для прогнозирования заказов сток
18. И т. д.

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

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

Цифры легче понять.

Есть ли у вас несколько

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

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

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

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

Удачи

Говорящий почти наверняка имел в виду « роспись Сикстинской капеллы [потолок]». Есть ли какие-нибудь значимые параллели?

Микеланджело имел некоторые проблемы с строительными лесами, предложенными первоначальным архитектором. В итоге он построил свой собственный каркас.

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

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

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

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

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

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

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

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

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

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

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

Затем ему нужно географическое указание местоположения супермаркета.

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

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

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

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

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

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

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

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

Нет.

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

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

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

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

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

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

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

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

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

Другой:

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

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

Brain Surgeon - That Mitchell & Webb Look, Series 3 - BBC Two

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

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

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

Затем хирург подходит, включает зажигание и заводит машину. Затем он смотрит на механика: «Ну, а теперь почините».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рич

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

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

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

Если у вас есть модульные тесты, возможно, сделайте однострочный тест, а затем покажите им результаты ваших тестов перед (который должен все проходить), и после с красной полосой после красной полосы. «Вот, можешь указать. Посмотри на все, что сломала одна строчка кода. Я должен исправить все там». Конечно, это надуманный пример.

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

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

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

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

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

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

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