Как убедить руководство выбросить прототип?

Я люблю создание прототипов как быстрый и эффективный способ поставить пользовательский интерфейс перед пользователем.

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

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

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

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

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

...

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

Итак, попробуйте сделать свои прототипы в Photoshop вместо Visual Studio или что-то в этом роде.

Не создавайте прототип с рабочим кодом. Прототип с карандашом и бумагой, или программный эквивалент .

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

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

Никогда не ставьте под угрозу качество вашего кода.

Написание мусорного кода - ложная экономия.

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

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

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

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

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

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

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

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

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

И да, попросите их рискнуть, если они действительно знают лучше.

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

Скорее всего, с этими бонусами за производительность и будущими грантами на акции они будут слушать.

Обходите проблему в первую очередь. НЕ ЗАКОНЧИТЕ ЭТО. Под этим я подразумеваю, чтобы он не выглядел красиво или не подходил к существующим стилям на сайте. Цель состоит в том, чтобы просто получить наиболее грубую рабочую версию из всех возможных, чтобы вы могли видеть, что работает очень простой поток пользовательского интерфейса. Если вы добавите существующий стиль сайта или чрезмерно отшлифуете его, они будут предполагать, что вы можете просто «подключить его». Управление похоже на Pakleds из Star Trek. Они просто хотят, чтобы вы «сделали это». Чем больше вы готовы показаться, тем больше они будут думать, что это так.

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

В настоящее время я работаю над кодовой базой, в которой есть не два, а тройной стек Rails, .NET и Java. Причина, по которой мы взяли на себя Rails, заключалась в том, что в Rails был создан прототип, а главный представитель компании сказал: «Сделай это». Мы должны иногда говорить нет. Пока мы не делаем это все время, они должны относиться к нам серьезно.

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

Не беспокойтесь об этом.

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

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

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

И менеджменту, наверное, все равно.

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

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

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

Вы избавляетесь от скуки «приложения должны быть в java 1.6 с использованием Web (вставьте дорогой J2EE механизм выбора управления)» и бессмысленных стандартов именования и т. Д.

Мои текущие прототипы на выбор: «php» (который полностью масштабируется для мощных производственных сред - просто спросите Facebook) и очень элегантное сочетание Groovy / Java с Tomcat или Jetty.

Комбинация groovy / java отлично подходит для быстрого развития. Groovy хорошо использовать для быстрой разработки, но он работает как гериатрическая улитка, однако легко переориентировать критические разделы производительности на чистую Java. Свадьба с приложением в Tomcat или Jetty означает, что вам больше никогда не придется иметь дело с EJB и другими ужасами J2EE.

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