Книга: Франчайзи на грани нервного срыва. Как небольшой фирме-партнеру 1С перестать выживать и начать зарабатывать
Назад: Глава 38. Как долго рассчитывать стоимость доработки
Дальше: Глава 40. Как провалить несколько тендеров из-за пустяков

Глава 39. Как определить качество программы, не беспокоя пользователей

– Рустэм, там заказчик звонит, ругается. Будете с ним общаться?

– Конечно. Соединяй.

– Ваша программа никуда не годится! Мы работаем на ней уже полгода, а ваша техподдержка так и не устранила все наши замечания!

– А что за замечания?

– Много разных. Ну вот, например, у нас в Волгоградской области есть особенности в учете коэффициента…

– Погодите, мы обеспечиваем поддержку Российского законодательства в своих программах. Но речь не идет о местном законодательстве. У нас – 85 регионов, мы не можем уследить за всем. Доработку можем сделать для вас по договору сопровождения...

Бывают и совсем другие сообщения – от довольных клиентов. Которые раньше работали в Excel или устаревших программах.

– Мы так довольны! Программа – супер. Теперь нам не надо работать в выходные, чтоб выставиться в срок!

Такая же точно ситуация и с отзывами наших сотрудников. Кто-то считает, что программа – недостаточно хороша. И ее приходится не только настраивать, но и дорабатывать при внедрении у конкретного клиента. Специалистам отделов продаж не нравится часть интерфейса. Он – типичный для 1С, а им хотелось бы поражать пользователей чем-то особым при первой же демонстрации. Но эти же ребята в другой день бывают совершенно счастливы. «Мы показывали нашу программу специалистам Очень Большого Клиента. Они не ожидали, что в типовой программе 1С так глубоко проработана договорная работа с абонентами».

Как же судить о качестве программы при таких противоречивых отзывах? Может быть, воспользоваться готовой системой оценки качества программы пользователями, которую предлагает вендор?

Конечно же, мы знаем о такой системе и давно пользуемся ей. Оценку могут давать наши пользователи сервиса «1С:ИТС Отраслевой», зарегистрированные на сайте 1С. Очень ценно получить комментарий к оценке, поясняющий ее значение. Но, к сожалению, вот с чем мы столкнулись при использовании данной системы.

Во-первых, оценку давать не обязательно. Если пользователям системы «не жмет», они вообще забывают о возможности дать оценку. Если же хоть что-то идет не так, пользователи обязательно зайдут на сайт и поставят двойку. В итоге получается, что свободная средняя оценка всегда стремится к своему низшему значению. Удивительно эффективный метод работы с таким несовершенством системы я обнаружил в своем отделе инновационных разработок. Ребята регулярно прозванивали пользователей и просили поставить хорошую оценку. Объясняя это тем, что средняя оценка влияет на их КPI, а значит, зарплату. Добрые клиенты помогали как могли. Благодаря этому «инновационному» методу управления качеством оценка дошла до 4,5. И мы почти попали в список «Топ-10 лучших программ 1С».

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

Конечно же, такая ситуация с оценкой качества меня не радовала. Я не понимал, качество у нашей программы – высокое или низкое? Нужно ли инвестировать в ее доработку? Или радоваться, что программа хорошо продается, и подсчитывать прибыль? И я задумался о том, что можно было бы сделать. Как перейти к такой системе оценки качества, которая бы не зависела от конкретной оценки пользователя, но учитывала бы реальное соответствие программы требованиям потребителей?

И я, конечно же, обратился к трудам классиков. Кто больше всего знает о качестве и по-настоящему умеет им управлять? Конечно же, это –Масааки Имаи, автор книги «Кайдзен. Ключ к успеху японских компаний». Книга, безусловно, хороша сама по себе. Одно только начало чего стоит!

«… Для новых экономических условий стали характерны:

– резкое повышение цен на сырье, энергию и труд;

– наличие излишков производственных мощностей;

