01｜角色转变：新手项目管理的三大误区

项目经理和产品经理是同一个职业吗

最近一个项目，业务复杂度，项目重要程度都非常高，同时要求使用新技术新平台（相当于团队研发），团队肩负着甲方的进度压力和质量压力，中间几个核心成员离队，同时信息中心又想通过这个项目打插边球，要求团队偷偷摸摸做一些范围外的工作，项目经过两次延期，好在是现在上线了，回想这路走过来... 最大的心里体会是： 1.如果项目经理忙于琐碎的细节，自己成为瓶颈，无法有效管理团队，那么团队必然失控。很多时候项目出了问题，自己一个熬通宵解决，感觉没有一个人帮得上忙。项目组成员都有一种事不关己高高挂起的状态。 2.信息中心要求使用微服务技术来做系统，受限于项目组技术储备和业务压力，第一阶段我坚持使用SpringBoot技术+传统技术实现，而没有使用SpringCloud组件，千方百计确保项目关键模块先上线，让业务部门看到希望，给团队看到希望。这样做的后果是，业务保住了，但是系统立马面临改造，相当于技术上做无用功，好在这些技术工作慢慢都消化在项目推进中。最后的结果是业务和技术都保住了，现在回显起来，自己的决策应该是对的，那时我一个人基本站在了信息中心对立面，甲方项目经理都要绝交了。事后项目上线了，运行稳定，业务部门满意，信息中心才慢慢改变态度，并对我的决定表示理解，说“不管是乙方项目团队还是信息中心都是为业务部门服务，他们满意了，项目就成功了”。 3.在项目管理中，我通过引入日报机制（必须发送日报）、周报（通过钉钉发布，里面包括关键用户、甲方项目经理）、每周四发布代码（开发轮着部署代码）、建立项目组成员工作特点清单（记录他们的工作特点，在进度控制中采取不同策略，执行力强的人不用天天催，执行弱的人半天催一次），每周五过周计划，然后周日晚上整理下周的计划，并当天晚上发布到工作群，每月阶段性汇报，等机制慢慢让项目步入正轨。 4.我总结的是：要做好一件事情：事前规划（计划管理）+把事情做好（质量管理）+执行力（过程管理）+有效的沟通汇报。

第一点（凡事恨不得事必躬亲）很有感触，应该做到： （What）目标明确：知道要做到什么程度，达成什么效果 （Why）背景/环境清晰，形成核心动力和凝聚力 （How）如何做：赋能团队和个人，找对人 做不到上述几点，会把项目经理陷入到繁琐的日常事务的泥潭。

转行项目经理需要具备哪些条件？

始终在第一和第二个误区徘徊，相当的难受呀。

1、在我的项目中我觉得质量是更重要的，时间是允许有一定调整空间的，因为在所接触的项目中，除了要驻场开发的，几乎每个项目都会延期，具体原因总是归结于需求改动，需求没有确定完全，都是边开发边更新新的需求，但是其主要原因还是要归结于内部，至于成本，公司的项目都是承接的，不自主研发，成本高也是时间延期，人员工资增加，成本在一定范围内是可以延期的； 2、其角色痛点是开发没规范，没有固定的开发流程，就算前期定好，后期也没落实，其主要原因是公司原来是两、三人的团队，人少，不需要管理，每个人都会自觉有自己的计划，但是突然增加到十多人的开发团队，就不知道怎么管理了； 3、这些痛点是迫切需要改进的，要不然一直这样下去，根本没办法让公司更上一步，人多了，延期成本会更高； 4、目前的定位是项目经理，也与老板沟通过，也开会说过要根据什么样的流程来，但是老板忙于跑市场，在项目扔给我后总是感觉不知怎么如实按着流程来； 5、我认为基于我的情况，应该自上而下地全面推广，首先要从确定开发流程，制定工作计划切入，且要实施起来；

讲的太好啦，作为项目经理的我看到这些，真是感同身受啊，句句讲到我心里

我在想，如果建立了职责明确的okr，项目是不是可以自驱呢

变更的背后是对客户需求管理的失控，那么怎么样才能更好地管理需求呢？

1、我们公司依然处于发展期，要想留住或者吸引更多的客户，个人认为项目质量是关键，只有东西做好了，才有继续合作的可能性；其次是范围，我们公司的客户经常会提出需求变动，让大家都很头疼，做好前期的需求沟通，明确项目范围，也是我公司要考虑的重点问题；相比之下，时间和成本可以有一定的调整空间； 2、目前，公司研发人员的技术水平参差不齐、且缺乏基本的编码规范意识，做出来的东西经常bug很多；另外项目管理流程比较简单，更多的是看项目经理自己的发挥；再一个，需求变更管理不到位，我无论是学PMP还是软考时，给我的感觉就是，无论项目大小，需求变更管理很重要，然而在公司实际工作中，变更都是口头传达，没有经过更多的评审就直接做了，变更管理无从谈起。领导其实都很清楚这些问题，每次开会也都强调大家要重视这些问题，想办法解决掉，然后就没有然后了。。。其实总的看来，还是缺少一个符合公司状况的项目开发规则和流程，这个规则需要领导发起，相关人员共同商讨制定，而且更重要的是，如何在人手有限的情况下，把这套规则真正的实施下去！ 3、规则的完善，是我公司重点需要考虑的问题，而规则又细分为很多部分，比如需求设计规则、代码开发规则、测试规则、项目管理规则等等，我作为一个程序员出身的项目经理，比较关注研发人员的的代码开发状况，目前问题其实不少，代码设计冗余、不合理，代码注释缺失严重，没人愿意接手其他人的代码，理由基本都是看不懂，接手后改起来也很痛苦，这样的状况开发出来的系统，问题能少才怪了。然而这些问题并非技术难题，还是缺少编码规范，以及有效的审查和监督。因此新的一年里，会和领导反映，一定要解决这个最基本的问题。