近期项目管理上的一些感触

来到这家公司已经快2年了，期间也做了不少的项目，在这些项目中，零零散散的碰到了一些可以改进的问题，现在把这些问题整理一下，以便后来人可以借鉴，少走弯路。

1. 用人 / 选人

在这点上我相信大部分的项目经理/产品经理都没有太多的话语权，基本上就是部门/HR的BOSS给什么人，自己就得用什么人，但在用人的技巧上还是有些可以提高的。

a) 人员结构

大部分的团队的结构都是金字塔型的结构，这本身没什么问题，但人员的比例怎么分，每个人应该在什么位置，却是两个很难把握的点。

有些团队一个人会带很多人，美其名曰垂直管理，但每个人的精力有限，肯定会顾此失彼，个人建议每个人最好带3个人以下，如果在有自己的开发/管理任务的时候，2个人最好。

每个队员应处的位置，现在很多团队都会出现，老员工带新员工，但所谓的老员工，并不一定能力一定比新员工强，如果让这样的老员工来带新人，有可能这个老员工将成为新员工成长的瓶颈（跟对一个领导很重要）。

b) 经验

上面的问题中说到的老员工，其实大家或多或少的都会觉得工作时间越久的人，应该经验就越多。但通过这些年的观察发现很多人仅仅只是一个经验用了N年，而不是真的拥有了多年的经验。

经验本身是不可度量的，而经验值则是可以量化的，怎么衡量一个人的经验值呢?拿自己做标准肯定不合适，因为人都会带着有色眼镜看自己，由团队人员相互评分，以团队内大家公认的经验最丰富的人作为10分满分进行相互打分，则是比较好的一个做法，当然不能盲目的打分，需要在明确的说明每一分的得分点。打分应不记名，阅后即焚。

c) 职位

团队建设中，并不是每个人都适合职位上升的，有很多人在当前的岗位干的非常出色，这时大家(可能包括他自己)也会觉得自己可以胜任更高一级的职位，但是事实上往往有很多人并不一定适合更高一级的职位，因此，团队的领导者有责任也有义务为每位员工做出合理的职业规划。

同样职位的高低不应该直接决定拿到的薪水。薪水的多少应该取决于为公司创造的价值。

2. 项目

IT项目中，特别是纯软件项目中，大家见到最多的借口无外乎，时间紧，需求变更大。

其中时间紧的问题，除了商务谈判/政治 因素直接指定的外，大部分是因为估算不准引起的。

1）估算

估算本身应该是一种手段/工具，用以辅助项目计划的指定，而且随着项目的发展，估算的准确性将会越来越准确，所以什么时候可以得到最精确地值？答案是项目结束后。

项目计划本身也应该是辅助管理的一种手段，但现在大部分团队管理者都是抱着把实际工期往计划上硬靠得态度在管理项目，这种样的话，就会存在如果估算不准，后期不管怎么样加班加点也都赶不回进度，而且项目中只要存在一点点风险，都有可能让计划变得无法执行。

怎么才能有一个合理的计划呢？首先先从估算本身修改，我们现在项目的估算是采用的人日作为单位，但这种单位是可以变化的，例如一个生产性很高的员工的人日和一个生产性很低的员工的人日产出是绝对不会相同的。所以采用人日/人月这种单位本身就应该有问题的，因为这个单位是可以变化的，打个比方就是1米的标准单位是不停的变化的，如果你建设一座大楼，每个建筑工人/设计师对1米的定义都是根据他们自己的理解力指定的，这栋大厦绝对没可能建成的。

建议的估算单位是以开发中最简单的一个功能模块作为评估单位，并通过统计计算出其他模块的相对值。

例如开发中最简单的一般是一个数据库单表的增删改查操作，可以将这个功能定义为一个标准单位。其他的如文件操作，跨系统调用等进行量化。这样可以得出一个项目的合理的功能量。

得到了功能之后，就是评估每个团队人员的开发效率，也就是生产性，得到每个队员生产一个标准单位所使用的时间后，就可以得到一个日期的估算值。这样的估算相对来说不会偏离太多。

2） 需求变更大

