Практика прототипирования в софтверной компании

    imageНет, это статья не об игре про заражённый вирусом Манхэттен и его мутантов. Речь пойдёт о прототипах другого рода — прототипах программного обеспечения.

    Прототипирование ПО становится всё более популярным и часто используемым процессом в российских IT-компаниях. Причины видятся следующие: с одной стороны – это определенная дань моде, с другой – прототипирование обещает компании ряд весомых преимуществ.

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

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

    Когда и как использовать прототипы? Теории и практики


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

    SWEBOK (Software Engineering Body of Knowledge). Свод знаний по программной инженерии
    Первое упоминание прототипирования в своде знаний встречается в главе Программные требования в секции Извлечение требований в теме Техники извлечения требований как один из подходов к извлечению требований. Говорится, что прототипы – это отличный инструмент для уточнения и/или детализации требований.

    image

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

    Таким образом формулируется первая цель прототипирования – решение проблемы недопонимания между аналитиком и пользователем. Упущение тех или иных аспектов, неоднозначность или тем более некорректность интерпретации информации, полученной от пользователей – все это наиболее типичные причины “сверхзатрат” (времени, денег и т.п.), а иногда и полного провала проектов. Первая задача прототипирования – не допустить этого.

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

    image

    IEEE 830-1998. Рекомендации IEEE по разработке требований к программному обеспечению
    Процесс прототипирования в этом стандарте также рассматривается как инструмент извлечения требований и улучшения спецификации требований. Согласно стандарту, прототипы полезны по следующим причинам:
    1. Потребитель может предпочесть посмотреть и оценить прототип, нежели читать и оценивать SRS. Поэтому прототип обеспечивает быструю обратную связь.
    2. Прототип демонстрирует неожиданные аспекты поведения системы. Таким образом, он не только дает ответы, но и задает новые вопросы. Это помогает более полно проанализировать SRS.
    3. SRS, основанная на прототипе, имеет тенденцию меньше подвергаться изменениям во время разработки, тем самым сокращая время разработки.

    Мнения специалистов
    В публикациях «по теме» я впервые встретил мысли об использовании прототипов за рамками этапов сбора требований и проектирования.

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

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

    Промежуточные итоги. Выжимка из теории

    Итак, на основе анализа источников можно выделить следующие варианты использования прототипов:
    • Как инструмент извлечения, проверки и утверждения требований на этапе работы с требованиями
    • Как основу для написания SRS и ТЗ на этапе проектирования
    • Как технику проверки программного дизайна на этапе проектирования
    • Как объект исследования юзабилити-тестирования на этапе тестирования
    • Как образец для разработчиков на этапе реализации (конструирования)

    Но мы используем прототипы ещё более широко – добавлю к перечисленным ещё 4 наших варианта.

    Как ещё можно использовать прототип?

    На этапе коммерческого предложения

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

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

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

    Как образец при тестировании готового ПО

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

    Как образец при приёмке-сдаче работ

    Здесь уже больше используем прототип не мы, а наши заказчики. При приёмке работ они теперь помимо, а иногда и вместо проверки функций по ТЗ, сравнивают реализованную систему с прототипом. Это выгодно обеим сторонам. Заказчик вправе предъявить претензии, если в реализованной системе что-то не так, как в прототипе. Но и мы как исполнитель можем защитить себя от претензий, если реализуем систему точно так же, как в прототипе. У заказчика просто не будет оснований быть недовольным. Таким образом, исполнитель отдаёт, а заказчик получает ровно то, что было согласовано – ни больше, ни меньше. Никто не делает лишней работы, и все довольны.

    Как пример решения для демонстрации потенциальным заказчикам

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

    Жизненный цикл прототипа

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

    image

    1. Установление контакта с потенциальным заказчиком и получение предварительной информации от него. Менеджер создаёт небольшой интерактивный прототип. Сам, пока без привлечения дизайнера. Отправляем коммерческое предложение вместе с видеозаписью прототипа.
    2. Если мы выбраны в качестве исполнителя проекта, то поручаем дизайнеру отрисовать UI-компоненты и дорабатываем прототип. Идём к заказчику с обновлённым прототипом. При этом, если заказчик и пользователи – разные лица, мы просим допустить нас к конечным пользователям: они прямо на прототипе показывают, что им нравится, а что они хотят изменить. Таким образом мы собираем требования, в соответствии с ними изменяем прототип и опять идём к пользователям. За несколько итераций прототип, и, соответственно, функциональность, согласована.
    3. Когда функциональность согласована, мы просим пользователей указать функции, которые им выполнять неудобно, некомфортно, непривычно. Исправляем прототип в соответствиями с замечаниями. Это своего рода юзабилити-тестирование.
    4. Параллельно с общением с пользователем согласовываем прототип и с разработчиками. Узнаём, возможно ли и насколько сложно реализовать то, что показано в прототипе. Если какую-то функцию реализовать невозможно – тогда придумываем альтернативный вариант и согласовываем с заказчиком. В конце концов получаем прототип, согласованный как с заказчиком, так и с разработчиками.
    5. Снимаем с прототипа скриншоты и делаем на их основе ТЗ.
    6. Отдаём ТЗ и прототип разработчикам. Разработчики реализуют систему, используя прототип в качестве образца.
    7. Готовая система и её прототип отдаются тестировщикам. Они также используют прототип в качестве образца.
    8. Сдаем систему заказчику. Он проверяет, соответствует ли реализованная система прототипу.
    9. Прототип уходит в архив. Но если заказчик просит доработку, ты мы достаём прототип и дорабатываем его с учётом новых требований. И дальше вновь по циклу со второго шага.

    Последствия прототипирования


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

    Если раньше процесс передачи информации выглядел примерно так:

    image

    то сейчас он представляет собой что-то вроде этого:

    image

    Картинки позаимствовал из презентации Геннадия Драгуна, за что ему премного благодарен.

    Прототипы бывают разные...


    Существует множество мнений о том, что нужно/можно считать прототипом и какими характеристиками он должен обладать. Чтобы не выставлять своё субъективное видение за истину, я опять обращусь к своду знаний SWEBOK. Он говорит, что прототипом могут считаться как “бумажные” модели, так и пилотные подсистемы, реализуемые как самостоятельные (в терминах управления ресурсами) проекты или бета-версии продуктов.

    Прототипы можно разделить на 2 большие группы в зависимости от способов их создания и последующего использования:
    • Одноразовые прототипы
    • Эволюционные прототипы

    image

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

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

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

    Какие прототипы мы используем?

    Одноразовые прототипы делятся в свою очередь по:

    • степени интерактивности,
    • детализации, точности, близости к конечному дизайну.


    image

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

    Прототипирование на постсоветском пространстве


    Теперь краткая информация о распространении и тенденциях прототипирования в России и странах СНГ. Как показывает опрос, проведённый Павлом Коноплицким на Хабре, в половине компаний процесс прототипирования вообще отсутствует.

    image

    Однако радует осознание того, что ситуация с прототипированием в компании неудовлетворительна. Это видно по результатам другого опроса: более 70% опрошенных не удовлетворены текущей ситуацией и почти половина из них находится на данный момент в поиске хорошей методики и инструмента. Хорошая тенденция.

    image

    Кто должен прототипировать?


    Вернёмся к первому опросу. Если смотреть на исполнителей, прототипированием в большинстве проектов занимаются технические специалисты. Для меня это стало неожиданностью: как я уже сказал, большинство стандартов и публикаций рассматривают прототипирование в первую очередь как инструмент для извлечения и утверждения требований. А кто занимается сбором требований? Менеджер или аналитик, но никак не технический специалист. Если это будет делать он – у нас опять появятся большие потери информации, менеджер будет играть роль сломанного телефона. Поэтому мы считаем, что прототипировать должен именно менеджер, как центральное звено команды проекта и как лицо, непосредственно контактирующее с заказчиком. В нашей компании должность менеджера и аналитика объединена, что является ещё одним фактором в пользу прототипирования менеджерами.

    Как мы делаем прототипы?


    Мы поставили перед собой два условия: во-первых, прототипы должны быть интерактивными, во-вторых, прототипировать должны менеджеры. Нам нужен был инструмент, который позволяет создавать интерактивные прототипы без программирования, т.к. менеджеры в общем случае не умеют программировать. Пробовали Visio – но интерактивность созданных в нём прототипов была невысокой. Пробовали GUI Design Studio. Но и он не прижился.

    imageВ итоге мы пришли к собственной разработке и сделали её такой, какой хотим видеть инструмент прототипирования. Если не хватало каких-либо функций – добавляли. В итоге разработка доросла до качественного продукта, и мы выпустили его на рынок. Назвали GUI Machine. Сейчас это кроссплатформенный инструмент прототипирования, который позволяет создавать интерактивные прототипы декстоп и веб-приложений без программирования.

    Использование для создания прототипов собственного инструмента имеет как положительные, так и отрицательные стороны. Минусом для компании является необходимость выделения ресурсов на развитие GUI Machine. С выводом продукта на рынок количество необходимых ресурсов только увеличиваются: инструмент нужно продвигать, развивать, поддерживать. Преимущества своего продукта в том, что мы можем сделать инструмент таким, каким мы хотим его видеть. Кроме того, продукт начал приносить коммерческую прибыль.

    Зри в корень. Ищи ответы


    Хочу отметить, что инструмент – это всего лишь средство обеспечения процесса прототипирования. Первичен именно процесс. Без построенного и отлаженного процесса ни один инструмент прототипирования «не выстрелит». Сначала нужно ответить на вопросы:
    • для чего прототипировать?
    • кто должен прототипировать?
    • когда нужно прототипировать?

    И уже потом решать, с помощью чего это делать. Только тогда к вам придёт понимание того, какой инструмент вам нужен.

    Прототипировать ли?


    В качестве итогов – плюсы и минусы от внедрения процесса прототипирования.

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

    +
    • Новый уровень коммуникации с заказчиком и внутри компании
    • Ошибки, допущенные в начала проекта и обнаруженные в его конце – самые дорогие. Прототипирование позволяет обнаружить допущенные ошибки на ранней стадии и минимизировать появление новых
    • Повышение качества за счёт снижения количества ошибок
    • Уменьшение сроков и стоимости разработки за счёт разработки «с первого раза» без необходимости доработки – экономия дефицитного времени разработчика
    • У пользователей не возникает отторжения, поскольку они уже знакомы с прототипом, и интерфейс системы не становится для них сюрпризом
    • Пользователей, поработавших с прототипом, не нужно обучать работе с системой
    • Повышение лояльности заказчика.

    Цифры

    Трудно подбивать все проекты под одну шкалу: все они очень индивидуальные, сильно различаются по длительности и стоимости, а также по раскладке работ при разработке. Поэтому приведённые ниже цифры носят оценочный и усреднённый характер:
    • Сроки на работу с требованиями и проектирование увеличились на 50%
    • Сроки реализации сократились на величину от 20 до 35%
    • Сроки тестирования сократились на 30%

    В наших проектах работа с требованиями и проектирование занимают около 30% всей длительности проекта, реализация – около 40%, тестирование – около 30%. Исходя из этого, можно вычислить, что общее время проекта сократилось на величину от 2 до 8%.

    image

    Это только сухие цифры, но, как я уже говорил, прототипирование даёт далеко не только уменьшение сроков.

    Вывод

    Для нас процесс прототипирования стал однозначно выгодным и полезным.

    Если вы ещё не прототипируете – попробуйте, не пожалеете.
    ALEE Software 40,93
    ПО для электронных архивов и библиотек, оцифровка
    Поделиться публикацией
    Комментарии 25
    • –11
      Играл в Prototype, мне понравилось
      • –10
        сразу столько минусов, никому игра не нравится?
      • +6
        600€ за бессрочную однопользовательскую лицензию в России? И это после слов, очевидно одного из участников проекта:

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

        Я бы предпочёл http://www.axure.com/
        • +3
          Ну да, простите. Я и забыл, что это корпоративный топик, где нужно хвалить продукт.
          • 0
            Что же в этом топике корпоративного? Если вы продукт поругаете, я ваш коммент ни удалить, ни закрыть аккаунт, даже внести ваш айпишник в блэклист не могу :) Есть немного маркетинга, но как же без него?
            • +4
              Как хорошо, что остались в мире борцы за справедливость, в пух и прах разоблачающие эти гнусные коммерческие компании и их жалкие замыслы!
            • 0
              600€ за бессрочную однопользовательскую лицензию в России? Я бы предпочёл www.axure.com/

              Так никто не мешает. Статья не про продукт, а про подход. Выбирайте axure, visio, notepad, бумагу учите работать с ним своих сотрудников и прототипируйте!

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


              Узнаю автора :) Цитируемая фраза немного выдрана из контекста, см. полный вариант. Тем не менее от слов не отказываюсь, в первый раз все так и было, однако после 4х часового инструктажа самостоятельно нарисовал кликабельный прототип виндового меню «Пуск» в варианте один-в-один. Думаю, не плохо для начинающего интерфейсера.
            • +3
              Про «мнение специалистов». Мне сразу вспомнилась давнишняя статья Спольски в пользу бумажного прототипирования.

              Отдельное спасибо за SWEBOK. До сегодняшнего дня даже не подозревал о существовании такой штуки. Хотя, конечно, советы от 2004-го года следует воспринимать с переосмыслением :)
              • 0
                Возможно, Вам будет интересно его посравнивать с образовательным стандартом SE2004 (http://sites.computer.org/ccse/SE2004Volume.pdf), то есть сравнить целевой объём знаний с предлагаемым путём его обретения.
                Перевод SWEBOK есть тут: swebok.sorlik.ru/
                • 0
                  Вы имеете в виду, что советы 2004-го года устарели? Не соглашусь. Большинство описанных в стандарте практик и на сегодняшний день являются актуальными. Более того, многие российские компании ещё не доросли до того уровня развития, чтобы процессы компании соответствовали описанным в стандарте.
                  Нам есть чему учиться у зарубежных коллег :)
                • 0
                  Вообще работа с прототипированием, как мне кажется, требует более тщательного контроля за прохождением проекта. На последнем графике, например, мы видим, что время тестирования сократилось, что понятно, поскольку части прототипа так или иначе тестировались в процессе. На практике же, когда сроки уже сильно профуканы, прототипирование может запросто привести к тому, что заказчик этот самый наполовину доделанный и кое-как оттестированный прототип и получит, особенно когда куча вышестоящих менеджеров плохо понимает разницу между прототипом и продуктом. Возможно, это не так сильно относится к продуктам, где прототипирование и разработка происходит с использование различных инструментов, но если для прототипа и окончательного продукта используются одни и те же инструменты разработки, то такая опасность есть. Мы используем прототипирование, но стараемся по возможности не использовать код прототипа в релизах.
                  • 0
                    Это одна из причин, почему мы используем одноразовые, а не эволюционные прототипы. В нашей ситуации ну никак нельзя выдать прототип за конечный продукт.
                  • 0
                    mockupbuilder.com/ — вот классная софтина. Как начал ей пользоваться, забыл все эти axure как страшный сон :)
                    • 0
                      Ваш проект это тоже отклонение в сложную сторону. Идеология прототипирования как части реализации. Мне же ближе подход скетчей, из них идеи понятны намного лучше, а трудоемкость меньше в разы.
                      • 0
                        Выбор инструмента зависит от того, как вы используете прототипы, каковы особенности процесса разработки в компании, какого рода проекты вы делаете и т.д. Я имею в виду, что нельзя угодить всем. То что подходит одним — совершенно не нужно другим.
                        Например упомянутый инструмент предназначен для создания скетчевых, недетализированных прототипов с минимальной интерактивностью. А что если заказчик потребует детализированный и полностью интерактивный прототип?
                        • 0
                          Тогда лучше будет делать его сразу в IDE, чтобы не делать одну работу два раза.
                          • 0
                            По нашему мнения и опыту прототипы должны делать менеджеры или аналитики, но никак не разработчики. Трудно себе представить себе такого менеджера, который легко накидывал бы интерфейсы в IDE. Инструмент для менеджера должен позволять создавать детальные интерактивные прототипы без программирования.
                      • +2
                        Вы отлично пишете, под отлично подразумевается доступный язык и последовательность изложения. Продолжайте в том же духе.
                      • +2
                        У нас прототипирование заложено в архитектуру проектов. Прототип составляет примерно 80-90% от необходимой функциональности, позволяет оценить как юзабилити, так и подготовить все структуры данных для дальнейшего «оживления».

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

                        Так что могу поздравить компанию с выходом на новый качественный уровень развития.
                        • +2
                          Рад за вас что вы таки пришли к созданию нужного вам прототип-мейкера. Я в похожей ситуации смог выкроить время только на поделки, хотя прототипирование показало себя намного лучше чем у вас — разница была практически как проект выполнен с прототипом успешно и проект без прототипа сдан формально. customer satisfaction и прочие радости :) Там просто были свои специфики в GUI, которые на пальцах неподготовленным людям не понять, да и подготовленным не всегда.

                          • +1
                            Спасибо компании за поддержку и развитие проекта :)
                            Если вы говорите про уменьшение сроков проекта — то это меньшее из достигнутых нами преимуществ.
                            На самом деле, разница проектов с прототипами и без у нас тоже немалая, и выражается она в первую очередь не в сроках.
                            • 0
                              У меня первый проект был очень длинным и сложным и я на нем начинал будучи просто русскоязычным контактным лицом и закончился тем что я стал на нем ПМом. Этот проект был фактически провален, разве что финансовые показатели были в норме, но продукт был стырен и переписан сторонними разработчиками, на что мы закрыли глаза, который тоже не удовлетворил заказчика. Там вообще была длинная и грязная политика. Из него я много вынес для себя и в том числе сложный опыт работы по составлению ТЗ с неопытным в данной теме заказчиком.

                              Так что когда я начинал свой новый проект я занялся прототипом UI, описание и тесты писались уже по нему. И другой проект, который я подхватил, я начал с того что мне команда нарисовала прототип из кода. И так далее… Также я делал проекты, в основном забирал чужие, на которых не было прототипа и ощутил разницу в отношении к продукту от заказчика, в скорости вовлечения новых людей в тонкости продукта. Прототип в целом давал преимущество во многих отношениях, которые считаю ключевыми для успеха проекта.
                          • +1
                            Вы меня простите… Но с точки зрения компании, которая сейчас рассказывает о том, когда и как надо прототипировать, а также учитывая факт вашего создания инструментов для прототипирования, я бы пересмотрел ваши взгляды на то, как сейчас выглядит сайт вашего продукта… Да и ваш личный…

                            У вас проблемы начинаются с ваших продуктов… А если проблемы уже видны на поверхности, то я бы побоялся даже ставить ваш инструмент…

                            Без обид.
                            • 0
                              Виталий, вы пока ничего обидного не сказали. Вы можете поточнее описать проблемы, увиденные вами на поверхности?

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

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