IT研发外包团队是不是真的在搞敏捷？一个老PM的碎碎念
这个问题，我太有发言权了。从十几年前在甲方天天跟外包团队“死磕”，到后来自己也带外包团队做项目，我见过的敏捷站会，比我喝过的咖啡还多。每次有人问我，“外包团队到底适不适合做敏捷？他们每天开站会吗？” 我脑子里总是能瞬间浮现出好几个团队的影子，有的在飞速迭代，有的……简直是在演戏，为了站会而站会。
所以，这事儿吧，真不是一句“是”或“不是”就能说清楚的。它更像一个复杂的化学反应，底料是甲乙方关系，催化剂是项目类型，温度是团队成熟度。任何一个变量不对，最后出来的味儿就全变了。咱们今天不扯那些高大上的理论，就聊聊我亲眼见过、亲身经历的那些事儿。
理想与现实的距离
先说说最理想的情况。什么样的外包团队能用好敏捷？答案往往出乎意料：它不像个“外包团队”，更像一个公司内部的延伸。
我接触过一个做底层算法的外包团队，老大是甲方公司出去的资深技术专家。他们和甲方的内部研发团队混编在一起办公，甚至工位都是打乱的。每天早上9点半，所有人，不管是甲方员工还是外包员工，都会围到一个大白板前。
那不是一场尴尬的、冷冰冰的站会。没人像报户口一样干巴巴地说“我昨天干了啥，今天打算干啥”，更没人把站会当成汇报工作的审判台。大家聊的是具体的 blocker（阻碍）。一个同事可能会皱着眉说：“我昨天配环境，发现编译脚本有个库的版本对不上，卡了半天，谁知道这个依赖的正确版本是哪个？” 马上就会有另一个同事接话：“哦，那个是王工之前改过，你用我们内部那个镜像源才行。”
你看，这才是敏捷站会的精髓——解决问题，同步信息。在这个例子里，外包团队和甲方团队之间几乎没有墙，信息流动非常快。他们的敏捷是真敏捷，站会是真站会，因为环境土壤是合适的。这种模式下的外包，本质上就是人员外包，但协作内包。
但，这是金字塔尖，是理想态。现实中，绝大多数外包团队面临的，是下面这些更普遍的困境。
为什么很多外包团队的敏捷是“样子货”？
当你听到一个外包团队的PM（项目经理）胸脯拍得山响，说“我们团队绝对敏捷，天天开站会”，你心里最好打个问号。因为很多时候，这只是一种姿态，一种为了迎合甲方要求的“流程正确”。
我曾经负责过一个电商项目，外包给了一家号称“敏捷经验丰富”的团队。合同里白纸黑字写着“采用Scrum框架，每日站会”。行，听起来很正规。
第一天站会，我就觉得不对劲。
九点钟，会议室里大家准时坐下，但气氛很沉闷。团队负责人打开一个Excel表格，开始点名。轮到每个开发，就像是小学生被老师抽查作业。
“小张，昨天任务进度怎么样？完成了几个story point？”
“完成了3个，今天计划再做2个。”
“小李，你那个模块怎么还没做完？昨天不是说好了吗？”
小李有点尴尬：“那个需求有点模糊，我跟甲方产品经理确认了一下，还没得到回复。”
负责人眉头一皱：“下次注意！不要自己干等，要主动推！”
整个过程10分钟，全是这种自上而下的工作汇报。我在旁边看着，哭笑不得。这哪是Scrum站会？这分明是古代的晨会，是查岗，是压实担子。
这种“站会”的目的根本不是为了暴露问题、寻求帮助，恰恰相反，它是为了确保进度可控、责任到人。一个开发如果老实地在会上说“我遇到了一个阻碍，可能今天解决不了”，他面临的是项目经理的压力和甲方的质疑。久而久之，谁还敢说真话？大家的策略就是报喜不报忧，把问题藏着掖着，实在藏不住了再说。
这就是外包团队敏捷的第一个死结：信任的缺失，导致了信息的扭曲。外包团队普遍有一种“乙方心态”，他们担心暴露问题会显得自己无能，会影响项目验收，甚至会影响尾款的结算。所以，他们宁愿加班加点自己扛，也不愿在公开的站会上把阻碍摆出来。站会的初衷，那个“寻求帮助”的核心价值，就这么被磨没了。
三个角色的“罗生门”
在一个敏捷项目里，通常有三个核心角色：Product Owner（产品负责人）、Scrum Master（敏捷教练）和开发团队。在理想的内部团队里，这三个角色是紧密协作的。但在外包场景下，这三者往往是割裂的，甚至是对立的。
你可以想象一个典型的场景：
-
甲方产品经理 (PO角色)：他掌握着需求的最终解释权，但他可能同时负责好几个项目，忙得脚不沾地。他对“敏捷”的理解，可能就是“快速响应变更”，今天提个想法，明天就想看到原型。他很少有时间去参加外包团队的每日站会，更别提定期的迭代规划会了。
-
外包团队项目经理 (SM角色)：他的核心KPI是项目按时交付、不超预算。他最大的愿望是需求稳定、范围清晰。面对甲方频繁的需求变更，他内心是抗拒的，因为这会打乱他的排期计划，增加团队的交付风险。他的“敏捷”往往更偏向于瀑布流的微缩版，叫“小步快跑的瀑布”可能更准确。
-
外包团队的开发人员：他们夹在中间，最是难受。一方面要应付甲方PO天马行空的想法，另一方面要承受项目经理的交付压力。他们的真实工作状态，可能是在赶工期、修复一堆由于需求不明确导致的Bug。
当PO在会上说“这个功能我们下个迭代要加进去”时，外包项目经理心里想的是“我的天，这得延期多少天，成本怎么算？” 而开发人员心里想的是“这东西跟现有架构冲突啊，上次不是说好不做了吗？”
每日站会，在这种复杂的权力结构下，就成了一种微妙的博弈。它不再是团队同步进度的工具，而是变成了甲乙双方互相试探、互相施压的场所。项目经理通过站会向甲方展示“我们很努力，但问题很多，都是你需求变来变去搞的”，而甲方通过旁听站会（如果他参加的话），来监督“我的钱花得值不值，你们有没有在认真干活”。
这让我想起一个哭笑不得的经历。一个外包团队为了向甲方证明自己“敏捷”，搞了个超大的显示器挂在办公室，上面是实时滚动的燃尽图、Kanban板。每次甲方领导来视察，项目经理就指着屏幕一顿猛吹，说我们看板多么透明，响应多么迅速。结果有一次，领导前脚刚走，一个开发小哥就悄悄跟我说：“别信那个，那屏幕就是个吉祥物，我们真正的进度都记在自己的小本子上，大屏幕上的任务删了，是方便给领导看的。”
这就是形式主义的极致。为了敏捷而敏捷，为了站会而站会，最终的结果就是剧场式敏捷。每个人都在扮演自己的角色，但心里都清楚，这并不是事情本来该有的样子。
血淋淋的现实：成本与时间的铁律
说到底，外包的本质是什么？对于甲方来说，是用可控的成本，获取确定性的交付。对于乙方（外包公司）来说，是在有限的人天合同里，最大化地榨取利润。
这两个目标，本身就和敏捷拥抱变化、持续改进的精神存在一定的矛盾。
一个敏捷项目，它鼓励你小步快跑，快速试错。今天发现一个方向不对，明天就调整。这在内部团队是好事，但在外包模式下，就是一场灾难。每次需求变更，对于外包团队来说，都意味着重新评估工作量、重新报价、重新走合同审批流程。这个流程慢则一两周，快也要好几天。等流程走完，开发团队可能已经忘了当初要改的是个啥了。
我见过一个外包项目，甲方希望用敏捷模式，让外包团队“随需而动”。一开始合作还算愉快，但到了中期，甲方内部业务调整，大量需求被推翻重写。外包公司的项目经理脸都绿了，因为他们的合同是按人天签的，这种大规模的需求变更，意味着项目预算要严重超支。
于是，在每日站会上，气氛完全变了。项目经理不再关心团队遇到了什么阻碍，而是不断地强调“这个需求变更没有走流程，不属于本次迭代范围”，他要控制范围，避免“免费”干活。而甲方的对接人则在站会上不断施压，说“业务要得急，你们先做，流程后面补”。开发团队夹在中间，无所适从。最后，这个项目不了了之，双方不欢而散。
所以，你会发现一个有趣的悖论：越是需要敏捷来应对不确定性的项目，往往越不适合外包。因为外包模式，天然是为了解决“不确定性的确定性实现”这个问题的。如果一件事从一开始就能说得清清楚楚，所有细节都已明确，那它可能更适合用传统的瀑布模式来做外包。而那些模糊的、探索性的、需要不断试错的工作，甲方通常会倾向于自己组建团队来搞，因为外包的成本和沟通风险太高了。
有没有活得好的外包敏捷团队？
当然有，但他们的模式通常比较特殊，或者说是经过了“魔改”。我总结了几个活的还不错的团队的共同点，你会发现他们都在试图解决前面说的那几个死结。
-
固定团队，固定薪资，而不是人天结算。
这是最重要的一个转变。甲方不再按天付钱，而是整体打包，按月付给外包公司一个固定的“Team Fee”。这样一来，外包公司为了保证利润，会倾向于让这个团队稳定地输出价值，而不是派个新手来刷人天。甲方也敢让这个团队去尝试、去试错了，因为成本是相对固定的。这种模式下，每日站会才有可能回归其本来面目——团队的内部同步会，而不是跟甲方汇报的“业绩报告会”。 -
深度融入，你中有我。
还是前面提到的那个算法团队的例子。外包人员的工位在甲方公司，使用甲方的沟通工具（比如企业微信、钉钉），和甲方员工一起参加所有技术分享和团建。他们不是“外面来的”，而是“项目组的”。这种身份认同的建立，能极大地消除信息传递的壁垒和不信任感。 -
甲方有强有力的PO，并愿意投入时间。
甲方必须认识到，你不是花钱买了几个“码农”，你是买了一个“解决方案团队”。你必须投入一个懂业务、有决策权、并且能随时响应的人（PO）和他们紧密工作。这个PO要能每天参加他们的站会，不是为了听进度，而是为了及时澄清需求，帮他们移除障碍。如果甲方不愿意出这个人，那敏捷基本没戏。
即使做到了这几点，也只是提高了敏捷在外包模式中存活的概率，并不能保证100%成功。公司文化、项目周期等太多因素会影响最终结果。
每日站会到底有没有用？
聊了这么多，回到最初的问题：IT研发外包团队到底用不用每日站会？
回答是：大部分会用，但用法千奇百怪，而且大部分都没用到点子上。
一个健康的、对项目真正有益的站会，通常具备以下特征，你可以用这个清单去观察你身边的团队：
- 时长：严格控制在15分钟以内。如果每次都开成半小时的长会，那一定是形式主义或者有人把站会当成了问题解决会。
- 参与人：是整个团队，包括开发、测试，最好还有PO。大家站着说（如果条件允许），而不是坐着轮流汇报。
- 氛围：应该是合作的、开放的。如果有人汇报时其他人低头玩手机，或者项目经理训话下属的氛围，那就跑偏了。
- 后续：站会结束时，问题暴露出来了，但会后会有人自发地、小范围地凑在一起解决问题，而不是让问题停留在看板上。
在现实的外包世界里，你更常看到的是以下几种“变种站会”：
-
任务汇报会：最常见。每个人轮流报告昨天做了什么，今天打算做什么。项目经理负责记录和追问。会议结束，压力传导完毕，然后各自回到座位上继续埋头苦干，毫无协作可言。
-
障碍甩锅会：和第一个相反。开发人员在会上大肆渲染自己遇到的困难，强调需求多么不明确、环境多么不稳定、历史代码多么烂。目的不是解决，而是为未来的延期和质量问题埋下伏笔：“你看，我早就说过会有问题的”。项目经理则在会后把这些“锅”整理成风险报告发给甲方。
-
老板汇报会：如果有甲方领导参加，站会自动升级。所有人都精心准备措辞，说的都是亮点和功劳，遇到的问题一带而过。整个过程就像一场精心编排的舞台剧。
你看，站会这个简单的仪式，在外包的责任关系和利益格局中，被扭曲成了完全不同的东西。它要么是权力的秀场，要么是甩锅的平台，很难成为真正的协作催化剂。
最后聊聊
聊了这么多，其实我心里也没个定论。外包团队是否采用敏捷，每日站会是否有效，这问题没有标准答案。它不是一个“是”或“否”的选择题，而是一个复杂的“度”的问题。
我后来渐渐觉得，也许我们不该强求所有外包团队都“敏捷”。有些项目，需求明确、边界清晰，用瀑布流管理，做好严格的里程碑评审，可能更高效，风险也更可控。而那些真正需要用敏捷去探索的项目，在选择外包团队时，就要做好心理准备，这会是一条非常崎岖的路。你需要找到的，与其说是一个“懂敏捷”的团队，不如说是一个愿意和你共同建立信任、共同承担风险的合作伙伴。
所以，下次当你考察一个外包团队，听到他们自信满满地说“我们天天开站会，非常敏捷”时，不妨多问一句：“你们的站会，是什么样的？”
别听他们怎么说，去看看他们的表情，听听说话的语气，感受一下空气里是紧张的“求生欲”，还是解决问题的“战斗欲”。答案，往往就在那些没说出口的话里。毕竟，活儿是人干的，流程只是辅助，人心才是根本。
人员派遣