如何避免项目失控？

前言

作为一名技术开发人员，每次面对产品又改需求时，曾经我也会像别人一样很烦躁，心里不免抱怨产品的反复无常。但我立即明白这样想是不对的，不应抱怨，而是要想办法解决这个问题。于是我转念想，为什么技术这么害怕产品改需求？是不是因为我们写的代码还不够灵活？还不够强大？如果代码也可以像衣服那样任意搭配，是不是就能更好满足客户的需求。

另一方面，在更高的维度，从创业团队到发展中公司再到上市企业，都会面临同样的问题。不管团队人数有多少，不管业务复杂或简单，项目推进起来，总觉得进度都没有想象中的那么好，那么顺利，那么准时。

为什么呢？原因到底是什么？

我们应该怎样才能做得更好，不让项目失控？同时，让技术团队做起来不那么痛苦，压力更小，让企业和老板能更好控制成本和得到预期的效果，最终迎来企业性感的GMV增长曲线。

何为项目？项目=需求+任务+问题

首先，我们再来理解下对项目的定义。

我总结了下来，项目，是指在一定时间周期内，由技术人员完成的有限需求以及由此而产生的问题的一个集合。

从抽象层面概括，项目是一个集合，它是多元化的，因为在这个集合里面，它既包含了产品的需求，开发的任务，测试发现的Bug，同时蕴含了时间、项目干系人，以及在这过程中产生的设计稿、文档、PRD、测试用例、项目计划、制品、和最终的软件产品。只是为了方便管理，我们给这些元素界定了一个边界，由此产生了项目。

从具体层面讲，项目可以是一个全新的产品项目，也可以是一次软件外包项目；可以是一次版本迭代，也可以是某一周要做的事情；可以是技术优化专项，也可以是重构项目。

抽象层面的概括好比一个模板，刻出了具体的层面的项目样子。

为了简化对项目的理解，我提炼了这个公式：

项目 = 产品需求 + 开发任务 + 测试问题

进一步延展，补充每部分背后的核心关注点，则有：

项目 = 产品需求（目标） + 开发任务（效率） + 测试问题（质量）

这个公式，能让我们更加聚焦项目的主要成分，以及需要重点关注的要素。

这样梳理过后，我们就会发现，项目为什么难做？不外乎是：产品需求复杂多变、开发效率不高、项目质量不稳定。

需求不确定或前期梳理讨论不充分，就会在后面的研发过程中处处碰壁踩坑，频频出现“此路不通”的现象。换一个新想法成本不高，产品需求文档的调整成本也不算高，但如果项目开发已经进行到一半，这时说要换个商业模式或改需求，就要把已经打好的架构根基、做好的系统模块以及调试好的每一行代码都推倒重来，这时成本就会非常高。

开发效率低，就会导致项目的进度和里程碑一延再延，但可怕的不是延期，而不是知道还要延期多久，更致命的是，我们有时居然对此束手无措。这可能是团队执行力问题，也可能是项目安排统筹不当，抑或是核心技术人员被其他事务占用了宝贵的时间。

项目质量不稳定，就会引发产品的不满，投诉需求为什么老是达不到验收的标准。真相只有一个，做好的系统就像城市的道路，一旦上线使用，就会迎来用户的使用和流量，用得人越多，经过的流量越大，隐藏在系统中的每一个不合理、每一处缺陷，都会被人发现。这时，就有了故障。小故障磨人，大故障伤身。特别在ToB企业服务中，客户看到的不是你做好的99个强大功能，而是关心你还有哪个点没做好或有问题的，很可能就因为这个问题最终没买单。在ToC的业务中，故障的危害就更明显了，客户投诉、收入损失、企业形象受损。

项目的关键特性

著有《建筑的永恒之道》的亚历山大，为了找到构建建筑的本质，走访了世界各地的村落和城市，尝试整理出那些永恒建筑的特质，从而总结并书写了脍炙人口的建筑模式。他说，“无心之心，道之永恒。”应该怎么设计这座歌剧院才能满足人们在这个场景下的需求，不是我为了某些私心或利益而故意这样设计，也不是为了突显我个人的风格而那样设计，而是因为歌剧院本来就应该这些设计，就是歌剧院的本质，只是上帝让它通过我的大脑和我的双手来把它表达描绘出来而已。如是，则找到了建筑的永恒之道。

同样，在我们找到更好的管理项目的模式或方法之前，我们也需要尝试找到项目的关键特性。

项目的关键特性有：约束、具体化、不确定性。

很重要的一点，项目是约束的。项目有经费预算、有时间要求、有资源限制、有目标限制。就目标限制而言，也是项目存在的价值和缘由。例如企业的项目，最终是要实现商业化，赢得利益，这就要求项目能支撑公司的业务发展，满足用户的需求，促成订单，把企业的商业模式落地执行，尽快收回成本并实现盈利。又如学校的项目，要能满足对某事项的管理工作，虽然对ROI要求甚微，但要能达到各部门、各单位、老师和学生的使用需求。又如公益项目，是希望能把活动的效果发挥得更有影响力。其次，项目在经费和时间方便的约束，也是显而易见的。做任何一个项目，最终都是有其目标的，不管是为了实现盈利还是为了达到某种效果，理解这个目标和约束，对整体的项目把控对最高优先级的编排有很大参考意义。