不变的需求基本上已经是这个产业链中最不值钱的地方了，所以如果你碰到的需求总是在不停的变化的话，说明你得工作还是有价值的。

对于需求的变化，除了现在已有的流程上的层层把关，采用敏捷开发等以外，建议引入DDD，即领域驱动开发，以及精益看板和故事版。

当然，不论你采用什么方式，单元测试和自动化测试是一定要做的。

3. 研发流程与质量管理

1) 流程改进

现在很多号称采用了敏捷的团队，实际接触后会发现，他们采用的仅仅只是小瀑布，需求开发测试，每个步骤之间都有着明确的分界线，在一个节点没有完成之前，其他人员都是处在待机状态，这样的团队很容易出现队员之间的相互指责，因为大家谁都不想背负错误的代价，所以好的做法是每个人的角色都不要划分的太清楚，每个团队的人数以10人左右为宜，团队中的需求/开发/测试人员相互混淆自身的工作职责，出了问题团队一起承担责任。

在需求阶段，开发和测试可以进行需求的模拟，借以理解用户的真实想法；开发阶段，需求和测试可以快速的查看产出物，并在其中提出意见/建议；测试阶段，需求开发一起测试，查找BUG。当然如果需求人员不足的话，但是测试和开发混合也是可以的；但需要提醒的是，找出的问题不要以BUG计算，尽可能的按照跟踪事项提出，原因很简单，没有人愿意承认自己存在问题，自己的产出物存在BUG。

2）开发质量把控

开发质量想把控的好，单元测试，自动测试少不了，当然还需要自动化部署，自动化验证。

自动化工作做好了，自然可以快速迭代快速开发。

不过目前我的团队最需要做的是：消灭编译警告！如果连编译器给出的警告都置之不理的话，静态代码分析什么的都是shit。

想做好更多的自动化，需要先进行代码解耦，团队解耦，自动化工具的投入。

代码解耦不用多说，建议采用DDD，领域驱动开发进行解耦，目前来说这是最快的，在解耦重构的时候，一定要补充好单元测试和集成测试代码。对外提供的接口至少要向下兼容一个版本。

团队解耦，每个团队都要为自己的产出负责。如果涉及多个团队一起发布/研发的时候，则需要将这些团队的人员混编成一个临时的小组，但这样的成本将会很高，但在代码已经解耦的情况下，团队之间的相互依赖将会减少很多。

自动化工具的投入，这个因为涉及到各种 平台就自己慢慢摸索好了。

自动化测试，单元测试一定是快速的不需要配置的。集成测试则至少每天执行一次。

自动化发布，建议在版本管理器上采用发布TAG管理，即将可以发布的代码的TAG保存在一个发布用版本管理工具上，每个团队在自己的团队的代码分支上做开发。这样如果某个团队不能按时发布自己的代码，主分支也不需要回滚，只需要将配置管理服务器中得TAG删除即可，加上之前的要求接口至少向下兼容一个版本，也可以保证不会对线上产品造成影响。

自动化部署，这个不用多说，SQL脚本的部署/回滚，代码的部署/回滚，都应该自动化的完成，而且要高效的完成。备注，测试环境应尽可能的和线上环境一致，而不是采用单独的环境，这样测试才会更有效的发现问题。 如何和线上环境保持一致？答案目前只有一个，云；只有云才可以快速的高效的完成一个环境分复制，否则按照传统的做法，等你采购了服务器回来，项目都该过期了。

自动化验证，这个也不用多说了，自动脚本验证，主要验证各个配置是否已经完备，系统是否正常启动，基本/关键操作是否可以正常进行，此处可以通过创建专用的验证用用户来验证相关的环境是否正常。

监控与日志

这个不用废话了，对于大部分的系统来说，至少需要1个建议至少有2个服务负责监控主服务是否正常，并记录用户/系统的相关操作日志，如果出现崩溃/异常及时报警，及时采集相关信息，日志中至少应该记录了该操作的输入数据，以及尽可能多得环境数据(环境变量，数据字典等)

以上就是这些年对于团队管理/建设的一些想法，希望对后来人有用。