讲•道•理

   做什么事都要讲道理，今天我说说软件开发中开发人员的”讲道理“。

 

   开发人员写代码之前，一般都会做几件事：

 

   编写详细设计文档 ： 有些开发人员，或者公司要求写详细设计文档，用来对自己将要进行的开发工作做一个详细的设计。

 

   参加系分，概要设计宣讲和评审 ： 有时候，是没有详细设计的，直接听了系分宣讲，理解一下需求和系统实现的大概思路，就动工了。

 

   仅仅理解需求 ： 这种情况下，没有系分，设计文档，直接理解需求后，直接开始编码。

 

 

   以上几种场景，都是很常见的。依不同组织，不同团队，不同的紧迫程度而不同。

 

   设客户理解的软件为C，需求分析人员理解的软件为R，设计人员理解的软件软件为D，开发理解的软件为P。

 

   理想情况下： C=R=D=P，这是理想，限于时间，成本，不可能完全相等。

 

   我了解的日本外包，C=R=D≠P，他们通过大量的时间，将软件用语言描述为文档，但到实现层面，开发人员理解还是可能产生误差。保证了C=R=D≠P

 

   这里，我不说其他的环节，只讨论开发人员完成编码工作需要的前置条件，换句话说，开发人员做了什么事情，他就可以开干活了，并且保证理解的正确，返工率低。

 

   有人赞成编写详细设计文档，有人说详细设计文档写了也没用，浪费时间，设计变了，还得改文档，麻烦。

 

   设想一个场景：

 

   我让我儿子去打酱油，我话音刚落，他已经出去了，不一会，回来了，拿了一袋酱油。我说：”你怎么买袋装的，我想要瓶装的，用起来方便啊“。话音刚落，我儿子出去了，买了一瓶酱油回来。我说：“我要黄豆酱油，你这个太淡了啊！”。

 

   此故事纯属虚构，我儿子目前还不会打酱油。我想说明的是，如果在打酱油之前，他能够问一下：“爸，你想要什么样的酱油啊”，就尅有避免这种事情的发生，包括返工。

 

   但，仅仅问就足够了吗？ 说着可能溜号，口不对心，想要A，说成了B。听着也可能把A听成B。

 

   回到软件开发场景，开发和上游的理解偏差可以表示为，即：

 

   ΔPD = P-D

 

   如何让ΔPD = 0呢？

 

   大家都有这个体验，洗澡的时候，开热水，不热，再拧，tmd太热了，拧回来，又太凉了，反复几次之后，终于水温合适了。

 

   这就是负反馈回路，又叫平衡回路。

 

   在这里，就需要开发人员和上游有多次反馈，不能只听不问，只听不讲，只讲而不做确认。

 

   如果你刚开始程序员的工作，编码，你需要做的就是不断的听，问，讲。大多数开发人员听的多，问的少，讲的就更少了。 如果要在职业生涯更近一步，成为资深开发工程师，一定要学会讲，积极的讲。这道坎迟早要迈的，不仅要讲，而且要讲的简明扼要，要抓住关键，要让别人很快就能明白你的意图，你的设计，你的方案，你的问题等等。

 

   这就是我说的讲道理，作为软件这条线上的蚂蚱，不仅仅是开发，其他角色也一样，一定要多讲。

 

   从这个角度，讲道理可做如下解释：

 

   “讲“，然后”道“就”理“清楚了，只有讲了，思路才能更清楚，你能讲的出来，说明你已经理解的非常透彻了。详细设计文档，系分宣讲，需求文档无非都是媒介，终极目的是作为开发人员，你理解了多少。

 

   今天你讲道理了吗？

 

 

评论

12 楼 iamlotus 2010-03-02  

同意楼主的观点
Developer和BA/QA的交流总是应该尽量的多，事先交流远远比事后交流的效率高。无论文档多么详细，保证Developer能够尽量准确理解需求的唯一方式就是反复的，主动的交流。因为只有在面对面交流的过程中，Developer才会有动力去问一个又一个的为什么，“为什么用户需要这个功能？”，“为什么你想用这种方式实现这个功能？”，“为什么不试试用那种方式实现呢？”。
Developer理解需求就是去询问这样一个个为什么的过程，如果只看文档的话，由于沟通成本的上升，本来会问十个“为什么”的过程可能只会问道一到两个，而这就会带来理解的差异，造成返工。众所周知，一个返工需要前面问十个“为什么”的时间。PPT也好，DOC也好，UML也好，都只是方便交流的工具罢了。按照敏捷的要求来说，只要能够表达清楚，就该怎么简单怎么来。
当然，这种反复的过程对Developer的沟通能力和主动性要求也比较高。我认为这点上Developer大致能分三种：比较好的Developer可以在需求细化阶段和BA进行深入讨论，理解业务背景，知道实际上作出来一个什么东西才能满足BA的去要。这样的Developer在设计时甚至可以指出文档中的一些错误。一般的Developer在文档出来后会反复仔细的阅读文档，通过和BA的沟通尽量保证自己清楚BA脑海里的成品是个什么东西。比较差的Developer则是一边作一边按照自己的理解去解释文档，和BA的交流很少，最后自然bug也比较多。
说到底，只有好的Developer才能作出好的系统，那些认为只要有了流程(无论是ISO还是Agile)随便什么人都能搞出好系统的想法流毒太深了。有这个空不如多和程序员谈谈心，告诉他们主动沟通能给自己带来什么好处（能力上和待遇上），这才是王道。

