Опубликовано в журнале "Компьютер Price" http://www.comprice.ru/
Владимир Сарнацкий <director@smartpartner.spb.ru>
Чего хотят люди?
Древняя китайская пословица гласит: "Лучше быть счастливым и богатым, чем бедным и больным".
Все мы хотим жить счастливо и спокойно, вовремя завершать начатое, и реализовывать задуманное именно так, как оно было задумано.
А между тем, по статистике лишь от 25 до 50% проектов в области программного обеспечения и создания сайтов реализуется в срок, в рамках выделенного бюджета и в соответствии с предъявляемыми требованиями.
Только ли получаемое удовольствие от работы заставляет разработчиков засиживаться допоздна, когда рабочий день уже закончен, менеджеров - постоянно звонить, бегать, и всячески надоедать клиентам, согласовывая то, что почему-то не было согласовано ранее, а директора - в очередной раз откладывать заслуженный отпуск?
Как правило, причиной проблем с проектами является то, что "некто не поговорил с кем-то другим о чем-то важном".
"Чем-то важным" являются критические риски. От их успешного предотвращения зависит, будет ли проект реализован в принципе.
Эти риски связаны с пониманием заказчиком и исполнителем предъявляемых требований к проекту, своевременным финансированием и выполнением проекта в заданные сроки.
Прежде всего, необходимо прийти к полному взаимопониманию относительно существенных элементов проектируемого сайта.
Помните, как Остап Бендер сказал Адаму Козлевичу: "Все ваши беды происходят оттого, что вы правдоискатель. Вы просто ягненок, неудавшийся баптист. Печально наблюдать в среде шоферов такие упаднические настроения. У вас есть автомобиль - и вы не знаете, куда ехать. У нас дела похуже - у нас автомобиля нет. Но мы знаем, куда ехать. Хотите, поедем вместе?".
Люди делятся на три категории: тех, кто стоит и не делает ничего, тех, кто знает, что нужно идти и что-то делать, но не знает куда идти, и тех, кто знает, куда идти.
Разработчики программного обеспечения относятся ко второй категории. У них есть автомобиль, и даже есть бензин; со всей виртуозностью опытного шофера, аккуратно соблюдая правила дорожного движения, они легко привезут вас в любую точку мира, но только какой в этом прок, если они привезут вас не туда?
Итак, мы выяснили, единственный человек, который знает, куда нужно ехать - это Клиент. Одновременно с этим, только Разработчики знают, как ехать.
Что же мешает в процессе управления требованиями разработать правильную систему?
Во-первых, клиенты и разработчики разговаривают на разных языках.
Я не буду проводить аналогию с бензином и сообщать, чему численно равно октановое число, но попробуй объясни клиенту, что некоторые функции, такие как постоянные соединения с базами данных (persistent database connections), доступны только в версии PHP, скомпилированного как модуль Apache, а не в версии PHP в конфигурации интерпретатора CGI, в то время, как он, ткнув палец в прайс-лист конкурентов, провозглашает: "Но ведь у них поддержка сайта (хостинг) на 2 доллара дешевле!".
Вторая проблема заключается в том, что очень часто сложно понять, чего хотят клиенты.
Причина этой проблемы в том, что клиенты не до конца осознают возможности разработчиков: есть ли в машине кондиционер, подушка безопасности, откидной верх и/или бортовой компьютер. Иными словами, какие вообще элементы сайта могут реализовать разработчики, могут ли они связать с сайтом уже существующие базы данных клиента, какие подходы к разработке дизайна разработчики предлагают и т.д.
Третья проблема в том, как фиксируются требования, по которым достигнуто соглашение. Здесь есть три варианта: требования могут быть зафиксированы в техническом задании, которое разрабатывается индивидуально для каждого клиента (самый дорогой вариант), в стандартном техническом задании, когда у необходимых элементов сайта достаточно проставить галочки, и вообще без технического задания.
Последний вариант мы рассматривать не будем - он относится, в основном, к деятельности различных Васей Пупкиных, когда клиент в результате получает то, что и хотел: "просто сайт". В самом деле, ну зачем еще какое-то техническое задание? Ведь сайт он либо есть, либо его нет, не правда ли?
Итак, как же все эти проблемы решить?
Для начала необходимо разделить все предъявляемые требования на три большие группы: функциональные, нефункциональные и требования к контексту.
Требования к контексту - это требования к содержанию сайта: структуре страниц, набору изображений и т.д.
Функциональные требования - это требования к тому, что должна делать система - "нажал кнопку, получил результат". Особенно они актуальны при проектировании интернет-магазина, когда "внутри" находится достаточно сложная и толковая система интерактивного общения с клиентом, динамические каталоги и система оплаты. Естественно, все это должно быть продумано заранее, чтобы потом "не было мучительно больно".
С описанием первых двух видов требований способен справиться любой руководитель проектов. Ему за это платят зарплату. Хотя дело не из легких - нужно избежать двусмысленностей, исключить предположения и очертить границы элементов.
Кстати, проблему с наполнением сайта информацией (содержанием сайта) заказчик может решить самостоятельно, если разработчики предоставляют возможность встраивания Системы Управления Содержанием (контент-менеджер) в проектируемый сайт. С помощью подобной системы можно без знания даже основ веб-дизайна обновлять информацию на сайте. Ввод текста аналогичен вводу текста в обычном текстовом редакторе.
Нефункциональные требования - это требования к дизайну, а также требования, связанные с вопросами производительности, безопасности, расширяемости, надежности.
Это настоящая трагедия! Как заранее предусмотреть "степень красоты" дизайна и "талантливости" текстов для сайта (если их по договору подготавливает Исполнитель).
У этой проблемы есть несколько решений.
Во-первых, разработкой дизайна вполне может заниматься Заказчик самостоятельно и учесть все необходимые требования к корпоративному дизайну. Техника дошла до того, что html-кодер, программист, ответственный за написание исходного кода для сайта, способен любую картинку из Photoshop'а превратить в функционирующий сайт. Здорово, правда?
Во-вторых, разработкой дизайна может заниматься исключительно Исполнитель. Когда мы признавали, что Клиент - это единственный человек, который знает, куда ехать, одновременно мы согласились, что Разработчики - это те, кто знает, как ехать. В конце концов, Клиент выбирает разработчиков сайта исключительно добровольно, а, те заинтересованы в том, чтобы подходить к делу основательно и творчески - будущие клиенты не забудут заглянуть в список работ - портфолио.
В-третьих, на практике проблема не решается никак, и руководитель проекта вынужден постоянно бегать и согласовывать каждую закорючку дизайна с клиентом.
Далее хотелось бы рассмотреть самый болезненный вопрос любого проекта. Это вопрос о финансировании. Зачастую разработчики склонны поддаваться на понятное желание клиента оплатить работу после ее выполнения. Более того, некоторые веб-студии предлагают это в качестве своего конкурентного преимущества.
Хотя, если подумать, это совсем не конкурентное преимущество, а, наоборот, "конкурентный недостаток". Большинство веб-студий на рынке - это небольшие компании, реализующие в месяц два-три проекта. Представьте, что по различным причинам двое из трех клиентов не перечислили деньги вовремя. Что будет с третьим проектом, когда веб-студия останется без оборотных средств? В любом случае - это критический риск, который нужно предотвратить заранее.
Последний критический риск связан с планированием проекта во времени.
Сроки проекта могут быть нарушены в том случае, если в процессе реализации выяснится, что необходимо внести существенные изменения.
Решения здесь такие:
Во-первых, необходимо заранее в общих словах обговорить процедуру взаимодействия: передачу необходимых для разработки документов и возможности внесения изменений в проект.
Во-вторых, для сложных проектов имеет смысл разбить его на этапы. В таком случае, решение о завершении каждого этапа окончательное, и изменения, которые нужно было внести на первом этапе, должны были быть внесены именно на первом этапе.
Иначе, представляете, как вы "обрадуете" программистов сообщением, что неожиданно дизайн на предыдущем этапе был изменен, и всю дальнейшую работу надо выполнять заново.
Разбиение на этапы позволит существенно ограничить риски и реализовать проект в соответствии с тем, как он был задуман.
Перед началом работы необходимо, чтобы и на стороне Заказчика и на стороне Исполнителя было определено по одному человеку, ответственному за осуществление проекта. Ситуацию, когда за дело отвечает больше одного человека, мы будем называть демократией. Я склоняюсь к мысли, что для достижения результата деспотизм является куда лучшей формой власти, чем демократия.
В заключение, хочу пожелать своим коллегам при
реализации проектов подходить к делу обдуманно: с чувством, с
толком, с расстановкой, а тем, кто собирается заказывать сайты, -
основательнее подходить к выбору
партнеров.