最近半年终于从零上线了一个公司内部的startup项目，领队专家能力很强，我个人也学到了很多，特此记录。

首先强调一下，我这里的startup并不是风投的创业项目，而是toB的企业内部项目。它立足于大公司平台，面向内外部客户提供企业向的SaaS服务。但是也不要觉得大公司就等于低效官僚，大公司内部更聪明、无底线的利己主义与模仿者很多，同样需要找到方向、组建团队，交付项目。假如项目失败，无论级别都将被淘汰掉。

本文面向读者：自己有3～5年技术经验，写够了CURD，希望自己能够设计落地方案的读者。本文关注点在实施流程，入门工程师与高级管理者可能收获不多。

本文虽然是2019的文章，但是后续仍有持续补充。

快速结论

如果不想读完本文，可以先看结论

• 方向与愿景：已经完成了从零到一的规划，找准典型场景，顶层设计方向要大致正确
• 需求：要明确语境，长/短期诉求，明确SaaS中产品/需求的定制界限
• 落地技术方案：要用拿来主义思维（购买或者开源项目）来节约时间，成熟度从40（POC）到60（MVP），再到100进行延展，不要开始就深入源码（ go spelunking through the source code）与高并发来证明你的技术
• 过程效率：能找人干活而不要自己全干，更要有高度成熟的DevOps/Agile/Meeting等经验框架来管理过程
• 团队组建与招聘：在起步阶段，要找比自己优秀的，有主动能力的（同样的成本，宁可要1.5能力 * 1人 而不是 1能力 * 2人），详见Management的Tag

上面每个决策失误都将消耗珍贵的起步时间作为学费

背景

本文不涉及的内容

下面这些难度超纲，我就不瞎写了，本文假设下面均已经搞定

• 本部门与Sponsor通过各种方式磋商(ROI价值分析/竞品/受益群体)，达成了要投资(人力/时间/采购/投资)的诉求与决策
• 部门级、公司级、平台级的宏观战略比较清晰
• 团队基本组建成型（Sponsor的客户也要有人全职跟踪与验收），组织有活力与执行力
• 项目节奏的把控，趋势/风口的追逐

再次强调，本文只是工程师维度的搬砖改良与效率压缩的记录，仍然是泰勒模式的践行，尚不能达到决策层。但是你就算是作为搬砖者，投入的也是珍贵的全职时间，要明白项目有啥用，PPT如何写

你所拥有的

• 上层提出的一个宏观模糊的，需要3到5年才能完成的目标
• 上层初步与客户对出的业务流程
• 运气好有几个人给你带，运气不好需要自己面试挖人组建团队，运气最差是连HC都没有

你需要做的

以下为项目开始只做一次的

• 验证上层战略是否可行
• 在上层讨论的基础上完善业务流程细节，画出包含细节的Workflow
• 制定技术方案选型、初步做出POC与MVP并演示汇报

以下为项目稳定后每个迭代的搬砖工作，只要有经验方法与良好的招聘流程就可以转为砸人天，可以看我以前的文章

• 挖掘客户需求，落地到平台需求
• 设计需技术方案细节，堆人上，并盯着编码人员不要走偏或瞎搞
• 招聘与学习型组织建设、处理求助、开会、AAR、DevOps、WIKI、JIRA等等…

参考流程

本文主要流程

本文与理论上的“软件工程”是不同的，而更加偏向于集成商的角色。更加推荐简化的MM（市场管理）流程或者IPD（集成产品开发）流程。

愿景与实施

愿景大致正确

格鲁夫曾经说过，在一个组织中，某管理层的战略/愿景，通常即是高他一层的经理人考虑的战术，而你作为执行者是负责实施上级战略的。

大前研一也曾经说过，做任何事情，都要以顾客的顾客为中心，所以你的技能不能只满足于编码或当包工头，而是让所有人都满意，因此你个人就算是只写CURD代码也要高看一层。

此外还有创造性张力, 格物致知, 形而上学等类似术语，我这里就不掉书袋了，这些属于都强调了最高方向的重要性。

以企业向IT项目为例

通过这种分析方法，可以把所有人的思路给连接起来，有了最高战略，我们才有共同目标，这样就可以引入方法论框架进行实施。上述过程在H公司叫做【对齐(Aligenment)】，一旦方向大致正确，就用超高的执行力实施。

如果你与其他人的理念不合适，那么就赶紧散伙。如果你自己都不认可所做的项目，我觉得还是换家公司吧。

方向错误会发生什么

假如客户无法自己想要什么，那么可能会把IT团队给累死，部门名声差了，后面就没人敢接这个部门的活了。这里是很常见的，有一本《管理咨询的神话》就专门介绍战略规划是多么愚蠢。

