Когда сталкиваюсь с разработкой решений на SharePoint часто наблюдаю парадоксальную на первый взгляд картину. С одной стороны заказчик постоянно хочет с экономить на решении. Очень часто исполнитель выбирается исключительно по самой низкой цене. Заказчик часто пытается сократить расходы на анализ потребностей, проектирование и тестирование. С другой стороны к решениями часто предъявляются совершенно неразумные требования, часто противоречащие эффективному использованию этих самых решений. Все это бьет по качеству решения.
В итоге решение для заказчика стоит гораздо больше суммы контракта. Причем определить эту скрытую стоимость довольно сложно. Только путем анализа многих операционных показателей.
Из чего складывается скрытая стоимость
Затраты на ожидание
Первый пункт самый банальный. Любая компьютерная система имеет время реакции на действия пользователя. Самое простое – время открытия страницы. Если пользователь открывает 20 страниц в час, то за день выходит 160 страниц. Если вместо двух секунд страница открывается 6 секунд, то за день только в ожидании страниц пользователь проводит 10 минут. Для 100 пользователей это уже значительное время. А время = деньги.
Сюда относится время простоя системы из-за неполадок, обновлений и тому подобных вещей.
Слишком много ручных действий
Казалось бы, в чем проблема нажать кнопку, или вбить значение в поле. Но если это делается много раз в день, то возникает две проблемы. Первая – время затраченное на эти действия. Вторая – чем больше ручных действий, тем больше вероятность ошибиться.
Поиск информации
Очень часто системы позволяют вводить много информации, тысячи документов, миллионы элементов списков. Но извлечь нужную информацию из системы далеко не всегда возможно и легко. Часто это пытаются решить вводом большого количества метаинформации, но это приводит к проблемам, описанным в предыдущем пункте.
Исследования показывают, что сотрудники, занимающиеся обработкой информации тратят на её поиск от 15% до 35% времени. Источник: http://www.kmworld.com/Articles/Editorial/Features/The-high-cost-of-not-finding-information-9534.aspx.
Обходные пути
Часто бывает так, что решение вроде работает, но иногда падает или дает не тот результат. Ошибка вроде некритичная и есть обходной путь. В таких условиях заказчик обычно принимает решение и подписывает акты, а исполнитель обычно подобные ошибки не правит.
Обходные пути могут отнимать много времени, но часто они настолько входят в привычку, что люди перестают воспринимать обходной путь как проблему.
Обращения в службу поддержки
Когда решение сделано некачественно, службе поддержки приходится гораздо чаще отвечать на вопросы пользователей. Кроме того часто могут требоваться вмешательства администраторов системы для восстановления нормальной работы. Это прямые затраты для службы поддержки и косвенные затраты на ожидание для пользователей.
Доработки
Чем ниже качество системы, тем чаще требуются доработки и тем дороже они стоят. Часто еще возникает проблема что поставщик решения – по сути монополист и может диктовать условия. Другой исполнитель не сможет разобраться в решении и для его выгоднее будет создать с нуля, чем проводить локальные доработки. Для заказчика оба варианта плохи.
Стоимость апгрейда
Почти любое решение в SharePoint требует дополнительных затрат при апгрейде платформы. Причем чем хуже сделано решение, тем дороже стоит его апгрейд. Даже если решение реально не надо переделывать, то исполнитель заложит в смету риск, никто ведь заранее не скажет где и когда оно упадет.
Стоимость обслуживания решения
Это прямые затраты администраторов для резервного копирования\восстановления, настройки, переноса решений, раздачи прав доступа, мониторинг системы и архивирование данных. Чем хуже сделано решение, тем дороже обходятся эти банальные операции. Сюда же относятся затраты на исправление проблем, когда одно решение влияет на другие или на возможности платформы.
Как бороться со скрытыми затратами
Большинство скрытых затрат происходят от дефектов решения, которые невозможно выявить на приемо-сдаточных испытаниях. Чаще всего это:
- Непроработанность пользовательских сценариев
- Дефекты в модели данных, усложняющие масштабирование
- Низкое качество кода, большое количество дефектов в реализации
- Дефекты сценариев развертывания
- Решение не адаптировано к работе в довольно динамичной среде SharePoint
А теперь собственно как бороться:
Пилотные проекты
Проекты SharePoint несут большую степень неопределенности при старте. Сделать успешное решение, для масштаба компании в несколько тысяч человек, почти невозможно. Нужно проверить что решение работает на небольшой группе, уточнить требования к нему, не потратив много денег. На стадии пилотного проекта можно пожертвовать качеством, но очень важно собрать обратную связь от пользователей. На маленьком масштабе проще удовлетворить всех пользователей и выделить ключевые потребности.
Ранее прототипирование
При разработке новой системы обязательно нужны прототипы. Сначала на бумаге, потом интерактивные, потом изготовленные непосредственно в SharePoint. Прототипы позволяют быстрее всего договориться всем участникам о том, какой будет результат.
Слабосвязные сервисы
Если выбирать между большой интегрированной системой и набором отдельных полезных сервисов, то обязательно надо выбирать второе. Отдельные сервисы дешевле, проще в создании и внедрении. Внутренняя сложность отдельных сервисов гораздо ниже большой системы, а SharePoint обеспечивает возможности интеграции между сервисами.
Если сделать хороший сервис для одного структурного подразделения, то совершенно необязательно его масштабировать на всю компанию. Можно просто продублировать сервис для каждого подразделения, а потом собрать данные для отчетности и анализа прямо в Excel.
Не пытаться покрыть 100% потребностей
Это очень важно. SharePoint, как и любая другая платформа имеет свои ограничения, то сделать на нем можно все что угодно, но некоторые вещи будут крайне дорогими. Тут нужно применять правило Парето: 20% усилий дают 80% результата. Остальные 80% лучше потратить на создание других сервисов.
Придерживайтесь best practices
Даже в официальной документации по платформе описаны сотни рекомендаций как надо делать. Кроме того множество книг содержат эти самые рекомендации. Отступая от этих рекомендаций вы повышаете скрытые расходы ваших решений на SharePoint. Нужна очень веская причина чтобы отступать от рекомендаций.
Design review
Для каждого сервиса необходимо проводить инспекцию дизайна ДО того как начнется разработка и внедрение. Даже если своих ресурсов нет для этого, то можно пригласить консультантов. Опытный архитектор SharePoint быстро поймет где источники скрытых затрат, глядя только на схему решения.
Проверка решений
По возможности делайте аудит кода. Для этого существуют инструменты, например SPCAF (http://www.spcaf.com/). А особо сложных случаях также можно привлечь консультантов.
Имейте все исходники и документацию
Часто подрядчики хотят зацепить клиента нехорошим способом – не отдавать исходники решений, продав при этом дорогой контракт поддержки. С самого начала работ с внешним исполнителем надо договориться о передаче имущественных прав на решение и исходных кодов заказчику. Кроме того требуйте наличие технического описания решения, которое говорит о том из каких частей состоит решение, как оно устанавливается и как предоставляется пользователю.
В идеале для этого необходимо использовать интегрированные среды разработки, желательно в облаке.
Заключение
Прочитав этот пост многие подумают, что уменьшение скрытых затрат ведет к увеличению затрат явных.
Исследования множества проектов разработки (Shull defects paper) говорят о том, что 20%-80% стоимости разработки занимает переделывание работы, связанное с исправлением дефектов. Разброс большой, точная величина зависит от уровня зрелости разработки у исполнителя.
Ранее я приводил таблицу результативности методов устранения дефектов (http://gandjustas.blogspot.com/2013/07/code-review-vs-testing.html). Прототипирование, инспекции дизайна и кода показывают одни из лучших результатов. В совокупности они могут дать до 95% устранения дефектов до релиза. Правильный подход к разработке может сократить общие затраты на создание решения более чем в два раза, добавив незначительные затраты на прототипирование и инспекции.
В том же исследовании указано, что затраты на создание сложносвязных систем вы разы выше, чем создание систем с малым количеством связей между компонентами. Именно поэтому стоит создавать небольшие сервисы, которые в дальнейшем объединять в системы. По моему опыту такой подход позволяет во много раз сократить совокупную сложность системы и позволяет плавно переходить от стадии прототипирования к масштабированию системы.
В итоге делать хорошие решения получается быстрее и выгоднее для обоих сторон.
