我对项目管理的见解

2020-10-30 09:32:14 【his_his系统_emr电子病历_医院信息管理系统_养老系统】-行心医疗云 阅读

最近想写点关于HIS项目管理方面的总结,毕竟受过PMP培训而且长期从事这个行业的老罐子,应该有点东西倒出来吧。但一直因为时间关系写不成,直到最近我看到下面几个项目组长很忙但没有搞好项目。我觉得自己应该总结一下。

在项目管理的书本里说,项目管理有九大领域:范围管理、时间管理、成本管理、质量管理、风险管理、人力资源管理、沟通管理、采购管理及系统管理的方法与工具;项目管理是PDCA的过程:Plan(计划)、Do(执行)、Check(检查)和Action(行动)。这样的理解太表面化、初级化。每个行业,每个项目的理解都不一样,侧重点不一样。真正的经验和悟性来源于对项目各种因素的侧重点的理解。所以项目管理其实是一门艺术和技术的结合学科。艺术性之一在于她追求一种矛盾之间、变化之中的平衡,艺术性之二在于她里面其实就是处理各种各样的人际关系。技术方面就是你或你的团队要精通项目所需的业务和相关技术。不同项目根据行业的特点,有不同的侧重点,但项目管理是有章可循的。项目管理从一开始就是追求完成为了验收,没有100分的,只有更好,没有最好。

兵法有云:战争胜负取决于天时地利人和。项目的成败也一样,总体来说取决3大因素:项目大环境的有利因素,包括客户和公司领导的支持(天时);项目经理的领导水平、技能水平和专业态度(地利);项目团队(包括客户参与成员)的参与、配合和信赖程度(人和)。以下针对这些方面说说我的重点见解

项目经理的素质当然是最关键的。我认为项目经理最重要的素质是紧迫感和责任感。只有这样,他才会很用心的去留意和思考各种各样的事情。。懒惰、贪玩、不成熟的人请远离这个圈子。怕事、软弱、内向的人也不要靠近。值得一提的是,技术人员或者技术倾向的人去做项目经理也是灾难性。因为技术人员喜欢单线程的思考和工作方式,但项目尤其是大项目是多线程的并行任务,这是个巨大的、无法改变的矛盾;而且技术人员喜欢解决问题而不是发现问题,他们是问题的终结者而不是发起人,所以,他们一般不会主动地与干系人沟通。应该承认,当我埋头搞技术的时候,我连一个试用期的毕业生项目经理都不如!有些项目经理也喜欢处理各种各样的问题,他们或许觉得这样很有成就感很有满足感,他们或许很关注客户的满意度,但要明白,那是技术人员和客服人员要做的事情,项目经理不是客服人员,他们更多的是应该处理人而不是处理问题。从DISC性格差异来说,项目经理也是有不同的职业生涯规划的,实施工作不是他们的永久之计,他们有4个职业发展出口:开发、管理、销售、创业。C型的适合开发,S型的适合管理,I型的适合销售, D型的适合创业。例如,项目区域经理(巡检员)属于管理岗位,必须要有2个意识:1、把项目的责任背上;2、把培训帮带新人的责任背上。

