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

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

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

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

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

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

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

14.5.3. Представление результатов

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

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

С технологиями принцип тот же. Когда мы, технари, излагаем подробности (например, что у основной базы данных нет резервирования и что она работает на одном сервере с публичным IP-адресом), нам кажется, что все тут понятно. Часто мы упускаем из виду вопрос «и что?» и забываем объяснить, каковы последствия этого.

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

1. Общий обзор объекта покупки.

2. Методология: время проведения, кто присутствовал, какие материалы были предоставлены, а какие были недоступны.

3. Выводы.

4. Дополнительные материалы.

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

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

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

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

Светофор для выводов

Я не раз проводил due diligence для покупателей – как компаний, так и частных инвесторов. За годы я разработал удобную шкалу оценки: на «красные» зоны заказчику нужно обратить пристальное внимание, «желтые» – иметь в виду, а «зеленым» можно порадоваться, если они соответствуют его целям.

14.5.4. Прохождение due diligence

До сих пор мы обсуждали, как проводить due diligence со стороны покупателя, но что, если ваша компания – объект покупки и опрашивают вас? Теперь, когда вы знаете, как проводить процесс, вы лучше поймете, о чем вас спрашивают. Имейте в виду, что вас не судят, а если вы чувствуете обратное – это ошибка того, кто проводит интервью.

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

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

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

• Общие схемы архитектуры/сети.

• Список всех технологий (включая версии).

• Лицензии, даты обновления и стоимость.

• Организационная схема со всеми сотрудниками.

• Описание процесса адаптации новых членов команды.

• Список недавних обращений в поддержку.

• Приоритеты развития.

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

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

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

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

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

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