Автор упоминает, что некоторые ИТ-специалисты воспринимают себя как "гуру и чуть ли не божества", чтобы подчеркнуть проблему излишней самоуверенности и ограниченности знаний у некоторых представителей ИТ-сферы. Он отмечает, что часто эти специалисты считают себя экспертами во всех вопросах только потому, что могут составлять простые программные конструкции из английских слов (for, while, if, loop), при этом их знание второго языка и технических аспектов обычно ограничено. Это создает барьеры в коммуникации с бизнесом и усугубляет проблему разобщенности между ИТ и бизнес-подразделениями.

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

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

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

При отсутствии предпроектного обследования возникает несколько серьезных рисков: подрядчики вынуждены завышать оценки бюджета и сроков из-за неопределенности задачи, что приводит к неоправданным увеличениям стоимости проекта; возрастает вероятность неполного или некорректного решения поставленных задач; повышается риск появления непредвиденных трудностей в процессе реализации; возрастает вероятность конфликтов между заказчиком и исполнителем из-за расхождения ожиданий. В среднем, риски при нечеткой постановке задачи начинаются от 10% и могут значительно увеличить итоговую стоимость проекта.

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

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

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

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

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