某个周末，天气还是那么热。我和我女朋友在一家播放着催人拉屎音乐的德客士发生了争执，争执的起因其实很简单：我在帮她review她的项目的需求，对于一些观点我们产生了歧义。当然了我们夫妻不吵架那是不正常的。顺便说明：她是business analyst，我是一个code maker。话好像说远了，那就让话题再远一些吧，说到code maker那是公司最被看不起的人了，市场的人总说：“你们了解客户吗？不了解还不照我说的做。”你了解，你了解你来把客户不知从哪本过期杂志上看到的技术实现了？销售的人总对你炫耀：“你看看你们做的狗屎，还不是只有我能把它拿出去当黄金卖了。”我真想塞块狗屎给他让他以200元/克，卖出去给我看看。QA的人说：“这个bug你们修是死不修也是死……”那就让我早日去见我敬爱的马克思吧。技术支持的人总告诉你：“要不是你的烂程序一天死8次，我也不会被客户一天骂20次。”好吧责任都是我们的，光荣只属于你们。这下高兴了把所有人都说了个遍。真的说远了，现在就回来：
虽然她也同意我的比喻：对客户说酒红色不如截一张图给他看，跟程序员说酒红色不如告诉他240,65,85。但是就是不觉得把这个用户可以干的一大堆事情，和那个用户可以干的一大堆事情，跳转、禁止使用、开放使用什么的叫做权限，好吧也许你们项目里面不把这个叫做权限，但是能不能用程序员的语言说明吗？旋转、跳跃——我这种智商的已经晕了。
说这个事例我无意苛责谁，只是想说明做一个优秀的经理那是多难，因为你要跟很多岗位交道，用户当然不愿意去看那满是RSF-8,IEEE 4867这些名称的文档，程序员也不愿意看满是为了XX，实现XX的豪无参考价值的文档，好吧，如何解决？这个肯定有聪明的前辈们给我们想到了，有人（他不是一个人）发明了UML，好吧，问题貌似解决了，让我们来看看UML这玩意儿，用例图、类图、序列图、状态图、活动图、组件图和部署图，这也就是我能懂一点点的图，还有…也许早有人不耐烦，是的我想不是每一个职位都能阅读明白2种——5种UML的图的，这个统一建模语言让我想起以前听说过的一种世界通用语言，我不去评论这个语言的好坏，但是事实是不是所有人都愿意在自己的母语基础上多去学那么2，3种语言的，好的UML也是也许除了OMG那些成天制定规矩的人没有几个能会绘制UML里面的所有的图的吧（也许你的公司所有人包括你都是UML的专家，那好的恭喜你，你可以点击右上角的那个小X了）。好了下面才是BA、经理们需要干的：
需求分析报告：一般是对某个市场或者是客户群来讲的，类似于调研报告，重点是体现出产品要满足哪些功能，哪些是重点、热点。
需求说明书：是根据与现场实际客户进行沟通，把客户的需求进行整理，重点是站在客户的角度讲产品功能。
需求规格说明书：是从业务规则讲起的，细一点偏向于软件的概要设计。是从开发、测试的角度去讲产品功能，里面要包含原型界面、业务接口、活动图等。
好了，我不会去费口水来教这些文档应该怎样写，因为Google一下满天都是，不过要写好不同的文档需要的知识面也是不同的，这个道理很简单，他们都听不懂或者某些人听不懂世界通用语（我都已经说过了要是您公司的人都是通用语的专家那我说的都是废话），那好请准备说中文、英文、德文以及西伯力亚文，什么你只会说中文？那你只能祈祷你的同伴都能听懂中文或者他们能不厌其烦的连猜带比划的同你工作了。综上所诉公司应该让什么样的人成为程序经理，我觉得是了解业务、懂技术、会管理的人。好吧我的想法跟你一样，我也觉得这有点难为人了。
