В этой статье я решил описать современные тренды по технологии обеспечения надежности программных продуктов принятых де-факто крупными вендорами как, например, Microsoft. Многие из читателей знают, что, я принимал участие в разработке MS Project 2007/2010/2013, как контролер качества, проверяющий как продукты работают на «сценариях из реального мира». На мой взгляд десктоп MS Project вполне соответствует очень высокой планке качества характерного для семейства продектов Microsoft Office, но MS Project Server хоть и стал надежней, но все равно, вероятно, по числу «глюков» в семействе серверов MS SharePoint остается самым сложным в обслуживании. Как показала практика, ни мне, ни ряду разработчиков MS Project, которые даже уже не работают в Microsoft, не удалось «уйти от ответственности». Нас всех конечно помнят и когда какие-то ошибки блокируют внедрения припоминают. 🙂 Но думаю многие клиенты задают себе вопрос: каким образом часть клиентов Microsoft делает вполне рабочие внедрения даже на «закрытых бетах» продукта, а другие клиенты не могут внедрить релиз? Проблема заключается в том, что для современных технически сложных продуктов таких, как MS Project Server, обеспечение стабильной работы продукта — задача клиента, а не поставщика.. Хотя я эмоционально также устал от многих приключений с MS Project Server, но надо признать, что в 80-90% случаев зря «катят бочку на Microsoft». Все в ваших руках на 90%, а не в руках Microsoft, уважаемые пользователи.
Давайте разберемся почему ошибки в ПО зачастую не являются большей проблемой, чем отсутствие функционала. И почему компании Microsoft и Oracle не ставят себе даже теоретической цели исправить все ошибки в своих продуктах? Что такое «Тропа Инков» через минированное багами поле? Почему на телефонах поддержки у вендоров сидят не инженеры, а психиатры? Думаю этот материал будет полезен многим разработчикам и пользователям ПО, так как представляет анализ очень непростой проблемы надежности сложного современного ПО и дает обзор очень многих полезных практик для разработки ПО разрушает ряд мифов. Для начала надо понять, что проблема надежности ПО очень комплексная и гораздо шире просто «исправления багов».
Просите продавцов поставщика не танцевать свой ритуальный танец вокруг общих слов, а продемострировать сценарий работы продукта, т.к. он именно по нему и тестировался
Опытный внедренец MS Project Server на предложение стажера использовать продукт не так как описано в документации Microsoft
Нетиповой пример эксплуатации может сразу не получится, но всегда приводится в порядок с помощью поддержки вендора
Обычно пользователи обращаются в поддержку по проблемам, которые создали сами, но не могут это понять
Если вы перейдете от асбстрактых заявлений типа «программа не работает» к описанием проблем в терминах «шагов воспроизведения», то ускорение работы поддержки поставщика вас просто потрясет
Не нужно пытаться внедрять сразу все модули сложного программного продукта. Лучше внедрять по частям и согласовать этот план с планом поддержки поставщика