项目管理大家谈
作为组织级项目管理员，我们打交道最多的是项目经理，最需要了解的是项目经理遇到的困难。今天，我们非常高兴能邀请到一位有想法、有干劲、擅总结、能创新的新晋项目经理，和我们分享在担任项目经理以及日常开发运维过程中遇到的痛点与亮点，为中心的项目管理乃至其它管理制度献计献策。
被访谈人员均被隐去真名，这也是个小小的伏笔，等系列访谈结束后，我们将统一公布被访谈人员真名，敬请期待吧！闲话不表，直奔主题。
1、痛点一：立项晚、需求急—立项之痛
小新：那我先从立项说起吧。其实我们的项目早就有需求意向了，并且列入了年度计划，但是从有需求意向到正式下达立项函，耗时半年。其中的原因很多：中心主办部门不确定、立项流程冗长等。最终受苦的还是项目经理和开发人员。在监管要求下，面临着工期紧、任务重的难题。需求来得晚、来得急使我们非常被动，只能从别的项目组临时抽人，加班加点，“压力山大”。因此我建议精简立项流程，提高立项效率。
另外总是有些项目存在主协办争议，本来时间就紧迫，又被各种主协办争议、技术架构争议等问题耗掉宝贵的项目时间，对业务部门及具体开发人员来说都是很不好的体验。对此，我的建议是，建立专门的争议解决通道，迅速找到决策人做出决断。
小项：我想跟你分享两个好消息。首先，根据新的项目管理办法规定，项目立项可以在需求书交付之前进行（具体的中心立项流程可以参考小项的另一篇专题--“小编答疑解惑课堂之一中心立项流程”），已实现了你“精简立项流程”的提议。其次，中心已有一整套争议解决机制，使我们可以争取在3个工作日内解决争议。我相信，立项方式的改进以及争议机制的建立会对咱们目前面临的立项困境有所帮助。
2、痛点二：资源申请不畅—渠道之痛
小新：听了你的解决方案，我觉得立项已经不是问题了，但资源申请还很成问题。大多数项目都会需要资源，现在的资源申请渠道有PM平台、IT服务台、邮件等。我们一般会根据之前的项目经验直接在这些渠道里申请。渠道多不说，关键是它还会变！不仅是入口会变，流程也常常变化，让我们无所适从。比如我有一次按照原来的经验在PM申请了网络资源，后来被告知网络资源变成从服务台申请了。这个时候我再换一个渠道申请，耽误的可是项目的宝贵时间啊！希望咱们能和资源部门做好对接，形成入口统一、审批透明、开放咨询的资源申请流程。
小项：我们也注意到了资源申请过程中出现的这些问题，也在努力寻求更好的解决办法。目前由科技局主导，我中心配合建设的ITA（科技综合服务管理平台）的搭建正是改进资源申请流程的好机会。该平台可对科技项目进行全流程管理，提高了各部门之间的信息流转效率。对于资源申请效率的提高，ITA将是个很好的依托。我们将在后续参与ITA建设的过程中，把资源申请问题考虑进来，尽可能实现你提到的“入口统一、审批透明、开放咨询”的资源申请流程。
3、痛点三：被逼无奈的创新—协办之痛
小新：听起来我们的资源申请未来要轻松简单很多了。那我再来吐个槽：我们的项目赶上和全行重点项目并行，其中一个协办说实在抽不出人来实现我们这个项目的需求，只好由主办自己想办法。我们真的是想了各种招，终于设计出一套虽可行但非常复杂的技术方案。我对我们的技术创新感到很骄傲，但是同时也觉得非常无奈。放在协办那里做会很简单的事情，最后不得不整这么“NB”。要我说，能否在项目前期就做好技术方案与人力资源之间的平衡工作呢？
小项：这里就不得不说说中心的技术评审制度。首先不要把技术评审看成是负担，而要把它当做是一种保护。不知你有没有留意，在每一份项目任务分解表中，都有一条“申请架构评审”的任务。我们正在开展架构评审前移行动，从项目到达中心的那一刻起，中心架构管控团队就已经开始了分析研究，就是为了避免后续出现架构争议。回到你说的具体困境，显然是属于协办任务的技术方案问题，可以联系我们启动前面提到的争议流程，后续将根据争议结论决定的技术方案实施。我们与架构管控团队也会跟进该技术方案的贯彻实施。这样一来，你的方案就不需要这么“NB”了。
小新：这真是个好消息。我回去跟大家宣传宣传，我们就不需要像无头苍蝇一样到处乱撞了。
4、痛点四：测试案例太简单—测试之痛
小项：项目前期的立项、争议问题解决了，后面的资源申请也有了解决方案，那么还有其它什么阻碍项目开展的问题吗？
小新：那我得说说测试问题。开发的时候，我们开发了很多的功能，每个功能都设想了各种可能出现的异常状况，反复优化程序的分支和结构，就是为了确保程序上线之后能够安全地运行。有时候我们看到测试案例时，就很纳闷，只写了几个案例，根本测不完整。出测试报告时，测试的部门还告诉我们报告可以出，责任不能担。上线之后出问题，只打项目组的板子，而测试的部门却毫无责任。我建议测试案例也要评审，不能光评审项目组，参与测试的各方都应该接受监督，负起责任。
小项：太好了！这个建议非常重要，将测试案例纳入评审是推进测试工作规范化的好想法。评审是手段，责任落实是关键。现在根据新版的项目管理办法（未发布）规定，数据中心已经承接牵头组织系统测试和业务测试的职能。这说明测试与开发已逐渐明确各自职责边界。我们也会努力推动，协调好开发与测试之间的职责移交。测试工作的职责明确了，出了错，落下的板子也就有了明确的目标。有了这样确定的职责划分，我想大家都会对测试工作重视起来，评审的手段自然会有落实的动力。
5、痛点五：“爱做饭不爱洗碗”—运维之痛
小新：开发与测试的职责划分清楚了，运维的职责最好也能划分清楚。我做新人的时候参与过组内的运维工作，作为运维人员需要24小时开机，随时应对分行的运维需求。当时那段经历对我锻炼很大，运维工作对快速熟悉系统大有裨益，也比较辛苦。但相比运维，我还是更喜欢做开发，大部分人和我一样，“爱做饭不爱洗碗”，爱开发不爱运维。但是现实状况是，我们每个开发人员都承接着任务量不小的运维工作，往往分身乏术，导致两头工作都没有做好。
小项：运维移交机制的建立就是为了解除开发人员的后顾之忧，让程序员更加专注于开发，让运维需求统一扎口。不过，咱们为了将运维工作更完整地移交出去，也需要注意文档的沉淀，将日常的运维操作步骤、已有的运维经验知识尽可能详尽地总结整理，让接收运维工作的同事按图索骥，快速上手。
除了痛点，我们的访谈还发现了项目组的很多亮点，下面就摘录一个例子，以飨读者。
6、亮点：咱也可以优化需求
小新：当然了，我们在工作中除了开发外也会提供其它方面的价值。有时候，我们对业务部门提的需求是能够做出优化的。以我参加的一个项目为例，客户向业务部门提出了一个很小的需求，业务部门来咨询项目组，我们分析了这个需求之后，发现可以用同样的工作量实现更丰富的功能，业务部门把我们的建议转达给客户之后，客户表示非常满意。
小项：这就是熟悉系统的优势！咱们开发部门在需求编写过程中的积极参与能够为我行赢得更好的客户体验，真正实践了“科技就是生产力”。
每一次与大家访谈，我们小项都受益良多。谈话的内容丰富多样，无法在一篇小文中完全涵盖。好在咱们这是一个系列，现在不说不代表我们遗忘了大家的建议。可能是问题复杂，需要更多的调查研究；也可能是问题零散，我们会在积累归并之后统一成文。总之，不管短期长期，20个小项都会把大家的问题放在心上，不放过击溃它们的任何机会。我们会带着大家的建议去思考变革的方向，尽我们最大的诚意，切实解决实际问题，准确地为大家做好服务工作。
最后，播放一条广告，大家如果遇到任何项目相关的问题，都可以找项目管理员，也可以在项目周报中暴露出来，项目周报我们会持续关注，贯穿整个项目的生命周期，我们能解决的一定帮助解决，不能解决的也会给您答复。愿我们共同努力，让“开心”的项目在开心的氛围中展开！
