участников, что разговор продолжался три часа вместо запланированных полутора, и обсуждение часто носило без преувеличения драматический характер. Качество имеет множество аспектов, в этой области интересы разных людей могут почти не пересекаться. Тем более важно было понять, какие из вопросов качества — определяющие, задающие приоритеты и направления для всего остального. Забегая вперед, скажем, что анализу этих вопросов пришлось посвятить почти всю первую встречу по теме «качество».
«Мы не ищем легких задач!»
Диспозиция
|
На заседание были приглашены два известных эксперта в области надежности, качества и сертификации программ — В. В. Липаев, главный научный сотрудник ИСП РАН (Е-mail: boytchen@ispras.ru, subject: Mr. Lipaev), и Г. В. Виталиев, руководитель Отдела защиты прав на интеллектуальную собственность фирмы «АйТи» (g_vitaliev@boheme.ru). «Незримо» присутствовал В. В. Васютович, начальник отделения ВНИИстандарт ГОССТАНДАРТа России, предоставивший сведения о положении в области государственных стандартов по ИТ и СОД. В заседании Клуба, как и в прошлый раз, участвовали: А. Г. Цицин (фирма «Термика», ask@termika.ru), Е. К. Ким (ЦИП ООО СЕПТ, tais@arc.ru), Д. В. Соколов (ЦИЭС «Бизнес-Программы-Сервис», dvs@finsoft.ru), Б. А. Вольфман («ЭЛКО технологии», elco@elco.ru), Е. З. Зиндер (фирма «Группа 24», рубрика «Директору», ezinder@osp.ru).
То, без чего бессмысленно начинать
Важно было понять, какова роль качества потребительских ППК в реальной жизни создателей и потребителей этой продукции. Ставилась цель выделить массовый слой такой продукции, для которого обсуждение имело бы смысл. Определить роль качества в жизни этой продукции. А уж потом выбрать, о чем говорить дальше: о каких именно характеристиках качества и методах их обеспечения.
Поэтому обсуждение начиналось с вопросов взаимосвязи рыночных факторов и качества потребительских коммерческих прикладных пакетов программ общего делового назначения.
Исходные положения
Для обсуждения был предложен пакет исходных определений и список из 12 вопросов для оценки разных сторон качества.
Под потребительским комплексом имелся в виду (близко к ГОСТ Р ИСО 9127-94) не уникальный, предназначенный для продажи более или менее широким тиражом, возможно — частично заказной (то есть допускающий в своем составе, кроме типовых, и уникальные заказные модули) пакет прикладных программ.
Обсуждаемые ППК трактовались как компоненты прикладного ПО для ИУС организационно-хозяйственного типа.
Было предложено говорить о качестве, отталкиваясь от его роли в развитии ППК некоторого «среднего» размера и некоего «среднего» качества. ППК с явно низкими характеристиками не рассматривались.
Под ППК «среднего» размера имелись в виду программные комплексы, находящиеся в диапазоне между такими малыми, как «Финансы без проблем» или «1С: Бухгалтерия» (по крайней мере, в их начальных версиях), и крупными, как SAP R/3, Baan или SYMIX (в их сегодняшнем состоянии).
«Космонавты» vs. «Бухгалтеры»
Профессиональный опыт участников был настолько различен, что вначале приводил к противоположным оценкам ряда исходных положений. Однако после бурной полемики предмет обсуждения был не только сохранен, но и уточнен. Это — один из важных результатов встречи.
Уточнение области назначения ППК
Слова «ИУС организационно-хозяйственного типа» воспринимались как недостаточно конкретные.
Евгений Зиндер (ЕЗ) связал этот класс ППК с приложениями для таких систем, как АСУП, ОАСУ или для их подсистем, в отличие от, например, АСУТП или систем управления аэрокосмического назначения. Понятно, что размытость границ существует, но основанием для выделения таких ППК служит большая рыночная тиражируемость продуктов, отсутствие единственного заказчика и относительно нестрогие требования к такому показателю качества, как коэффициент готовности системы. По этим причинам развитые АБС — автоматизированные банковские системы — тоже было предложено вывести за границы первой встречи клуба по теме качества.
Это ограничение показалось очень спорным.
|
Однако обсуждение только таких ППК уводило в сторону от массовых ситуаций, связанных с реальной конкуренцией, с реальным эффектом от затрат по статьям обеспечения тех или иных характеристик качества. (Хотя сразу обращало к интересным техническим вопросам типа «как делать», «чем делать», «какие нормативы и стандарты нужны» и т. п.)
ЕЗ: Практика в области продукции массового потребления отличается от правил создания уникальных систем. Для коммерческих тиражных продуктов ситуация менее ясная. Ведь от фирм-разработчиков мы слышим: «У нас все замечательно, покупайте. А мы вас не бросим, ведь вы же будете у нас на техподдержке!» Потом пользователь, заплативший еще и за эту поддержку, обнаруживает в продукте кучу ошибок, на которые и сообщений-то разумных нет. Он звонит по горячей линии, и в лучшем случае слышит: «Хорошо, мы приняли этот запрос на исправление вашей(!) ошибки в следующей версии». Но когда пользователь получит это исправление?
Говорилось и об отличиях ППК для АСУТП или жестко связанных с АСУТП. Отказ в каком-то звене программного комплекса «фронт-офис — бэк-офис» приводит к немедленному отказу в процессе оказания услуги клиенту банка (в отличие от отказа в подсистеме внутренней бухгалтерии большинства предприятий, даже и самого банка). Поэтому требования и контроль качества в таких областях изначально более жесткие.
В результате ППК для систем с требуемой готовностью хотя бы 0,99 мы вывели за пределы первого обсуждения: да, здесь есть важные проблемы, но ответы хотя бы в принципе известны и нового не так много (скорее — много забытого).
Примерами ППК, выбранных в качестве «полигона», назывались бухгалтерские и финансовые комплексы, управление складами и запасами, управление логистикой и продажами, а также правовые и обучающие системы, и список этот открыт.
Уточнение «среднего» размера и качества
Столь же остро обсуждались вопросы размера и уровня качества ППК. Звучали реплики: «Если для вас средний размер ППК — 50 тыс. операторов, то для меня — миллион!» Все же введение такой модели ППК оказалось возможно и оправданно.
|
Далее уточнялось понятие «среднего» качества. Для этого Д. Соколов обратился к истории развития продуктов класса «бизнес-софт» и происходящим сегодня процессам. Толчком послужила реплика В. Липаева.
ВЛ: Большая часть таких бухгалтерских программ сделана самодеятельными художниками. Сначала они думали, что все просто, затем их били и били потребители, и их программы естественным путем умирали. А заменили их те немногие программы, которые были сделаны другими людьми и уже профессиональным образом.
(Примечание: термином «художники» В. Липаев обозначил таких программистов, которые не хотят и не могут работать в рамках стандартов, четко регламентирующих сквозную технологию разработки ППК со всеми требованиями, отчетными формами и прочими «заморочками», придуманными для обеспечения качества.)
Однако Д. Соколов нарисовал иную картину. Он сказал, что большинство появившихся семь-восемь лет назад ППК этого класса не исчезло, а либо работает в узкой нише при поддержке разработчиков, либо получило более явное развитие в виде нескольких версий с существенным увеличением тиража. В обоих случаях качество все это время совершенствовалось. Одновременно на рынок в уже сложившиеся сегменты продолжают выходить новые фирмы и новые продукты старых фирм. Это важно, так как новые продукты нельзя вывести на рынок с качеством, которое было бы ниже некоторого порога: рынок не воспримет!
Отсюда следовало, что «среднее» качество можно рассматривать как меняющийся во времени минимальный уровень качества продукта, которым этот продукт должен обладать для того, чтобы не быть отвергнутым рынком.
Если не качество, то что?!
Уже при подготовке встречи участники говорили о том, что сейчас роль качества отнюдь не первична.
Маркетинг
ДС: К сожалению, сегодня успех определяется маркетингом в его узком и широком смысле. Могу привести несколько примеров. Хотя бы компанию «АйТи», в которой поставлено на поток создание информационных материалов для различных изданий. Очень важно и удачное создание сети распространения продукта. Например то, как Борис Нуралиев в «1С» одним из первых сделал ставку на дешевый продукт и создание широкой сбытовой сети.
|
Говорили и о том, как неумолимый рынок едва ли не кровавым плугом прошелся по судьбам многих квалифицированных разработчиков. Многие из тех, кто ставил на первое место добротное качество своей разработки, проигрывали, а их продукты исчезали с рынка.
Порог вхождения повышается
ДС: Теперь как бы де-факто задан некий порог вхождения на рынок. Система не имеет права сразу после инсталляции повиснуть, хотя раньше и это проходило. Она должна корректно отрабатывать некий набор алгоритмов. Стандарт выхода на рынок повышается, и, самое главное, работают совершенно понятные рыночные механизмы. В результате сейчас, чтобы что-то небольшое сделать и вывести на рынок, требуется порядка 150-200 тыс. долл., и надо еще иметь коллектив этих самых «художников», которые изначально почти бесплатно заложат какие-то основы, да, действительно, как тут говорят, «изюминки», а уж потом их доработают «профессионалы». «Художники» также угадают новую рыночную нишу — новые потребительские свойства, которых рынок сейчас ждет.
Промежуточные выводы
Коробки и некоробки
ЕЗ: Здесь звучали слова, что все это относится к «коробочным» ППК. Однако учтем следующее.
- Выводы о месте и роли маркетинга и качества вполне годятся и для так называемых «некоробочных» продуктов.
- Надо лучше разобраться с тем, что такое «некоробочный», но коммерческий потребительский ППК. Ведь многие используют слово «коробочный» как ругательство. Вспомним: пренебрежительное отношение к «коробкам» пришло к нам извне, но там оно касалось такой деятельности, как box moving. То есть примитивной торговли продуктами без нужной поддержки, без ответственности за возможные неполадки при эксплуатации.
Конечно, простота программного пакета, богатство его функциональных возможностей, возможности адаптации — это факторы объективно противодействующие, ограничивающие друг друга. И чем сложней продукт, тем больше объем документации, тем выше требования к квалификации тех, кто будет ставить пакет и делать на его основе ИУС. Но если продукт «некоробочный» только потому, что его нельзя использовать даже в каких-то типовых вариантах без получения большого комплекса дополнительных услуг, это — показатель низкого качества продукта, а не его достоинство.
Смысл уточнений
Отметим: точная числовая оценка размера ППК была не очень существенна. Важно было понимание того, что не только наибольший, но просто определяющий успех сегодня приносит реклама и прочий «промоушн», хорошая сбытовая сеть и своевременный выбор своего потребителя, включая поиск новых секторов рынка. А реальная роль качества в настоящий момент — вторична. Тем не менее, поскольку требования к «среднему» качеству растут (см. выше про «порог вхождения»), качество как конкурентный фактор реально существует. Другое дело — как этот фактор использовать.
Качество как маркетинговый прием
ДС: Качество выходит на первое место в тот момент, когда оно превращается в маркетинговое свойство. К сожалению, часто эта идея извращается.
Участники вспомнили объявления некоторых фирм о введении у себя программ качества. Во многих случаях казалось, что такие объявления — всего лишь декларация, за которой ничего не стоит, и которая никак или почти никак не отражается на качестве продукта. Все же фирмы, поднимающие такой маркетинговый флаг, просто вынуждены — чтобы не дискредитировать себя — реально что-то делать для повышения качества своего продукта.
Место и доля качества
Борис Вольфман (БВ): С одной стороны, под словами Дмитрия я подпишусь на все 300%. Другое дело, что без этого самого качества нельзя (см. врезку — Прим. ред.). Если говорить о доле, приходящейся на качество, можно предложить такую форму вопроса: как тратить получаемые деньги? Я бы ответил: 80% — на маркетинг, 20% — на качество.
Конечно, эти цифры понимались как условные: будете вы тратить 20% на прирост качества или 70% — это вопрос текущей политики. Но если у вас 10% на маркетинг — вы прогорите. Если же у вас постоянно только 10% на обеспечение качества и вы постоянно упираете только на маркетинг — вы тоже в конце концов прогорите.
О роли «художника» в истории разработки
Отталкиваясь от уже отмеченной роли «программистов-художников», Б. Вольфман выделил важную тенденцию в распределении труда между программистами разных стилей и фирмами разной устремленности.
БВ: Как правило, для того чтобы продукт вышел на рынок, сначала должны поработать один-два «художника-энтузиаста». Сейчас на рынке в основной массе работают «ремесленники», способные качественно сделать 250 бухгалтерских формул и свести дебет с кредитом, учесть все правовые нормы, сделать, чтобы меню хорошо работало — это им не сложно. В этом смысле западное производство программных продуктов ничем не отличается от нашего. Все эти Клипперы, Фоксы и т. д. были произведены энтузиастами-одиночками, подхвачены более крупными фирмами, на них навешана качественная документация, и, главное, привлечен хороший маркетинг.
А. Цицин отметил, что зарубежный опыт показывает существование небольших компаний, которые постоянно ищут пустующие рыночные ниши, потом для этих ниш делают какой-то продукт, потом продают его крупным корпорациям, причем в работе параллельно находится 15-20 разработок. В этом режиме в большей степени работают именно «художники».
Обсуждалось наличие подобной ситуации у нас, и было отмечено, что признаки такой потребности и даже зачатки такой организации труда уже есть. Примером служат некоторые конкурсы «личных» разработок, устраиваемые фирмами, которые наиболее продвинуты в маркетинговом осмыслении и планировании дела.
Как тратить деньги на качество
Скромные возможности
ЕЗ: Я безусловно вынужден упрощать, и все же: мы заключили, что на одном «голом» маркетинге нельзя держаться, что эти условные 20% или около того все-таки надо тратить на качество. Но раз уж так мало мы можем тратить на качество, то нужно выделять наименее дорогостоящие и наиболее эффективные по результату меры по обеспечению качества и говорить именно о них.
Приоритеты качества
Некоторому анализу и оценке подверглись сами характеристики качества (инструменты были отодвинуты «на потом»). Прозвучало два типа оценок:
- улучшать в ППК надо то, что сейчас «просело» сильнее всего (точка зрения разработчика, находящегося в реальной динамике развития продукта);
- есть наиболее приоритетные характеристики качества (точка зрения консультанта, общающегося с большим потоком потребителей).
БВ: Сначала нужно реализовать функции, которые были в спецификации или в техническом задании, а уж дальше устранять узкие места. Если ты не проходишь по времени — борись со временем. Если время приемлемо, то оставь эту сторону качества в покое! Если у тебя интерфейс пользователя недостаточно понятный — то есть если пользователь в нем ничего не понимает — улучши его. Если у тебя нет документации — сделай документацию. Расшивай узкие места, только так можно сделать нормальную систему. А на вопрос, какой показатель — время, интуитивный интерфейс или документация — сегодня важнее, однозначного ответа, по-моему, нет.
ДС: Для себя я все-таки определил, что имеет наибольшее значение сегодня. Потребители-то мучают. Я выделил четыре показателя.
- Первое — это количество ошибок. Тестировать надо! Альфа-тестирование, бета-тестирование... «Наработка на отказ», можно и так назвать.
- Второе — «защита от дурака» в самом широком смысле. Это к вопросу об «интуитивно понятных» интерфейсах, недокументированных функциях, к вопросу о нестандартных реакциях на те или иные действия, даже к вопросу о непротиворечивости внутренней, логической модели базы данных.
- Третье — это адаптируемость. Те продукты, о которых мы сегодня говорим, к сожалению, должны очень быстро реагировать на изменения законодательной базы, нормативной базы — то есть внешней среды. Саму программу менять быстро не удается, поэтому лучше, чтобы в ней были заложены механизмы, которые позволяли бы быстро ее приспосабливать к изменившимся внешним условиям.
- И четвертое — это корректность документации. Не качество «вообще», а корректность. Чем грешит в настоящий момент масса книжечек, брошюрочек и т. д. и т. п.? Тем, что они просто некорректно написаны. Мало того, что не все детали описаны, часто отсутствуют целые смысловые блоки. Человек не обязан понимать, что думал разработчик, когда он что-то там свое делал. Система должна быть описана вся: от общей схемы, от взаимосвязей ее компонентов. К сожалению, часто сегодня документация находится на уровне описания кнопок. Причем с перекосами типа: «Кнопка F10 — это ?хелп?». Почему не F1? Хорошо, может быть и F1. Тебе дается механизм, который позволяет самостоятельно назначать кнопки. И на эту тему пишут 20 страниц. Кому это важно?! От этого существенные моменты работы системы не меняются.
Поэтому для разработчиков у меня такие рекомендации: тестировать. А также — разрабатывать, а не писать документацию. А для потребителей — не бояться ставить под сомнение слова разработчика.
ЕЗ: Обратите внимание: сейчас, когда мы сформулировали роль и приоритеты в области качества ППК, мы наконец-то можем конкретно говорить об узкопрофессиональных аспектах получения качественного программного изделия. Теперь можно будет ограничивать разговор — то ли о стандартах, то ли о других инструментах — именно теми условиями и приоритетами, которые мы определили.
Во время этой встречи обсуждались также:
- региональные особенности успеха программных продуктов;
- наличие и роль стандартов, и как к ним относиться;
- сертификация программ, ее плюсы и минусы.
Участники решили, что конкретные аспекты темы качества будут обсуждаться на следующих заседаниях Клуба. Ваше мнение для нас также существенно. Пишите участникам заседания и в рубрику «Директору» по адресу: cwr@osp.ru.