Почему обслуживание веб-приложений должно быть чем-то большим

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

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

Так что же это за секрет?

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

Не убежден?

Быстрый поиск по термину «Общая стоимость владения» предоставит вам множество похожих определений, подобных этому от Gartner (выделено мной):

[TCO — это] стоимость внедрения, эксплуатации, поддержки и обслуживания или расширения, а также вывода из эксплуатации приложения.

Кроме того, в этой статье Стэнфордского университета утверждается, что обслуживание обычно составляет от 60% до 90% совокупной стоимости владения программным продуктом.

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

Мы не настаиваем на техническом обслуживании

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

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

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

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

Что такое техническое обслуживание?

В своей статье 2012 года «Эффективное обслуживание приложений» Хизер Смит и Джеймс Маккин определяют обслуживание как (выделено мной):

Перенос приложения на новый сервер, взаимодействие с другой операционной системой, обновление до более новой версии, изменение налоговой таблицы или соблюдение новых правил — все это требует обслуживания приложения. В результате техническое обслуживание сосредоточено на обновлении приложения, чтобы обеспечить его производительность и/или рентабельность . Оперативная группа предпочитает следующее определение обслуживания приложения: любая модификация приложения для исправления ошибок; улучшить производительность; или адаптировать приложение к изменившейся среде или изменившимся требованиям. Таким образом, добавление новых функций к существующему приложению (т. е. усовершенствование), строго говоря, не считается обслуживанием .

Другими словами, техническое обслуживание — это важная работа, которую необходимо выполнять над программным приложением, чтобы оно могло продолжать надежно и безопасно функционировать.

Это не добавление новых функций. Это не проверка файлов журнала или обеспечение выполнения резервных копий (это служебные задачи). Он работает над кодом и базовой платформой, чтобы убедиться, что все в курсе, что он работает так, как ожидают его пользователи, и что свет остается включенным.

Вот несколько примеров:

• Изменения в технологиях и платформах
  Сторонние библиотеки нуждаются в обновлении. Базовый язык требует обновления, например, с PHP 5.6 до PHP 7.1. Современные операционные системы регулярно рассылают обновления. Соблюдение этого требует технического обслуживания и иногда также требует внесения изменений в кодовую базу, поскольку старые способы выполнения определенных действий устаревают.

• Масштабирование
  По мере роста приложения будут проблемы с ресурсами. Подпрограммы в коде, которые нормально работали с 10 000 транзакций в день, не работают с 10 000 транзакций в час. Приложение необходимо отслеживать, но также необходимо предпринимать действия при срабатывании предупреждений.

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

Трудно продать?

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

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

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

• Отчетность о прогрессе в сравнении с KPI (например, трафик, конверсии, количество запросов)
• Ограниченное «бесплатное» время каждый месяц для небольших настроек сайта
• Отчетность о простоях, обновлениях сервера или завершенных разработках
• Доступ к вам или конкретным членам вашей команды по телефону для ответов на вопросы

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

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

Тривиальная задача для вас или вашей команды; большое значение для вашего клиента.

Практический пример

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

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

Вы стремитесь минимизировать долгосрочный риск.

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

Вы также понимаете, насколько важно техническое обслуживание любого делового актива.

Позже, в разделе результатов, вы можете добавить часть об обслуживании либо как отдельную опцию, либо в комплекте с текущим авансовым платежом.

В следующем примере мы упростили его и объединили с предоплаченным авансовым платежом за разработку:

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

Как клиент, который разумно заинтересован в обслуживании приложения, а также в добавлении новых функций, мы предлагаем N дней в месяц (в качестве отправной точки) для общего обслуживания и разработки.

Мы бы распределили все так, чтобы разработчик работал над вашей системой по крайней мере [некоторый период в неделю/месяц], что дает вам явное преимущество в том, что разработчик может переключиться на что-то более важное, если возникнут проблемы в течение [того же периода]. . В зависимости от ваших приоритетов это время может быть потрачено на работу над новыми функциями или разделено на обслуживание, это ваш выбор. Обычно мы предлагаем разделить 75%/25% между новыми функциями и важным обслуживанием.

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

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

Если речь идет о фазе 2 или просто о выставлении окончательных счетов и передаче, напомните им о техническом обслуживании. Напомните им о постоянном обучении, отчетах и ​​доступности поддержки . Добейтесь гонорара, не забывая говорить в том же коммерческом ключе: их новый актив нуждается в обслуживании, чтобы оставаться блестящим .

Может ли обслуживание раздражать?

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

Однако обычно это не так. Возможно, в начале у клиента будет список загвоздок, которые нужно проработать, но это в порядке вещей; если вы опытны, то вы ожидаете этого. С ними легко справиться, улучшив каналы связи (используя средство отслеживания проблем) и объединив все запросы, т. е. работая над ними за один раз.

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

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

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

Как упростить техническое обслуживание?

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

Долгосрочная поддержка (LTS)

• Используйте технологические платформы с хорошо задокументированными выпусками LTS и путями обновления.
• Следует ожидать и учитывать текущие обновления ОС, языка, фреймворка и CMS для всех проектов, поэтому отслеживание версии LTS не составляет труда.
• Все должно работать на поддерживаемой версии. Если это не так, должны зазвенеть большие тревожные звоночки.

Хорошая гигиена проекта

• Публично размещайте задачи обслуживания в своем журнале задач или в системе отслеживания проблем и согласовывайте приоритеты с вашим клиентом. Не прячьте задачи обслуживания.
• Уровень кода и функциональные тесты позволяют следить за особенно проблемным кодом и помогают при извлечении модулей для рефакторинга.
• Контролируйте приложение и понимайте, где находятся узкие места и ошибки. Любые проблемы могут быть добавлены в журнал разработки и соответствующим образом расставлены по приоритетам.
• Отслеживайте запросы в службу поддержки. Предоставляют ли конечные пользователи полезную обратную связь, которая может указывать на необходимость обслуживания?

Приложение должно быть портативным

• Любой разработчик должен иметь возможность легко настроить и запустить систему локально — не только вы! Используйте виртуальные серверы или контейнеры, чтобы убедиться, что разрабатываемые версии приложений идентичны рабочим.
• Приложение должно быть хорошо документировано. Как минимум, рабочие процессы подготовки и развертывания, а также любые специальные заклинания, необходимые для развертывания, должны быть записаны.

Техническое обслуживание — это подлинный беспроигрышный вариант

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

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

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

Сделайте одолжение себе, своему клиенту и всей нашей отрасли: помогите сделать обслуживание веб-приложений чем-то большим.