天生我才必有用

每个项目干系人对项目的工期当然希望越短越好。如何缩短项目活动的时间，来最快的完成项目呢？

1. 增加资源：这种办法不容置疑会增加项目的成本。同时另一个缺点是不可经常使用，长期的加班势必造成心力憔悴、身体不适，最终反而影响了项目的进展。
2. 减少任务活动的范围：这种方法势必损害了项目干系人的利益，采用的可能性不大。
3. 降低工作质量：这是一种非常不可取的方法，可能在某个阶段，项目干系人采纳了这个建议，但最终你还是必须完成此项未完成的工作，对项目负责方来说绝对不可取。
4. 改变工作工艺：这种方法可能是所有方法中最提倡推广的，毕竟对所有项目干系人来说都会带来益处。虽然有一定小成本的支出，不过应该最终会带来较大的回报。

从网络上找到的，分享给大家。

不知道PMBOK?不会吧，PMBOK就是美国PMI研究的成果，全称Project Management Body of Knowledge，提供的是最新的2004版，不过看来这个版本会要给新的版本替代了。

下载地址

“80％的业务来自20％的顾客。”这句通常被称为80/20法 则的格言，出自美国质量管理大师约瑟夫·朱兰（Joseph Juran）。上世纪30年代末，在底特律的一间汽车组装厂，朱兰就缺陷如何进入生产系统的问题进行了研究，并得出结论：80％的问题是由20％的系统引起的。

他把这一现象称为巴雷托法则(Pareto Principle)，以纪念意大利经济学家维利弗雷多·巴雷托(Vilifredo Pare- to)，巴雷托曾观察到，意大利80％的财富被20％的人拥有。

朱兰进一步将该理论应用到其它商业方面：80％的利润由20％的雇员创造；80％的成本由公司20％的部门产生；最后，80％的销售额来自20％的顾客。

精确的百分比不那么重要，关键是原则：一小部分顾客通常带来一大块不成比例的销售，这些顾客频繁购买．或大量购买，或两者兼备。

很大程度上，对购买模式的研究证实了我们的常识：有小孩的家庭会购买大量洗衣粉；大批量制造商要比小批量制造商定购更多的原材料和元件，等等。

因此．这条法则在理论上基本正确，问题是如何运用它。朱兰在对该法则的论述中，使用了两个关键术语，他把多数人(即80％的顾客)称为”有用的多数”(useful many)，没有这些人，公司会遭受损失，但仍能生存下去：他把20％的少数人称为”关键的少数”(vital few)，即使只失去少量这部分顾客，公司也会陷入困境。

有两种策略可供选择，第一种是把注意力集中于”关键的少数”，并逐渐甩开其他顾客。然而，这会导致企业把所有鸡蛋都放在一个篮子里．当顾客需求改变时，企业就会自食其果。

几年前，福特(Ford)和通用汽车(General Motors)决定，集中发展利润丰厚的运动型多用途车。如今，消费者对该车型的需求迅速下降．福特和通用都忙于寻找替代策略，同时也在亏钱。

另一种策略是，针对不同顾客群体采取不同方法，这要求市场营销人员接近关键客户。鼓励他们加大消费力度，同时也要接触边缘顾客群体，鼓励他们也多花钱。

这一策略有助于增加利润，并减轻对少数顾客群的依赖。英国超市集团特易购(Te8CO)就是这样做的，它用不同的方法吸引不同的顾客群，让他们更离不开特易购。结果．特易购的销售额占英国所有商店销售总额的7％。

某些情况下，专注”关键少数”，放弃其他顾客的做法可能是正确的，但做这样一个决定决不轻松。在这么做之前。要想一想得到那些顾客多么不容易，然后记住，如果放弃这些顾客，以后再要把他们争取回来就需要花费双倍力气。

1. 概念确立。就是对所要做的事情有一个框架性的设计，有一种思想。
2. 问题的定义。即对长远目标说明。第二步骤是对第一步的进一步细化和具体化。
3. 生成项目的备选方案和战略计划。就是提供思路、备选方案和战略计划总体思路。
4. 战略计划评估和选择。就是在选择方案的同时，有一个从总体技术路线到总体项目管理策略的评价和选择。
5. 战略的确立。就是确定具体的战略、目标。
6. 制订项目的实施计划。这是一个更加具体的、第二个层次的项目计划，就是怎样实施。
7. 项目干系人批准计划。这里的计划包括战略计划、初步计划、详细计划，在这些项目实施之前，有一个批准过程。
8. 签署项目计划。项目的批准人、参与项目的有关干系人要签署项目计划，对计划做出承诺，同时建立项目的跟踪记录，做一个项目进展情况日志或者周志、月志、记录，根据这些记录信息进行知识管理。
9. 执行项目计划。执行项目就是正式开展计划，进展这个项目。
10. 监控项目进展。计划开始实施之后，就要考虑计划执行得如何，有无问题，要对进展情况进行监控、监测和控制。
11. 审查项目定义。项目实施之后，需要做一些评审，评审包括对原来工作的评审，同时也包括对项目目标定义的评审，如有问题就返回到步骤二，重新修正项目的定义。
12. 对项目的战略进行评审。首先是评价目标或项目的定义，然后评审战略计划、战略制订是不是有问题，如果有问题就返回步骤四，重新修正你的项目战略。
13. 项目的实施计划。具体的计划工作流程、对一些细节要进行评审，有问题就进行修改。
14. 循环。按照整个过程不断地从计划的执行到监测、评审，有问题就要修改计划，然后再执行，再评审，这个过程一直延续到全部工作结束。
15. 总结经验教训。项目全部完成以后，及时总结经验教训，对一些问题进行归档，作为今后项目的指导和借鉴。
16. 结束项目。这是一个完整的项目管理流程，从这个流程可以看到整个项目战略计划实际上是在制订项目的详细计划和实施计划之前。在项目计划的时候，首先要有一个总体的战略计划，在总体的战略计划指导下再开展具体的项目计划。

