Получение непрограммистов, чтобы понять процесс разработки

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

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

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

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

Один подход, который я нашел успешным, заключается в следующем:

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

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

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

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

ИМО, я обнаружил, что прозрачность, обеспечиваемая гибкими процессами (например, Scrum, Crystal и т. Д.), Во многом показывает, как разработка работает для среднего заинтересованного лица.

Объяснение метафорой - это утечка, но вот некоторые идеи, которые часто работают для меня:

Обратите внимание, что ни одно из этих объяснений не оправдывает небрежную работу.

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

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

Наконец, я спрашиваю, могут ли Intel и Microsoft избежать ошибок, как они ожидают нас?

Я ответил на аналогичный вопрос более подробно , но суть в том, что «программирование похоже на строительство фабрики или конвейера».

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

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

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

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

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

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

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

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

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

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

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

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

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

Возможно, попробуйте пройти их, в идеале, в одиночку или в небольших группах, используйте те варианты программного обеспечения, которые вам нужно разработать. По мере того, как они описывают варианты использования, определите точки в случае, когда могут произойти разные вещи (неожиданные, но не неразумные случаи). Начните перечислять их, попросите дать некоторые разъяснения и проиллюстрируйте все решения и указания, которые необходимо принять или согласовать, и компромиссы, которые будут сделаны при этом. Продолжайте, пока они не озадачены и не могут дать вам ответ. Заставьте их понять, что то, что вы делаете с ними сейчас, это именно то, что вы делаете весь день, возможно, самостоятельно, возможно, с гораздо менее четким руководством, как при выборе курса, так и при написании кода, для сотен или тысяч случаи использования, которые могут или не могут быть изложены кем-либо. И когда там Если вы не думали о себе, вы не можете гарантировать, что программа сделает. Может быть, это делает "правильную" вещь, может быть, обратите внимание. И это то, что ошибка. И именно поэтому написание программного обеспечения требует времени. Чем меньше у вас времени, тем меньше случаев, которые вы имели возможность рассмотреть и учесть, и тем более вероятно, что программа не будет делать «правильные» действия в неизвестных обстоятельствах.

Стоимость и время.

Время

Установите ожидания, что вы поставите X в Y количество времени. У него не будет ничего больше, ни меньше. Затем скажите им, что будет в следующей версии. Поначалу они могут удивиться, полагая, что сборка X занимает Y времени - это то, где вы объясняете затраченное время и сложности создания программного обеспечения. Если они не удивлены, либо вы оценили очень мало времени, либо они знали лучше, чем вы думаете о создании программного обеспечения.

Стоимость

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

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

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

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