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

Принцип распределения ответственности между группами при обработке просроченного инцидента заключается в том, что степень ответственности каждой группы пропорциональна её доле в общем времени обработки инцидента. То есть, если группа потратила большую часть времени на обработку просроченного инцидента, её доля ответственности будет больше и метрика KPI покажет более низкое значение. Формула учитывает время ti, которое каждая группа затратила на работу с инцидентом, и общее время Ti обработки инцидента. Таким образом, ответственность за просрочку распределяется более справедливо, чем при традиционном подходе, где вся ответственность возлагается на последнюю группу.

Чтобы определить, действительно ли бизнес нуждается в SLA, следует проверить несколько аспектов. Во-первых, включает ли ваш SLA компоненты L (Level – измеримые характеристики услуги) и A (Agreement – осознанное соглашение сторон). Во-вторых, проверьте, нужен ли SLA именно бизнесу, а не просто ИТ-подразделению как формальности. В-третьих, наблюдайте, используется ли SLA бизнесом после подписания: проходит ли он пересмотр, контролируется ли соблюдение условий. Если ответ на эти вопросы отрицательный, то SLA не востребован бизнесом и не несет практической ценности для организации.

Делегирование задач — это ценный навык для руководителя, так как он позволяет оптимально распределять работу между командой, развивать компетенции сотрудников и освобождать время руководителя для решения стратегических задач. Умение делегировать наполовину показывает, что руководитель способен построить систему работы, где каждый участник выполняет то, в чём он наиболее силён. Это особенно важно в небольших коллективах, где полное разделение ролей невозможно, и необходимо находить баланс между личным участием в работе и управлением процессами.

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

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

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

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

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

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