假如领导挖掘需求能力较弱/二传手，脑子里是浆糊，或者天天开会效率低，那么就算是CURD的业务，你也要996搬砖，万一项目搞砸了，就等着34岁被淘汰。这类市场观察与用户画像的能力可能是需要交学费的。

假如我对抽象领域的“externalization”能力较弱，软件架构能力差，那么要么996，要么走人。

当然这些话题扯远了，我这里主要还是想强调先方向、后方案、再实施。假如你是技术设计者，切忌上来就陷入代码细节、高可用与源码分析，这样你就把下面的实施人力给浪费了。

其他必要条件

除了方向正确外，还需要有强执行力、有活力的组织与技术视野确保成功开头，执行过程中需要有流程与经验支持，有了流程才能守破离，否则瞎搞会导致下面996加班/跑路。

现状分析

高层领导与客户交流是高纬度的战略，因此这种方案一般是需要2～3年才能彻底完成的项目，而下面干活的肯定不止你一个，因此你要把属于你的活给抽出来，自己搞一个思维树。

收集现象，对齐语境，建立符号的知识树

举个例子，我做的X项目中有大量的领域术语(terminology)缩写，甚至连中文资料都很少，你需要如下操作

• 通过搜索引擎了解符号缩写的深度与广度，甚至去参考术语相关的IT产品、商业产品是什么样
• 去图书馆等专门的知识渠道去过一遍知识，你不用完全读懂书，只要知道这个流程需要哪些步骤就可以了
• 将上述过程整理为Wiki/Gitbook，与客户再用术语对齐一遍，补充备注。

你在这个阶段是顾问的角色，将Wiki协同发布后，后面你就可以用这些符号与客户在同一个语境下交互了。

还原现象的细节(enrichment)

这里是隐性的，经验的，感性的，无法量化的知识，要用基于story的观察方式进行描述。本文这里主要使用了还原论作为框架

联系客户（1～2个人，不要拉一堆人），打开会议室的投影，打开绘图工具，然后采用问答的方式画业务总体流程图，举个例子

• 这一步从哪里开始，后面到哪，角色是X吗？如果失败将交给谁？
• 这里的交付件是什么，储存在什么地方？产出是否纳入版本管理？
• 这一步分出的4小步是什么，它们输出了什么？第三步挂了是否还接着走，如果挂了怎么定位？

这种会议将非常高效，因为你是主持人，场景补全后，将这些流程图共享，这就是第二阶段的成果。

我个人比较喜欢的两个场景工具进行分析（可以看我写的npm等绘图插件），一个基于亨普尔覆盖律，一个基于休谟的齐一律

• Work Breakdown Structure: 工作分解图，是广义的空间维度，基于功能的维度
• Timeline Diagram: 找出流程中所有的关系人，比如BPM，泳道图，基于连续时空与因果的维度

注意这里只是符号与概念，还没有到UI/Axure/User Journey等细节

这里一定是高阶方案，千万不要陷入细节、定义或者术语（约束范围）的争论

现象分析的验收

上述所有的现象分析一定是可证伪的客观结论，一定要与用户达成一致再进行设计

• 所有场景需要用MECE的方法进行枚举
• 用户的“我想要/我认为”是主观的需求，暂时不在这里处理

产品设计

设计产品Feature的WBS

设计一个超大的菜单，并将上述场景承载录入到菜单层次中。此处暂时可以不用原型图，偷懒可以用Excel等工具画一个即可，再次强调不要上来就用UX工具或者UML进行DB建模。

• 明确各个菜单与业务的一对多，多对多的关系，最好能直接写好前台的录入URL
• 明确数据主题的资源与权限的颗粒度

这样就可以开始写Demo去忽悠客户了

设计POC(可行性验证)提案

（此操作可以与上一个任务并行执行）

技术方案需要拿来主义，可以网上查商业与开源方案，买Cookbook，甚至花钱找顾问的经验/招聘比你强的人。至于说如何设计好的架构，由于需要视野积累与业务场景，本文不多讲，但是最终汇报材料至少如下

• 背景与ROI，业界ABCD公司的方案与度量标准，现状的不足
• 高阶应用方案：需要有证据链，展示要有场景层，业务层（承载了什么业务）与技术基座。也可以考虑外购软件。
• 技术可行性：科普性质的技术解释，需要有网络部署图和工时初估（精确到月）。
• 规划下次会议需要演示的交付件与开发计划，赶紧把搬砖的活给分下去

这些搞定了，再与领导对一遍，然后再搞，架构方案是可以调整的，但是主要方向不能改。