首先,没有使命没有目标就没有紧迫感!项目经理的使命是上线,而不是现场客服,不是现场受理和处理问题,也不是去培训,一切为了上线验收!每个项目计划必须要有目标上线时间,而且与客户达成一致意见,并签名确认达成一致目标。再者,医院信息化管理系统是一个管理流程再造、优化的过程,跟一个企业管理系统的建设一样,有周期长、成本高、阻力大的天然属性。所以,HIS系统建设就是“急,乱,多,拖”的特点,一线医务人员太急,管理落后,专业多、信息多、人多、系统多,而且国家单位的人不想多做事,喜欢拖。针对这个行业特点,HIS实施因而更注重项目时间管理和沟通管理。项目管理教材的九大领域在这个行业最突出的是这2个方面。所以,时间安排不紧凑,没有学会同步并行地进行工作任务,单线程实施,喜欢一件事情做完做另外一件;沟通方面,闭门造车,不喜欢与项目相关人沟通,或者“忍辱负重”,“得过且过”,不想讨论,不敢争取,不想方设法尽早把问题暴露——这都是最大的毛病。写项目周总结和计划也不能马虎的应付了事,要站在项目管理和推进沟通的角度去考虑,而不是站在“汇报工作”的角度去写。其实实施HIS并不难,计划计划再计划,沟通沟通再沟通,做好细节事情的时间安排,做好沟通,避免上述问题,即使你是初哥菜鸟,至少也可以拿60分;如果做不好,有以上所说的问题,你最多50分。以上是从沟通管理方面看HIS行业,从实施风险来看,我们首先必须保持危机感、紧迫感和服务意识。我们做项目,正确的观念应该是:实施工作做到细致,防止上线出问题;万一出事,就要加班加点赶快解决。也就是:“是起火之前,做好防火工作;起火之后,急用户所急”。做项目,服务很重要,及时性和紧迫感都是首要的。如果不是跑起来、吵起来,是不可能做得好的,最后结果极有可能就是延期失败;如果不跑过去旁边敦促他、不发脾气、不互相传递压力,仅仅靠发QQ信息,怎么可能有紧迫感?最好越吵越好。我创业做得最成功的项目就是茂名中医院,最大的得益就是有一个“泼妇型”的搭档——赖科长,天天吵架,结果项目就做成了。

只要项目经理素质不坏,技巧是可以学习、积累的。但医疗系统的庞大以及国营事业单位的做事方式,你就要花多点时间学习积累才能跟他们PK。首先要把握项目的总体规划,领导的想法,以及项目的节奏。先回答:新系统的切换策略打算采用分步上线(先换掉老系统)还是新旧一起整体切换?搞清楚领导希望是以稳为主还是以快为主。如果分步上线,周期会比较长,但对一线科室的业务冲击不大,不会大范围的影响医院正常业务开展,比较稳妥,尤其适合有自我开发能力的信息中心。但如果因建设周期延误不得,计划整体上线,稳中求快的想法,则需要整体切换,风险大一些,需要科室比较多的前期准备,需要比较强的项目管理能力,需要调动多方配合,科室要充分参与,而且进场后会组织信息化小组,最好临床各科医护各有2至3名信息员参加强化培训后带动科室其他人员并担任联络任务,这些科室信息员开一次动员大会,并经常开会总结。进场后,第一阶段,制定项目计划,调研和需求规格说明书才是重点;第二阶段,数据初始化和二次开发是重点;第三阶段,培训和试运行是重点。我们主动点,我们带着客户走,不要给客户外行带着我们内行的走。准备阶段,用户的参与是至关重要的,给用户互动性的演示、试用、新旧系统对比等手段是极好的。说服技巧方面,主要是考虑如何说服主管领导和信息科长,他们的支持也是重要的。请吃饭,甚至一些“邪门歪道”手段都是有必要的。另外,国家单位做事是讲责任、谈问责的,他们怕签名,但偏偏这个东西既可以施压有可以保护自己,应该多多利用。虽然有点“形式主义”,但做他们的项目就要融入到他们的工作氛围,随波逐流,没有办法,谁叫你搞他们的项目呢?如果用户参与度不能提高,那项目经理自己就要更加用心。

