MS Project Download
Имя: Пароль:
Забыли пароль?

Статьи

Методика управления проектами [86]

Методические пособия и книги [25]

Готовые отраслевые решения [60]

Обзоры программ для управления проектами [62]

События в мире Управлениия Проектами [126]

Сравнение разных программ для управления проектами [26]

Обучение и сертификация [50]

Управление рисками [4]

Опыт внедрения [36]

Разрешение проблем MS Project и др. системах [4]

Скачать Microsoft Project [3]

Администрирование MS Project Server [36]

Разработка для Microsoft Project [5]



356 пользователей нашли статью интересной, если согласны нажмите тут 
10.01.2014

Обеспечение надежности программных продуктов на примере MS Project

 

В этой статье я решил описать современные тренды по технологии обеспечения надежности программных продуктов принятых де-факто крупными вендорами как, например, 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 не ставят себе даже теоретической цели исправить все ошибки в своих продуктах? Что такое "Тропа Инков" через минированное багами поле? Почему на телефонах поддержки у вендоров сидят не инженеры, а психиатры? Думаю этот материал будет полезен многим разработчикам и пользователям ПО, так как представляет анализ очень непростой проблемы надежности сложного современного ПО и дает обзор очень многих полезных практик для разработки ПО разрушает ряд мифов. Для начала надо понять, что проблема надежности ПО очень комплексная и гораздо шире просто "исправления багов".

Понятие "блокирующией проблемы" (Blocking Issue) или почему ошибки программистов часто менее опасны чем создание Запорожцев вместо Ferrari

Начнем с очень важного понятия "Блокирующей проблемы". Обычно при обращении в службу технической поддержки, заказчики очень часто говорят об "ошибках", но на деле только около 30% обращений является настоящими ошибками, примерно 30% составляют ошибки самих пользователей, просто программа не имеет для какой-то ошибке "человеческого" сообщения и выдает предупреждение на системном языке,еще 30% представляют собой заявки на изменения функциональности системы, т.к. текущая реализация продукта блокирует пользователя своим поведением. Пользователи обычно понимают, что немного лукавят рассуждая об "ошибках", подавая заявку на доработку под видом "ошибки". Проблема системных диагностических сообщений на деле не очень сложная, т.к. специалист технической поддержки обычно может пользователю "перевести" с системного языка на человеческий в чем суть неверных действий по настройке. Далеко не все настоящие ошибки программистов играют важное значение для пользователей, обычно пользователь использует только около 30% функций любой программы и поэтому ошибки в остальных 70% функциональности его не волнуют, т.к. это проблемы в другой реальности и у других людей.


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

Наиболее существенной проблемой, затрудняющей внедрение системы являются вовсе не ошибки в ПО, а совсем другие причины. Я тестировал Microsoft Project в составе команды его разработки в трех последних версиях (MS Project 2007/2010/2013). С точки зрения стандартов качества Microsoft на деле существует не ошибка, а другое намного более важное понятие - "Блокирующая Проблема" (Bloking Issue). Именно такие проблемы являются реальными ПРОБЛЕМАМИ. Что такое блокирующая проблема? Как я расскажу ниже, любой продукт для бизнес-применения имеет на деле зашитый в себе бизнес-процесс, как некий сценарий последовательных действий. Только некомпетентные "методологи" думают, что тот же Microsoft Project или Oracle Primavera - это россыпь "айтишных" функций . Нет, функции подчинены тому, чтобы сработал некоторый встроенный в продукт бизнес-процесс. Безусловно какая-то ошибка программиста может заблокировать саму возможность такого процесса. Таких ошибок в продукте быть как раз не должно - это как раз ошибки из разряда Blocking Issue.Но очень важный момент, о котором пользователи догадываются только спустя какое-то время, заключается в полном отсутствии какой-то функции, необходимой для реализации процесса, и это такая же блокирующая проблема, как и ошибка программиста, только гораздо серьезнее. Поэтому при тестировании MS Project я очень часто добивался совсем не исправления ошибок, а именно добавления функций, чтобы разблокировать бизнес-сценарии. Вот пример функции, которую я добавил в MS Project, чтобы разблокировать работу команды ресурсов для сценария строительного проекта. 