– рост конкуренции между компаниями на насыщенных или сокращающихся рынках;

– изменение ценностной ориентации потребителя и ужесточение требований к качеству;

– потребность ускоренного создания и продвижения на рынок новых продуктов;

– потребность в снижении точки безубыточности (breakeven point)...»

И ничего, что это – цитата из книги, изданной в 1986 году и описывающей мир в эпоху после нефтяных кризисов 70-х. Ее смело можно применить к франчайзингу «1C» в 20-х годах этого тысячелетия:

Внимательно изучая эту замечательную книгу, я обнаружил в ней то, что искал. А именно – подход, который называется «Структурированием (развертыванием) качества».

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

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

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

Предприятие заказчика:

– Руководитель предприятия (выражающий также интересы собственника предприятия)

– Начальники отделов, использующих программу или результаты ее работы

– Пользователь программы

– Руководитель службы ИТ (выражающий также интересы специалиста техподдержки службы ИТ)

Партнер фирмы 1С:

– Руководитель (как правило, собственник) предприятия

– Менеджер по продажам

– Специалист, непосредственно внедряющий программу

Фирма 1С:

– Менеджер по отраслевому направлению (непосредственно общается с нами и представляет все требования фирмы 1С)

Наше предприятие:

– Руководитель (собственник) предприятия

– Начальник отдела инновационных разработок

– Специалист техподдержки отдела инновационных разработок

– Руководитель отдела продаж

– Специалист, непосредственно внедряющий программу

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

– Все выработанное (произведенное) тепло должно быть реализовано абонентам

– Оплата за все реализованное тепло должна быть получена в полном объеме

– Расчеты реализации тепла должны соответствовать законодательству РФ.

А вот требования одного из пользователей:

– Чтобы не нужно было вручную собирать отчеты, которые хочет руководство

– Чтобы программа сама считала как надо по законодательству РФ и не нужно было ничего досчитывать в экселе

– Чтобы не нужно было открывать много окон для получения нужной информации и совершения нужных действий

Ниже – требования техподдержки ИТ-службы одного из клиентов:

– Приемлемая скорость устранения ошибок разработчиком

– Приемлемая скорость получения консультаций от техподдержки разработчика

– Готовность техподдержки разработчика работать с рабочей базой, а не с демо-базой

– Прозрачная система работы с техподдержкой разработчика (чтобы в любой момент можно было видеть состояние своего обращения, приоритет, плановый срок ответа, плановый срок устранения ошибки и т. п.)

– Отсутствие ошибок в программе

– Расширяемость (простота доработки программы)

– Ремонтопригодность (при доработках программы изменение одного модуля не должно требовать изменения других модулей)

– Соответствие исходного кода программы стандартам (в том числе стандартам фирмы 1С);

– Актуальная документация по программе (описание по отражению в программе конкретных ситуаций)

– Актуальный учебный курс по программе

В итоге у нас собралось несколько десятков разнообразных требований. Измерять качество по такому списку было бы очень трудно, тут требовался анализ и синтез. После систематизации требований мы пришли к иерархическому списку параметров качества программы:

Экономическая выгода:

– Экономическая выгода для клиента – высокая степень реализации произведенной тепловой энергии

– Экономическая выгода для клиента – высокая степень собираемости оплаты

– Экономическая выгода для клиента – высокий уровень автоматизации и снижение трудоемкости выполнения функций персонала

– Экономическая выгода для партнера

– Экономическая выгода для разработчика

Соответствие законодательству РФ:

– Степень соответствия законодательству РФ

– Скорость отражения изменений в законодательстве РФ

Функциональность:

– Степень соответствия функциональным требованиям

– Скорость появления новой функциональности

– Интегрированность со смежными программами

– Интегрированность со смежным оборудованием

Техподдержка:

– Удобство и прозрачность техподдержки

– Скорость получения консультаций

– Отсутствие ошибок

