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

Проверьте себя

Что из перечисленного ниже вы уже сделали?

• Планируете работу сотрудников и управляете ей (если у вас нет руководителя проектов).

• Отслеживаете работу команды в системе управления задачами.

• Придерживаетесь определенного подхода к разработке и планированию проектов.

• Описали и внедрили четкие и понятные стандарты разработки.

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

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

• Имеете представление о размере технического долга и составили план его уменьшения.

• Создали выделенную группу тестирования, не являющуюся частью команды разработчиков.

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

• Избавились от конструкций вида «если клиент такой-то, то…» в кодовой базе.

10. Работа с договорами

В этой главе

• Договоры с поставщиками и подрядчиками

• Техническое задание

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

• Лицензии и договоры на поддержку

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

В этой главе мы рассмотрим основные договоры, которые могут оказаться у вас на столе, их цель и то, как заставить их работать на вас. Уточним: это юридические документы, составленные характерным юридическим языком. Я настаиваю, чтобы вы всегда консультировались с юристом, прежде чем подписывать или составлять такой документ. Слишком часто самоуверенные инженеры, считающие, что полностью понимают содержание документов, подписывают то, что подписывать не стоит. Юридические документы – это не программный код: в них отсутствует логичная структура и единая понятная цель. Хороший технический директор отдает себе отчет в том, что это не его сфера компетенции, и оставляет юридические формулировки юристам.

Пара слов о хранении: обычно все бумажные копии (так называемые оригиналы) договоров с подписями и печатями хранятся у финансового директора. Тем не менее рекомендуется иметь и электронные версии в вашем хранилище файлов (Google Диск, Dropbox, Office 365), чтобы при необходимости в них можно было быстро что-то найти и проверить.

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

10.1. Договор оказания услуг

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

• Пополнение штата сотрудников.

• Выполнение конкретного проекта.

• Оказание поддержки.

• Управление системой.

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

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

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

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

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

Заметки с полей

Читайте, что написано мелким шрифтом

Философу Юджину Льюису Фордсворту (Eugene Lewis Fordsworthe) приписывают высказывание: «Допущения – источник всех ошибок», – и это действительно так, когда речь идет о договорах. Я участвовал в аудите due diligence от имени частной инвестиционной компании, которая намеревалась приобрести компанию, занимающуюся разработкой ПО. У этой фирмы не было разработчиков в штате, и все свои проекты она передавала стороннему подрядчику. Предполагалось, что правами на все результаты работы владеет заказчик. Однако тут была проблема: в договоре не была прописана передача прав интеллектуальной собственности на конечный продукт, и заказчик не мог его продавать. Полагая, что это просто недоразумение, и учитывая их прекрасные многолетние отношения, компания посчитала, что урегулировать юридическую сторону дела не составит проблем. Однако люди ведут себя непредсказуемо, когда речь идет о больших деньгах. В итоге они не смогли договориться. Подрядчик воспользовался ситуацией и начал выдвигать новые требования. Излишне говорить, что инвестор отказался от сделки, и все потому, что кто-то не прочитал то, что было написано в договоре мелким шрифтом.

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

Договор оказания услуг часто дополняется следующими документами:

• техническим заданием;

• описанием параметров оказания услуг.

10.1.1. Техническое задание

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

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

ОПРЕДЕЛЕНИЕ

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

Типовое техническое задание содержит следующую информацию:

• Объем работ: что нужно делать, что не нужно.

• Предоставляемые результаты: исходный код, библиотека или сервис.

• Момент передачи прав интеллектуальной собственности на результат работы.

• Доступы, необходимые для выполнения работ.

• Разрешения/ограничения на использование определенных сотрудников или привлечение субподрядчиков.

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

• Гарантийные обязательства.

• Срок действия договора.

• Условия продления / внесения изменений / прекращения действия договора.

• Ограничения возможных вариантов реализации.

• Условия оплаты.

Степень детализации ТЗ зависит от планируемого взаимодействия. Для ресурсов, предоставляемых быстро и по запросу (таких, как привлечение разработчиков), характер выполняемой работы обычно указывается кратко. Например: «Услуги разработки на языке Java по запросу менеджера проекта», – без перечисления конкретных задач. Однако в этом случае обычно обозначаются минимальные сроки работ