Если ошибку в целом программист с адекватной технической поддержкой обычно может достаточно быстро исправить, то вставка какой-то новой функции часто технологически невозможна. Поэтому когда мы говорим о качестве программного продукта, это совсем не отсутствие ошибок. Даже на Форуме этого сайта, видно, что в MS Project имеются десятки тысяч неисправленных мелких ошибок программистов. Но тем не менее, MS Project очень качественный продукт, если говорить о десктопе так вообще почти эталон качества по надежности в отрасли, т.к. хитрость не в том, что в нем несколько десятков тысяч ошибок,  а в том что MS Project содержит 0% блокирующих проблем не только как полное отсутствие ошибок на типовом сценарии бизнес-процесса, но и как наличие всех функций, чтобы его сделать.

У пользователей продуктов и даже многих IT-специалистов есть традиционное заблуждение, что эволюционно простой продукт можно развить до сложного. Иными словами, недостаток функционала как "блокирущие проблемы" можно снимать постепенным развитием. Хотя даже простейшие аналогии показывают, что это технологически невозможно: нельзя модернизациями Запорожца получить Феррари. Запорожец и Феррари хотя и автомобили, но технологически выполнены по разному, поэтому превращая Запорожец в Феррари вы должны будете выкинуть на свалку Запорожец. Фактически "эволюция" это предложение выкидывать Запорожец по частям, хотя сразу понятно, что проще его отвести на свалку и купить Феррари, раз цель Феррари. Но Феррари сложнее разработать, а добиться испытаниями его надежности еще сложнее.

С программными продуктами тоже самое. Разработчик продукта должен решить, что он хочет поставить на рынок: Запорожец или Феррари. Это решение можно принять очень часто всего один раз. И ответственность за такое решение очень велика. Ведь если разработчик Феррари еще выпустит доступный по цене Ferrari Light, то он просто уничтожит производителя Запорожца, т.к. кроме как ценой ему конкурировать нечем. В случае MS Project как раз и выполняет роль Ferrari Light относительно MS Project Server и там где такое "мини Феррари" проехал остаются только дымящиеся обломки конкурентов. Даже полностью бесплатный OpenProj (ProjectLibre) на деле не в состоянии конкурировать с Microsoft.

Надо понимать, что появление Ferrari Light в плане надежности решения будет для пользователей Запорожца катастрофой. Ведь как я напишу ниже надежность продукта больше чем на половину обеспечивается адекватной и профессиональной системой технической поддержки продукта. Это постоянные издержки производителя программного продукта. Если у него нет продаж, то он не сможет содержать техническую поддержку. Одного компакт диска с продуктом для надежной работы решения недостаточно. Если вспомнить OpenProj, то коллега из Франции в какой-то момент понял, что не может никак монетизировать продукт в конкуренции с Microsoft и просто взял... и закрыл поддержку. Как в том анекдоте "Экипаж прощается с вами и желает вам приятного полета". Часто пользователи выбирая те же продукты не учитывают, что надежность - это баланс очень многих факторов. "Дебилизация" программного продукта может иллюзорно повысить его надежность, но потом функциональная недостаточность возвращается бумерангами блокирущих проблем или даже вообще отключением технической поддержки от пользователей. 

