关于项目人员离职的风险控制
一个项目进行中。人员的有来有去司空平常。有的时候一个项目结束了，人员几乎全换了。可能项目经理都换了。像我做的一个Sony的项目。结束的时候就省一个项目经理光杆司令了。哈哈。。。想起来自己也觉得好笑。
其实人员的流动对项目的损害很大的。尤其项目进行中的情况。人员刚刚熟悉业务，系统设计，编码进行的还算顺利。人员离开了，有人的接手工作把。得找合适的人吧。得重新熟悉吧。如果文挡做的全面还好说。如果文挡不全。接手起来就更加困难了。而且目前来看，在大多数项目的编码中。个人的个性编码还是比较多的，对在项目编码规范的执行力度都不大。使原来的设计面目全非了。
有人说文挡是防止这个的最好方式。只要文挡全面就好上手。其实我个人觉得还有其他的方法。就是在项目中两人成组的开发。有点类似于极限编程的意思。但是有不全是。极限编程是两个人同时开发一部分的功能代码。而这里我觉得只是针对于需求部分、设计方面和代码了解方面的。
两个人可以互相了解对方所负责的业务，互相的讲解对方的业务。这有以下好处。
一：可以加深对业务的了解程度。大家都知道，当你给别人讲解东西的时候最容易发现问题，而且对自己所讲解的内容更能加深理解。同时，听的人也可以给你提出问题，来加深对业务的理解。
二：可以增加程序之间的沟通，在这里认为分组的方式应该以业务的相关性为基础，相关性越强越应该分成一组，因为这样在业务的边界部分更容易沟通，达成一致意见。
三：可以控制离职风险，如果两人中的一人离职，项目中不会没有人不清楚业务，而且另外一人可以临时顶替，来保证项目的进度，当有接替的人的时候可以顺利接手。
当然，其中分组的的人员搭配个人觉得还有能力的区分问题，尽量技术能力有些距离，但不要太大，这样可以互补并提高成员的技术水平，同时有不因为技术差距太大而产生无法沟通，呵呵，高手总是不愿意和太低的对手过招的。这主要看项目经理的分配能力了。
两个人也要对彼此的代码熟悉。好处和需求防买内的差不多。另外就是可以保证有好的方法可以相互借鉴，同时对于代码规范的执行也有好处，对于代码的了解程度可以根据项目的不同情况由项目经理来决定，同时制定考核标准，例如要了解主要业务逻辑的代码。但业务和设计必须全面了解。同事也要定期考核，也就是执行力。执行很重要，在好的东西也的考执行来实现。
总之两人组合的开发模式认为可以避免离职风险，能有效的衔接后续人员的接手问题，同时也能够提高人员的对项目的理解和技术水平。
大家有什么好的建议和意见？？？？小弟恭听之。。。。。
其实人员的流动对项目的损害很大的。尤其项目进行中的情况。人员刚刚熟悉业务，系统设计，编码进行的还算顺利。人员离开了，有人的接手工作把。得找合适的人吧。得重新熟悉吧。如果文挡做的全面还好说。如果文挡不全。接手起来就更加困难了。而且目前来看，在大多数项目的编码中。个人的个性编码还是比较多的，对在项目编码规范的执行力度都不大。使原来的设计面目全非了。
有人说文挡是防止这个的最好方式。只要文挡全面就好上手。其实我个人觉得还有其他的方法。就是在项目中两人成组的开发。有点类似于极限编程的意思。但是有不全是。极限编程是两个人同时开发一部分的功能代码。而这里我觉得只是针对于需求部分、设计方面和代码了解方面的。
两个人可以互相了解对方所负责的业务，互相的讲解对方的业务。这有以下好处。
一：可以加深对业务的了解程度。大家都知道，当你给别人讲解东西的时候最容易发现问题，而且对自己所讲解的内容更能加深理解。同时，听的人也可以给你提出问题，来加深对业务的理解。
二：可以增加程序之间的沟通，在这里认为分组的方式应该以业务的相关性为基础，相关性越强越应该分成一组，因为这样在业务的边界部分更容易沟通，达成一致意见。
三：可以控制离职风险，如果两人中的一人离职，项目中不会没有人不清楚业务，而且另外一人可以临时顶替，来保证项目的进度，当有接替的人的时候可以顺利接手。
当然，其中分组的的人员搭配个人觉得还有能力的区分问题，尽量技术能力有些距离，但不要太大，这样可以互补并提高成员的技术水平，同时有不因为技术差距太大而产生无法沟通，呵呵，高手总是不愿意和太低的对手过招的。这主要看项目经理的分配能力了。
两个人也要对彼此的代码熟悉。好处和需求防买内的差不多。另外就是可以保证有好的方法可以相互借鉴，同时对于代码规范的执行也有好处，对于代码的了解程度可以根据项目的不同情况由项目经理来决定，同时制定考核标准，例如要了解主要业务逻辑的代码。但业务和设计必须全面了解。同事也要定期考核，也就是执行力。执行很重要，在好的东西也的考执行来实现。
总之两人组合的开发模式认为可以避免离职风险，能有效的衔接后续人员的接手问题，同时也能够提高人员的对项目的理解和技术水平。
大家有什么好的建议和意见？？？？小弟恭听之。。。。。
