项目经理：邓欣
PM介绍：邓欣于2016年年底加入软通动力，目前担任网络BD NOS工具域PO、运维NLS二期项目PM。邓欣在工作中勤于思考，善于沟通交流，有非常强的责任心。进入公司后，在较短的时间内即有突出表现，接手运维NLS二期项目的管理工作后，在总结一期项目得失的基础上，合理安排人员分工、业务赋能，使二期项目的交付工作得以顺利进行。
1、请先简单介绍一下运维NLS项目的一些基本情况。
运维NLS二期项目是继承项目，于今年6月立项，立项前我们总结了一期项目的经验教训，对二期可能出现的功能点进行了预估，提前识别出了业务风险，并据此做了详细的赋能与帮扶计划，尤其是贯穿项目过程中的关键点业务培训和技术攻关点计划得到客户的认可，因此顺利拿到该项目。由于项目后期可能会对接商用，涉及到安全加固问题，客户要求比较严格，我们团队一直在积极学习安全相关知识，对最终的顺利交付充满信心。
运维NLS项目的功能是基于Fenix版本完成NLS设备的基本情况监控，提高故障运维能力，对故障信息进行图形化展示，帮助开发、测试迅速定位故障，排除故障点，比如说客户的Fenix开发和测试运行在NLS设备时可能会出现一些问题，可能是某个fabric链路断了，也可能是某个资源占用情况变糟了，这个时候就可以通过我们的系统监视展示出来，并定位是什么资源引起的故障。我们项目的价值也体现在这一点上，可以完成Fenix管道OS运维能力的提升，全面可视化的展示HostOS层面、VM层面、VNF层面、进程层面、KPI层面的系统状态，通过大数据的日志挖掘和故障树模式对系统故障进行定界、初步定为、提前预测、友好展示。
2、承接项目时的主要挑战是什么，采取的措施有哪些？
承接项目之时，业务方面的主要挑战就是前期对Fenix一些业务不了解，整个系统非常大，里面各个模块的衔接肯定会存在一些问题，初期我们请客户的专家帮扶培训过一次，但是过后发现效果并不是很好，在开发和需求讨论过程中还是会出现需求不太明确的情况。后期我们组织了两次组内讨论，反而讨论出一些成果，这可能就是实践与全员参与的力量。但是我们也预估到可能会存在一些盲点，专攻盲点分析与收集，再请客户的专家帮忙梳理，效果好了很多。
技术方面的主要挑战是第二期项目涉及商用，安全要求很高，包括一些密钥、登录证书等，在技术管理上这些确实是我们的盲点。通过大概两星期，这些重要的技术难点基本被攻关掉了，但是后期陆续还会有一些如FMA共享、接口的共享信息等难点，因此还是有一定难度的。
3、一期项目你们总结了哪些经验，对二期项目有什么帮助？
我加入的时候正好是一期项目尾声，我也组织了组员讨论了在一期项目过程中大家发现的问题，主要分三块：
首先是业务层面。一是项目一开始时我们对业务不是很了解，业务分工也不是很明确，造成代码偶尔会有冲突，二期项目时我们任务分工，通过横向和纵向去拆分，降低每个人工作的耦合性，再出现代码冲突的可能性就降低了。二是总结了一期培训存在的一些问题，二期项目通过客户赋能和组内讨论、培训，再加上客户接口人的指导，短时间把业务能力提升起来了。第三，一期项目时每个人对业务的了解只局限于模块内部，不会关注其他人的业务情况，如果某个模块的负责人请假或临时有事，会存在很大的风险，因此二期项目时我就把模块之间的交流组织起来了，实行模块业务的人员备份。
其次是管理方面。一期项目时有个别员工反映自己技能提升有限，二期时我们根据个人能力地图，有针对性的为每个人制定了能力提升计划。
再就是沟通方面，二期项目我会从PM角度更多的去了解员工技能、业务情况，还有生活情况，做到心中有数，把所有风险都降到最低。同时加强组内成员之间的交流，使团队凝聚力增强，提升稳定性。
4、项目团队如何“通过环境氛围激励员工提高效率”？
我们项目组有老员工也有新员工，我觉得员工工作年限长了后就会有定式，我要把老员工的积极性调动起来，也要把新员工的奋斗精神激发出来。我想到的有两点，第一个是正向激励，根据任务完成情况，对一定时间内完成任务多少情况给予积分，积分直接和绩效挂钩，这样可以激发老员工的活力，也激励新员工更加努力学习，不断超越。第二个是负面晾晒，有些项目经理认为负面晾晒会影响组织团结，会伤及成员面子，我想到的办法是晾晒只对任务不对人，我会定期把所有任务的完成情况晾晒出来，哪个任务完成情况良好，哪个任务延期多少天，都会明确的显示出来，这样就会避免伤及组内团结，也达到激励与批评的目的。
5、项目组在人员管理方面有没有什么特殊的方法？
如果一个员工长期在一个职位，刚开始工作两三个月肯定会有新鲜感，也会比较稳定，但是长期固定的重复一件工作，他肯定不会愿意，也会因为太过熟悉而忽略一些小细节，因此我们组内有这样的机制：在了解不同模块业务的基础上，我会让两个人对调轮岗，这对个人业务、技能提高都有好处。
还有就是关键角色A、B角备份，比如说项目有一个DE，我会挑选出另外一个级别比他低的人做DE角色备份，这样对级别较低的人来说可以提升积极性与能力，对DE来说也产生一种危机感，激励他做到更好。
在解决组内成员冲突方面我也有一些特殊的方法。组内成员在业务方面出现冲突时，我采取的方法首先是回避，让冲突双方单独解决对任务的分歧，如果冲突升级，我再和他们分别沟通，收集想法，调和解决。初期回避之后我并不是放手不管了，而是不断观察，在他们自己解决冲突后再去沟通、总结，因为我觉得如果一开始就介入并不是好的办法，下次他们可能还会有冲突，我不可能每次都去调和他们各自针对业务理解上的冲突，一定要让他们理清自己的思路，找到最好的方法。
6、目前项目的主要风险是什么，会对最终交付结果产生影响吗？
我们这个项目依赖客户的主系统过点时间，一开始立项时这个风险我们并没有识别出来。在开发过程中，我们会对外提供一些接口，当时知道需求对接方，但是具体内容和完成时间是不确定的，到后面才发现接口这些需求要通过子系统的一些依赖才能完成。客户方如果通过TR1的时间延期了，我们原本定在项目里程碑迭代一完成的对应任务，涉及的需求澄清、具体实现方式就会相应的被延迟，只能把迭代一该完成的需求拆分到迭代二、三，这个很难把控，并且很被动，如果客户方迟迟不能给出需求的话，只能申请需求变更。发生这样的情况我们的项目排期、人员调度会受到影响，是否会影响交付结果还是要看客户主系统的过点安排。
7、谈谈你们是如何做质量策划的？
质量方面我们组比较注重风险管控。之前主要是项目经理分析风险，现在我们会定期组织全员参加的风险评估会，让所有人从自身角度分析他所看到的业务、技术、人员风险。
另外在立项结束后，我制定出来严格的项目计划，所有的任务执行都要按照项目计划来，我对任务进行拆分，精细到以人/天为单位。
在代码质量这一块，我们在本地搭建了一套jenkins检查库，每次发版本时会通过检查库来检查数据，保证每个迭代验收时不会出现大量检查问题。有些项目在结项时检查出来的问题有上万个，要把这么多问题在短时间内消化掉难度太大。通过检查库，我们把这项工作分散到平时的开发过程中，降低了风险，保证了质量。
从目前来看，我们在质量方面可能会存在的问题主要是代码复杂度，我们的代码逻辑比较复杂，后面还要做好调整。
8、你觉得项目经理应该如何在FP转型中发挥更大作用？
首先是需求澄清。我觉得我们最严重的问题之一就是立项时的业务澄清做的不够好，做的过程中还是会出现拿不准的问题，再花大量时间和客户沟通，相当于是需求澄清花费了双倍时间。因此项目经理应该在初期时摸清楚需求，把关好需求澄清。
第二，项目经理应有充分利用资源的意识。我们在业务、意识方面和客户有一定差距，客户的赋能渠道会比较多，我就在思考如何建立渠道，利用客户的培训资源来提升我们的整体能力。
FP转型后，PM不能只关注自己的任务量，要从项目角度去关注全局，因此责任心一定要强，如果没有责任心或者责任心偏弱，我觉得还是不要做PM这个岗位，无法树立榜样，也不能很好的指导员工、应对项目困难，最终的交付结果肯定不好。（本文于2017-08-31首次发布）
