项目，不是产品。
恭喜你，当你把它当项目，而不是产品时，你已经成功了一半。剩下的一半靠不动摇。

“项目思维”是搞砸项目的总纲领。记住，“特性”比“业务需求”重要；Output（产出）比 Outcome（结果）重要。

有些人满嘴“用户价值”，“拥抱变化”，你想考研吗？

资源迅速到位
根据需求列表和项目期限，迅速拍脑袋争取到需要的 Resource 。

一定要说 Resource，不能说资源，更不能说工程师。逼格越高越有希望把项目搞砸于无形之中。

不同的项目当然要有不同的资源配比，资源也是多多益善。你让相对固定的并且配合默契的“两个披萨”全功能团队去做，万一，做成了怎么办？

开好启动会
“启动会”不开最好，开只是为了显得专业。

会议上先谈任务，把特性列表过一遍。千万别去谈什么“产品愿景”，“目标用户”，“RAID”（Risk/Assumption/Issue/Dependency），根本没人关心。

然后要鼓舞士气，让大家相信这些特性在规定时间是一定可以完成的。如果看到迷茫不坚定的脸，要坚定地说：“老板对这个项目的支持力度非常大，必要时我们会向老板要更多 Resource，请大家放心。”

“万一完不成，Scope 是否可以调整？”这种还没开始就伤士气的话，谁提让谁走人，换一个 Resource 进来。

迅速开始
敏捷的时代，能动手尽量别吵吵。产品经理分析好了需求，团队马上开始建造巴别塔。

巴别塔的意思是：不要让程序员听懂业务术语。

有个叫 DDD （领域驱动设计）的东西，发明人写的那本书跟砖头一样，写的佶屈聱牙，让码农自嗨去，千万别碰。

我们要 UI 驱动。产品经理和 UX 设计师直接把 UI 画出来（一定别叫上没品位的程序员），高保真，精确到像素。前端拿过来直接用，那叫一个快。

技术团队上手也要快，直接上代码，别搞什么领域模型图之类的设计文档。

代码即文档，一切知识，如果不在代码里，那就在代码的注释里。过几个月回看起来都门儿清。

分工明确
刚才说了，UI 是 UX 设计师的事，程序员别插手。同样的，需求分析必须由产品经理全权负责，“怎么实现我不管”。

架构师负责架构设计（PPT），你要是自降身份去写代码，你是不想好好混了。

前端团队和后端团队一定要分开，最好有不同的老大，互相制衡。API 的设计，谁强势谁说了算，弱势一方负责联调。

程序员要专心写代码，测试得有专职的 QA 。可以不时来一句：“这么简单的 bug 都没测出来？”，以加强 QA 的羞耻感和人肉测试覆盖率。

QA 的反击是测出尽量多的 bug 来增加程序员的羞耻感（那他们也得有啊！）。

并且必须追着程序员改，加班也要改。bug 严重不严重我不管，我不能让一个 bug 从我眼皮底下溜走。

各角色要清楚自己的责任，管好自己的一亩三分地。该撕就撕，太和谐的团队不见得好。

全程追踪产出
燃尽图耍起来。这东西太好了，进度一目了然而且还敏捷。

比如一个 6 个月的项目，团队在第一个迭代（半个月）要是没有完成需求列表的 1/12，那完了，要加班赶进度了。

不要相信 “软件开发是个学习旅程”， “Forming-Storming-Performing”之类的鬼话，只有进度条是不会骗人的。

追求燃尽图（或者burn-up chart）的完美是项目进度管理的利器，怎么强调都不为过。

最好是燃任务的小时数，这样团队比较容易动点手脚让它完美，你懂的。

保护 Sprint 和老板
需求在一个迭代里必须固定。团队里至少要有一个能手撕产品经理的愣头青。

要有这个意识，我们是 Scrum， 不管你为什么要加东西，反正你要加，只能加到下个 Sprint。否则你就是伪敏捷。

如果是老板要加东西，那另当别论，要保护老板，老板都是对的。

千万别去看官方的 Scrum Guide，不然心态容易崩。

保持繁忙
Sprint 最重要的是有足够的需求让团队保持繁忙，不要去设置什么Sprint Goal，要设也就是设成“把所有 Story 完成”，设了干嘛？

团队不能闲着，忙着做布朗运动也比歇着好。

有些团队还每两周都喝着奶茶开什么回顾会，1 个人 1小时，10 个人就 10 小时，简直是无耻。

互相尊重
明确的分工也是为了各角色之间的互相尊重。是什么头衔，就干什么活，别越界，更别越俎代庖。

同一个角色内部，比如程序员之间，也要互相尊重。我写的代码，你不能重构，不然太不把我当干粮了。

万一要 Code Review，走走过场就行了。只要能实现功能，代码怎么写都行。大家低头不见抬头见的。

注重质量
质量是测出来的。所以 QA 测试必须全面且到位，如果一个迭代内测不完，可以搞个 QA Sprint，去测试 Dev 上个 Sprint 完成的需求。

bug 率是衡量质量的唯一标准，必要时全民 QA， 加强人肉的回归测试力度。

至于功能是否带来业务价值，代码的可维护性，程序员的代码提交习惯，等等，统统不在质量的范畴。

没有 bug 质量就是好。什么质量内建，听也听不懂，懂也不会做。

保证发布的成功
第一个发布，一定要打响。

要制定严格的质量标准，做好充分完备的测试，确保发布出去的东西，都是跟产品经理的需求一致的。

这样就是一个成功的发布，要庆功。

至于用户的需求是不是被满足，那是产品经理的事，不然凭什么你叫经理？

而用户的反馈就更不用听了，用户啥也不懂，就知道加需求，而且那些需求他们自己都说不利索。

项目中间一定要避免用户的骚扰。

什么？你是乙方？那客户说啥就做啥，不要去骚扰用户。

杜绝浪费
要警惕有人鼓吹的把用户故事拆成 INVEST 这种不懂行的做法。

把一个馒头掰成 3 份，再一份份吃掉？跟直接吃有什么区别？有掰馒头的时间我已经吃完了。

还有，1 个 Story 拆成 3 个，你让 QA 要测 3 遍？真的是狗咬火车不懂科学。

精益就是要杜绝浪费，所以一定不要整虚的，把东西整出来才是硬道理，别管怎么整。

领导力
领导力不一定是领导的事情，每个人都可以有领导力。

他们目光如炬，表情深沉，到了要发布的关键时刻，在大家一片盲目乐观的情绪中，冷静地指出项目存在的种种问题。

不要提前说出来，时机不到没有效果；也不要提任何解决方案，你把问题说出来的一霎那，你就赢了，云淡风轻。

领导力还表现在刷存在感，随时找人谈话；挥斥方遒，布置任务。

人类，特别是程序员有一种叫“心流”的状态，一旦有人进入这种状态，这项目可能要成。要警惕啊！

待续？
弃马十三招是象棋著名骗局，13 招内弃马杀贼。

我也刚好凑了 13 招，写到这边已经黔驴技穷了，如果这都还没把项目搞砸，只能动用一些更微妙的手段了。

您有什么高招吗？