Настоящий CTO: думай как технический директор - Алан Уильямсон

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

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

Хорошее техническое задание должно быть достаточно подробным, чтобы обе стороны четко понимали свои обязательства, но при этом гибким, чтобы адаптироваться к изменениям по мере вашего развития. Ни одна из сторон не должна чувствовать себя связанной чрезмерными обязательствами, поэтому старайтесь не заключать соглашения на слишком длительный период. Примеры ТЗ см. на странице https://www.projectmanager.com/blog/statement-work-definition-examples.

10.1.2. Параметры оказания услуг

Параметры оказания услуг, или SLA (service-level agreement), обычно определяют верхние или нижние границы различных характеристик услуги или продукта. Например, ожидаемое время доступности сервиса и какова компенсация в случае, если оно не обеспечивается.

AWS в SLA для службы Elastic Compute Cloud (EC2) указывает, что доступность сервиса в месяц составляет не менее чем 99,99 % времени, а в случае невыполнения этого требования клиенту будет предоставлена скидка в размере 10 %. Это значит, что время недоступности сервиса может составлять около шести минут (точнее, четыре с половиной минуты – прим. редактора) в месяц, если оно будет больше – Amazon должен будет вернуть вам 10 % от суммы вашего счета за EC2 (https://aws.amazon.com/compute/sla/).

Цель SLA – обеспечить вашу уверенность в том, что на сервис можно положиться. Представьте, что Amazon не оговаривает параметры оказания услуг или, что еще хуже, доступность сервисов у них составляет всего 50 %. Это означает, что их сервисы могут быть недоступны до двух недель каждый месяц без каких-либо компенсаций. Устраивает ли ваш бизнес такое качество обслуживания?

Документы SLA очень распространены для облачных сервисов и моделей X-as-a-Service (что-либо как услуга). SLA применяется ко всем сферам, в которых привлекаются сторонние сервисы, и определяет, на какую их доступность вы можете рассчитывать, что, в свою очередь, позволяет вам предоставлять своим клиентам информацию о возможностях вашего продукта.

SLA предусматривают разные уровни: чем больше девяток (0,999999) надежности вам нужно от службы, тем дороже она будет. Выбор оптимального варианта во многом зависит от ваших потребностей и может быть разным для разных областей. Некоторые части вашей экосистемы способны выдержать большее время простоя, чем другие.

SLA также определяет, сколько времени может пройти с момента сообщения об ошибке или проблеме до ее решения. Чем важнее сервис, тем выше требования SLA.

ОПРЕДЕЛЕНИЕ SLA

С другой стороны, если ваш продукт предоставляет API или работает по модели X-as-a-Service, вам необходимо сформулировать ваши параметры оказания услуг, которые вы должны будете соблюдать. Они оговаривают уровень сервиса, который вы планируете предоставлять своим пользователям, и компенсацию за его невыполнение.

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

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

• Какой из сторонних сервисов, используемых вами, имеет самый низкий уровень SLA? (Вы сильны ровно настолько, насколько сильно ваше самое слабое звено.)

• Какова длительность простоя, необходимого вам для выпуска релизов или обновлений системы?

• Способны ли вы обеспечивать выполнение SLA 24 часа в сутки каждый день, или же только в рабочее время?

• Каковы сроки решения той или иной проблемы?

• Достаточно ли у вас сотрудников для обеспечения поддержки, с учетом отпусков?

• Каким был уровень доступности вашего продукта до сих пор?

• Какова самая слабая часть или единая точка отказа в вашем решении, которая может повлиять на его бесперебойную работу?

Никогда не берите цифры из воздуха. Они должны быть достижимы, и вы должны быть готовы обосновать и защитить их.

10.2. Оценка поставщиков

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

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

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

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

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

• Рекомендации/отзывы. Попросите рекомендации от клиентов со схожими требованиями. Если поставщик предоставляет услуги поддержки определенного продукта, узнайте, существует ли для этого продукта список рекомендованных поставщиков или партнерские программы и входит ли в них ваш кандидат?

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

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

10.3. Лицензии на использование ПО

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

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

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

• Дату приобретения.

• Дату/стоимость продления.

• Контактные данные поставщика лицензии.

• Контактные данные вашего персонального менеджера, такие как электронная почта/телефон/адрес.

• Комментарии, для чего конкретно используется лицензия.

• Ключи/коды лицензий.

Чтобы поддерживать список в актуальном состоянии, его следует пересматривать