--- title: "兼职 CTO 的 30/60/90 天计划" canonical: https://wavect.io/zh/blog/fractional-cto-30-60-90-day-plan/ language: zh description: "一位兼职 CTO 的前 90 天应当产出什么：评估、规划、执行，加上能在他离开后留存的交付物和仍在运转的系统。" image: "https://wavect.io/img/blog/headers/header_fractional-cto-30-60-90-day-plan.png" --- [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 min 阅读 · 13 Jun 2026 [**下一篇**](/zh/blog/fractional-cto-when-to-hire-austria/) # 面向奥地利初创公司的兼职 CTO 30/60/90 天计划 要点速览 你已经聘请了一位兼职 CTO；前 90 天应当产出什么？第 0 到 30 天：评估与稳定（一轮倾听、跟随真实工作、风险分诊、只做低风险的快速见效项、一份书面工程现状评估，并且明确不重写、不重组、不裁员）。第 31 到 60 天：规划与打基础（一张与业务目标挂钩的技术路线图、一份招聘计划、一套交付节奏、基础工程指标、修复前一到两位的风险、把决策记录下来）。第 61 到 90 天：执行并做好交接准备（通过新节奏交付、用风险和投资的语言向董事会汇报、把组织调整到无需 CTO 每天在场也能运转、定义聘请全职的触发条件）。其价值在于能在他离开后留存的交付物和一个仍在运转的系统，而不是成为屋子里技术最聪明的人。 您已经聘请了一位 [兼职 CTO](/zh/glossary/fractional-cto/) 。前 90 天究竟应当产出什么？第 0 到 30 天是评估与稳定：一轮倾听、跟随真实工作、风险分诊，并且只做低风险的快速见效项，最终交出一份书面的工程现状评估。第 31 到 60 天是规划与打基础：一张与业务目标挂钩的技术路线图、一份招聘计划、一套交付节奏、基础工程指标，并修复排名前一到两位的风险。第 61 到 90 天是执行并做好交接准备：通过新节奏交付一项成果，用风险和投资的语言向董事会汇报，并把组织调整到无需 CTO 每天在场也能运转。兼职 CTO 的价值不在于成为屋子里技术最聪明的人。它在于一套交付物和一个仍在运转的系统，能在他离开之后留存下来。 这是执行计划。关于究竟要不要聘请，以及成本如何，请参阅 [何时在奥地利聘请兼职 CTO](/zh/blog/fractional-cto-when-to-hire-austria/) 以及 [日费拆解](/zh/blog/fractional-cto-austria-day-rates/) 。本文回答下一个问题：现在人已经在公司里了，接下来会发生什么。 ## 塑造这 90 天的那条原则 一位新任技术负责人能犯的最大错误，就是在还没有可用替代方案之前，就拆毁现有的执行体系。一家能交付的初创公司，哪怕做得乱糟糟，也比一家在重组中途被冻结的公司更有价值。因此这个计划把理解前置、把变革后置。第一个月主要是倾听；真正的变革，只有在负责人真正理解了这地方如何运转之后才开始。 ## 第 0 到 30 天：评估与稳定 这里的模式是海绵，而不是推土机。与每个人一对一交谈（在少于 30 人的团队里，就是字面意义上的每个人），并问两个问题：你会改什么，以及什么东西运转得太好、我们绝不能弄坏。跟随真实工作：坐下来看支持工单，观察一次事故，并亲自交付一处微小改动以感受部署流水线。同时进行一轮风险分诊，它会成为第一份交付物：安全、单点故障、关键人物与公交因素风险、基础设施成本以及交付瓶颈。只采纳低风险且可逆的快速见效项，那种能赢得信任而不押上公司的项。 一位优秀的兼职 CTO 在第一个月里会刻意不做的事：不重写、不重组、不大改流程、不裁员，唯一的例外是真实的安全或安全隐患威胁。在第二周就提议从零重写的人，向您展示的是一个危险信号，而不是领导力。 ## 第 31 到 60 天：规划与打基础 现在变革开始了，但要以有边界的实验进行，而不是一次性大爆发。最多推进一到两项限定时长的改动，以免团队不堪重负。产出经过优先级排序的技术路线图，把工程工作与资金跑道和产品目标绑在一起。如果需要招聘，就为最多几个关键岗位写一份聚焦的计划，因为招聘每个岗位都有固定开销，十个空缺职位本身就是一种失败。建立交付节奏：冲刺、站会、代码评审，以及清晰的完成定义。搭建起基础工程指标（四项 DORA 指标是惯常的起点）。并修复风险清单中排名前一到两位的风险，过程中把架构与供应商决策记录为 decision records。 ## 第 61 到 90 天：执行并做好交接准备 通过新节奏交付一项真实成果，让变革得到证明，而不只是被宣布。建立一份对创始人或董事会的定期汇报，用董事会真正会思考的两种货币说话：风险和投资，而不是故事点。最终敲定 decision records 和 runbook。并做好那件定义兼职合作的事：把组织调整到无需 CTO 每天在场也能运转。第 90 天有一个有用的自测：你能否说出团队中每个人各自的独特之处；如果不能，说明你没有进行过正确的对话。最后，把成功指标以及那个会告诉你"该聘请全职 CTO 了"的触发条件写下来。 ## 一位优秀的兼职 CTO 留下的交付物 这就是真正的合作与昂贵的 Slack 存在感之间的区别。要把这些都要到手。 | 交付物 | 它是什么，以及你为什么想要它 | | --- | --- | | 工程现状评估 | 倾听一轮之后对技术、团队、交付与风险的一份书面审查。你诚实的起点基线。 | | 风险清单 | 一份有名有主、附带可能性、影响和缓解措施的风险列表。让关键人物风险变得可见，而不是隐性。 | | 技术路线图 | 工程工作按业务目标和资金跑道排序，使技术决策能回溯到结果。 | | Architecture decision records | 记录背景、决策及其后果的简短文档，让下一支团队知道为什么，而不只是知道做了什么。 | | 招聘计划 | 几个排好优先级的岗位，附带顺序和职位描述草稿，而不是一通乱撒的空缺职位。 | | 交付流程文档 | 冲刺、站会、代码评审和完成定义，写成文字，让节奏比 CTO 留存得更久。 | | 董事会技术报告 | 一份以风险和投资语言呈现的定期更新，创始人可以拿去给投资人看。 | | Runbook | 逐步的运维与事故处理流程。一份有文档的操作手册比临场发挥能快得多地恢复服务。 | 一位给您留下一支能运转的团队和这些文档的兼职 CTO，算是把工作做完了。只给您留下感觉和一段聊天记录的，则没有。 ## 如何衡量他们，以及反指标 用四项 DORA 指标衡量交付的可预测性（部署频率、变更前置时间、变更失败率，以及服务恢复时间）、从清单中关闭的风险数量、把团队速度和士气作为趋势而非绝对值来看、对照计划完成的招聘岗位，以及最被低估的一项：创始人腾出了多少时间，因为创始人不再是每一个技术决策的升级路径。 不要衡量代码行数。它奖励数量而非价值，而删代码往往才是胜利。那位在一份生产力表格上填报"负 2,000 行代码"的 Lisa 工程师，把软件做得更快更小，他做得完全正确。并且要警惕那种计划是从零重写的 CTO；把能用的软件从零重写是经典的战略错误之一，因为读代码比写代码更难，而旧代码承载着多年来已修复的 bug。 ![Kevin Riedl](/img/team/kevin.webp) "聘请一位兼职 CTO，是为了让他按计划把自己变得不再被需要。交付物不是他出现在会议里。而是一支没有他也能交付的团队，以及那几份文档，让下一个人能从他停下的地方接着干。" ## 何时用全职聘用替换兼职 CTO 触发点是工程管理本身变成一份全职工作的时候。实际上，那大致是一个人再也无法把团队维持在健康管理幅度内的那个点，大约是八名或以上工程师的标线，以及有人每周超过一半的时间花在管理而非构建上的时候。再加上已越过 product-market fit、需要持续的每日执行，这就是把这个角色引入公司内部的信号。成本和时机我们在 [何时在奥地利聘请兼职 CTO](/zh/blog/fractional-cto-when-to-hire-austria/) 中有讲，所以这里的重点是交接，而不是算账。 把过渡当作缓慢的接力，而不是一刀两断。兼职 CTO 为自己的接替者撰写职位描述并甄选候选人，主持结构化的知识转移，并在交接系统的同时交接关于人的知识。这正是交付物发挥作用的地方：decision records、路线图和 runbook 就是交接包。新上任的全职 CTO 从第一天起就对决策负责，而兼职者退到顾问角色或彻底退出。 ## 奥地利视角 这种合作几乎总是企业对企业的固定聘约，而非雇佣，形式上是 freier Dienstvertrag（持续提供服务的自雇式服务合同）或普通的自雇合同以提供持续可用性，或在有单一具体交付物时采用 Werkvertrag（成果合同）。这使其免于工资税和雇佣义务，但必须构建得当以避免假自雇（Scheinselbstständigkeit），从而让 CTO 真正自行决定其时间和方式。资深工程师市场很紧俏，尤其在维也纳以外，填补一个资深岗位可能要花好几个月，这也是为什么一位同时还擅长招聘的负责人很有价值。一位优秀的负责人懂得资助版图：aws 的项目资助公司建设以及种子或成长期融资，而 FFG 资助真正的研究与开发。因此路线图及其文档应当构建得当，使研发工作能干净地映射到 FFG，而公司建设映射到 aws。这是一个具体的、桌面上真金白银的理由，说明文档纪律在这里为何重要。 ## 兼职、临时、全职，还是联合创始人？ 对于执行阶段，真正重要的区别很简单：临时是全职但有期限，兼职是非全职但持续。 | | 兼职 CTO | 临时 CTO | 全职 CTO | 技术联合创始人 | | --- | --- | --- | --- | --- | | 投入 | 非全职，持续 | 全职，固定期限 | 长期，全职 | 无限期，全职以上 | | 主要报酬形式 | 现金聘约，少量长期股权 | 现金 | 薪资加高管授予 | 股权 | | 执行阶段最佳契合 | 搭建系统和交付物，准备交接 | 危机或空缺补位（一次离职、一次扭转） | PMF 之后持续的每日执行 | 从第零天、产品之前就掌管技术 | 对于处于或刚好在 product-market fit 之前的早期初创公司，兼职 CTO 搭建可运转的系统；临时者补一个窟窿；而全职或联合创始人回答的是关于持久性和所有权的另一个问题。 我们的 [兼职 CTO 服务](/zh/services/fractional-cto/) 正是按上面这 90 天来执行，采用按周可取消的 retainer，投入的是两位创始人而不是一名外包。如果你缺的人更接近合伙人而非雇员， [兼职联合创始人](/zh/services/fractional-cofounder/) 这种形式回答的才是所有权问题。 [兼职 CTO 与临时 CTO 对比](/zh/compare/fractional-vs-interim-cto/) 把两者并排放在一起，而 [Polity](/zh/case-studies/polity/) 展示了合作结束后仍然留存下来的交付体系。 ## 常见问题 ### 兼职 CTO 在前 90 天做什么？ 评估与稳定（第 0 到 30 天）、规划与打基础（31 到 60）、然后交付新节奏的证明并准备一个可交接的组织（61 到 90）。目标是一个没有他也能运转的系统，而不是逞英雄。 ### 兼职 CTO 应该交付哪些交付物？ 一份工程现状评估、一份风险清单、一张技术路线图、architecture decision records、一份招聘计划、一份交付流程文档、一份董事会技术报告，以及一份 runbook。如果你得到的反而是感觉和一段聊天记录，那工作就没做完。 ### 兼职 CTO 在第一个月里不应该做什么？ 在理解这地方如何运转之前，不重写、不重组、不大改流程、不裁员。唯一值得立即行动的，是真实的安全或安全隐患威胁。 ### 我该如何衡量一位兼职 CTO？ 用四项 DORA 指标衡量交付可预测性、从清单中关闭的风险、把团队速度和士气作为趋势、对照计划完成的招聘岗位，以及创始人腾出了多少时间。不是代码行数。 ### 为什么代码行数是个糟糕的指标？ 它奖励数量而非价值，而删代码可能才是胜利。那位记下负 2,000 行代码、同时把软件做得更快更小的 Lisa 工程师做对了。 ### 我何时用全职聘用替换兼职 CTO？ 大致在工程管理变成一份全职工作的时候，约为八名或以上工程师需要每日管理、已越过 product-market fit、需要持续的每日执行。那就是该把这个角色引入公司内部的时候。 ### 我该如何干净地完成交接？ 当作缓慢的接力，而不是一刀两断。兼职 CTO 撰写职位描述、甄选候选人、主持结构化的知识转移，并交接关于人的知识加上整套交付物，而新上任的 CTO 从第一天起就对决策负责。 ### 兼职 CTO 和临时 CTO 的区别？ 临时是全职但有期限，用于危机或空缺补位。兼职是非全职但持续，用于搭建系统并准备过渡。不同的工具应对不同的情形。 ### 在奥地利如何与兼职 CTO 签约？ 通常是企业对企业的固定聘约，形式为 freier Dienstvertrag（自雇式服务合同）或自雇合同，而非雇佣，因此没有与工资相关的雇主成本。把它构建得当，让 CTO 自行决定其时间和方式，以避免假自雇（Scheinselbstständigkeit）。 ### 兼职 CTO 能帮上 aws 或 FFG 的资助吗？ 能。一位优秀的会把路线图和技术文档构建得当，使研究与开发工作映射到 FFG 资助、公司建设映射到 aws 的项目，从而让申请更可信。 ## 最终思考 一位兼职 CTO 的前 90 天，不是要成为屋子里最聪明的工程师。而是要在改动系统之前先理解它，修复真正威胁公司的风险，并留下一支能交付的团队和一套比这次合作存续得更久的文档。 评估与稳定，然后规划与打基础，然后执行并准备交接。用交付可预测性、关闭的风险和腾出的创始人时间来评判结果，永远不要用代码行数。做得好，这次合作就以组织无需 CTO 每天在场也能运转而告终，并附带一个清晰的触发条件，告诉你何时该聘请全职，这正是其全部意义所在。 ## 你可能也喜欢.. [**何时在奥地利聘请兼职 CTO** 关于兼职 CTO 何时胜过全职聘用的诚实算账，以及各阶段可预期的日费。](/zh/blog/fractional-cto-when-to-hire-austria/) [**兼职 CTO 对比临时 CTO** 临时是全职但有期限，兼职是非全职但持续。你的情形究竟需要哪一种。](/zh/compare/fractional-vs-interim-cto/) 分时领导 ## 继续浏览此集群 分时 CTO、CTPO 与 CPO 何时以及如何创造杠杆。 - [Fractional CTPO 对比 CTO 和 CPO](/zh/blog/fractional-ctpo-vs-fractional-cto-and-cpo/) - [Fractional CPO vs 资深 PM](/zh/blog/fractional-cpo-vs-product-manager/) - [什么时候招 Fractional CPO](/zh/blog/when-to-hire-fractional-cpo-austria/) - [奥地利 Fractional CTO 日费率](/zh/blog/fractional-cto-austria-day-rates/) - [何时 Fractional CTO 胜过招人](/zh/blog/fractional-cto-when-to-hire-austria/) 只收重要内容 ## 关注与你相关的内容 每当我们发布新文章，你会收到一封简短邮件。你可以关注整个博客，也可以只选感兴趣的主题。 [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 min 阅读 · 13 Jun 2026 [**下一篇**](/zh/blog/fractional-cto-when-to-hire-austria/) 邮件订阅新文章 × × 通过邮件获取新文章 我们发布时给你一封简短邮件。免费，不做跟踪。 ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/zh/blog/fractional-cto-30-60-90-day-plan/#webpage", "@type": "WebPage", "dateModified": "2026-07-07", "inLanguage": "zh", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-07-07", "url": "https://wavect.io/zh/blog/fractional-cto-30-60-90-day-plan/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "你已经聘请了一位兼职 CTO；前 90 天应当产出什么？第 0 到 30 天：评估与稳定（一轮倾听、跟随真实工作、风险分诊、只做低风险的快速见效项、一份书面工程现状评估，并且明确不重写、不重组、不裁员）。第 31 到 60 天：规划与打基础（一张与业务目标挂钩的技术路线图、一份招聘计划、一套交付节奏、基础工程指标、修复前一到两位的风险、把决策记录下来）。第 61 到 90 天：执行并做好交接准备（通过新节奏交付、用风险和投资的语言向董事会汇报、把组织调整到无需 CTO 每天在场也能运转、定义聘请全职的触发条件）。其价值在于能在他离开后留存的交付物和一个仍在运转的系统，而不是成为屋子里技术最聪明的人。", "articleBody": " 博客概览/领导力与团队/分时领导 面向奥地利初创公司的兼职 CTO 30/60/90 天计划 要点速览 你已经聘请了一位兼职 CTO；前 90 天应当产出什么？第 0 到 30 天：评估与稳定（一轮倾听、跟随真实工作、风险分诊、只做低风险的快速见效项、一份书面工程现状评估，并且明确不重写、不重组、不裁员）。第 31 到 60 天：规划与打基础（一张与业务目标挂钩的技术路线图、一份招聘计划、一套交付节奏、基础工程指标、修复前一到两位的风险、把决策记录下来）。第 61 到 90 天：执行并做好交接准备（通过新节奏交付、用风险和投资的语言向董事会汇报、把组织调整到无需 CTO 每天在场也能运转、定义聘请全职的触发条件）。其价值在于能在他离开后留存的交付物和一个仍在运转的系统，而不是成为屋子里技术最聪明的人。 您已经聘请了一位兼职 CTO。前 90 天究竟应当产出什么？第 0 到 30 天是评估与稳定：一轮倾听、跟随真实工作、风险分诊，并且只做低风险的快速见效项，最终交出一份书面的工程现状评估。第 31 到 60 天是规划与打基础：一张与业务目标挂钩的技术路线图、一份招聘计划、一套交付节奏、基础工程指标，并修复排名前一到两位的风险。第 61 到 90 天是执行并做好交接准备：通过新节奏交付一项成果，用风险和投资的语言向董事会汇报，并把组织调整到无需 CTO 每天在场也能运转。兼职 CTO 的价值不在于成为屋子里技术最聪明的人。它在于一套交付物和一个仍在运转的系统，能在他离开之后留存下来。 这是执行计划。关于究竟要不要聘请，以及成本如何，请参阅何时在奥地利聘请兼职 CTO以及日费拆解。本文回答下一个问题：现在人已经在公司里了，接下来会发生什么。 塑造这 90 天的那条原则 一位新任技术负责人能犯的最大错误，就是在还没有可用替代方案之前，就拆毁现有的执行体系。一家能交付的初创公司，哪怕做得乱糟糟，也比一家在重组中途被冻结的公司更有价值。因此这个计划把理解前置、把变革后置。第一个月主要是倾听；真正的变革，只有在负责人真正理解了这地方如何运转之后才开始。 第 0 到 30 天：评估与稳定 这里的模式是海绵，而不是推土机。与每个人一对一交谈（在少于 30 人的团队里，就是字面意义上的每个人），并问两个问题：你会改什么，以及什么东西运转得太好、我们绝不能弄坏。跟随真实工作：坐下来看支持工单，观察一次事故，并亲自交付一处微小改动以感受部署流水线。同时进行一轮风险分诊，它会成为第一份交付物：安全、单点故障、关键人物与公交因素风险、基础设施成本以及交付瓶颈。只采纳低风险且可逆的快速见效项，那种能赢得信任而不押上公司的项。 一位优秀的兼职 CTO 在第一个月里会刻意不做的事：不重写、不重组、不大改流程、不裁员，唯一的例外是真实的安全或安全隐患威胁。在第二周就提议从零重写的人，向您展示的是一个危险信号，而不是领导力。 第 31 到 60 天：规划与打基础 现在变革开始了，但要以有边界的实验进行，而不是一次性大爆发。最多推进一到两项限定时长的改动，以免团队不堪重负。产出经过优先级排序的技术路线图，把工程工作与资金跑道和产品目标绑在一起。如果需要招聘，就为最多几个关键岗位写一份聚焦的计划，因为招聘每个岗位都有固定开销，十个空缺职位本身就是一种失败。建立交付节奏：冲刺、站会、代码评审，以及清晰的完成定义。搭建起基础工程指标（四项 DORA 指标是惯常的起点）。并修复风险清单中排名前一到两位的风险，过程中把架构与供应商决策记录为 decision records。 第 61 到 90 天：执行并做好交接准备 通过新节奏交付一项真实成果，让变革得到证明，而不只是被宣布。建立一份对创始人或董事会的定期汇报，用董事会真正会思考的两种货币说话：风险和投资，而不是故事点。最终敲定 decision records 和 runbook。并做好那件定义兼职合作的事：把组织调整到无需 CTO 每天在场也能运转。第 90 天有一个有用的自测：你能否说出团队中每个人各自的独特之处；如果不能，说明你没有进行过正确的对话。最后，把成功指标以及那个会告诉你\"该聘请全职 CTO 了\"的触发条件写下来。 一位优秀的兼职 CTO 留下的交付物 这就是真正的合作与昂贵的 Slack 存在感之间的区别。要把这些都要到手。 交付物它是什么，以及你为什么想要它 工程现状评估倾听一轮之后对技术、团队、交付与风险的一份书面审查。你诚实的起点基线。 风险清单一份有名有主、附带可能性、影响和缓解措施的风险列表。让关键人物风险变得可见，而不是隐性。 技术路线图工程工作按业务目标和资金跑道排序，使技术决策能回溯到结果。 Architecture decision records记录背景、决策及其后果的简短文档，让下一支团队知道为什么，而不只是知道做了什么。 招聘计划几个排好优先级的岗位，附带顺序和职位描述草稿，而不是一通乱撒的空缺职位。 交付流程文档冲刺、站会、代码评审和完成定义，写成文字，让节奏比 CTO 留存得更久。 董事会技术报告一份以风险和投资语言呈现的定期更新，创始人可以拿去给投资人看。 Runbook逐步的运维与事故处理流程。一份有文档的操作手册比临场发挥能快得多地恢复服务。 一位给您留下一支能运转的团队和这些文档的兼职 CTO，算是把工作做完了。只给您留下感觉和一段聊天记录的，则没有。 如何衡量他们，以及反指标 用四项 DORA 指标衡量交付的可预测性（部署频率、变更前置时间、变更失败率，以及服务恢复时间）、从清单中关闭的风险数量、把团队速度和士气作为趋势而非绝对值来看、对照计划完成的招聘岗位，以及最被低估的一项：创始人腾出了多少时间，因为创始人不再是每一个技术决策的升级路径。 不要衡量代码行数。它奖励数量而非价值，而删代码往往才是胜利。那位在一份生产力表格上填报\"负 2,000 行代码\"的 Lisa 工程师，把软件做得更快更小，他做得完全正确。并且要警惕那种计划是从零重写的 CTO；把能用的软件从零重写是经典的战略错误之一，因为读代码比写代码更难，而旧代码承载着多年来已修复的 bug。 \"聘请一位兼职 CTO，是为了让他按计划把自己变得不再被需要。交付物不是他出现在会议里。而是一支没有他也能交付的团队，以及那几份文档，让下一个人能从他停下的地方接着干。\" 何时用全职聘用替换兼职 CTO 触发点是工程管理本身变成一份全职工作的时候。实际上，那大致是一个人再也无法把团队维持在健康管理幅度内的那个点，大约是八名或以上工程师的标线，以及有人每周超过一半的时间花在管理而非构建上的时候。再加上已越过 product-market fit、需要持续的每日执行，这就是把这个角色引入公司内部的信号。成本和时机我们在何时在奥地利聘请兼职 CTO中有讲，所以这里的重点是交接，而不是算账。 把过渡当作缓慢的接力，而不是一刀两断。兼职 CTO 为自己的接替者撰写职位描述并甄选候选人，主持结构化的知识转移，并在交接系统的同时交接关于人的知识。这正是交付物发挥作用的地方：decision records、路线图和 runbook 就是交接包。新上任的全职 CTO 从第一天起就对决策负责，而兼职者退到顾问角色或彻底退出。 奥地利视角 这种合作几乎总是企业对企业的固定聘约，而非雇佣，形式上是 freier Dienstvertrag（持续提供服务的自雇式服务合同）或普通的自雇合同以提供持续可用性，或在有单一具体交付物时采用 Werkvertrag（成果合同）。这使其免于工资税和雇佣义务，但必须构建得当以避免假自雇（Scheinselbstständigkeit），从而让 CTO 真正自行决定其时间和方式。资深工程师市场很紧俏，尤其在维也纳以外，填补一个资深岗位可能要花好几个月，这也是为什么一位同时还擅长招聘的负责人很有价值。一位优秀的负责人懂得资助版图：aws 的项目资助公司建设以及种子或成长期融资，而 FFG 资助真正的研究与开发。因此路线图及其文档应当构建得当，使研发工作能干净地映射到 FFG，而公司建设映射到 aws。这是一个具体的、桌面上真金白银的理由，说明文档纪律在这里为何重要。 兼职、临时、全职，还是联合创始人？ 对于执行阶段，真正重要的区别很简单：临时是全职但有期限，兼职是非全职但持续。 兼职 CTO临时 CTO全职 CTO技术联合创始人 投入非全职，持续全职，固定期限长期，全职无限期，全职以上 主要报酬形式现金聘约，少量长期股权现金薪资加高管授予股权 执行阶段最佳契合搭建系统和交付物，准备交接危机或空缺补位（一次离职、一次扭转）PMF 之后持续的每日执行从第零天、产品之前就掌管技术 对于处于或刚好在 product-market fit 之前的早期初创公司，兼职 CTO 搭建可运转的系统；临时者补一个窟窿；而全职或联合创始人回答的是关于持久性和所有权的另一个问题。 我们的兼职 CTO 服务正是按上面这 90 天来执行，采用按周可取消的 retainer，投入的是两位创始人而不是一名外包。如果你缺的人更接近合伙人而非雇员，兼职联合创始人这种形式回答的才是所有权问题。兼职 CTO 与临时 CTO 对比把两者并排放在一起，而 Polity 展示了合作结束后仍然留存下来的交付体系。 常见问题 兼职 CTO 在前 90 天做什么？ 评估与稳定（第 0 到 30 天）、规划与打基础（31 到 60）、然后交付新节奏的证明并准备一个可交接的组织（61 到 90）。目标是一个没有他也能运转的系统，而不是逞英雄。 兼职 CTO 应该交付哪些交付物？ 一份工程现状评估、一份风险清单、一张技术路线图、architecture decision records、一份招聘计划、一份交付流程文档、一份董事会技术报告，以及一份 runbook。如果你得到的反而是感觉和一段聊天记录，那工作就没做完。 兼职 CTO 在第一个月里不应该做什么？ 在理解这地方如何运转之前，不重写、不重组、不大改流程、不裁员。唯一值得立即行动的，是真实的安全或安全隐患威胁。 我该如何衡量一位兼职 CTO？ 用四项 DORA 指标衡量交付可预测性、从清单中关闭的风险、把团队速度和士气作为趋势、对照计划完成的招聘岗位，以及创始人腾出了多少时间。不是代码行数。 为什么代码行数是个糟糕的指标？ 它奖励数量而非价值，而删代码可能才是胜利。那位记下负 2,000 行代码、同时把软件做得更快更小的 Lisa 工程师做对了。 我何时用全职聘用替换兼职 CTO？ 大致在工程管理变成一份全职工作的时候，约为八名或以上工程师需要每日管理、已越过 product-market fit、需要持续的每日执行。那就是该把这个角色引入公司内部的时候。 我该如何干净地完成交接？ 当作缓慢的接力，而不是一刀两断。兼职 CTO 撰写职位描述、甄选候选人、主持结构化的知识转移，并交接关于人的知识加上整套交付物，而新上任的 CTO 从第一天起就对决策负责。 兼职 CTO 和临时 CTO 的区别？ 临时是全职但有期限，用于危机或空缺补位。兼职是非全职但持续，用于搭建系统并准备过渡。不同的工具应对不同的情形。 在奥地利如何与兼职 CTO 签约？ 通常是企业对企业的固定聘约，形式为 freier Dienstvertrag（自雇式服务合同）或自雇合同，而非雇佣，因此没有与工资相关的雇主成本。把它构建得当，让 CTO 自行决定其时间和方式，以避免假自雇（Scheinselbstständigkeit）。 兼职 CTO 能帮上 aws 或 FFG 的资助吗？ 能。一位优秀的会把路线图和技术文档构建得当，使研究与开发工作映射到 FFG 资助、公司建设映射到 aws 的项目，从而让申请更可信。 最终思考 一位兼职 CTO 的前 90 天，不是要成为屋子里最聪明的工程师。而是要在改动系统之前先理解它，修复真正威胁公司的风险，并留下一支能交付的团队和一套比这次合作存续得更久的文档。评估与稳定，然后规划与打基础，", "articleSection": "领导力", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "dateModified": "2026-07-07", "datePublished": "2026-06-13", "description": "你已经聘请了一位兼职 CTO；前 90 天应当产出什么？第 0 到 30 天：评估与稳定（一轮倾听、跟随真实工作、风险分诊、只做低风险的快速见效项、一份书面工程现状评估，并且明确不重写、不重组、不裁员）。第 31 到 60 天：规划与打基础（一张与业务目标挂钩的技术路线图、一份招聘计划、一套交付节奏、基础工程指标、修复前一到两位的风险、把决策记录下来）。第 61 到 90 天：执行并做好交接准备（通过新节奏交付、用风险和投资的语言向董事会汇报、把组织调整到无需 CTO 每天在场也能运转、定义聘请全职的触发条件）。其价值在于能在他离开后留存的交付物和一个仍在运转的系统，而不是成为屋子里技术最聪明的人。", "headline": "兼职 CTO：30/60/90 天计划", "image": "https://wavect.io/img/blog/headers/header_fractional-cto-30-60-90-day-plan.svg", "inLanguage": "zh", "mainEntityOfPage": { "@id": "https://wavect.io/zh/blog/fractional-cto-30-60-90-day-plan/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/zh/blog/fractional-cto-30-60-90-day-plan/", "wordCount": 339 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/zh/", "name": "首页", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/overview/", "name": "博客概览", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/topics/leadership-teams/", "name": "领导力与团队", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/clusters/fractional-leadership/", "name": "分时领导", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/fractional-cto-30-60-90-day-plan/", "name": "兼职 CTO 的 30/60/90 天计划 | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "评估与稳定（第 0 到 30 天）、规划与打基础（31 到 60）、然后交付新节奏的证明并准备一个可交接的组织（61 到 90）。目标是一个没有他也能运转的系统，而不是逞英雄。" }, "name": "兼职 CTO 在前 90 天做什么？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "一份工程现状评估、一份风险清单、一张技术路线图、architecture decision records、一份招聘计划、一份交付流程文档、一份董事会技术报告，以及一份 runbook。如果你得到的反而是感觉和一段聊天记录，那工作就没做完。" }, "name": "兼职 CTO 应该交付哪些交付物？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "在理解这地方如何运转之前，不重写、不重组、不大改流程、不裁员。唯一值得立即行动的，是真实的安全或安全隐患威胁。" }, "name": "兼职 CTO 在第一个月里不应该做什么？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "用四项 DORA 指标衡量交付可预测性、从清单中关闭的风险、把团队速度和士气作为趋势、对照计划完成的招聘岗位，以及创始人腾出了多少时间。不是代码行数。" }, "name": "我该如何衡量一位兼职 CTO？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "它奖励数量而非价值，而删代码可能才是胜利。那位记下负 2,000 行代码、同时把软件做得更快更小的 Lisa 工程师做对了。" }, "name": "为什么代码行数是个糟糕的指标？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "大致在工程管理变成一份全职工作的时候，约为八名或以上工程师需要每日管理、已越过 product-market fit、需要持续的每日执行。那就是该把这个角色引入公司内部的时候。" }, "name": "我何时用全职聘用替换兼职 CTO？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "当作缓慢的接力，而不是一刀两断。兼职 CTO 撰写职位描述、甄选候选人、主持结构化的知识转移，并交接关于人的知识加上整套交付物，而新上任的 CTO 从第一天起就对决策负责。" }, "name": "我该如何干净地完成交接？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "临时是全职但有期限，用于危机或空缺补位。兼职是非全职但持续，用于搭建系统并准备过渡。不同的工具应对不同的情形。" }, "name": "兼职 CTO 和临时 CTO 的区别？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "通常是企业对企业的固定聘约，形式为 freier Dienstvertrag（自雇式服务合同）或自雇合同，而非雇佣，因此没有与工资相关的雇主成本。把它构建得当，让 CTO 自行决定其时间和方式，以避免假自雇（Scheinselbstständigkeit）。" }, "name": "在奥地利如何与兼职 CTO 签约？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "能。一位优秀的会把路线图和技术文档构建得当，使研究与开发工作映射到 FFG 资助、公司建设映射到 aws 的项目，从而让申请更可信。" }, "name": "兼职 CTO 能帮上 aws 或 FFG 的资助吗？" } ] } ```