项目管理-7-降妖除魔

来源：互联网发布：js获取li的name属性编辑：程序博客网时间：2024/04/29 14:22

项目管理-7-降妖除魔
引言
前面说到‘唐玄奘披上袈裟，领的禅杖，手捧金钵，辞别唐王’，从此上路了。取经路上，各路妖魔鬼怪，魑魅魍魉，凶神恶煞，无不想吃掉唐僧，以得永生。幸亏收得悟空，悟能，悟静三位高徒，才保得唐曾，不辞艰险，一去西天，取得真经，修得正果。
对于项目管理，前面的制定章程，规划，估算，日程安排，创建团队，算是项目的前期准备的话，那么现在就该正式运行了，项目管理，就是风险的管理，而整个项目过程中风险迭出，层出不穷，如何才能发现风险，分析风险，消除风险呢。本节就说一下一些具体的管理实践。
需要注意的是，这些实践有很多，他们之间没有特定的顺序，但是有彼此的联系，要融汇贯通，多管齐下，才能达到你想要的目的，即，项目的成功。就像三徒弟一样，法力不同，性格迥异，但只有同心协力，才历尽磨难，保得唐僧，功德圆满。
下面就一一说一下这些为项目保驾护航的管理实践。

7.1紧握船舵
7.1.1发现影响项目节奏的情况
1》不知道先要完成哪些需求
如果有人问你‘老大，咱们先干什么呀，先弄哪个功能啊’，这就有问题了。
2》需求相关的工作花费了较长的时间
如果都过去好几周了，还在有人问你‘老大，你看，现在还有哪些需求啊，是不是该进行需求分析了’，赶紧的，别收集需求了，赶紧组织，找到最重要的那个需求，进行分析，不要再召集所有人，对所有需求进行分析了。
3》GUI人员不知下一步干嘛
如果前期一直在做底层的功能模块，GUI的人员一直闲着，整天上网，聊QQ，那么记住‘按功能实现，而不是按架构’。一个功能的实现，一般会涉及到GUI。
4》没有对架构的整体描述
如果大部分的人对这个项目的整体还不了解，只知道自己的‘一亩三分地’，不行！赶紧的，召集到一块，整体介绍一下。
5》要完成某个功能，需要增加相应的技术人员，但是领导不给人。
没人什么也干不了。并且尽量不要外包，尤其是对于一些嵌入式的项目。环环相扣，外包来填补空挡，难度很大。

7.1.2举行中途回顾会议
抽空，大概每两周举行一次，召集大伙，谈谈心，聊聊他们对项目的感觉，看法，建议。开完以后，给人家一个回应，这个很必要。

7.1.3给需求排序
不要一个word文档，从头到尾，一行行写着需求，除了一个序号，没有其他的标志。要给需求排序。按价值，给需求排序。排序，程序员一定不陌生，采用‘冒泡法’就行。当然，需要考虑一下几方面的因素：对架构的影响，完成计划所用的时间，对于客户的重要性，实施的技术可行性。
防止出现‘这些需求都很重要’的情况。

7.1.4制定productBacklog
上面排完序，写到excel里，指分析前面几个需求，并分解成小任务，完成后，依此类推。各个击破。

7.1.5用时间盒限制需求相关的工作
如上所叙，对于需要，当断则断，不断则乱。

7.1.6使用显式或隐式的迭代
千万不要把整个项目作为一个迭代，不行，要把功能分解成小功能，用一定的时间完成，然后测试，集成。即，持续集成。如果公司不允许什么‘迭代’的概念产生，低调点也行，直接这么做就行了，别给他起个名称，实在不行，就起个外号。也成。

7.1.7波浪式的规划项目，安排日程
不要试图，一口吃个胖子。要按经过排序的需求列表，化大为小，循序渐进，各个突破，持续集成。

7.1.8创建跨职能团队
尽量使自己的项目团队的角色多一些，包括，做架构的，编码的，测试的，GUI的。这样会有好处的。技术越全面，做出来的产品越完美。

7.1.9选用合适的生命周期模型
前面已经说过了，适合自己的最重要。

7.1.10保持合理的加班时间
一般一周不要超过两天在加班。要不然团队会抱怨的严重。产生抵制，效果会适得其反。如果出现了，就修改日程安排或调整资源配备。

7.1.11化整为零
把大任务，分解成小任务。一般不要超过1个人日。

7.1.12应对干扰
人是社会的人，总会跟别人打交道，要打交道，就会有干扰。一般干扰分为两种，其他项目的干扰，其他人的干扰。
对于其他项目的干扰，要尽量推迟，最少要推迟到下个迭代。并且把这些干扰都记录下来，然后呈献给领导和其他人看，让他们明白，干扰带来的影响。
对于来自其他人的干扰，要结对编程（别先假设团队不愿意，要先允许结对），对于讨论问题，让他们到封闭空间，别影响其他人。

7.1.13从项目开始就管理缺陷
在项目开始之前，就准备好bug列表，发现一个，记录一个，解决一个，更新一个。不要认为，bug是从项目后期才会出现的。而这就要求在一开始就有测试人员介入。如果没有测试人员，就把单元测试的结果填写进去，并时刻提醒成员，现在就有bug。

7.1.14多几只眼盯着项目
寻找机会，让更多的人来了解项目，了解已经实现的功能，并进行试用。对于团队内部，要尝试结对，同伴互查，走查，正式检查等方式来发现bug，增强健壮性。

7.1.15用故事来描述需求
对于需求，不要用很深奥的术语来描述，没几个人仔细看。要假设一种情景，把需求入其中。

7.1.16选择简单的工具来进行项目管理工作
别整好多专业的软件，云里雾里，效果不一定会好，还要花很多时间来学习，还要培训团队。一般情况下，简单的excel就能办到。

7.1.17不要开那些费时费力，没有多少效果的会议
首先要从自己做起，别动不动就把某某叫到自己的办公室。没什么事的话，就通过邮件沟通就够了。如果真有事，一般别超过15分钟。要不人别人会烦‘我刚要干活，你就把我叫过去了，结果今天什么也没干成’。
当然有些会是一定要开的，比如，项目启动会议，发布版本规划会议，迭代回顾会议，等。还需注意的是，会议之前要准备好，通知到。把会议目的，日程，讲义，要提前发给大家。这样会省好多时间，效果还好。要有会议记录，会后要有跟踪落实。要‘责任到人’。除此之外，每周要有一个进度报告，通过邮件的形式就行了，并且要让所有人知道当前项目的进度情况，以及别人的进度情况。即，敏捷里面的‘透明性’，这个真的非常重要。

7.1.18向领导和客户展现风险和已完成的功能
要定期的想老板和客户报告项目的风险，当然还要给他们信心，就是展示团队已经完成的功能。让他们看到，这个项目在一天一天的有所进步。

7.2张榜公示
通过上面的实践，是不是起到作用了呢，项目的进度是否合适呢，就需要反馈机制，这些反馈最好以图表的形式展现。下面就说几种，供选择。

说明，其实这些变量之间是存在关系的，为了方便，没有严格描绘，请见谅。

7.2.1功能数目图

全部数目
已完成数目
剩余数目
————日期