Самые важные моменты в технически сложных продуктах для обеспечения его гарантированной стабилизации таковы:

  • Прекращение модификации архитектуры продукта. Поставщик должен четко заявить, что не будет модифицировать архитектуру решения в этой версии. Стабилизация любого продукта невозможна, когда продолжается наращивание функциональности и изменение технологии самого продукта. Пример: MS Project Server 2007 на самом деле был недоделанной архитектурой MS Project Server 2010, поэтому когда в релизе продолжаются архитектурные изменения, конечно все сыпится. От  "точки замерзания архитектуры" идет обратный отсчет по времени стабилизации до уровня очень высокой надежности. Если поставщик заявляет о планируемом изменении архитектуры, то разработка еще не завершена и пока продукта нет. Точка "замерзания архитектуры" должна быть четко объявлена -  поставщик должен сказать, что в это версию продукта он ничего добавлять функционально больше не будет.
  • Проверка не получился ли Запорожец. Как я уже отмечал, всегда надо сравнивать новинки понимая, что еще хуже выпустить примитивное решение, которое не выдержит конкуренции. Не должно быть иллюзий - вы разделяете судьбу поставщика, если он проиграет конкуренцию. Наиболее серьезное последствие как я уже сказал - полное прекращение поддержки продукта. Это цена ошибки примитивизма.
  • "Тропы инков" и "Дорожные карты" по стабилизации. Об этом ниже. От "точки замерзания архитектуры" сразу же обычно на 100% работают базовые сценарии эксплуатации, если  тестирование выполнялось правильно. Про то как нетиповые сценарии стабилизируются ниже, но важно понимать, что их обратный отсчет идет также от "точки замерзания архитекторы". 

 

Изучение тестовых кейсов по видео на предмет соответствия широты охвата и акцепт оферты стабилизированного поставщиком бизнес-процесса

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

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

А вот теперь самое интересное, что имеет прямое отношение к функциональности и к надежности. Надо понять какие сценарии эксплуатации заложены в продукт. Это очень важно, так как, если вы поймете сценарии поставщика, то продукт будет очень надежно работать в вашем окружении, а также вы получите как бонус готовые бизнес-процессы. В чем тут хитрость. На деле только новичок разрабатывает программные продукты для бизнеса как набор неких функций. В реальности большинство серьезных поставщиков в особенности оставщиков, в особенности отраслевых решений, не разрабатывают функции, они сначала разрабатывают сценарии бизнес-процессов, а потом добавляют в продукт функции, чтобы это бизнес-процессы работали. Существенный момент, что продукт на самом деле будет тестироваться поставщиком именно по этим сценариям и если вы планируете использовать его как-то кардинально иначе вам гарантированны большие приключения. Но большой бонус тут в том, что хороший продукт не россыпь функций, а именно зашитый в продукт бизнес-процесс. В большинстве случае поставщик отраслевого решения автоматизирует "лучшую практику", т.е. наиболее типовой и удачный бизнес-процесс для отрасли. Как правило заказчик почти всегда имеет процесс менее совершенный, поэтому поставщик цивилизует заказчика в управлении. Но нужно четко понимать, что возможно ваше представление о том как должен работать некий бизнес-процесс кардинально отличается от точки зрения поставщика, попытка кардинально перенастроить продукт под то для чего он не разрабатывался и не тестировался обычно приводит к огромному количеству обращений в техническую поддержку. 


Просите продавцов поставщика не танцевать свой ритуальный танец вокруг общих слов, а продемострировать сценарий работы продукта, т.к. он именно по нему и тестировался

Поэтому вам очень важно разобраться, а вы вообще согласны с таким сценарием автоматизации процесса поставщика или нет? Как это узнать? Демоверсия неверное решение на данном шаге, т.к. чтобы понять по демоверсии какой сценарий заложен в продукт, вы уже должны уметь продуктом пользоваться. Поэтому есть два варианта: демонстрация продавцом поставщика или же просмотр записанной видеодемонстрации как решение работает. Существенный момент - вы анализируете сценарий, а не просто область охвата продукта. Если область охвата продукта отвечает на вопрос "что" собрался сделать поставщик, то сценарий отвечает на вопрос "как".  Поэтому если продавец вам вместо демострации сценария пытается перейти на общие рассуждения, надо его сразу обрывать и требовать показать только продукт и по шагам процесса.

И так, вы посмотрели каковы предлагаемые поставщиком бизнес-процесс. Теперь надо принять решение принимаете ли вы такую "оферту" построить свое управление по такому процессу или нет? Если это идет совсем в разрез с вами представлениями об управлении, то надо просто искать другой продукт. Правда если вы вдруг заметите, что все поставщики на рынке делают что-то похоже, то скорее вопрос в том, что проблема не у них, а у вас, т.к. вы пытаетесь "изобретать велосипед" и не работать по надежным бизнес-процессам как другие. Приключения для "изобретателей велосипедов" всегда гарантированы и не только с надежностью средств автоматизации. Если вы видите, что процесс в целом похож на нужный, но хотелось бы некоторые вещи сделать иначе, то нужно оценить теперь сценарии настройки продукта - теперь берем демоверсию.

