В зависимости от того, на каком этапе находится ваша карьера, вы, скорее всего, хотя бы 1–2 раза уже проводили due diligence. Возможно, процедура называлась иначе – скорее всего, оценкой. Она могла проводиться не для компании, а для конкретного ПО, языка, фреймворка или сервиса. Готовясь к ней, вы заранее изучали все, что могли, формулировали свои мысли и составляли вопросы.
Когда вы общались со специалистами по оцениваемой системе (ее пользователями или же техническим менеджером), вы спрашивали их о вещах, относящихся к проблеме, которую эта система должна решать. У вас наверняка не было таблицы с абстрактными вопросами, ответы на которые ни на сантиметр не приблизили бы вас к принятию обоснованного решения. Вместо нее у вас был список тем, относящихся в основном к эксплуатации продукта, обсудив которые вы бы поняли, в правильном ли направлении движетесь. В этом и состоит разница: так вы понимаете «зачем» сделаны те или иные вещи, и на основании этого можете определить, подходит ли оцениваемый продукт для ваших целей.
Тот же подход применяется при оценке технологий всей компании – в этом случае требуется просто немного больше усилий, но сам процесс будет не сложнее. Вы здесь эксперт по технологиям, который занимается решением практических проблем. Большая часть из того, что вы увидите, будет либо «кока-колой», либо «пепси» (они обе хороши – просто разные), либо какими-то мелочами, которые легко решить. Так что именно вы, а не сотрудник консалтинговой компании, лучше всего подходите для проведения due diligence. Вы способны быстро распознать вещи, требующие особого внимания, поскольку они могут стать проблемными.
Рассмотрим основные области, которые требуют подробного изучения. При проведении обследования помните, что, если сделка состоится, все обнаруженные проблемы или вопросы придется решать вам. Но вполне возможно, что вы также узнаете что-то, что поможет вашей команде и что можно будет использовать в дальнейшей работе. Может быть, вы найдете решение для проблемы, с которой давно боретесь, или узнаете, как делать что-то более эффективно. Всегда найдется что-то полезное.
Насколько отличаются их технологии от ваших? Достаточно ли у вашей команды знаний, чтобы использовать их? Если они применяют устаревшие технологии, то что потребуется для их дальнейшей поддержки, в том числе будут ли проблемы с подбором специалистов или обслуживанием оборудования или операционных систем? Есть ли что-то, что можно оптимизировать или сделать более эффективным с помощью современных технологий? Если понадобится все переписать – каких усилий и затрат это потребует и вызовет ли это перебои в работе?
Какая часть их технологий уникальна? Что является объектом ПИС («секретным ингредиентом») – алгоритмы и код – либо это способ применения инструмента? Имеются ли патенты на технологии, и если да, то кому они принадлежат – физическим лицам, компании, кому-то еще? Кто (как ни странно это звучит) на самом деле является владельцем исходного кода? Ответ на этот вопрос не всегда очевиден, особенно если компания отдавала основную разработку на аутсорсинг.
Как сохраняются и используются данные? Какой их объем доступен и может применяться для аналитики? Каковы основные источники и потребители данных? Кому принадлежат данные и какие есть ограничения на их использование? Как регулируется работа с данными (должен ли выполняться регламент Евросоюза по защите персональных данных (GDPR)?) и есть ли в компании конфиденциальные данные, подпадающие под действие нормативных требований (например, PII, PCI или HIPAA)?
Заметки с полей
Это мои данные – буду делать с ними что хочу
Я часто сталкивался с компаниями, которые считали, что если адрес электронной почты попал к ним в базу данных, то они могут делать с ним все, что им заблагорассудится. Но это не так. Как были получены эти данные? Если пользователь не давал согласия на использование (или продажу) своих данных, то они бесполезны. Я не раз наблюдал, как люди бледнеют, когда понимают, что данные, которые у них есть, далеко не так ценны, как они думали.
Какова структура существующей технической команды? Каковы навыки и опыт сотрудников? В небольших организациях люди часто работают с самого момента основания компании, и всему, что они умеют, они научились на этой работе. Если вы имеете дело с таким случаем, то чему и у кого эти люди учились?
Кто из инженеров является более опытным, чем остальные, и незаменимым? Лучший способ выяснить это – спросить: «Чье отсутствие сильнее всего заметно в компании, когда человек уходит в отпуск?» Большинство команд ответят на этот вопрос быстро и не задумываясь. Небольшие компании слишком полагаются на верность и трудолюбие одного человека. Иногда это тот самый, кто спроектировал все системы, и, вероятно, именно он отвечает на все ваши вопросы в связи с due diligence.
Привлекает ли компания подрядчиков или аутсорсинговые фирмы для поддержки или разработки? Каковы их зоны ответственности и сроки договоров? Вам необходимо выяснить, могут ли какие-либо договорные отношения вызвать проблемы в будущем (например, с правами собственности или с прекращением договора).
О каких проблемах обычно сообщают пользователи или клиенты? Сколько времени тратится на поддержку по сравнению с разработкой новых функций?
Сколько усилий или времени обычно занимает в компании подключение новых клиентов? Участвует ли в этом техническая команда? Какие серьезные сбои или проблемы были за последние 12 месяцев? Как они повлияли на клиентов и что было сделано, чтобы они не повторились? Что не дает руководству спать по ночам и что бы они сделали в первую очередь, если бы у них была волшебная палочка?
Как в целом в компании организовано обеспечение безопасности? Когда в последний раз менялись основные пароли? Какие доступы имеют разработчики? Отделен ли продакшен от окружения для разработки?
Если компания работает с учетными данными пользователей, то как хранятся пароли в базе данных (открытым текстом или в виде хэша с солью)? Вы удивитесь, сколько компаний до сих пор хранит пароли в открытом виде!
Как организовано тестирование, проводились ли тесты на проникновение, на SQL-инъекции в продакшене? Требования безопасности либо могут учитываться с самого начала, либо про них вспоминают в какой-то момент позже – вам нужен первый вариант.
Если приобретаемая компания разрабатывает исходный код, очень важно изучить его общее качество и подходы к разработке. Вникнуть в каждую строчку кода, конечно же, не получится. Во-первых, у вас нет времени, а во-вторых, за несколько часов невозможно понять результат разработки, ревью, переписок и исправлений, сделанных множеством разработчиков за годы. Лучше выбрать несколько мест, подробно изучить их и на основе этого сделать вывод об общем состоянии.
Все мы в своей жизни писали код, по которому лучше бы нас не оценивали, поэтому выберите относительно недавний коммит. Найдите его по истории в системе контроля версий или начните с какого-то из тикетов и проследите работу над ним от создания задачи до разработки и деплоя на продакшен.
Еще одна сфера, на которую следует обратить внимание, – безопасность разработки. Изучите, как в коде организована работа с параметрами конфигурации, именами пользователей и паролями. Если в инфраструктуре имеется большое количество API – проанализируйте, как они устроены, единообразно ли используются? Как обрабатываются ошибки и исключения? Код основан на предположениях о том, что ничего не сломается, или в нем предусмотрены различные проверки?
О зрелости кода многое скажет его общая структура. Это просто куча функций или же все организовано в виде объектов, которые можно использовать при разработке нового функционала? И если говорить об использовании готового кода, то какие библиотеки с открытым исходным кодом применяются для решения типовых задач, и применяются ли? Соответствуют ли лицензии этих библиотек требованиям бизнеса, соблюдаются ли условия лицензий?
Наконец, ознакомьтесь с системой журналирования. Как мы увидели в предыдущей главе, она помогает мониторить продакшен в реальном времени и оперативно диагностировать проблемы. Приводятся ли журналы к единому формату, чтобы можно было легко выявлять исключения и ошибки среди информационных и прочих не требующих реагирования записей?
В компаниях, занимающихся разработкой, стоит изучить организацию работы, включая ревью кода, работу с системой контроля версий, тестирование, сборку и деплой. Небольшие команды обычно гораздо меньше соблюдают формальности, и в них все это может быть в зачаточном состоянии. Не нужно осуждать их – просто отметьте это как особенности. Неважно, что и как они делают и нравится вам это или нет: результат их работы кому-то нужен, иначе вы бы даже не и подумали приобретать эту компанию.
Последнее, что необходимо выяснить, – как выполняется деплой и как организован мониторинг продакшена. Вы можете спросить, для эффектности добавив драматическую паузу: «Откуда вы знаете, что прямо сейчас у вас все в порядке?» Ответ на этот простой вопрос, в том числе честное пожимание плечами, говорящее о том, что ваш собеседник понятия не имеет, все ли в порядке, многое скажет о том, как в компании организован продакшен.
Вам нужно понять, что необходимо для бесперебойной работы проекта. Помните: если сделка пройдет успешно, это станет вашей заботой. Итак, выясните, какие требуются ежедневные проверки, какие журналы нужно просматривать и по каким признакам можно понять, что что-то может пойти не так.
Изучите план обеспечения отказоустойчивости. Как работает резервирование при сбоях? Обсудите слабые места и точки отказа и что с ними можно сделать. Сюда также относится вопрос резервного копирования и восстановления – при его обсуждении также выясните, есть ли доступная документация или инструкции по восстановлению.
Еще в рамках этой темы узнайте, кто отвечает за оплату сторонних сервисов и продление подписок и договоров с ними. Нередко (особенно в небольших компаниях) учетные записи таких сервисов, как AWS, GitHub или GoDaddy, «принадлежат» программисту, который начал с ними работать, просто потому, что к ним привязана его банковская карта и с нее списывается ежемесячный платеж, который затем возмещается компанией.
Заметки с полей
Google забыл оплатить счет за домен
В современном мире, где все взаимосвязано, сервисы могут оказаться отключенными по самым нелепым причинам, в том числе если не оплатить продление домена или SSL-сертификата. Такое произошло с Blogger, одним из сервисов технологического гиганта Google. Кто-то не оплатил продление домена blogger.in, поэтому контроль над ним был на некоторое время потерян. См. https://www.androidpolice.com/2020/07/16/someone-at-google-forgot-to-renew-a-blogspot-domain-still-offline-a-week-later/.
Большинство из найденных проблем вполне решаемы и рассматриваются в этой книге, но, прежде чем заключать сделку, важно определить, кто чем владеет и на каких основаниях.