项目开展的过程往往不是一帆风顺的,项目经理该如何应对类似的突发问题呢?今天,我们邀请了希赛创造营的小伙伴们出谋划策,通过剖析具体问题进而提出解决方案,让大家在实际工作中可以有所参考。
本期案例
行业:IT
岗位:项目经理
案例背景:
公司接了一个项目,是关于一个web平台的开发工作。整个架构采用的是B/S架构,主要由界面层、图形层和数据层组成,项目经理对此没有相关经验。
遇到的问题:
1、用户一开始对业务需求描述得很模糊,只说到一些基础需求,但是后续有对其他特定功能进行补充,技术团队无法解决;
2、项目经理向上申请新增两名了解这方面的技术人员,但是现在这两位技术人员在外地实施别的项目,未确定时间到此项目组;
3、用于数据采集和系统测试的设备和配套软件,需要等公司另一个项目结束后才能使用。
待解决的问题:
项目经理应该如何处理以上事件?如何应对开发中存在的技术风险?
主治医师
01昵称:牧云
【PM如何解决问题】
1、技术团队能力不足时:
成本允许首先考虑外包,如外包给兼职的高程、第三方外包公司、靠谱的朋友或是希赛校友等等。成本不允许就属于商务范畴了,如果不幸被赶鸭子上架让你去沟通,就诉诉苦交交心,另外任何事还有一个终极大招“我不玩了”——领导,公司对我们的考核压力也非常大,再谈不拢,我真的只能被迫离职了。
2、技术资源异常紧张且不能到岗,说明公司属于弱矩阵,对本项目并不重视,建议对客户使用拖字诀,一个小技巧是尽量忽悠客户变更并主动延期,因为我方尚未开工,实际变更成本并不大。(如果公司对你严格考核进度又不给资源,一定要思考到底是什么原因让你不离开,是爱么)
3、数据采集部分可以让开发前期先手动录入几条,保证系统流程跑通,后续再追加数据即可,测试同理,毕竟不会测试的PM不是好PM。
【PM如何预防风险】
1、面对陌生项目时,一定要保持敬畏,最好先充分调研同类型项目的失败教训,如遇到过哪些坑,有哪些风险,为什么发生,事后复盘是什么,给你的具体建议是什么。最好多问问几个人再整合一下。
2、模糊需求遇到不较真的甲方很省事,实施方可以怎么方便怎么来,一旦遇到较真的就惨了,每个点都能渐进出无数变更。但这是你们主动选择的,要赌就要愿赌服输,当然也可以一开始就细化原型确认范围,这么做的缺点是费时费力,因为太细化也缺少转圜余地,看你怎么选择。日常中我们倾向于模糊需求,根据需求模糊的程度设定一个系数,并对不同的行业和客户群体上下浮动。
3、乐观做产品,悲观做项目,尽量降低期望值,凡事多往坏处想,比如甲方肯定会变需求,开发肯定会摸鱼,三流供应商肯定要出幺蛾子……
给项目预留一些弹性,万一发生风险也不慌,哪怕没有预案,起码还有足够的时间去补救(应急储备和管理储备)。
02昵称:米奇
大家好,我是米奇,因为之前处理研发项目较少,只能根据个人理解对该问题进行分析。
按照管理,首先重新描述问题。
1、项目经理对该研发项目没有相关技术经验。
2、项目立项时需求模糊,渐进明晰中发现有团队无法满足的技术需求。
3、项目经理协调的资源无法确定加入时间。
4、配套资源与其他项目冲突,需要等待。
首先明确一个概念,项目经理不是技术经理,不是解决方案专家。专业的事情交给专业的人来做才是正确的项目管理目标。通常信息化项目中立项阶段通常都会遇到需求不明确,需要渐进明晰的。这属于正常的项目过程。
针对投稿人的问题:首先投稿人对问题处置流程是没有太大问题的,超出职能范围的,超出团队能力范围的问题需要及时向上反馈,寻找资源帮助。但同时需要与甲方进行沟通。尤其是有可能会影响项目工期或质量的情况下,需要和甲方进行充分的沟通。有时候项目经理解决不了的还可以叫销售或者商务来处理。
针对问题1和问题2:专业的事交给专业的人去解决就好了。目前看来已经交给专业的人去做了,这个和问题3合并处理。
针对问题3:首先这里需要分情况处理。首先需要和甲方进行沟通,说明现在的问题是目前的团队无法处理的,目前项目经理已经协调了专家来进行处理,但因专家时间不确定,需要和甲方领导确定一个工期。如果这个问题不是有待处理的,可以暂时先完成其他已经明晰或者需要明晰的问题,最后处理这些难点或将问题集中起来让专家一次性解决。必要时候可以先完成目前可实现的部分,让商务人员出面将难点作为项目二期,追加研发费用实现。
针对问题4:需要向公司反馈,协调资源优先级或申请穿插。比如让公司协调测试人员或采集人员在条件允许的情况下进行采集或测试。如果确实不具备穿插条件的话,建议向甲方领导说明情况,并申请项目延期。
#我有话说#
@左佚名氏右:
项目经理其实很清楚他的问题,而且已经动起来了,只是动起来以后发现,问题没法迅速解决,需要时间。问了三个问题,其实就是两个,问题2是问题1的解决方案。首先,尽可能地找出来一个能跟客户对接需求的人,尽早跟进客户,把需求清单搞出来。新申请增员的两名技术人员,可不可以先通过线上的方式,提供帮助。
@slinker:
1.针对需求描述模糊,可以针对性的进行一些问题整理,针对性的询问,或是以DEMO的形式,做成原型和用户沟通,明确需求;
2.外地的技术人员可以用远程支持的方式加入团队,拟定任务职责,定期远程会议交流;
3.数据采集和系统测试的设备和软件,可以和另一个项目的项目负责人沟通,协调使用时间,比如集中某一时段运用,如果实在无法协调可以向上和领导沟通反馈现有问题和风险及解决方案,请领导代为协调。
@危笑:
1.针对用户目前的需求,先构建原型草图,跟技术讨论后,再与客户沟通,可以先上第一期必需的功能,定制化的可以往后再申请资源来做;
2.针对申请到的人员,如果未能到场,看能否协调他们先远程进行工作,如果不能,那就发送邮件给直属领导,让直属领导去催,同时注意留痕,否则后面扯皮因为技术人员没到位,导致项目工期延长,背锅;
3.针对另外设备未到场,可以先做一些用户调研,需求分析,原型构建,这些工作,说白了就是先做好客户关系,天天跟客户聊天,聊好了,后面啥都好说。技术风险,再大的坑,在客户关系面前都不是事儿。
@Lin Weiwei:
1.这是典型的滚动式规划啊,敏捷肯定是最好的开发方法。迭代处理,先从基础需求开始,做个原型来给用户补充功能,开发思维。技术团队无法解决就说明这团队不是通才了,一般现在应该很少有通才团队吧。时间来不及学习培训的话,就只能加人了,找技术专家解决。PMP®里说有结队编程,感觉……挺扯的,但是如果有条件可以用这个学习新技术。
2.好不容易加两个人,还不知道啥时候来。先跟派这两人来的上面沟通啊,急用不急用,啥时能来,我先安排一下工作,整半年之后来,项目还做不做了。不能到岗属于事业环境因素,要按这个前提安排自己的项目计划,这个也算风险,记到风险登记册里,先讨论一下潜在应对措施。实际操作可以自己联系一下那两个资源,看看能不能用人际关系啥的催促人员快速到岗。
3.又是一个事业环境因素,按照PMP®的思维和理论,就是先看影响呗,如果影响很大,那就提交变更,这东西我也不能自己生产一个啊,只能等,拖慢进度就得变更延长进度。或者就是搞关系了,要不然就是申请新买一套用,要不就是看看协调能不能跟另外一个项目兼用。总之,想早点用上是关键。技术风险规避不掉,只能尽量在各个阶段减轻,首先要认清风险,然后别忘记了它,观察它,别被风险干倒了还不知道咋办呢。分享风险信息,不能自己扛着,要让领导和公司都认识到才行。
@老鱼:
其实问题并不是问题,因为题主知道问题在哪,所以找准问题后知道从哪些方向寻求资源制定对策进而帮助项目。
1.第一个问题按照跟各位IT大佬们相处之下觉得是还算正常的情况,那就渐进明细嘛,无论啥需求提出之后业务团队也不是自己就做主的,所以进行一下需求评审,能做的就纳入范围,做不了的就拒绝掉,老板又想赚这个钱就提出资源和技术差异,进行补充;
2.问题二明显老板不舍得到嘴的肉,也同意了资源进入,但是还没办法增添资源来用,那就明确好进度计划和偏差原因,然后排出资源的可利用时间,如果超出客户期待的DDL,那就再找老板早点把资源给你;
3.问题三也是一样的,老板想吃肉就得架火雇厨子,不利因素识别清楚并且反馈了,在项目计划里面展现出来,老板不愿意就再向上协调。