Прототипирование - мощная техника работы с требованиями, которая неоднократно помогала автору этой статьи выяснить, что хочет заказчик и транслировать это командам разработчиков. Однако, как и любая техника, прототипирование имеет свои сильные и слабые стороны, о которых, собственно, и будет разговор.
Должен также предупредить придирчивых коллег-аналитиков, что никак не претендую на абсолютную истину. Все это – лишь небольшая ретроспектива собственного опыта и субъективные выводы. Окончательное решение по использованию того или иного подхода, инструментария или совета – личная ответственность читателя.
Опыт первый, когда мудрости не хватило всем
Когда-то, в начале своей карьеры в середине бурных 90-х автор этой статьи работал инженером по планированию телекоммуникационных сетей в рядах компании-оператора связи.
Однажды нужно было решить вопрос обработки большого массива показателей работы сети. Как можно догадаться, задача нуждалась в автоматизации, и мне поручили подготовить техническое задание (ТС) для отдела ИТ-поддержки, где находился небольшой штат программистов или программистов-аналитиков, как тогда было принято их называть.
Первая версия ТС, как говорится, не зашла, несмотря на то, что требования были тщательно прописаны по предоставленному шаблону. Судьба второй версии была не намного лучше. Третья попытка была существенным, но все еще недостаточным прогрессом. Это длилось около двух месяцев.
Следовательно, нужно было менять подход: единственное, что мне пришло в голову, было дополнение описания требований прототипами экранных форм, что, собственно, и было сделано (к сожалению, документ не сохранился). Но, чувствуя, что провал четвертой попытки будет трудно объяснить своим руководителям, решил перестраховаться и пошел сразу к новому начальнику отдела ИТ-поддержки, бывшему разработчику, кстати.
Парень просмотрел немаленький документ в течение минуты-двух, поднял на меня глаза и выдал следующее: «Вопросов нет, сделаем. Но, слушай, если ты уже потратил столько времени на подготовку этой задачи, может тебе стоит приложить еще немного усилий и написать код?». Это было остроумно, но они действительно удивительно быстро сделали аппликацию, которая без проблем обрабатывала большие объемы данных, но без всех экранных форм, которые оказались лишними.
Чем пользовался: MS PowerPoint.
Подход: условный Paper Prototyping.
Что сработало хорошо
"A picture is worth a thousand words". Разработчики по каким-либо причинам отказались воспроизвести прописанные в техническом задании экране формы, но прототип помог проиллюстрировать саму идею продукта. Это сработало лучше, чем детальное описание вариантов использования (Use Cases).
Что стоило улучшить, чего избегать
Старайтесь стремится к совершенству, но не забывайте о здравом смысле.
Если вы чувствуете, что над вами издеваются, может, так оно и есть. Это, конечно, шутка, но не следует пренебрегать анализом заинтересованных сторон (stakeholder analysis).
Опыт второй, в основном положительный
Представьте себе, что вам нужно описать требования для вот такого эпика «As a Customer, I want to a shop guidance to select items in a physical shop, so that I can pay either in the shop or by link later». Если вы считаете, что эта история звучит немного странно, вы не очень ошибаетесь, но в жизни случается всякое.
Совершенно коротко и схематично это должно выглядеть как показано на рис. 1.
Рис.1.
Вам все еще непонятно? Мне было тоже, но, к счастью, догадался переложить свои сомнения на кликабельный прототип, созданный на основе существующих экранных форм и отправить его заказчику на валидацию, а затем на просмотр команде. В конце концов остановились вот на таком варианте (рис. 2)
Рис. 2.
Чем пользовался InVision.
Подход: моделирование потока работ (Workflow Modelling).
Что сработало хорошо
Прототип прекрасно демонстрировал реализации разных вариантов процесса покупки.
Было создано единое рабочее пространство для взаимодействия заказчика, бизнес-аналитика, разработчиков и тестировщиков.
Использование существующих экранных форм существенно сократило время создания прототипа, упростило валидацию и дальнейшую работу разработчиков.
Что стоило улучшить, чего избегать
Единственное замечание со стороны заказчика: «Это так просто и очевидно! Зачем вам нужно два спринта (4 недели, прим. автора), а не 2 дня на реализацию?». Так что не забываем работать с ожиданиями со стороны заказчика.
К сожалению, InVision прекратил поддержку инструментария для создания прототипов на основе существующих экранных форм. Поэтому советую поинтересоваться последними достижениями в этом направлении, особенно с использованием искусственного интеллекта.
Опыт третий: как можно, но не следует делать
Вы бизнес-аналитик, работаете над требованиями к созданию отчетности для руководителей проектов. Несмотря на то, что проектная информация содержится в Jira, заказчики считают, что имеющиеся инструменты для построения отчетов недостаточны.
Итак, вы разработали формы отчетов (см. рис. 3), которые очень понравились заказчикам, но некоторые из очень влиятельных пользователей поставили под сомнение возможно ли такое вообще.
Рис. 3.
Да, такое возможно, но для этого нужно было построить функциональный прототип (рис. 4). Это была аппликация Windows, которая включала полноценную базу данных, со связанными экранными формами, процедурой импорта данных Jira в виде CSV-файла, и, собственно, отчетностью (рис. 3).
Рис. 4.
Чем пользовался: MS Access, Visual Basic for Applications (VBA).
Подход: функциональный прототип (эволюционный).
Что сработало хорошо
Доказана возможность построения сложной управленческой отчетности путем создания рабочего прототипа информационной системы.
Продемонстрировано, что время создания отчетности можно сократить в четыре раза.
Что стоило улучшить, чего избегать
Создание требований превратилось в полноценную разработку. Даже если вы хорошо владеете тем или иным языком программирования, не стоит забывать о том, что вы аналитик (а я был именно аналитиком) и ваша первоначальная задача – работа с требованиями. Иначе говоря, если вы построите действующий прототип, но в процессе разработки упустите критически важное требование, такое вряд ли понравится заказчику.
Стоит отметить, что заказчики, даже очень влиятельные, тоже люди могут ошибаться. Поэтому перед тем как принимать выражение «Нас не устраивает штатная отчетность» по аксиому, советую исследовать, что именно не устраивает и по каким причинам. Особенно если речь идет о Jira, или что-то подобное.
Опыт четвертый, учитывающий третий
Маленькая компания в Соединенных Штатах много лет работала на рынке кухонной мебели по заказу где-то на Среднем Западе. Процесс оформления заказа к условному сегодняшнему дню (события происходили в 2019 году) не менялся с середины прошлого столетия. То есть заказчик, обычный хозяин, который захотел новую мебель на кухню или решил обновить старую, приходил в офис компании, садился за стол с менеджером по продажам и листал огромные каталоги вариантов дизайна и комплектующих. Менеджер все фиксировал на бумаге, время от времени проверяя, правильно ли он записал. Это могло занимать от нескольких часов до нескольких дней, но всех все устраивало. Вдруг что-то произошло, и владельцы компании решили автоматизировать процесс создания заказа, насколько это было возможно.
Чтобы представить сложность задачи, посмотрите на количество возможных вариантов реализации дверцы (см. рис. 5). Конечно, не для каждого стиля подходили все породы древесины или опции панелей, однако примерно так, конечное количество вариантов огромно.
Рис. 5.
Как можно понять, визуализация являлась ключевым инструментом общения. Более того, это был единственно возможный вариант, поскольку времени для подготовки описания требований для такого проекта-проверки концепции (Proof of Concept) почти не было: через две недели заказчик хотел отчаянно видеть результат. Он увидел его в виде работающей аппликации, очень похожей на прототип, который он согласовывал (рис. 6).
Рис. 6.
Чем пользовался: MS PowerPoint, Sketch.
Подход: моделирование потока работ (workflow modeling).
Что сработало хорошо
Использование готовых шаблонов экранных форм одной из е-коммерческих платформ.
Передача только что согласованных форм и моделей процессов разработчикам.
Что стоило улучшить, чего избегать
Когда действуют жесткие ограничения в ресурсах, важно четко договариваться с заказчиком, какую именно часть требований будет демонстрировать проверка концепции.
Не забываем о времени, необходимом для описания самих требований и не стесняемся говорить об этом на этапе планирования. В этом конкретном случае мне повезло, потому что работал с командой опытных разработчиков, но так было не всегда.
Опыт пятый, провальный
А как вам задача? Компания-дилер американского оператора мобильной связи предлагает путешественникам из Европы приобрести заранее SIM-карту оператора. Карты отправляются обычной международной почтой на указанный домашний адрес будущего абонента, а активируются по прибытии в США. Причем абоненту нужно заранее подать заявку на активацию карты через отдельный веб-портал, что, собственно, и было темой разработки, где указать номер заказа, личные данные, дату активации и 19-значный номер полученной SIM-карты. Конечно, сейчас это трудно представить, но этой истории не так много лет.
Перечитав требования и вспомнил свой богатый опыт работы в телекоме и е-коммерции, решил предложить следующее (рис. 7 и 8):
Рис. 7.
Рис. 8.
Для данной статьи принял только две формы из восьми, наиболее показательные. Но каждая экранная форма была тщательно отработана со ссылкой на конкретные требования и пояснения. Кстати, как они вам? Мне до сих пор нравятся. То же говорил мой коллега-аналитик, которому я отправил их вместе с требованиями на пересмотр как независимому эксперту.
Чем пользовался: MS PowerPoint.
Подход: эдакие визуализации с текстом (Storyboarding).
Что сработало хорошо
Формы гармонично сочетали функционал онлайн магазина и портала активации.
Последовательность форм в виде слайд-шоу наглядно демонстрировала процесс полностью.
Каждая форма имела ссылку на функциональные требования, которые она покрывала.
Что стоило улучшить, чего избегать
Если заказчик говорит, что его интересует только портал по активации, то дайте ему требования и прототипы именно портала. Дополнительный функционал можно предложить потом, если конечно заказчик готов это воспринимать. В моем случае заказчик не был к этому готов, однако отрицательный результат тоже имеет свою ценность. Итак, делюсь.
Эпилог
Следовательно, прототипирование является чрезвычайно эффективной техникой работы с требованиями, а также
обычно хорошо воспринимается заказчиком (но помним об анализе заинтересованных сторон),
должно дополнять, но не подменять собой требования,
должно фокусироваться на идеях/фунционале, пренебрегая деталями (what rather than how). И, напоминаю, стремитесь к совершенству, но помните о здоровых ограничениях и правильно формируйте ожидания заказчика.
Владение специализированными инструментами прототипирования важно, но не критично. Исключением могут быть случаи, когда либо уже наработана какая-то база прототипов в определенной среде, либо доступны качественные отраслевые шаблоны (пример - Axure RP). Это действительно работает, но в большинстве своем слышал от заказчиков что-то вроде «Сделает как у тех ребят, только лучше», а для таких задач достаточно MS PowerPoint.
Ну, и напоминаю прописную истину: заказчика слушаем внимательно, беспристрастно, но критично.
Собственно все. Удачи с прототипированием!
Об авторе
Владимир Туровец, практикующий бизнес-аналитик, CBAP/PSPO II
e-mail: vturovets@gmail.com
コメント