风险方面,最容易造成项目延迟或失败的因素是需求没有清晰;基础资料没有收集完整或错误;硬件延迟没有准备好。培训方面还不能算大风险,因为即使没有做好,“人海战术”也可以弥补不足。每天早晨起来在尿急的时候想想未完成工作,其实是最有效的规避风险手段,比项目计划的风险分析还直接。比如需求风险,不要只依赖他们骨干提出需求,因为他们要熟悉我们系统还需要很长时间,他们很难在初期提出那些有对比性的、有建设性的、大风险的问题。经常有矛盾的地方,包括界面、操作方法、流程、打印格式、报表等,很多都是在他们的惯性思维,我们要主动去发现,学习他们的旧系统,这样我们可能在调研阶段就意识到这里有个很大的“地雷”(风险),然后今早讨论、解释、引导或不得不开发迁就,并签字确认避免以后扯皮——我们尽早把‘地雷’发现而且挖走,也就是及早处理这个矛盾,否则等他们提出的时候可能一切已经迟了。我一再强调要检查好系统参数,进场后没有调研,没有设置好,越到后面代价越大。上线前给开发员调试带来成本增加,上线后发现再调整的代价更大!而且,设置参数的过程也是我们调研补漏,以及用户借鉴其他医院的管理方法、重新思考流程改造的一个过程,是我们和用户共同思考还有哪些流程没有考虑到、测试到的过程和结果。所以,不重视这个是要打八十大板!我长期维护一个文档《切换系统前关键检查点(QC)》,我还要求我们的管理经理和巡查员按《项目跟踪检查表》的要求检查,目的就是提醒项目经理和项目总监,风险意识比计划还重要。如果已经上线的系统,更加要提高风险意识。如果没有现场工程师,远程修改代码的,组长要审核代码,现场人员要测试好,才能更新。项目计划是项目管理中的核心,相当于人的脑袋;紧迫感则是心脏。我们必须有总体项目计划(时间节点),而且要时时保持最新。我们PMO主管应该每周跟医院信息小组开一次周会,总结本周情况和下周计划。现场经理或项目负责人要每天在群里发一下今天的进度和遇到的问题。发现系统问题要登记OA来管理问题处理流程,在腾讯共享文件夹维护一个《开发任务明细表》给大家看到所有问题的解决情况。还有一个忠告就是,项目越是风平浪静,里面可能酝酿着的风险就越大。

跟所有项目一样,计划跟不上变化的事情肯定有的,在HIS行业,跟所有与国家单位办事一样,你要记住你是跟普通人打交道。计划只是口号而已,从做计划的第一天就要想办法如何应对他们的拖拉。消极放任肯定没有好结果,每天设法敦促对方执行才是正道。当然有时候也不得不向他们低头。当变化来临之前,应该注意尽早与用户领导和公司领导沟通,“垃圾放得越久就越臭”这句名言在这个行业更加贴切。所以,保持一定的政治敏感度十分有必要!切记不要等客户催,大家要明白,客户每次催促以后,都会对公司印象有减分。这个是不对的,我们要注意我们的工作方法:1、预先计划好,通知客户、团队、上司;2、如果计划有变化要请示上司,通知大家;3、不要让别人催,反过来催别人,主动把最新进度告知大家,才能让客户对你更加有敬畏和好感。另外,对于一些项目金额比较低的小医院或者不怎么配合的客户,我们宁愿使用人海战术,快进快出,等他们不得不要动,万事俱备只欠“我们”的时候,我们就组织部队一次性上线、维稳、验收。也就是说,先确定上线切换日期,定计划再派人进场。进场的原则是:大部队进场,快进快出,速战速决。最好说服客户派人来广州学习一段时间,我们同步二次开发。一旦上线日期确定,我们提早2周进场,培训、试运行、上线、维稳,一条龙。我们千万不要在前期为了客户满意度而跟他们耗时间。耗时间还有个坏处就是纵坏客户,养懒我们的人,还让客户觉得我们的人不行,派不出精英、熟手的人员。

时间管理和控制方面,项目经理的注意力方面和时间管理很重要,既不能偷懒,也不能以个人勤奋去弥补计划的缺少,更不能“埋头苦干,只干不说”。例如,过分把注意力放在敦促开发员去解决用户提出的那些不太重要的或操作方便性的需求上(有时候客户发火和不满意并不代表我们必须把大部分注意力放在他们发火的问题上),我们应该把注意力放在流程测试、基础数据、人员熟练度等方面,这才是根本,我们不要把自己的节奏打乱了。另一方面,必须意识到打国家工的人是不会轻易帮你加班的。如果想他们加班只有2个办法,要么领导压,要么你请他吃饭。这些都不算好办法。最好的办法就是调整自己的时间,尽量安排在上班时间坐在他身边跟他们磨,上班大部分时间是找人做事,下班才去弄自己的事情。所以最好他们上班时候你去沟通,下班以后再对数据和测试系统。否则,你就会在死期已到时发现给他们拖死了,你可以找借口,但其实你也有很大责任,为什么不一开始就去磨他们呢?还是记住那句话,找他们做额外的工作量很难,叫他们加班更难。自己“执生”啦!

