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

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

Работая на стороне заказчика в клиентской компании, автор имел рабочую загрузку в пределах 70-80%. В этом режиме времени обычно хватало не только на выполнение всех поставленных задач, но и на изучение новых технологий, управленческих методик и других интересных направлений. Хотя иногда случались авралы и завалы, в среднем за период рабочего времени баланс был приемлемым. В консалтинге же уровень загрузки значительно вырос — до 120-130%, а в пиковые периоды достигал 160%. Это привело к острой нехватке времени и поставило вопрос 'как это всё вообще можно успеть', требуя поиска специальных подходов к управлению временем и повышению личной эффективности.

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

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

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

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

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

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

По мнению автора, важно точно обозначить проблему управления временем, потому что без чёткого определения задачи решение искать сложно. Ранее автор обращался к этой теме неоднократно, изучал материалы, применял какие-то подходы, но никогда не формулировал в чём именно заключается задача, которую он пытается решить. Сейчас он осознал, что это 'непорядок', и выделил четыре основных аспекта проблемы для более целенаправленного решения. Четкая формулировка проблемы позволяет: - Четко понимать, что именно нужно решать - Разрабатывать более точные и эффективные стратегии решения - Распределять усилия на устранение конкретных аспектов проблемы - Оценивать прогресс в решении Таким образом, обозначение проблемы является необходимым первым шагом к её решению.