– Скорость устранения ошибок

– Глубина техподдержки (работа с базами клиентов)

– Квалификация техподдержки

Удобство использования:

– Простота и интуитивная понятность интерфейса.

Производительность (скорость выполнения различных операций)

– Скорость расчетов и подготовки отчетов приемлемая

Качество кода:

– Соответствие кода внутренним стандартам (в том числе, фирмы 1С)

– Ремонтопригодность (изменение одного модуля не требует изменения других)

– Расширяемость (простота добавления нового функционала)

– Прозрачность и самодокументируемость кода

Документированность:

– Наличие актуального учебного курса;

– Наличие актуальной документации по программе (в том числе helpы, инструкции, методические материалы);

– Оценка на портале ИТС Отраслевой;

– Полнота и работоспособность демо-базы (в том числе демо-сервера).

Также в отдельный блок были выделены показатели, которые мы уже измеряли:

Отзывы потребителей:

– Оценка программы со стороны клиентов (по результатам дополнительных опросов по процессам системы менеджмента качества)

– Оценка программы со стороны партнеров

– Оценка программы со стороны наших продавцов

Ну, с параметрами мы определились, и это было здорово. Правда, оставался один маленький вопрос – как же нам измерять эти параметры? Создать для каждого свою шкалу? А что дальше? Опять опрашивать пользователей? «Как вы считаете, по шкале от 1 до 10, насколько наша программа соответствует законодательству?». С одной стороны, это казалось не таким уж плохим решением. Вместо вопроса «Как вы оцениваете качество нашей программы в целом?» мы могли задавать более конкретные вопросы. Но это не решало проблему нежелания пользователей давать ответы. И даже усугубляло ее! Теперь вместо одного ответа пользователю пришлось бы давать два десятка – отдельно по каждому параметру. Также оставался риск получить негативный отзыв плохо выспавшегося пользователя. Или пользователя, который не мог справиться с локальной ошибкой в программе и проклинал ее в целом. И снова – торг и аварийные работы за хорошую оценку? Не очень нам этого хотелось!

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

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

Часть требований из этого списка была удовлетворена. По всем таким требованиям была посчитана трудоемкость, выполнена работа и написан отчет. Часть требований была оценена с точки зрения трудоемкости. А часть – вообще не была разобрана! Таких инцидентов, которые ждали своей очереди, было несколько сотен. Сотен, Карл! Это было очень интересное открытие, просто клад.

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

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

В итоге мы не только разобрали все неразобранные инциденты, но и получили в разрезе параметров качества:

Вот пример некоторых элементов такого списка.

Параметр качества:

– Простота и интуитивная понятность интерфейса

Ранее реализованные требования:

– Интерфейс рабочего места специалиста отдела сбыта – 160 часов

– Интерфейс рабочего места специалиста договорного отдела – 40 часов

Не реализованные требования:

– Интерфейс рабочего места расчетчика физлиц – 160 часов

Итого:

– Реализовано – 200 часов

– Не реализовано – 160 часов

– Всего требований – 200 + 160 = 360 часов

Дальше оставалось совсем немного: придумать цифровую формулу для расчета качества по каждому из параметров.

У нас получилась следующая формула:

Качество = (X + ТР) / (X + ТР + ТН) x 100 %,

где: ТР – Трудоемкость ранее реализованных требований по параметру;

ТН – Трудоемкость еще нереализованных требований по параметру;

X – Трудоемкость требований, реализованных по параметру на момент выпуска программы в первом релизе.

Х… Этот загадочный Х. Как его посчитать? Нет, общую трудоемкость разработки программы мы знали. Но как разбить ее по 20+ параметрам? Эта работа представлялась невыполнимой. И мы решили X просто проигнорировать. На самом деле, чего мы хотели добиться? Правильно, на 100 % качественной программы. Когда такое возможно? Правильно, в случае, если ТН = 0. Но в этом, крайнем, случае значение X становилось неважным!

