Предпроектный анализ: Серия 2

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

• «Письмо Дяди Фёдора»
• Не учтены полный ЖЦ и структура как системы, так и финансового актива
• Избыточная детализация требований
• Не представлены объем и достаточное деление системы
• Не проявлено понимание целей заказчика
• Нет основания приемки результата
• Выбран неверный режим коммуникации требований

Давайте рассмотрим каждый пункт.

[sendpulse-form id=”278″]

«Письмо Дяди Фёдора» или “Запорожцы пишут письмо турецкому султану”

Эта проблема возникает у заказчиков далеких от мира IT или с низкой IT-зрелостью.
Начинающие заказчики ИТ-систем действуют так: несколько человек высказывают свои мысли обо всем, что приходит им в голову в связи с построением обсуждаемой системы. Эти мысли записываются как есть в произвольном порядке и называются ими требованиями.

В этом случае записывается не всё, что нужно для успеха построения системы, а только исходно непонятное или интересное лично каждому из авторов, то, что «и так всем ясно».

В таких требованиях нет полноты, непротиворечивости, однозначности, понятности.

Результат оценки и планирования по таким требованиям: «на любой вопрос – любой ответ».

Ближе к концу проекта в таких случаях всплывают фразы: «эта система полностью соответствует ТЗ, но не делает то, что нам нужно» или «ой, мы забыли еще …» или «в этом ТЗ мы имели в виду совсем другое».

Со стороны исполнителя такие технические задания ставят в первую очередь вопрос о том, как будем приемо-сдавать результат. «Письмо дяди Федора» или от “запорожцев” для исполнителя — «попадание в рабство» к заказчику на пару лет.

Не учтен полный жизненный цикл и структура системы

В какой-то момент становится ясно, что ТЗ надо писать и писать его хорошо.

В зависимости от того, к кому попадет идея проекта: специалистам по железу, ПО-эксплуатационщикам или кому-то еще, мы получаем перекос в разные стороны.

Разработчики ПО любят писать детальное ТЗ на программу, забывая, что надо привезти и установить оборудование, озаботиться каналами связи.

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

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

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

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

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

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

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

Избыточная детализация требований

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

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

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

В такой ситуации люди, участвующие в процессе, теряют веру в практику написания ТЗ и идут искать лучшей доли в другие практики.

Не представлены объем и достаточное деление системы

Мы разобрались, которое ТЗ писать.

Учитывая, что судьба проекта не ясна, нас просят сделать ТЗ подешевле.

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

Оценка стоимости системы не уточняется и не возникает «поля для торговли» по цене и срокам: что будем резать и какие возможности при этом «отвалятся».

И это закономерно, так как до ТЗ нужно придумать концепцию системы.

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

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

Не проявлено понимание целей заказчика

Когда финансовый директор говорит нам: «Вы сейчас зачитали мне 243 функциональных требования, 15 нефункциональных требований, 10 видов обеспечения, но это для меня белый шум. Скажите проще, что улучшится, если я сейчас забюджетирую и потрачу эти конкретные $5 млн? Кого мы сможем уволить? Мы будем больше продавать или производить? Вы готовы взять это как обязательства?»

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

Обычно, если работа идет через документы, за ответы на такие вопросы отвечают бизнес-требования (или требования заказчика), которые надо создать до концепции.

Нет основания приемки результата

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

Требования должны быть не только полными, обоснованными, реализуемыми, но и тестируемыми. Это отдельная работа и другой документ — собственно ТЗ на систему, которое нельзя путать с ТЗ на ПО.

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

Выбран неверный режим коммуникации требований

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

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

Коммуникация в предпроекте описывается фразой: «Первое впечатление можно произвести только один раз». Если проекту откажут в финансировании, потому что спонсор не убежден в отдаче, или заказчик не убежден в эффекте, или пользователи не убеждены в новизне получаемых возможностей, то «показать класс» уже не получится.