项目管理的本质是管理进度、质量和成本,很显然,这三者是相互制约的,项目管理就是想通过一些方法论以及手段来优化三者的组合,以达成项目的最终目标。要求低成本,高质量、快进度的项目,从某种意义上讲,本身就是“耍流氓”,但服务提供方往往没有办法,还得接单,还得屈从,还得要提供满意的服务。不合理的项目要求并不是不能生产出可用的软件,只是在软件最终体现的属性上会大打折扣,得不偿失。现在大多数的客户方迫于市场和竞争的压力,往往是要求进度和成本优先,这样的项目的特征是:进度的坑优先填完,但质量和最终总成本的坑才刚刚开始。同时,由于存在大量的同质化的服务提供方,不讲商业规则,赔钱也要和你争一争,导致服务定价极端混乱,身处这样环境,作为项目管理者,往往是很无赖的,于此同时,我们又必须要服务好自己的客户,要考虑如何在成本和进度受控的情况下,以好的质量完成项目。我们该如何做呢,在这里,我想谈谈自己的一些看法。
特别说明:本文中的项目管理主要是指软件项目的管理。包括定制化软件项目,软件集成项目等。一家之言,有不对的地方,请大家指正,或者留言讨论。
一、建立业务壁垒
软件项目很大一部分都是由业务的发展驱动而产生的,是业务处理由手工到半自动,再到智能的全自动的过程,本质上都是借助信息化和数字化手段帮助客户完成其想要达成的事项。
这些事项我们称之为需求,正确的理解需求是很关键的,会面临很多的困难,是一件很有挑战的事情。在需求理解的过程中,首先要关注的是客户直接关心的功能性的需求,它决定了要做什么以及如何做,然后再关注如何提供便捷、快速、高效的处理方式等非功能性的需求。对服务提供方来说,最初的我们可能只是擅长技术,不了解或者很少了解客户方的业务需求,所以,如何快速有效的形成对业务需求的掌握和延展是关键,只有我们很好的理解了客户的业务需求,利用我们擅长的技术有效的驱动和促成客户需求事项的信息化、自动化落地,我们才能赢得客户的信任,我们才有机会去为客户服务下一单。
通过持续不断的理解、积累和挖掘客户方的业务需求,我们才有可能成为某个具体业务的专家,某个行业业务的专家,最终建立自己的业务壁垒。当然,这种能力是需要长时间的积累和沉淀的。
二、优化团队管理
软件项目的具体实施需要许多的资源,在这些资源里面,人是一个关键的资源。现在的软件项目的实施通常都是团队协作完成,如何管理由人组成的团队是一项有挑战的工作。项目实施过程不管是采用敏捷迭代还是传统的瀑布模型,对参与其中的人的管理以及协调,是项目能否成功落地的一个很关键的因素。团队管理应当关注团队成员的技能构成,团队的沟通协调机制、团队的激励机制、团队的风险控制机制等。
团队中最好要有技能的分工,每个成员在具备基本技能的情况下有自己的技能专长,基本技能帮助其完成普通的任务,技能专长帮助团队完成关键任务以及解决棘手的问题,在团队的运作过程中,每个成员都能高效的运作。
团队要建立良好的沟通机制,成员之间要保持及时有效的沟通,良好的沟通机制能有效的减少成员连接时的消耗成本。具体的沟通机制包括实时通讯工具,电话、会议,定制汇报等形式。
团队要建立有效的奖罚机制,奖励能促进团队工作开展的成员,惩罚拖团队后腿的成员。考核标准可以综合考量个人专业技能,沟通协调能力、责任心、抗压能力等。
团队要有风险控制意识,团队是一个抽象的存在,团队中的成员却是具象的,是会流动的,项目管理者要正确看待这样的流动,做好人员储备、留存的工作,做好工作经验的文档化工作,团队的经验应该以文档化的方式留存,不要散落在具体的个体成员。
三、建立合适的项目过程管理
项目过程管理是一种制度建设,通过总结项目实施过程中踩过坑,经验教训,形成一套可重复利用的项目实施准则。业界现在比较流行的是CMMI项目过程管理模型。CMMI项目过程管理其实是比较复杂的,其是按着软件项目的生命周期分阶段的进行管理,重点关注的有需求管理、进度管理、风险管理、质量保障等。
文章的前面部分有提过,现在项目的特点是:成本受控,进度受控,这样一来,在现实的项目管理过程中,如果完全搬用CMMI项目过程管理的方法,项目就会很难落地。CMMI项目过程管理增加了很多附加但必要的工作,天然就会增加成本和影响项目进度。良好的规则制度(CMMI模型)需要配套的基础设施(合理的成本和进度要求)才能发挥应有的作用,这是现实与理想的差距。然而,我们又不能完全去掉项目的过程管理,我们可以做的是,根据自身项目的特点基于CMMI模型进行裁剪,找到与项目实际情况吻合的项目过程管理方式和方法,通过量身定制的方式来实现项目的过程管理。
项目过程管理的重点是关注项目的过程,它是动态的,但我们目标却是通过若干个动态的过程找到一些静态的处理方式,以不变应万变,所以要形成过程管理的文档,形成历史,同时,我们又要时常去学习这些历史的东西,从中获取项目过程管理的经验和教训。