Как сравнивать предложения fractional CTO?

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

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

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

Сначала приведите результат к общей форме

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

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

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

Попросите каждого кандидата указать, какие изменения можно будет увидеть на 30-й, 60-й и 90-й день. Формулировка «стратегия AI готова» не подходит. Результатом 30-го дня могут быть измеренные исходные показатели для двух потоков разработки и ранжированный список экспериментов. Результатом 60-го дня может быть один производственный процесс с согласованными правилами проверки. К 90-му дню может появиться план по составу команды и организации работы, подкрепленный измеренными изменениями времени цикла, числа дефектов, дошедших до пользователей, и нагрузки поддержки.

Единица сравнения здесь не «fractional CTO на три месяца». Это определенное изменение с заданными ограничениями и доказательствами в трех контрольных точках. Когда единица сравнения зафиксирована, задавать кандидатам неудобные вопросы становится намного проще.

Ясный объем работ требует исключений и приемки

Ясный объем работ объясняет, кто выполняет каждую часть, какой документ или рабочее изменение появится в результате, как вы его примете и чего fractional CTO делать не будет. Длинный список задач без этих четырех деталей только выглядит точным.

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

Для каждого результата добавьте критерий приемки. «Оценка текущего состояния» принята, когда в ней описан поток разработки, указаны системы-источники для каждого исходного показателя, зафиксированы пробелы в данных, а технический руководитель и основатель проверили документ. «Пилот AI-разработки» принят, когда выбранный процесс прошел на изменениях, предназначенных для продакшена, правила проверки задокументированы, а результаты показаны рядом с исходными значениями. Критерии приемки должны проверять доказательства, а не требовать от fractional CTO бизнес-результата, который зависит от вашей команды.

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

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

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

Исходные показатели должны подтверждаться данными

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

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

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

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

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

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

Полномочия определяют, сможет ли план двигаться

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

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

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

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

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

Для расчета экономии нужен реестр, а не процент

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

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

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

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

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

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

Оценивайте расчеты экономии от нуля до пяти. Ноль означает процент без обоснования. Один ставьте за общую сумму фонда оплаты и целевой процент. Два требуют назвать затронутые роли или контракты. Три разделяют прямую экономию, предотвращенные расходы, производительность и выручку. Четыре включают сроки, замещающие расходы и диапазоны сценариев. Пять связывают каждую существенную строку с механизмом, владельцем и доказательством, которое можно проверить во время проекта.

Первые 90 дней стоят больше месячной ставки

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

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

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

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

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

Оценивайте прозрачность стоимости от нуля до пяти. Ноль означает только месячную ставку. Один добавляет срок и график платежей. Два называют крупные дополнительные расходы. Три учитывают внутренний труд и лицензии. Четыре включают диапазоны зависимостей и правила изменения объема. Пять показывают обязательную, ожидаемую и неблагоприятную сумму с графиком денег и постоянной месячной позицией на 90-й день.

Сведите все предложения в одну таблицу

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

Используйте в электронной таблице следующие колонки:

• Категория: Объем, исходные показатели, полномочия, экономия или стоимость первых 90 дней
• Факт из предложения: Точное обязательство, допущение, исключение, цена или дата
• Доказательство: Раздел договора, приложение, пример данных или ответ кандидата
• Пробел: Отсутствующий владелец, критерий, источник, диапазон или право согласования
• Уточнение: Отправленный вопрос и полученный ответ с датами

Эти колонки сохраняют доказательства и пробелы до выставления оценок. Добавьте еще четыре колонки для суждений:

• Оценка: Целое число от 0 до 5 по правилам этой статьи
• Вес: Согласованная важность до открытия предложений
• Взвешенная оценка: Оценка, умноженная на вес
• Красный флаг: Да или нет с указанием сработавшего условия

Распределите между пятью категориями веса, которые в сумме дают 100. Разумный начальный вариант для AI-трансформации с упором на реализацию: объем 25, исходные показатели 20, полномочия 20, экономия 20 и стоимость 15. Измените их до того, как увидите финальные цены. Компания с немедленным ограничением по деньгам может увеличить вес стоимости. Компания с сопротивлением руководителей может увеличить вес полномочий. Не меняйте веса после того, как один кандидат получил плохую оценку.

Посчитайте результат по этой короткой формуле:

weighted_total = SUM(category_score / 5 * category_weight)

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

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

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

Проверка должна испытывать рабочие обещания

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

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

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

Для AI-работ спросите, как кандидат обращается с исходным кодом, учетными данными, информацией клиентов, сгенерированными изменениями и проверкой человеком. AI Risk Management Framework от NIST делит работу на Govern, Map, Measure и Manage. Это полезное напоминание о том, что выбор модели входит в более широкую систему управления. Предложение может не использовать термины NIST, но оно должно назначить ответственных, описать контекст применения, измерять результаты и сбои, а также указывать действия на случай, если защита не сработает.

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

Практическое сравнение обнаруживает скрытую выгоду

Представим компанию из 14 человек, которая сравнивает два предложения на три месяца. Предложение A стоит $8 000 в месяц. Оно обещает диагностику, внедрение AI-инструмента, обучение команды и рекомендации по составу сотрудников. Предложение B стоит $11 000 в месяц и включает извлечение исходных показателей, два пилота на производственных процессах, изменения репозиториев, обучение руководителей и решение по рабочей модели на 75-й день.

Сначала основатель видит $24 000 против $33 000 и предпочитает A. Таблица меняет сравнение. В A настройку инструмента передают техническому руководителю клиента, оценивают внутреннюю работу инженеров в 120 часов, исключают проверку безопасности, а реализацию оценивают только после диагностики. B требует 55 внутренних часов, включает настройку для двух пилотов и ограничивает дополнительные работы суммой $5 000 без нового согласования.

При внутренней расчетной ставке $90 за инженерный час A потребляет $10 800 рабочего времени инженеров, а B потребляет $4 950. Для A, вероятно, нужна проверка безопасности за $4 000, а реализация остается неоцененной в диапазоне от $8 000 до $20 000. В B проверка безопасности для названных пилотов включена, но требуется $2 500 на модели и инструменты. Ожидаемая стоимость 90 дней для A достигает $46 800, даже если реализация останется на нижней границе $8 000, а для B составляет $40 450. Предложение с меньшей месячной ставкой оказалось более дорогим проектом.

Оценки качества объясняют коммерческую разницу. Допустим, A получает 2 за объем, 1 за исходные показатели, 2 за полномочия, 1 за экономию и 2 за прозрачность стоимости. С начальными весами его взвешенный результат равен 32. B получает 4, 4, 4, 3 и 4, всего 76. B теряет один балл за экономию, потому что заявленный рост производительности еще не стал решением о денежных расходах. Такая сдержанность повышает доверие к предложению, а не снижает его привлекательность.

Теперь посмотрим на полномочия. В A CTO называют советником и требуют согласия основателя на инструменты, процессы и кадровые вопросы, но не задают срок ответа. B дает полномочия по инженерному процессу и инструментам пилота в пределах утвержденного бюджета, а основатель сохраняет кадровые решения на назначенных встречах 45-го и 75-го дня. План B работает между встречами. График A предполагает решения, которых его модель управления не разрешает принимать.

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

Закрепите доказательства и выход в договоре

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

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

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

Оплачиваемый Team & AI Audit может стать разумным первым договором, когда в предложениях остается слишком много допущений для сравнения. Фиксированная диагностика должна дать исходные показатели, доказательства экономии и решение по реализации, не обязывая компанию продолжать трансформацию с тем же исполнителем.

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