源码分析/技术视野应该在轻松业余时间完成，上班时很难集中精力去搞，如果你的代码读的少，那么设计架构明显会很吃力，看源码逆向固然快，但是你的一天时间也被耗没了。如果招聘招的准，这一步就快。

POC与验证(Try Run)

这里你真的就要开始编码了，还是先不要急着看源码，建议先看各个框架官方的架构文档。

• 按照技术方案，从入门到精通搭起来跑一下
• 哪些场景痛点解决了，哪些没解决，需要怎么改？
• 尝试编写部分代码，但是不要整个时间耗进去

把Demo报上去给客户看看，根据客户的意见补充改进，直到最终客户拍版同意实施正式开发。

此处用户会提出很多诉求，但是你本人当前时间非常珍贵，不要耗到细节中，也不要这么早当用户的客服，否则其它的就没法做了，进而影响总体功能。
另外，只用找几个客户补充验证场景即可，不要盲目扩展多个客户，否则你的人力也会被耗完
最后，要识别种子客户，明确“诉求”与“诉求的实现”的区别，你做的是SaaS产品，而不是定制外包，诉求实现的决策权在你这里

POC过程中，用户也会提出一些需求，但是作为SE，一定要平衡长期与短期诉求，定制与通用诉求，它们的投入产出是不一样的。任何情况下，都要考虑SaaS化。比如用户短期想马上用，你可以给一个简陋的版本，但是还是不要耗进去了。不要在这里直接否定用户，而是说”先评估下“婉拒；不与用户讨论底层实现，只讨论最终要求。

build an impressive proof of concept to take to later stage investors to raise more money.

准备Demo Day的POC汇报

一般来说，假如你是纯技术SE，一般是不需参与撰写这种Slider，但是没人的话就只有你来干了。可以参考各大公司的招股说明书，比如这里，或者参考顶级的Y combinator的标准。这个是有极高难度的，对于纯技术人员来说并不擅长。

设计落地方案(with gap)

当可行性ok后，也就是已经上一版本后，那么就要进行真正的设计了。

PAAS层: 尽可能快，使用厂商中立且廉价的云原生方案，亦可搭建私有云，这里是要求广度高于深度。

• 预估出计算资源、网络（时延/带宽/网关/命名服务）、存储、备份容灾
• 命名服务/滚动升级/蓝绿发布
• 系统部署架构图，明确好region/datacenter层次的方案，是否需要跨WAN的强一致性
• Telemetry：运维/监控/日志可视化/弹性伸缩

技术承载层: 指SpringBoot/Rails等开源框架的选型

• 初期版本尽可能采用low-code、动态语言与中立的SaaS服务提高上线速度
• 开源与第三方软件的连续性与法律合规问题
• 内网是否需要强一致性？哪些地方有锁？哪些地方持久化？

SAAS层

• 分片与多租户定制方案
• 用户/群组/ACL等Authz方案，IAM等Authn方案，SOD权责分离方案
• 基线与定制是否分离清晰

业务Portal层

• 按照覆盖律与因果律两个维度进行设计，先不要引入复杂的交互结构
• 合理安排定制与基线的分离点，参考GraphQL等Low-code方案
• 自测场景用例
• BI与运营工具，注意toB产品工具属性强，讲究场景覆盖率，用户量起初并不重要

CICD：由于当前开发人数过少，更需要自动化

• 需要基于上述的基础方案与应用路由方案，提高自动化率
• 设计时就要考虑二进制的可回溯性，实现可审计的源码交付

SaaS项目的主要难点是在于挖掘场景(The Challenge, the solution)，并提前克服墨菲定律进行枚举分解，而不是多个问题混在一起，也不要被短期诉求/条件所限制（你先出方案，再找上级解决限制问题）。

这里推荐使用PERT图来绘制依赖关系（详见UML），依赖清楚后，把任务按照1～2天的颗粒放到总backlog里面，然后与领导讨论哪些功能先上，最终整理出一个MVP迭代计划。

这时可以开始用专业的DevOps工具导入项目，比如Azure DevOps就可以从持续集成到需求管理全部帮你搞定。

拆解一定要按照功能需求-技术实现-实施细节-度量标准的维度进行拆解，而不是用技术-功能-实施来拆解，否则项目会遗漏。

启动MVP(minimum viable product)项目

此处是最小可行版本，也就是短期诉求，我们可以先搞两个月，然后用较少的用户去试点业务流程

• 开始找更多用户进行推广（自上而下/自下而上）
• 功能与壳优先，尽可能将问题转化为供应链问题，去采购服务，先只考虑低并发/单DC的方案
• 就算是第一版也要要有运营方案，再差也要有统计方法（需要导入开源BI工具）
• 通过技术/运营手段控制总人数，但是业务流程POC的覆盖面要广

