Previous Entry Поделиться Next Entry
SaaS против коробочного ПО: статистика использования против галлюцинаций разработчиков
kalaev
SaaS имеет еще одно неоспоримое преимущество перед "коробочным ПО" - возможность постепенных изменений и получение обратной связи через статистику.

Представим как работает технологический цикл у gmail:
  • посмотрели СТАТИСТИКУ эксплуатации и предложили изменения;
  • запрограммировали изменения;
  • изменения оттестировали на своих тестировщиках;
  • запустили изменения на 1% от аудитории gmail, внимательно посмотрели на СТАТИСТИКУ;
  • если статистика негативная - пошли переделывать, если статистика хорошая - запустили на остальных пользователей;
три побочных преимущества SaaS:
  • вернуть версию при плохой реакции можно мгновенно;
  • количество и частота изменений не ограничены из-за отсутствия задержек в  дистрибуции;
  • версия у пользователей всегда одна - не приходится думать о совместимости собственных версий.
А теперь представим цикл у "коробочного" Outlook
  • команда собрала МНЕНИЯ от клиентов и сама решила что еще можно улучшить (тут уже сразу кроется проблема в субъективности отзывов и мнений команды, в отличие от объективной статистики);
  • запрограммировали изменения;
  • оттестировали своими тестировщиками;
  • предоставили бета-версию, собрали МНЕНИЯ от первых пользователей;
  • запустили маркетинг, УГОВАРИВАЮЩИЙ старых клиентов перейти на новую версию;
  • запустили дистрибуцию;
  • если нашли ошибку в ПО, то выпускаем patch и надеемся что все клиенты постоянно обновляют ПО.
В случае с SaaS у нас есть реальная статистика использования и именно опираясь на нее делаются все изменения.
В случае с коробочным вариантом обратная связь собирается через мнения пользователей, потом интерпретируются командой разработчиков в которой обычно возникает "коллективная галлюцинация" по поводу потребностей и удобства использования.

  • 1
Так оно...
У SaaS-проектов и на старте жизнь в этом плане проще: сделал прототип > нагнал народу > собрал статистику > три раза переделал продукт, доводя его функционально и интерфейсно.
А нормальный фидбэк у нас пошел где-то через год после старта для появления обратной связи нужен продукт, которым пользуются сотни, а лучше тысячи (с пожеланиями обращается не больше 10% клиентов, остальные выкручиваются сами).

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

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

Зависит от сложности продукта - есть MS Office - он сложный, выпуск новой версии - событие эпохальное, а есть Бизнес-Пак - коробочное приложение, функционально идентичное интернет-сервису - они выпускают обновления часто, отслеживают фидбэк и статистику обновлений и вообще ведут себя почти как мы.

Зависит от подхода.
docs.google или salesforce может и менее сложные, но не на порядок.
Вопрос в сложившейся внутри компании парадигме.

Основания для принятия управленческих решений в ИТ вообще злобная тема.

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

  • 1
?

Log in

No account? Create an account