在需求(项目范围)确定的情况下,质量、成本、时间这个项目管理三角形定律在HIS行业仍然有效——某一边增加或减少势必导致另外两边的增加或减少。那么,是追求质量与口碑?还是追求降低成本?或要求快速完成?这4个因素代表四方的利益:时间代表项目经理和开发人员,质量代表客户,成本代表老板,范围代表销售商务人员。出现三角矛盾时,项目经理应该四方(用户方、销售商务方、开发实施方、公司老板方)协商折中解决,“磨刀不误砍柴功”这句话不一定正确。例如,我们老板追求利润最大化,但作为项目经理,也是要主动沟通,要引导他往市场、对手、用户满意度和项目实际情况等外部因素考虑和回答,揣测到老板的心思,才能往下开展工作。又例如验收被卡就是这个“三角矛盾”的典型例子,我们的策略是:去科室收集问题,分优先级级别定计划,汇总成验收问题文档,答复给验收小组签名,然后安排开发员进驻解决,同时把受理问题的窗口转交给信息科或验收组长(注意:只是解决三级问题。需求方面只解决已签名的A级需求,其他一律验收后再做),随后实施人员撤出,以此解决验收无限期延长的死结。我们做项目的,记住一个单词就是“底线”,英文就是Deadline,就是超出这条线就要死的意思。我们要清楚,公司的成本、质量、进度、范围都是有底线的,任何一个方面超出底线,公司都会蒙受损失,公司都可以会放弃项目,因为公司是需要盈利才能生存。

鼓励用户充分参与,首先要基于信任和沟通的基础上,否则大家的精力时间都浪费在争吵之中。第一阶段要组织双方良好沟通,紧密配合,小步快走。初期项目干系人对信息化理解和期望不一致,信息不对称,但用户方有主导地位。要说服领导,教育领导,给点耐心,有时候不懂的人来指挥是灾难。重心重点就在于少数用户精英——骨干。重视骨干培训,医院人多部门多,人山人海,抓住重点就是抓住骨干。骨干要培训控制好,骨干培训关系到需求确定、流程测试、推广培训、上线等环节,他们的熟悉会带动其他人,包括项目经理自己也会被一位充分参与的骨干所感染和调动。我记得在肇庆第一人民医院的龙姐就是充分参与的骨干代表,因为她的熟练,她们整个组的需求和培训都很轻松顺利,结果上线时本来应该最忙的收费处反而是最平静的。“前期是否准备得好,看看骨干熟悉程度就知道”——应该求质不求量。如果你很乖,事无大小,不分主次,什么事情都包揽一身,客户认为只要你在就不是问题,他们就不参与了。又例如,系统已经上线,已经交付了。剩下的工作就是验收和维保,而不是培训!所以要信息科作为内部部门的受理窗口,由他们先受理问题,如果属于验收方面和维保方面的工作,是我们来做,但培训和受理疏导是他们来做。如果他们信息科说永远不懂,你是不是打算永远在他们那边上班?不是为了好沟通就一味的迁就、讨好,这会形成2个恶性循环:1、医院依赖你,你走他们就大意见,不准走;2、他们自己不学习,不进步,没有能力独立维护系统,他们不成长也是你的错,即使你干得很累了,很多理由了,但还是你的错!纵坏的孩子就是家长的错,纵坏的客户就是我们的错。无原则的讨好等于纵容,纵坏了客户是没有好结果的。

