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

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

Адаптация к клиенту играет ключевую роль в бизнесе, так как именно удовлетворение потребностей клиентов обеспечивает устойчивость и рост компании. Этот принцип остается актуальным на протяжении десятилетий: от неформальных предложений на рынках 1990-х, таких как «Рассмотрю любые предложения», до современных формулировок миссии компаний, ориентированных на «качественное удовлетворение покупательского спроса».

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

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

ITIL рекомендует избегать абстрактного термина «срочность» потому, что его неопределённость приводит к неоднозначной интерпретации. Поля с уровнями «низкая», «средняя» или «высокая» срочность часто используются бизнесом некорректно — например, для максимального приоритета выставляется «сверх-срочность» даже в незначительных случаях. Это создаёт путаницу и снижает эффективность управления изменениями. Вместо этого ITIL акцентирует внимание на чёткой конкретизации срока реализации и оценке влияния на бизнес, что позволяет объективно расставлять приоритеты.

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

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

Деловая игра 'Проект Феникс' демонстрирует, что кратное ускорение действительно возможно без смены персонала. На начальном этапе участники, работая как в обычных компаниях, показывают низкую эффективность: Time to Market составляет около 25 минут на задачу, а процент завершённых задач - 25-50%. К концу дня, после осознанного подхода к организации работы - правильной приоритизации задач, управлению потоком и внедрения ограничений на текущую работу - Time to Market снижается до 40 секунд - 1,5 минуты, а процент завершённых задач возрастает до 85-100%. Это подтверждает, что системные изменения в организации процессов, даже без изменения архитектуры и технологий (в рамках игры такие изменения невозможны), могут привести к ускорению в 15-25 раз.

Альтернативы иерархическим структурам управления, которые могут повысить эффективность ИТ-подразделений: - Создание самоорганизующихся команд вместо традиционных отделов. - Внедрение подхода коллективной ответственности вместо ответственности тим-лида. - Переход к управлению задачами вместо управления людьми. - Фокус на потоке создания ценности вместо распределения задач. - Использование продуктового подхода вместо проектного. - Формирование гибких сетевых структур, которые могут быстро адаптироваться к изменяющимся условиям. - Применение Agile-методологий и других современных подходов к управлению. - Создание плоских иерархий с минимальным количеством уровней управления.