你是不是经常碰到承诺了一周上线，但是发现两周你还没有搞定项目。
你是不是经常碰到产品经理来突然对你说，今天要上线的，为什么来不及了，而你一脸懵逼。
你有时候是不是发现开发着这个项目有紧急需求插入过来了，你默默做了，然后等到了上线的时候，你才突然给他同步风险。
你有时候是不是承诺了一个时间点，但是在评开发的过程中发现有很多难点和卡点，导致工期已经远远超出了自己的承诺范围。
上面所说的就是你应该重视需求、风险和预期管理了。
项目的管理本身就是一个哲学性的话题。你评估的时间太短了，可能导致自己会非常被动。如果评估的太长了，很容易被其他同学挑战能力问题。
不像流水线工作，可以把每个步骤经过反复的试验取得一个最符合实际预期的时间，然后把每个步骤叠加到一起，就能够清晰的预判整体交付。
所以这里面第一个讨论的问题就是如何做预期管理。
预期管理简单来说就是要让所有人对整个项目达成一个心理预期。这个预期就是要概括这个项目的范围在哪里，边界在哪里，核心难点在哪里，是否需要分阶段来上线，项目优先级是什么，多少资源投入。
预期管理非常重要的一点就是要站在不同的视角来看待问题。对于产品经理来说，就希望我现在提出的需求看起来好像挺简单的，能不能明天就上线。
而实际上可能对于产品经理来说是一句话的需求，底层可能涉及到架构的大量改动、编码、测试回归以及灰度发布。可能里面的固定流程就超过一个星期。
所以在这种情况下，预期管理就变得非常重要，首先就要站在产品经理的角度来理解产品经理希望这个功能在什么样的一个范围上线，要了解到产品经理对于产品上线的预期。比如有些功能本身是属于业务就比较紧急的情况，有些需求只是老板脑子一热临时想到的。
首先站在全局上来说，一定不是需求做的越多越好。可能一个优秀的产品功能，只需要一两个核心的功能即可满足绝大多数用户的需求。
从实际的那个经验上来说，大量的功能上线都是浪费的，也非常符合28的原理。即上线了一堆功能，只有20%是有价值的，80%是长尾，甚至是无效的功能。
所以从程序员或者项目经理的角度就对，必须要对这20%的核心产品功能进行严格的赶工评估和排期，需要识别出这20%的核心功能点。
也就是说程序员一定要把握出来哪些是关键需求，哪些是非关键需求，哪些是能拿到业务结果的需求，而哪些只是次要功能的需求。
所以站在这个角度的话，那么一定就要对这些关键需求做一些细致的评估以及特别的风险管理。
预期管理
- 上传图片
预期的管理的第一要素就是要让团队对整个项目的价值开发，人力投入和优先级要达成一致。
由于每个人对于项目的视角和要求可能都是不一样的，所以达成预期一致是最重要的一件事情。达成一致之后，不仅方便于项目的及时推进和同步，更重要的是保障了项目能够如期上线，也规避了出现异常的情况后的相互扯皮的可能性。
第一个就是项目价值和优先度的问题。
在评估项目的时候就务必要达成一致，这个项目优先级是否是最高，这个项目的价值是否是大家认可。如果这个答案是否定的，那么就有极大的可能因为出现了工期异常导致相互甩锅的情形。
有的时候，也只是表面上达成了一致，而非达成了真正的一致。所以在做预期管理到时候，就必须真正做到业务目标的一致，实现有效沟通，并对业务目标进行一个同步和通晒。
萧伯纳说过一句明言，沟通最大的问题，就是大家认为已经沟通过。
我在各个团队就出现过表面上达成了一致，当业务上线时间不满足预期或者业务上线后拿不到业务结果，团队之间就相互推诿甩锅。
达成目标不仅是和团队内部，也需要和外部团队达成一致，并有所约束。
协作型项目价值如果不够，跟外部团队没有办法达成利益共同体，那么外部团队就很容易产生优先级更高的事情的插入而导致外部风险。
第二个是项目评估，务必充分。
从经验来看，程序员大概率会过渡承诺。
很多程序员就会根据自己过往的经验，想当然的对项目做一个粗略的评估。而我们经过复盘发现往往比较大的项目的话，都会存在着各种各样的不确定性和风险，但很多其实本应该在项目评估的时候就应该评估出来的，但是我们发现实际上都会由于各种各样的原因有了疏漏进而导致了工期大幅度延长。
我们碰到过一个项目预期是2个月时间，真正到发布上线持续了3个月。
我们经常碰到这个问题，就是产品经理在拉开发同学评估产品需求的时候直接就问你大概看一下这个工期在多少，什么时候能上线？
所以很多时候程序员就根据自己的经验就当场给了一个粗略的评估和上线的时间点。
对于产品同学，他是很乐意及时的快速的拿到上线的时间点，同时他就把这个时间点可能纳入自己的产品规划或者对外的一些宣传里面。
把粗略的评估当成对外承诺，这就可能引起沟通和协同的灾难的开始。
这种临时性的、模糊的、粗略的、大致的评估点就会导致重大的项目风险发生。一方面由于需求评审可能也是比较粗略省掉了一些关键的步骤，这些步骤可能在产品经理看来是个既定的，但是在程序员这块看来可能是不需要的，所以这块就会产生了一个比较大的一个内在分歧。
另外由于在这种比较紧张的情况下的评估可能是非常的主观的，可能对每一个模块评估是根本不到位，同时在这种情况下，可能程序员也忽略了测试和回归验收以及发布上的一些固定时间。所以在这个情况下给出的承诺往往会存在巨大的不确定性，甚至是不负责任的评估。
第三个是评估研发流程的客观流程。
这个不仅是某个项目的问题，这个是要在所有项目里面，程序员都要和产品经理达成一致的。
这里面应该有很多成的段子，比如说某个老板找到一堆程序员说给你50万，一个月的时间，能不能做出一个淘宝来。
经常会有这样的一些段子，其实就真正表明了在项目评估里面，可能每个人的理解确实是不同的。对于一个老板来说，投资50万砸七八个程序员进去，已经是一个巨额的预算，应该能产出一个比较好的一个结果，但实际上研发流程的复杂度不是一般非技术人士能够评估准确的，甚至对于同一个项目，不同的人对于难度认知相差十万八千里。
对于一些外行的评头论足，你可嗤之以鼻，反正达成不了一致，相互吐槽，也不影响大局，但对于你长期协作的产品经理和业务同学来说，你就务必要达成内在的认可和一致，否则就存着长期的冲突。
这里面也很容易理解，站在业务的角度的话，希望产品功能是越快上线越好，站在程序员的角度是希望能够高效快速的交付稳定性的系统。也就是说两者其实在本质上是一致的，都想以这种快速敏捷迭代的方式交付出产品。
但尽管这样，由于职能线的不同，两者的评估的内容和时间都是可能达成不了一致的。因此就需要程序员客观的把交付的研发流程给予客观的评估。
比如技术方案的调研，比如说模块的编码、自测、联调以及测试，还有线上回归，这些可能对于大部分的项目来说都是不可避免的，需要占用一定固定量的工时，但这个公司产品经理可能不关心，他关心的只是产品功能上线，所以这里面有这么非常大的一个GAP的话，就需要反复的和产品和业务方去沟通去确认。一直直到一方和产品经理的认同为止。而且这种机制是整个研发流程，整个公司或者部门下达成一致的规约，是任何人都不能破坏的。
很多大公司如果测试不完善或者没有按照严格的灰度节奏就是一个红线，严重的会被直接开除。
对于某些客户端来说，一定要有一个发版的过程，只有客户升级了最新版才能够获得最新的功能，这个发版的过程也不是人为能够控制控制的。
所以这些既定的流程应该事先要同步给所有参与的角色，让大家达成一致或者知晓。退一步来说，也就是说假如我开发的速度足够快，可能也需要测试两天，需要灰度三天，也就是最终不管你的功能多紧急，我都需要五天的时间才能够保障线上用户能体验到。
这是一个客观规律，是公司长期以来形成的流程，程序员无法解决，如果要挑战，请挑战公司的开发流程。
需求管理
程序员需要对需求进行管理。我们知道很多需求，其本身它就是不合理的，可能80%的需求都根本拿不到业务，结果甚至有些需求在逻辑上都就存在BUG的。所以对于程序员来说，不仅仅做交付，更要对交付的内容做一些适当的控制和管理。
当然并不是所有的业务是准确的，也不是所有的程序员都准确的。所以按迭代分期交付的模式。
在当前社会发展迅速的情况下，敏捷迭代的一个非常好的一个特点就是把需求拆成了模块化MVP闭环，最小的功能来交付进行线上验证，同时根据用户的反馈不断的进行迭代升级处理。
所以对于需求来说也是一样，其实非常切忌产品经理提一个大需求，然后程序员用半年的时间来开发，然后用几个月的时间来测试，最后才上线，这个时候很可能赶不上市场的业务变化，甚至如果发生了不和预期一致的情况，则导致产品经理和程序员都拿不到结果。
所以在这种情况下，程序员就应该是特别应该协助产品经理圈定最小的闭环，分阶段来进行交付。对于非核心逻辑异常或者是分支型的该砍的功能就坚决果断的砍掉。
遇到有核心点分歧的必须要上升，一定要在自己认同的情况下才去做，否则根本问题没有抓到，只因为工期问题相互扯皮。
如果在某些小方向不能认同，大方向一致的情况下，可以先采用试点的方式先做几个需求，看看交付的情况到底如何，能不能拿到业务结果，最后根据业务结果来进行小方向分歧的复盘和拉通。
如果长期来看产品经理的需求，跟你程序员想要实现的模式都有非常大的冲突，并且通过实际验证也没办法达到市场的预期，那么这个情况下建议程序员就不要在这个公司继续干下去了。
风险管理
风险管理的最重要的一个手段就是信息同步和透明。
对于常规性的项目来说，其实一般在项目评估的时候就能够评出外部的风险。对于临时性的紧急的风险其实相对来说也不会那么大，比如说安全问题，比如说合规问题，这些可能有，但是应该不至于贯穿到所有产品的研发流程里面。
确定了一个项目需求之后，在立项技术方案之评审后，其实工期相对来说是比较可控的。但尽管这样，还是一些有非预期的风险，会导致整个项目delay或者流产。
比如人员的休假问题，比如说有更高优的需求插入，比如说外部依赖风险，比如说合规风险，人力抽调，比如说需求沟通不充分等等。
这里面除了一些不可抗力的原因，还有一些其实应该在项目立项评估的时候就应该能控制的。
这里面非常关键的一点就是要做到进度的透明化和机制的同步。最忌讳的就是中间发生了各种风险，但是没有同步和上报，而到项目原计划上线的时间点才同步出来，一般发生这种风险，业务侧的产品同学都不能接受的。
所以我主张对于核心项目的其实应该在每一个节点形成固定的风险和进度通报同步机制，比如说周报，比如说双周报，对于一些比较小的需求，可以设置双日报或者日报的形式。
风险管理这个形式可以多样化，但是里面内容主要就两个，第一个就是进度，第二个就是风险。
由于这种周报或者例会的形式，关心进度的可能不仅仅是程序员，也可能有产品经理或者测试或者外部业务方，因此就不要用过多技术术语来同步进度，更可能更简单的方式可以把它整合成百分比的形式，这样能方便所有同学一眼就能够看到当前的进展大概在多少。第二个就要把风险及时的同步，最好是在风险发生的当下就判断出是否是风险，然后在当天的日报或者以其他形式就可以即时同步出来。
风险要做及时同步，过夜都不行。
比如突然碰到了安全问题，需要解安全的方面才能够让项目上线，就应该当下及时的把风险同步出来，同时推动各方以及安全来探讨如何解决或者规避安全问题。
碰到风险性问题的第一要素就是即时性，也就是是要即时的进入风险评估以及风险的同步。
由于互联网这种敏捷迭代交付的方式有很大的一个问题，就是有可能会有一些紧急需求的插入。这个首先我们来说是不可避免，因为在这个业务进行的过程中，确实会有很多临时性或者突发性的需求或者超大老板的需求。首先界面达成明确的一个点，需求不是随意都能插入的，如果一旦开了这个口子，那么就往往会导致其他需求或者这个点带的崩溃，甚至长期都有这种。排好的需求，但后面又被临时更改，长期以来的话，会导致程序员和产品经理交付的效率都会非常偏低同时会非常影响士气。
有些约定本质上是一样的，约定了就要按照约定去走，才能让业务和团队稳固发展。就如同国家的政策一样，朝令夕改的国家政策，一定不是好政策，也一定不是好国家。
所以程序员和相关的角色要制定一定的需求变更的规则和准入门槛。同时对于这种实在没办法紧急要接受的变更插入需求，一定要做风险的同步和管理。要让大家知道，紧急需求的插入是有代价的。
所以综上来说，互联网项目其实是所有同学都要共背目标拿结果了，在这里面就需要更多充分的协同和相互理解，而程序员作为落地的最关键的一环，就特别要注意需求管理，预期管理和风险管理。
只有这样，程序员才能够用对的方式，做对的事情，发挥最大的价值。
作者：ali老蒋