刚才已经讲过,项目管理从一开始就是追求完成为了验收,每个项目的资源都是有限的!项目的目的是按照计划和标准交付,而不是无原则的用户满意!做项目的,从一开始就要专注于完成验收上,而不是客户满意度。所以,从进场一开始就应该知道验收的标准和计划,而不是靠“现场磨,零缺陷,包满意”。项目经理与客服人员是有区别的。对客户的无理刁难,如果不能说服,就要能拖则拖,不择手段,只要能够完成项目,能够验收收钱,你就有本事。大家要记住,你们是实施人员,你们不是客服人员。实施人员的天职就是交付验收!等主管吩咐,等客户安排事情,要客户满意……如果不能验收撤退,这些都是扯淡。项目完成不等于用户完全满意。当然如果遇到无法跳过,必须面对、解决的坎,你也别浪费时间跟他们磨嘴皮,老老实实地加班吧。总之,项目的过程就是一个权衡利弊、看风使舵的过程。还是那句话:“从进场第一天开始,就要为尽快撤场做准备”,这就是我们项目经理的考核标准的核心,所谓“技术”、“经验”、“能力”、“态度”、“文档化”、“政治意识”、“紧迫感”、“质量”等都是围绕这个主题而开展的。做HIS真的不能太软弱,该说就说,而且早点说。做HIS只能平衡各方利益关系,所以加班赶工、成本进度、责任等压力全都给自己,但很多事情完全超越自己的能力,最后只会害了客户,害了合作伙伴,害了公司。很多项目经理最喜欢说的一句话就是:“反正我也催了,他们不做,我也没有办法”,呵呵,事情做不好,是你的责任;做好,是你的能力。

团队建设需要人力资源,自私一点说,不管哪个项目经理都想公司配备最猛的武将给自己。但现实世界怎么会那么理想呢?公司的资源永远都是有限的,你还要站着公司的立场和项目的立场去考虑问题。所以PMP强调项目经理要正直,不能有私心。还要学会经营,给组织创造利润,主动地PDCA,发现风险提早杜绝,不能被动的每天“受理-处理”,平时多点跟老板沟通,说明白利害关系,等待、接受和理解他的决策。Yes,Sir!

再进一步说就细化到技术方面了,对业务的熟悉、实施的经验和解决问题的能力会大大增强用户对你的认可信任程度,理解和沟通能力会更强,办事无疑是事半功倍的,讲话也更有分量。另外,重视对技术人员的管理,得到他们的支持也很重要,有时,他们2个小时的动手就相当于实施人员2个月的嘴皮。但如何得到他们的支持?老实说要说服技术佬没有说服那些院长科长那么复杂!往上汇报,不停地汇报,不厌其烦、撕破脸皮地汇报就行了。技术人员不怕讲道理,就怕烦人怕啰嗦。随着项目的逐步深入,实施人员总会遇到很多“不关自己事”的技术问题,但能不能有效解决取决于自己的态度和方法。对付开发人员必须有足够多的任务给他们,推着他们动。我最怕的就是项目经理和实施人员本身就是紧迫感不够,最后问责的时候就说是开发人员的问题,那项目就完了。所以在态度上最大的问题就是“怕”、“懒”,怕得罪人,懒沟通。其实我平时也怕沟通,懒理。但事情逼到上来的时候,我谁都敢得罪,吃饭睡觉都在想,都在催。只要有这口气,而且有道理,够耐心,对方也会怕你,甚至敬畏,时间久了,还会尊重这种人。方法上,沟通是最主要的,但别以为有问题报告就可以了,报告并不能代替沟通,很多人容易产生误解。他们认为只要情况跟相关人反映了,微信QQ发了,邮件也抄送给主管了,如果对方和主管都没有行动就不关我的事。事实上,可能因为他们可能没有时间及时看和处理,结果就大家都不理了。于是抱怨开始了,责任推卸的时候也有说法了。作为项目经理,应该好好有缓冲时间,可以多向沟通或者召开技术会议把相关人召集开网络会,提高大家的重视程度,也可以叫开发员加班解决。为什么都没有利用好这些平台?!有些人会问,能不能制定一些条条框框的制度约束开发员?想靠制度,而不想得罪人,就没有项目经理了。

