В последней части В последней части Анонсировал серию статей о работе аналитика в предпроекте.
В нем перечислены проблемы, решения и некоторые принципы, которые следует учитывать при запуске ИТ-проекта.
В новых частях серии мы рассмотрим все вопросы более подробно.
Сегодня мы обсудим предпроектные проблемы, которые возникают очень часто.
Вот их список (вы уже знакомы с ним из вступления}:
1) «Письмо дяди Федора»
2) Не учитывается полный жизненный цикл и структура как системы, так и финансового актива.
3) Чрезмерная детализация требований 4) Не представлен объём и достаточное разделение системы 5) Нет понимания целей заказчика 6) Нет оснований для принятия результата.
7) Выбран неверный режим связи с требованиями.
Давайте обсудим каждый пункт. Для тех, кто не хочет ждать следующих частей цикла статей, есть видео моего отчета с встречи что послужило толчком к их написанию.
При этом хочется не только переписать тезисы выступления, но и выйти за временные рамки доклада, добавив к уже сказанному нечто не уложившееся во времени или возникшее в результате обсуждение потом.
«Письмо дяди Федора»
Начнем с проблем заказчика с низкой ИТ-зрелостью и постепенно усложним ситуацию.Обычно начинающие заказчики ИТ-систем поступают следующим образом: несколько человек высказывают свои мысли обо всем, что приходит им в голову в связи с построением обсуждаемой системы.
Эти мысли записываются в случайном порядке и называются требованиями.
Чаще всего записывается не все, что нужно для успеха построения системы, а только то, что изначально непонятно или интересно лично каждому из авторов.
Новое или отличное от того, что «уже всем понятно».
О выборе правильных точек зрения и полноте списка заинтересованных сторон не может быть и речи.
Такие требования не страдают от полноты, последовательности, однозначности или понятности.
Результат оценки и планирования на основе таких исходных данных чаще всего соответствует выражению: «на любые вопросы мы даем любые ответы».
Под конец проектов мы каждый день слышим или говорим: «эта система полностью соответствует техническому заданию, но не делает того, что нам нужно» или «ой, мы забыли…» или «в этом техническом задании мы что-то имели в виду».
полностью отличается.
"
Со стороны исполнителя подобные технические задачи ставят, прежде всего, вопрос о том, как мы примем и сдадим результат. «Письмо дяди Федора» для исполнителя — хорошая заявка на «закабаливание» у заказчика на пару лет.
Полный жизненный цикл и структура системы не учитываются.
В какой-то момент становится ясно, что техническое задание должно быть написано и оно не должно быть написано бессистемно.
А коллеги на волне прозрения попадают в такую ловушку: если у вас в руках молоток, то все вокруг похоже на гвозди.
В зависимости от того, кому принадлежит идея проекта: специалистам по аппаратному обеспечению, специалистам по эксплуатации программного обеспечения или кому-то еще, мы получаем перекос в разные стороны.
Разработчики программного обеспечения любят писать подробное техническое задание на программу, забывая о том, что им нужно привезти и установить оборудование и позаботиться о каналах связи.
Допустим, такое даже возможно, но это будет стоить совсем других денег.
Инфраструктурщики (особенно со стороны поставщика) и люди с архитектурными амбициями любят акцентировать внимание на красивых архитектурных решениях вопросов мониторинга, катастрофоустойчивости, высоких нагрузок и прочих «космических кораблей, бороздящих просторы Большого театра», забывая о функциональной композиции.
Разобравшись в железе и ПО, они часто (но зачастую слишком поздно) обнаруживают, что нужно ещё как-то организовывать пользователей, мигрировать данные, «врезать» каналы интеграции в соседние системы и делать массу других интересных вещей, на которые забыли заложить бюджет. деньги и сроки.
Но что еще интереснее, оказывается, что часть работ невозможно выполнить без участия заказчика, который не всегда хочет там в чем-то участвовать.
Короче говоря, не вся работа, которую необходимо выполнить для работы системы, планируется.
Либо просто «чужие» или непонятные разделы проекта помечаются как «это не проблема» и недооцениваются по деньгам и времени.
Но это не все.
Система должна не просто запуститься, но и принести ожидаемый эффект и вернуть вложения, как бы мы не считали эту отдачу.
Об этом чаще всего забывают. Уже построенная, но бесполезная система саботируется пользователями, не получает необходимых ей эксплуатационных затрат и умирает. Казалось бы, для исполнителя это не так уж и важно, ведь свои деньги он получит. Фактически отсутствие ответов об эффективности и влиянии может создать проблемы с финансированием уже на этапе строительства у спонсора, при реализации у пользователей и при сдаче-приемке у заказчика.
Чем ближе подписывается приказ о переводе в промышленную эксплуатацию, тем больше люди думают о будущем – о том, что скоро им придется остаться наедине с системой, показать бизнес-эффект и отчитаться за вложение денег.
Замечаний становится все больше, они становятся все более мелкими и бессмысленными – люди затягивают завершение опытной эксплуатации, потому что чувствуют какой-то подвох, но не могут его понять.
Задачи предпроектного этапа не учтены
Чрезмерная детализация требований Допустим, мы преодолели предыдущие проблемы, решили написать техническое задание, поняли, с кем нам следует не забыть поговорить, поняли, что требования необходимо проверять на взаимные противоречия и обеспечивать полноту для всех точек зрения.Распространенной проблемой на этом этапе является непонимание текущей цели требований.
Нам пока не нужно нагружать команду входными данными и давать исчерпывающие описания тестировщикам.
При этом зачастую, услышав о том, что ТЗ нужны, еще до начала проекта коллеги пытаются написать (а заказчики заказывают) ТЗ на программное обеспечение, срок написания которого приходится на конец техзадания.
Теперь нам нужны технические характеристики системы — это другой набор решений как по составу, так и по назначению.
Неизбежно, что при попытке забежать вперед, это оказывается либо слишком дорого (и мы еще не знаем, продвигаемся ли мы с проектом вперед или нет), либо слишком расплывчато, поскольку невозможно принять все необходимые решения.
начать разработку в приемлемые сроки и бюджет предпроекта.
В такой ситуации люди, участвующие в процессе, теряют веру в практику написания технических заданий и идут искать лучшей жизни в других практиках.
Объем и достаточное разделение системы не представлены.
Допустим, мы разобрались, какую спецификацию писать.
Учитывая, что судьба проекта не ясна, нас просят удешевить техническое задание и часто вместе с водой выплескивают и ребенка.
Я видел множество технических характеристик системы, из которых невозможно получить полный и четкий список, дающий нормальную оценку.
Непонятно, что покупать, что, где и на что устанавливать, как подключить и настроить, что развивать, кого обучать, кого нанимать или отвлекать, откуда и куда мигрировать данные и т.д. Оценка стоимости системы не уточняется и нет «пространства для торговли» по цене и срокам: что будем сокращать и какие возможности в этом случае «отвалятся».
И это естественно, так как до технического задания нужно придумать концепцию системы.
Вопрос о достаточном разделении системы — это одна сторона медали.
С другой стороны, сама реализуемость – это возможность получить запланированный эффект и выполнить требования, соединив определенное количество компонентов в единое целое.
Концептуальный образ системы, который необходимо будет создать, призван доказать, что пользователи получат необходимые им возможности, заказчик — эффект, а спонсор — возврат инвестиций.
Кроме того, это обеспечивает основу для построения системы, что приводит к разумному определению стоимости.
Хорошая концепция не бесплатна; вам нужно уметь сделать это недорого.
Поэтому часто создается плохая концепция или ее вообще нет. Нет понимания целей клиента.
Сумев определить список пунктов, подлежащих проверке, мы вплотную подошли к вопросу эффективности системы.
Когда финансовый директор нам говорит: «Вы сейчас прочитали мне 243 функциональных требования, 15 нефункциональных требований, 10 видов поддержки, но для меня это белый шум.
Скажите мне проще, что улучшится, если я сейчас запланирую и потрачу именно эти 5 миллионов долларов? Кого мы можем уволить? Будем ли мы продавать или производить больше? Готовы ли вы принять это как обязательство? Люди, которые распределяют деньги, думают об эффективности и эффекте – они несут ответственность за эти деньги и показатели.
Этот вопрос будет задан прямо или косвенно подрядчику во время сдачи-приемки системы.
Обычно, если работа ведется через документы, ответами на такие вопросы отвечают бизнес-требования (или требования заказчика), которые необходимо создать до концепции.
Нет оснований для принятия результата Выполнив обоснование производительности (устное или письменное, точное или приблизительное), мы должны решить последнюю задачу – объяснить будущей команде проекта, что от них ожидается, чтобы получить именно то, что мы заложили в бюджет и обосновали, а не материализация иллюзий, комплексов, страхов, амбиций, симпатий и антипатий исполнителя.
Требования должны быть не только полными, обоснованными, реализуемыми, но и проверяемыми.
Это отдельная работа и еще один документ – собственно техническое задание на систему, которое не следует путать с техническим заданием на программное обеспечение.
В результате при выполнении задач предпроекта необходимо понять требования бизнеса, придумать концепцию системы, утвердить вариант концептуального решения, подходящий по соотношению цена/эффект (или возможностям) заказчика и запишите окончательные договоренности в техническое задание для проектной команды.
Выбран неверный режим связи запроса
А так мы все сделали правильно: осознали важность технического задания, не доверили его разработку случайным людям и случайному процессу, выполнили задачи предпроектного этапа и теперь остается только донести решения до всех заинтересованным лицам, чтобы основное соглашение о запуске проекта вступило в силу.Может быть обидно, проделав за короткое время значительную работу, поняв для себя эффективность, окупаемость системы, ее концептуальный образ, план создания и стоимость, просто не донести все это до нужных стейкхолдеров, влияющих на запуск системы.
проект. Общение в предпроекте описывается фразой: «Первое впечатление можно произвести только один раз».
Если проекту отказано в финансировании, потому что спонсор не уверен в эффекте, или заказчик не уверен в эффекте, или пользователи не уверены в новизне получаемых возможностей, то «показать класс» уже будет невозможно.
.
Кто платит и как сделать дешевле
В обсуждении предыдущей части этого цикла статей тов.exehoo сосредоточили наше внимание на очень правильном вопросе: «Есть еще серьезная проблема типа «Кто будет платить за предпроектные работыЭ» Ведь когда непонятно, начнем или нет, никто не любит платить.
Для поставщика решений предпроектная работа входит в бюджет продаж и маркетинга; для организации заказчика он чаще всего попадает в неизвестное место.
Однако вопрос о том, платить или не платить, не стоит. Правильный вопрос: за что платить и сколько платить.
Вы можете пойти методом проб и ошибок, который хитро называется «прототипированием».
Вы можете прибегнуть к проектированию и проработке требований.
Вопрос в том, что дешевле:
- платить за доработку, что часто означает переобучение сотен тысяч пользователей;
- или для дизайна, который зачастую не может дать достаточно точного представления о будущем.
Наша задача — сохранить баланс между стоимостью решений и их детализацией с учетом вероятности их изменения в будущем.
Как только проектирование становится дороже, чем доработка, его следует остановить или отложить на более поздний срок, когда будет больше уверенности.
Именно здесь растет принцип поэтапной организации жизненного цикла ИТ-системы.
Подробнее об этом вопросе, а также о том, о чем еще нужно помнить при запуске ИТ-проекта, мы поговорим в следующей части.
Теги: #Управление продукцией #Системный анализ и проектирование #аналитика #управление проектами #системный анализ #суперзадание #бизнес-анализ #предпроектный анализ
-
Электрический Лонгборд Своими Руками
19 Oct, 24 -
На Шаг Ближе К Восстановлению Тимуса
19 Oct, 24
