|
一、 我是软件项目管理中的“第三类人”项目管理者联盟
从看到征文通知的一刻开始，我就一直在纠结自己的征文要怎么写，在纠结中关注着所有投稿的文章。投稿人员都有一个共同点，那就是“我是项目经理”。这让我有些未战先败的感觉，因为我不是项目经理，而且很有可能在我所处的环境中永远也没有机会成为一名项目经理。那我究竟是什么职业，处在怎样的环境中呢。下面向大家介绍一下。项目管理者联盟
我所在的是一家软件公司，我们在一些行业领域有自己的固定客户，所以按所研发系统服务的用户业务来划分一级机构，这些一级机构都可以算成一个生产单位，每个生产单位下都设一个部门，叫生产管控部，其主要职责是管理一级机构的所有项目，使领导能够从这个部门了解到目前公司各个项目的进展情况，而不用叫着各个项目经理挨个问一遍;同时要让项目按照公司的规范化要求来开展。我就是生产管控部的一员。我们的组织结构图可以这样表示。项目管理者联盟
项目管理者联盟
看到这，大家会觉得生产管控部和项目管理办公室(PMO)类似，确实如此。但我们又与理论上的PMO有着差别，成为我们艰难成长的障碍，让我觉得我们是促进项目管理走向正规军的第三类人。项目管理者联盟
从图中可以看出，我们可以说是项目管理中提到的职能式结构，项目只是一种确保工作顺利推进的方式，很少有跨部门合作的项目，多数项目都是有职能部门归属的。生产管控部是各个一级机构的PMO，只能在一级机构范围内执行自己的职责。我们负责识别和制定项目管理方法、最佳实践和标准，通过审计，监督对项目管理标准、政策等的遵守程度，在项目间协作时，作为一级机构对外的统一接口。由于生产管控部大多数员工并没有代码开发经历，这在软件公司算是一个致命的缺陷吧，在技术人员看来，没有真正的项目经历，都是在项目的外围感受进度的延期、范围变化带来的疯狂加班，因此监督对项目管理制度的遵循程度很难得到认可，指导、辅导、培训、协调项目间资源就更不要说了。在软件公司，几乎从项目经理到部门经理，甚至到副总，都是由技术人员晋升的，部门经理与副总们或多或少都有机会，在管理能力上提升、锻炼逐步适应自己的岗位，而项目经理更多的角色类似于技术经理，要分心钻研技术，是项目的第一责任人，很难有时间思考如何通过提升管理能力来提升项目效率。再加之公司缺乏对失败项目的清晰定义，及相关数据的收集，没有确切的数据证明因为项目经理管理能力的低下造成项目成本的提高、进度的延误、质量不高等。因此与项目经理的沟通也很难在同一个层次上。就是在这样的环境中，因为生产管控部人员的先天缺陷，与项目经理对项目管理的片面认识，使我们无法静下心来客观的沟通项目管理工作。项目管理人员几乎没有机会实践项目管理方法，更多是作为项目经理的秘书或者部门经理的秘书，在他们需要进行工作汇报时统计数据，证明项目是怎样的成功。工作时只能祈祷遇到一个有着管理意识的项目经理，这曾一度让我很难适应，无所适从，不知道如何给自己定位。项目管理者联盟
这就是我想表达的软件项目管理中的“第三类人”，艰难成长的PMO成员。但人总是要给自己找出路的，否则永远只能苦闷得无法成长。自己还是非常喜欢项目管理的，重新分析自己的环境，变换工作的手段与技巧，下面就是我在项目管理平台研发项目中吸取的一些失败经验，在后续重新思考方法后，觉得取得了一些效果的经历。项目管理者联盟
二、 项目管理平台研发项目项目管理者联盟
项目管理平台研发是我所在部门的一个软件项目，看名字大家也能猜出来，就是研发一个项目管理系统，领导让我们采取设计与开发分离的模式研发项目，也就是我们说的大瀑布式。采用这样的模式，是由于通过粗略的财务统计，公司发现我们研发的系统，在后期运维时投入的成长比研发的成本大很多，而且成上升趋势。领导们认为这是由于前期需求、设计过程中质量不过关，造成后期运维成本成几何级增长的原因，当然还有资料不全的原因。我们其他的项目研发模式可以说是更偏向迭代、敏捷开发。很多项目没有留下需求资料，留下的设计资料大多数还与真正的开发成果对不起来，我们更崇尚先上线再不断修改，在这个过程中可能还有非成手的新员工加入，代码质量很难保证。这一系列的原因，导致当系统上线后，进入运维期，开发人员几乎无法脱离这个项目，直到培养出成手接替他维护这个系统;还有当系统出现缺陷时，由于没有相应的资料记载，我们不知道改了这段代码会带来什么问题，只能注释掉出问题的代码，重新编写新的代码来修复缺陷，这样的问题多了以后，注释的代码也越来越多，新的代码越来越多，已经没有人敢动代码了，再后期系统出现的缺陷越来越难在短期内修复。大家可能会说我描述的这些似乎是中国软件公司的常见现象，是个难题吧。我们公司想用的解决办法就是规范过程，通过物理的手段把每个过程都规范起来，即需求、设计、开发分别由不同的组织承担，通过组织的责任划分来促进每个过程的质量提升。我们取名为设计与开发分离模式。项目管理者联盟
三、 项目管理是系统工程，在制定项目活动计划之前，必须先考虑项目的过程计划，即必须先确定用什么方法和过程来完成项目项目管理者联盟
前面说了，我们要采用设计与开发分离模式，尽管我们常讲瀑布模式，但是需求文档到底写到什么程度设计人员才能看明白，而设计文档到底写到什么程度开发人员才能看明白，最终保证开发出来用户想要的系统。关于这样的模式，大家还有争议中，直到项目开始，也没有相关的人员来统一参与人员的思想，在项目立项发文时，项目组成员只有我们部门注明了明确的人员姓名，而其他组织只是显示了组织名称，表明这个组织参与了这个项目。在项目开始后，我们需求、设计、开发三方人员没有坐下来，认真的商谈如何编写各个环节的资料，才能确保下一环节的工作顺利开展。因此在项目的进展过程中我们经过三次的工作流程重新设计，最终确定有界面原型来体现需求，设计人员在界面原型上增加设计信息，如按钮调用的服务、关联的数据表等，设计数据表，编写程序伪码，综合这三方面交接给开发人员，才使开发进行下去。而这时，原计划的设计时间，2/3已经过去了，确定最后这样的模式时，针对前期的工作从文档编写上来说，相当于推倒重来，我们2/3的时间没有产生有价值的实物成果。痛苦的还在开发交付，由于前期占用很多的时间沟通设计如何交付给开发环节，开发可用的时间也不多了，开发只能分批次交付，测试当然也只能分批次测试了，当测试接到可测成果时，发现了大量的缺陷，我们面临新功能和缺陷同时开工的问题，开发人员单方决定了先开发新功能，缺陷暂时放着。同时在这个过程中，测试还发现了需求、设计、及开发与设计不否的缺陷，造成了开发与设计两个环节之间就缺陷的性质扯皮，虽然工作在推进，不可否认，这样的扯皮还是消耗了我们部分时间，最终到验收时，我们也只能保证主要的业务流程通顺，还有很多影响用户使用的缺陷未修复。club.mypm.net
在这个过程中，我们可以看出来，从一开始由于对于项目过程的执行方式不统一，造成人力资源不确定，到各参与人员的具体工作及边界不清晰，导致时间延后，扯皮较多，到最终交付给用户时，并不是一个相对较好的成果。这让我不由得想起了项目管理中讲到的大项目管理与一般项目管理的区别，大型及复杂项目，在制定活动计划之前，必须先考虑项目的过程计划，也就是必须先确定用什么方法和过程来完成项目。我们的项目在公司当中从项目预算看，我们不是第一次做这样规模的项目，但从协作来看，我们是第一次跨部门协作，第一次使用设计与开发分离的模式推进项目，我们除了需要统一项目团队的思想，更需要在项目开始前，设计一个周全的过程计划，确定我们开展项目的具体方法和过程。这是我从这个项目中获得的第一点教训。项目管理论坛
前面我也描述了自己开展工作的尴尬，但我依然希望做一些实践，让人庆幸的是，由于在公司时间较长，各位项目经理都还年轻，凭借自己的工龄还能在某些时候做点强制措施。给项目经理们灌输这样的思想比较困难。后期，借由部门确定生产例会的制度，即每周召集各项目经理召开周会，部门通过这样的途径来了解部门各项工作进展，也希望部门内部员工互相了解彼此的工作。我们是每周一开会，我请各位项目经理对照计划来说明上周的工作进展情况，同时说明本周的工作安排。经过一段时间后，发现项目经理开始逐步思考较长一段时间的工作计划，当然这是与之前的情况比较。之前我们一个月的计划都很难说明白，执行时更是经常延期。通过这样的一个将各人工作透明化的方式，使项目经理开始思考较长一段时间的计划、思考手上的人力资源，也算是一种思考工作方式好的开端吧。项目管理者联盟
四、 需要明晰的描述项目目标blog.mypm.net
这个项目立项时，领导说我们要开发一个项目管理系统。系统研发完成后，我们申请了验收，领导要求我们暂不能验收，需要这个系统真正的用户使用后，出具用户报告，根据用户报告的结果我们才能申请验收。于是我们又立了新的项目，便是实施这个项目管理系统。而这是让我们抓狂的开始。我们遇到了难题，当系统要上线时，我们没有具备上线条件的系统，从前期开发时设计与开发分离，再到实施又是一个新的参与者，在实施上线前，关于消除影响上线的缺陷，后期由谁来接手持续运维，大家开始争议，在边扯皮边销缺的过程中，我们又花了近两个月的时间消除重大缺陷，先让系统具备上线条件。在这期间测试也不是很顺利，之前的测试用例因为业务变化，有些已经不能用了，为了识别出这些不适用的用例，需要有人说明变化的业务是哪些，而我们找不到任何资料，只能依靠设计人员现场讲解，而让人郁闷的是，设计人员也不能说明全部的变化，因为中途为了赶工，需求与开发人员直接对接，变化了哪些设计人员也不知道了，为此测试与设计人员还产生了冲突。大家总结这期间的各种冲突产生的原因时，有如下几种：PgMp.mypm.net
1. 设计和开发分离模式本来就不适用我们公司的情况。项目管理者联盟
2. 由于中途需求与开发人员对接了，没有通过设计人员，所以设计人员不知道系统变化情况说得过去。(在需求与开发对接的期间，我们派驻了设计人员一直在现场，最后还是说不明白。)转自项目管理者联盟
3. 由于我们之前收集需求时面对的用户，不是现在使用系统的用户，所以系统功能不适用现在的用户也说得过去。(我们立项曾讨论过这个项目成果的未来，这个项目研发的系统要用于公司的一个外部用户，也要在公司内部上线使用，这些没有写在书面文档中，参与人员心里基本明确。)项目管理者联盟
4. 系统上不了线，是由于设计与开发分离模式，开发归属另一个部门，项目经理也没有办法控制代码质量。pmp.mypm.net
看着上述各种各样的冲突及各种各样的原因，我个人觉得单纯从项目管理上讲，除了前面说的项目过程计划没有设计好之外，还有就是项目的目标没有描述清晰，我们立项时没有说明什么情况下验收，项目组人员以为开发出系统就可以验收，申请验收时，而领导说验收条件改变，我们又花了近两个月的时间才让系统具备上线条件，我们一开始没有描述清楚验收是验收一个系统还是验收一个具备使用条件的系统;还有对于功能不适用用户的原因，也是我们一开始没有确定好目标，包括这个系统到底是针对哪些用户开发的;还有关于设计人员守在现场，确不能说明变更，我们的目标是守在现场，还是了解需求变化等等，这一系列都是由于目标描述不清晰导致的。service.mypm.net
为了避免这种问题，我请各位项目经理立项时先要说明几点：项目起止时间、项目经理、项目成员、项目范围、项目交付物、项目验收标准，前5项内容之前公司一直都要求提供，我多增加了项目验收标准，希望通过这样的要求，项目经理能够思考，当项目验收时到底应该具备怎样的条件。收到申请时，我在申请中已经发现部分项目经理较为明确的描述出来，至少已经可以说明白验收的是一个系统还是一个缺陷控制在一定数量内的系统。由于现在刚刚开始要求，还没有项目验收，不知道实施的效果是怎样的。项目管理者联盟
五、 坚持下去，做好项目管理“第三类人”项目管理者联盟
从上面的描述中，我想大家也猜出来，在公司里推广项目管理，我还是希望自己有机会能够把经验分享出来，先将理论知识传播出去，使项目经理了解，我们能够抱有认可的态度，来交流项目管理，如何通过项目管理来提升项目投入产出率。项目管理者联盟 项目管理者联盟
本文为项目管理者联盟联盟会员原创文章，授权发布，非经同意不得转载！
|