"Тропа Инков": Прогон тестовых кейсов на демоверсии и оценка качества документации 

Прежде всего вы должны определить завершено ли тестирование новой версии продукта вообще. Это не означает, что в продукте нет ошибок. Любой программный продукт имеет множество ошибок, но они могут совершенно не беспокоить пользователей и даже быть им неизвестны, т.к. не лежат на их пути эксплуатации. Завершение тестирования продукта - это 100% отработка предложенных поставщиком примеров реализации бизнес-процессов.

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

Первое с чего нужно начать, это открыть документацию на продукт и найти там сквозные демопримеры. Если продукт тестировался, то они обязательно там будут, т.к. на этапе тестирования эти примеры составляются и прогоняются через продукт. Поскольку они важны также для изучения продукта, то их обычно переносят в документацию. Если вы не видите демонстрационных учебных примеров в документации - это очень тревожный знак. Скорее всего тогда продукт тестировался как говорят в Microsoft методом "Обезьяны с гранатой" (Monkey Testing). Проще говоря студент-тестер нажимал куда попало в продукте записывая какие попало сообщения об ошибках, о стабилизации продукта под некий сценарий бизнес-процесса речи даже не идет. Поэтому если демопримеров в документации нет, можно просто прекратить рассматривать продукт - приключения с технической поддержкой гарантированны. Отметим, что известные приключения вокруг "глюков" MS Project Server 2007 во многом были связаны с большим количеством системных тестов методом Monkey Testing, начиная с MS Project Server 2010 акцент тестирования сместился именно в сценарный по бизнес-процессам и повышение качества заметили и клиенты и сам Microsoft по опросам.

И так, вы все же нашли демонстрационные примеры в документации, тогда можно идти дальше. Особенно хорошо, если есть еще записанный видеопример. Вы скачиваете демоверсию и повторяете ровно так как написано в документаци без каких-то отклонений данный пример. Он должен отработать на 100%. Если это не так, то стоит обратится к поставщику, и лучше через чат поддержки спросив все ли вы правильно делали, об этом ниже. Возможно что-то вводили не так, но если все так и не работает, то покупку стоит отложить до того как будут проходить не на 99%, а на 100% описанные в документации сквозные примеры. Американцы называют такой подход Acceptance Tests, т.е. приемочные тесты. Нормальный поставщик вам должен выдать набор таких тестов сам.


Пользователь, который знает  бизнес-процессы "Тропы Инков" в MS Project Server на фоне пользователей, которые тыкают куда попало

Если все получилось, то теперь вы должны понять очень важный момент. Вы овладели сокровенным знанием о продукте - "Тропа Инков через минное поле". Тут есть секрет почему у многих тот же MS Project Server ужасно глючит, а у других работает без проблем. Просто вторые знают "Тропу Инков" через продукт, т.к. 100% гарантированно работающую последовательность действий. Вокруг может быть хоть миллиард ошибок программистов, но если "Тропа Инков" по шагам ведет вас к нужной цели, то совершенно безразлично для вас существуют они или нет вообще. Это очень и очень важно. В любом отраслевом решении обязательно есть такая "Тропа Инков", если вы ее знаете, то проблем практически никаких, а если не знаете и начинаете "метаться" нажимая что попало в продукте, то проблемы гарантированны.

Опытный внедренец MS Project Server на предложение стажера использовать продукт не так как описано в документации Microsoft

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

Разработка своего тестового примера как развитие базовых сценариев, оценка гибкости настроек программы

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

Хорошая идея открыть Microsoft Word  и сначала набросать там шаги своего примера и возможно некоторые данные. Далее по "принципу подобия" вводите свой тестовый пример в продукт. Если у вас все получилось, то в можно констатировать, что продукт полностью пригоден для работы. Но если вы увидите, что продукт обладает огромными возможностями настроек, то все может оказать сложнее.

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

