项目上线半个月,运行平稳,自去年7月项目启动到现在已经1年有余,而自己这1年多时间也大部分在北京渡过,经历了北京的春夏秋冬四季,北京空气治理成效和雾霾天的明显减少,也让自己在时隔差不多5年后对北京有了新的认识。大型ESB总线和集成平台实施项目,基本都是以年为单位,超过1年那是常事,一做就上5年10年也是正常,而这种大型项目,相对来说也更加锻炼人。
经验来源于亲身实践,来源于在一线的证悟 ,虽说对于ESB类实施项目已经做了10年,但是还是感觉对于这种集团型的大项目,基本每个项目做下来都能够有所收获,能够弥补原来的知识漏洞并完善知识体系,也能够进一步的通过项目实践形成更加体系化的思考框架和管理模式。
软件项目管理本质是对人的管理和风险管理
对于软件项目管理,其本质仍然要回归到两件事情上面,一个是对人的管理,一个是对风险的管理。
当我们在谈人的管理的时候,比较容易谈的还是人力资源管理方面的内容,比如人员招募,团队组建,工作的分配,学习和培训,考核和激励,成长路线规划等。这些都相当重要,但是今天谈人的管理不谈这些方面,对于软件项目管理中人的管理, 核心是在于如何形成核心小团队,比如3到5人,有项目经验,共同目标,通用词汇表,高度的配合默契。
不管是20个人的软件团队,还是上100人的软件团队,你会发现最关键的就是这个核心小团队,一般控制在7个人以内。我们做软件讲核心底层架构,这个核心团队就是整个项目底层架构,只要这个底层架构稳固不垮掉,那么个别功能出现问题不影响大局。但是如果这个底层架构都不稳固,那么整个软件团队想协同好也困难。
如何讲这个小团队呢?就是说你将工作目标或任务安排到这个核心小团队的时候,你至少能够做到95%以上的信任度,能够按时按质的得到交付,而不是你事必躬亲,你的重点是在这个小团队如何高效配合,协同运转,而不是在于检查。
核心小团队人员之间最重要的就是信任,对承诺的信任,对个人技能和能力的信任,这是配合的基础。
除了对人的管理外,项目管理最重要的不是简单的制定目标,分解WBS,排计划,而是风险管理。
前期大量经验积累最终带来的是关键风险预判
在谈项目管理的时候,我经常会强调一个观点,就是项目管理本质是风险管理,风险管理贯彻整个项目管理生命周期过长。如果在项目管理和执行过程中没有风险,那么项目就应该一定能够按照既定目标完成,因此项目延期或超支,都是前期关键风险没有识别导致,到这里最后风险变成问题,你只能是疲于奔命,花费比前期多达数倍的人力和物力资源来解决。
软件项目管理是技术型管理,对于项目经理而言技术背景和一线技术实践和重要,可以试想下你没有经验,你如何排计划,如何分解WBS,如何识别关键风险?所有这些事情你都会感觉寸步难行,都要依赖于下面的需求人员或架构师帮助你来完成。
风险管理方法和流程,犹如教科书般标准,从风险识别,风险定义,风险定性分析和定量分析,风险应对和缓解,风险监控等。但是风险管理的真正核心不在这些地方,而在于你是否能够识别出关键的风险。你所有的QA过程检查都100分,风险登记册做的很漂亮,但是最终项目还是失败了,原因就是关键风险没有识别。
一个有经验和有技术背景的项目经理,最重要的一个能力就是识别项目关键风险的能力,同时对于关键风险即使转变为问题,还有Plan B计划。什么是最关键的风险?简单的拿考试来类别的话,就是关键风险是确定你是否能够及格的风险,而不是那些是评估你考80分还是90分的风险。我们把大量时间花费在80分到90分上,而最终发现一个大的失误,导致根本没及格,如果这样就根本没法玩了。
项目管理的重点是分清优先级和轻重缓急
有是很简单的道理,但是这个确实又是项目管理的一个重点内容。对于项目经理来说,精力始终是有限的,那么你就必须思考清楚你的精力应该放在哪些关键的事项,关键的风险,和关键的问题解决上面。
我们可以举一个最简单的例子,当前项目里面有一个关键的技术问题没有解决,直接影响到平台的正常运行,那么你这个时候是去花精力解决这个关键问题还是说按PMO的要求提交细分后的计划,周报等内容。显然就我自己来说第一时间做问题解决,计划和周报找其他人完成,即使提交给PMO计划不足够准确也无所谓。原因很简单,关键技术问题涉及到你是否及格问题,而计划是否按时提交只涉及到你是90分还是95分。
再举个例子,项目临近上线阶段了,整个软件产品的功能基本封板,这个时候可能甲方让你紧急增加两个报表功能,而且要在上线前完成。那么这个时候你如何应对?这个时候最好的策略一定是不做,原因就是上线前的各种检查,风险预案准备,查漏补缺,这些功能重要度远远高于两张报表功能。即使前面仍然有时间空余,最好做法也是不要接新需求和新开发任务。经常做软件项目的相信都有同感,在上线前项目越是忙的不可开交的,基本上线后都会出乱子, 所以你更加应该意识到在项目上线前能够真正空下来,做思考,做全面检查和风险预判,并且准备关键风险的PlanB更加重要。
项目管理不是简单的授权和放权,而是真正知道这个项目的Key Point究竟在哪里?甲方或你的干系人理解的关键点和你理解的关键点是有区别的,你不要被外界带着走。项目日常工作和事务如此之多,你要做到的就是对于关键点能够真正一插到底,乃至自己亲自上阵协同解决。而对于非关键的东西完全不要去太多关心或分散自己的精力,这些最好的就是工作例行化后能够交给你的助理去做。
这也再次说明有技术背景积累的项目经理往往在确保项目按期按质交付上面往往更加有优势,项目经理往往能够起到最后一层缓冲和后备力量的作用。即总是能统揽全局,发现关键问题,并解决关键问题。
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- 【Vue项目总结】后台管理项目总结
- 项目管理总结02(10.30)
- 项目用 GoModules 管理依赖的方法和经验总结
- 项目管理基础:什么是项目管理?
- 项目组合、项目集、项目管理实践经验及思考
- 项目管理:如何避免项目延期?
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Release It!
Michael T. Nygard / Pragmatic Bookshelf / 2007-03-30 / USD 34.95
“Feature complete” is not the same as “production ready.” Whether it’s in Java, .NET, or Ruby on Rails, getting your application ready to ship is only half the battle. Did you design your system to......一起来看看 《Release It!》 这本书的介绍吧!