【思考】一次交付项目小结

【背景】

　　公司销售谈了一个重要的项目，与我们正在研发的一个产品关系比较大，可惜前期由于种种原因，耽搁了很长时间，等到我们研发部门知道消息的时候，已经很晚了。9月中旬启动，11月下旬要求上线，按常理，这么短期的项目是没法做的，不过出于完善我们产品的考虑，我们还是咬着牙硬着头皮上了。由于产品还不成熟，交付工作只能我们自己上。

【现状】

　　按照计划，下周就要开发完成，进入测试阶段，可是我们还没进行过一次完整的提交，客户比较着急。而我们是原本是出于想把事情做好的想法，不希望把尚不完善的东西提交出去，导致进度看上去延后了。现在的情况是，客户产生了一些怀疑，而我们很被动。

　　目前我们拟定的方案是，赶紧先把目前做好的版本做一次提交，让客户看到现阶段的成果，再逐步修改完善。

【反思】

　　话说有些事情，不自己亲手做，永远都体会不到。之前我们一直是在做产品的项目，习惯了先思考设计->代码->改善设计->代码的方式，当我们把这种习惯带到交付项目里面后，发现两个项目的做事方式完全不一样，得出几点结论，供大家参考：

1、项目的首要目标是做的“没错”，项目的终极目标是“上线”：

　　这一点乃所有结论的最高前提。

　　在跟客户直接打交道的交付项目中，一定要时刻牢记，你做的事情，可以做的不好，但是一定不能“做错”。你可以做的不够好，但是一定要能“上线”。实际上，做的不好有多方面的原因，比如需求糟糕，时间紧急，第三方环境准备不充分等等，但是一定不要做的“有错”。就目前这个项目而言，由于项目时间非常紧急，客户的需求本身很不完善，交互设计不合理，风险点考虑不完善，需求中存在自相矛盾的地方。在这种情况下，我们犯的最大的错误是，没有按时提交版本。对需求进行细致分析没错，希望做一个好的东西出来没错，但是没有做到最基本的按时提交，就是做错了。先做好基本需求，再说锦上添花的事情。

　　其实现在看来，正确的做法应该是，按照客户给出需求先实现一个版本并提交，再去跟客户分析讨论如何完善需求。的确，这么做的话，可以想到的是，第一个版本的东西一定非常不好用，问题百出，会被骂的体无完肤，但是，这样做，达到了“做的没错”的目标。我们是按照客户给的需求做的，我们并没有做错，按照需求来做，不会延期。不好用是因为需求不完善。我们出了一个版本之后，因为要完善需求带来的时间成本和工作量，是由我们和客户共同承担。而成本共同承担的结果很有可能有意外的惊喜，比如需求被拆分，部分放到二期实现。而现在我们试图先做“完善需求”，再做开发，带来的额外时间成本和工作量都由我们自己承担了。

　　同样的问题还有加班。加班是大家都不喜欢的，但是在这种情况下，加班是一种态度。不管怎么样，我辛苦的加班，不会是做错。

　　项目的终极目标是上线，如果不能上线，其他一些都是浮云，做的东西再完善，如果不能按时上线，就是属于交付失败。此乃终极目标。不完善的东西，可以留到下一期再做。什么？跟客户说延期是因为我们需求给的不完善吗？客户是不认的，因为我们一直没有提个版本出来，现在只好吃这个哑巴亏。

　　关于最重要的这一点，请各位仔细体会。

2、需求变更其实是一把双刃剑，要看怎么样能用好：

　　话说需求变更是所有开发者的噩梦，但是在一定条件下，需求变更可以用来做对自己有利的事情。还是上面的情况，我们先提交代码，然后叫客户过来进行初步的测试，这时候客户肯定会提各种各样的意见，需求变更的噩梦就要开始了。但是，在目前项目情况下，其实这些变更是可以作为我们争取有利条件的砝码的。