Вполне вероятно вы увидите из продукта "ошибки" с непонятными объяснениями, но не факт, что это ошибки программистов. Дело в том, что продукт имеет очень богатые средства настройки, то даже теоретически невозможно охватить все варианты неправильных настроек пользователей с выводом "человеческих" диагностических сообщений типа того, что ноль рабочих ну ни как не справятся с этой работой по задаче и т.п.  Очень многие пользователи тут делают неверные заключения об общем качестве продукта, на деле нужна консультация по настройке, чтобы понять в чем проблема. В принципе даже лучше если у вас выскочит 1-2 непонятных проблемы, т.к. теперь вы можете оценить качество поддержки продукта. Даже если вы не нашли проблем сейчас, это не значит что их нет, в той или иной степени но с поддержкой продукта придется столкнуться и тут важно понять насколько адекватно она работает. В принципе без разницы есть проблема или нет, если поддержка может быстро ее решить.

Поэтому запишите вопросы и посмотрите как обратиться в поддержку.

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

Поддержка - это очень важно. Априори не бывает программных продуктов без ошибок. Надежность продукта на деле базируется на хорошо продуманных "Тропах Инков" и на проводниках по минному поле вне этих троп. Эти проводники и есть сотрудники технической поддержки. Насчет "Тропы Инков" я уже написал, вы ее в своем продукте должны просто выучить. Если же вы сошли с "Тропы Инков" тут важно понимать как правильно пользоваться поддержкой. Обычно тут у пользователей много есть заблуждений и ложных представлений. 

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

Начнем с того, что вы должны сразу оценить в адеквате ли находится техническая поддержка поставщика. Традиционно пользователь обнаружив проблему эмоционален и хочет поделится своими эмоциями. Помните, на любого профессионального инженера технической поддержки бесполезно кричать, как-то передавать эмоции или угрожать. Желающих убить любого специалиста поддержки так много, что он может только посоветовать занять для этого очередь. Но тут есть "военная хитрость" о которой надо знать всем пользователям. Поскольку человек звонит в поддержку, чтобы "выговориться и получить сочувствие" его там ждет скорее психиатр, а не инженер. У всех вендоров включая Microsoft это так называемые "регистраторы проблем". В случае Microsoft Rus вы даже по телефону поддержки попадете даже не в Microsoft, а ... в call-center поддержки Beeline на аутсорсинге. Девушка на телефоне выслушает не только ваши проблемы с ПО, но даже ваши проблемы с тещей или свекровью. Но реальное действие ее - это "зарегистрировать" проблему и передать инженеру поддержки, который трубу по этому телефону и не собирается брать. Инженер изолирован на деле от попытке с ним вести пустые разговоры. Это вы должны понимать, поэтому телефон поддержки можно пропустить сразу - вам нужен инженер, а не Доктор Фрейд.


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

Хотя большинство пользователей поддержки ищут телефон куда позвонить или форум где им помогут другие пользователи на деле нужно искать совсем другое - Чат технической поддержки или переписку по e-mail. Очень удобно если есть чат поддержки в социальной сети типа Facebook, тогда вы можете получать уведомления об ответах находясь в ней, но главное не это - вы можете увидеть по социального профилю, что это профессионал, а не мальчик-региистратор проблем. Как я уже отмечал, профессионалы не берут трубку телефона, но обычно они доступны в чатах поддержки или по электронной почте. Из крупных вендоров чаты поддержки используют Google или Skype, некоторые правда еще отстали от жизни и работаю только через электронную почту.  Теперь как правильно воспользоваться проводником через минное поле, раз вы его нашли и он вышел на контакт.

Если вы перейдете от асбстрактых заявлений типа "программа не работает" к описанием проблем в терминах "шагов воспроизведения", то ускорение работы поддержки поставщика вас просто потрясет