这个模型可能定义了比较详尽，单个人感觉模型定义如此，是否过于复杂？

QFD(Quality Function Deployment)质量功能展开是日本质量专家赤尾洋二在20世纪70年代提出的。所谓QFD就是将市场的需求转换成代用特性，以确定产品的设计质量，并将其系统地展开到各功能部件的质量、零件的质量，直至过程要素。

QFD通过定义“做什么”（质量需求）及“如何做”（代用质量特性），使产品或服务具有令顾客满意的、稳定一致的性能；通过明确地定义完成任务所需的工作 目标，有助于将顾客定义的质量客观地注入到产品或服务中，从而实现以市场为导向的质量管理思想。即从顾客需求确认到产品（服务）输出确定，再到过程要素分 析以及输入条件的要求。

尽管QFD并不能确保成功，但它大大地提高了获得成功的可能性。

质量功能展开的程序有以下几个步骤：

1. 顾客需求展开
2. 关键顾客需求确定
3. 技术要求（质量特性）展开
4. 质量表编制
5. 关键质量特性确定（输出质量设定）

在Eclipse中集成Subversion的版本控制应该是最方面的，可能也是最佳的解决方案。两个原本都是Open Source的系统，可以非常方便的集成在一起。同时候选方案还不只一种。使用比较多的是以下两种:Subclipse和subversive。

1.Subclipse:

这个不用介绍了由Subversion的官方发布的Eclipse 的插件，从Eclipse比较早的版本已经开始支持，使用纯Java的代码。最新可以支持到Eclipse Europa版本。

2.Subversive:

由Polarion Community开发，a brand new Eclipse Client for SVN，从他们的目标中就可以看出是准备打造全新的Eclipse的客户端。曾经使用过一段时间，感觉界面操作和Subclipse非常的相似，但稳定性却大大不如Subclipse，使用了一会就会造成Eclipse的异常，最终我还是选择回了Subclipse。

同时两者都支持和Eclipse中Mylar插件的结合，不过个人感觉安装了Mylar后会对Eclipse造成很大的影响，所以只能忍痛割爱，放弃这个Mylar的插件。

（阅读全文…）

很久没有关心Subversion的更新情况了，这几天由于公司准备架构Subversion的代码版本控制，所以特意去看了下Subversion，突然发现在原来下载的地址中多了一个VisualSVN Server。既然有新的工具那就是用一下。

Visual SVN Server是由原来做Visual Studios Subversion Version Plugin的团队开发的，不过这个Server是免费的，不用支付任何费用就可以使用。它整合了Apache + Subversin + SSL。安装不用说了非常的方便，安装时可以选择8443或者443作为HTTPS得端口。

安装完后，有一个管理的UI界面：可以建立用户、设置密码，同时还可以建议新的代码库。对初学者来说避免了很多Apache服务器的设置。同时也不用运行svnadmin来建立svn repository。总体来说，打个80分。

需要下载可以连接这个页面 。

其他功能还在摸索中，会陆续补充说明。

1.Physiological Needs (生理的需要)
2.Safety Needs (安全的需要)
3.Social Needs (社交的需要)
4.Esteem Needs (尊重的需要)
5.Self-Actualization (自我实现的需要)

（阅读全文…）

盈亏平衡分析是指项目投产后，在一定的市场、生产能力及经营销售条件下，确定产量、成本、价格、生产能力利用率、利润税收等因素之间的关系，找出一个平衡点，大到收入和支出平衡，净收益等于零。

盈亏平衡方程 PQ = F + VQ。

式中：

• P ：产品价格。
• Q ：设计产量。
• F：固定成本。
• V：单位产品变动成本。

1. BCWS (Budgeted Cost for Work Scheduled) : 项目实施过程中某阶段计划要求完成的工作量所需的预算工时
2. ACWP (Actual Cost for Work Performed) : 项目实施过程中某阶段实际完成的工作量所消耗的工时
3. BCWP (Budgeted Cost for Work Performed) : 项目实施过程中某阶段实际完成工作量按预算定额计算出来的工时
4. CV（Cost Variance) : 费用偏差 CV = BCWP - ACWP
5. SV (Schedule Variance) : 进度偏差 SV = BCWP - BCWS
6. CPI (Cost Performed Index) : 费用执行指标 CPI = BCWP / ACWP
7. SPI (Schedule Performed Index) : 进度执行指标 SPI = BCWP / BCWS