Владислав Головач, Александр Белышкин
Внедрениесистем автоматизации бизнеса, как знает любой вовлеченный в эту областьспециалист, отнюдь не является легким делом. Если само создание системы, вообщеговоря, технически не очень сложно (к примеру, нельзя сказать, чтосреднестатистическая система наполнена сложнейшими алгоритмами), то внедрениетребует от автоматизатора недюжинной квалификации, редкого упорства иизворотливости. При этом корни многих проблем находятся в техническом задании.Как говорится, «что задумали, то и сделали», но потом иногда оказывается, чтозадумали-то и неправильно. Для решения проблем, возникающих при создании ТЗ, апроявляющихся при внедрении, придумано множество технологий и методов однакосамо их количество свидетельствует о том, что ни один метод к полному успеху неприводит. Кроме того, многие методы имеют принципиальный недостаток – ониувеличивают объем части работы, пусть и ради экономии на другом этапе, итребуют серьезных инвестиций в обучение сотрудников (характерный пример – RUP).Существует, однако, подход, который не требует особой квалификации сотрудников,значительно облегчает внедрение, не увеличивая объем работ по разработке ТЗ.
Сущностьподхода может быть описана одной фразой — проектирование интерфейса не естьчасть процесса разработки, а часть процесса создания спецификаций на систему.
Здесьнеобходимо сделать два важных уточнения. Во-первых, интерфейс всё равно будетразработан (практика показывает, что заказчики почему-то неохотно оплачиваютфункциональность без интерфейса). Во-вторых, от проектирования интерфейсаничего особого не требуется — на него могут быть выделены те же ресурсы, что ив случае обычной разработки, равно как и получиться он может таким же. Авторам,зарабатывающим себе на жизнь разработкой эргономичных интерфейсов, неприятноэто говорить, но интерфейс может быть даже не эргономичным, все равно внедрениебудет облегчено; разумеется, в случае эргономичного интерфейса внедрение будетещё более простым, но такой интерфейс дороже и дольше делается.
Предлагаемыйподход позволяет решить следующие проблемы:
Устранитьразличия во взглядах на постановку задачи заказчика и исполнителя. Спецификациина сколько-нибудь сложные системы слишком абстрактны. Их с трудом удерживают вголове даже авторы, а до конца не понимает никто, в особенности ключевое лицо —заказчик. Для него эта спецификация ничем не отличается от сакральных письмен(многие даже предполагают, что непонятные ТЗ предназначены для того, чтобыпроизвести на них впечатление и содрать побольше денег). Нет разницы, чтоподсунут ему разработчики, реальное ТЗ или инструкцию к газонокосилке на фарси —все одинаково непонятно. Наивно предполагать, что заказчик, легко подписавшийтакое ТЗ, также легко примет разработанную систему. Прототипы интерфейсаявляются тем единственным документом, который заказчик может понять и оценить.А поняв и оценив — сознательно подписать.
Облегчитьпроцесс внедрения системы. Весомая часть проблем внедрения в качественновыполненном проекте приходится на интерфейс, созданный формально правильно, нонеадекватно представлениям заказчика. Не существует вида ТЗ, кроме собственнопрототипа интерфейса, который бы мог интегрировать такого рода требования.Наглядный пример: в любом ТЗ можно прописать, что «в системе есть адреснаякнига, которая состоит из таких-то данных и таких-то функций». Но невозможноформализовать уже в ТЗ, как эта адресная книга должна реально работать(какие-то функции нужно «вытащить» наверх, какие-то можно «задвинуть»), как, вконце концов, эта адресная книга должна выглядеть. При этом апелляцииисполнителя к подписанному техническому заданию – дескать, вот же перечисленныефункции... вот они все налицо — как правило, не срабатывают, поскольку приизвестной изворотливости в контексте пользовательского интерфейсапроинтерпретировать ТЗ всегда можно очень по-разному. Только заранееспроектированный интерфейс позволяет застраховаться от такого рода претензий.
Сократитьчисло доработок системы, вызванных несоответствием ее функциональностиожиданиям клиента. Только увидев саму систему, заказчик может реально понять еевозможности, равно как и оценить собственные потребности. Для заказчикапрограммный продукт и его интерфейс совершенно тождественны. Следовательно,показав заказчику интерфейс на стадии подготовки ТЗ, можно снизить количество иобъем переделок, потребность в которых возникает из-за расхождений ожиданийзаказчика с запланированной в ТЗ функциональностью системы. (Нужно, впрочем,отметить, что такие переделки чаще всего не проблематичны для разработчиков,которые обычно настаивают на дополнительной оплате этих услуг.)
Снятьриск необходимости доработки функциональности системы, из-занеудовлетворенности заказчика предложенным интерфейсом. При разработкеинтерфейса нет решительно никакой гарантии того, что он будет принятзаказчиком. Описание функций системы бинарно, функция может быть, может небыть. Доказательство её наличия редко требует аргументации. Интерфейс же можетбыть либо достаточно хорошим, либо недостаточно хорошим. Когда в дело вступаютотносительные термины, все усложняется, что может приводить в возникновениюконфликтных ситуаций. Нечего и говорить, что при переделке недостаточнохорошего интерфейса функциональность системы, которая уже есть, меняется тоже,причем без оплаты труда разработчика.
Такимобразом, есть объективная польза в том, чтобы рассматривать проектированиеинтерфейса не как стадию разработки, а как стадию создания ТЗ. Но как этосделать? На первый взгляд, задача кажется трудноразрешимой, частично сорганизационной, частично с технической сторон.
Сначалаоб организационной стороне. На первый взгляд заказчика трудно убедитьотказаться от мысли, что делать что-то «реальное» надо сразу после подписаниядоговора. Однако практика показывает, что промежуточные наглядные результатыработы над системой, а именно прототипы интерфейса, продемонстрированные уже навторой день работы, а не через несколько недель, приводят клиента вблагодушество. В отличие от обычного ТЗ, работа над которым заказчику реальноне видна («ну что там, пара пунктов добавилась») прототипы интерфейса легкопонятны и прогресс в работе явно заметен. Вторая организационная проблема связанас необходимостью подписывать два договора: на создание ТЗ (читай — интерфейса)и на разработку функциональности системы. Причем подписание второго договораоткладывается на определенный срок, необходимый для разработки интерфейса, чторастягивает проект во времени. В принципе, эта проблема неразрешима, но, сдругой стороны, здесь многое зависит от её восприятия: да, договора два, нозато второй договор получается значительно более точным (уже имея интерфейс,легче оценить трудозатраты).
Техническаяпроблема связана с трудностями прототипирования. В обычном режиме работыинтерфейс создается уже в средстве разработки, создавать же прототип такимобразом нерентабельно. Интерфейс создается через множество итераций, апеределывать уже сделанное уже дорого. Сравнительно недавно появилисьспециальные средства для прототипирования интерфейса (например, NorpathStudio), но пока они довольно сырые. Выход — использование неспециализированныхграфических редакторов. Ещё несколько лет назад основным таким редактором являлсяMS PowerPoint, сейчас же наиболее удобным следует признать MS Visio. Сложныеэкранные формы, впрочем, до сих пор удобнее просто рисовать на бумаге.
И,наконец, главная проблема. Удлинение процесса разработки ТЗ частовоспринимается самими разработчиками как безусловное зло — привычка сначаладелать, а уж потом думать, традиционно сильна в российском IT-бизнесе. Увы,изменить этот обычай может только «опыт, сын ошибок трудных». Пока, во всякомслучае…
Конечно,проектирование интерфеса на этапе разработки спецификаций системы не являетсяпанацеей. Такой подход не позволяет улучшить качество разработки в принципе,например, он вовсе не уменьшает количество ошибок программирования . Болеетого, он не всегда применим. Интерфейс сложной системы невозможно с самогоначала спроектировать полностью: придется сначала делать работающую бета-версиюи окончательно править интерфейс уже на её основе. Кроме того, во многихпроектах из-за не зависящих ни от кого причин не получается растягивать процесссоздания ТЗ (заказчик хочет увидеть какие-нибудь результаты уже завтра).Однако, учитывая низкие «входные» требования к применению предложенного метода(несравнимые, например, с волокитой и бюрократией, обусловленной использованиемUML), проектирование интерфейсов на стадии подготовки спецификаций почти всегдаявляется крайне успешным методом решения проблем внедрения.