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

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

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

8.2.1. Покупка

При принятии решения о покупке основной технологии для вашей компании необходимо учитывать следующие соображения:

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

• Профессиональные услуги по настройке.

• В случае запуска системы на своем оборудовании:

• затраты на оборудование и дополнительные лицензии на ПО;

• затраты на обслуживание оборудования и программного обеспечения (резервное копирование, обновления безопасности и т. д.);

• Время на внедрение и настройку программного обеспечения.

• Можно ли периодически экспортировать данные.

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

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

Таблица 8.1. Покупка: преимущества и недостатки

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

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

Крупная покупка

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

8.2.2. Разработка

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

Таблица 8.2. Разработка: преимущества и недостатки

Хорошее сочетание – «купить» то, что можно, и «разработать» то, что требует большей гибкости и соответствия вашим требованиям. Как мы отметим позже в этой главе, когда будем обсуждать облачные решения, разработка не означает, что вы должны создавать вообще все. Вы можете использовать и интегрировать многие сторонние компоненты. Например, для отправки электронной почты можно использовать стороннюю службу, или если вам нужна подробная аналитика, то лучше отдать эту задачу отдельному инструменту бизнес-аналитики (BI), а вы будете загружать в него исходные данные.

Помните также: будьте осторожны с решениями low/no code. Это современные версии Visual Basic, позволяющие не-разработчикам создавать ПО с помощью инструментов point-and-click («наведи-и-щелкни») или drag-and-drop («перетащи-и-брось»), без написания кода. Эти инструменты создают обманчивое впечатление, что вы экономите кучу времени и быстро решаете 80 % задачи, но оставшиеся 20 % могут делаться гораздо дольше, потому что окажется, что проблема только усложнилась. В худшем случае вы идете на компромиссы, чтобы оправдать выбор именно этого инструмента, хотя он и не обеспечивает необходимой гибкости. Пойдут ли ваши конкуренты на такой же компромисс или же обойдут вас с более широким набором функций?

8.2.3. За и против

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

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

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

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

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

Создание систем уровня предприятия

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

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

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

8.2.4. Чек-лист

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

Таблица 8.3. Разработка или покупка

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

Стоит отметить, что если вы пойдете по пути покупки, то ров вокруг вашей организации станет значительно у́же. Это может быть не важно для организаций, чья интеллектуальная собственность не является технологией. Термин ров (moat) в сфере инвестиций определяет, насколько сложно конкурентам копировать то, что вы делаете. Если вы покупаете сторонние инструменты, ничто не мешает вашему конкуренту делать то же самое.

8.3. Облако или свое оборудование

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