databaseadmin | 01 八月, 2006 10:43
1、项目经理必须关注项目成功的三个标准
简单地说，一是准时；二是预算控制在既定的范围内；三是质量得到经理和用户们的赞许。项目经理必须保证项目小组的每一位成员都能对照上面三个标准来进行工作。
2、任何事都应当先规划再执行
就项目管理而言，很多专家和实践人员都同意这样一个观点：需要项目经理投入的最重要的一件事就是规划。只有详细而系统的由项目小组成员参与的规划才是项目成功的唯一基础。当现实的世界出现了一种不适于计划生存的环境时，项目经理应制定一个新的计划来反映环境的变化。规划、规划、再规划就是项目经理的一种生活方式。
3、项目经理必须以自己的实际行动向项目小组成员传递一种紧迫感
由于项目在时间、资源和经费上都是有限的，项目最终必须完成。但项目小组成员大多有自己的爱好，项目经理应让项目小组成员始终关注项目的目标和截止期限。例如，可以定期检查，可以召开例会，可以制作一些提醒的标志置于项目的场所。
4、成功的项目应使用一种可以度量且被证实的项目生命周期
标准的信息系统开发模型可以保证专业标准和成功的经验能够融入项目计划。这类模型不仅可以保证质量，还可以使重复劳动降到最低程度。因此，当遇到时间和预算压力需要削减项目时，项目经理应确定一种最佳的项目生命周期。
5、所有项目目标和项目活动必须生动形象地得以交流和沟通
项目经理和项目小组在项目开始时就应当形象化地描述项目的最终目标，以确保与项目有关的每一个人都能记住。项目成本的各个细节都应当清楚、明确、毫不含糊，并确保每个人对此都达成了一致的意见。
6、采用渐进的方式逐步实现目标
如果试图同时完成所有的项目目标，只会造成重复劳动，既浪费时间又浪费钱。俗话说，一口吃不成个胖子。项目目标只能一点一点地去实现，并且每实现一个目标就进行一次评估，确保整个项目能得以控制。
7、项目应得到明确的许可，并由投资方签字实施
在实现项目目标的过程中获得明确的许可是非常重要的。应将投资方的签字批准视为项目的一个出发点。道理很简单：任何有权拒绝或有权修改项目目标的人都应当在项目启动时审查和批准这些项目目标。
8、要想获得项目成功必须对项目目标进行透彻的分析
研究表明，如果按照众所周知记录在案的业务需求来设计项目的目标，则该项目多半会成功。所以，项目经理应当坚持这样一个原则，即在组织机构启动项目之前，就应当为该项目在业务需求中找到充分的依据。
9、项目经理应当责权对等
项目经理应当对项目的结果负责，这一点并不过分。但与此相对应，项目经理也应被授予足够的权利以承担相应的责任。在某些时候，权利显得特别重要，如获取或协调资源，要求得到有关的中小企业的配合，做相应的对项目成功有价值的决策等等。
10、项目投资方和用户应当主动介入，不能被动地坐享其成
多数项目投资方和用户都能正确地要求和行使批准（全部或部分）项目目标的权力。但伴随这个权力的是相应的责任——主动地介入项目的各个阶段。例如，在项目早期要帮助确定项目目标；在项目进行中，要对完成的阶段性目标进行评估，以确保项目能顺利进行。项目投资方应帮助项目经理去访问有关的中小企业和目标顾客的成员，并帮助项目经理获得必要的文件资料。
11、项目的实施应当采用市场运作机制
在多数情况下，项目经理应将自己看成是卖主，以督促自己完成投资方和用户交付的任务。项目计划一旦批准项目经理应当定期提醒项目小组成员该项目必须满足的业务需求是什么，以及该怎样工作才能满足这些业务需求。
12、项目经理应当获得项目小组成员的最佳人选
最佳人选是指受过相应的技能培训，有经验，素质高。对于项目来说，获得最佳人选往往能弥补时间、经费或其它方面的不足。项目经理应当为这些最佳的项目成员创造良好的工作环境，如帮助他们免受外部干扰，帮助他们获得必要的工具和条件以发挥他们的才能。
databaseadmin | 01 八月, 2006 10:42
随着建筑施工行业的平均利润率不断降低，加强施工过程的成本控制越来越被施工企业所重视。一些具有实力的软件公司在深入研究施工项目成本控制的客观规律的基础上，研制开发了适用于施工项目成本管理的软件系统。
经过实际应用，这种系统会给项目成本管理带来了3个层面（数据、流程、决策）的变化；解决了4个主要的问题（准确、实时的项目成本核算；权责明确的过程控制；动态的“盈亏分析”；改变人的工作状态）。
1 对项目成本管理带来了“三个层面”的变化
1.1 第一个层面是数据的信息化。
长久以来，项目部成本数据的归集都倚靠手工操作进行，部门之间成本数据的交互倚靠纸介质进行，无法进行成本数据的统计、查询、分析，而工具软件的应用（如材料管理软件、概预算软件等）可以方便的进行某一方面的成本数据的归集、分析、查询，但满足不了项目成本管理的系统性要求。
软件系统将各种与成本相关的数据如消耗材料的进库、出库、退库、报损；周转材料的进场、出场、报损等等都以一定的数据格式录入到计算机里，以数字的形式保存起来，可以随时进行成本的归集、查询、分析。此外，各相关部门的成本数据通过局域网络传输，实现成本数据的共享，从而实现了数据的信息化。
1.2 第二个层面是流程的规范化
目前，建筑企业在项目成本管理工作中面临的一个普遍现象是操作流程不规范，造成了成本浪费的隐患、成本管理的低效及管理漏洞。
软件系统作为一种管理手段，辅助企业的管理制度，将企业已经规范的一些科学的项目成本管理流程以软件程序的方式固化下来，使得流程所涉及岗位员工的工作更加规范高效，加强了成本管理中的约束（如限额领料），减少人为控制和"拍脑袋"的管理行为，同时堵塞了管理上的漏洞。
1.3 第三个层面是决策的科学化
已往，由于落后的成本管理手段，在决策时缺乏对成本对象的“定量”分析（往往只能作“定性”的分析），使得决策往往依靠管理者的个人积累的经验。而且管理者要等每个月报表出来后才知道哪儿超了、哪儿省了，若要等此时才决策，恐怕早已为时已晚了，这种凭经验决策及事后决策（控制）的方法与市场经济是极其不相适应的（可能也是“实属无奈”），也根本无法控制住项目成本。此外，由于项目成本管理的“一次性”特点，也在客观上决定了决策的“一次性”，过程控制中的决策失误将无“后悔药”可吃。
软件系统通过对那些成本原始数据进行科学的加工处理，运用一定的计算模型，实现了项目成本管理的事前计划、事中控制、事后分析等全过程的“定性”、“定量”分析，更重要的是通过这些“定性”、“定量”分析使项目管理者对成本过程控制中的“薄弱环节”作到心中有数，及早应对。所有这些从理论上（因为决策是管理者的行为，有人为因素参杂）保证了决策的科学性。此外，这套软件系统可实时动态的进行成本数据归集、查询，从而真正起到对项目成本管理科学决策的支持作用,从某种意义上来说，这套系统也是项目成本管理的决策支持系统——辅助项目管理者科学决策。
2 解决的四个主要问题
2.1 准确、实时的项目成本核算
软件系统本身就是一个业务平台，从根本上消除了各业务部门的“隔离”，财务部门不但能了解项目成本产生的全部过程，而且伴随着各相关业务部门的每一个作业，财务都有相应的反应。如材料部门在记录一笔材料出库、退库的同时，财务也得到了这个信息，并将相应的材料费用计入实际成本；经营部门对分包商每完成一笔结算，财务就产生相应的应付款等等。可以看出正是这种成本数据信息的通畅、透明，才保障了项目成本的准确、实时成本核算才成为可能。
2.2 权责明确的过程控制
项目部不仅要进行管理范围内的权责划分，且还要处理外部错综复杂的权责关系：项目部建筑主材往往由公司或甲方供应；专业分包中公司与甲方也往往参与其中；项目部对公司的承包方式（实际上就是权责划分）多种多样等等。哪些成本由材料部门负责，哪些由机械部门负责；哪些成本是由公司负责，哪些由项目部负责；哪些成本由A分包队负责哪些由B分包队负责等等。而且，在市场经济条件下要作到权责明确还必须进行“量价分离”，如公司供应主材时“价”对项目部是不可控的，而“量”是可控的，此时，这种材料的成本就由公司和项目部共同产生。对项目部来说就要对所有这些（成本的）权责进行划分并跟踪，否则，成本的“过程控制”将无法控制好。
已往在某些建筑企业也实行了“全员、全过程成本管理”，但由于成本管理手段的落后及制度方面的原因，使得责任成本制定容易、跟踪难、考核更是难上难，这就造成项目成本谁都负责，而实际上又谁都不负责的局面。
软件系统可以很方便地帮助项目部进行目标成本分解，依实际情况将目标成本明晰地划分为“可控”及“不可控”部分（注意：此“不可控成本”并非与项目部无关了，而是从“量”或“价”角度按权责划分不由项目部负责的），对“不可控”部分成本的盈亏项目部能说明盈亏的原因，对“可控”部分成本进行进一步的权责划分，将其落实到责任部门及责任人，实时利用计算机系统对其发生成本进行计算、数据归集、分析，并对其进行跟踪，使得成本的“过程控制”“有章可循、有据可查”，配合项目部相关成本管理制度使“成本谁都负责，谁又都不负责”这个局面得以彻底改观。
2.3 动态的“盈亏分析”
项目管理者关心在项目实施过程中到底是盈了还是亏了，盈了——盈了多少，亏了——亏了多少，这在过去往往是谁也说不清，其中一个重要的原因是——项目施工环境的“动态性”。
在项目施工过程中的不可预见因素很多（往往造成“计划赶不上变化”），且各关键因素又是紧密关联的，如进度、成本、质量三者中某一因素发生变化都会导致其它因素发生变化，如在施工过程中，由于某种原因造成进度计划发生了延误，这将导致一系列的变化：控制工期的关键工序可能发生变化；为保证工期可能要改变施工方法；这又可能导致材料、机械等资源使用计划的变化；与此同时为保证工程质量可能将导致增加资源投入；而所有这些必将导致成本的变化，这是一个复杂的、系统的逻辑、数学模型。动态的施工环境决定了施工过程中的“盈亏分析”必然是动态的，单靠人手工计算及已往的经验积累是不可想象的，这也难怪已往项目施工过程中“盈亏谁也说不清”的无可奈何了。
软件系统利用计算机强大的数据处理功能，将与项目成本有关的各因素按成本费用的逻辑关系，建立起数学模型，采用人机结合方式，面对施工环境的动态变化系统自动进行成本的归集。现在，用户在应用了此套软件系统后，随时都可进行准确的成本的“盈亏分析”。 前面也提到项目部随时可面对投影仪（计算机）显示屏进行“成本核算”，其实它同时也可进行成本的“盈亏分析”，它的过程同样可以作到实时、动态。
2.4 改变人的工作状态
软件系统集项目施工现场管理与成本管理于一体，它以提高项目部成本管理的整体水平为目标，不仅从业务上保证成本管理的更趋科学和规范，同时从人的角度对提高整体水平也有重要作用（1）该软件系统是一个平台软件，各部门相关工作人员同在此平台上进行项目成本的管理工作，加强了人与人之间、部门与部门之间、员工与领导之间的沟通，提高了工作效率。（2）由于这套软件系统将项目成本形成过程“透明化”及“可控化”（即：过程可控）使得项目部员工能积极参与到项目成本的管理中来，为项目管理者出谋划策，增强了员工的成本责任感。（3）项目管理者在决策时可以掌握更为详尽（全面、定量）的信息，也就减少了决策失误产生的可能。同样，由于成本形成过程“透明化”及流程“规范化”，堵塞了管理上的漏洞，使少数人不能再“浑水摸鱼”了。（4）通过软件系统的实施，营造了一种沟通、参与、信任、高效、权责分明的文化氛围，这些又保证和促使了项目部成本整体管理水平的提高。
总之，系统的应用使得项目部业务流程、管理制度、人员工作状态得到很大的改善。相信，随着软件公司对施工管理过程的深入了解以及施工企业对信息化的不断认识，软件公司作为施工企业提高管理的强大支持必将发挥更大的作用。
databaseadmin | 01 八月, 2006 10:41
软件测试员的目标是找出软件缺陷，尽可能早一些。
软件测试员的一个基本素质是：打破沙锅问到底。
大多数软件测试员应具备的素质：
1.探索精神：软件测试员不会害怕进入陌生环境。
2.故障排除能手：软件测试员善于发现问题的症结，喜欢猜谜。
3.不懈努力：软件测试员总是不停尝试。他们可能会碰到转瞬即逝或者难以重建的软件缺陷；他们不会心存侥幸，而是尽一切可能去寻找。
4.创造性：测试显而易见的事实，那不是软件测试员；他们的工作是想出富有创意甚至超常的手段来寻找软件缺陷。
5.追求完美：他们力求完美，但是知道某些无法企及时，不去苛求，而是尽力接近目标。
6.判断准确：软件测试员要决定测试内容、测试时间，以及看到的问题是否算作真正的缺陷。
7.老练稳重：软件测试员不害怕坏消息。
8.说服力：软件测试员要善于表达观点，表明软件缺陷为何必须修复，并通过实际演示力陈观点。
9.在编程方面受过教育。
databaseadmin | 01 八月, 2006 10:40
要做好各要素沟通，要实现于人的管理，就应站在这些“项目干系人”的角度上，从他们的需要及利益出发，最大限度的通过项目实现他们的价值，如果脱离这些，那么项目是很难获得成功的，举一个在项目管理中实际遇上的案例：
年前，我们接到一个有关商务管理系统开发的项目，当时用户提供的需求只是七、八页的几张纸，反馈说已经是最清楚最详细的需求，并且包括了需要的几张报表，接到该单后，我们开始最初的需求调研，由于与我们沟通的客户工作人员一直未能提供其它相关资料，于是，我们按其提供的需求分析其业务流程，将业务流程转化为系统模型，并一环一环地与客户进行确认，在进行了一个多星期的细化调研及分析后，我们整理出六七十页的需求，当要与客户进行确认时，客户的部门经理一句话否定了我们的所有工作：“这不是我们要的啊，虽然我们现在是按这个流程，但要上系统，我们的流程也要变，基本上不是按这个方式进行的啊！”
这是项目经理在一开始，在与客户沟通前所忽略的问题，需求调研就是要与客户就其所需要的功能、流程、操作等需要为基础，而且需求决策者必须是项目经理或部门负责人，所以项目经理如果在与客户进行需求调研及交流前，在充分考虑项目的需求性及可行性后，列一个需求管理（包括详细的沟通计划及要求沟通）计划，考虑需求沟通中所需的人员、资源、时间的要求，才可以保证需求调研的准确性，虽然有些因素是客户方照成的，但我们应该站在其角度上，为其考虑一些存在的客观及主观因素，这就是在沟通前没有充分考虑一些假设或约束的因素，沟通要求并没有充分明确列举。在具体活动中可参考下图“项目管理—沟通管理的活动要求”
同样也是该项目，由于项目经理并未把一些过程的实际及交流情况及时反映给部门经理，虽然有些责任并不是我们应该承担的，但因受到客户的投诉，部门经理自然就将所有的责任归究于项目经理了。在调整了活动方式及沟通方式后，我们又花了二个多星期进行需求的再次调研及分析，最终分析出的需求文档已经和原来的完全不同，页数也上升到200多页，客户的满意度自然达到100%。而先前所花费的二个星期时间就等于无用功，该项目的成本也比预先估计的要翻了好几翻（因为实际调研出的需求功能比原先估计得要多出许多）。
软件开发中需求管理的沟通方式影响到需求基线的准确性，同样在项目的开发、设计过程中，项目经理与项目成员之间的沟通方式及项目经理对团队的建设技巧也是直接影响到项目成败的关键。项目过程中沟通的目的是为了“保持项目进展、识别潜在问题、征求建议以改进项目绩效”，如果在项目的开发、设计过程中未把好沟通这道关，也有会产生意料之外的项目失败，曾经听过同行的这样一个例子，某公司在开发一套考核绩效管理软件，项目需求做得非常的完善，系统分析地也十分明确、清晰，但在开发阶段，项目经理发现系统分析其中一个中间层的函数出错，因为该功能模块由他一个人负责开发，当时他直接就对其参数进行了修改，也并未及时和其它编程人员进行沟通说明，过后也就忘了这件事，但当项目接近尾声时，系统突然出现一个大的Bug，影响到整个系统的运行，最后在花了大量的人力、精力进行查询后，才发现就是这名项目经理更改的参数出了错。如果当初名这项目经理能及时和其它人进行沟通，这种错误完全能够避免。但这些错误延误了系统在合同期内的交付，影响到客户的利益，最后几万元的项目反而赔偿用户损失近十万。所以，项目过程中的沟通有时会直接影响到项目的成败，同样一个好的配合团队能使项目达到事半功倍的效果。有认识这么一位软件开发项目经理，他项目管理的理念就是“以人为本”，在项目活动中，他考虑到各项目成员的物质、精神的需要，在与客户沟通时，他注重的是客户需要什么，能为客户提供什么，每次他带的项目总比别人的进度要快，成本要低、项目团队配合融洽、每个成员神采奕奕，这是令其它项目经理所羡慕不已的。
沟通在项目管理中，有其必然的、不可取代的重要地位，在1995年，斯坦迪什集团研究发现，与IT项目成功有关的三个主要因素是：用户参与、主管层的支持、需求的清晰明确。所有这些因素都依赖于拥有良好的沟通技巧。项目经理除了在项目前期编制良好的沟通计划外，更要懂得如何科学地管理团队，如何艺术化的与‘项目干系人’进行沟通，站在各角色人的立场上，想客户所想，急客户所需，这样才能做到通过我们的项目成果使客户得到最大的收益，让客户满意，这样才能实现一个项目的成功性目标。在最近的一个外包项目中，我们项目组在前期就对与分包商之间各阶段工作的数据采集、成果验收、评审依据等沟通形式进行了明确的细化要求，这样在操作上双方都有一个清晰地沟通形式及目标，项目进展就较为顺利许多。
说到项目管理是一门艺术，不仅仅表现在与“项目干系人”之间的沟通技巧，项目管理的八大要素硬背起来谁都会，但如何灵活地驾御它，使这些要素操作上更灵活化，更适合实际的项目运作中去，这就需要项目经理艺术化的管理、技巧上的操作，管理条条要求是定死的，但人是活的。无论在哪个领域的项目管理中，这些沟通技巧都是通用的并配合掌握着其它项目管理要求的相关要素进行着的。
在今后的实际工作中如何使用“项目管理”这门艺术，灵活地通过“沟通”管理，保证项目极大限制地满足客户的需要、引导项目迈向成功的目标，是每个项目经理应给予考虑并慎重实施的。
databaseadmin | 01 八月, 2006 10:34
总体上说，我们的需求分析是做了，但是做得很不够，我们做的需求只解决了我们能做出这样的项目，但是没有解决这样的项目是不是真就是客户想要的。造成这种状况的原因主要是下面几个情况：
客户本身说不清楚
文物网是这样，中彰国际更是这样，但是这不能怪客户，毕竟客户在软件方面的知识要少的多，也没有相关的经验，可能心里只有一个想要的软件的轮廓，于是可能会要求我们去替他们来完整这个轮廓的细节，而我们的能力、我们能否真正站在客户角度去搜集和整理这些需求，就决定了这个需求的完整性和有效性。
需求自身经常变动
随着客户对这个项目越来越深刻的理解，那么可能他的需求也会随之改变，这些变化的可能性越大项目风险就会越大，我们在需求分析的时候就要充分考虑到哪些需求是相对固定的需求，哪些可能会是产生变动的需求，考虑到他的可变性，这样设计功能和数据库的时候不致因为后面的变动而影响整个工程。
分析人员或客户理解有误
毕竟，不是每个分析人员都是专业而合格的，为避免这种情况的发生，需求分析必须要有审核制度，公司自己内部要审核一遍，客户再审一遍，提出意见，修改后双方共同评审签字，确认。
由此出现的问题：
a) 需求分析过于笼统，只关注到面上，没有关注到点上，开发出来的东西在具体的细节上和客户的理解有误差，并且无法严格界定是否属于需求变更。中彰的方案就是这样的。
b) 需求报告只求我们这方评审通过，不去关心客户的评审，认为只要客户签字认可就行。虽然签字认可能够给日后出现问题时划清我们的责任，但是不能保证使项目实施成功。
c) 需求分析中含有技术实施上有难度的功能，一味的求全和盲目按照客户的设想，受客户影响过大，毕竟，很多时候，客户的想法在实际实施过程中是不现实的，或者可以有更为简便的方法来替代的。如中彰国际的在线交易功能，后台大批量邮件群发功能。
d) 对双方已经确定的需求，实现以后并不适合客户使用，需要按照变更手续执行的时候，客户可能会纠缠，提出“你们是专业人士，你们应该事先能提醒我们可能会出现这种问题”并以此来把责任推给我们，而我们又不好完全按照变更手续执行，因为可能激化双方的矛盾，比如508的批量处理功能，因为属于人事管理比较专业的细节问题，需求分析师开始没有对客户业务熟悉到如此细致的地步，而客户也没有过多关注这些细节，导致软件的某些功能不合用，较为繁琐，而重新按着客户的意见修改的话工作量比较大，导致成本增加、工期延长。
e) 项目的成熟度受客户预算的限制。大部分客户在项目投入上都是有预算的，在成本有上限的前提下，项目的功能设计（软件的成熟度）方面必然受一定影响，毕竟功能越多越完善，相应的开发成本就越高。这种功能上的不完善需要事先告知客户并得到理解。
f) 此项工作的反复造成思想上的倦怠，使需求分析最后虎头蛇尾。需求分析是一项繁琐枯燥的工作，需要和客户之间不断的商讨、确认和反复，另外由于大部分的客户虽然安排专人负责这项工作，但是该人并不只做这项工作，特别当他被很多其他的事情缠身的时候，而无心细看提交过去的需求报告的时候，他很可能会给你一个错觉，让你认为他已经真正的理解并认可了你的设计。
结论
a) 需求分析是整个项目管理中需要重点控制的几个关键节点之一，首先思想上一定要重视。
b) 需求分析报告的编写者要参与到需求的搜集工作中，准确领会客户的意图，并转化成软件能够实现的功能。对于说不清楚需求的客户，要善于问关键问题，引导客户提出自己的需求。可以采取的措施是事先编制一个问卷调查之类的文档，详细列举需要客户回答的问题，以便防止遗漏。
c) 需求报告的编写者要能够对客户需求进行深入分析，区别出哪些需求存在日后变更的可能，哪些需求属于相对固定的，哪些需求能够实现，哪些需求需要变通才能实现，以便于指导后面的功能设计。
d) 需求分析报告对功能细节的描述不能有歧义，描述一定要全面、准确，防止开发方和客户只见对同一个问题有两个截然不同的理解。可以通过评审，用大家的力量来避免这种情况发生
e) 需求报告的每个关乎功能的描述都要让客户明白和理解，客户在理解之上的确认才能够保证日后一旦出现问题不致出现双方互相推托责任纠缠不清的情况。
f) 需求报告一定要经过一个有技术人员和业务人员参加的评审，要充分发挥团队的力量，重视每个人的才智，一个模块一个功能的逐一的过，让大家来共同找出需求报告里不合理的、有歧义的、不完善的、遗漏的等等问题
g) 帮助客户去理解提交给他的需求分析报告而不是只等签字，对于有能够用好几种方式实现的功能，尽量做到能让客户去比较和选择。不要让客户对报告中的部分产生歧义。只有客户对报告的完全的理解，才能在日后客户提出的修改被认为是需求变更的时候能够得到客户的理解
h) 最后，需求分析报告一定要双方共同签字确认
databaseadmin | 01 八月, 2006 10:33
程序开发是项目的核心。因此缺少管理的程序开发，就不会作出成功的软件项目。
项目遇到的问题：
程序开发是项目的核心。因此缺少管理的程序开发，就不会作出成功的软件项目。程序开发过程中，项目的程序员是根据已有的模块设计文档，理清思路，然后编写程序。但是由于程序员编写程序步骤比较随心，导致可能出现对需求理解不清楚，又或者由于本身的水平有限，导致程序本身存有缺陷。
解决方法：
因此，在项目管理中，项目经理需要指出项目中高级程序员必须指导他们所属的程序员。
1.程序员必须了解清楚自己所做部分的需求。
2.程序员必须了解清楚自己与其他人所做模块的衔接点,及其应该注意的地方。
3.程序员在开发前最好编写一个开发的步骤文档
步骤如下：
3.1 弄清表间的关系(例如：A表与B表的关系究竟是1：N 还是 1对1 还是 N：M)
3.2 看自己工作所需是视图还是表，如果是视图，先编写好视图的sql语句，这里亦可以当做一个数据备份
3.3 写出业务逻辑运行步骤，例如先计算A，后计算B，再计算C。这样写代码的时候，就可以一步一步根据文档有序的往下编写程序。
3.4 构思出对页面的布局及做法并写进文档。
3.5 让你的上级对文档进行评审以便他对的你的错误地方在编写程序前已可以当面指出。
3.6 编写2点中与他人模块间的衔接点及注意的地方，以及以什么方式衔接（例如是采用接口，还是某个对象）
4. 正式编写代码。（为了可以提高自己的写代码的效率，可以利用代码生成器生成基本代码，根据文档增加进所需的逻辑业务。）
5. 代码编写完成后，要进行测试。 测试既要自己测试，也要提供大量的模拟数据给测试人员方便进行测试。因此，应该编写一个模拟数据的存储过程。
此文仅代表作者个人意见。
databaseadmin | 01 八月, 2006 10:30
企业管理体系这样一个系统，本身也有其自身的规律，目前全球众多的机构推行着众多的企业管理理论和方法，但其实都万变不离其宗，他们就如同软件开发中相关的理论和方法论，为管理者提供指导。既然企业管理体系也是一个系统，那么要建立这样一个系统，也需要经过系统分析、设计、实施等一系列的过程，而且这个过程还可能是一个迭代的过程，企业的管理体系是逐步建立起来的，管理水平是呈螺旋形上升的。木桶原理也好，短板管理也好，无非也是强调企业管理这个体系的内部关系，强调均衡发展。
为了建立好一个企业管理的系统，需要管理者具备两方面的能力：一方面，要利用管理技术，能够定义系统的功能，对系统进行分析、分解，对各个部分进行设计和实现，并且要保证所有部分最终能够有机的结合在一起，均衡发展。另一方面，在建立这个体系的过程中，也要考虑各项管理内容的相互依赖关系，所需的资源、条件等因素，按照一个合理的步骤来组织改进过程的实施。这两者的关系，就如同我们现在项目中的工程管理和过程管理，工程管理是系统建立所必需完成的工作及应得到的成果，体现的是产品工艺，是企业管理体系固有特征决定的，这方面主要反映在MBA的知识体系中，而过程管理就是企业的变革管理，决定了实现过程的组织，这方面主要反映在项目管理的知识体系中。生产工艺从根本上决定着生产过程，而生产过程又反过来影响系统的实现。企业管理的规律决定了企业管理体系的核心内涵及其内部的相互依赖关系，它从根本上决定着企业管理改进的过程。我们不否认管理本身的艺术性的部分，但是必须明白，管理本身首先是一门技术，它是管理艺术的基础，艺术家也是从基本功学起的，他们的艺术性是对基本功的娴熟、灵活的运用，但不是任意而为。没有管理技术的基础，根本就谈不上管理艺术。
因此，要成为一个好的管理者，就需要特别注意管理技术的学习，这个管理技术还不是指我们平时所说的那些管理技巧，技术与技巧英文原文分别对应Technology和Skill两个不同的词。用软件编程作比方，编程语言的语法规则是技术，如何运用这些基本规则来编写程序是技巧。现在许多人高谈阔论管理艺术、技巧，但管理技术方面的知识在其头脑中还是空白。
作为管理者，特别是企业的管理者，就需要加强对这种管理技术的学习，这确实是一个专业，来揭示管理工作中各种管理对象、内容的相互关系，并提供理论、方法作指导，提供成熟的管理工具的支持。这是做好管理的必要条件。在管理者当中经常可以看到这样几种不正确的做法：
1，纯粹经验型的管理，凭借自己以往的经验和自身的聪明灵敏，兵来将挡，这种情况往往表现为被动应付，即使有时会提出一些改进建议，但往往只是局限在解决表面现象，不能从问题的根源上解决，舍本求末，以后还会反复出现同样的问题，结果是治标不治本。
2，用专业技术管理代替全面的管理，这种情形经常会发生在具有丰富专业技术经验的管理者身上，把自己的工作重点放在了指导下属解决专业技术问题上，利用更高的职权来解决以前解决不好的具体问题，就好像从项目经理提升成了高级项目经理一样，在成为真正的管理者后，把以往工作中遇到过的具体问题，作为管理改进意见提出，但还是在原来形成的专业技术管理的思维方式和工作模式中，没有真正转向管理，没有系统的思考如何完善管理体系。
3，缺乏科学理论指导而进行管理体系的改进，这种情况在一些管理者身上也比较常见。许多管理者也非常愿意改进企业的管理体系，提升自身的管理水平。但是，由于缺乏对管理体系的科学认识，不了解建立这种系统的方法论，对其中各项管理内容缺乏深入、细致的分析，完全凭着热情做事，在改进管理的过程中，往往是眉毛胡子一把抓，解决了一个问题又带来了新的问题，或者在解决一个问题时反而为以后继续解决问题设置了障碍，甚至把管理改进引入歧途。
用一个形象的比喻来形容管理体系的建立和改进。一个充满问题的企业就像一条被污染了的河流，面临问题的人其实是处于河流的下游，接触到的是问题的结果，是表面现象。针对具体问题逐个解决，就像在河流的下游治理污水，属于被动防守。如果要从根本上解决问题，就要从上游污染源入手解决，而且顺序应该是从上游到下游，治理掉一个解决一段，而对于下游来说，初期的效果不会很明显，只有到上游的所有问题都从根本上解决了，问题才能最终得到彻底解决。但如果不从上游入手治理，那么下游将永无宁日。因此，在企业管理改进中，不仅需要在下游治理污水，更要从上游治理污染源，而且只有从源头解决，才能使问题得到最终彻底的解决。
尚未掌握管理技术的管理者，由于对这样的管理体系缺乏系统的认识，有的甚至对一些基本的管理概念、名词术语还存在着误解，这将给整个组织带来混乱，给管理体系的改进带来反复。这就如同一个不具备系统分析能力的程序员，一味强调编写程序，结果必定是盲目的。因此，在成为管理者的过程中，都需要做好角色转换，注重学习相关的管理技术，掌握企业管理体系的内在规律，用理论指导实践，在解决燃眉之急的同时，从源头抓起，从根本上解决问题。学习管理技术，是磨刀不误砍柴功，以后做管理工作才能够事半功倍。
随着改革开放，西方先进的管理理论、方法也随着进入本土企业。但是有许多管理者却认为这些舶来品在本土企业中水土不服。诚然，西方人和东方人在文化背景方面存在着很大的差异，但是在管理技术方面，却不存在着本质的差别。我们只有静下心来，本着实事求是的态度，进行深入、细致的学习和研究，掌握其中的客观规律，才能在实践中很好的运用。在此之前，我们先不要妄下断言，也不要断章取义的盲目运用，这都不是正确的方法。
在学习管理技术的过程当中，要特别注重对专业术语、方法论和管理工具的学习。
在每一个专业领域中，都有其特定的专业术语，而每个术语背后都有其特定的内涵，专业术语是这个专业领域中沟通的基础，也是了解、进入一个专业领域的门槛，在管理学领域中，有许多的管理术语，每个术语背后的含义都是特定的，就象在软件开发中有许多特定的术语一样，一说“软件”，就理所当然的要包括“程序、数据和文档”，在项目管理领域中的“计划”，其本身就涉及到了项目管理各个知识领域的全部内容，而“时间表”只是其中的一个组成部分。这些对于专业人士来说，都是不需要解释的。
在方法论方面，管理之所以能够成为一个专业领域，就是因为在这个领域中有许多人面对着许多具有共性的问题，大家通过长期的摸索和实践，总结出一套相对来说行之有效的方法，被称为方法论，对于不同的问题有针对性的方法论，是人类知识的结晶。掌握方法论，就等于是直接站在巨人的肩膀上，直接得到了众多前人的经验教训，可以少走许多弯路。这就像我们直接利用软件工程的方法论一样，不需要我们自己重新再去摸索，可以节约大量的成本，如果是企业管理中，那么是否能够正确运用方法论，有时就直接关系到企业的生存和发展。方法论在整个社会发展过程中，所产生的影响是巨大的。
管理工具使管理理念、方法具有了更强的可操作性。管理工具主要指各类管理图表，例如各式各样的人力资源表格、货物验收检查表、质量管理表格、销售业绩统计图表、任务进度跟踪图表等，这些工具将理念、方法论更加具体化，组成结构化的工具，可以提供给更多的人使用，可以大大提高管理的工作效率。随着信息技术在管理领域中的广泛应用，现在许多这样的工具都被电子化，那么这个管理体系中的信息就可以利用电子化的手段，更加全面、综合的被管理和利用。所以很多组织都在建立管理信息系统，从组织的管理体系的角度出发，系统化地建立组织的信息模型，使各项管理工作的效率得到了进一步的提高。但这里必须明确的是，管理工具是一个广义的管理概念，而信息技术只是手段，它可以改进管理工具。
对于专业术语、专业方法和工具的学习和掌握，在各个不同的专业领域中都是一样的，一个人不论做什么事，做得是否专业，在这三方面的体现都是最直接的。针对以上这三点来说，不专业的人做事至少会带来额外的沟通成本和造成更多缺陷的可能。
组织的管理体系，实际上也是一个反馈型的控制系统。在系统控制论当中，一个典型的反馈控制系统，包括了输入、放大、输出、比较基准、反馈等部分，如下图所示：
通过这样一个系统，使得系统的输出趋向于所需目标。在管理体系当中，我们也经常说“PDCA”这样的过程，就是计划、执行、检查、纠正这四个环节，其实也是构成了一个反馈系统，计划是所期望的输出和比较基准、检查就是对输出进行采样并与比较基准进行比较，纠正就是根据发现的偏差作调节，如果是不利的偏差，就会通过提供负反馈来反向调节，如果是有利的趋势，就会通过提供正反馈来加强。总之，作为一个系统，管理体系应该是闭环的、可控的。从企业来讲，绩效管理体系就是这种控制体系的全面反映，奖惩不是绩效管理的目地，而是这个系统的调节手段。因此，管理技术，实际上是系统控制论在管理领域中的一种应用，其中也存在着大量的技术问题，需要管理者以系统化的思维方式来学习，掌握其内在的客观规律。
在管理技术中，产品管理、财务管理和项目管理属于核心内容，是需要重点学习的。在产品管理中，涉及到企业决策、新产品开发、市场营销、售后服务等整个产品生命周期中的全部管理要求；在财务管理方面，不仅是学习那些财务计算公式，更重要的是学会财务思维方式，因为财务管理中覆盖了大量的管理的概念、原则和方法，往往是企业各项管理手段和效果的集中体现，所以财物指标经常被作为各项管理中主要的绩效标准；而在项目管理中，则可以学到如何有效的组织过程实现目标，这是企业执行力的重要来源。
在强调管理技术的同时，也要认识到它的局限性，管理者的工作对象主要是人，管理体系的执行也是通过人来实现的。管理技术不适合针对人的管理问题。对于人的管理问题，属于另一类称为软技能（Soft Skill）的范畴，其中也有许多对于人的价值观、人际沟通等的研究。相对而言，管理技术也有时被称为硬技术。要做好管理，最终要能够做到硬技术和软技能的相得益彰。
总之，要成为一个合格的管理者，管理技术是基础，特别是从专业技术岗位走上领导岗位的管理者，更要认识到对管理者不同的知识结构的要求，认真学习好管理技术。
databaseadmin | 01 八月, 2006 10:28
不是每个公司都能够拿出数百万美元用于尖端科技的应用。这些公司面临的挑战是，它们需要找到一个不会耗尽其资源的大胆的，有魄力的方法来实施其IT战略。那些“100位有魄力的CIO”殊荣获得者采用的方法范围非常广泛：包括看重可实践性(比如缩小主项目的范围)、更具风险性(比如使用测试版软件)、完全地违背一般人的直觉(比如不进行预算就着手项目原型的开发)等等。通常，每个战略都伴随着一些折衷的办法，但是对这些有胆量和魄力的CIO来讲，管理好风险比支付额外的费用更为重要。
美国佐治亚州的富尔顿郡政府
目标：使该郡成为美国应用科学技术最为先进的地方政府之一
风险：依靠新兴的供应商和测试版的软件来运作
应对战略：测试、测试，再测试
当Robert Taylor被任命为富尔顿郡的CIO时，该地区的IT部门远远落后于时代，当地使用的1200个MindSpring(一个网站)的账号甚至比不上一个普通公司的E-mail系统。“我的职责是让该郡从落后状态中解脱出来，然后进入90年代，”Taylor如是说。
而当时已经是2000年八月份了。
后来，Taylor改变了富尔顿，使其变成了全美国科技含量最高的地方政府组织之一，而且这仅仅用了2400万美元。他说，关键在于与供应商建立良好关系、努力寻找决定价格的关键因素、付款计划为双方考虑，还要用节约出的小笔资金来弥补部分不足的款项。
比如，为了不使用思科公司的一个售价为30万美元的产品，Taylor使用微软公司的一个测试版的同类产品。另一个例子是，他同意为一家叫做CloudShield 的公司在软件开发的最后阶段提供帮助，以换取价格折扣。这些“没有准备好的”产品经常在富尔顿的实验室进行测试，然后先给IT部门和一些关系比较好的部门使用，最后再推广到整个郡的42个部门使用。这些做法常常能使他的团队给IT工作带来很多改进成果。
富尔顿的IT部副主管说：这些方法不会对每个潜在合作者奏效，有些供应商会说他们是一个有着严格规定的公司，所以不会讨价还价，我们就找其他同类公司，总会有公司乐意这样做的。
Taylor认为没有什么成本细小到不需要节约。他开玩笑地说道：我们节约成本的方法之一是让对方打电话过来，因为接电话不要钱。
Questar燃气公司
目标：更换一个陈旧的客户信息系统
风险：这类项目经常耗时很长且会超过预算
应对战略：组建一个有公司高层参与的团队，花1年半时间来确定项目的需求，然后再与供应商谈判
2001年，Shahab Saeed走进CEO的办公室，宣称公司当时使用的CIS系统是一个定时炸弹。这个系统已经有数十年历史，使用的技术非常落后，效果非常差。CEO关心的是这个项目可能会严重地超出预算，但是Saeed确信他能够找到合适的人来完成这个项目，并且比预算要少花两个月时间和1000万美元资金。
Questa公司的成功关键在于其谨慎小心的计划。在投入资金之前，Saeed及其团队花了一年时间来研究业内的CIS失败案例，然后利用这些教训开提出了Questar公司的整套需求。比如，他们发现大多数应用程序公司都尽量把老系统的数据放进新系统，所以当供应商说想要把三年前的有价值的历史数据放进新系统的时候，他们大声叫停，并要求供应商证明那些信息是必要的。最后证明历史超过13个月的客户信息只有1%是有价值的，折衷之后，Saeed决定把前13个月之内的数据转移到新系统中。
“每个决定都要建立在事实基础上，”他说，“如果有人说他们想要某些东西，我们可能会说，那好，向我们证明你为什么需要它吧。”
Questar公司评估了10家供应商，试图找到一个其产品与该公司的要求最匹配的供应商，然后花六个月的时间来谈判合约，其中包含了这样一个条款：Questar将不雇佣任何承包商，这个项目中的人员要么是Questar公司的人，要么是供应商的人。
2004年2月，Saeed被提升为Questar公司的一个子公司的总裁兼CEO、Questar公司的副总裁、Questar能源服务公司以及另一个子公司的COO。他说：“我对我的老板说，只有让我担任项目负责人时，我才能接受该项工作。”
CUNA Mutual Group(位于美国威斯康星州首府麦迪逊的一家金融服务公司)
目标：降低会员金融服务业务的IT成本
风险：替换一个正在运行的系统
应对战略：在定制系统没有做好之前，不要废止目前使用的CRM系统
在2003年，CUNA Mutual Group的主管业务技术的副总裁Sean Fallon再次提起针对公司的会员金融服务(MFS)系统的预算，同期，Siebel公司的 CRM系统的一项全国性展示表明该系统可以降低企业25%的IT成本，为此，大家都认为该公司的IT系统也应当达到这个水平。该项目针对的是团体客户，需要对为他们服务的CRM系统进行重新设计，并且这不能触及Siebel公司的专利权，当然也不能超过该公司产品的成本。最终，四个程序师指出需要建立一个专门的CRM系统来处理MFS服务，这个新系统需要的初期投资不超过100万美元，长远看来，它将比Siebel 的产品便宜很多。
Fallon认为该项目能成功有两个原因。第一，该团队知道，支付一大笔钱在Siebel的系统上是不合算的，将来不管是继续使用它的升级产品还是选择更好的产品，都没有开发自己拥有所有权并且有很好的投资回报率的系统好。第二，他们很快就限制了该项目的功能范围，以免开发人员陷入顺便开发一些不需要的功能的泥沼之中，这样，开发团队就避免了触及诸如客户如何与办公室联系或者公司已有的其他服务项目。总的来说，这个自产的CRM系统只有Siebel公司产品的一半内容，做起来更容易、费用更低。
“大多数项目都有一个一流的版本，” CUNA Mutual的CTO Rick Roy认为，“而很多功能不一定能用到，我们干脆就解决那些的确会发生的问题吧。”
美国ING保险公司
目标：开发一个涉及到六个国家的仓库数据模型
风险：没有单独预算，而是从其他项目抽出时间和资源
应对战略：重新使用其它项目的代码，员工乐意超时工作来完成该项目
可能没有人希望看到一个组织有着4.5亿美元的IT年预算，却全部放在一个项目下面。但是美国ING保险公司的CIO David Gutierrez却建立了一个组织文化，特别能够抵消企业中因为这种把所有鸡蛋放在一个大篮子中的做法而令人感到不舒服情绪。当Gutierrez领导团队建立一个可能需要整合涉及到六个国家的原有数据，并最终由ING保险公司来运作的仓库数据模型的时候，他要求其IT团队开发出原型，但只有一个200万美元的预算，而没有任何的专有资源。该团队只能选择这种安排，或者等上一年，从他的下一个预算中获得支持。
当接到这个项目的时候，人们第一个要问的问题就是：我们有什么资源？Gutierrez认为，并不是每件事情都需要资源，这就像发明家在自己的办公室熬夜工作一样，如果对某件事情有深深的信仰，你就会致力于这项工作，如果太关注于资源，你将会失去某种企业家精神。
程序师可以开发出其框架结构，这最终能成为仓库数据系统的基础，同时需要重新使用其他项目开发出的成果。团队成员们常常靠加班来做这个项目。“有很多的好主意在我们周围，”Gutierrez认为，“我们并不希望仅仅因为没有资金预算就让好主意溜走，所以我们鼓励人们依靠他们所拥有的任何东西来完成任务。”
databaseadmin | 01 八月, 2006 10:26
企业项目管理体系结构
企业项目管理体系，从结构层次上可以依次分为：
项目管理的总体目标和原则
项目管理中的重点关注领域
项目管理的具体流程和方法
从建立企业项目管理体系的角色分工来看，前两项由企业决策层负责，主要依据是企业的经营战略以及市场环境因素。最后一项由项目管理人员，甚至是直接受众――专业服务人员来共同制定，主要依据是企业文化，以及组织结构、人员能力等实际情况。因此，项目管理体系的前两个层次，具有通用性特点，在不同企业中具有相似，甚至是相同的层次；而第三个层次即项目管理的具体流程和方法，具有很大的灵活性，无论是制定主体（以管理层为主，还是以直接专业服务人员为主），还是最终结果上，不同的企业背景会出现很大的差异。
项目管理的总体目标和原则
企业项目管理的理念，集中体现为项目管理所要达到的目标，以及为了实现这些目标而采取的一系列原则。目标和原则是企业项目管理体系的基石，由企业的决策层来制定，其依据主要是企业的经营战略，以及市场环境因素。前者决定了项目管理目标和原则中的“静态”部分，而后者决定了“动态”部分。企业的经营战略是稳定的，也是任何企业活动都必须围绕的核心，项目管理也不例外；同时，市场环境是频繁变动的，企业项目管理的目标和原则应该保留对这种变动的适应能力，才能真正符合市场竞争环境。
项目管理（软件服务行业）的目标一般包括如下一些：
如期完成项目
保证项目质量
用户需求得到确认和实现
妥善处理用户的需求变动
项目成本控制在计划之内
保持对项目进度的跟踪与控制
顺利实施系统配置管理
保证对第三方产品或服务的控制和协作
为实现上述目标，企业所采取的原则包括以下几方面：
简洁、实用管理的原则
成本效益匹配原则
充分交流与合作的原则
技术先进原则
扩展性原则
企业在开始项目之前，应该先与客户沟通，确认以上项目管理的目标和原则，并对其具体含义达成共识，如果有必要，还可以根据客户的具体情况进行适当调整。项目管理的目标和原则，是处理项目进行过程中一些重大纠纷的依据，也是项目执行和控制的立足点。
项目管理的总体目标和原则是企业项目管理建设的纲领。在此基础上，企业需要设定项目管理的主要关注领域，并将总体目标和原则体现到每一个领域。总体目标和原则，主要关注领域，组成了企业项目管理体系的框架，在这个框架中设计并运转符合企业实际的具体流程，是细化并实现企业项目管理理念的最终举措，企业的项目管理体系也正是这样层层相扣的有机结构。
作为专注于软件服务的IT企业，在制定项目管理的总体目标和原则时，必须从战略的角度出发，认识到企业的使命和面向的用户。同时，对于自身专业服务的增值过程了如指掌，只有这样，才能充分把握企业的核心竞争力和利润来源，从宏观的角度来掌控一切项目管理活动。
databaseadmin | 01 八月, 2006 10:15
虽然没有一个单独的内容会比其他的更加重要，但是开始研究这些理念的一个合理的出发点就是个人掌控这个概念。Mastery这个词起源于梵语之中的mah一词，意思是更大的。Mah还是法语中maitre一词的根源，maitre的意思是精通的或是高度熟练的。对于优秀的项目经理来说，个人掌控这一概念可以被理解为一种自我知识的组合，丰富的技能的培养和完善和个人为支持其他人的成长所做出的承诺。
开展个人的SWOT回顾
我们的出发点是自我知识。因此以一个SWOT回顾开始也是有意义的。SWOT回顾是一个对我们的实力，弱点，目前的机会，对生活中什么样的情况会带来最坏的结果的判定（从专业和个人两个角度来讲）等等的评估。我们都曾经在项目工作中做过SWOT回顾，但是这一次，我们将转而关注于我们自身。
一旦你已经完成了这些（而且我所花的时间不会超过两个小时），下一步就是要问一问自己为什么要对自身的实力和弱点进行分类。一些关键性问题出现了：你到底是谁？你对自身的实力和弱点的判定的正确性有多大？
你到底是谁？
一个多年之前与我合作的CEO帮助我提出了个人掌控这一概念。他对我说，“你可以试图让我改变我的习惯和癖好，但试图让我改变我性格上的缺点则是浪费时间。”我们都懂得这个意思，而且不会说出那些令人厌烦的话，但是我们不能从根本上改变我们自己。从一个优秀的项目经理的角度来讲，这一点事实是被完全接受的。毕竟，优秀的含义之中一个关键的内容就是在现实情况的基础之上实现回报的最大化的能力。优秀的项目经理知道他们自身并不完美，而且他团队之中的成员也并不完美，但是他们知道每一个人都有能力做出有效的贡献。
优秀的项目经理所具有的最重要的技能之一就是接受确定的事实并改变那些易变因素的能力，它是所有的风险管理的基础，也是事务管理的秘密所在。允许项目经理挑选合适的人选作为项目团队的成员是一个基础。
评估实力和弱点
那么你是如何分辨出个性特点或性格的缺点和一个简单的可以被弥补的弱点之间的差别呢？个性的资料是一个很好的出发点。Myers-Briggs，social styles和enneagram中都介绍了有关人们的个性因素这方面的内容。
Myers-Briggs性格学将一个人说成是四对特性的组合：外向的/内向的，直觉的/理性的，思考的/感觉的，还有判断的/感知的。Social styles的模型将人们与他人合作的方式划分为四种类型：驱动型，表现型，亲切型和分析型。而enneagram为性格设计出一个具有八种类型的复杂模型。
对于“我是谁？”和“我的实力和弱点是什么？”这些问题，上面这些模型没有一个可以作为完美的答案。但是这样的模型可以让我们洞察到一些我们先天擅长的地方和我们还需要在什么地方不时地做出一些努力。
我的经历之中有一个例子，来自于几年之前我所教授的一堂课。那时我在解释Myers-Briggs性格学，一个学生后来找到我说，“你是一个思考者，课堂里的大多数人也都是思考者，但我是一个感受者，而且你讲的话我听不懂，用了太多的头脑却没有用心。”从个人掌控的意义上讲，他所说的意思是我有一种能力叫做思考/直觉，这种能力使我可以将无形的“知晓”转化为明确的语言文字和概念，但是我还有一个空白需要弥补：将这些知晓与那些不仅仅是想听一次知识讲座的人进行沟通。
项目内容
在软件和NPD项目管理的世界之中，优秀的项目经理的周围通常是INT—内向而直觉的思考者。在课堂之中我所面对的沟通难题就是一个外向者（大多数是非技术性的项目经理）与一个内向者的沟通。如果我们在这里假定我们都是思考者（而不是感受者），那么对外向者的最佳定义就是需要外部反馈来表明他们的想法的人。另一方面，内向者则接受外部的数据并通过将其与自己的内部过程进行衡量比较来表明想法。
在项目工作中，这个差别意味着会议是一个完美的工具，让那些外向者解决问题，而且会议可以作为一个论坛，让内向者可以传达他们的想法。但问题是内向者和外向者自身对会议的需要有着不同的节奏而且对于在会议上要完成的工作有着不同的目标。
了解了外向者和内向者之间的差异，优秀的项目经理就不用再为项目团队拿出一个一刀切的解决方案了。功能性团队（通常是一组外向者）可以按照他们的意愿安排任意多的会议来解决问题，而开发团队成员则可以坐在他们的办公间里，当需要的时候再进行合作。而两个团队都需要出席的会议（例如状况会议等）则可以以一种中层目标进行开展。较低的会议频率或是较短的时间和制定明确的会议日程确实可以使两个团队都感到满意。
这种会议讨论的关键就是一个力度问题，而且问题所在可以成为同一枚硬币的正反两面，基于外部环境的情况将会被最大化或是最小化。在某个工程建筑公司工作的一位高级副总裁在一次会议上带给我这样的信息，当时他对项目经理建议要在团队成员之中加入一个“模糊思考者”以确保成功。从Myers-Briggs的角度来讲，这里的意思就是“确保你的团队成员之中至少有一个NP（直觉/感知型）类型的人，而不能像通常那样全都是SJ（理性/判断型）类型的人。”
由于软件项目之中NP类型的人经常会过剩，因此我意识到他的建议是在项目中安置至少一个或多个人来弥补所有的团队天生的空白。在软件项目中，通常的做法就是确保有一个QA人员（经常是SJ类型），他的工作涉及到整个项目过程，并且能够提出他们自己独特的观点。
对机会和威胁的评估
SWOT分析之中的第二部分涉及到对我们面对的机会和威胁的分析。对于优秀的项目经理来说，机会被定义为一种具有成功的可能性的工作环境。而威胁则定义为一种个人失败可能无法避免的项目。目前在我们的社区流传的一个说法指出，一个好的项目经理可以管理任何类型的项目。对于优秀的项目经理来讲，这样的说法是错误的，即使仅仅是从字面意义上讲。
例如，我发现当消极因素使得项目局面处于绝境时，我有很大的可能性使得这种快速而关键的项目获得成功。我通常在最后站出来帮助即将失败的项目扭转局面，或是将那些僵而不死的项目解决掉。一些杰出的项目经理可以管理那些长达三年时间的项目，项目工作的计划令人难以置信的复杂，团队成员的编号数以百计。个人掌控之中的一个关键内容就是要具有认可自身优秀之处的智慧，并且理解经常会有时候别人可以比我们做得更好。
个人掌控的理念需要我们去看一看自身优秀的地方，将我们在适当的环境中分享这些技能的机会最大化。它还要求我们诚实地对待自身的僵化问题（正如鱼离开水的情形）和弱点，然后我们就要避免这些问题并开发解决办法来减轻影响。
对于个人掌控的讨论完全地避免了关注于诸如如何建构一个更好的风险计划或是完善一个更加精确的进度安排等这样的事务，这对于每个人来说都应该是显而易见的。个人掌控确实包括对技能的培养，但发展这些技能的秘诀在于具有自我知识，确认什么样的技能能够自然地使你成为优秀的项目经理，需要有什么样的技能来弥补项目工作的空白。
让它成为可能
个人掌控并不是一夜之间就能完成的事，但通过致力于开展一个个人的SWOT回顾并花时间研究一下关于自我描述的知识（Myers-Briggs，social styles和enneagram），同时还要依靠于健全合理的PM实践工作，例如读一本与项目管理有关的刊物，开展个人的项目后期调查，就可以让发展个人掌控成为优秀的项目经理的第二天性。
databaseadmin | 18 七月, 2006 10:22
databaseadmin | 17 七月, 2006 22:41
databaseadmin | 17 七月, 2006 22:39
databaseadmin | 17 七月, 2006 22:37
databaseadmin | 17 七月, 2006 22:36
| « | 五月 2012 | » | ||||
|---|---|---|---|---|---|---|
| 一 | 二 | 三 | 四 | 五 | 六 | 日 |
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 | |||