Четкие границы между инцидентом, запросом на обслуживание и запросом на изменение - это скорость и предсказуемость. Далее - простой детектор и чек-листы для бизнес-приложений.
Важные управленческие навыки приходят не только из книжек. Отцовская повседневность дает свои уроки: эмоциональный интеллект и терпимость к неопределенности. Эти навыки не про мягкость, а про результат команды и бизнеса.
Конечно не нужны. Понадобятся только в трех редких случаях: когда важно видеть, что именно поменяли; когда завтра должно работать так же, как сегодня; когда не хочется платить штрафы. Но это же мелочи, правда?
Цифровые ассистенты становятся частью рабочего процесса. Такие ассистенты есть и у нас.
Визуализация через несколько уровней детализации - это простой способ превратить сложную систему в понятную картинку, одинаково полезную бизнесу и разработчикам. Описание от общего к частному помогает нам самим увидеть состав, границы и роли участников на старте. Постепенное углубление помогает понять детали реализации и объем необходимых изменений - это упрощает диалог с бизнесом о сроках и стоимости.
"Да, без проблем, опыт есть, люди есть! Сто раз так делали. Завтра все сделаем." "Баг? Но не воспроизводится же. На проде воспроизвелся? Завтра все исправим." "У нас все готово! Мы все обновили! Завтра запускаемся" Никто, конечно, завтра не сделал, не исправил и не запустил.
Недавно я писал о брифе как первом контакте с RFC. Прежде чем подготовленный бриф уйдет на согласование, он проходит еще один важный этап - анализ на признаки проекта.
1 сентября традиционно ассоциируется с новыми знаниями для детей - они идут в школы, строят фундамент будущих успехов. А что насчет нас, взрослых? Готовы ли мы проходить новые уроки?
- Дорогой Дедушка Мороз, пишу тебе RFC. Сделай, пожалуйста, чтобы все там работало как надо. Зарелизь в следующую пятницу - заживем счастливо. - Дорогой пользователь, спасибо, что обратились в наше самое лучшее агентство по разработке. Мы очень любим размытые и непонятные запросы без владельцев и ответственных. У нас лучшие практики ожидания ответов, проведения бесконечных совещаний и безупречные шаблоны бесполезных протоколов.
Один из типичных паттернов техподдержки - защитная реакция. Пользователь жалуется на ошибку, а сервис-деск отвечает в оборонительном тоне: * "Система работает корректно" * "Вы сами ошиблись" * "Такое поведение задокументировано" Кажется, мы защищаем себя. На самом деле - подрываем доверие. 💡 Сервис-деск нужен пользователям, а не системе. Когда пользователь открывает отчет и не видит нужную сумму, ему не поможет информация о регистрах, по которым считаются обороты. Он видит проблему - и ожидает решение.