Если вы не очень поняли как работает программа откройте сообщение в чате и кратко сформулируйте проблему. Если программа выдала какую-то ошибку , то сразу скопируйте ее текст. Если проблема типовая, то вполне вероятно вам буквально через пару минут ответит профессиональный инженер с объяснением как правильно сделать и часто даст ссылку на документацию или приложит экран программы с правильной настройкой. Оцените почему профессионалы не берут трубки телефона, так за 5-10 минут они могут решать местами непростые проблемы, т.е. за 1 час который бы вы у него украли пустыми разговорами, он смог бы помочь 10 пользователям.  Кроме этого, как вы заметили нужно приложить сообщения программы, по телефону это не сделать. Инженер обычно не работает голосом, т.к. ему нужны не сотрясения воздуха, а экраны программ, настройки и сообщения для того чтобы выполнить свою работу.

Если проблема не решилась, то инженер поддержки начнет оформлять "инцидент". Очень важно пользователю понять, что сейчас происходит с технологической точки зрения обеспечения надежности. Для того, чтобы исправить любую проблему в программном продукте нужно ее воспроизвести, т.е. чтобы не только вы, но и другие могли создать такую же проблему. Если проблема воспроизводится, то можете считать что она решена, вопрос только срока решения и как его узнать ниже. Что от вас будут добиваться:

  • Какие шаги вы делали в программе. Важна не сама проблема, а то каким шагами вы ее создаете. Если вы объяснили по шагам как это делается, то на 90% проблема решена. На деле примерно 80% все проблем в программных продуктах устраняются примерно в течении суток, если продукт имеет правильную архитектуру. Основная проблема - диагностика, т.е. понять как это вышло. 
  • Иногда какие-то шаги описать сложно. Проще снять экран с настройками программы.  Для этого есть во истину замечальный бесплатный продукт  Gyazo. Вы можете с его помощью за секунду сделать копию экрана и показать инженеру поддержки.

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

Планирование постепенного внедрения и закупок от списка разрешения проблем важных именно для вашего тестового примера

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

На деле просто обычный пользователь не готов например к тому, что MS Project или Oracle Primavera содержат тысячи еще нерешенных ошибок или проблем и может начать делать ложный вывод о нестабильности продуктов. Хотя по своим "Тропам Инков" продукты стабильны и техническая поддержка быстро проводит пользователей через минное поле багов вне "Тропы". Но есть важный момент. Технология требует документировать и обрабатывать все обращения пользователей, какими бы бредовыми они не казали на первый взгляд. Даже если пользователь обратится в поддержку с вопросом почему не появляются Зеленые Телепузики после распечатки документов или почему сломалась программа после того как ноутбук упал на пол. Все это должно быть задокументировано, рассмотрено и закрыто по бизнес-процессу  поддержки. Тотальное документирование обращений приводит к тому, что в реально эксплуатируемой программе большим числом клиентов обычно тысячи обращений. Это нормально, хотя может шокировать обывателя.

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

На деле все 100% поставщиков программных продуктов продают их по лицензии "как есть" (AS IS), т.е. с отказом от гарантий в том числе по срокам. Но тут есть важная деталь насколько поставщики готовы раскрыть план работы поддержки.

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

В Microsoft такое раскрытие есть, но не для всех клиентов. В рамках программы MS Technology Adaption Program (TAP) клиент, если он участник такой программы, имеет доступ к общему списку проблем в специальном закрытом портале Microsoft Connect. Тут важно понять, хочет с вами поставщик продукта играть также в открытую или нет. Если хочет, то на деле это огромный плюс. Открытая работа с клиентами подразумевает вот что:

  • Выделенный ресурс поддержки из программистов исправляющих проблемы по приоритетам именно от клиентов, а не только по внутренним приоритетам. Для внутренних приоритетов должен быть другой ресурс.
  • Некоторая процедура поставщика, где поставщик делает раскрытие информации о наличии проблем, формирует для групп проблем блоки работ
  • Предложение поставщика к группе клиентов по какой процедуре определить приоритетность решения проблем либо путем голосования, либо каким-то другим путем, но исходная информация о приоритезации разрешения проблем исходит от пользователей
  • Формирование графика обработки блоков проблем с плановыми сроками и отметками фактического выполнения

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

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

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

Управление версиями поставки ПО

