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

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

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

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

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

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

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

SWEBOK (Software Engineering Body of Knowledge). Свод знаний по программной инженерии

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



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

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

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

IEEE 830-1998. Рекомендации IEEE по разработке требований к программному обеспечению

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

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

Мнения специалистов

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

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

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

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

Итак, на основе анализа источников можно выделить следующие варианты использования прототипов:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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



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

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

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

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

• Одноразовые прототипы
• Эволюционные прототипы

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

• для чего прототипировать?
• кто должен прототипировать?
• когда нужно прототипировать?

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

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

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

-

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

+

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

Цифры

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

• Сроки на работу с требованиями и проектирование увеличились на 50%
• Сроки реализации сократились на величину от 20 до 35%
• Сроки тестирования сократились на 30%

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



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

Вывод

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

Если вы ещё не прототипируете – попробуйте, не пожалеете.