25 июня 2014 г.
Большое количество высокому качеству: лучше больше да лучше!
© Алишер Файз
Давайте сегодня поговорим про качество. Это один из варьируемых показателей ИТ-проекта. Помните известное выражение «Есть три показателя проекта: стоимость, сроки, качество. Выберите любые два»? Каждый работающий в ИТ-области, особенно в сфере оказания консалтинговых услуг, периодически задает себе вопрос: должного ли качества данный проект? Полагаю, что менеджеры со стороны клиентов задают себе такой вопрос даже на порядок чаще, ведь срок проекта и его стоимость четко прописаны в договоре, а про качество обычно говорится достаточно пространно: работы должны быть выполнены (или услуги оказаны) качественно.
Что же такое «качественно»?
По версии ГОСТ
Согласно ГОСТ Р ISO
Итак, качество предполагает соответствие требованиям. В заказе на ИТ-систему требования четко прописаны. Если этим требованиям разработанная система соответствует, то система качественная. Только вот как четко трактовать понятие «соответствует»?
Недавно после очередного посещения официального сервиса известной автомобильной марки мне позвонили и попросили оценить качество услуг. Причем оценивали по пяти градациям:
- Исключительно удовлетворен.
- Полностью удовлетворен.
- Удовлетворен.
- Не полностью удовлетворен.
- Не удовлетворен.
Кстати, такие градации (очевиден прилежный перевод с одного из европейских языков), по отзывам работников сервиса, доставляет немало трудностей. Ну кому в России придет в голову охарактеризовать результат услуги как «исключительно удовлетворен». Это как надо услугу оказать, чтобы было «исключительно»? Кофе угостить, подушку дать, в постель уложить, колыбельную спеть? Но в целом подход понятен — есть ожидания качества услуги, есть обратная связь. Т.е. если потребитель удовлетворен, то и услуга оказана качественно.
В применении к ИТ есть, правда, своя сложность — большое число потребителей ИТ-системы. Всем не угодишь. Вам нравится ездить на машине по широкой ровной скоростной свободной дороге? Да. А нравится, когда такая дорога под вашим окном? Нет.
Но даже если бы потребитель был один, дополнительных факторов, влияющих на оценку качества проекта, очень много. Начиная с терминологии. В моей практике был занятный случай — я участвовал в команде, которая убеждала потенциального заказчика, что наша система — это то, что ему нужно. В процессе разговора происходит такой диалог:
— Ну хорошо, в вашей системе «из коробки» реализован график платежей?
— Конечно.
Когда я в составе проектной команды пришел внедрять систему, подошла очередь как раз графика платежей. И тут выясняется, что клиент ожидал увидеть прогноз кассовых разрывов, аналитику, где выгоднее взять кредит, а не простой перечень заявок на платежи с отчетом вида «перечень». Я, конечно, немного утрирую, но суть именно такая: мы ожидаем одно, а получаем другое.
В таких случаях крайне важен профессионализм исполнителя, его проектной команды, умения этой команды управлять ожиданиями клиента. По управлению ожиданиями написано много учебников, повторяться смысла нет. Обязанность клиента — выбрать тех нескольких (чем меньше, тем лучше) потребителей, которых нужно удовлетворить. А обязанность консультантов — понять, что значит «удовлетворить» и выработать соответствующие критерии.
Система должна соответствовать критериям, понятным и консультанту, и клиенту. Причем, понимаемым ими одинаково. Как этого достичь? Для объектов материального мира (и соответствующих активов) придумали чертежи, которые позволяют однозначно ответить на вопрос «соответствует ли». К примеру, на чертеже деталь должна быть 10 мм длины с допуском +/- 0,2мм. Измеряем. 10мм? Если от 9,8 до 10,2 мм — да, соответствует. Если допуски выше, то не подходит.
Думаю, что задача каждого консультанта — определить эти миллиметры, придумать или «вытащить» из головы пользователя измеримые критерии, подтвердить, что именно этими критериями будет оперировать клиент при приемке. Желательно, чтобы этих измеримых критериев было не очень много. Они по сути должны быть целью проекта.
— Что вы ожидаете от проекта, от его результатов? Как изменится ваша работа?
— Ожидаю, что отчеты вместо двух часов будут формироваться не более 20 минут по 8 филиалам, с выборкой такой-то...
К сожалению, пользователи достаточно редко могут так детально сформулировать целевые параметры. Чаще бывает по-другому — «Система должна работать быстрее». Тогда превратить это в «не более 20 минут с параметрами....» — работа проектной команды. При этом очень важно закрепить достигнутые договоренности в каких-либо документах. Иначе может быть так: если именно этот пользователь перестанет участвовать в проекте, то у пришедшего ему на замену могут быть другие критерии удовлетворенности. К примеру, ему может быть важно не время отчета, а его внешний вид.
Мой совет: плотнее общайтесь с клиентом на всех уровнях. Зайдите к ключевым пользователям, поймите, чем они живут, какие показатели учитывают. Какие производят действия, что при этом оценивают. За что их ругают, а за что хвалят. Если система будет помогать им делать ИХ работу, то они будут удовлетворены, даже если не будет особой красоты и система не сможет варить кофе. Если же нет, то, поверьте, и кофе не поможет.
Другие статьи автора: По щучьему велению, или Как сократить сроки внедренческих проектов, Почему затягиваются сроки внедренческих проектов? Внешние факторы, У семи нянек дитя без глазу, или ошибки вида «несколько заказчиков в структурах управления проектом».
Источник: Андрей Шоханов, советник руководителя дирекции по работе с предприятиями нефтяной и энергетической отрасли, ЗАО «ЛАНИТ»
