В прошлой части

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

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



Вот их список (вы уже знакомы с ним по введению}:

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

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

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

«Письмо Дяди Фёдора»

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

Чаще всего записывают не всё, что нужно для успеха построения системы, а только исходно непонятное или интересное лично каждому из авторов. Новое или отличное от того, что «и так всем ясно». О выборе правильных точек зрения и полноте списка заинтересованных лиц речи не идет.

Такие требования не страдают ни полнотой, ни непротиворечивостью и однозначностью, ни понятностью.

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

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

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

Не учтены полный ЖЦ и структура системы

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

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

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

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

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

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

Но и это еще не все.

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

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

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

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

Не учтены задачи предпроектной фазы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кто платит и как сделать дешевле

В обсуждении предыдущей части этой серии статей товарищ exehoo акцентировал наше внимание на очень правильном вопросе: «Есть еще серьезная проблема вида «А кто заплатит за предпроектные работы?»

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

Однако вопрос платить или не платить не стоит. Правильный вопрос: за что платить и сколько платить.

Можно пойти методом проб и ошибок, называемым по умному «прототипирование». Можно прибегнуть к проектированию и работе через требования.

Вопрос в том, что дешевле:

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

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

Более подробно этот вопрос, а так же то, что еще надо помнить, приступая к запуску ИТ-проекта, обсудим в следующей части.