摘要:
计划赶不上变化,计划还要不要写呢?项目工期限死,估算有什么价值呢?只有项目经理紧张项目,其他人是打工心态,怎样办呢?PMP的知识能搭救项目吗?如何才能做出一个按期交付的完美计划呢?所有问题,将在这一篇中大爆发!
说明:
这是“挨踢项目求生法则”系列文章,之前已经为大家分享了战略篇、团队建设篇、需求篇、设计篇、编码篇、测试篇、实施篇,这篇是计划篇。
什么叫挨踢项目?
IT项目,特别是软件开发项目,都属于“挨踢”项目的范畴。挨踢项目的几大特点:
1.需求不确定。
2.技术不确定。
3.工期限死。
4.预算限死
两大不确定和两大限死,你想不“挨踢”都难!
什么是项目计划?
实际工作中计划应该在前面就写了,为什么本系列文章直到第8篇才写计划这个主题呢?
计划其实就是为了实现项目的目标,对项目各项工作的统筹安排。
那什么是项目的“各项工作”呢?
各项工作包括团队建设、项目分析、需求分析与管理、软件设计、编码、测试、实施等,本系列前面的文章逐一分享了”各项工作“(当然项目的”各项工作“不止这些,后文会补充说明)。各项工作的最佳实践,将会直接决定计划的质量。为什么在第8篇才分享“计划”这个主题,原因也是如此。
计划对加速工期有多大帮助?
有朋友问了一个计划应该如何写的问题。这位朋友已经有几年的软件研发一线工作经验,项目经理的工作也不是第一天干的,问出这样的问题我觉得有点怪。但我仍然说了一通项目计划的“大道理”供他参考。然后他说:项目成员技能不足,计划怎样写?
后来我才发现,他的真正问题是:如何写好计划以保证工期!
我给出的回答竟然是:计划本身对加速工期并没有帮助!
要加速项目工期,主要在于两方面:
1)提升需求分析与管理能力,能为客户带来价值的前提下,尽量将需求控制在一定范围内并尽量简单。
2)提升软件的设计能力,让项目的整体工作量下降。
如果项目小组能力不足,并且不重视上述两个方面,那么这个计划怎样写都是写不好的,写计划不是纸上谈兵啊。
而通常情况我们的工期是限死的,所以我们的计划是“倒推法”写出来的,计划中的关键节点基本上通过倒推法已经卡死,我们能做的事情就是想办法让事情变得更简单、工作量更少和提升我们的能力,以便在工期内完成项目!
所以计划及计划跟踪的问题,并不是仅仅本篇就能解决的,你还需要再认真看看前面的几篇文章,理解项目的”各项工作“是做好计划的根本。
法则1:项目管理首先是一门技术活
作为新上任的项目经理,如何写计划指导大家工作呢?
首先请做这两条自测题:
1)你熟悉这个项目需求吗?
2)你熟悉这个项目需要用到的开发语言、数据库和相关技术吗?
如果上述两条题目的回答都是NO,你是无法开展工作的。
软件项目管理首先是一门技术活,如果你不懂需求、不懂技术,你将会:
1)无法拆解工作;
2)无法和项目组成员沟通;
3)无法与客户沟通。
当然大部分项目经理是技术出身的,这方面的问题就不太严重;但有些项目经理是“外行”出身的,如果又不愿意去学习需求和技术,那么只能说祝你好运了……
法则2:项目经理需要周身刀并且每把刀都要锋利
中国的项目经理,通常要干以下事情:
1)项目管理(这个不用说了,废话);
2)需求分析与管理;
3)软件设计,包括数据库设计;
4)写代码;
5)测试软件;
6)和客户沟通;
……
或者这样说会更合适一点,项目经理不干的事情有哪些?结果你发现:没有!
项目经理必须是全才,而且各方面能力都需要数一数二!
当然你会说:你当我是齐天大圣啊,可以三头六臂地干活!
以下一些实用建议供你参考:
1)有机会要尽量每方面都学习一下锻炼一下,项目经理确实是需要全才;
2)如果项目规模不大,那么你一个人兼任”管理+需求+设计”是可以的;
3)如果项目规模比较大,你可以兼任“管理+需求”或“管理+设计”;
4)哪怕项目规划超级大,不建议你干“纯管理”的事情,你至少要兼任“管理+需求”。“纯管理”其实是干不了事情的,还需要其他人“服侍”你,你才能“纯管理”。
法则3:积极提升项目成员水平
我做过这么多项目,没有试过项目小组从一开始具备了完成这个项目所需要的全部能力,这种情况估计以后也不会发生。提升项目成员的能力和水平,是按期交付的重要因素,甚至是决定性因素。
员工离职的两个重要因素,一个是薪金,另外一个就是学不到东西。项目经理可能还无法直接提升项目成员的薪金,但你可以创造学习机会和环境,甚至是亲自传授知识给项目成员,让他可以学到提升薪金的技能。如果你的下属离职了,原因是一直学不到东西,那么你们两个可以抱头痛哭了!
法则4:应对变化的最好办法就是计划
计划赶不上变化,所以计划写了也没有用!果然如此吗?
你可能觉得软件项目“两大限死两不确定”很恐怖,其实有更恐怖的项目呢,那就是战争指挥!
打仗要不要写作战计划?战争中信息千变万化,你会因为这样而不准备作战计划吗?情况越复杂,不确定因素越多,其实越需要计划!
法则5:估不准总比不估算要好!
估算很恐怖,很多人不愿意估算,主要原因有:
1)“两大限死“,估了等于没估;
2)“两不确定”直接导致无法估算;
3)估算就是一种承诺,我可不愿意自己限死自己啊。
其实在我们软件开发届,估算偏差达到100%是很常见的事情,甚至是200-300%都很正常,但如果不估算,你的误差就是无穷大!
勇敢的跨出第一步,估不准总比不估算要好,估算和实际工作量之间总会有个谱,只要跨出第一步,我们就有改进基础了!
法则6:计划需要近期细,中长期粗,并持续细化和优化
曾经负责某项目,项目工期3个月,领导要求我写出3个月的详细计划。我很郁闷,死活写不出来,我不想纸上谈兵、不想浪费时间写这些没有用的计划,所以我还去和领导理论这样的做法是不合理的。软件项目存在这么多不确定因素,一般来说几周后的具体工作是很难计划出来的,所以法则6很重要。计划并不是僵化的东西,需要持续细化和优化。
其实比较怕遇到外行的领导,外行领导监督工作的办法就是让你写计划,然后根据你的计划来检查你,而这个计划的工期是卡死的。如果有人用这个你无奈而写的计划来卡死你,你肯定不愿意写这样的计划。
开明的领导是这样做的:
1)计划写出来了,我会全力支持你完成计划,包括:提供各种资源、协调各部门、协调客户等等;
2)计划可以变,可以推迟,但你要尽早告诉我;
3)我不会用计划作为你工作成绩的检查标准,也不会以此来绩效考核。
法则7:人人都是项目管理者
很多项目经理都有这样的感触:好像整个项目小组当中,就只有自己最紧张项目的成败,其他人的心态就是完成工作的打工心态。其他人似乎从来不会主动汇报工作,主动思考项目的风险与问题等。
项目管理是每一个人的事情,而不仅仅是项目经理的事情,每一个人至少需要做到:
1)全力完成工作,要保证工作质量;
2)要主动报告进度,遇到风险和问题要主动提出来;
3)要主动管理好自己的工作产品;(做好自己工作产品的配置管理)
4)要主动协助同事完成工作;
5)要主动沟通。
每一个人至少要做到能管理好自己的工作,如果自己的工作还需要别人来管理,这样的工作水平是不及格的!
法则8:计划的执行在于每一天!
我们都知道以下大道理:
1)项目的问题都是通过一天天积累的;
2)问题越早发现,解决成本越低。
但我们往往在计划跟踪上节省时间,结果得不偿失,在临近项目死期(发布日),进入正式测试阶段时问题大爆发:
1)某些需求没有实现;
2)某些缺陷无法改,需要改动数据库底层或软件架构才能搞定;
3)软件整体的用户体验很差,但这些问题已经遍地都是了,没有时间去改;
4)一大堆不符合编码规范的代码;
……
每天的计划跟踪能解决上述问题,并且能加速项目成员的能力提升。
跟踪计划的最有效方法是眼见为实,就是直接编译程序看看运行效果,同时检查代码与数据库实现。
法则9:通用项目管理知识的对项目的帮助不大
我在大学时曾经学过“施工进度管理”的课程(我大学学的专业是城镇建设),当时学了很多项目管理的知识,例如:前置任务后置任务、关键路径、单代号网络图、双代号网络图、甘特图、流水施工等等概念,开阔了很大的眼界,发现项目管理确实是一门高深的学问。后来我的课程设计就是要写一个施工进度计划,我纸上谈兵地完成了这个课程设计,结果我感觉良好,以为自己就是项目管理大牛了!
幸好我舅父给我泼了冷水,让我浮躁的心安静下来。当时舅父带我到某建筑工地见识一下,我见到工地的办公室中有一张很大的甘提图(进度计划),我问这个图有用吗?我舅父说:这个图只是摆出来应付检查的!
从事软件研发工作后,尽管我学过一些项目管理知识,但确实发现这些知识对项目管理基本上没有实质性的帮助。刚学习时,你确实会有“哇呀”这样的感觉,项目管理居然可以这样!实际上如果你没有丰厚的一线研发工作经验,软件项目管理是做不好的。
关于通用项目管理知识的学习建议:
1)公司报销或者你是土豪,并且你有很多空余时间,建议去考一考PMP,这个过程还是学到一些知识的;
2)没有银两,但你有很多时间,可以去自学一下,考证就不是必须的了;
3)这些通用的项目管理知识不要硬套到软件项目上。
还有会有SQA篇、SCM篇和维护篇
之前刚写完“实施篇”的时候,有朋友问什么时候写“SQA篇”?
确实我原来没有计划写“SQA篇”,“计划篇”就是最后一篇。
但计划赶不上变化,计划是可以调整的!我打算将来再为大家分享SQA篇、SCM篇和维护篇。
你有任何想法和建议,欢迎提出来!
作者:张传波
创新工场创业课堂(敏捷课程)讲师
软件研发管理资深顾问
CMMI首席专家
《火球——UML大战需求分析》作者
www.umlonline.org创办人
转载于:https://blog.51cto.com/fireball1975/1372564