部门建设建议（草稿）
部门建设建议
1. 写在前面
我建议：
1、 建立一个开放式的BBS，提供集思广益的平台
2、 建立一个会议制度，制约会议过程和会议结果的追踪
3、 对内部培训进行适当的鼓励，应该明确表明大力支持的态度
4、 规范化需求流程，形成文档
5、 增加产品线级的需求管理人员岗位接收、判定、分法和限定需求
6、 逐步建立代码库
7、 逐步建立共享知识库（本文没有涉及）
8、 分离各个项目的核心模块和本地模块（改造的时间很长）
9、 明确现场维护人员的职责，明确后台支持人员的守则
10、 确保对规则承诺能够得到兑现
11、 确保改进必须的政策支持和信任
2. 沟通
沟通的问题不仅在当前存在，以后也会长久的存在；不仅在我们公司存在，也会在其他绝大多数公司存在。我们能够做到的是将沟通做的更加通畅一些，而不是流畅一些，毕竟沟通是一个人与人之间的活动，而影响这些活动的因素大部分归结于参与者的性格和经验，这些是我们无法预知的。
沟通需要：准确的表达、正确的接受、适当的途径或者方式。对于表达和接受，我们无法确知，只说说沟通的途径。
2.1. 沟通机制
机制应该有政策作为保障才能正确的贯彻，也需要政策作为保障才能保证其持久性。
同级员工内部之间沟通存在的问题基本属于人品问题的彰显，没有约束也不能有约束，因为表达是一种权利。
但是上下级之间的沟通就显得微妙了，不管在何种的企业文化环境中，上下级之间无论如何也不可能达到一种推心置腹的效果，下级的利益掌握在上级手中，话说的太透了会产生下级的不安。问题似乎是出在下级不能说出自己真正想说的，但是事实整好相反，正出在上级身上。
我不是想让整个团队中象乌托邦一样泰然，我只是想是否我们可以缩短这些距离，让双方都得到满意的效果。
内部的BBS应该是一个不错的选择，其成功的关键有以下几个因素：
1、 良好的分类
2、 除非特别出格的事情，管理员不应该删除帖子。
3、 针对性的帖子应该及时回复，不管是领导回复还是秘书回复，至少表明了一个态度
4、 应该允许匿名，而且一定承诺不排查，这点比较关键，可能招来大量的谩骂，但是所有的谩骂都是有理由的，如果不能承受这些谩骂，那么这个BBS根本就没什么用处。
看起来比较良好，其实问题的真正根源在于上级怎么样看待问题，是回避还是坦然。六西格玛说要开一个RCS（谣言制止会议），是说让领导坦然的坐在那里，员工陈述听到的传言，领导诚实的回答，“我不知道”、“我不能告诉你”都是有效的回答，试看当前，谁能做到？
2.2. 内部培训
内部培训有几个效果：
l 让很多人了解一个东西，并且能够大致了解这个东西的形状
l 让很多人知道某些方面的问题可以直接找谁问
l 让讲课的人真正的回溯一下相关的知识，巩固和提高总是密不可分的
这样看来，内部培训简直就是一个利国利民的工作。和其他的培训不一样，内部培训更加注重的是一个过程，而不是培训的结果。内部培训的主要目的是为了交流而不是教授。所以内部培训如果民间自发的效果远远优于官方组织。
但是很多Team中的内部培训却真实的是内部培训——仅仅局限于自己所在的Team中，除了与组织者自身有关以外，外界环境的影响或者说风气的影响也不容忽视。所以，应该对内部培训提出一些要求（不是限制、制度，只是要求或者建议），甚至一定程度的鼓励。否则，内部培训只局限于自己Team的活动可能会愈演愈烈，真的没几个人不小心眼，随便你承认与否。
2.3. 会议
我们的会议缺乏一个会议的守则。
一个会议中，各个参与者拥有平等发言权尤其重要。平等的概念，除了各个成员都有机会发言之外，还包含各个成员对于其他成员的发言的尊重。
一个会议守则是应该必须的，例如
l 按时开始和结束会议
l 遵守会议议程
l 参会者应该事先有所准备
l 会上不谈论与会议主题无关的其他内容
l 参会者具有平等的发言权
l 24小时之内发送会议备忘录
l 每个人都是会议的参与者，不是观众
l 任何问题和想法都可以提出，不存在优劣之分
l 针对思路，不攻击个人
同时一个会议中，应该具备一个主持人和一个书记员。
主持人的工作一方面是确定会议的主旨（议题），另一方面引领会议的进程（议程），同时，主持人还兼顾部分守则的执行的职责。
而书记员的职责是将会议中的议题、结论和问题进行记录整理，并形成备忘录。
能不能把会议的结果贯彻，是会议是否有意义的一个标志。会议的目的不是陈述，而是为了解决问题，如果单纯停留在陈述上面，还不如直接传阅电子文档——反正听与不听效果都一样。
一般来说会议的结果会包含一些针对个人的期望（可能是任务、也可能是资源需求），如何对这些期望进行管理和追踪是一个依赖责任方的个体行为的问题。可以建立一个具有关联性质的任务表来处理这个问题，在固定时间的报告会议（周会）上进行跟踪回溯。
2.4. 报告
本节报告是指日常的报告文档，包含日报、月报和周报文档。报告的有效性体现在报告人对待报告的态度和接受报告的人对报告的处理之上。
在当前公司日报不常见，我个人的对日报也是持一种保留态度，日报在没有成为每天工作的负担的情况之下，的确可以指导个人的工作。如果从一个笃定的流程观点看待日报，将日报作为日常必须上报的文档之一，那么可能适得其反。一个好的日报应该是一个对自己工作的报告，这个报告的确应该面对的是自己，原因是现在的软件系统、模块已经不可能在一两天内完成，PM关心的是整个进度而不是单一的每个个体在做什么事情（当然也有例外）。如果看过GTD(Get Things Done)这套理论的应该不难理解日报对个人工作的重要性。在一些公司（包含A和B）都提供了日报的机制上报，不同的是，A的日报系统不是强制要求上报的，只是一个简单的参考，或者说是，一个给员工自己记录自己工作纪要的小工具，事实上，这个工具被使用的次数非常少。相比之下，有行政支持的B的日报系统就有点人声鼎沸的感觉，B强制要求员工每日下班之前填写日报，否则绩效被扣。可以想像，这个工作到底有多么痛苦，所以我为我自己的项目组里面的人写了一个程序，使用windows程序进行填报，并有自动复制、提醒和自动登录到Web填充“官方”需要的日报的功能。反倒这个被我们用的很好。
周报的制度不用多说，周报上写什么也不用多说，千锤百炼了。
对于大多数人而言，月报其实本身就是周报或者日报的累计，但是对于单个项目而言，整体的月报还是有必要的。所以我的建议是对于PM要求每月对整个项目的情况进行月总结，月总结和周报的内容一致，应该包含几个部分：本期完成的工作、预订本期完成而未完成的工作、延期的工作的原因，下期的工作和所需要的协助。
事情很多时候是和我们的初衷相背离的，报告制度的价值缺失的一种表现就是，报告作为一个流程来呈现。我们缺乏的是对报告的处理过程，而不是填报、上报的过程。一般而言，领导需要了解现状（本期工作、延期事由），同时也需要承诺需求（需要的协助），对于长期无法承诺的需求，只有两种可能，一是需求方忘记了，另外就是承诺方忘记了。所以无法承诺的需求或者无法处理的问题，是导致周报、月报失去其本身意义的根本症结所在。
而报告上报的形式也是值得商榷，当前使用Excel进行上报，不管是周报填报方对于自己周报的查询还是周报收集方对于周报的整理都是一个痛苦的事情，是否可以建立一个简单的系统，能够直接使用Web进行填报，这样减轻双方的工作量。
3. 需求管控
需求管理的根本原则在于界定范围。范围包括需求的时间要求、度量和相关性。需求管控涉及到需求辨析和需求处理两个部分。
3.1. 核心需求和本地化需求
对于单一的项目（没有本地化开发的项目）的需求管理可以翻看各种的同类书籍，这些书籍中记载了大量的实证的方法，我主要想描述本地化开发占用核心开发的工作量30%以上的项目，例如建管项目，的需求管控方法建议。
需求分成两类,本地化需求和核心需求，本地化需求是本地化版本中开发，其成品只在一个地方运行；而核心需求是指对核心版本变更的需求，其成品需要部署到产品的所有客户方。本地化需求一般在现场进行开发测试，而核心需求应该在公司内部进行统一开发测试。
3.2. 需求管理人员
设置统一的需求管理员对整个产品线的需求进行管控。需求管理人员除了熟悉当前系统中的处理的业务之外，更重要的是需要了解当前软件的构架。
需求管理员的职责：
1、 接受一线维护人员或者客户服务的经过初步整理的需求
2、 判断这些需求核心需求还是本地需求
3、 生成需求计划文档并交由一线维护人员或者客户服务递交给最终客户
4、 提交计划给施工部门进行施工
5、 维护需求库中的数据信息
6、 跟踪需求的开发进度信息
4. 代码开发
4.1. 重复开发
重复开发不仅是我们公司的问题，只要有些规模的公司都存在，原因很简单，各个项目组都在赶进度，没有时间进行相互之间的沟通，也缺乏一个协调机制协调这种沟通。
对于各个项目中的共通的开发模块的发现需要一个协调人员对此进行确认并提出方案，同时，对于开发这些共通模块的项目组要求这些共通模块必须承载另外的项目组所需要的功能。这无疑给开发工作和管理工作都带来了不小的工作量。项目掌控实际是人的掌控，合作开发和等待别的项目的成品都会给项目带来风险。关键看这些风险是否值得。
可以这么计算，减少一个模块的开发，实际是节省这个模块所消耗的人力。
4.2. 公共库
毫无疑问，搭建一个公共库技术难题反倒成了附属，开发的哲学却占据了主角。
搭建公共库必须回答以下三个问题：
1、 是否有必要搭建一个公共库？
2、 搭建的公共库能够包容哪些东西？
3、 如何搭建？
第一个问题比较好回答，有必要让各个项目中的重复开发的模块进行统一管理。
第二个问题相对比较好回答，公共库应该包含类似日志、数据库连接池、JavaScript Effect、转换函数、帮助类等等一些通用的东西，随着时间的推移，这个库的内容会逐渐扩大。
第三个问题最难回答，这里面包含两个问题，1、谁负责编码？2、谁负责维护管理？对于公共库的代码要求同时也是对负责编码的人员的如下：
1、 尽量兼容的技术体系，例如采用JDK6的功能开发公共库应该来说是有些冒失。
2、 尽量兼容大部分的需求（和XP严重违背）
3、 统一的代码风格，至少让代码可读性提高。
4、 代码库升级的向下兼容性。即便是设计的很糟烂，也应该在升级的时候给老版本留点时间
5、 严格保证进度。毕竟不是一个项目组在使用代码，其他项目可能正在等待。
6、 原则上使用一台清制度，谁写的代码由谁负责升级
同时，公共库的编码人员需要很强的设计抽象能力，否则是不可能写出“通用”的代码的。一个XP的忠实Fans显然不是公共库编码人员的合理选择。
独立一个小组或者部门出来进行公共库的编码建设会直接导致经济问题，是不可取。应该是在各个项目组中协调技术人员进行开发。协调的工作应该由公共库的维护管理人员承担，这个职位应该具备以下职责：
1、 公共库的模块评估，是否可以将特定的模块放入公共库，放多少进入公共库
2、 公共库开发人员指定。
3、 公共库各个模块版本信息维护并保证升级之后能够实时通知各个相关模块的项目负责人。
4、 各个模块的代码审核
4.3. 本地化开发
多个本地化版本的系统比较难以设计，也难以开发，原因是：
1、 各个本地化版本的需求不一致，抽象这些需求需要时间
2、 由于工程进度安排，各个本地化版本可能纠缠在一起开发，导致代码不能剥离。
从前面的需求我们可以指定需求的管控人员度对需求进行分类。那么代码层面也可以按照相同的做法。
首先我们要抛弃的是XP的务实的观点，兼容需求好的代码不是当前能用的代码，而是考虑到各个方面的代码（至少有个接口或者Mock伪装），所以初期对核心模块的界定尤其重要。一个简单的方法就是直接使用已有需求抽取共通的需求组成核心模块。核心模块之外的定义为各个本地化模块（数量可能不小），各个本地化模块使用相同的核心模块提供的接口，同时，这些本地化模块的代码是完全独立的。
在界定完成核心模块之后新进的需求，根据需求人员的分类归并到核心模块和本地化模块中。同时，本地化模块在特定的时候可以升级为核心模块。
注意核心模块可以部署到任何一个本地化需求所在地，而本地化需求只能不是到本地化需求所在地（即使两个地方个别需求完全一致，出于对结构的完整性考虑，还是采用复制代码的策略复制两份完全相同的代码。）
在Java代码中，我们采用*.localize包下面的为各个地方的本地化模块，其他的包为核心模块，例如*.localize.sichuan标识是四川的包，其他各省的包和此包平行。这样可以使用CVS的分支功能或者手工拷贝的方式对各个地方的本地化包进行独立部署。
核心模块和本地化模块之间的挂接采用外部配置的方式，例如XML文件、数据库等等。这样减少核心模块和本地化模块之间的耦合。
5. 现场维护
现场维护的职责需要明确，同时现场维护人员面对的后方支持人员也应该确定，一般来说现场维护人员的后台支持人员为项目经理。一旦现场出现需要协助的，应该由项目经理向研发提出资源请求，而不是现场人员直接提出资源请求。另外一点，不管是开发人员还是项目经理，接到现场人员的Bug陈述的时候，严禁说“不可能”，原因很简单，现场问题已经出了。
现场人员必须明确一点，在现场就是代表公司，现场的工作情况，就是客户所看到的公司的形象。
现场人员除了日常维护，还有一个工作就是接受本地化需求。需求处理的流程上面已经谈到，的确，那是一个理想化的需求，客户很多时候需要立即得到答复。
首先我们应该对需求的提出方进行限定，限定需求的提出来自于客户方固定的接口（固定的接口部门，最好是固定的接口人），这个接口收集客户的需求并通过一种预订的方式传递给现场人员。如果不能确定这个，将会导致各个业务部门的客户都可以随意提出需求，造成需求的混乱。
然后很多时候客户的需求是不理智的，一般情况下是官越大提出的需求越不靠谱越不成熟，这些需求时限要求紧，大有不出结果就砍掉项目的架势，而且这些需求可能就是很短的时间内需要，然后就再也不需要了，或者不久之后就对这些需求进行修正。应对这种需求只有推诿，不管以何种方式，至少要让客户明白，这些需求的完成需要时间。另外需要明确这些需求的性质，是临时需求还是持续需求，这点可以找接口人确认。确认了以上的问题之后就可以继续走流程了。
原则上，对于新增需求或者变更需求都需要双方签字盖章的需求工单。
现场工作的难做主要是客户关系的难处，其实换个角度来看问题，我们直接面对的客户大部分是施工人员、中层经理，这些人和我们一样，脑袋上悬着指标考核，既然他们分管了当前的项目，当前项目的成败就一定和他自身的利益相关。我们需要向这些人传递这么一个信息，“这个项目做不好，你我都讨不了好，所以你的需求应该慎重的提出，相关报告也应该慎重”。传递这个信息是一个漫长的过程，如果你在一两天之内让用户确知了这么一个信息，那么客户肯定认为你是在威胁他。
一旦大家明确了利害关系，后面的事情相对来说就简单了。客户会很“理智”的听你延期的解释，并将这个讯息传达给他的领导。
在很长一段时间里面，我都认为在客户方掌控大局的人应该是那些我们经常见不到的人，直到我的项目第一次被群起攻击的时候，我认识到我每天接触的这些小PP其实对项目有很大的决定能力。就像我们在客户现场代表了我们公司一样，这些人也是冰山的一角。很多时候这些人虽然没有决策权，但是他们的意见却对决策影响较大。
人是一种非常可爱的动物，会将自己的欲望进行控制，一旦满足这些欲望却又窃喜不止。有一个女哲人说“每个人都是偷窥狂（原词不雅，呵呵）”。在某些时机适当的向客户透露一些小秘密是个非常有趣的活动，作为报答，对方会将一些你所不知道的东西回馈于你。其实目的就在此处。这个活动有趣在于，参与泄漏秘密的双方和各自的公司都得到利益，如何看待利益的大小是另外一个层面的事情了。需要注意的是，一旦你故作神秘的透露了一些对方已知的信息或者事后这些信息被证明无效，你在对方心中的评价将逐步降低。
严格的来说，在涉及到各自公司层面上的事情的时候，任何“好朋友”都会有不同程度的保留。可能这样说让人有些丧气，但是换个角度可以实证这个观点，参与者——无论哪方——都会把对方提供的信息落实到自己的工作中，既然大家都知道这个规则，出于自身的安全方面考虑，都会对一些信息进行刻意的掩藏。
是的，我的意思很明白，玩玩泄密的小把戏大家都很开心，但是真正涉及层面广了，就只会让对方开心了。
这个游戏不是田忌赛马。
现场肯定涉及到一些报告性质的文档，我个人觉得报告越是详细越好，不用在乎客户是否看这些报告，的确他们只关心报告中的结论，对那些标红的系统日志和数据并不敏感，但是如果他们感觉到现场人员的专业程度，无形之中会增加对现场人员的信任度。这点信任度的确来之不易，它可以决定客户对现场人员传递的信息的可信度。
6. 我们是否站在同一边？
6.1. Are we clear?
如果可以把我们和我们的领导之间的问题归结于沟通的问题，那么以下的问题仿佛是可以得到一定程度的解决，但是事实好像有些相反。不管你承认不承认，我们所处的环境中总是存在或多或少的官本位思想的影响，是的，我是说我们辛苦得出来的条款对于领导来说几乎无效。
下属和领导在一个问题上能否达成一致，在大部分的时候不成问题，因为总是有一方会有妥协。但是一些情况之下却会造成负面效应，尤其是在处理客户需求的时候。在我的工作经历中，我不止一次的遭受到这样的场景：我的顶头上司贸然（对于决策者来说，这样的批评的确有些过头）答应了客户的要求，然后让我们承受不能准时交付甚至无法交付所带来的风险和责难。从这个问题的成因来看，应该是领导对于实际情况的掌控程度不足，但是更深的层面考虑这个问题，可能体现在领导对待事情的心态方面。一种可能的情况是，领导认为，他所承诺的东西如果没有落到书本上就应该什么不存在施工与否的哲学命题，但是很多时候却事与愿违，客户可能会直接提出此项要求，同时提出对领导信用度的质疑，于是这个命题转化成如何去做的命题了；另外一种可能的情况是，领导的自信心或者虚荣心严重超出其对待问题、认识问题的能力。
是的，还是我们妥协，基本没有办法。
另外的一个情况更加令人尴尬，领导对于数学的理论实证的热情远远超出他们对待问题的细致程度。我们不断的申请资源，领导也慷慨的追加资源。很多时候，领导天真的以为投入和产出应该是线性分布的。的确令人尴尬，尤其是面对新进员工是个新手的时候，可能计划还要延期，而领导的确不喜欢听到这些词汇。
客户需要承诺、领导也需要承诺，他们所处的立场不一样，但是对于项目延期或者承诺的打折的反应却是惊人的相似。
对于客户而言，承诺有的时候的确像是一个公益行为，这个行为可以在一段时间内让大家保持一种恒定的安定状态。但是对于属于我们自己阵营的领导而言，有些让人费解。
代有谏官，唯魏征名垂青史，盖太宗唯一人耳！
6.2. 规则就是拿来打破的
令人尴尬的是，规则的打破者大多数时候就是规则制定者本身。一个典型的例子是会议守则，领导要求参会者手机改成震动或者直接关机，但是领导坐在首位大声的讲电话（手机的确是震动）算不算违反守则？
很多时候领导没有意识到自己本身也受规则的制约，原因很简单，制定规则的人在潜意识里面是凌驾于规则之上的。一个不好的现象是，领导的这种违规行为没有得到制止会形成一个习惯，甚至影响到其他的规则的实施。
另外的情况是，对于下属的违规行为领导放任的行为，例如在会议上讲了一个荤笑话的员工因为和领导长期关系密切而没有得到实时制止，可以想象，下次的荤笑话可能会更加精彩。
6.3. 孤独的舞者是危险的
能够看到问题和有心思去解决这些问题本身来说就是一个进步，但是真正解决这些问题却比较费工夫。改进是一个过程，直接感受改进效果的是人，对于改变的接受程度取决于一个人的个性和他的经验。对于被改进的受众如此，对于凌驾于（请原谅我用如此直接的词汇）改进实施之上的各个领导也是如此。对改进的接受程度直接影响到他们对于改进所采取的策略。
制定一个制度并不难，难的是如何去执行；任何改进都会涉及到不同层面的冲突，可能是利益冲突，也可能是习惯冲突。所以改进必须拥有一定的行政支持，而此项支持，对于大多数人来说都是奢侈的。之所以奢侈，一方面是因为得到真正的行政支持不仅需要行政授权人员对于改进的理解，同时还需要这些人能够准确的知道中间所经历的过程——关键是那些可能导致传统抵触的方面；另外一个方面，改进是一个长期的过程，这个过程中的行政参考是否能够一直保持原有的态度的确是一个问题——在很大程度上，领导和我们面对的客户一样，希望得到的承诺能够尽快的得到兑现，最好就是现在兑现。
秦杀商鞅，非诛其功！
我想我是在描述一个风险。