Следующий важный момент в плане надежности, который надо знать. Если вы поставили и внедрили продукт, а поставщик обновил версию продукта, то не самая умная идея сразу бежать и обновляться. Не исключено, что именно на вашем сценарии эксплуатации что-то начнет работать не так на новой версии решения. Поэтому важнейший момент для клиента правильно управлять версиями. Современная разработка программных продуктов перешла на очень частый выпуск версий с исправлениями. Microsoft для MS Project Server выпускает обновления (Cumulative Update) чуть ли не каждый месяц. Время когда выпускался продукт и надо было ждать решения своей проблемы месяцами или годами до новой версии ушло в прошлое. Как правильно управлять версиями поставщиков? Если у вас все работает и все устраивает, не нужно ничего обновлять. Если возникают некритические проблемы, записывайте их и отслеживайте когда поставщик планирует их устранить. Когда видите, что выпущено обновление где сделано много улучшений аккуратно его проверьте сначала на своих настройках и если все работает - обновляйтесь. Но в любом случае это надо делать не часто.

Если у вас уже продукт нормально работает, хорошо подумайте перед тем как поставить новую версию от поставщика

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

Подведем итоги как обеспечить надежность сложного программного продукта

Сделаем контрольный список действий по обеспечению надежности программного продукта:

  • Определите по общению с поставщиком, что модификация архитектуры продукта закончена и сейчас только стабилизация и поддержка.
  • Изучите область охвата продукта по выступлениям Архитектора. Помните, что попытка развить продукт приведет к его дестабилизации - выбирайте готовое.
  • Изучите демонстрацию сценариев реализации бизнес-процессов в продукте либо по видео, либо по демонстрации продавцом. 
  • Оцените насколько вы сможете внедрить именно стандартные процессы на которые рассчитан продукт, т.к. такой вариант самый надежный в эксплуатации
  • Ищите в документации описание демонстрационных примеров процессов и повторяйте их на демоверсии. Протестированный продукт должен проходить пример со 100% вероятностью
  • Помните, что у всех поставщиков техническая поддержка по телефону это служба психиатрической помощи пользователям, если вам нужно решение проблем ищите чат поддержки, где находятся инженеры, а не психиатры
  • Работайте с инженером поддержки в терминах пошагового описания. Если вы можете формулировать шаги которые приводят к некорректному для вас поведению продукта, то вам помогут очень быстро
  • Многие поставщики имеют программы доверия с клиентами с раскрытием технологических рисков и текущих планов работы поддержки. Старайтесь работать с поставщиками, которые вас приглашают в такие программы. Планируйте закупки и внедрения в зависимости от дат, когда поставщик выпустит разрешение проблем, которые вам мешают чем-то воспользоваться.
  • Любой реальный продукт в эксплуатации имеет множество проблем и ограничений, одна вам нужно понимать, что проблема именно для вас. Если вы чем-то не пользуетесь, то такой проблемы для вас просто не существует. Обращайте внимание только как поставщик обрабатывает проблемы, которые касаются Вас, а не какой-то другой организации с другими задачами
  • Если продукт уже в эксплуатации очень осторожно обновляйте версии. Делайте это нечасто и с проверками, т.к. исправление каких-то других проблем, может изменить поведение продукта в вашем сценарии. 

Этот несложный набор лучших практик позволит вам внедрить даже очень сложный технически продукт обойдя технологические риски внедрения.

 

 

 

Расскажите о статье друзьям

Вы не вошли под своим пользователем на MicrosoftProject.ru.
Рекомендуется нажать "Закрыть" и зарегистрироваться на сайте.
Зарегистрированные пользователи, выступающие как редакторы,
имеют различные бонусы по доступу к закрытым материалам.
Если Вам не важны бонусы, можете отправить правку прямо сейчас.

Фрагмент, требующий улучшения
Ваша версия фрагмента. Отредактируйте текст
Степень серьезности проблемы
Проблемы содержания
Стилистические проблемы
Синтаксические и орфографические проблемы
Ваш комментарий:

Если вы заметили любую ошибку в статье, вы можете сообщить об этой ошибке редакторам сайта, выделив мышью отрывок текста с ошибкой и нажав Ctrl+Enter. Ваша помощь в улучшении материалов для нас неоценима!

© 2003-2013, Портал MicrosoftProject.Ru. Все права защищены.

E-mail: обратная связь