В итоге у нас получилась следующая формула для расчета значения качества параметра:

Качество = ТР / (ТР + ТН) x 100 %,

где: ТР – Трудоемкость ранее реализованных требований;

ТН – Трудоемкость еще нереализованных требований.

Рассчитанное по формуле без X значение качества получалось гораздо ниже, чем с X. А значит, мотивировало на повышение качества намного сильнее. Неправильный расчет, таким образом, совсем не означал, что он некачественный.

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

Рассчитанное по формуле выше, общее цифровое значение качества программы составило всего 28 %:

Сводное значение показателя качества = 6 879 / ( 6 879 + 18 090) x 100 % = 28 %

То есть из всех накопившихся к программе требований на 25 тысяч часов реализовано было около 7 тысяч! Совсем небольшая часть – чуть больше четверти.

Очень интересно было посмотреть на качество программы в разрезе каждого параметра. Бэклог у нас ведется в программе «1С:Документооборот». Благодаря этому мы смогли быстро написать несколько отчетов и развернуть показатели качества по отдельным параметрам и временным периодам.

Пример такой развертки для групп параметров за 2019 год приведен на рисунке 1 на следующей странице.

После чего начальник отдела инновационных разработок задал мне несколько каверзных вопросов. Его вопросы и свои ответы на них я приведу ниже c небольшими сокращениями:

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

– Сейчас у нас нет понимания, насколько мы «хорошие» или «плохие» в цифрах. Мы даже не знаем, становимся мы лучше или хуже, и насколько. А значит, мы не можем управлять уровнем качества.

– Хорошо, у нас появится приближение такого понимания. Но что глобально изменится? Мы и так знаем, что нужно поддерживать законодательство, добавлять функционал, совершенствовать юзабилити, устранять ошибки и оказывать техподдержку. И мы и так этим занимаемся – все задачи в ежемесячных планах отдела относятся к тому или иному параметру качества. Что все-таки изменится?

– Появится цифровое понимание, становится программа лучше или хуже. Какие показатели сильно плохие, какие – сильно хорошие. При планировании доработок мы сможем принимать решения о направлении ресурсов в соответствии с определенными цифровыми правилами. Появится возможность на заявления недоброжелателей: «У вас плохая программа» отвечать: «Вовсе нет» и «Наша программа становится лучше с каждым месяцем». Мы наглядно покажем заказчикам, как растет качество нашей программы. И сможем мотивировать коллектив отдела в зависимости от качества программы и от скорости улучшения качества.

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

– Той точности, что мы получаем, вполне достаточно для управления системой. Мы сможем понять, по каким параметрам у нас провал, а где ? нет особых проблем. И сможем принимать управленческие решения по направлению ресурсов в нужную точку.

Цифровое измерение качества программы в терминах трудозатрат, требуемых для ее улучшения, привело к нескольким важным изменениям. Во-первых, мы приняли решение об усилении отдела инновационных разработок. Приняли в него еще одного сотрудника. Во-вторых, мы стали искать источники инвестиций для удовлетворения требований по развитию функционала системы. На этом пути родилась идея реализовывать значительные усовершенствования в виде отдельных модулей к основному решению. И продавать их за дополнительную плату или ставить вопрос о повышении стоимости основного решения с увеличенным функционалом. Так разрабатывался модуль «Расчет платы за негативное воздействие на окружающую среду» для программы «1С:Управление водоканалом 2». Также мы запустили магазин платных доработок. И обеспечили, таким образом, приток инвестиций в развитие функционала, по которому накопился пул нереализованных требований.

Наверное, вам интересно, а как же изменилось качество программы со временем? За год общее качество программы выросло на 10 %. А безошибочность – на 20 %. И рост продолжается.

Назад: Глава 38. Как долго рассчитывать стоимость доработки
Дальше: Глава 40. Как провалить несколько тендеров из-за пустяков