11 楼 gurudk 2010-02-28  

raojl 写道

写文档，反馈，任何事情都有个条件，当你的任务压的慢慢，你还有时间考虑这个，还有时间
考虑优化，国内的环境就这样！

大家都觉得这个没时间，那个没时间，但最后总是有时间返工！

你的领导被事实愚弄了，你被他愚弄了，最后大家都被愚弄了。

10 楼 raojl 2010-02-26  

写文档，反馈，任何事情都有个条件，当你的任务压的慢慢，你还有时间考虑这个，还有时间
考虑优化，国内的环境就这样！

9 楼 gurudk 2010-02-26  

我觉得该说的时候还是要说，但说之前，我们自己要比较清晰，在脑子里过过。

现在社会化大分工，每个人都是紧密联系的，比起老子那个时代，人与人直接需要沟通的需求更迫切。

老子云：“多言数穷，不如守中”。苏格拉底认为，道理就是通过“对话”，通过“辩论”，通过刨根问底才越来越明确的。

8 楼 gurudk 2010-02-26  

cuixuxucui 写道

讲*道*理之后，用简洁的文字描述下来备忘，并让别人也看得懂，这才是有意义的文档

可以使用PPT，思维导图（脑图），如果要分享，ppt加工一下就可以了。

7 楼 cuixuxucui 2010-02-26  

讲*道*理之后，用简洁的文字描述下来备忘，并让别人也看得懂，这才是有意义的文档

6 楼 咖啡仔 2010-02-24  

gurudk 写道

咖啡仔 写道

一直我都是听的居多，很少有"讲"的
现在我公司的都是有了需求后，让美工设计好页面，直接编码
大部分都没有所谓的文档的。
这样很不好，开始时我都会有写一些文档的。后来我都慢慢少写了。:(

讲的前提是设计思路理清楚了，时间充裕，可以做一些详细设计，对自己系统思考是一个锻炼，但格式可以不限，哪怕是ppt，草图都可以。写那种详细设计的八股文档很让人崩溃。

嗯！记得在学校时老是要写。又不懂格式，就上网搜索,再慢慢修改为自己所做项目的设计
不过，还是用文档把设计思路记下来比较好，毕竟人脑是很快就会忘记的呢！

5 楼 java_fxj 2010-02-23  

同意！慢慢学会讲...

4 楼 gurudk 2010-02-22  

咖啡仔 写道

一直我都是听的居多，很少有"讲"的
现在我公司的都是有了需求后，让美工设计好页面，直接编码
大部分都没有所谓的文档的。
这样很不好，开始时我都会有写一些文档的。后来我都慢慢少写了。:(

讲的前提是设计思路理清楚了，时间充裕，可以做一些详细设计，对自己系统思考是一个锻炼，但格式可以不限，哪怕是ppt，草图都可以。写那种详细设计的八股文档很让人崩溃。

3 楼 咖啡仔 2010-02-22  

一直我都是听的居多，很少有"讲"的
现在我公司的都是有了需求后，让美工设计好页面，直接编码
大部分都没有所谓的文档的。
这样很不好，开始时我都会有写一些文档的。后来我都慢慢少写了。:(

2 楼 honlin 2010-02-22  

博主写的非常好，佩服佩服。抛开C，我们从R到D到P一直都在吵架，P出问题了就指责开发人员的水平有问题，或者理解有问题。这个问题一直困惑着我，不知道该怎样表达，一直建议公司重视流程的改进，但领导们都来都不管流程，就是坚持瀑布模型+ISO 9000一条道走到黑，烧了多少钱领导们都没意识到。

1 楼 funcreal 2010-02-22  

严重同意！
积极地反馈不仅仅是技术范畴的事，更多是道德范畴的事情。缺乏这一素质的人很难有所发展。