人月神话札记：贯彻执行

前言：He'll sit here and he'll say, "Do this! Do that!" And nothing will happen.应该就是光说不练假把式的意思，本篇的标题为passing the word，当项目经理拥有了结构师，开发人员，那么如何保持概念一致性呢？

文档化的规格说明-手册         显然，对于我当前所处的团队，手册是不存在的，我到现在都不知道手册该写些什么，诚然，我看过很多说明手册，教如何使用产品或者如何操作手顺书。作者所说的手册是“不但要能够描述包括所有界面在内的用户可见的一切，同时要避免描述用户看不见的事物”。之前在日企工作时，大量的产品说明手册，我不知道日本人是怎么做出来的，很多还没有创造出来的产品，他们就能够写出大量详细的文档以及图形。        思考：手册到底该描述写什么？针对我当前所开发的期货交易平台，我们的手册是什么？ 形式化定义        也就是说，在写手册的时候，手册的写作内容要形式化，避免表达的不够精确，如果可以的话，需要伴随一定的记述性定义。 会议和大会          作者所说的会议室周例会，而大会就是所谓的年会。当然对于我当前的项目来说，会议就是和客户、领导一起，讨论新需求的合理性，如果需求合理，大家讨论如何实现，然后就是分解需求，进而实现它。          面对客户和领导的压力，我需要在会议上坚持如下要点：

1. 需求的合理性，往往很多时候，客户提出的需求都是凭空想象的，当然他已经拥有了很多经验。
2. 需求的必要性，客户和领导很少会去衡量他们想法的必要性。
3. 需求的优先级，他们似乎从来不去认真的思考需求的优先级，当前阶段有必要做不做，做完以后用不用。
4. 需求的负影响，如果要做这个需求，对当前已经稳定的系统有什么影响。

然后再来看看作者提出的观点和方法：

1. 结构师、用户和实现人员每周交流一次，会让大家对项目内容比较了解。
2. 会让每个人承担理解面对问题的义务。
3. 明确首席结构师的话语权。

电话日志        在这个小节中，我认为作者的这句话非常好，如下“对于存在疑问的程序员，鼓励他们打电话询问相应的结构师，而不是一边猜测一边工作，这是项基本措施”，这句话看似简单，在我们的项目团队中却遇到了很大问题，多数情况下，需求不停变换，进而导致程序员对于模糊的需求不求甚解，在开发的时候依靠自己的判断力去决策，最终导致大量的返工。 产品测试         看完这个章节的内容后，我有点莫名的忧伤。因为一年前，我的项目小组就没有专职的测试人员，一直到现在，充当测试的人员是我，多重角色的苦恼一直无法解决，肯定是成本和重视的原因。         抛开个人团队因素，产品测试非常的重要，一个成熟的测试团队是保证产品质量以及产品创新的驱动力，测试团队就是用户的代表，他们反馈的问题是结构师、开发人员最不愿意看到的，然而这样就会保证bug无所遁从。

标签：需求,产品,神话,贯彻执行,手册,札记,测试,团队,当前
来源： https://blog.51cto.com/u_2324584/2937221