我把大厂那套搬到创业公司，各种水土不服
前阵子带团队，踩过一个挺典型的坑：我把上一家大厂里跑得还不错的一整套研发流程，原封不动搬到了创业公司。
我当时还挺有信心的，心想这些东西我都实战过，也验证过，怎么都不至于太差。结果三个月不到，团队效率没上去，情绪先下来了。大家活没少干，但整个人的状态都不对，流程像套在身上的一层壳，怎么动都别扭。
后来我才慢慢意识到一个事：流程这东西，不是越完整越高级，也不是越像大厂越专业，关键是合不合适。
上家公司是成熟中大厂，我们事业部有10个小组左右，通常8 到 9 个人的小组，角色配置相对完整，很多事情都有前提条件托着，标准敏捷那一套跑起来问题不大，比如我带的团队有9个人比现在创业公司带的人还多，工作得比较顺畅，所以我天然认为那套东西是好用的。可创业公司不是这个环境。人少、事杂、变化快，今天定的东西，明天可能就要推翻。这个时候你还想把流程铺得很满，最后大概率不是提效，而是添堵。
下面说几个我自己踩得比较实在的坑。
1. Jira 看板搞得太细，最后大家都在伺候看板
刚开始我把 Jira 也上了，而且沿用了上家公司那种拆法。一个需求要拆到设计、开发、测试、联调，最好还能估到小时，状态流转也尽量完整。
这套东西放在稳定一些的环境里，是有价值的。因为团队规模一大，协作链路一长，你不把信息结构化，很多事情就会乱。
当时我脑子里想的，其实差不多就是下面这种模式。一个板子看起来很清楚，列、卡片、负责人、状态，一眼望过去特别“专业”。
Jira 官方看板示意，来源：Atlassian。
但创业公司不是这么回事。
创业公司最常见的情况是，需求今天这么说，明天又换了；老板上午说先做 A，下午看了竞品又觉得 B 更重要。这个时候看板刚整理清楚，内容就过时了。大家不是在推进任务，而是在不停维护任务卡片，补字段、改状态、对齐口径。
慢慢地，团队开始烦这个东西。那种烦不是嘴上抱怨两句，而是你能明显感觉到，大家觉得在做无用功。
后来我们直接砍掉了这套细颗粒度管理，不再盯单个任务拆得多漂亮，只保留一个比较轻的整体节奏视图，主要看大的节点和关键事项。说白了，就是别再折腾一堆“过程看起来很美”的卡片，先把人从流程里解放出来。
我们后面实际落地的方式，反而很土：一张每日跟踪表，再配一张整体计划表。没有那么多状态流转，也没有那么多字段，但它足够直观，够我们这个阶段用。
这里先放两张我们当时真实在用的图（来源于产品负责人）：
改完以后，大家最直接的反馈不是“这个流程真先进”，而是终于不用天天填东西了。听着很朴素，但这往往说明方向对了。人重新把精力放回到做事本身，效率反而起来了。
2. 详设模板很完整，但完整本身就是负担
我以前的公司，详细设计是比较重视的，而且也确实有它的价值。系统复杂、协作方多、生命周期长，前面多花点时间把设计做扎实，后面能省不少事。
所以到了创业公司，我也想把这个习惯延续下来，要求大家按比较完整的详设模板来。虽然我知道不能照搬原来公司的但是我想着先试着暴露问题再调，
果然问题很快就出来了。
- 团队成员几乎都没有正儿八经的写过详设，可能是在如今的软件开发，大家完全摒弃或者看不上很多年前的研发流程，所以不重视也不愿意接触。（但是经验告诉我存在既合理，你可以改进单不能完全否定，至少对我来说详设是让你想清楚你要做什么怎么做的过程，其实并不冲突）
- 创业公司讲究的是快速验证，你先得证明这个东西值不值得做、能不能跑通、市场买不买单。有些模块的生命周期可能很短，有些模块就是很简单的CRUD。这个时候还要求每个需求都搞一份“大而全”的详设，性价比很低。
后来我的调整是，只保留重难点设计。
也就是说，不是不要设计，而是只在真正有必要的地方认真写。比如复杂流程、核心链路、容易出事故的地方，这些该写还是得写，而且要写清楚。至于那些简单页面、普通接口、试验性质的功能，就没必要搞得那么正式，很多时候口头对齐一下，加上关键点同步，也就够了。
模板也顺手砍掉了大半，能简就简。并比如只保留异常处理、数据库设计、关键算法、外部引入说明等章节。
这么改完以后，大家不会因为“要交一份文档”才去写东西，而是因为“这里确实需要想清楚”才写。这个差别挺大。前者容易把写文档变成任务，后者才更接近设计本身。
3. UI 评审流程太正式，节奏根本跟不上
我一开始还认真搭了 UI 评审流程，想着把产品、UI、前端这些角色都拉齐，尽量在正式评审里把问题消化掉。
这个思路本身没错。问题还是那个问题，环境不对。
创业公司很多时候拼的不是“流程是否完备”，而是“反应够不够快”。有时候你这边还在约会、准备材料、等人齐，外面竞品已经上线了。等你一轮会开完，讨论很充分，市场窗口也差不多过去了。
后来我就把这件事彻底做轻了。
多数情况下，前端和 UI 直接碰一下；如果产品逻辑也有争议，就三个人凑一起，当场对齐。能站着说完就别拉长会，能今天拍板就别拖到明天。先把主要分歧解决掉，剩下的小问题边做边收。
这样做当然没那么“规范”，但更符合创业公司的现实。
很多流程设计，表面上是在降低风险，实际上是在用确定性对冲不确定性。可创业公司真正的问题往往不是“讨论不够充分”，而是“动作不够快”。这时候流程越重，可能越错。
4. Sprint 很标准，但标准得有点不合时宜
我之前也试着在创业公司推标准 Sprint，单周也好，双周也好，站会、估时、回顾这些动作都想带起来。
现在回头看，方向有点想当然了。
标准 Sprint 背后有个很重要的前提，就是需求相对稳定，或者至少在一个迭代周期内，不要被打断得太厉害。这样团队才能围绕承诺来组织协作，节奏也才跑得顺。
可创业公司常常不是这种节奏。业务方今天提一个需求，明天就要看结果；线上出了点情况，当前优先级立刻变化；老板临时看到了一个机会，整个排期可能都要让路。
在这种情况下，固定迭代周期很容易从“管理工具”变成“现实阻力”。
你会发现团队嘴上还在讲 Sprint，实际上天天都在被插单。于是形式上很完整，执行上很别扭，大家最后既没享受到 Sprint 的好处，还多了一层心理负担。
后来我就不硬推固定迭代了，更偏向流动式开发。优先保证关键事情快速流过来、快速被处理掉，而不是先想办法把所有事情塞进一个看起来工整的周期里。
说白了，就是别为了流程的完整感，牺牲交付的真实节奏。
5. 工时估得越细，大家越焦虑
还有一个坑也挺常见，就是工时评估。
大厂里很多时候要做资源管理、项目协同、跨团队承诺，所以你会比较强调估时，甚至希望大家估得尽量准一些。这在某些环境下有它的合理性。
但在创业公司里，很多需求本身就带着不确定性。你连边界都没完全看清，非要提前精确承诺到某个点，最后大概率是两头难受。
一头是管理者以为自己拿到了确定性，另一头是执行的人背着一个并不靠谱的 deadline，越做越紧张。
尤其是一些复杂问题，真正难的地方往往在做之前并不能完全看出来。你要求团队给一个很精确的工时，看起来是在做计划，实际上可能是在制造幻觉。
后来我不再盯精确工时，而是更多给出一个大致时间窗口。该说明风险就说明风险，该留缓冲就留缓冲，不再逼着大家把很多本来就估不准的事情说得特别肯定。
结果挺有意思，精确度没那么好看了，但交付反而更可预期了，团队状态也轻松不少。
后来我真正想明白的几件事
1. 创业公司不是大厂缩小版
这个是最核心的一条。
很多人从大厂出来，容易有个潜意识：创业公司只是规模小一点，很多管理动作做轻一点就行了。
其实不是。
这两种组织在很多底层逻辑上都不一样。大厂更多追求稳定、可复制、可预测，流程是拿来放大协作效率、控制系统风险的。创业公司很多时候追求的是快速试错、快速验证、快速调整，它首先得活下来，然后才谈得上优化。
所以你不能简单理解成，大厂那套减配一下就能直接用。
2. 研发天然就不喜欢太重的文字工作
这个事挺现实的，但很多管理动作设计的时候经常假装看不见。
大多数研发真没那么喜欢填表、写一堆过程文档、反复同步那些价值不高的信息。不是因为懒，而是因为他们天然更愿意把注意力放在解决问题、写代码、做实现上。
所以减少无效文档，并不只是为了省时间，本质上也是一种尊重。你尊重一个岗位的工作重心，团队的配合度通常就会高很多。
当然，这不是说文档没用。我的意思只是，别把“有文档”当成默认正确，而是先想清楚，这份东西到底帮了谁，解决了什么问题，值不值得花这个成本。
3. 灵活不等于混乱，底线还是要有
创业公司不适合重流程，不代表什么都可以不要。
有些底线是不能退的，比如代码规范、版本管理、发布安全、线上稳定性这些东西。这些不是“有空再说”的选项，而是基本盘。没有这些，所谓灵活很容易滑成混乱，最后大家都在救火。
我现在更认同的一种状态是：在底线之上尽量灵活。
该守住的东西守住，剩下的就别绑太死。不要一边嘴上说着创业公司要快，一边又把团队拴进一堆并不适合当下阶段的流程里。
什么阶段适合什么模式
如果是成熟一些的中大型团队，人员配置完整，协作链条长，项目复杂度也高，那标准化流程通常是有收益的。它能提升协作效率，也能降低很多因为人多而带来的不确定性。
但如果是小型创业团队，尤其是不到 10 个人的研发团队，我现在的看法会很明确：怎么灵活怎么来，但底线要守住。
不是不要流程，而是只保留那些真正帮你提效的流程。凡是已经开始明显拖慢节奏、压坏情绪、制造无意义劳动的东西，就该果断砍。
最后的话
流程是手段，不是目的。
以前我总觉得，一个团队越专业，流程应该越完整。后来才发现，不是这么回事。真正成熟的团队，不是流程堆得最满的团队，而是知道什么该坚持，什么该省掉，什么阶段该用什么方法的团队。
说得再直白一点，创业公司最怕的不是“不够像大厂”，而是明明身子还很轻，却非要背上一整套大厂的装备。
那玩意儿穿在大厂身上可能是铠甲，穿在创业公司身上，很多时候就是负重。