项目工具也很重要,所谓工具我可以泛指所有前人已经总结好的方法和文档,包括企业管理系统(OA)。像计划模板、MS Project管理和跟踪软件、日常文函的模板、需求调查问卷、培训大纲、数据字典、知识库、模板库等也算工具。工具的好处只要是2个,第一是提高效率;第二是借鉴前人成功的经验,少走弯路。医院信息化行业都存在“交付难,验收难”的难题,所以我们更加要把握好验收标准,《需求规格说明书》不是一个培训的文档,这是大家沟通的一个工具和蓝本。我们在签合同、项目沟通、需求委员会管理都要强调验收标准。因为我们现在没有验收标准和计划,现在还是沿用“现场磨,无标准;零缺陷,包满意,求验收”的做法,这个就是没有重视计划,没有重视工具的表现。这个是项目管理的方法和精神,没有计划和标准,没有这些工具的项目就不要做了。因此,我们进场后应根据合同要求功能列表和应用目标积极开展调研及与客户沟通,一起看系统,提问题,修改开发;再看系统,再提问题,再修改开发……循环复始,直到大家满意为止就开始准备上线前的软件规格说明书。这个需要很多次的磨合才能达到那个双方都愿意“签名确认作为验收标准”的境界。对于科室强势的项目(不接受规格说明书)或者必须走科室验收流程的项目,请使用《验收问题表》。流程是:去科室收集问题,用这个模板整理好问题,统一给科室签名确认。然后发给公司,公司答复后给医院留底。这个方式可以代替规格说明书。这个步骤最好在上线前做完,如果不行就在后期做。我们应该时刻关注以下问题:我所在的项目什么时候验收,如何验收?有没有达成共识的标准?还是不了了之?既然销售合同没有写好验收标准,一旦出现收费纠纷、扯皮,我们如何保护自己?我们平时跟客户信息科、科室用户、需求委员会、销售人员沟通,如何做才能更加好?

关于大小项目的区别,要分别对待。小医院的特点是标准化程度高,成本低,客户弱,所以我们必须保持强势,速战速决。小医院计划、调研、培训、考试都可以简单甚至省略掉。而大项目风险多,定制多,意见多,沟通多,通常各个环节都需要精细化、专业化。但某些时候,处于成本和时间的考虑,不想打消耗战,用毛主席说的“集中优势兵力打歼灭战”的战术,其实对我们的沟通成本、用户满意度也是有效的,我们还是要灵活运用,主动提出,并开会讨论,组织“上线冲锋队”或“维稳救火队”,这个策略要成为公司管理的常态,灵活抽人、调动、安排。

小公司靠个人能力,大公司靠平台、靠流程、靠标准化。项目经理在大公司上班要注意改变概念,融入新组织,不要过分追求项目经理的个性和个人能力,这个社会是要分工的,公司做大也是要组织架构的,如果没有组织分工去做销售、开发、客服、培训咨询、调研谈判、现场协调、上线指挥、人事后台管理,公司永远做不大。大公司最大的标志就是企业流程管理系统(即OA系统),我们要学会,既要接受流程化标准化管理,又要以沟通弥补系统与制度的不足。首先须明白,OA的作用是规范化、精细化、系统化,但它只是人的工具,并不能完全代替人。人与人的沟通不能完全依赖机器,但可以借助机器和网络作为管理工具。机器控制不了人(更何况对方是程序猿!),现在还没有到电脑控制人脑的“科幻未来”,所以,不能完全靠系统管人,必须用口头沟通来弥补“电脑不能控制人脑”的缺陷。口头沟通的作用是:事前提醒、事中敦促、事后分析处理(奖罚或再计划),通过口头沟通来控制人。在实践上,客户提交的问题要登记到OA任务,然后找负责人确认计划,提醒他计划完成的时间,要求他承诺;在完成的过程中观察他是否在全力以赴的按计划完成?遇到什么问题,需要什么帮助协调;如果时间节点到了还没有完成,是主观因素还是客观因素?主观的要惩罚加班,客观的要重新制定计划,重新登记OA——这些都是项目经理、客服人员都应该学会的沟通能力。沟通是能力的体现,项目的困难也是倒逼我们提高自己的能力,我们最大的能力就是沟通能力(所有的困难、风险都可以归结到沟通问题),从这一点来说我们应该感恩困难,感恩麻烦的客户,让我们成长。

