- PVSM.RU - https://www.pvsm.ru -
Нет, это статья не об игре про заражённый вирусом Манхэттен и его мутантов. Речь пойдёт о прототипах другого рода — прототипах программного обеспечения.
Прототипирование ПО становится всё более популярным и часто используемым процессом в российских IT-компаниях. Причины видятся следующие: с одной стороны – это определенная дань моде, с другой – прототипирование обещает компании ряд весомых преимуществ.
Однако сделать процесс прототипирования полезным и эффективным — непростая задача.. Встречаются подводные камни, появляются вопросы. Кто и когда должен прототипировать? Как делать прототипы? Как их использовать? Ответы на эти вопросы и последующие шаги определяют успешность и полезность нововведения. Если они будут неверными – прототипирование может стать не только вредным, но и крайне дорогостоящим процессом.
В статье я хочу поделиться опытом построения процесса прототипирования в моей компании [1]. Расскажу, как мы ответили на озвученные вопросы и каких успехов достигли.
Для определения места прототипирования в процессе разработки ПО, в первую очередь мы обратились к международным стандартам в этой области и собрали следующую информацию.
Далее в секции Утверждения требований прототипированию вообще посвящена отдельная тема, как средству проверки и утверждения требований. В ней говорится, что прототипирование подразумевает проверку инженерной интерпретации программных требований и извлечение новых требований, неопределенных или неясных на ранних итерациях сбора требований.
Таким образом формулируется первая цель прототипирования – решение проблемы недопонимания между аналитиком и пользователем. Упущение тех или иных аспектов, неоднозначность или тем более некорректность интерпретации информации, полученной от пользователей – все это наиболее типичные причины “сверхзатрат” (времени, денег и т.п.), а иногда и полного провала проектов. Первая задача прототипирования – не допустить этого.
Далее свод знаний предполагает использование прототипирования и на этапе проектирования – как технику проверки программного дизайна в целом или отдельных его атрибутов качества.
В своих публикациях Влад Головач предлагает использовать прототипирование в первую очередь для написания и улучшения качества ТЗ [2] или даже для его частичной замены. По его словам, прототипы интерфейса являются тем единственным документом, который заказчик может понять и оценить. Да, это опять этап проектирования. Но, кроме этого, Влад предлагает использовать прототипы для проведения юзабилити-тестирования [3]. А это уже этап тестирования.
В цикле статей Юрия Ветрова [4] об интерактивных прототипах [5] я встретил мысль об использовании прототипов на этапе реализации. Он предлагает разработчикам использовать прототип в качестве образца, поскольку он намного проще и правильнее понимается, нежели многостраничное ТЗ.
Итак, на основе анализа источников можно выделить следующие варианты использования прототипов:
Но мы используем прототипы ещё более широко – добавлю к перечисленным ещё 4 наших варианта.
Иногда мы делаем прототипы на этапе коммерческого предложения, т.е. ещё до запуска проекта и до сбора требований, основываясь только на базовой информации от потенциального заказчика. Как мы это делаем – я уже рассказывал [6].
Для чего мы это делаем? Тут всё просто: прототип позволяет нам выделиться из десятка похожих коммерческих предложений и расположить к себе заказчика.
Мы делаем это не всегда, т.к. всегда есть риск того, что исполнителями проекта выберут не нас, и, соответственно, работы по прототипированию оплачены не будут.
Мы используем прототип в качестве образца не только при реализации системы, но и при её тестировании. У наших тестировщиков сейчас под рукой, помимо ТЗ, всегда есть прототип. Некоторые интерфейсные функции тяжело описываются и воспринимаются в текстовом виде, и в этом случае прототип является хорошим помощником.
Здесь уже больше используем прототип не мы, а наши заказчики. При приёмке работ они теперь помимо, а иногда и вместо проверки функций по ТЗ, сравнивают реализованную систему с прототипом. Это выгодно обеим сторонам. Заказчик вправе предъявить претензии, если в реализованной системе что-то не так, как в прототипе. Но и мы как исполнитель можем защитить себя от претензий, если реализуем систему точно так же, как в прототипе. У заказчика просто не будет оснований быть недовольным. Таким образом, исполнитель отдаёт, а заказчик получает ровно то, что было согласовано – ни больше, ни меньше. Никто не делает лишней работы, и все довольны.
Иногда у нас нет возможности продемонстрировать заказчику готовую систему и мы показываем ему прототипы, разработанные и использованные на прошлых проектах.
Теперь, когда перечислены, наверное, все возможные способы использования прототипов, покажу полный цикл использования прототипов у нас.
После внедрения прототипирования у нас изменился процесс разработки ПО в целом. Как видно из жизненного цикла, прототип пронизывает весь процесс разработки. Прототип стал элементом, который все видят и который все обсуждают: от пользователя до программиста. Он стал своего рода объединяющим, центральным звеном. Он вывел коммуникацию как с заказчиком, так и внутри компании на новый уровень. Значительно уменьшилась потеря информации по пути от заказчика к программисту, потому что все видят один и тот же прототип.
Если раньше процесс передачи информации выглядел примерно так:
то сейчас он представляет собой что-то вроде этого:
Картинки позаимствовал из презентации Геннадия Драгуна, за что ему премного благодарен.
Существует множество мнений о том, что нужно/можно считать прототипом и какими характеристиками он должен обладать. Чтобы не выставлять своё субъективное видение за истину, я опять обращусь к своду знаний SWEBOK. Он говорит, что прототипом могут считаться как “бумажные” модели, так и пилотные подсистемы, реализуемые как самостоятельные (в терминах управления ресурсами) проекты или бета-версии продуктов.
Прототипы можно разделить на 2 большие группы в зависимости от способов их создания и последующего использования:
Одноразовые прототипы являются макетом интерфейса, который в последствии не станет частью готовой системы и на определённом этапе будет «выброшен». Такие прототипы создаются и изменяются быстро, поскольку не требуют качественной реализации. Зачастую они создаются в специализированных инструментах без программирования.
Эволюционный прототип – это предварительная реализация программы, альфа-версия, которая по мере своего развития становится всё ближе и ближе к готовому продукту и, в конце концов, становится им. Эволюционные прототипы менее гибкие, их создание и изменение более длительное и дорогое. Поскольку на начальном этапе не все требования известны и утверждены, прототип в ходе своего развития может обрасти «заплатками». При таком подходе есть большой риск получить на выходе продукт неудовлетворительного качества. Преимуществом эволюционных прототипов считается то, что, во-первых, уже на ранних стадиях заказчик получает работающую систему, во-вторых, не нужно тратить ресурсы на создание прототипа, который потом будет «выброшен».
У каждого из подходов есть свои преимущества и недостатки. Каждый сам для себя решает, какие прототипы ему создавать в зависимости от решаемой задачи, от особенности процесса разработки ПО в компании, от квалификации сотрудников. Мы для себя решили использовать одноразовое прототипирование, как наиболее гибкий, эффективный и менее рискованный инструмент. На нём я и акцентирую внимание.
Одноразовые прототипы делятся в свою очередь по:
Большинство из нас делает «бумажные» прототипы в самом начала этапа сбора требований. Затем по мере уточнения требований увеличивается точность прототипов. Кто-то останавливается на вайрфрейме (каркас интерфейса без конечного дизайна), кто-то доводит до мокапов с дизайном, близким к конечному. Но наибольший интерес представляют интерактивные прототипы. Именно они позволят полноценно вовлечь пользователя, показать систему целиком и в действии. Для нас интерактивные прототипы являются наиболее эффективными, поэтому именно их мы и используем в нашей деятельности.
Теперь краткая информация о распространении и тенденциях прототипирования в России и странах СНГ. Как показывает опрос [7], проведённый Павлом Коноплицким [8] на Хабре, в половине компаний процесс прототипирования вообще отсутствует.
Однако радует осознание того, что ситуация с прототипированием в компании неудовлетворительна. Это видно по результатам другого опроса [9]: более 70% опрошенных не удовлетворены текущей ситуацией и почти половина из них находится на данный момент в поиске хорошей методики и инструмента. Хорошая тенденция.
Вернёмся к первому опросу. Если смотреть на исполнителей, прототипированием в большинстве проектов занимаются технические специалисты. Для меня это стало неожиданностью: как я уже сказал, большинство стандартов и публикаций рассматривают прототипирование в первую очередь как инструмент для извлечения и утверждения требований. А кто занимается сбором требований? Менеджер или аналитик, но никак не технический специалист. Если это будет делать он – у нас опять появятся большие потери информации, менеджер будет играть роль сломанного телефона. Поэтому мы считаем, что прототипировать должен именно менеджер, как центральное звено команды проекта и как лицо, непосредственно контактирующее с заказчиком. В нашей компании должность менеджера и аналитика объединена, что является ещё одним фактором в пользу прототипирования менеджерами.
Мы поставили перед собой два условия: во-первых, прототипы должны быть интерактивными, во-вторых, прототипировать должны менеджеры. Нам нужен был инструмент, который позволяет создавать интерактивные прототипы без программирования, т.к. менеджеры в общем случае не умеют программировать. Пробовали Visio – но интерактивность созданных в нём прототипов была невысокой. Пробовали GUI Design Studio. Но и он не прижился.
В итоге мы пришли к собственной разработке и сделали её такой, какой хотим видеть инструмент прототипирования. Если не хватало каких-либо функций – добавляли. В итоге разработка доросла до качественного продукта, и мы выпустили его на рынок. Назвали GUI Machine [10]. Сейчас это кроссплатформенный инструмент прототипирования, который позволяет создавать интерактивные прототипы декстоп и веб-приложений без программирования.
Использование для создания прототипов собственного инструмента имеет как положительные, так и отрицательные стороны. Минусом для компании является необходимость выделения ресурсов на развитие GUI Machine. С выводом продукта на рынок количество необходимых ресурсов только увеличиваются: инструмент нужно продвигать, развивать, поддерживать. Преимущества своего продукта в том, что мы можем сделать инструмент таким, каким мы хотим его видеть. Кроме того, продукт начал приносить коммерческую прибыль.
Хочу отметить, что инструмент – это всего лишь средство обеспечения процесса прототипирования. Первичен именно процесс. Без построенного и отлаженного процесса ни один инструмент прототипирования «не выстрелит». Сначала нужно ответить на вопросы:
И уже потом решать, с помощью чего это делать. Только тогда к вам придёт понимание того, какой инструмент вам нужен.
В качестве итогов – плюсы и минусы от внедрения процесса прототипирования.
Трудно подбивать все проекты под одну шкалу: все они очень индивидуальные, сильно различаются по длительности и стоимости, а также по раскладке работ при разработке. Поэтому приведённые ниже цифры носят оценочный и усреднённый характер:
В наших проектах работа с требованиями и проектирование занимают около 30% всей длительности проекта, реализация – около 40%, тестирование – около 30%. Исходя из этого, можно вычислить, что общее время проекта сократилось на величину от 2 до 8%.
Это только сухие цифры, но, как я уже говорил, прототипирование даёт далеко не только уменьшение сроков.
Для нас процесс прототипирования стал однозначно выгодным и полезным.
Если вы ещё не прототипируете – попробуйте, не пожалеете.
Автор: RGaifutdinov
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/interfejsy/10470
Ссылки в тексте:
[1] моей компании: http://alee.ru
[2] для написания и улучшения качества ТЗ: http://usethics.ru/blog/lib/ui_at_spec_stage/
[3] для проведения юзабилити-тестирования: http://usethics.ru/blog/lib/testing_by_the_cheap/#_Toc104718073
[4] Юрия Ветрова: http://habrahabr.ru/users/jvetrau/
[5] об интерактивных прототипах: http://habrahabr.ru/post/17379/
[6] рассказывал: http://habrahabr.ru/company/alee/blog/141633/
[7] опрос: http://habrahabr.ru/post/35175/
[8] Павлом Коноплицким: http://habrahabr.ru/users/badlittleduck/
[9] другого опроса: http://habrahabr.ru/post/35185/
[10] GUI Machine: http://guimachine.ru
Нажмите здесь для печати.