Практика использования интерактивного прототипа на этапе коммерческого предложения

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

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

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

    Наши шаги


    1. Читаем конкурсную документацию
    2. Выделяем небольшую, но интересную на наш взгляд функцию системы, имеющую представление в пользовательском интерфейсе
    3. Изучаем предметную область всеми доступными способами
    4. Тянем с сайта заказчика корпоративный стиль (логотипы, типографика, иконки, цвета и т.д.)
    5. Делаем прототип веб-интерфейса системы в корпоративном стиле
    6. Запускаем прототип и снимаем видео с экрана, попутно сопровождая голосовым комментарием.

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



    Вы можете скачать запускаемый прототип и самостоятельно пощупать его (для запуска нужно открыть файл designerviewer.exe) либо скачать рабочий прототип, который можно посмотреть «изнутри» (для его открытия нужно скачать и установить GUI Machine Demo)

    Подытожим


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

    Это уже может многое сказать заказчику о вас и склонить чашу весов в вашу сторону. Естественно, это срабатывает не всегда. Как бы то ни было, нужно помнить, что на этапе коммерческого предложения тратить на прототип много времени недопустимо. В зависимости от размера проекта — от нескольких часов до двух-трёх рабочих дней. Не выбирайте большие функции. Не страдайте фанатизмом и не занимайтесь pixel-hunting'ом.

    Почему даём заказчику видео, а не сам прототип?


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

    Комментарии 21

      +5
      Отличный подход! Особенно меня порадовала идея внедрить корпоративный стиль — так заказчик сразу почувствует вашу работу как часть своего бизнеса… останется только заплатить деньги =)
        +4
        Эх, если б все заказчики мыслили также… :)
          +1
          Говорят, бывают такие заказчики, которым, например, готовые дизайн с вёрсткой (и тем более частично написанным JS) показывать вообще нельзя, потому что им кажется, что работа почти закончена (и остаётся только «немножко» доделать, чтобы всё заработало).
            +2
            На этапе коммерческого предложения уж очень маловероятно, что заказчик подумает о том, что система почти готова. На этом этапе ещё исполнитель не выбран :)

            А на других этапах вы можете доходчиво объяснить, а вменяеный заказчик вполне способен понять, что это лишь прототип и до готовой системы ещё далеко.
        +1
        А если не закажут у вас, каков убыток от разработки прототипа?
          +2
          Стоимость нормочаса сотрудника, разработавшего прототип * количество затраченных часов
            0
            Поэтому
            нужно помнить, что на этапе коммерческого предложения тратить на прототип много времени недопустимо. В зависимости от размера проекта — от нескольких часов до двух-трёх рабочих дней. Не выбирайте большие функции. Не страдайте фанатизмом и не занимайтесь pixel-hunting'ом
            0
            Если в компании прототип разрабатывают дизайнер+кодер+манагер, который им еще ставит задачу, убыток большой в любом случае. У нас прототипы рисуют менеджеры проектов и консультанты, т.е. непосредственно те сотрудники, которые общаются с клиентом.
              +1
              Под консультантами имеете ввиду ux-дизайнеров? Свои или отдаете на аутсорс?
                +1
                Под «консультантами» я подразумеваю продающих и консультирующих менеджеров и еще продакт-менеджеров. UX-дизайнеров в штате нашей компании нет, есть классический графический дизайнер, рисующий интерфейсы, кнопочки мулечки, но прототипированием она не занимается.

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

                Теперь про прототипы и манагеров. Наше глубокое убеждение, что на этапе сбора требований, иногда проектирования системы, особенно если речь идет просто о кастомизации веба UX-специалисты не нужны. Их функции могут на себя взять менеджеры и консультанты, которые раскладывают проекты на UML-ные диаграммы и заодно накидывают интерфейсы, сразу утрясая их с заказчиком. Конечно для такого подхода нужны определенные навыки и соответствующий продукт, такой как GUI Machine. Схема абсолютно рабочая, мы по ней работаем уже не первый год.

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

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

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

                ИМХО, для заказчика в коммерческом предложении важен первым делом факт, что исполнитель понимает задачу и готов с ней справиться. На втором месте — деньги и время. И когда мы говорим о внешнем виде и показываем прототип, в первую очередь речь идет о функциональной составляющей т.к. картинку мы берем уже привычную для заказчика. Т.е. показывая окно, описанное в нашем видео (см. выше) мы спрашиваем, правильно ли мы поняли требования заказчика, что в веб-интерфейсе удаленного оператора банка должны быть такие функции?

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

                Видео-презентации компании и системы, и пользовательские документы никак не подскажут клиенту каким образом мы решим его проблемы.
                  +1
                  Гарантией может выступить залог в размере определенной суммы.

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

                  Допустим, вы сделали чек-бокс, а представители ранее тестировали подобное решение и им не понравилось использовать чек-боксы. Ваше решение могут не выбрать, просто потому, что понравилось решение с выпадающим меню.
                    +1
                    Гарантией того, что исполнитель справится? В предлагаете в банковскую ячейку класть денежную гарантию от исполнителя и аванс от заказчика и по завершении этапа решать кто заберет деньги? Я понимаю как это работает на госбюджетных проектах куда лезут все в том числе и демпингующие фирмы однодневки, но будет ли такое работать при реализации сложных коммерческих проектов? Вы сами, Николай, пробовали денег давать за работу которую беретесь выполнить?

                    В конкретном примере с банком мы как и все остальные участники получили предварительные требования клиента в том числе о реализации интерфейса сканирования документов заявителей кредит. Был предоставлен перечень документов к сканированию. И если все наши конкуренты написали текстом что они могут это сделать, мы кроме текста выслали видео как мы можем это реализовать. Опять же на этапе коммерческого предложения ни о какой полноте реализации функций речи идти не может, это понимает и заказчик т.к. высылает не конечный а предварительный перечень требований. Детализация требования будет проводиться после подписания контракта на предпроекте результатом которого будет ТЗ. Вот там будет все написано полно и детально.
                  +1
                  Видео-презентации компании, обзор возможностей программного продукта, документы — разве этим можно удивить и привлечь внимание? Это же есть у всех. А вот видео-презентация прототипа, выполненного в корпоративном стиле заказчика и демонстрирующего вполне конкретную функциональность планируемой заказчиком системы — это совсем другое. Тут принцип «давайте снимем фильм, а какой — неважно» — не работает.

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

                  Что касается сотрудников заказчика, которые «не понимают» или «могут подумать». Эти вопросы просто решаются общением с заказчиком. Люди в конце-концов не глупые
                    +2
                    Есть такой пример из моей практики, не относящийся к работе, наоборот я выступал заказчиком. Имеется земельный участок на котором хочется построить жилое здание. Для выбора архитектора проектировщика изучил множество предложений в интернете и присланных на почту. В конечном итоге предпочтение отдал архитектору, приславшему его видение конфигурации и посадки здания на моем участке. Этот исполнитель помимо цен сроков и др условий потратил суток своего времени на работу в графическом редакторе и этап выделил себя. Работаем с этим подрядчиком уже не первый год и он выполнил мне уже два проекта.
                  +3
                  Эх, Рустем, Рустем!
                  как так!? в отделе тестирования не используется прототип?
                  как раз таки это второе наше оружие после технического задания!

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

                  Так и последующее функциональное тестирование, тоже осуществляется на основе прототипов.

                    +1
                    Виноват, не уследил, теперь буду чаще заходить к QA в гости :)
                      +1
                      Мария, не будь такой категоричной. Рустем в статье не писал, что «прототипы в отделе тестирования у нас не используются»! Он написал, что «РЕЖЕ», чем на этапах сбора требований, проектирования и разработки. «НЕ» и «РЕЖЕ» — большая разница, так что не надо передергивать. Другой вопрос, что с аргументацией причин редкого использования можно дополнительно поработать. Думаю, не в детальности проработки прототипа дело.
                        +2
                        Станислав, ни в коем случае не думала передергивать,
                        просто хотела сказать, что используем и очень даже часто, иногда даже чаще программистов.

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

                    Самое читаемое