Portal场景要贴身定制，打包整理为"解决方案"，并找客户使用，企业客户使用后一般会内部汇报，再由上级一层层下发使用。这种官僚流程与toC场景也极不一样。

无论你是对内IT，还是天使轮项目，都有竞争者，MVP的目标始终是通过最快试运行的运营结果获得决策者的认可，要求始终是快速出产品（quick win/Leads to Cash），而不是高并发微服务等技术细节(Buy don’t build)。

我在这个位置就再次陷入源码分析与高可用细节了，导致投入耗费了一周。startup项目是绝对不适合应届生的，根本没有时间去培训

扩张与推广

这里是一切痛苦与团队矛盾的开始

偿还技术债务

有了POC与MVP的案例，后续推广与开发就方便多了，基本上堆人就可以搞定很多事情。

• 偿还QuickWin带来的技术债务（比如CICD/运维/日志/代码质量等来不及做的基础设施）
• 偿还Demo中残缺的部分，Demo吹完后，需要作为核心场景被大量使用了
• 确保核心代码稳定，补充完善稳定模块的测试用例，这样后续才有机会重构
• 投入较多时间去搞招人挖人培训赋能

特性开发与维护成本比可能是1:3，最后的10%进展非常慢，ROI也低，它们一不小心就会拖垮项目的人力。同时，也不要为了100%无债务而降低RD速度，技术债务只是可控负债而已，决策在你身上。

此处如果需要从软件工程理论角度也能进行度量分析，可以参考CMMI模型（CMMI本质也是泰勒制）

扩张节奏

后续工作主要就是一个迭代一个迭代的做场景，MVP，再按照敏捷（不管是真假敏捷，反正就是要搞定）等流程拆解与完成。场景挖掘、项目扩张都是相当复杂的问题，也是SaaS降低成本的关键因素。核心就是用调研出的通用场景来满足大量用户需求，降低定制是核心。

在扩张过程中，有如下的时间分配与节奏最难把握

• 形成项目的惯性（高语境），降低沟通与入门成本，团结组织
• 老场景与体验问题的打磨、跟踪、细化时间
• 新场景的挖掘与RD开发时间
• 当前用户的支撑、客户

你作为Owner，这时就不得不…加班了，这个与我的不加班信念抵触。要解决这些问题，就必须要有估算时间与预测成本的能力，并防止力量碎片化，然后找人、要人、培训与搬砖。

本文只是记录搬砖的，所以关于"节奏"控制就不多指导了，因为这个的确需要一个经验丰富的指挥官。

自己不能控制的，优先推动做；尽可能不要亲自部署

附录

总结与困难

通篇下来，我觉得在搬砖中，重要性依次如下

• 招人：招聘中短短的几小时很难分辨出水平，最重要的“认知水平（认识事物的方法）”，而且voice only的面试会丢失很多互动细节。
• 场景：认知洞察toB场景（需要有本体论、认识论的框架）
• 推广：SaaS产品受众面很窄，打广告效率很低，小团队就靠口口相传了，读者可以研究下各种创业公司的首页菜单。
• 技术：其实很多项目都很难达到技术门槛，而属于模式创新，初期建议用quick win/买买买的方案来实现

时间管理

有一个优秀经验的领导带你工作，的确可以帮助你少走很多弯路，节省很多时间。优秀的领导每天的工作时间分配的很棒，列举如下

• 借助公司流程获取资源
• 与领域客户讨论需求，与高端顾问讨论技术方案，撰写方案
• 指引执行层，防止“瞎搞”，比如我以前做代码很容易陷入细节与源码中，领导会及时纠偏

这样可以放大自己时间的效率，把工作外包化/自动化，基本上不会有浪费。

不足

上述方案讲得基本是就是泰勒理论的生搬硬套，目前来说还是有作用的，但是缺点也很明显

• 上述时间只要有压缩，你的技术深度就会降低
• 做任何事情都很保守，按照模版搞，拆解的很细，很容易陷入概念的细节
• 做事情的节奏比较依赖上层判断，限制了自己的思维，当然也很难出错
• 万一没有Plan B，心里就会慌
• 同事间缺少“被关注感”，所有人都陷在流程中如同机械一般

总的来说，这套方法在大型搬砖组织作为中高级螺丝钉是足够的，但是在小型组织中是不够灵活的，希望后期能够做到守破离，实现更佳的方法。

参考

• https://jrott.com/posts/why-buy/
• http://paulgraham.com/articles.html