Надежность Microsoft Project: тесты, статистика, организационные риски


Многие меня знают как критика Microsoft за разные проблемы Microsoft Project Server, собственно мне как контролеру качества его и положено быть таким. Однако данную статью я решил написать, чтобы отбить откровенную атаку с черным PR на Microsoft со стороны его же партнера с попыткой мигрировать клиентов на Oracle Primavera под надуманным предлогом "ненадежности" MS Project.

Давайте обсудим как мы дошли до жизни такой и как проверять надежность IT-решений на базе Microsoft Project. Начнем со второго.


Тестирование решений на базе Microsoft Project на больших объемах


Вообще атаки в стиле "ваш продукт глючит" в адрес MS Project считаются на рынке нарушением деловой этики, т.к. все продукты имеют проблемы вопрос какова вероятность их появления и насколько быстро они устраняются. К чести центрального платформенного конкурента MS Project от Oracle Primavera, а именно ПМСОФТ, коллеги никогда не скатываются на уровень такого "базарного маркетинга".

Традиционно заявляет, что "MS Project глючит" г-н Либерзон из Spider Project, но это надо понимать, что скорее игра, т.к. Владимир как гениальный маркетолог создал себе имидж "сумасшедшего гения" играющего без правил. Но это при всей маркетинговой пыли внешней резкости на самом деле игра в этакий очень аргументированный "пинг-понг" с аргументами и контраргументами. Поэтому я собственно и создал тест Microsoft Project ниже на больших объемах включая столь любимый Владимиром Либерзоном Resource Leveling, чтобы ответить на его критику. Однако еще раз отмечу, что критика Владимира обоснованная, а не просто какие-то голословные утверждения. И на мой взгляд от открытого обмена аргументами и контраргументами потребитель только выигрывает.



В принципе видео в чем-то повторяет знаменитый Тест Джека Далгрена, где он даже создавал проекты до 1 миллиона задач показывая, что ограничение по числу задач MS Project это мифология, а реальное ограничение MS Project это скорость обработки задач примерно 60 задач в секунду. Данное ограничение мы обходим в Turbo Planner за счет алгоритмов которые пересчитывают не весь проект, а только что изменилось под действием пользователя. Поэтому формы сбора факта загружаются фактически мгновенно. По этой же причине расчет плановых показателей по ресурсам и финансам вообще идет "на лету", т.е. модель перестраивается сразу же после ввода данных, что очень важно для моделирования "а что если?". Как видим в опытных руках MS Project не испытывает проблем масштабирования и производительности. Но думаю не нужно объяснять, что если руки не такие, то и результат может быть иной.

Анализ надежности решений через публичные источники поставщиков


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

Все обращения в техническую поддержку Turbo Planner за 12 месяцев находятся в группе технической поддержки в Google Plus и доступны для анализа.

Всего в группу поддержки вступило 1407 пользователей, которым потребовалась помощь из более чем 50.000 обладателей демо-эккаунтов. Большая часть пользователей (99,7%) решила возникшие вопросы с помощью учебных видео по продукту опубликованных в группе поддержки. Что доказывает большую эффективность учебного видеоканала по продукту.  

Как можно убедится по сообщениям в группе, по выявленным в продукте ошибкам совершается примерно 4 обращения в месяц. Таким образом, та или иная ошибка возникла у 0,3% пользователей, что является низким показателем для бизнес-решений. 

Отметим, что сам по себе Turbo Planner очень серьезный тест для Microsoft Project, т.к. заставляет его работать на пределе своих возможностей. Однако как видим полученное интегрированное решение весьма стабильно.

Если брать даже возникающие проблемы, то больше половины из них из серии "обновите Microsoft Framework" или еще какое-то обновление Microsoft не поставили. Бывают конечно засланные конкурентами тролли из фанатов их продуктов или неадекватные люди, но даже таких процент ничтожно мал.

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

О том как "А" и "Б" сидели на трубе. "А" упало, "Б" пропало