项目具体化。项目的一个很大挑战在于要把无形变成有形，把抽象变为具体化，把不确定的变成确定的。最开始是一个想法概念，最终呈现和交付的是整套生态系统，包括软件产品、使用终端、数据库，甚至还有硬件的集成。

把无形变成有形，意味着我们要借助文档、图形和表格把在我们每个人脑中理解的概念、逻辑和流程实物化，让它可以能被看见、被传播和查阅。例如，产品经理要把抽象的需求做成详细的产品需求原型文档；技术人员要把对系统的设计和业务的规则用一行一行代码编译起来；测试人员要把对系统的功能验证方式用测试用例一个个整理出来，并把发现的每个Bug记录下来。虽然在当面沟通或开会的那一短暂的时间内，在场的人员是能理解这些规则、系统设计或问题，那没有好的文档记录，一段时间会就忘却，一旦忘却就容易迷茫。

把抽象变成具体化，前面也有提及到，在软件开发领域里，结合需求文档、设计稿、测试用例、服务器以及时间、人力和资源的投入后，产生的将是具体化的产品，例如是一个App、一套系统、一个网站或者一堆API接口，这些产品最终使用的人群是客户或其他第三方系统。软件开发是跨学科性的工程，其本身是理性的，任何一行代码都要精确出现在它应该出现的地方，除了代码语法本身要正确外，还要能满足业务需求对它的期望。试想一下，在一部30万字的小说里，如果人物角色的名称老是错乱会是怎样的后果，修改起来又是怎样的工作量，更何况一个项目下来就会产生少则几千多则几十万行的代码，而这些代码每一行都必须要毫无差错，可想要求之高。

项目的不确定性。做软件开发一个很有意思的特征是，我们都是在开发别人从来没做过的产品。外包天天有，但甲方的需求各有各的不同，项目千奇百态。虽然某个领域的产品前面已经有较成熟或现成的代码，但根据企业自身的商业模式，又会有新的创新或不寻常之处。就商城而言，有B2C、B2B、S2B2C、O2O，还分平台型、分销裂变型、加盟或连锁，还要分是销售商城软件的，还是做SaaS商城的，还是研发商城给自己业务使用的。使用的人群不同，处理的数据不同，所在的行业领域不同，发起项目的企业不同，处在的时代不同，对项目产生了很多不确定性。研发的周期越长，不确定性就越大。

做项目的几种境界

一代国学大师王国维在《人间词话》总结了人生的三大境界。分别是：“昨夜西风凋碧树。独上高楼，望尽天涯路。” “衣带渐宽终不悔，为伊消得人憔悴。” “众里寻他千百度，蓦然回首，那人却在，灯火阑珊处。”

青原行思大禅师也曾说人生的三大境界，分别是：“看山是山，看水是水。” “看山不是山，看水不是水。” “看山还是山，看水还是水。”

那么，做项目，又有几种境界呢？ 

我觉得，可以分为四种：项目失败、项目延期、项目按计划交付上线、项目出色超预期完成。

最恶劣和最不想发生的情况是项目失败。项目失败的原因可能是项目本身中止或放弃，可能是项目没能实现预期的目标，可能是项目最终消耗的时间和成本已远远超出了制定的预算，可能是项目遇到了目前无法解决或者解决代价非常高的限制，例如政策。

其次是项目延期，虽然项目没有失败，但背后需要付出的努力和等待的过程是非常艰辛和漫长的。这不是一个好的开头，纵使项目勉强交付和上线了，但这将会迎来新的一波问题和挑战。伴随着前面的赶工期，埋下了技术债务和设计不合理，在业务初期不会突显，但当业务发展到一定程度时，这些隐患就会越发明显。例如小问题时有发生，系统不稳定，新需求难以扩展，用户量达到一定规模后就会出现系统宕机，维护成本高，缺乏文档记录，整个系统看起来就像一个黑洞，不断吞噬我们的时间、精力、成本和激情，还阻碍了向前发展的大好趋势。那时，可能你会恨不得立即马上现在就把它重构。值得庆幸的是，项目延期只是一个信号，只是一个开头，在接下来的时间里，我们还是可以在这个长跑过程中逐步优化和调整，把系统做成我们想要的最美样子。

项目按计划交付上线。没有仔细统计，但在我过往近十年的研发项目里，能做到按计划交付上线的项目，占比真的不多，估计在5%。能做到按计划将付上线，已经是很不容易了。这意味着，除了需求功能开发完成，测试验收完毕，系统完成服务器搭建、部署和上线，用户培训结束，通过试用，跑出来的数据和结果与现实情况匹配无误。思前顾后，百密无一疏。除此之外，项目团队还对之前已发现的问题预留了应对方案、PlanB和监控手段。这是一个好的开始，也是一个很难得的阶段性成果。

