Непредвиденные последствия

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

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

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

Как это работает в теории?

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

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

1. Ввести произвольное количество целых чисел.
2. Запустить команду суммирования.
3. Прочитать с экрана результат суммирования.

Включив все свои давно устаревшие стереотипы разработки программ для Windows, вы рисуете на бумаге первый эскиз интерфейса программы, например, так:

После этого вы описываете функционирование интерфейса в соответствии со сценарием использования:

Программа “Суммирование чисел”

Для достижения результата нужно задать список суммируемых чисел. Это делается путем ввода очередного числа в самое верхнее поле и нажатием кнопки “Добавить число”. При этом введенное число добавляется в начало списка суммируемых чисел и одновременно удаляется из поля ввода.

Если вы случайно ввели неправильные числа, можно удалить их из списка и ввести заново. Для этого необходимо выделить число в списке, кликнув по нему мышкой один раз, и нажать кнопку “Удалить число”.

После ввода всех чисел следует нажать кнопку “Суммировать”, и пользователь увидит результат суммирования в соответствующей строке внизу.

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

Заказчик смотрит на эту муть, пишет на полях резолюцию “Интерфейс слишком перегружен” и отправляет вам на доработку.

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

Описание функциональности несколько уменьшается:

Программа “Суммирование чисел”

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

Примечание: в поле ввода работает автоматический перенос слов.

По мере ввода чисел они автоматически суммируются и результат суммирования отображается в строке “Сумма” внизу.

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

Новая спецификация показывается заказчику, он ее одобряет, заключается договор с указанием сроков разработки (только теперь, после утверждения спецификации, вы можете корректно спланировать все этапы разработки и предположить, сколько это займет времени), описываются штрафные санкции и проставляется сумма денег, которую вы получите авансом или при сдаче проекта.

Если вы не будете делать прототипирование программы, то при оформлении договора будет идти привязка к размытому первичному техническому заданию. Когда через пару месяцев вы придете к заказчику с готовой программой, и ему вдруг не понравится ее интерфейс, он скажет, что не примет проект и не отдаст вам деньги, пока вы не приведете все в соответствие с ТЗ (читай: “будете переделывать все до тех пор, пока мне не понравится”).

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

Так должно быть в идеале.

В реальности, эта схема не работает, если вам заказали проект, который:

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

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

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

Это выглядело так: мы доходили до какого-либо спорного момента в разработке, несли проект на предприятие, и показывали его там представителю заказчика в полуразобранном виде, а представитель помогал решить проблему. Но одновременно с решением проблемы при каждом нашем посещении он вспоминал какую-нибудь особенность документооборота на своем предприятии, и говорил, что без нее систему никто не будет использовать, так что “вы уж постарайтесь эту штуку сделать”. И мы очень старались. Это был наш первый большой проект, и мы, конечно, хотели сделать все по высшему разряду. Поэтому кривая роста запланированных функций ползла вверх гораздо быстрее, чем график их реализации. Жизненно важно было установить какой-то предел и выпустить, наконец, версию 1.0.

Мы уселись за разработку форм и описание их функционирования. Для прототипирования использовался MS Visio, в котором есть отличный набор форм интерфейса Windows XP. Около месяца ушло у нас на полное проектирование и описание интерфейса системы. В результате получился внушительный документ на полторы сотни страниц, который худо-бедно показывал систему так, как ее увидит пользователь, и мы начали процесс утверждения.

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

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

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

1. По бумажному прототипу нельзя понять, как работает сложная система. Бумага не передает динамику и реакцию на ваши действия. То, что вы рисуете на бумаге, может в реальности работать совсем не так, как запланировано.
2. Ни один заказчик не будет пытаться понять концепции работы системы по бумажному прототипу. Даже если вы думаете, что у вас есть талант доносить свои идеи людям в письменном виде, и эти люди прочитают все, что вы написали, они все равно будут рассматривать все написанное в контексте своего видения системы, которое может радикально отличаться от вашего. Заказчик никогда не скажет вам все, чего он ожидает, пока не увидит готовую систему. Просто потому, что он не знает, о чем именно должен вам рассказать, так как для него все его пожелания ясны и понятны. В отличие от вас.
3. Между завершением прототипирования и сдачей проекта проходит длительное время. За время реализации проекта по готовому прототипу обстановка у заказчика может радикально измениться, появятся новые потребности и пожелания, которые даже в мыслях не возникали на стадии проектирования. И ваш проект при сдаче уже не будет им соответствовать.

В заказных проектах бумажное прототипирование с полным согласованием — это не лучший выбор.

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

Если вы уже залезли в долгосрочный договор, не уходите от прямого диалога с заказчиком и не прячьтесь за утвержденными прототипами. Каждую неделю показывайте то, что уже реально работает, а не “будет работать через год” и не стройте глобальных долгосрочных планов. Если вы позволите проекту развиваться вместе с восприятием заказчика, то в итоге вы, скорее всего, получите не то, что запланировали вы, а то, что хочет увидеть ваш клиент. Это гораздо лучше.

Однако не следует думать, что полное прототипирование бесполезно. Оно очень полезно, но для разработки коммерческого софта, который вы собираетесь продавать на рынке. Когда вы сами как бы являетесь и заказчиком, и разработчиком проекта одновременно, нет ничего лучше для установки четких целей самому себе, чем формализованный прототип. Это прочный скелет для ваших идей, которые без прототипа “растекутся по древу” и помешают закончить разработку в срок, который вы же и наметили. Даже если вы во время разработки отклоняетесь от прототипа, он все равно будет наглядно показывать вам, на какой вы стадии и к чему надо стремиться.