И так, как говорится все совпадения в изложенной истории являются случайными, а герои вымышленными. Жили были компании, которых назовем "А" и "Б". В общем, "А" и "Б" внедряли решения на базе MS Project. При этом "А" имел функцию продавца, а "Б" выполнял реальное обслуживание корпоративных решений на базе Microsoft Project. Причем так хорошо "Б" выполнял, что стал Microsoft Internal Vendor, т.е. стал делать внедрения MS Project и от лица Microsoft Consulting Services.

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

Тогда в "А" решили найти экономически эффективную замену и на проект с бюджетом 15 миллионов рублей позвали фрилансеров за 20 тысяч рублей, чтобы они завершили работу "Б".

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

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

Идем далее. Поскольку фрилансеры не справились, а клиент стал жестко скандалить с "А", что поломали, то что уже было в эксплуатации и стал требовать вернуть экспертов "Б", которые обладают компетенцией корпоративного уровня в Microsoft Project и выгнать фрилансеров с проекта. В общем логичное требование.

Далее конфликт плавно перекочевал в Арбитражный Суд, который заключил, что "Б" правы в данном запутанном споре и работу делают компетентно.
Коллеги из "IT-Шапито" шутят над IT-фрилансом, но часто корпоратив за свои деньги получает именно "четкое внедрение" хотя вроде бы платил Gold-партнерам Microsoft

Теперь "А", к величайшему удивлению коллег из ПМСОФТ,  объявил себя экспертом в  Oracle Primavera и рассказывает всем, что Microsoft Project "глючит". А раз Microsoft ненадежная платформа, давайте поставим Oracle.

При всем моем уважении, но наезд на Microsoft таким черным PR затрагивает и наши интересы, хотя мы к конфликтам и судам коллег не имеем никакого отношения. Просто нам клиенты начинают говорить, что им сами партнеры Microsoft рассказали, что Microsoft Project не работает, а потому как же они могут воспользоваться Turbo Planner, если Microsoft производит "глючную байду" (правда непонятно как же с этим живут 20.000.000 пользователей).

Честно говоря не могу понять в чем проблемы Microsoft в данной ситуации, я вижу проблемы в другом:

  1. Реальная компетенция в технологиях Microsoft Project сосредоточена в дорогих компаниях как "Б" и "А" просто без "Б" не может обеспечить корректное развертывание решения Microsoft, т.к. компетенция находится у "Б". Правильнее сказать, что не MS Project "глючит", а что он "глючит" у "А"
  2. Попытка замены серьезных и недешевых экспертов как "Б" на дешевых фрилансеров подвергает серьезнейшим технологическим рискам корпоративных клиентов. Но это риск под управлением генподрядчика как "А" и относится к организационным, а не технологическим рискам от Microsoft.

Я бы призывал "А" и "Б" помириться и восстановить сотрудничество, т.к. мне кажется сомнительным, что без экспертизы "Б" возможно внедрять "А" крупные решения на Microsoft Project силами фрилансеров. И я бы попросил коллег выясняя отношения, не кидаться какашками в Microsoft только из  целей личной наживы, т.к. вредит всей экосистеме MS Project и тем, кто к их конфликтам не имеют никакого отношения.

PS. И давайте перестанем смешить рынок, что партнеры Microsoft вдруг получили эквивалент 20 летней компетенции ПМСОФТ в Primavera и смогли создать такую великолепную линейку решений. В России "Primavera=ПМСОФТ" и это заслуженная репутация на рынке, в том числе высокой бизнес-этикой работы. Я не вижу каких-то причин выбрав Primavera зачем-то идти вместо ПМСОФТ с таким признанным мегаэкспертом как г-н Цветков к новичкам без решений для Primavera.
Надежность Microsoft Project: тесты, статистика, организационные риски Надежность Microsoft Project: тесты, статистика, организационные риски Reviewed by Владимир Иванов on 4:13 Rating: 5
Все права защищены (C) 2014. Копирование разрешается при условии действующей ссылки на блог. Технологии Blogger.