项目出色超预期完成。最后，如果项目是出色超预期完成，那么真的是凤手麟角了。这是真正的极客精神，工匠精神。这对创始人、团队成员要求非常高，每个人都是不可或缺的一员，并且各自有其擅长之处，团队之间完美无缝合作。项目也是处于风口浪尖之上，顺势而为。这就好比如，在茫茫大海之上，突然间有一个明显的浪潮，浪潮之巅有一艘船，船上有不惧风雨和独具慧眼的船长以及他的水手们。他们抓住了这个稍纵即逝的宝贵机会，冲锋在最前面，齐心协力，排除万难，一路飞奔向上！而这艘船，就类比我们这讨论的项目。项目做好了还不行，还要尽快投产使用，让它发挥最大的价值，实现我们对目标的追求。如果我们花3万块钱造一艘船，并且能很快用它来挖掘和创造价值3千万的财富，想想这是多么激动人心。这时项目如果能超预期完成，其价值和重要性可想而知。

银弹何在

软件行业一直说，“没有银弹”。不存在放之四海而皆准的解决方案。但我们可以“退而求其次”，找到一种能帮助我们更好完成项目的方式。

项目是一个集合，也是一个过程。项目就有点像拍一部电影，参与的人员和角色会很多，故事情节一环扣一环，还要有场景、道具、群演，但电影不是杂乱无章的，而是精心编排的，在合适的地点，在指定的时间，出现相关人物，让画面呈现。

这意味着，做一个项目，不仅在于一开始就做得很好，而是要从一开始到结束到未来，都要一直做到最好，在合适的时间节点，让对应负责的成员正确完成计划完成的事项。

总结下来，以下三个策略对做好项目有非常重要的指导意义。

向上策略：项目管理

跨部门策略：信息互通

一线策略：团队协作

向上策略：项目管理

老板最关心的是结果，是ROI，是成本，是时间周期，以及项目做成后的成功概率和预估的收益和回报率。因此，老板在承担风险和压力的同时，要做的是定战略，做决策。项目管理和老板之间，要形成双向回路。

一方面，对内而言，项目要向老板汇报提供项目排期、项目风险、项目里程碑、项目具体进度、项目上线计划和项目发布后的效果复盘。有些信息，老板不一定会问，但他应该具有知悉权，以便在进行决策时有依据，有重要的精准信息作为参考。

另一方面，老板会根据对市场的了解，对竞品的分析，对趋势的揣摸，对现有资源的梳理，以及当前项目的状况，及时做出更合理的高层调整。这时就需要项目负责人，能根据接收到背景信息，老板的期望，再拆解并传达给团队成员和项目干系人，最终形成新的项目作战方案。

当项目和老板之间的双向回路形成后，对项目的成功将会有很大的促进作用。因为做正确的事情，会比把事情做正确更重要。

跨部门策略：信息互通

在企业里，会有多个部门。进行一个项目，通常会涉及多个部门，不乏产品部、设计部、研发部、市场部、商务部、客服部、质量管控部、运维部等。几乎每个专业线都会有相应的团队或部门，或以水平横向的方式形成组织内的多个事业部。由此产生了跨部门的沟通与合作。

与村庄的生活方式不同，在城市，需要有一套明确的规章制度和约定，才能让来自五湖四海的人都共同遵循规则办事。例如，如果你想在广州开车，那么你首先要考取驾照，符合资格后才能上本地车牌。开车出门，要注意不能闯红灯，不能压线，要记得加油，要买保险，要按规定停车并缴费（不然可能会被锁车贴纸或罚款），要定期做保养年审。在企业内，也需要制定或约定一套符合自己团队的工作流程，从需求收集到最终上线，以及故障反馈处理机制等。这样，不同部门的人才能各司其职，通力配合。信息要互通、合作而非对立，这样内耗低、响应更快。

一线策略：团队协作

对于一线团队，关注的是执行力，是效率和质量。对此，我们需要更多的方法论、专业技能和工具。

例如，在研发团队，可以用DDD领域驱动设计把复杂的领域问题简单化，可以用TDD测试驱动开发做到意图导向编程，可以用自动化集成环境进行CD持续交付。当然，项目本身就是一个协作过程，因此还需要一款团队协作的项目管理工具。

例如，我们团队针对敏捷开发专门设计的YesDev项目管理工具，可以用于团队协作开发。在项目管理，可以看到当前的项目和历史项目，每个项目，聚合了项目的概况信息，如进度、负责人、时间节点。还有一个很重要的特色，就是根据前面所说的公式，汇总了项目需求、开发任务和问题。此外，还可以根据不同的工作组划分项目，让每个人只需要关注和自己有关的项目。

我们不能对我们不知道的东西进行预测、分析和改进。只有理解项目的本质，需要用到的工具，当前团队的情况，我们才能更好的规划和执行。这过程，需要每个人的努力与配合，也需求沟通和协作，还需要流程和工具来辅助。

让优秀成为一种习惯。