在这里我们还讲讲客户。做项目,千差万别,会有遇到很难缠的客户。首先应该认识到:退一步,我们拿了别人的钱,受点委屈是应该的,与客户保持好关系,互相信任是有必要的。我们不要那么消极,多沟通。他发飙的目的是要我们老板重视,但工程师也要帮老板挡挡箭。赶快找他们开会,摆事实讲道理,他可能会骂我们老板,但没有人会惩罚做事的人。沟通才能折中选择,平衡各方项目干系人是现场项目经理的天职。即使有矛盾,只要充分沟通,要知道沟通不是追责,沟通本身就没有先后,没有对错,没有情绪,有问题只要多沟通,只要我们与项目干系人取得共识,再开会协商,不要开会吵架,问题还是有机会顺利解决的。如果持续得不到解决,要把问题升级,让双方的老板知道并干预解决。

谈到上下级关系方面:如果你是下属,对待你的上司,除了坏消息要汇报,好消息和一般反馈的信息也应该多与上司谈谈,争取他们的支持和指导,需知道,搞HIS,一把手不重视或者不懂,我们就很被动,成本高。如果没有办法改变他,拖也是一种办法。如果你是上司,对待你的下属,应该恩威并重。如果你在现场,以身作则,业务或技术过硬,你头上的宝剑已经足够锋利了,威信不言而表。施恩则因人而异,因才而异;如果你不在现场,应该有一个可以客观评分考核和奖罚的标准,既要额外的激励又要让他们有压力而且口服心服。老实说,这一点我还没有做得很好,但我相信随着时间的推移,我会找到一个合理的平衡点。

IT的实施工程师往往都是年轻人,年轻人都有个毛病:贪玩,而且“放养在外”,没有监管,更加容易松散。他们希望每天多睡一会,睡醒还有工资拿。这个世界上怎么有那样的好事?不得罪人,不把他吵醒,怎么成事?所以,公司也应该建立一个项目办公室(PMO),对项目的总体计划、月计划、周计划、日计划要时时更新,要求现场人员按时汇报,每周跟客户负责人开会或电话回访,注意回访时联系现场负责人的本周工作成果(即周报内容)来询问核对,如果与周报内容对不上,要调查周报真实性和用户的真实想法。PMO要分析,还有结合用户的反馈进行对比。当天解决问题,即时通报情况,谁做错就追究谁,不行尽快往上汇报。现场人员的责任就是要盯紧用户同时催紧公司的项目管理员;项目管理员的责任就就是要盯紧现场人员同时催紧公司的开发人员;PMO的的责任就就是看哪一边盯紧各方,凡是风平浪静的,链条没有拉紧的,都是风。PMO记住一个原则:做项目不是做买卖,怕得罪人就做不好项目!关于用户现场问题,我们既要保持紧迫感,也要注意沟通技巧。腾讯共享文档(docs.qq.com)的作用是“沟通桥梁”,“看板靶子”,是“情绪镇静剂”,给老板、PMO医院领导、信息科、用户去看进度,去沟通,引导大家关注目前还有哪些具体哪些问题,以及关注问题分级和解决进度,引导大家“以问题为核心,就事论事”,大家不要花费时间在口舌和情绪上,应该把焦点放到具体问题上,针对问题来沟通、答复、管理督促。引导用户写问题,这个文档的沟通流程应该是用户QQ或电话沟通确认存在问题,然后在文档中登记(提出),我们填写负责人和完成时间(答复),用户再确认(闭环)。我们要知道用户也是要催、要管理的,如果你不早说,出问题时我们不要埋怨用户“为什么上班的时候不提?”这样的话。

