小软件项目开发的管理
一个企业的管理，大公司有大公司的方式，小公司也有小公司的方式，如果把别人的经验生搬硬套到自己身上，可能会适得其反。同样，管理一个软件项目也一样，大项目和小项目的方式不完全一样。但从另一个角度来看，项目的大与小并没有本质的区别，很多方法是共通的。本文的目的是从作者的经验来谈谈小项目开发的管理。
一、小项目的特点
大家知道，“软件危机”的出现起源于一些大型项目的不断延迟甚至失败。小项目相比之下，具有以下特点:
1.项目功能相对较少
2.开发人员较少
3.开发周期较短
另外，在现实中，有很多小项目是由一些中小公司进行开发的，这些公司往往人员流动性较大，这也是不容忽视的一个现实.
二、小项目开发中常犯的错误
小项目看起来比较简单，比较容易成功，因而人们往往忽视了小项目的管理，其实这是一种误解，从本人的经验看来，小项目开发中容易犯以下的一些错误:
1、开发之前没有认真地进行项目可行性和工作量的估计。往往由于项目较小，便很草率地制定一个开发日程表，没有认真地估计项目难度，结果实际完成时间与估计完成时间往往有较大差别。
2、没有真正的设计过程
开发人员少，意味着不同人员的程序之间交互、接口相对少一些。开发周期短意味着往往是同样的几个人从头到尾负责一个项目。这两者都让人容易犯些错误。往往是几个人碰一下头，讨论一下最基本的数据结构、函数接口便分头去做自己的工作了，没有一份较正式的文档。
这种做法潜在的危险之一是有的人可能会对讨论出的接口、结构理解有偏差(应该承认人是会犯错误的)。一个误解可能造成以后的返工。另一个潜在的危险是由于讨论时忽略了某些情况，等大家都按当时的分工完成属于自己的工作后，才发现各个模块组合起来却形不成一个完整的系统。其根源在于没有一个负责协调的人员不断监控整个开发过程。
第三个潜在的危险是一旦有人中途退出开发队伍，其他人加入时，新来的人难以理解以前别人做好的代码，索性自己从头来。另外，没有文档的程序，日后维护和版本升级都比较困难。
3.不经过单元测试而直接进入系统测试
造成这一现象的原因是每个模块相对比较简单，但是为了测试一个模块需要建立一些测试环境。例如，为了测试一个函数是否正确，应该用一些测试数据去调用该函数，需要编写一些测试数据。但很多开发人员嫌麻烦，觉得反正其他模块也很快出来了，直接用真正的数据来运行几次就行了。
殊不知，一旦直接进入系统测试，发现运行结果不正确后需要一步步查找。由于模块间的调用关系，可能查了很久才发现是某个模块的问题。这种方法一来效率比较低，大量的时间用在了将一个错误定位在模块上了。另外由于这种测试不完全，真正运行系统，当调用某模块时，可能大部分时候都是正常数据，极少出现边界情况，可能某些边界情况容易被忽视，很久之后才被发现。但是如果对每个模块进行单元测试时都进行一下边界测试，就会很容易消除一些隐患。真可谓欲速则不达也。
三.合理的开发流程
合理的开发模式，一句话形容就是“麻雀虽小，五脏俱全”，即使是小型项目的开发，
仍然应该遵循软件开发的一般规律，必须的步骤不能省略。但是小项目有它自身的一些特点，实行起来可以相对灵活些。
以下我从几个方面描述一下我认为比较合理的模式.
1.需求获取
在进入正式开发之前，必须先从用户处获取准确的需求。在这上面花费相当时间是很必要的。
软件项目可以大致分为专用软件和通用软件两大类。
对于专用软件，例如给某单位开发一套该单位专用的系统，一般用户对于软件要完成哪些功能已经有了一个比较清楚的轮廓，而且往往在开发合同中已经大致地规定了。
但是，开发合同上规定的只是一个大概的框架，在进入开发之前必须与用户进行比较具体的交流和讨论，了解清楚用户心目中的产品究竟是什么样子。这个步骤如果没有好好做，往往到了开发工作的后期才发现开发人员的理解和用户的要求有一些误解，那么必然造成时间上的浪费。
对于通用软件，在开发之前应该做一定的市场调查工作，一方面是从经济效益考虑，调查产品的潜在市场有多大，另一方面是从技术的角度，必须了解清楚潜在用户对软件的各种技术上的要求，例如，用户现有硬件配置如何，软件配置如何，使用什么网络，使用什么数据库等等，根据调查的统计结果决定即将开发的软件的一些技术指标。
为了比较好地与用户进行交流，使用一些工具是很有好处的。为了讨论用户界面，可以用VB, delphi等做一个原型，根据原型有针对性地与用户讨论需求。(原型开发不仅仅可以用于准确获取用户的需求，开发出来的原型本身可以作为下一步开发的基础，增量式地完成开发)
为了讨论软件运行的流程，可以采用UML的Use Case图。
2.需求分析
在了解用户的需求之后，将需求用一种模型来表示，就是需求分析，目前比较流行的分析方法是面向对象的方法，通过分析用户需求，用类、类之间的各种关系来表示整个系统。
这部分涉及到具体的方法，在此不详细讨论，但是原则上是提取类->类之间关系,可能需要不断修改而形成一份分析文档。
我想强调几个问题。
一是要分清问题域与系统责任。系统责任是指所要开发的软件应该完成的功能，而问题域是包含所有相关的部分。例如你要开发一个程控机计费程序，程控机已经是现成，输出的数据格式也已经是固定的，你的程序仅仅需要从程控机中读取相应的信息，那么，程控机在你的系统里只是一个外部的东西，把它作为一个类也许就是不必要的，仅仅需要一个类来完成读数据的操作。又如，你需要在一个已经存在的数据库上开发一些应用，数据库的格式已经固定，并且已经有一个后台程序在运行，你需要开发一个新的前台程序，这时，服务器程序对你来说就是一个外部的东西。但是，象这种外部的内容必须在分析文档中有一些说明，作为系统的外在约束。二是需求获取与需求分析的关系。
用什么方法来完成需求的获取，在很大程度上影响了需求分析的做法。
例如当初采用Use Case来表示用户需求，那么从各种序列图中选出相互交互的各个实体，就是一个个类。
三是分析与设计过程的衔接。
分析过程的内容是用类的结构来表示目标系统，并不设计具体实现，如采用什么编程语言，在什么操作系统平台上运行等等。这些具体实现是在设计阶段来完成的。面向对象方法的优点是分析、设计、编码过程表示法统一，能比较好的衔接。但是，是把分析和设计阶段分开，采用瀑布式开发，还是采用其他方式，要看具体的情况。
对于需求潜在变化不大的项目，可以采用瀑布模型，有一个很明显的设计阶段，这样做的好处是有一份比较完整的分析文档，这样以后如果需要采用不同的编程语言、或者采用其他的平台时，便可以以这份分析文档作为开发的基础。
对于需求变化频繁的项目，可能采用少量分析;少量设计少量编码测试的方式更合适，而且随时可能要返回到前面某个一阶段去进行修改。但是这意味着可能没有一份完整的分析文档。
现在很多CASE工具并不区分分析和设计的阶段。但是，这并不意味着开发就可以对分析和设计不加区分，CASE工具如同一支笔，如何用好还得还人。
3.设计过程
设计阶段的工作包括:
对分析模型必要的修改。可能需要对某些类结构进行一些修改，这些修改的原因可能是编程环境的要求，或者为了重用以前的某些工作。
定义界面部分、数据访问(数据库)部分。
由于目前很多编程语言都可以可视化地设计界面，所以界面部分工作往往留到了编码阶段来完成。于是设计阶段的工作量并不大。
4.编码
进入编码工作之后，可能会发现前面分析或设计阶段的某些错误，这时应返回到前面的阶段进行必要的修改。
5.测试
如前所述，即使是小项目，也应该严格地进行测试。
四、人员的安排
比较小的项目，往往是几个人来完成，这几个人基本上从头到尾参加开发。在这几个人中，有一位项目负责人，负责分析、设计和协调的工作。由于项目小，项目负责人也要参加编程,那么这人必须把时间合理运用，
经验告诉我几条原则:
1.协调几个人的工作比自己完成一段编码更重要.
由于协调上出了漏洞，可能导致很大的问题，所以项目负责人必须随时监控各开发人员的工作，包括内容是否与要求发生偏差，进度是否滞后等等。
只有在完成这些工作之后，项目负责人剩下的时间才能用于编程。 2.给每个开发人员明确的任务书.
不管是用面向对象或者其他方法开发，分析、设计模型只是从功能的角度来描述系统。但是，具体开发时每个开发人员必须非常明确自己的任务，这些任务应该采用明确的文档来表示。
3.让大家都大致熟悉设计模型.
让每个开发人员都清楚自己所做的工作在整个系统中处于什么地位，有时侯可能会发现设计模型中的漏洞，避免了各人的代码编写完毕之后又要修改的后果。
以下工程开发指导是我对决定一项使用任何语言的软件工程成功与否的决定因素的一些认识。
1．记住往往事与愿违
纯粹的“轶事工程”（原文为：anecdotal project，其含义不好理解，暂译为"轶事工程"，盼指正--译者）的失败几率总是存在，一些低至百分之五十而另一些高达百分之八十，但是所有的这些都表明：你失败的机会大于你成功的机会。为什么我要从这个令人丧气的预测开始我的话题呢？因为每一天开始时，我都想“今天将会不同，我今天能够完成四倍数量的事情”，尽管（在此之前）有过一系列不间断的例外。对于软件工程来说，过度的狂热往往被那些（只）关心结果人所夸大——“这一次，我们将解决以前从来没有人解决过的问题，只需付出更少的时间和更小的代价”，尽管他们知道，真正的规则是：“你只能从此三者中选择一个”。
记住你身后高高堆积的纸牌[i]非常重要。你手中有一根包含时代力量的魔术手杖或者是挂在悬崖上，会让你做出完全不同的两个决定。如果你懂得你的处境属于后者，你将会说：“是的，这很好。但首先让我们看看我们是否能够在现有的进度和预算情况下完成这一切。”
一个将不稳定形势和对失败的认识放到显著位置的方法是研究过去的失败。一份很好的资料是Roberts Glass（一位爱好研究崩溃的专家）的著作：《软件失控》(Software Runaways,出版信息：Prentice Hall 1998)，以及他其它的著作。此外可以阅读Tom Demarco和Tim Lister的经典之作《人件——生产性工程和团队》(Peopleware: Productive Projects and Team,出版信息：第二版，Dorset House,1999)。
2．切合实际地安排时间
时间安排的“魔法”经常受到非开发人员为满足软件开发实践之外的愿望和期待而产生的想法所驱使。最近我校正了自己的时间安排策略。我先将整个工程显示脑海中，然后闭上眼睛，清理自己的大脑并让它判断这个工程大概需要多少时间。如果不考虑奇怪的技术问题、各种会议和其他分心的事物的影响，得出的这个时间居然非常合理。但我建议将这个合理的时间乘以3，或许可能是4，并且加上百分之十。如果这个估计出来的时间将让你失去市场机遇，那么考虑不要进行这个工程。如果你认为像这样计划时间不合理，那么首先请注意，大多数工程将遵循这个规律。其次，试想一下，如果你所在公司的所有工程都很成功进行会带来局面：你将拥有更多的收入；更少的程序员会因为愚昧的工程时间安排筋疲力尽而退出。
你也许还会争论说这个时间评估技术非常没有科学性，这一点我同意。然而，所有的软件评估技术都含有臆测和直觉的成分在内，甚至连功能点（原文为：function point，若有其他正规译法，请指正）分析都需要对功能点进行猜测。我的“信封背面”技术将所有臆测结合到了一起，而不试图假装没有猜测。用更少的时间，也许产生更好的结果。但是，我的猜测是建立在我自己的经验之上的。
3．首先让它运作起来
当我试图进行一些无意义的事情时，我最大的创造性成功来临了。铭记最重要技巧——当你开始一个工程时，你好比已经用手指将自己挂在一个悬崖之上；然后你考虑一下能够做什么
疯狂的事情简单地让你的工程运作起来。这并不意味着你需要马上投入进去并用通常的方式开始撰写代码，你只需要尽早尽快找到一个转换周期非常短的工具，用来判断你是否可以做该项工作以及你的工程可行性如何。我在后面将要提到的Python语言就是这样一种工具。
将你的计划运作起来有很多好处。凭你的经验，你应该知道，用户只有能够开始使用你开发的东西的时候才能理解你开发的是什么，然后他们会突然产生各种念头并对该软件应该做些什么真正提出要求。一份系统说明书往往只是一份文档，人们往往不会认真地阅读，但是如果你让他们体验一个可运行的程序之后，他们就会确切地明白你的意思。更早地了解用户们真正想要什么岂不是更好？
事情往往会比你想象出来的要复杂四倍以上，所以对你能够完成的东西要尽可能地保守一些。无论何时，一些不可知的因素都在伴随着你的工作（这一点你可以从产品描述中一些“最”中察觉到：“最快”、“最大”、“最新”），原型的价值不能进行夸大。如果在此之前你没有做过类似的工程，那么最重要的事情是尽快地判明该工程是否可以实现，开发一个根本不能发挥作用的程序将会以浪费你的大量金钱而收场。
最后一点，优化。要能够在这个阶段抵抗得了诱惑。牢记Donald Knuth说过的话（其中略有一点开玩笑的意思）：“不成熟的优化是所有麻烦的根源”。虽然优化是一些工程的关键因素，但是在确认程序切实可行之前一切优化都是盲目的。在最后建造系统之前浏览一遍所有的问题。每个工程都有一些你没有接触过的东西，你应该首先将注意力放到这个领域，创建一个测试程序或者原型来寻找解决问题的方法。在你知道你是否可以做到并且知道做到的难度有多大之前，你没有其他办法能够得知工程是否能够成功、如何为它安排时间以及它需要多少付出等等。
4．使用恰当的工具
一个工程的早期部分应该是高度探索性和实验性的，因为那个阶段是发现自己不会做什么以及如何去建造程序的阶段。寻找最适合工具的最好方法是去体验一下他们，然后摈弃其中工作效率低下的那些。例如，你可能开始的时候用的是Rational Rose，后来决定使用Visio Professional来创建视图，因为你需要Visio（或者通过Versa）提供的一些特性。
用来做工程的恰当工具并不一定就必须是你已经了解的编程语言。当使用一种语言时，你就被局限在该语言所能表示的范围之中了。如果你是一个C++程序员，你很自然可能想用C++创建所有的工程管理和工具。但当你需要更加灵活的工具时，Perl是一种更快速的选择（甚至将考虑学习需要的时间在内）。在你的实际工程开发中，使用Python来快速造型或者甚至交付一个内嵌Python语言的应用程序将给你带来更好的局面。首先，它是免费的，所以不需要支付任何许可授权费用；同时它对C 和Java有完全兼容的接口，你可以使用Python 解决所有Perl能够解决的问题，所以它是C++和Java的一种完美的辅助语言。
5．接口的设计
在C++中，接口是一个包含所有虚函数的类；而在Java中接口技术被直接支持；在COM和COBRA中，你没有其他选择，你和所有的抽象打交道——所有的都是接口，没有实现。接口提供了一个更加整洁的设计方式。要想让程序员们确信这一点有些困难，但是它对将COM 或者COBRA指定为构件模型非常有帮助的（COBRA技术也是与操作系统无关的技术）。它不仅仅提供了工程实现语言的灵活性，并让你能够完全地将工程切割开来。如果你打算在你的开发组或者公司之外实现你的工程的一部分，整洁的接口可以阻止任何与工程其它部分不适当的连接，同时你可以用任何语言来进行开发。你可以采取快速造型来实现所有的接口，稍后才对其中比较特别的部分进行优化。
6．设计时充分考虑异常情况
在C++中，异常控制并不像在Java中那样得到有力支持——这是Java在工程管理方面成功之处。在设计、代码编写和模块使用的时候往往会有一些错误，除非软件自身能够通过抛出一个异常来声明这些错误，否则你将会花费许多小时或月的时间来捕获这些问题。只有通过严谨的异常使用，你才能保证这些问题不会出其不意地让你的工程陷入困境。
7．简洁往往付出代价
虽然很难说服管理部门，但是“简洁”这个词是可维护性和复用性的同义词。不仅如此，一个简洁的程序让人感觉很好。但是因为我们确信软件工程是一种商业行为，目的是为了赚钱，而不是为了感觉，因此很难说简洁的程序比其他非简洁的程序更加有灵气地结合在一起。但是由于软件是一种能够赚钱的艺术实体，在美学和实用性之间必然会一场争论。
8．人与人之间的交流是一个瓶颈
这就是为什么小型的组队往往更加有生产力的原因。当一个工程像火焰一样失去控制的时候，将更多的程序员扔进火焰将使情况变得更糟。这也是为什么简短的小会议往往可以发挥作用而冗长的大型会议却做不到，还有为什么太深的管理机制会导致生疏的原因。参阅《人件》（早些时候提及过）一书了解更多的细节。
解决交流问题的最好办法是免费的：在一台废弃的计算机上安装一个Linux服务器，你可以在几分钟内完成这项工作，自动安装将包括一个Apache网页服务器。然后将你们所有的文档，从测试分析到用户文档，拷贝到服务器上，以便每个人都能够访问到最新的信息。你可以轻松地加入Java Servlets或者Perl脚本（https://www.doczj.com/doc/3216271436.html,/）或者Python(https://www.doczj.com/doc/3216271436.html,/)来收集每一页的内容，然后用一个List服务器来向所有的成员发送公告。如果你想用camera-ready格式来提供文档，你可以用Adobe Acrobat格式来代替HTML格式。如果你的工程足够大的话，指定一名成员专门负责维护服务器是值得的。
9．制定一份计划（可以是任何类型的）
我曾经见过许多工程在没有签订任何合同（更别说一份计划）时已经有大量资金流动。哪怕是对于一个很小的工程，你也需要某种计划，甚至它可能只是被写在一个信封的背面或者只存在于主程序员的脑海中。当工程逐渐变大，你需要一个回顾的过程。一个典型的计划包括：分析阶段（包括你打算用程序解决什么问题以及程序将完成什么）、设计阶段（程序如何完成它的任务、程序实现的组成、分析阶段预定目标是否达到的测试使用信息以及发布、安装和培训等事项）。当新的信息被收集时，这些阶段将被重复。根据工程的大小，这些步骤将被缩小或者放大，但你必须像熟悉你的编程语言一样熟悉它们。
10．考虑外部帮助
一种放弃：我的公司提供培训和咨询服务，因此当然我感觉这是一个好主意。然而，如果你的公司内部有经验丰富的人可以担任你的工程的顾问，你可以不必向公司之外寻求帮助。这是一种以知识为基础的商业行为，生产力最低和最高的软件工人之间的生产力差别是很大的。如果你无法雇用那些最有生产力的工人，你可以通过培训提高他们的生产力，通过咨询和代码预排来改进你的工程的分析、设计和实现。对于顾问和客户来说，有一本优秀的书籍是Weinberg的《咨询的秘密》（出版信息：Dorset House,1986）
另一方面，我曾经见过一些工程中，使用外部的开发组队剥夺了内部的队伍的权利，该项目最后以花费更多的时间和资金收场。这将我们带到我的最后一个提示:
11.了解永远没有银弹（原文为：silver bullets,此处直译为银弹，估计引申含义和free lunch 接近）的道理
这句谚语是由Fred Brooks发明的，对于今天仍然适用——尽管有许多“银弹”已经被发明出来了。统一建模语言（UML）就是这样一个例子：它当然是一个很好的通用词汇表和设计符号集，但是UML仅仅轻微地减少了方法学家之间的争论而已。永远不会有不劳而获的事情。你必须艰辛地计划你的对象、它们的接口和结构，然后跨越一道道障碍将工程变成成果。你必须清楚没有任何可以保证成功的方案可以依赖，同时牢记工程的失败的几率让自己更好的瞄准成功。
在最好的情况下，管理软件项目也是很困难的。不幸的是，许多新项目经理实质上没有受到任何就职培训。这里有20个成功的管理经验供项目经理参考。
1. 定义项目成功的标准
在项目的开始，要保证风险承担者对于他们如何判断项目是否成功有统一的认识。经常，满足一个预定义的进度安排是唯一明显的成功因素，但是肯定还有其他的因素存在，比如：增加市场占有率，获得指定的销售量或销售额，取得特定用户满意程度，淘汰一个高维护需求的遗留系统，取得一个特定的事务处理量并保证正确性。
2. 识别项目的驱动、约束和自由程度
每个项目都需要平衡它的功能性，人员，预算，进度和质量目标。我们把以上五个项目方面中的每一个方面，要么定义成一个约束，你必须在这个约束中进行操作，要么定义成与项目成功对应的驱动，或者定义成通向成功的自由程度，你可以在一个规定的范围内调整。相关的详细信息，请参照我的《创建一种软件工程文化》（Creating a Software Engineering Culture）（Dorset House, 1996）中的第二章。
3. 定义产品发布标准
在项目早期，要决定用什么标准来确定产品是否准备好发布了。你可以把发布标准基于：还存在有多少个高优先级的缺陷，性能度量，特定功能完全可操作，或其他方面表明项目已经达到了它的目的。不管你选择了什么标准，都应该是可实现的、可测量的、文档化的，并且与你的客户指的“质量”一致。
4. 沟通承诺
尽管有承诺不可能事件的压力，从不作一个你知道你不能保证的承诺。和客户和管理人员沟通哪些可以实际取得时，要有好的信誉。你的任何以前项目的数据会帮助你作说服的论据，虽然这对于不讲道理的人来说没有任何真正的防御作用。
5. 写一个计划
有些人认为，花时间写计划还不如花时间写代码，但是我不这么认为。困难的部分不是写计划。困难的部分是作这个计划--思考，沟通，权衡，交流，提问并且倾听。你用来分析解决问题需要花费的时间，会减少项目以后会带给你的意外。
6. 把任务分解成英寸大小的小圆石
英寸大小的小圆石是缩小了的里程碑。把大任务分解成多个小任务，帮助你更加精确的估计它们，暴露出在其他情况下你可能没有想到的工作活动，并且保证更加精确、细密的状态跟踪。
7. 为通用的大任务开发计划工作表
如果你的组经常承担某种特定的通用任务，如实现一个新的对象类，你需要为这些任务开发一个活动检查列表和计划工作表。每个检查列表应该包括这个大任务可能需要的所有步骤。这些检查列表和工作表将帮助小组成员确定和评估与他/她必须处理的大任务的每个实例相关的工作量。
8. 计划中，在质量控制活动后应该有修改工作
几乎所有的质量控制活动，如测试和技术评审，都会发现缺陷或其他提高的可能。你的项目进度或工作细分结构，应该把每次质量控制活动后的修改，作为一个单独的任务包括进去。如果你事实上不用作任何的修改，很好，你已经走在了本任务的计划前面。但是不要去指望它。
9. 为过程改进安排时间
你的小组成员已经淹没在他们当前的项目中，但是如果你想把你的组提升到一个更高的软件工程能力水平，你就必须投资一些时间在过程改进上。从你的项目进度中留出一些时间，因为软件项目活动应该包括做能够帮助你下一个项目更加成功的过程改进。不要把你项目成员可以利用的时间100％的投入到项目任务中，然后惊讶于为什么他们在主动提高方面没有任何进展。
10. 管理项目的风险
如果你不去识别和控制风险，那么它们会控制你。在项目计划时花一些时间集体讨论可能的风险因素，评估它们的潜在危害，并且决定你如何减轻或预防它们。要一个软件风险管理的简要的指南，参见我的文章“Know Your Enemy: Software Risk Management”（Oct. 1998）。
11. 根据工作计划而不是日历来作估计
人们通常以日历时间作估计，但是我倾向于估计与任务相关联的工作计划（以人时为单位）的数量，然后把工作计划转换为日历时间的估计。这个转换基于每天我有多少有效的小时花费在项目任务上，我可能碰到的任何打断或突发调整请求，会议，和所有其他会让时间消失的地方。
12. 不要为人员安排超过他们80％的时间
跟踪你的组员每周实际花费在项目指定工作的平均小时数，实在会让人吃惊。与我们被要求做的许多活动相关的任务切换的开销，显著地降低了我们的工作效率。不要只是因为有人在一项特定工作上每周花费10小时，就去假设他或她可以马上做4个这种任务，如果他或她能够处理完3个任务，你就很幸运了。
13. 将培训时间放到计划中
确定你的组员每年在培训上花费多少时间，并把它从组员工作在指定项目任务上的可用时间中减去。你可能在平均值中早已经减去了休假时间、生病时间和其他的时间，对于培训时间也要同样的处理。
14. 记录你的估算和你是如何达到估算的
当你准备估算你的工作时，把它们记录下来，并且记录你是如何完成每个任务的。理解创建估算所用的假设和方法，能够使它们在必要的时候更容易防护和调整，而且它将帮助你改善你的估算过程。
15. 记录估算并且使用估算工具
有很多商业工具可以帮助你估算整个项目。根据它们真实项目经验的巨大数据库，这些工具可以给你一个可能的进度和人员分配安排选择。它们同样能够帮助你避免进入“不可能区域”，即产品大小，小组大小和进度安排组合起来没有已知项目成功的情况。Software Productivity Centre(www.spc.ca)公司的Estimate Pro是可以一试的好工具。
16. 遵守学习曲线
如果你在项目中第一次尝试新的过程，工具或技术，你必须认可付出短期内生产力降低的代价。不要期望在新软件工程方法的第一次尝试中就获得惊人的效益，在进度安排中考虑不可避免的学习曲线。
17. 考虑意外缓冲
事情不会象你项目计划的一样准确的进行，所以你的预算和进度安排应该在主要阶段后面包括一些意外的缓冲，以适应无法预料的事件。不幸的是，你的管理者或客户可能把这些缓冲作为填料，而不是明智的承认事实确实如此。指明一些以前项目不愉快的意外，来说明你的深谋远虑。
18. 记录实际情况与估算情况
如果你不记录花费在每项任务上的实际工作时间，并和你的估算作比较，你将永远不能提高你的估算能力。你的估算将永远是猜测。
19. 只有当任务100%完成时，才认为该任务完成
使用英寸大小的小圆石的一个好处是，你可以区分每个小任务要么完成了，要么没有完成，这比估计一个大任务在某个时候完成了多少百分比要实在的多。不要让人们只入不舍他们任务的完成状态；使用明确的标准来判断一个步骤是否真正的完成了。
20. 公开、公正地跟踪项目状态
创建一个良好的风气，让项目成员对准确地报告项目的状态感到安全。努力让项目在准确的、基于数据的事实基础上运行，而不是从因为害怕报告坏消息而产生的令人误解的乐观主义。使用项目状态信息在必要的时候进行纠正操作，并且在条件允许时进行表扬。
这些提示不能保证你的成功，但是它们将帮助你在你的项目上获得一个坚实的把手，并且保证你做了所有你可以做的事来让项目在这个疯狂的世界上成功。
技术管理就像开车。当你做得正确时，没有人注意，一旦某个环节出错，问题会接踵而来。以下是我11年来作为Interviewing Manager的Team管理体会，排名不分先后，你必须注意每一点。
1. 不要重复过去二三十年来别人犯过的错误
这句话来自Steve Mcconnell，IEEE软件编辑和软件开发畅销书作家。Mcconnell的作品包括经典著作“Code Complete”。Mcconnell认为，“大量阅读”是避免凡重复错误的最好方法。
2. 80%的管理就是选择正确的人选
Scott Adams, Dilbert漫画的作者认为一个好的项目经理必须创造一个人尽其用的环境。所有的项目经理都应该读一读Tom Demarco和Tim Lister的新书“Peopleware：Productive Projects and Teams”（2nd Edition, Dorset House, 1999）。
3. 总是试图雇用比你强的人
不要让你的自负成为项目的瓶颈。组织一支聪明的队伍，给他们足够的资源和解决问题的规则，让员工自己解决问题。
4. 不要浪费时间
Tom Bragg，Intellisys Technology Corp.的首席技术官员，认为太多的项目由于不能如期开始最后陷入麻烦。通常导致延迟的原因包括其它任务的干扰，人事变动，不准时的经理等等。
5. 最优的未必是最大的
Tom Bragg的另一个建议是：密切注意项目开始后发生的事情。Bragg说：“计划好你的工作然后如期进行，过分紧张的工作强度反而往往导致生产率的降低，可能保持每周50小时以内的工作强度是最佳的。
6. 真实的，公正的估计
项目经理应该避免“依照管理者的欲望修改计划”的陷阱。“一个有效的估计的特征是所估计的时间与金钱比实际情况低和高的概率相等”，Bragg说。
7. 使你的组织结构更有效率
很多情况下，你可以采用另外一种与现在不同的组织结构。看一看Apache Web server的开发小组，他们的层次组织并不分明，却开发出了成功的产品。
8. 使用WWW上的免费工具
从https://www.doczj.com/doc/3216271436.html,/winwin/winwin...可以下载由Barry Boehm的学生开发的，能够把W 理论（WinWin模型）和螺旋形模型结合起来的工具。在项目管理研究所的网址https://www.doczj.com/doc/3216271436.html,，你可以下载它的联机手册...套工具：Control Panel和Risk Radar。Control Panel是Excel表格形式，由于监测生产率和质量；Risk Radar是一个Access数据库，对项目的风险进行量化管理。
9. 不要小看老程序员
重新训练现有的程序员比雇用新毕业的大学生要有价值。老的程序员在以往的多个项目上有丰富的经验，通过新技能的训练后，他们的经验和知识会帮助年轻的程序员（包括项目经理）节约时间和金钱。
10. 为你的项目选择定正确的工作流程
并不是所有的项目都适用一种开发流程。Intel公司有规律地检查每个开发小组的工作质量，如果出现了延迟交付或质量问题，Intel鼓励该小组改进他们的工作流程。
11. 做好你的生存计划
对开发过程共享实施猛烈的变革和改变是个什么样子？除了可能的时间大量损失（好，其实这是很小的
可能，除了正在改变开发过程时），当它们获得了人们支持时就都会成功。
在历史上，人民，社会的劳动者，通过联合推动了社会变革。这就是我们所满意的应用程序，MeshTV，用二维和三维的有限元网格以图形的方式可视化和分析数据。它也能处理多种不同的网格类型，提供各种方式查看数据并去除了大多数的硬件和厂商的依赖，同时以自身图形硬件的速度显示图形。MeshTV也可以并行工作，你可以想象得到这需要一些组织级别满足程序的复杂性，保持有序。最后说一点，MeshTV大约有450,000行源代码。
这是我所作的全部描述。如果你想了解得更多，查看https://www.doczj.com/doc/3216271436.html,/bdiv/meshtv，你可以下?..⒃创 牒褪植帷?/a>
受约束的混乱
象许多为内部使用而开发的程序一样，在加利福尼亚Livemore的劳伦斯Livemore国家实验室，对程序必需的修改和增加超出了可用的资源。在MeshTV项目中，这导致了混乱，（on
the MeshTV project, this led to controlled chaos, where developers implemented new features based on the crisis du jour.）（译者注：这句话不好译）没有人有时间坐下来画出应用流程。我们都在实验室的里里外外，忙于我们客户的贪婪的需求。（有约150个文档用户-可能更多，实际上要靠5个兼职的开发人员支持）在我们这种状况下，这种过程导致了我们用户更多的抱怨和可靠性匮乏的程序。
三年前，我们的职责很小（几个用户，几个开发人员，很少有广泛的应用功能）允许我们在CVS上用非常不正规的过程管理源代码。当用户数和他们需求差异增多时，相应的代码管理的复杂性也增加了。处理我们增长的工作量也变得更加困难，我们知道有些事情必须要改变了。我们决定加入到我们部门的其他开发小组中去，并使用Rational软件公司的版本控制系统—ClearCase。从此，我们过程的改进氛围（our process improvement culture）开始改变，变革的种子已经播下了
在我们转向ClearCase前，我们小组的一位经理曾经诱导我们更多的集中在过程上，她徒劳了。她看到了增长的压力和用户的不满，她想我们应该尝试用不同的方法提高我们程序的可靠性和在用户那里的名声。不幸的是，她的话从来没有引起重视，同样我们也认识到了这点，但我们不得不忙于作完我们的工作。开发人员认为最好的情况是软件工程学所论述的那样，而在最糟和最可能的情况下，会占用大量的时间，提供众多的文档，用处不是很大。我们的一些老开发人员认为改进我们的过程没有用并且……（Some of our veteran developers saw no use for "improving our process" and would have sooner appeared in public in a tutu rather than utter such a sissy phrase.）（译者注：这句话太难译了，单词也不认识）而且俱乐部所有人，包括我也怀疑我们要收获的巨大好处。我认为CVS工作得很好，我们真的不需要更多先进的东西。
在CVS工作的同时，ClearCase工作得更好。我认为在每个软件工程生产力上没有真正的提高，但是可以用我以前不能采用的工作方式工作。这些新的工作方法可以使管理源代码变得更容易，同时也减少了我曾经在CVS中遇到的问题。例如，我现在可以轻松的多并发地开发，我可以在我完成后可靠的归并我所作的。新特性弥补了我花在开发和学习新过程上的时间。
真正的产出
过渡不久，一位同事和我与一位来自苹果计算机公司的开发同行进行了一次有趣的讨论。他的工作需要产品开发过程的急迫应用，包括构建方法学和发行版本管理过程。当我们叙述我们通常随意无计划的方式时，他几乎震惊晕倒。后来的讨论，使我们惊奇的了解到了通过改进我们的过程所获得的好处。有一位经理鼓励我们是一方面，但是非同寻常的另一面是听到一位开发同行称赞他发现的好处。这是真正的产出，计算机科学风格的。
我们对其思考的越多，我们越认识到我们需要行动。将新特性和缺少固定发行日期联系起来的狂热，导致了在发行新版本和功能性的匮乏测试间长久的延期。我们的意图是好的，我们想让我们的客户满意。然而，不知何故，我们的期望事实上很糟糕，似乎看起来我们工作得
很辛苦，但是，我们听到了更多的抱怨。我们需要改变现状。
首先，我们转换到有目的的发行版本日期，使其包含明确的更改和新的功能。像许多的内部产品，MeshTV有着明显的直接的用户（MeshTV had users who lived "right down the street."）。新特性的不同的声音淹没在所有的目标回应中，我们尝试经常性的从那些所有从会议厅走下来，停下来聊会儿天的用户那里获取要求。（这些打断也可以避免我们持续工作）荒谬的是在试图获取所有要求中，我们不能满足他们中的大多数，我们失望了。所以我们从这种方法上退回来。或者试图将所有要求放进去（可能匆忙地完成，没有更多明显的bugs）,或者针对最后的抱怨作一个改正（从而没有旧的要求）。我们需要一个载明新发行版本应体现哪些要求的计划。
这表明另一个过程需要改进。在决定之前，我们通过将bugs报告和要改变的要求写到纸上，保证可追踪。这片纸经常“走向了所有事物的归途”，或者偶然的扔进了废纸篓，或者压在了其他所有的纸张下面。（这点上我坚信我已危险地靠近制造我自己桌面中子星）（译者注：黑洞乎）那些纸随着时间的流逝而不能理解，无心的造成了客户输入损失的结果。
我们需要很好的保持我们改变要求的追踪，这样我们就可以为下一个发行版本选择明确的要求。在对几个产品调研后，我们购买了Pure Atria的ClearDDTS，帮助我们管理我们的改变要求，我们试图一年四次发布新版本应用程序，这作为一策略被我们采纳，这样我们就可以很快的清晰地增加新功能，不用更新得过于频繁导致没有时间测试我们的修改。为了达到结束点，我们努力选择一定量的能够在三个月内完成的工作。第一次时，因为我们没有人知道如何预测一个详细的修改需要多长时间，我们彻底失败了。幸运的是，我们可以通过ClearDDTS跟踪我们曾经预测的时间和工作中实际花费的时间，并且个别开发人员利用这些数据预测将来。在为其他版本的选择工作中，这获得了重大的成功。变革明显的站住了脚。
我们也决定与目标发行版本并进，着手提高质量的工作。为了完成这点，我们要求所有决意要改变的要求要被不具有开发责任的其他人所验证。当我们知道其他人会检查工作时，我们就都会非常仔细，这多么惊奇。我们也开始采用Mercury Interactive’s Xrunner和内部使用的脚本开发了一个自动测试系统。将来，在我们发布一个新版本应用程序前，这些测试必须成功的测试过。
持续的改进
所有这些工作都以我们不能想象的方式的到回报了。我们更好地跟踪我们的改变要求，也就是我们没有丢掉它们，我们确实能跟得上用户的更新状态了。用户喜欢这点，我们也不再面对来自客户的挫折。他们也喜欢我们更频繁的更新和更加健壮的程序。
我们正在寻找另外的方式，我们可以从改变我们过程中获得好处的方式。现在，我们正在研究软件开发成熟度模型（CMM）,看是否能通过遵从2级帮助我们提供更好的应用软件（请到https://www.doczj.com/doc/3216271436.html,/查看更多的CM...在于核对boxes。
我们正在进行的另一个改变是，我们能够更容易地在我们每年四个主版本之间发布修订bugs 的版本。这点可以是我们更快的转向用户的要求，平息用户的愤怒。（我们基于用户认识到的严重性和我们察觉的严重性的比较，选择哪些bugs被改正，还包括工作区存在的风格。我们在整体上也为客户整合了全部优先级的感觉）
我们过程改革的更多惊人结果之一是不只影响了程序，更多地影响了程序开发人员。他们停止了改善用户的态度，转向提高应用程序。程序变得更可靠，发行版本变得更可预测的同时，用户对应用软件整体上也更加满意。
但是我们不仅只关心我们的过程的改革。MeshTV的开发人员同其他的开发小组并同工作着，我们试着同其他的小组分享我们的经验，学习我们的胜利和错误。围绕我们新的过程，我们提供了四个展示，至少有一个小组已经决定采用我们的一些经验。变革在成长。
成功孕育成功
当管理层尝试推动改变过程时，从最初的怀疑和愤怒，我们在这个过程中经历了巨大的变革。这些曾经著名的过程都是那些所有刊物都讨论过，当作福音传授给我们的同事。当我回头看看我们的小组，我惊奇于我们从使用一个版本控制系统改变到几个可重用性、文档化过程，甚至将那些经验出售给别人。什么能够允许我们背离我们正规的商业方式
对于我们来说，在开展新的过程中最重要的因素是一个成功的战士，他酝酿了过程改革中的兴趣。这个战士应该是一个受到尊敬的开发人员，在小组里的，因持续工作而闻名，因渴望经验的增长而受人尊重。在我们的事中，我们有二位战士，我的同事Sean Ahern和我自己。在我们兴奋于可能的好处并开始着手于一些改革后，小组的其他人信服了并跟随我们。当管理层决定了过程必须跟随时，来自小组外的压力出现了。对于外来的，组员将可能排斥它，对此我不能强调得足够多。然而，来自里受人尊敬的组成员的狂热，开发人员感到是必须听从。毕竟，这些人们事实上知道到底它象个什么样子。一旦其他团队里的人看到了真正的好处，他们就会跳进这个潮流中，变革也就会良好的进行下去。当开发人员开始思考改进过程的方式，获取真正的好处时，好戏就开始了
你如何开始你的变革？每次一个改变。一旦明显有好处，你的同事就会加入到你的行列中，同你一起征服编程世界。
简介
可用性测试为您带来的好处
简言之，如果将可用性测试从产品开发周期的一开始一直贯彻到项目的每一阶段中，将使您在最后的处理过程中省去重新开发这一环节。
本文首先讨论重复、周期性的设计过程。第一部分阐述了以用户为中心进行设计时的四个原则，这是由Gould、Boies 和Lewis 提出的。接下来介绍了两种类型的产品设计过程：“瀑布式”方法和“螺旋式”方法。本文的其余部分将简要介绍产品开发的各个阶段，并讨论可用性活动是如何渗透各个阶段并带来益处的。此处所述的开发阶段包括：构思、规划、开发、稳定化以及为下一版本做准备。
在您阅读各小节时，请注意用户将频繁地参与到各个过程中。用户对每个阶段的介入将会在项目的收尾阶段为您省去成本高昂的返工工作，而且这样开发出来的产品将使用户乐于使用、易于学习，并会长期使用。
使用反复、周期性的设计过程
反复、周期性的设计过程为以用户为中心进行的设计带来了极大的便利。以用户为中心的设计有四个重要原则，这些原则是由Gould、Boies 和Lewis 于1991 年提出的：
?及早以用户为中心：设计人员应当在设计过程的早期就致力于了解用户的需要。
?综合设计：设计的所有方面应当齐头并进发展，而不是顺次发展。使产品的内部设计与用户界面的需要始终保持一致。
?及早并持续性地进行测试：当前对软件测试的唯一可行的方法是根据经验总结出的方法，即若实际用户认为设计是可行的，它就是可行的。通过在开发的全过程引入可用性测试，可以使用户有机会在产品推出之前就设计提供反馈意见。
?反复式设计：大问题往往会掩盖小问题的存在。设计人员和开发人员应当在整个测试过程中反复对设计进行修改。
多年来，“瀑布式”的产品设计过程是软件设计的标准。在这一方法中，项目开发通过分阶段发展的、按顺序的各个阶段进行。这种方法使用重大事件作为转变点和评估点，并认为在下一阶段开始前，前面的每一阶段均已结束。“瀑布式”的方法对于复杂的项目很有效。在复杂的项目中，多个供应商负责项目的各个方面（例如，一个供应商负责需求分析，另一个负责规范，等等）。但是，使用这种方法可能导致随着项目的进展，对项目进行更改越来越难。
相形之下，“螺旋式”的产品设计过程却是反复、周期性的(Software Engineering Economics, Barry W. Boehm, 1981)。这一过程允许更大地发挥创造性，并且更易于随着项目的进展而对项目进行修改。在进行螺旋式的设计过程时，您会发现可在各个阶段对产品各方面的功能进行设计。这种方法可为以用户为中心的产品开发过程带来便利。
螺旋式的产品设计过程有六个阶段：构思、规划、建模、开发、稳定化以及为下一版本做准备。
构思阶段
产品开发的构思阶段是确定项目的目标和范围的阶段。此阶段要确立构思陈述、设计目标、风险评估以及项目构架。
在构思阶段，通常进行下列可用性活动：
环境研究
基于Beyer 和Hotzblatt 于1997 年出版的Contextual Design 一书中所述的方法，此类型的研究包括观察用户的所做所为，使您更为直观地了解用户行为。如果您尚未决定究竟要开发何种软件，但认为存在市场机会，就可使用环境研究来对活动进行研究。您可了解可为用户做些什么以及实现的难易程度。不是寻求具体的功能，而是寻求设计机会。
环境研究为项目提供工作的重心。如果项目是全新的项目，或是较全面的升级，这种方法最为适用。在进行较全面的升级或开展全新项目时，您无法全面了解用户在做什么、如何做、以及他们所面临的问题或困扰。而进行较小的升级时，您有可能从产品支持部门、先前的研究等处获得这些信息。在这种情况下，您基本上是对现有的设计加以完善，所以环境研究并不是不可或缺的。
环境研究在以下情况最为适合：项目组进行跨学科的环境研究，小组由可用性工程师带领。竞争性测试
通过竞争性可用性测试，您可以为产品设置量化的可用性目标—任务完成的速度、每项任务出错的数目，等等。这种方法可对项目的成功与否进行量化的度量，即使所进行的竞争只是人工过程，而您将对此过程进行自动化。竞争性测试经常用于市场开发。当市场开发代表对竞争对手进行评估时，他们只比较产品的功能。可用性测试则更侧重于使用这些功能完成任务时的性能。
竞争性测试对仅用于公司内部的产品来说，似乎不大适用。但是，如果仔细考虑，从理论上而言，您也是在与产品的先前版本或前一个流程竞争。内部产品可能与人工过程进行竞争—产品必须比现有的进程更有效、更好。
进行竞争性测试的方法之一是开展研究，比较与其相竞争的产品的性能。例如，对其他人员的产品进行性能研究。在选择要测试的竞争产品时，要考虑到计算机之外的产品：如果产品涉及在线交易，则竞争性产品就可以是电子货币。从研究结果中您可以确定使用最频繁的、最重要的功能。
用户/受众分析
了解您的用户！尽可能采取各种方法来了解您的用户的特点。考虑一下如果您基于产品最终用户的特点来开发软件，可减少多少技术支持电话的数量。设想一下用户是否认为产品易于使用并且包含了他们所需的功能。问自己“对于我要创建的产品，哪些用户特点是与之相关的？”，例如：
?计算机使用经验
?年龄
?接受培训的程度
?用户群之间的社会关系
?特殊要求（可访问性）
您可以通过环境研究来获得一些此类信息。例如，您可对一些用户进行观察以得出一些假设，然后通过调研或取样来验证这些假设。您的人力资源部门或培训部门可能会具有一些相关的信息；例如每个新雇员要接受多少培训。市场研究人员也可能有此类信息。对于公司内部使用的应用程序而言，收集这些信息有时会比对外出售的应用程序简便，因为您的用户是具体的群体而不是普通大众。
规划阶段
规划阶段是进行首次实际设计的阶段。在此阶段中，有关用户界面的早期设想将初步成形，并着重于先前阶段未涉及的知识。原始模型可以是任何形式，如描述概念或功能的卡片、屏幕的简单描绘图纸、打印在纸上的屏幕位图图形，用Macromedia Director 之类的程序创建的带有有限交互功能（也称为“点阅”）的联机版本，或是用HTML 或Microsoft Visual Basic? 创建的带有大量交互功能的联机版本。在大多数情况下，您会发现原型具有的仿真度越高，用户建议进行重大修改的可能性就越低。所以，用写在纸上的原型来开始着手测试是非常值得采取的做法。
根据您所设计的产品种类，您可能需要进行下述的一些或所有活动。如果您在规划阶段花时
间来完成这些任务并使用原型，则在开发阶段碰到的可用性问题将会大为减少。
用户情况
创建您自己的用户情况概要，列出产品的典型用户能做什么，不能做什么。通过早期的环境研究和用户/受众分析，您做出一些较高级别的决策，基于这些决策进行软件设计。使用用户情节，您可创建一个有关用户使用您所设计的软件的“故事”。这些情况可以是情节串联图板、联机Macromedia Director 电影、简单的流程图、或简单的叙述性文本。一种比较精致的用户情节模式是“日常生活”录像。这种录像把演员作为“用户”显示，这些用户在日常活动中与模拟的系统进行交互。通过用户情节可得出您在任务分析时要寻找的具体细节。任务分析
任务分析决定了在新产品中执行任务的方式。在撰写规范之前，必须首先进行任务分析。用任务分析来确定您所规划的支持的任务是否确实能够反映现实，这一点是很重要的。对任务的逼真度进行分析。就产品的特性而言，任务的完整性如何？分析逼真度意味着观察用户完成一项任务所必须执行的所有操作；或进行表象的观察，了解用户完成所有任务或功能所需执行的所有操作。无需担心过于详尽—把重点放在实质内容上。
一些要考虑的问题和活动：
?此环境中的任务是什么？环境研究应能帮助您找出并描述用户所执行的任务。
?创建顺序图，描述用户执行的任务之间、用户和产品之间的相互作用。
?在构思阶段确定功能的作用领域。提出问题：“我们要支持的具体任务是什么？”
?与产品设计者一起创建情节串联图板或顺序简图。
启发式评估
启发式评估涉及评估人员小组，这些评估人员查看界面并基于基本可用性原则来对其做出判断。启发式评估允许您在整个反复式设计过程中查找并更正可用性问题。如果您在工作进展的同时纠正问题，您将在收尾阶段节省大量工作。因为在收尾阶段，更改真实代码将更加困难而且成本更高。
如Jakob Nielsen 在Usability Engineering (1994) 中所述，启发式评估包括以下步骤：
1. 每个评估人员都浏览数遍界面，检查各种对话框元素，然后将其与一些已知的可用性原则相比较。
2. 评估人员相互合作，将结果合并到列表中，列出用户界面中的可用性问题，并注明设计方案中违反的相关可用性原则。
3. 一旦每个评估人员都分别执行了启发式评估后，他们就集中起来将其评估结果合并在一起。
在开发的早期阶段，启发式评估可能是发现可用性问题的非常有效的方法。
认知性遍历
认知性遍历的意思是，仔细检查界面要求用户执行多少步骤以及何种步骤后，才能完成某项任务，其中包含用户必须经过思考才能完成的那些步骤。您需要关注的是用户必须调用什么或用户必须进行的计算—认知性任务决定学习和使用您的产品的难易程度。认知性遍历可帮助您找出潜在的可用性问题，以及找出您制订的规范中的破绽！
根据Gregory Abowd 的Performing a Cognitive Walkthrough，要进行认知性遍历活动，需要以下四个条件：
1. 对系统原型的详尽描述，例如初级规范可提供什么样的系统。这种描述不一定是完整的，但要相当详尽。诸如菜单的位置或措辞这样的细节也可能导致相当大的差异。
2. 对用户在系统中要完成的任务的描述。该任务应当是大多数用户将要执行的有代表性的任务。
3. 一个完整的、书面的操作清单，列出使用给定原型完成任务所需执行的操作。
4. 指出用户的身份，以及评估人员能够假定这些用户已具有哪一类别的知识和经验。
有了这些信息，评估人员可执行一遍上文第三项所列的操作，从而确定用户是否能够按预期要求合理执行这些步骤。
GOMS
GOMS 是描述任务和用户执行该任务所需知识的方法，它是通过目标(Goal)、操作符(Operator)、方法(Method) 以及选择规则(Selection rule) 四个方面进行描述的。
Card、Moran 和Newell 提出了原始的GOMS 模式。他们还创建了一个简化的版本，即击键级别模型(KLM)。Bonnie E. John 开发了并行活动版本CPM-GOMS，而David Kieras 则开发出定义更为严谨的版本：自然GOMS 语言(NGOMSL)。所有这些技术都基于同一GOMS 概念。
?不言自明，目标就是指用户的目标。用户使用软件要达到什么目的？在下一天、下几分钟、下几秒钟？
?操作符是指软件允许用户采取的操作。
?方法是子目标和操作符经仔细设计后得出的序列，可用来实现诸如剪切和粘贴等目标。?选择规则是用户要遵守的判定规则，以确定在特定环境下要使用的方法。
GOMS 模型由对方法的描述组成，这些方法是达到目标所必需的。方法是一些步骤，这些步骤包括用户为达到目标所需执行的操作符。如果有一种以上的方法可以达到目标，则需使用选择规则来确定在此情况下哪种方法更为适用。
卡片排序
卡片排序是一种可用性技术，用于此阶段的早期，以了解用户关于信息的总体模型。卡片排序的基本任务是要让参与者按卡片上的说明对卡片进行组织，将属于同一类的项目堆放在一起。在创建好堆后，参与者还可为所创建的堆建立名称、标签或说明。
卡片排序用于：
?展示用户对于任务范围的总体模型。
?展示用户如何对项目进行分组或分类的。
?展示用户对项目之间的关系和相似性的看法。
?将用户的概念模型转换为设计。
反复可用性测试
对原型设计的反复可用性测试是另一种很有价值的方法，用于在产品周期的早期阶段确定界面是否易于用户使用。在此阶段进行更改比等到开发阶段开始后再进行更改要更容易些，并且成本更低。
您从可用性实验室可以收集的数据量取决于原型的强健性。对于纸上原型测试，可用性工程师就是计算机，并且在测试的过程中与用户在一起。
在许多种情况下，严谨的可用性测试是过犹不及的。在建模阶段，您仍可使用简化的方法进行有效的可用性测试，这些方法通常称为“打折扣的”可用性测试。
如Jakob Nielsen 所述，反复的可用性测试包括：
1. 用户和任务观察—观察用户，保持安静，让用户做一切通常情况下会做的操作。
2. 情况—使用一种可以减少功能数量、降低功能级别的建模方法。
3. 简化的对谈式测试—一次安排一个用户完成一组任务，并要求用户“发现问题就直接告知测试人员”。
4. 启发式评估—基于基本可用性原则来评价界面。
开发阶段
开发阶段是将产品用实际的代码来实现的阶段。在此阶段中，您可以对实际产品的早期版次
工程项目管理案例分析 澳大利亚悉尼港海底隧道工程 澳大利亚悉尼港海底隧道工程是典型的BOT项目融资模式，首先理解BOT融资模式的意义：BOT项目融资(即Build—Operate—Transfer建设～经营～移交)是项目融资的诸多方式中的一种，在我国又被称作”特许权投融资方式。一般有东道国政府或地方政府通过特许权协议，将项目授予项目发起人为此专设的项目公司(Project company)，由项目公司负责基础设施(或基础产业)项目的投融资、建造、经营和维护；在规定的特许期内，项目公司拥有投资建造设施的所有权(但不是完整意义上的所有权)，允许向设施的使用者收取适当的费用，并以此回收项目投融资、建造、经营和维护的成本费用，偿还贷款；特许期满后，项目公司将设施无偿移交给东道国政府。 悉尼港海底隧道工程的项目背景 针对悉尼港湾大桥车流量逐年增多并己超过大桥设计能力的现状，澳大利亚新南维尔州政府在1979年就向社会公开发出邀请，就解决悉尼港湾的交通问题请私人企业提出建议，最初提出的建议(主要是修建悉尼港湾第二大桥)由于种种原因均未被政府所接受。1986年，澳大利亚最大的私人建设公司Gransfield和日本的大型建设公司之一Kumagai Gumi Co Ltd(熊谷组)联合向州政府提出了建设海底隧道作为悉尼港湾第二通道的建议。州政府在经全面研究后，认为这个建议是可以接受的，于是摇权这两个公司用自有资金对该项目的筹
资方式，建设和经营隧道进行全面的可行性研究。主要包括：技术可行性研究，环境影响研究，资金筹措方案。其中就资金筹措方面聘请了澳大利亚WESTPAL银行为财务咨询单位，对筹资方式进行了咨询并提出了初步方案。 该项目的可行性研究报告历时18个月投入400万澳元并在1987年被州政府批准，这两家私人公司为保证该项目的实施正式成立悉尼港隧道有限公司与州政府签订了特许权合同。该项目在经济上是可行的，最终要达到以下目标：政府的财政预算内不承担提供资金的义务，隧道收费要保持在最低水平上，政府承受的风险限制在最低限度上，政府能影响项目的设计、建设和经营，以保证项目的财政能力；长期性的解决悉尼港大桥的的交通问题，政府仅承担项目实际收入与设计收入之间的差额风险，保证项目有足够的收入归还贷款。 资金筹措方面 该项目总投资7.56亿澳元。最后确认的资金安排方案是：政府无息贷款2.23亿澳元（占29%）；这部分资金来源于隧道建设期间悉尼大桥的纯收入，澳大利亚最大的私人建筑公司GRANSFIELD与日本的大型建设公司熊谷组的共同项目贷款为4000万澳币元（各2000万，共占5%）和共同项目资本金分700万澳币元（各350万，共占1%）、；西太平洋银行和德意志银行认购债券2.66亿澳元（占35%）；Cheunug Kong Infrastructure 出资1.1亿（占15%）；DB Capital Partners 出资6600万（占9%）；Bilfinger Beeger 出资4400万
IT项目管理的现状 10125230 虞灵婷 摘要：本文主要介绍了我国IT项目管理现在的发展状况、以及在IT项目管理中存在的问题。并且对其发展前景以及应对对策提出了一些建议。希望能帮我我国的IT项目管理行业更好的发展。 关键词：IT项目、现状、问题、发展前景 1.前言 随着我国IT行业的日益发展和不断进步，各个IT企业已经开始陆续引进并开始实施了“项目经理制”的管理模式。从现代管理学角度来看，项目管理的宗旨是在运作方式和管理思维模式上最大限度地利用内外资源，从根本上改善管理人员的工作程序，提高工作效率。企业要想在高度竞争与快速变化的环境下把握商机、提高营运效率以及合理地进行资源配置，项目管理的重要性是不言而喻的。而对于中国的IT企业来说，研发项目的管理可以说是项目管理中最核心的组成部分。下面就我国IT 行业现在的特点和影响IT项目管理的因素及实施中的对策问题进行初步探讨。 2.我国IT项目管理的现状 2.1我国IT行业项目管理发展状况 过去由于我国对项目管理不够重视,造成大量时间、人力等方面的浪费, 严重制约了我国现代化的进程,IT 行业尤其如此。伴随着信息时代的到来,我国IT 行业得到了飞速的发展。虽然项目投资已经位居全国各个行业的前几名。但是IT 行业项目管理水平较低,即懂得IT 专业技术又具备专业项目管理人才缺乏,据了解,我国IT行业真正实现或者基本实现项目目标的投资项目所占比例很小, 彻底失败的占到了很大比例。其主要原因之一就是没有做好项目管理工作。即没有做好启动、计划、执行、控制、收尾五个项目管理过程,没有做好IT 行业九大集成
管理、工作范围管理、时间管理、费用管理、质量管理、人力资源管理、沟通管理、风险管理和采购管理系统管理的管理协调工作。但是随着我国经济的高速发展和信息化的不断提高,我国对于专门从事IT 行业项目管理的人才需求量日益增长,因此IT 行业项目管理人才市场需求日益广阔。国家目前也越来越重视IT 行业项目管理工作,正在起草建立相关的法律制度。我国IT行业项目管理工作已经或者正面临着前所未有的良好发展机遇。 2.2我国IT项目管理中存在的问题 1、项目经理与项目严重脱节，导致项目实施严重失控。当前，在进行项目组组建过程中，出于多种考虑，项目经理的头衔很多时候是落在了企业的老总，或是各事业部的总经理的头上。这些老总们多数时间是在忙于其他事务，而无暇或者不能全部时间关注项目的实施和进展工作，无法真正行使项目经理的权利。并且，其他的项目组成员没有足够的权力去管理和协调项目工作。这样就导致了项目的失控，项目进展中遇到的问题无法被及时暴露和解决，最终致使项目失败。 2、项目组无法统一目标和方针，导致项目组工作效率低下。由于多数项目的实施，要涉及的多个部门的协同配合，即项目组成员会由各个不同的部门同事组成。而项目经理没有足够的权力协调其他部门的组员的工作，而且，由于项目组是临时机构，这导致了项目组成员对项目组的无视，他们往往更加乐于按照部门负责人的安排工作，而不是项目经理。甚者会出现在项目实施期间，某部门突然将项目组中的人员抽调走，而导致项目停工或工期延误等后果。 3、授权模糊或没有授权，致使项目经理对其工作职权概念模糊。为了达到某种目的而创立了团队。企业可能会向项目经理"授权"。但是通常是很模糊的，即项目经理为达到既定目的可以在某种程度上采取一切必要的行动。但也可能企业没有这样授权。对此项目经理要么感觉手中无权，无法开展工作；要么就搞不清自己职权到底是什么。不管怎样，这样的团队往往是要失败的。 3.IT项目管理的研究及发展前景 通过对国内外项口管理研究现状的调查分析，我认为以下2个领域还存在广阔的研究前景：
一个项目经理的困难选择 张炎正在打电话的时候，他的秘书拿进来一封总部抄送的来自德勤公司的信。张炎是益达公司的项目经理，这两年一直在负责公司在海外的项目开发业务。而此刻这封信正是关于张炎所负责的一个香港的项目。 由于益达是在NASDAQ上市的公司，每个季度的财务报表要经过德勤公司的严格审计。益达核算项目收入的方式是采用完工百分比法，即随着项目的时间进度，按比例将合同款记入公司收入。这个项目2003年9月合同签订之日起，到2004年11月，历时1年多，合同款的80%也已经记入公司收入，而客户实际上的现金支付只有合同款的30%。2004年12月德勤在对公司的审计中发现了这一问 题，于是便寄来这封信，要求公司给予说明。财务部给出的建议是：请德勤向客户公司发欠款确认书，以此证明益达没有虚假账面收入。但是客户公司会签署这份确认书吗？张炎实在是没有把握。 益达公司和AHZ软件 益达公司成立于1992年，伴随着中国电信和因特网事业一路成长发展。其中AHZ软件是益达的核心产品，在国内为中国电信、中国移动等多家大型运营商提供对用户的管理和计费功能。 2003年香港凯业公司对益达的AHZ计费系统表示了兴趣，而益达的董事会也把这次合作看作步入海外市场的重要机遇。凯业成立于1994年，是香港首批获得允许为公众提供互联网服务的电信服务提供商之一，其主要投资方来自于日本。2003年9月，益达公司和凯业公司签署了用户管理和计费软件开发合同，合同金额为695,000美元。在这次项目中，益达将以AHZ产品为基础，结合凯业的业务需要，进行客户化和二次开发工作。对益达来说，这是公司第一个海外项目，标志益达业务步入了国际市场，这一消息使益达在NASDAQ的股票价格因
背景： 某钢厂改造其烧结车间，由于工期紧，刚确定施工单位的第二天，施工单位还未来得及任命项目经理和组建项目经理部，业主就要求施工单位提供项目管理规划，施工单位在不情愿的情况下提供了一份针对该项目的施工组织设计，其容深度满足管理规划要求，但业主不接受，一定还要求施工单位提供项目管理规划。 问题： ①项目经理未任命和项目经理部还未建立，就正式发表了施工组织设计，其程序是否正确？ ②业主一定要求施工单位提供项目管理规划，其要否一定正确？ ③项目管理规划是指导项目管理工作的纲领性文件。请简述施工项目管理规划的规划目标及涵。 ④试说明施工项目管理规划的控制原则。 答：①程序不正确，公司还未任命项目经理，项目经理部还未建立，施工组织设计无人审核和批准，不能发表。 ②施工组织设计可以代替施工项目管理规划，但施工组织设计的容深度应能满足施工项目管理规划的要求；冶金建设工程中，实际上一直使用施工组织设计代替项目管理规划；施工单位可以向业主说明提供的施工组织设计的容深度已达到项目管理规划的深度要求，不必再编制项目管理规划。 ③施工项目管理规划的规划目标及涵有： ａ.规划目标包括项目的管理目标、质量目标、工期目标、成本目标、安全目标、文明施工及环境保护目标、条件分析及其他容等； ｂ.涵包括施工部署、技术组织措施、施工进度计划、施工准备工作计划和资源供应计划和其他文件等。 ④项目管理规划的控制原则为：实现最优化控制；动态控制；主动控制；全过程控制；全要素控制；建立大控制系统的观念；要对规划的实施明确项目经理部各岗位职责、对执行进行检查分析和改进，进一步进行总结。 2、背景： 华北某厂１２６０ｍ３级高炉扩容改造工程。根据招标文件要求，为了实现快速、高效、优质、低耗地完成扩容改建任务，该扩容改造，应采用高炉整体平移新技术。高炉分两段安装：第一段为移送；第二段为悬吊，高炉本体工程拟定在拼装平台上基本完成，尽量缩短停炉后施工工期，保证业主要求的工期。高炉本体平移作业采用滚动摩擦方式液压缸推送。要求“新、旧高炉中心线重合，标高与原设计标高相符，误差控制在５～８ｍ”。高炉本体移送重量约４５００ｔ。推移高度约为３６ｍ，推移距离约４２ｍ。高炉本体在液压缸推动下，分步向炉基平移。 问题： ①结合本案例谈谈项目目标的制定。 ②结合本案例谈谈项目管理的总体安排。 答：①项目的目标包括质量、安全、进度、成本等目标，施工组织设计、项目质量计划由项目经理部编制，并按 规定程序报批和实施。如质量目标：工程质量一次验收合格率１００％，单位工程优良率８５％以上，质量达到冶金建设工程优良标准。无重大质量事故，质量管理体系持续有效运行。竭尽全力做好工程服务和投产顺产保驾工作，确保用户满意。 安全目标：工亡事故为零；重伤事故为零；重大机械设备事故为零；重大交通事故为零。 现场目标：在争创优质工程的同时，强化现场文明施工的管理，树立公司良好的形象，建设文明、规的施工现场。 ②项目管理实施项目经理责任制，项目经理对项目实施全方位的管理，负责项目施工全过程的质量、工期、安全、文明施工、确保履行合同，负责组织编制施工组织设计、项目质量计划、相应的项目管理文件。项目经理是工程项目质量、安全的第一责任人。 结合本案例项目管理的总体安排：强化项目管理，全面响应业主技术要求，严格科学管理、精心组织施工，优质、安全、高速建设高炉扩容改造工程。针对本工程的特点，结合类似工程的经验，我们对本工程的总体思路是：项目管理，科学组织；突出重点，齐头并进；有序安排，提高效率；阶段实施，步步为营；统一调度，道路畅通；质量贯标，安全可靠；发挥优势，缩短工期。
项目管理案例：项目经理应该为这些问题负责吗？（一）案例正文 陈伟明是公司的项目经理，在项目A筹备阶段就作为项目经理助理参与该项目，项目正式实施后被公司任命为项目经理。但使陈感到恼火的是：其他职能部门的经理虽然为该项目安排了时间和人手，但他们更热衷于其他项目。同时陈还被告之不要干涉部门经理对资源的调度和费用的预算。 半年之后，陈借向公司管理层汇报项目进度的机会向管理层说明了由于职能经理不合作而造成的项目严重拖期情况，这次汇报引起了公司管理层的注意，他们投入了更多的资源来使项目回到正常轨道上来，陈伟明不得不花费很多时间来准备文案、报告和投影以及各种各样的会议。 公司管理层还为陈指定了一个项目经理助理，该助理认为应该通过计算机程序把各种问题程序化，于是公司又投入了12个人来开发这个程序，在花费了巨额资金之后，陈发现这个程序并不能实现其目标，他向一个软件供应商进行了咨询，得知若要完成该程序，还需要多花费数倍的资金和两个月的时间，无奈之下，陈只好放弃了该程序。 这个时候项目的情况已经很困难了，项目滞后了9个月，但还没有成型的单元完成，客户对项目拖期问题非常关注，陈不得不花大量时间向客户解释存在的问题和补救计划。 三个月之后，项目仍然没有大的进展，客户开始不耐烦了，尽管陈进行了大量的解释和说明，但客户仍然不能接受严重拖期，于是指派了一个代表到项目现场监督工作。客户代表要求找出问题并持续更新，继而试图参与进来解决问题，陈和客户代表在一些问题上产生了激烈的冲突，导致两人关系恶化。 公司管理层最后撤换了陈伟明，项目A在超期一年之后，以预计费用的140%最终完成。陈伟明在项目A中遇到了很多项目经理都曾经遇到的困难，请你谈谈为什么他被撤换下来，他应该为这些问题负责吗？ （二）案例分析 ●从案例中可以分析得出，身为项目经理，陈需要为这些问题负责。造成这些问题的主要原因有以下两个： 1、沟通方面的问题 2、项目计划的制定、监控及修正的问题 以下对两个主要原因进行分析： 1、沟通方面的问题 1）没能与职能部门进行很好的沟通，协调资源； 从这个案例可以看出，该公司的整个运营链不流畅，有十分严重的部门墙存在。而陈作为项目经理，和各职能部门的协调沟通不够，造成公司资源(人力和资金等)的严重浪费。 案例片段： “其他职能部门的经理虽然为该项目安排了时间和人手，但他们更热衷于其他项目。同时陈还被告之不要干涉部门经理对资源的调度和费用的预算。” 分析： 项目经理陈由于没能与职能部门的经理进行很好的沟通而导致人力资源的
案例：IT项目管理分析 摘要：成功项目和失败项目的最大不同在于项目管理。曾经有这样一个项目，对于客户，是新开展的业务；对于集成商，大部分技术是未曾使用过的。通常说来，这样的项目存在极大的风险，那么，请看看其中的项目管理…… 1 项目描述 某年，B计算机公司（以下简称B公司）了解到A企业要建设一个客户服务中心，向客户提供有关本企业产品的咨询、查询、委托、投诉等服务，并希望能够尽可能采用各种计算机和通信技术，为客户提供快速、准确和渠道多样（包括电话、传真、WEB、邮件等）的服务。 1.1 背景 客户服务中心在国内至多属于萌芽状态。 A企业的原有业务运作只有一小部分采用计算机处理，而且原来并不存在客户服务中心这样的机构。 B公司擅长的领域是典型的基于UNIX与TCP/IP的交易处理系统，对于建立客户服务中心所需要的CTI知识知之甚少，WEB开发也从来没有尝试过。 总而言之，这是个新领域，在机会存在的同时，风险也非常大。 1.2 结果 B公司在项目中采用多种从未使用过的技术和产品：Browser/Web Server/Database Server 结构、CTI技术、排队机，并独立开发语音传真服务器，最后按时完成项目。该项目的完成为后续合作奠定基础，在第二年很快就签署二期合同。 无论是客户还是公司，都对项目的结果表示满意；项目成员也对能参与这个项目表示高兴。 2 项目过程 那么，B公司是如何成功完成这个充满风险的项目呢？项目完成后，公司及客户都认为，因为有一个合格的项目经理。接下来，我们就看看在项目实施过程中项目经理做了哪些事？ 2.1 起始阶段 在项目意向明晰后，项目经理首先做的事情是：查阅资料，确定助手，制定下一步计划。
某钢厂改造其烧结车间，由于工期紧，刚确定施工单位的第二天，施工单位还未来得及任命项目经理和组建项目经理部，业主就要求施工单位提供项目管理规划，施工单位在不情愿的情况下提供了一份针对该项目的施工组织设计，其内容深度满足管理规划要求，但业主不接受，一定还要求施工单位提供项目管理规划。 问题： ①项目经理未任命和项目经理部还未建立，就正式发表了施工组织设计，其程序是否正确？ ②业主一定要求施工单位提供项目管理规划，其要求是否一定正确？ ③项目管理规划是指导项目管理工作的纲领性文件。请简述施工项目管理规划的规划目标及内涵。 ④试说明施工项目管理规划的控制原则。 答：①程序不正确，公司还未任命项目经理，项目经理部还未建立，施工组织设计无人审核和批准，不能发表。 ②施工组织设计可以代替施工项目管理规划，但施工组织设计的内容深度应能满足施工项目管理规划的要求；冶金建设工程中，实际上一直使用施工组织设计代替项目管理规划；施工单位可以向业主说明提供的施工组织设计的内容深度已达到项目管理规划的深度要求，不必再编制项目管理规划。 ③施工项目管理规划的规划目标及内涵有： ａ.规划目标包括项目的管理目标、质量目标、工期目标、成本目标、安全目标、文明施工及环境保护目标、条件分析及其他内容等； ｂ.内涵包括施工部署、技术组织措施、施工进度计划、施工准备工作计划和资源供应计划和其他文件等。 ④项目管理规划的控制原则为：实现最优化控制；动态控制；主动控制；全过程控制；全要素控制；建立大控制系统的观念；要对规划的实施明确项目经理部各岗位职责、对执行进行检查分析和改进，进一步进行总结。
华北某厂１２６０ｍ３级高炉扩容改造工程。根据招标文件要求，为了实现快速、高效、优质、低耗地完成扩容改建任务，该扩容改造，应采用高炉整体平移新技术。高炉分两段安装：第一段为移送；第二段为悬吊，高炉本体工程拟定在拼装平台上基本完成，尽量缩短停炉后施工工期，保证业主要求的工期。高炉本体平移作业采用滚动摩擦方式液压缸推送。要求“新、旧高炉中心线重合，标高与原设计标高相符，误差控制在５～８ｍ”。高炉本体移送重量约４５００ｔ。推移高度约为３６ｍ，推移距离约４２ｍ。高炉本体在液压缸推动下，分步向炉基平移。 问题： ①结合本案例谈谈项目目标的制定。 ②结合本案例谈谈项目管理的总体安排。 答：①项目的目标包括质量、安全、进度、成本等目标，施工组织设计、项目质量计划由项目经理部编制，并按规定程序报批和实施。如质量目标：工程质量一次验收合格率１００％，单位工程优良率８５％以上，质量达到冶金建设工程优良标准。无重大质量事故，质量管理体系持续有效运行。竭尽全力做好工程服务和投产顺产保驾工作，确保用户满意。 安全目标：工亡事故为零；重伤事故为零；重大机械设备事故为零；重大交通事故为零。 现场目标：在争创优质工程的同时，强化现场文明施工的管理，树立公司良好的形象，建设文明、规范的施工现场。 ②项目管理实施项目经理责任制，项目经理对项目实施全方位的管理，负责项目施工全过程的质量、工期、安全、文明施工、确保履行合同，负责组织编制施工组织设计、项目质量计划、相应的项目管理文件。项目经理是工程项目质量、安全的第一责任人。 结合本案例项目管理的总体安排：强化项目管理，全面响应业主技术要求，严格科学管理、精心组织施工，优质、安全、高速建设高炉扩容改造工程。针对本工程的特点，结合类似工程的经验，我们对本工程的总体思路是：项目管理，科学组织；突出重点，齐头并进；有序安排，提高效率；阶段实施，步步为营；
it公司项目管理工作总结(多篇项目管理,公司) IT公司项目管理工作总结(多篇项目管理,公司) 目录第一篇： IT公司项目管理工作总结第二篇： IT公司招投标项目实习期工作总结第三篇： 年终总结(IT项目管理) 第四篇： 《IT项目管理》课程总结第五篇： IT项目管理心得总结更多相关范文正文第一篇： IT公司项目管理工作总结仅仅从做好管理这的角度来说，其实并不难，而且也有许多理论作为依据，战略规划、运营计划、团队建设、企业文化、流程制度等可以按照一定的科学规则去制定和实施。 这段时间比较令我困惑的是“领导”，以及管理和领导之间如何进行协调和平衡。 管理与处理复杂情况有关。 如果没有好的管理，复杂的企业可能会杂乱无章，面临生存危机。好的管理给诸如产品的质量和赢利能力等关键指标带来一定的秩序和连贯性。 尤其是科学的管理制度和流程规范可以帮助企业提高效率和规避风险。 领导更多的与变化有关，处理一些突发情况，企业、产品、业务等方面进行变革，这些都需要领导能力。 有些时候管理和领导之间可以相辅相成，但有些时候会互为矛盾，如何进行协调和平衡，这些是无法通过理论来学习到，要依靠自身的
知识能力和经验。 比如现在的产品实施，以业务为起点，经过产品策划、设计、开发、测试、验收、上线运营来完成。 可是某个产品功能，业务无法给出具体的需求，而且时间也比较紧迫，那么只能安排产品部门，要求他们根据自身对产品和市场的理解，替业务出需求，并进行产品策划，然后跟业务部门进行沟通讨论。由于情况特殊，那么必须破除规则，使用新的流程。 但是如果经常这样，就会产生很大的风险，毕竟对市场和业务的把握，产品部门肯定不如业务部门清晰，那么由产品部门主导的产品，在日后的运营和业务拓展过程中，很可能出现偏离市场的危险。 公司制定的管理制度和流程规范是为了帮助企业提高效率和规避风险，其中主要功能是明确责权利，尤其是工作职责，而我们是从事互联网业务，这就与互联网的开放、创新文化形成了冲突，前不久马云写给阿里新员工的信中写道“刚来公司不到一年的人，千万别给我写战略报告，千万别瞎提阿里发展大计.谁提，谁离开”，虽然话语偏激了一些，但是也反映了企业管理制度和创新变革之间的矛盾。 这也是最令我头疼的事情，不管是大公司，还是小企业，在企业规范管理和领导创新变革之间寻找一个合适的度，这才是最难最难最难的啊！！！第二篇： IT公司招投标项目实习期工作总结搭乘顺腾之舟起航体现自我人生价值——实习期工作总结初来公司，曾经很担心自己是否能胜任这份工作、不知该怎么与新同事共处，但是在领导悉心的教导下、公司
成功的项目管理案例： 古代有一个最成功的项目团队，那就是西游记的取经团队。 背景：为了完成西天取经任务，组成取经团队，成员有唐僧、孙悟空、猪八戒、沙和尚。其中唐僧是项目经理、孙悟空是技术核心、猪八戒和沙和尚是普通团员。这个团队的高层领导是观音。 团队的组成很有意思，唐僧作为项目经理PM，有很坚韧的品性和极高的原则性，不达目的不罢休，又有很得上司支持和赏识（直接得到唐太宗的任命，既给袈裟，又给金碗；又得到以观音为首的各路神仙的广泛支持和帮助）。沙和尚言语不多，任劳任怨，承担了项目中挑担这种粗笨无聊的工作。猪八戒这个成员，看起来好吃懒做，贪财好色，又不肯干活，最多牵下马，好像留在团队里没有什么用处，其实他的存在还是有很大用处的，因为他性格开朗，能够接受任何批评而毫无负担压力，在项目组中承担了润滑油的作用。 最关键的还是孙悟空，由于孙悟空是这个取经团队里的核心，但是他的性格极为放荡，回想他那大闹天空的历史，恐怕作为普通人来说没有人会让这种人呆在团队里，但是取经项目要想成功实在缺不了这个人，只好采用些手腕来收复他。这些手段是，首先，把他给弄得很惨（压在五指山下500年，整天喝铜汁铁水）；在他绝望的时候，又让项目经理去解救他于水火之中以使他心存感激；当然光收买人心是不够的， 还要给他许诺美好的愿景（取完经后高升为正牌仙人）；当然最主要的是为了让项目经理可以直接控制好他，给他戴个紧箍，不听话就念咒惩罚他。 孙悟空毕竟是牛人，承担了取经项目中的赶妖除魔的绝大多数重要任务，虽然是个难于管束的主，不能只用手段来约束他，这时猪八戒的作用就出来了，在孙悟空苦恼的时候，上司不能得罪，沙和尚这种老实人又不好伤害，只好通过戏弄猪八戒来排除心中的郁闷，反正猪八戒是个乐天派，任何的指责都不会放在心上。 在取经的项目实施的过程中，除了自己的艰辛劳动外，这个团队非常善于利用外部的资源，只要有问题搞不定，马上向领导汇报（主要是直接领导观音），或者通过各种关系，找来各路神仙帮忙（从哪咤到如来佛），以搞定各种难题。西游记里特别强调得到高层支持的重要性，有没有靠山真的很不同，君不见象白骨精这种没有靠山的妖魔都会死得很惨；只要有靠山的，这个妖魔就算犯了天大的事，关键的时候总会有后台跳出来搭救。
IT项目管理的关键因素 纵观所有行业，项目管理都可以使企业通过更好的信息共享来提高生产率和降低成本，在有限的资源条件下更快地以更低的成本交付产品和服务，从而增加营收。IT项目管理的成功不是以实施完验收为终点，而是把系统真正用起来为终点。现层次的CIO知识结构不仅限于懂IT，还涉及其他领域。就IT项目管理来说，其管理技巧对项目成功地实施所起的作用已为越来越多的人所承认，逐渐成为人们的共识。 一个项目可以被认为是实现特殊目标的结果，这一目标包括一系列的活动及耗费资源的任务。它必须在一项有明确开工和结束时间的计划期内完成。一个项目与选择和确定的任务有关，它最终要为公司带来综合的利益。这个利益可能是金融方面的、市场上的或技术上的，还将是趋向于长期的，有赖于整个项目的全面完成。 项目管理可以被解释为控制项目目标完成的过程，即人们利用现有的管理职能机构和资源以及各种工具、技巧来管理项目，并且不扰乱公司的正常运作。项目管理的作用是在一定的标准内将可利用的资源有效地用于完成一定的目标。项目管理的功能包括对工作提出要求；规定工作的范围；分配所需的资源；规划工作的实施方案，监督工作的进度以及调整实际进度与计划的偏差。适应市场的要求，满足投资者的利益，新项目运作程序的特殊性，运用管理来维持日常的运行等，使得项目管理变得越来越重要而迫切。 通常情况下一个大项目的全过程大致包括六个阶段：概念的形成阶段；规划阶段；生产（实施）阶段；移交阶段；项目使用阶段；项目关闭。在这六个阶段中，项目的各种参与者、项目和项目管理的功能及各自的目标、影响项目和项目管理获得成功的因素、评价项目管理和项目成功的标准等各不相同。在评价项目及项目管理成功与否时，应对不同情况进行具体的分析。
吉林省自学考试《项目管理案例分析》实践考核报告 题目：案例三、案例四 考生姓名：周塞男 考核号：A1166 准考证号：293813101166 考核教师：
目录 案例三：TCL项目研发成本的控制案例．．．．．．．．．．．．．．．．．．（1）问题1：TCL公司项目成本控制的关键是什么？研发成本的控制有效吗？为什么？．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．（1）问题2：TCL公司应如何从全局出发来考虑项目成本的控制?．．．．．．．．．．．．．．（2）问题3：请简述项目成本控制的目的和作用？．．．．．．．．．．．．．．．．．．．．．．．．．．（2） 案例四：三峡工程的进度管理．．．．．．．．．．．．．．．．．．．．．．．．．．．（3）问题1：请问三峡工程项目进度计划管理的特点?为什么要分三大层次即业主层、监理层和施工承包商层进行进度管理 (3) 问题2：为什么说项目进度的管理与控制关键在于项目进度基准计划？为什么进行项目进度基准计划修改必须慎重？...................................．．．．．．．．．．．．．．（4）问题3：从三峡工程的时间管理中你能学到什么？．．．．．．．．．．．．．．．．．．．．．．．．．．．（5）参考文献．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．（6）
案例三：TCL项目研发成本的控制案例 问题1：TCL公司项目成本控制的关键是什么？研发成本的控制有效吗？为什么？ 答：（1）TCL以研发过程的成本控制和目标成本作为整个项目成本控制的关键，从细节出着手，分析预算成本，保持成本和收益的联动关系，维持成本和收益的一定比例。 （2）非常有效，TCL成功的关键之一就是对项目研发成本的控制。 TCL的发展不仅有赖于敏锐的观察力、强劲的研发力、生产力、销售力，还得益于对项目研发成本的有效控制与管理，使产品一进入市场便以优越的性能价格比迅速占领市场，实现经济效益的稳步提高。 （3）由于成本在广义上包含了设计（研发）成本、制造成本、销售成本三大部分，也就是说，很多人在成本控制方面往往只关注制造成本、销售成本等方面的控制。 如果以研发过程的成本控制作为整个项目成本控制的起点，这才是产品控制成本的关键。研发成本的控制有效。 我们知道，一个产品的生命周期包含了产品成长期、成熟期、衰退期三个阶段，这三个阶段的成本控制管理重点是不同的，即设计成本、生产成本、销售服务成本。实际上，产品研发和设计是我们生产、销售的源头之所在，一个产品的目标成本其实在设计成功后就已经基本成型，作为后期的产品生产等制造工序（实际制造成本）来说，其最大的可控度只能是降低生产过程中的损耗以及提高装配加工效率（降低制造费用）。 有一个观点是被普遍认同的，就是产品成本的80％是约束性成本，并且在产品的设计阶段就已经确定。也就是说，一个产品一旦完成研发，其目标材料成本、目标人工成本便已基本定性，制造中心很难改变设计留下的先天不足。 如何保证我们设计的产品在给定的市场价格、销售量、功能的条件下取得可以接受的利润水平，我们在产品设计开发阶段引进了目标成本和研发成本的控制。目标成本的计算又称为“由价格引导的成本计算”，它与传统的“由成本引导的价格计算”（即由成本加成计算价格）相对应。 产品价格通常需要综合考虑多种因素的影响，包括产品的功能、性质及市场竞争力。一旦确定了产品的目标，包括价格、功能、质量等，设计人员将以目标价格扣除目标利润得出目标成本。目标成本就是我们在设计、生产阶段关注的中心，也是设计工作的动因，同时也为产品及工序的设计指明了方向和提供了衡量的标准。
项目管理最佳实践案例 主讲：陈宝光（通用管理、内训师培养高级讲师） 课程对象：企业中层管理者、项目总监、项目经理、项目工程师、项目相关参与人员。 【课程背景】 项目是遗憾的艺术：每次结束的时候都觉得本来还可以发挥更大的价值。即便技术质量指标都达到了要求，使用部门或者公司领导也还有不满意的地方，为什么会这样呢？其实每个项目在运行过程中，总会出现这样或那样的问题，比如：项目管理者的鼓励和推动不够 项目总监一开始就没有想透彻，项目团队的专家没有帮助领导整理思路 项目团队有经验的人手不足 中期设计开发的时候谁都有新要求 后期上线的时候大家方才如梦初醒：怎么是这么个东西 随着生产规范化、流程化，以及企业管理国际化的大环境下，越要求企业面向项目化管理。而在每一个项目运行过程中，项目经理都充当着非凡的角色，需要他们能够： 能够充分协调资源，保障项目有效运行， 制定详细的项目运行计划； 对项目各阶段的内容实施与进行动态跟踪； 促进多部门的沟通协作； 有效控制项目各阶段风险…… 以保证每个项目能够在预定的时间、预算和质量要求下达到的最终成功。 特别推出《项目管理最佳案例实践》课程，重点面向企业中高层经理，项目经理、核心项目组员，通过培训，帮助受训人员掌握现代的项目管理知识和运用方法，并结合万千项目实例，指导管理人员梳理和优化现有项目管理流程，建立有效的项目运行和控制体系。学会运用国际先进项目管理思想，熟练使用项目管理模版工具，进行实际项目练习，有效提高可操作性。 【课程价值】
全面认识项目管理，理解并掌握项目管理思维。 掌握项目管理工具及方法使用。 提高项目规划及管理能力。 提高项目计划能力，加强对项目的实施和控制能力。减少项目成本，提升管理效率。 【培训内容】 导入： 目管理的好处 第一单元：项目管理概论 有关项目活动的知识、技能、工具和技术的运用 视频案例： PMI与PMP PMI在项目管理的经验教训有哪些 第二单元：项目管理五大流程及项目流程之间的关系 1、启动流程 2、项目文件的展开 3、项目任务书 4、目标确定的标准 5、项目范围管理
目录 摘要 (3) 一、PDCA循环 (4) （一）PDCA循环原理 (4) （二）PDCA的步骤 (4) （三）PDCA的特点 (4) 1. 大环套小环，小环保大环，推动大循环 (4) 2. 不断前进、不断提高 (5) 3. 形象化 (5) 二、工程概况 (5) 三、第一轮阶段 (6) （一）计划阶段 (6) （二）实施阶段 (6) 1. 组织与经济措施 (6) 2. 合同与技术措施 (7) （三）检查总结阶段 (7) 四、第二轮 PDCA 循环 (7) （一）加强技术交底 (7) （二）加强操作监督，确保工序衔接 (8) 五、结论 (8) 参考文献 (9)
摘要 工程项目管理是以工程项目目标控制(质量控制、进度控制、投资控制)为核心的管理活动,是国际上通行的工程建设项目组织实施方式。在当前的后金融危机时代,建筑业面临着新的机遇和挑战,进一步深化项目管理以提高项目的投资收益是十分必要的。PDCA 循环法是一套以质量提高为目的的、从制定计划到实现计划的循环过程,是管理活动有效实施的基本方法,适用于各种质量管理工作。把PDCA循环法应用于工程项目管理,对提高项目管理水平,推动项目管理的科学化、规范化将起到积极的作用。 关键词：PDCA循环；应用；措施
PDCA循环在工程项目管理中的应用一、PDCA循环 （一）PDCA循环原理 PDCA循环法是美国知名质量管理专家戴明(W. Ed2wards.Deming)博士于1954 年根据信息反馈原理建议的,因此又称其为"戴明环”。PDCA循环是"计划（Plan）—执行（Do）—检查（Check）—总结（Action）”工作循环的简称。它是企业推行全面质量管理在方法上的重大变革。 图1-1 PDCA循环图 （二）PDCA的步骤 剖析现状，发现质量问题(工期、质量、投资、索赔等)；分析影响质量的因素，并对各个要素进行分析；找出影响目标控制的主要因素；制定措施计划；根据既定计划实施；检查效果，发现问题，总结符合标准的经验；并把问题转化为下一个周期。 （三）PDCA的特点 PDCA循环能使我们的思想方法和工作步调更加层次化、系统化、图象化和科学化。它具有如下特点： 1.大环套小环，小环保大环，推动大循环
李沙沙0906014 老师推荐给我们看的几本书让我受益匪浅。特别是《你的灯亮着吗?》。看进去之后方才知道老大的用心良苦，自己在处理工作 中的事情时，不管用户是非对错，用户提出问题，我的思想老是照着用户的问题去解决问题。在这本书中针对我目前的情况有详细的解析。 这些书带给我的启发不仅仅是关于高级IT项目管理这门课程的，也给我今后的人生上了重要的一课。正如项目经理案头手册中提到的J.M.朱兰将一个项目定义为一个计划要解决的问题。该定义使我们认识到，项目管理是在大的规模上对问题的处理。我们生活中也在不断的遇到各种各样的问题，在进行项目管理的过程中，随着工作的进展，也给我们生活中解决问题指明了一条正确的思路和方法。项目问题就是人的问题，这些书启发我们在做事的时候不要怨天尤人，惟有付之行动，生活才会回报付出者；没有计划，就没有控制；要积极主动，不要被动反应；承担责任，争取权力；所有的行为只有从执行者的视角来理解才有意义；人最害怕的是被拒绝，最需要的是被接受；沟通技能是项目经理最应具备的技能之一。 书中有说到一句：“问题其实就是你期望的东西和你体验的东 西的差别”。对于我工作中，用户正常使用TAJIMA的流程，就是我期望的东西，而体验到的东西都是，用户不按正常流程执行。问题就在于，用户更本不按流程走。而对于用户来说：用户期望的是可以直接改个供应商或直接改个单价就可以满足采购或财务的需要，而体验到的是在系统中供应商无法更改，单价在采购单更新后，财务部那边的出入库金额数据无法更新。所以用户的问题就是：采购单无法更新供应商，单价更新了无法满足财务的需要，怎么办？到
底是谁的问题？当出现这种情况，我往往把用户的问题定义成了问题。想尽方法帮用户解决。书中还有说到：“在寻找问题定义的道 路上疲倦地游荡时，不要忘记随时都回头看看，看看你是不是已经 迷路了”，在工作中我经常帮用户想解决方法，哪种解决方法对于 用户目前是最简单的？回头想想，有的时候真的帮用户解决到问题吗？没有！因为我在找解决方法的过程中，已经错误的定义了我在 解决的问题。用户入库拒收的库位选错了，入错了库位。我首先将 问题的定义为：将入错库位的数据调整至正确的库位。一股脑的想 如何去调整，用哪种调整方案最简单？结果表面上是以经解决了， 可过不了多久此类情况又会发生。其实遇到这种问题应该先想想， 库位选错的原因是什么，是不是之前的培训没有到位？如何杜绝这 种情况再次发生？现在该做些什么？应该教会用户在开单时就先确 认库位。如在开单时就选错库位就点选取消，重新开过单据。还有 一次，财务部提出采购部在采购单上更新了价格，但出入库记录的 金额还是没有，希望我们帮忙解决。我首先想到的就是帮财务部将 采购单上更新的价格导出给财务部，方便快速。但没有想到问题的 起源是：采购部在入仓之前没有输入价格，而要在入库之后才补上，导致现在这种问题。要解决这个问题的方法是让采购部在入仓之前 就把价格填上，在入库的时候就会自动获取价格，而不是给财务部 导出价格。 书中有个章节“什么是真正的问题？”里面有指出：“每种解 决方法都会带来新的问题”，回想过去的工作，的确存在很多问题 解决之后，产生了更大的问题。针对这种现象,书中指出：“问题最难以处理的部分恰恰是去意识到它们的存在”,因为用户养成的习惯，
项目管理经典案例：地主奋斗的故事 古代，有一个地主，家有良田百亩，算是一个小地主，他家一共雇佣了4 个雇农，都属于长工性质，主要负责田地的耕种。 开始，地主按照传统的方式对雇农采用高压政策，雇佣了一个护卫作为监工，现场监督雇农劳作，雇农稍有懈怠就会招来监工的一顿鞭打。雇农们非常气愤，经常聚集在一起声讨地主，一致达成默契，表面服从，但暗地里都不努力劳动，一有可能就磨洋工。 一年下来，收成比别家低了许多，地主一怒之下，认为护卫监工不力，便换了个护卫，由于成本问题，他不可能雇佣更多的人来做监工。第二年收成依然下降，而且还发生了雇农集体罢工事件。 地主气不打一处来，将监工和雇农全部拿下，并增加了四个雇农，他们分别是张三、李四、王五、赵六，同时地主亲自参与监督雇农的劳作，但情况丝毫没有转变，到了年底收成依然达不到理想水平。 地主苦恼极了，正在此时，一个西方的传教士来到这个封闭的山庄，经过与传教士的深层次交流，地主深感资本主义的先进性，他转变成为了新兴派人物，同时落实到实际情况上，他辞退了监工，并强调给予雇农们充分人权和自由，保证不再采用强制性的高压政策，而采用固定工资制并制定了详细的规章制度。 规章制度规定雇农们每日鸡叫必须起床，太阳升起之前必须上岗劳动，中午太阳烈时可以在树荫下休息一个时辰，太阳落山了才能够收工。上工和收工都必须在地主家按拇指印，考虑到雇农还得照顾家庭，地主规定雇农每隔5天可以休息2天，但条件是不得耽误农活。 凡违反劳动记录，一次迟到或早退扣罚当天工资，一次旷工扣罚10天工资，一年累计5次旷工（三次迟到或早退算一次旷工，缺少一个拇指印按半次旷工处理）做自动离职处理。劳动期间不准偷懒和晒太阳，凡发现者一律按迟到论处。 由于地主提供的薪金极具挑战性，而且按月提供，不至于青黄不接，雇农们欣喜若狂，纷纷表示一定要努力工作，以报答地主的大恩大德。 当年土地收成提高了50，地主看到民主管理带来的巨大收益，高兴得嘴都笑不合拢。兴奋之余，他决定扩大生产规模，于是向其他地主购买了100亩土地，另外又招聘了周七、武八两个雇农，准备大干一场。 一切照旧，想象着年底丰厚的收成，地主经常从睡梦中笑醒，日子一天天过去，年底来了，收成汇总下来，在新增100亩地和两个人的情况下，收入仅仅增长了10.地主气急败坏，把雇农们召集起来，开了一个声色俱厉的批判大会。大
省自学考试 《项目管理案例分析》实践考核报告 题目：案例一、案例五 考生： XXXXXXX 考核号： XXXX 号： XXXXXXXXXXXX 考核教师：
目录 案例一:微软公司办公商务单位—Winword之成败 1你认为WinWord的开发项目是成功的，还是失败的？为什么？并阐述影响项目成功的决定因素有那些 (3) 2 WinWord的项目管理过程中存在哪些问题 (4) 3 WinWord开发项目中，采取了怎样的组织形式？ (5) 案例五：石化公司低密度聚乙烯装置的风险管理 1根据石化公司对LDPE项目的敏感性分析表，请回答什么是敏感性分析，从敏感性分析表中能得出什么结论 (6) 2结合石化公司LDPE项目回答项目风险应对的方法和手段有哪些？具体如何操作 (6) 3具体分析石化公司LDPE项目可能存在的风险 (8)
案例一：微软公司办公商务单位—WinWord之成败 问题1：你认为WinWord的开发项目是成功的，还是失败的？为什么？并阐述影响项目成功的决定因素有那些？ （1）WinWord的开发项目从总体上看还是成功的，从以上的案例可看出，winword的开发是非常不容易的，从开始的筹备到最后的成功发行面临了巨大的压力的同时也带来了技术的创新，引发了新的软件技术革命。该文字处理程序是微软Microsoft Office组件的一部分，它虽然延期完成，但总体上的技术性能得以实现，这是从顾客使用的普遍性程度上能够看出来的，所以这一项目还是被顾客所广泛接受的，所以还是成功的，但是其中的瑕疵也是需要修改的。 （2）影响项目成功的决定因素主要有公司、项目本身和客户三方面的因素：①最主要的还是公司的因素，公司的选择对于项目成败关系非常重大，项目公司的总体经验和实力还表现在能否正确、妥善的处理项目实施阶段的各种问题。首先，公司要制定正确的经营战略，提高自主创新能力，依靠科技进步、科学管理等手段，形成自己的竞争优势。诚信经营，树立良好的信誉和企业形象，根据市场需求生产适销对路的产品。注重产品质量，提高产品的科技含量。自觉适应市场规则。并且为了防止上述问题的发生，需要设计合理的项目管理结构，保证项目的各个投资者有充分的利益需求而投入足够的资源承担起项目的管理责任，建立一支有经验的尽职的经营管理队伍。同时，注意建立相应的平衡制约机制，明确规定项目的决策程序，保护其他投资者的利益。公司必须对各种风险有清楚的认识，较好的处理各种风险。对于如此复杂而种类繁多的风险，公司应具备较强的风险管理能力，应尽可能的采取多种方法降低风险，如进行细致的场地调查、市场调查、准备备用方案、进行竞争控制以及取得货币可兑换性担保，等等。 ②项目本身的因素：项目成功的最重要因素之一是项目是否可行，尤其是项目在经济上是否可行。在项目初期，发起人应进行可行性研究，确定项目的可行性，可行性研究应该证明项目在不同方案下的财务和经济均是可行的。在进行可行性研究时应该对项目进行认真规划，增强项目的吸引力。在选择项目时，首先应考虑项目的必要性，即该项目是否很需要。包括项目是否在国家允许私人投资进入的产业围，特别是项目是否是国家急需建设的基础设施。在考虑项目的必要性时，