Кому: Узкому кругу читателей
От: Отдела совершенно бесполезных советов (ОСБС)
Куда: Туда, сюда и, может быть, везде
СОВЕРШЕННО СЕКРЕТНО
Прошу принять к действию следующие указания для нарушения бизнес-процессов и повышения уровня негативного клиентского опыта:
1. Подход к планированию изменений
При планировании изменений в системах и процессах, связанных с предоставлением услуг и сервисов нашим клиентам, необходимо соблюдать абсолютную секретность. Рассматривать влияние производимых изменений на сопутствующие или параллельные процессы недопустимо, необходимо увеличить риски неработоспособности ключевых и особенно сквозных бизнес-процессов, работы всех систем ИТ-ландшафта. Формировать общие рабочие группы, получать обратную связь от клиентов и создавать общий план/карту изменений СТРОГО ЗАПРЕЩЕНО!!!
2. Работа над этапами проекта
При проектировании, разработке и тестировании будущего бизнес-приложения отказаться от услуг системного анализа и архитектурного надзора. Это обеспечит отсутствие бизнес-выгод от проекта из-за некачественной реализации системы управления и, соответственно, нарушений в производственно-хозяйственной деятельности компании. Также будет создана высоковероятностная угроза асинхронной работы нового приложения и уже существующих решений. Даже если угроза не сработает при запуске системы в промышленную эксплуатацию, это обязательно случится в будущем в самый неудачный момент.
3. Ожидания бизнес-заказчика
Ожидания бизнес-заказчика (идеолога) будущего цифрового решения не должны учитываться ни при формулировании требований, ни при формировании финансовых показателей внедрения, ни при выборе партнера проекта. Все количественные и качественные требования проекта должны быть сформулированы в неоднозначной и неопределенной форме, желаемые результаты должны быть максимально верхнеуровневыми и завышенными. Принятие решений по ходу проекта — только коллегиальное, без личной ответственности участников рабочей группы.
4. Выпуск нового ИТ-продукта
Отсутствие плана выпуска новых продуктов, услуг или сервисов практически 100% гарантирует негативную обратную связь от рынка и репутационные риски, формирует отрицательный клиентский опыт и обеспечивает устойчивое падение бизнеса по ключевым критериям. Любая активность, связанная с выходом нового или обновленного функционала сервиса или продукта, должна идти в строгой секретности, чтобы управление эксплуатации и поддержки ничего не знало. Категорически запрещается проводить демонстрацию или обучение пользователей тому, как эксплуатировать новый продукт. При получении ожидаемых негативных результатов нужно максимально долго решать проблему, только в рабочее время и с привлечением всех сотрудников компании, кроме технической поддержки. И помните классику проектного управления: «Внедряй, но тихо, чтобы пользователь не знал. До тех пор, пока пользователь не знает, ты в шоколаде, ты красавец, тебя все любят!»
5. Использование практик и опыта
Формирование базы знаний и регламентов обслуживания для технических специалистов не предусмотрено, проблемы решают с помощью поиска в сети Интернет. Применение лучших практик и наработок команд разработки и поддержки не поощряется, обмен опытом между техническими специалистами не приветствуется. Решение о возможном обучении специалистов для повышения квалификации принимается исключительно по минимальной стоимости предложения.
КОММЕНТАРИИ К УКАЗАНИЯМ
- При нарушении любого из этих указаний есть риск получения положительного клиентского опыта и роста ценности компании на рынке.
- Нарушение п. 1 указаний может привести к неоправданному вниманию к вашим действиям. Это повлечет за собой массу бесполезных советов и согласований во избежание одной из наших основных целей — нарушения бизнес-процессов.
- Системный анализ и архитектурный надзор ведут к уменьшению наших деструктивных действий. Они призваны снизить их до нуля.
- Четко сформулированные и измеримые требования приведут к понятному и быстрому результату, соответственно, к положительному опыту клиента. Это недопустимо.
- Неисполнение п. 4 указаний ведет к испугу соседних подразделений и их неадекватной активности в вашем проекте. Их основная цель — снижение ваших деструктивных действий, направленных на их процессы.
- Если о выпуске продукта, услуги или сервиса прознают эксплуатация и службы сервиса, они могут испортить вам все веселье: их хлебом не корми, дай что-нибудь починить.
ПРИЛОЖЕНИЕ № 1
ПРИМЕРЫ УСПЕШНЫХ ПРОЕКТОВ, РЕАЛИЗОВАННЫХ ПО ДАННЫМ ПРАВИЛАМ
Пример первый
Финансовая организация решила автоматизировать выявление неблагонадежных заемщиков (юрлиц) с помощью системы принятия решения. Хочется отметить прекрасное владение вышеперечисленными указаниями. При работе над проектом применяли и повышенный уровень секретности от всех подрядчиков относительно принятых решений при проектировании каждого модуля системы, и отказ от архитектора всей системы. Вместо него поставили системного аналитика, догрузив сверху функционалом администратора проекта. Также было два стратегически важных шага. Первый — компания изменила требования к части системы, реализуемой одним из подрядчиков, после того, как другой подрядчик выполнил свои работы. Это прибавило остроты на этапе интеграции. Второй шаг — отсутствие плана запуска модулей системы в эксплуатацию. Это помогло загрузить службу эксплуатации бессмысленной работой и испортить ее репутацию.
Группа управления проектом отказывалась от рациональных предложений подрядчиков, мотивируя это отсутствием бюджета. При этом скрупулезно суммировала эти предложения, чтобы подготовить железобетонный аргумент для оправдания сдвига сроков проекта. Косвенные убытки и затраты от сдвига сроков и отсутствия результатов никто оценить не смог — все предположения разбивались о железобетонный аргумент «Экономия»! С помощью манипулятивных методов воздействия ответственность за общий результат перекладывали на подрядчиков. Действительно, за результат же отвечает подрядчик, а не сотрудник компании.
На данный момент сроки проекта превышены в три раза, количество эскалаций на высшее руководство компании и подрядчиков не поддается подсчету, а проект благополучно продолжает свое существование.
Пример второй
Здесь хочется рассказать про серийно повторяемый успех — это нечто удивительное. В компании есть обособленное подразделение. Его задача — развитие технических средств. Подразделение действует по строго отработанной и выверенной схеме с целью сформировать для себя высокую нагрузку, а значит, повысить собственную значимость, но ни в коем случае не создать ценность для бизнеса.
Схема включает несколько шагов, которые повторяются на каждом проекте. Начинается все со сбора требований, который осуществляют собственные аналитики. Это неплохо. Но предпочтение отдается тем аналитикам, которые могут быть привлечены здесь и сейчас. В какой степени они погружены в процессы подразделения, для которого будут производить изменения, значения не имеет. Процесс формализации требований ускоряется любыми способами ради самого ускорения, бизнес же требует все быстро сделать. Замечания и дополнения от бизнеса проходят «по касательной»: диалога и поиска альтернативных решений нет в принципе, подразделение накладывает ограничения на функционал, ссылаясь на сжатые сроки. При проектировании привлекают подрядчиков, выбирая их по стоимости и обещанным срокам исполнения, на компетенции подрядчиков в имеющемся ИТ-ландшафте опять же внимания не обращают. При этом скрывают от них реальное положение дел, а то «испужаются юродивые» и не захотят «заходить» в нового заказчика. Для экономии времени на проектирование и разработку пытаются переиспользовать имеющиеся сервисы, при этом не вдаваясь в подробности их реального назначения. Оценка идет на уровне «вроде, подойдет, а потом на проде доделают». Выпуск продукта в промышленную эксплуатацию происходит на тех же программно-аппаратных средствах, где проводится разработка. Вывод в продуктив может быть мгновенным и в любое время, как бизнес обычно и требует.
Поддержание этой схемы работы держится на единственном правиле: главное — быстро и в указанные сроки. Остальное — вина руководства и бизнеса, т. к. это их требование — сделать быстро и дешево.