我在审核项目工作量的时候发现问题:我们开发、实施都过于马虎——开发人员在完成工作后随意丢给客户,实施人员也没有把好关!造成客户抓狂,而我们自己也被动、挨骂,还不断的修修补补,后台查改错误数据来补救,浪费时间精力。这个是“血的教训”呀。我们应该明确,开发人员出来的东西在“出街”之前要测试一下,起码要避免低级错误;开发人员要告诉实施人员修改了哪些东西,在部署之前实施人员先把关测试,对之前的问题反复测试,并对可能性的错误进行预测和测试验证,例如上线前,必须把正式库备份成练习库,自动化测试或手工测试,先在最新的练习库用这个专家的工号完整走完一次门诊流程,包括预约、挂号、开处方、写病历、收费、发药,检查、检验。如果发现有程序问题或数据问题,叫开发人员加班解决,不要抱有侥幸心理。如果遇到低级问题,实施人员要骂人,投诉,学会问题升级。对客户多一点敬畏感,只有严谨和谨慎,我们才能做得好。

我们经常会骂公司的产品开发速度和产品质量问题,说什么“跟他们讲了很多次”、“问题反反复复出现”。我们要知道,产品质量来自于管理过程而不是来自于人工测试或人员能力。必须按照公司的管理流程,互相督促,层层把关,出问题的时候,链条是要拉紧的,大家都有责任。严格按照公司要求的“统一出口、禁止走私”、“每天三次内测、每天一次公测、每周一次打包”、“公司测试库->现场测试库->现场预发布库->现场正式版,逐级发布并经过自动化测试和确认完成”,即使是临时发布,也是要严格按照执行,像打排球一样,一传二传扣杀,有条不紊,不要乱了阵脚。

作为项目管理的新人,应该多问,多看文档,多对比其他项目。在项目现场实施过程中,如果需要人帮忙,先问帮带师傅;他搞不定就问信息科;信息科搞不定就问代理商;代理商搞不定就问老板。关于新人的培训,对于我们的实习生,必须给他们任务或题目,给他们问题,给他们切入点,同时给他们足够的压力,包括考试、考核。每个星期他们要达到什么水平,完成什么作业(任务),如何考试和评估,要开始认真规划一下,“放养式成长+无监管”的实习培训,进步太慢了!对于这些新人,每天带着学习的态度去工作,带着问题去工作,比学校里面的看书、听课、考试,更加有效果,如果不理解,不相信,不执行的实习生,要坚决开掉。因为这本身是一种态度,对于毕业实习生,我们需要一些形式来观察人,发现人,然后培养人,而不是为了留住他们,只有经过发现和培养的人才值得我们留住。

关于

项目的成功跟很多因素相关:公司开发服务(产品质量,管理流程,能力,及时性,知识库)、现场沟通、商务配合、客户个性、客户规模……等等。当你听到“我完成了”的报告,你不要急着感到高兴,请细心一点,看看质量如何再说。谁监管谁验收?我问过项目相关人以后再答复你。如上所述,HIS项目失败因素多,尤其是周期长,医院强势,实施人员年轻好玩,如果不是老板在现场,普通的项目经理,是经常会出毛病的,这个是我的经验。所以,不管哪个代理商,我都应该他派人跟我们在现场,而且要拉医院的人一起开会,互相监督、提醒,我不希望到了最后才去扯皮,或上线后去补救。项目的完成质量问题有时会困扰你一段很长的时间,让你后悔一辈子。写到这里我就没有话说了,最后归结到最后一句话:

——亲,我们的项目经理,你的心可以没有这些项目实施的知识和经验,但不可以没有你的项目,而且要满满的装着。用心其实最重要!

祝工作愉快、顺利!

 



标签:   项目管理 项目经理