Як ви переконуєте керівництво відкинути прототип?

Я люблю прототипування як швидкий ефективний спосіб поставити інтерфейс користувача перед користувачем.

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

Як вам вдається управління не робити цього?

Використовуйте такий інструмент, як Microsoft SketchFlow , або зробіть свій прототип якоюсь іншою мовою чи платформою, що робить його майже неможливим інтегрувати в основну розробку.

Також є нарис joelonsoftware про показ скріншотів та прототипів, де він робить нездійснені, а незроблені аспекти виглядають явно порушеними / не виконаними, що дає зрозуміти, де ще потрібно виконати роботу.

Важливі наслідки два. Якщо ви покажете непрограмеру екран, який має користувальницький інтерфейс на 100% гарний, вони подумають, що програма майже зроблена.

...

Що ви можете з цим зробити? Після того, як ви зрозумієте секрет Айсберг, з ним легко працювати. Зрозумійте, що будь-яка демонстрація, яку ви робите в затемненій кімнаті з проектором, буде стосуватися пікселів. Якщо можете, побудуйте інтерфейс користувача таким чином, щоб незакінчені деталі виглядали незавершеними. Наприклад, використовуйте scrawls для піктограм на панелі інструментів, поки функціональність не існує. Під час створення веб-сервісу ви можете розглянути можливість фактичного виходу з домашньої сторінки, поки ці функції не будуть створені. Таким чином, люди можуть спостерігати за тим, як домашня сторінка переходить від 3 команд до 20 команд, оскільки все більше створюється.

Отже, спробуйте зробити свої прототипи у Photoshop замість Visual Studio, або щось у цьому напрямку.

Не прототип з робочим кодом. Прототип з олівцем і папером, або програмний еквівалент .

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

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

Ніколи не посягайте на якість вашого коду.

Написання небажаного коду - помилкова економія.

Як свідчать інші плакати, ви можете досягти цього, використовуючи спеціальні інструменти для макетів.

Однак існують різні причини побудови прототипів. Іноді ви можете показати, що вам потрібно, не записуючи код, але часто це не так. Зацікавлена ​​сторона може захотіти, щоб ви продемонстрували технічну доцільність функції.

Побудуйте абсолютну найпотужнішу річ, яку ви можете продемонструвати, ознака / доведення концепції. Залиште все інше.

Що стосується функції інтерфейсу, переконайтеся, що ви нічого не розробляєте на сервері - не торкайтеся цього взагалі. Знову розробляйте вбудовані макети / підробки.

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

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

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

Тоді, якщо менеджмент почне змушувати вас знижувати якість, ви повинні запитати себе, чому. Вони пасивні? слабкий? відчайдушно? Жодна з цих речей не є вагомими причинами триматися в компанії.

Дуже просто насправді. Скажіть їм, що вони в кінцевому підсумку втратять улюбленого клієнта, якщо вони в кінцевому підсумку виставлять цю баггічну безлад для показу.

І так, попросіть їх ризикувати, якщо вони дійсно знають краще.

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

Ці шанси, що ці бонуси за продуктивність та майбутні грантові акції сьогодні будуть слухати.

Убік проблеми в першу чергу. НЕ ЗАКОНУЙТЕ ЇЇ. Тобто я маю на увазі не робити це красивим або подобатися, що це підходить до існуючих стилів на сайті. Мета полягає в тому, щоб отримати максимально грубую робочу версію цієї програми, щоб ви могли бачити, що саме основний потік інтерфейсу працює. Якщо ви кинете на нього існуючий стиль сайту або надмірно шліфуєте його, вони припускають, що ви можете просто "підключити його". Менеджмент схожий на Пакледса зі Star Trek. Вони просто хочуть, щоб ви "змусили його". Чим готовіше ви здаєтеся, тим готовішими вони вважатимуть це.

Якщо це не вирішує вашу проблему, влаштуйтеся на роботу хоча б в одну компанію з відомим брендом протягом року. Покладіть свою електронну пошту та номер на резюме в Інтернеті, і ви будете боротися з рекрутерами назад палицею, що дасть вам змогу сказати їм "абсолютно не" з впевненістю у біса, який знає, що вони роблять, і може отримати нову роботу завтра, де, сподіваємось, ваша експертиза з цього питання сприймається серйозніше.

Зараз я працюю над кодовою базою, яка має не дві, а потрійну стек-хам з Rails, .NET та Java. Причиною, по якій ми зачепили Рейки, було те, що прототип був зроблений в Рейлах, а топ-собака в компанії сказала "примусимо йти". Нам потрібно сказати ніколи. Поки ми не робимо це весь час, вони повинні сприймати нас серйозно.

Але так, що б ви не зробили з прототипом, переконайтеся, що він починається справжньо потворно.

Не хвилюйся.

Якщо ви сідаєте і кидаєте елементи керування інтерфейсом для "прототипу", це абсолютно нульова причина, коли ви завжди автоматично відкинете цю конструкцію. Якщо це було досить добре, щоб показати управління, то це гарне місце для початку, коли кодувати "справжню" програму.

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

Жодна з цих причин не є "ну це був просто прототип". У дизайні користувальницького інтерфейсу або в коді або в письмовій формі, будь-що може закінчити життя назавжди. А ті, що не всі, повинні мати дуже вагомі причини, щоб їх вбити.

І менеджмент, мабуть, не хвилює.

Реально, якщо ви не просто занесли свій інтерфейс до існуючого коду, це "я повинен був переписати його в наші правильні рамки", це повинно бути достатньо причини. А якщо це не так, ви, мабуть, мали б обговорити самі рамки інтерфейсу, але це вже інше питання.

У мене раніше виникала ця проблема, поки я не зрозумів, що це не проблема, а спосіб звільнення себе від досить застарілих стандартів розвитку, що застосовуються для більшості магазинів.

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

Ви уникаєте нуди "програми повинні бути в java 1.6 за допомогою Web (вставити дорогий J2EE двигун вибору управлінців)" та безглуздих стандартів імен тощо.

Мої поточні мови-прототипи на вибір - "php" (що повністю відповідає масштабним виробничим умовам - просто попросіть Facebook) і дуже елегантне поєднання Groovy / Java з Tomcat або Jetty.

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

Основною перевагою наявності робочого прототипу на відміну від ескізу, запропонованого кількома афішами, є зворотній зв'язок з користувачем. Прототипи - це чудовий спосіб залучити бізнес по-справжньому до дизайну. Як тільки вони зрозуміють, що вони можуть сказати такі речі, як "не повинно це поле бути на головному екрані", і так! там він знаходиться на головному екрані під час наступної демонстрації, і вони відкриваються та беруть участь у розробці дизайну, що приносить багато цінний діловий досвід проекту.