　　首先，这个项目时间很紧急，客户其实自己也清楚，在时间这么紧急的情况下下，肯定不会有大规模的需求变更，我们可以借此机会将变更范围缩小，对于一些无法确定的变更，可以引导客户放到二期再做。同时，由于东西先出来了，再进行的需求变更，客户感觉自己参与进去了，一般到后面，他就不会轻易否定你的做的东西了，因为反驳你等于反驳他自己。

　　其次，如果有确实需要变更的地方，跟客户提出工作量和时间的要求，借此加大客户对我们工作的认可。我们现在做的也很辛苦，其实做了很多客户看不到的事情，但是这些在客户眼里无法有效的体现为我们的工作量，反而是成为客户怀疑我们工作能力的一个质疑点。如果我们能先快速提交一个版本，至少客户会认可你的能力，对于需求变更带来的工作量，他们才会认为是有意义的。

　　最后，如果需求变更导致真的做不完，项目可能出现延期，这个问题也不会落到我们头上（牢牢记住第一条，只要没有“做错”就OK），客户反而会变成有求于你，如果能加把劲帮他们解决这个问题，收获的是他们的感谢，当然，还有下一期的项目。而现在，付出的工作量并不少，却是我们有求于客户，希望客户能多给点时间，简直亏大了。

3、所有人都是你的盟友

　　在跟客户讨论需求的过程中，我们发现一个有意思的现象，客户其实是分拨的：

　　第一拨，跟我们一起实际做事的，科技部门的，关注的是这个事情好不好实现，有没有现成的东西，需要新增还是改动，他们有多大工作量；第二拨，关注运营的，关心功能是不是够用；第三拨，关注风险的，关注设计中有没有遗漏的风险点；第四拨，关注界面点，专注于交互设计合不合理，给用户用起来顺不顺手。

　　所以，到后来，我们在提出我们的观点时，如果期望得到谁的帮助，第一句话一定会跟他相关，比如：“从风险管控的角度讲，这里xxxxxx”，好了，那个做风险的就会帮着你开始balabala………

　　记住，不要直接反驳别人的观点，一定要拉上他们当中的一个帮你说，到最后的结果就是，所有人都觉得你说的不错，因为所有人都觉得自己的意见得到了重视。

4、针对需求中的问题提出自己的想法时，直奔目标，不要用设问句

　　之前漏了这一点，补充上。

　　之前做产品研发的时候，我们对一个问题进行讨论时，经常使用设问句。比如：“这里有一个重新打印最多只能做一次的需求，这个需求对客户来说是否有点不合理？”，然后，大家就会balabala针对这个问句来思考，提出自己的看法，最后我们会提出自己的看法共大家参考云云……其实，这种设问句大部分都是我们已经有了方案，只是为了引起大家的注意和思考，所以会先抛出一个问题。

　　这次在跟客户讨论需求的过程中，我们一开始也习惯性的用这种方式跟客户讨论需求，结果发现客户思维在问句抛出之后立马开始发散，往往会偏离我们预想的方向。而当我们试图再抛出自己的方案来纠正这个方向的时候，客户会认为我们是在反驳他的观点，是在躲避需求。

　　发现这个问题之后，我们改了交流的方式，对于需求中有疑问的地方，不提问句，上来之后直奔主题，直接抛出我们的方案，“对于需求中提到的xxx，我们认为xxx，我们设计了一种方案是xxx，大家看看有没有什么问题？”猜猜客户的反应是什么？在大部分情况下，客户的第一反应往往是围绕你的方案来提意见，基本能保证方案按照我们的来走，然后修正其中一些不合理的地方，最后客户还觉得自己做了不少工作……

　　小结，讨论需求不是在做产品研发的头脑风暴，讨论需求是为了定下一个结论，一定要牢牢把握住方向，避免思维的发散性。

　　PS：其实仔细回想一下，有时候领导想让你做一个事情，而你又觉得这个事情不是很合理，不太想做的时候，往往领导会转移话题跟你探讨这个东西怎么实现，然后你的注意力就不知不觉被转移到这个东西怎么实现，而不是应不应该实现上去，因为程序员一聊到具体的技术实现就兴致勃勃了……有木有！！哈哈