Качество, трюкачество и немного ловкачества
Автор
Александр Башкиров
Есть мнение, что качество в ИТ — вещь, недостижимая изначально, по определению
Есть мнение, что качество в ИТ — вещь, недостижимая изначально, по определению. Потому что не успевает выйти на рынок один качественный ИТ-продукт, как оказывается, что на самом деле этих продуктов море, или что на рынок рвется нечто очень похожее, но лучше, или что в конкурирующем продукте есть «чуть более удобная фишка», он «чуть более интересный» и делается с «чуть лучшим качеством» — ну и т. д. Это если говорить о продукте. А если вести речь о ИТ-сервисе как о процессе, то идеал недостижим никогда — просто потому, что ожидания всегда чуть впереди возможностей. На шаг впереди, как говорится.
Про ожидания пользователей
Перефразируя закон Мерфи, можно сказать: сколько не делай пользователям удобно, все равно будет мало. Это вовсе не означает, будто пользователи плохие, нет — упаси Бог! Пользователи — наше все, ИТ существует ради пользователей, для пользователей и во благо пользователей. (Как бы некоторые из пользователей же не утверждали обратного.) В этом смысле, говоря о качестве, необходимо иметь в виду два очень важных аспекта: текущую работу (вернее, ту, что ведется для обеспечения текущей работы пользователей с заданными параметрами) и перспективные разработки (то есть работу на перспективу). И если с текущей работой все более-менее понятно, то с работой на перспективу обычно возникают сложности.
Хотя как «более-менее понятно»? Разделить пользователей по категориям, выделить сервисы, выделить, описать и формализовать их метрики, для каждой категории пользователей определить время реакции, выстроить службу поддержки так, чтобы каждый получал максимально быстрое решение запросов в рамках отпущенного времени — действительно «просто и понятно». То есть, если делать «по-правильному», то делать придется долго, вдумчиво и постоянно анализируя окружение (отмечу, что это единственно верный путь, потому что все иные «от лукавого» или как минимум приводят к ситуациям «ошибки из прошлого»). К сожалению, возможности ИТ не безграничны (а бюджет не бездонен), поэтому зачастую не делают никак или обходятся полумерами: не важно, как хочет работать пользователь с ИТ — имеет значение, как служба ИТ готова работать с пользователем. Причем на многих предприятиях это считается нормой, стандартом де-факто: там качество понимается в первую очередь как беспрерывность работы сервисов. А пользователь, извините, по остаточному принципу. Несмотря на то, что в этих строках можно увидеть намек на негатив — его там почти нет. Поскольку ИТ не такое «само по себе» — обычно к подобной модели поведения и отношения есть вполне конкретные побуждающие обстоятельства: тот же бюджет, политика, корпоративная культура, наконец. Да тут прямо так и напрашивается знаменитый треугольник ограничений проекта: ресурсы — финансы — сроки (результат). Если «потянуть» за один из углов, то «поедут» остальные. И, если изначально на ИТ выделяется, например, небольшое (недостаточное) финансирование, то о каких стандартах качества может идти речь? Выжить бы — и не сделать хуже. Хотя это и крайний случай, но встречается.
Теперь про перспективу. Почему с ней сложно? Потому что для ее оценки нужен относительно достоверный прогноз развития потребностей и технологий. Какой запас по мощности закладывать в новое решение? Скольким пользователям понадобится он через год? А через три? Будет ли все работать через десять лет? На основании ответов на эти и подобные вопросы разрабатывается архитектура решения. А если ответов нет — что тогда? А если они есть, но из области научной фантастики? Что делать? А ведь именно проектирование архитектуры, предусматривающей возможность развития, — залог того, что решение оправдает как «эмоциональную», так и «техническую» составляющую качества. Нет, ответы на самом деле есть. Они сводятся к тому, что первые лица ИТ «интегрируются» в бизнес и, по сути, за своих «подопечных» вырабатывают концепцию, которую после согласуют со всеми заинтересованными со стороны бизнеса. Путь, конечно, непростой и чреватый определенными подводными камнями, но вполне реальный. А подводные камни — да где же их нет?
Вообще, чтобы идти таким путем, надо не только быть хоть каким-то экспертом в предметной области, но и обладать определенного рода настойчивостью, умением коммуницировать, харизмой, быть немного психологом, немного провидцем, немного шахматистом... Сложно? Ну тогда можно вернуться к первому пути — создать идеальные условия со стороны бизнеса.
Первичное и вторичное
С точки зрения качества вторично то, как именно оно достигается, — контролем кода, разработкой планов качества, процедур тестирования или внедрением метрик. Важно не то, как оно достигается, — важно то, как эти достижения понимаются и воспринимаются. Это верно применительно ко всему ИТ, потому что, как мы помним, все, чем управляет ИТ, — работает на конечного пользователя. А вот под этим лежит уже солидный пласт работ: каждая из составляющих ИТ-систем должна быть проанализирована с точки зрения качества, а дальше... дальше — должен произойти выбор наилучшего варианта, опять-таки с точки зрения качества. И уже это описывается в книгах: способы оптимизации кода, планы качества при тестировании ПО, методы обеспечения качества аппаратных комплексов... Но еще раз подчеркну: самым важным во всех рассуждениях «про качество» является «эффект системы», то есть эффект, возникающий при взаимодействии всех компонент. И это то, что практически невозможно формализовать «до последнего винтика», поскольку невозможно предугадать, как себя поведет та или иная система, даже понимая все параметры всех ее компонент.
Например, установка в сети нового оборудования. Тестирование показало, что оборудование работает, все прекрасно. Но спустя неделю с момента запуска выясняется, что у бухгалтера, который работал с банк-клиентом, этот самый банк-клиент резко перестал функционировать. Потому что именно в данной версии прошивки есть маленький и некритичный баг, не позволяющий именно этому банк-клиенту связываться с сервером банка... Причем все остальное — работает, гораздо быстрее и стабильнее, чем раньше.
То есть, рассуждая о качестве ИТ-продуктов, мы вольно или невольно переходим к системному подходу в организации технологий, людей и ценностей. Точнее, начинаем рассматривать все это в системе — той, что должна привести в конечном итоге к приемлемому результату. И «приемлемым» будет тот результат, который эмоционально понятен всем участникам процесса, а не только разработчикам.
Ведь что зачастую происходит? ИТ «что-то делает», это «что-то» может быть абсолютно надежным, но... кому какое дело до надежности той же, например, почтовой системы, если вокруг не работает все остальное?
Работа на внешнего заказчика
Я уже писал о том, что качество базируется на людях, процессах и метриках. По сути своей качество волне обладает «здоровым запасом дуализма»: будучи понятием эмоциональным, оно, тем не менее, всегда материализуется в виде достижения конкретных метрик, которые говорят о том, «качественно» или нет.
К чему все это? Да к тому, что с внешним заказчиком договориться порой гораздо проще, нежели с заказчиком внутренним: если в договоре сформулировано, как именно будет оценено качество — то вообще нет вопросов. Или то, что предъявляется заказчику, соответствует метрикам или нет. Третьего не дано. Да, эмоционально качество может восприниматься не так, как происходит фактически, но факты вещь упрямая. Поэтому при наличии в договоре метрик качества и их достижении можно (и нужно) утверждать, что требуемый уровень качества достигнут.
Хуже в ситуации, когда в договоре нет ни одной метрики качества, а заказчик предъявляет соответствующие требования. Тут возможны два варианта: или же заказчику нужен повод для придирок, или его действительно интересует качество. В каждом из этих случаев подход будет индивидуальный, но с точки зрения качества как класса, алгоритм един — рассматривать аналоги, сложившееся в отрасли. Это, конечно, занятие неблагодарное (может дойти и до двух-трех независимых экспертиз), но почти единственный разумный выход. Правда, есть и альтернативы. Например, заключить дополнительное соглашение по качеству, в котором уже четко сформулировать и определение качества применительно к проекту, и метрики. Но подобное соглашение, особенно в условиях, когда каждая из сторон «тянет одеяло на себя», — больше из области научной фантастики.
Однако договор договором, а есть такая вещь, как репутационная составляющая. И она работает порой даже лучше, чем формальные вещи. Хотя надо сказать, что иногда она не работает в принципе. (Есть такие компании, которые репутацией не дорожат.) Впрочем, апелляция к репутационной составляющей, как правило, достаточно слабый аргумент. Но если продемонстрировать, что ты готов не то чтобы «идти до конца», а предпринять хоть какие-то действия, кроме предупреждений, то может и сработать. Но это уже совсем крайний случай. Обычно фирмы, имеющие положительную репутацию, стремятся ее поддерживать: внимание клиента (и желание вернуться) стоит значительно дороже. Это осознают, но, к сожалению, далеко не все. Часто желание «получить денег и сделать план» начинает брать верх не только над качеством, но и над здравым смыслом. Но это, как говорится, совсем другая история.
Погодные условия
Еще раз опустимся с неба на землю и посмотрим на мир глазами простого пользователя. Начнем с того, что ему абсолютно все равно, кто именно предоставляет услугу — «внешний подрядчик» или «внутреннее ИТ». Ему надо «чтобы работало», и «работало хорошо», то есть без сбоев. Чтобы проблемы не возникали, а в случае возникновения решались так быстро, как возможно. По большому счету, пользователю не важно, работает ли вы по ITIL или как-то еще. Ему важен результат. Очень простой пример: к определенному времени нужно распечатать коммерческое предложение для передачи заказчику.
Менеджер за 15 минут до времени Ч отправляет его на принтер, и принтер не печатает. Согласно SLA, такого рода проблемы для данного пользователя решаются в течение двух часов. Но нужно-то через 15 минут! И в этой ситуации все формальные SLA не стоят того, что из-за ненапечатанного вовремя документа может сорваться крупная сделка. Будет ли доволен менеджер, если ИТ станет упорно следовать SLA? Сомневаюсь. Более того, полагаю, что руководитель этого менеджера также будет не в восторге. К тому же оправдание, что «принтер не печатал» — скорее всего, не посчитают оправданием. Да, ИТ, конечно влетит... но после того, как каждый из участников цепочки получит свою долю негатива. Мораль очень проста: качественная услуга — это не только та, для которой соблюдается SLA, но и та, что способна работать на опережение SLA, в свете ситуации. Другими словами, если рассуждать формально, то в рассмотренном примере должен быть предусмотрен факт форс-мажора в SLA — тогда принтер успели бы отремонтировать до того, как ситуация стала необратимо ухудшаться. Если подходить не формально, а «с пониманием и вниманием», то, с учетом ситуации, ремонту принтера надо было дать приоритет № 1. Ну а худший случай — просто следовать SLA: «Вам нужна печать? Позаботились бы об этом заранее».
Ловкость рук и немного о фантастике
Все, что говорится о качестве, упирается в одну простую и сложную вещь, а именно в процессы. Об этом шла речь чуть выше: организация людей — это как раз оно и есть. Почему данный аспект столь важен? Во-первых, потому что качество в ИТ неразрывно связано с процессной частью — как выстроил процессы, то и получил. Можно написать сколь угодно лояльное к пользователю SLA, но если в ИТ нет процессов, гарантирующих его обеспечение, то грош цена такому SLA. Да и доверие пользователей можно утратить очень быстро: много ли толку от моего знания, что за два часа, отведенные на устранение проблемы, не произойдет ничего, способного если не ликвидировать, то хотя бы приблизить решение данного вопроса? Или что с того, что в SLA записана, скажем, смена картриджей принтера по требованию, если устройство все равно перезаправляет приезжающий специалист и с момента «требования» до момента замены может пройти до суток? В общем, вывод прост: под каждым обязательством, взятым ИТ, должен подразумеваться конкретный, понятный всем участникам процесс исполнения этого обязательства. В случае с внешним заказчиком все в принципе аналогично: можно принять на себя сколь угодно жесткие обязательства перед заказчиком, но если не понимать заранее, как именно они будут исполнены, — то лучше и не брать. (Кстати, что с внешним, что с внутренним заказчиком было бы неплохо прописать процессы обеспечения: как подается заявка, как регистрируется, что отправляется заказчику, подтверждение и т. д.) Словом, желательно иметь четкий алгоритм для всех процессов, связанных с качеством — просто для того, чтобы не «ударить в грязь лицом». Кроме того, нужно, чтобы алгоритм не просто «был», но и исполнялся. А ведь это отдельная большая задача: обеспечить надлежащее исполнение процессов порой едва ли не сложнее, чем все остальное, вместе взятое.
***
В заключение немного разбавлю эту, местами пессимистическую картину: практика показывает, что в большинстве случаев работает так называемый средний путь. Он заключается в том, что, с одной стороны, работа в области качества происходит «по процессам», а там где их нет (или они по какой-либо причине непригодны) — «по понятиям». Мне крайне редко встречались случаи, когда качество отсутствовало как класс, поскольку рыночные условия и для внутреннего, и для внешнего заказчика сейчас таковы, что пренебрежение качеством может больно ударить по тем, кто допустил такое. И соблюдение стандартов качества превращается из кабинетной работы и научной фантастики во вполне реально работающий тренд. Потому что при прочих равных «лучше брать то, что качественнее».
Опубликовано 12.02.2014