要了解组员对某些具体技术掌握的深度、大脑中积累的技巧、判断能力等方面的情况时，需要采取一些测试技术才能获得。因为被明显测试常常为人们所不愿意，也易产生不正确的答卷，所以项目经理要认真设计测试方案。可以给组员布置一些小的带测试目的的任务（告诉他们这是项目工作的一部分），从他们对任务完成的态度、效率、结果来了解他们；可以特意给某些组员安排一些与他们水平/能力相距极大的任务，他们因为光凭自己能力很难完成，一般都会找同事寻求帮助，从他们帮助与被帮助的过程、事件中，能对他们得出很多新的认知。只有比较正确地了解了组员的水平/能力，项目经理的组织方式、工作计划才能制定得合理，才能保证项目实际进展过程符合预期。

对组员的水平/能力有了较准确地认识后，项目进行过程中有可能还会碰到一些难于处理的问题：有些组员保留自己的经验、能力，不肯充分发挥。产生的原因是多方面的，如存在心理不平衡感、持有一种歪曲的竞争意识、个人的情感因素、公司在管理/待遇方面存在明显不公平的地方、项目管理方式上有一些缺陷等。项目经理要发现问题的症结，能通过项目内手段处理好地自然好办，通过项目内手段处理不了的，需要与上级沟通寻求办法，如前述方式均无助，你可能不得不重新考虑项目的组织方式，重新设计计划。这样的情况有时在项目计划前也能发现，如你从组员的态度、工作中的精神表现能发现它们。
项目内手段有很多。与组员进行深入地交流，化解他们思想上的障结/包袱；利用表扬/批评、奖励/惩罚等方式也能起到较好地作用，能给组员带来成感、荣誉感、耻辱感、失落感等，这些精神感觉/刺激如运用得当，能强化组员的效率、提高创造性、主动性、责任性。如果组员都自觉努力，发挥效率大于90%，采取宽松的任务管理方式能获得好的效果；如果组员有一些不佳情况（行为上的/精神上的），发挥效率降到了90%以下，可以采取定期写工作总结的方式，如月工作报告，周工作报告，这种定期报告能促使组员不断审视自己的工作效率和工作业绩，从而注意保持或提高工作效率/工作量；如果组员效率降到了70%以下，你可以要求组员写工作日志，促使其注意保持每日的工作量，不同的组员可以作不同的要求，因为对一个非常自励的组员来说，过于频繁/严格的工作要求，会降低他的工作效率、抑制其创造性和主动性。假如组员的发挥效率降到了60%以下，那你采取直接指定每日具体工作内容的方式进行管理，如制定日工作表格，日工作表格中计划安排了组员当日应完成的具体工作，每日下班前验收其工作成果，这种方式是一种严格的保证工作效率的方式，但它要付出较大地管理成本，如制定具体的日工作内容及检查工作的实施/完成是一个较繁重的工作，日工作计划会被频繁调整，有时还会感到无法拟订具体的工作内容（软件开发中经常如此）。

技术——准确把握项目的风险

对软件项目来说，项目进展过程也是不断解决技术问题的过程。项目中包含的技术难点可能大部分已被明显地描述出来，对这些技术问题人们都能理解要安排的资源及准备付出的成本；有一些技术难点并非一开始能描述清楚，它们需要在项目进行到一定地步后，才能看清楚；还有些技术问题普通人不能发现，只有那些经验丰富、水平较高的技术人员才能感觉到。

项目进行过程中遭遇到的直接影响到进度的技术问题不妨称之为技术卡点。如果项目进行前对技术卡点没有全部认识到，或认识有误，带来的后果是严重的。首先是打乱了项目计划（全局的或阶段的），然后是会使公司、上级怀疑你的能力及职业忠诚度问题（他们可能认为你是在故意制造事件、拖延怠工、养患自重…），会使你在各种明暗竞争中处于被动地位，甚至直接危及你管理的项目。当然，如果你确实感到能力不济，也要坦然承认。
在一个自动控制系统中，项目经理采用了一种新型的PLC控制器。他看了控制器的一些技术资料，觉得与他以前用过的控制器基本相近，于是他排好了计划，带领组员做好了设计，开始编程实现。相当部分的程序编好了，但他的组员遇到一个问题：控制器对时钟的处理方式与他们设计时理解的不同。设计时他们认为控制器的时钟是通过中断处理的，是不断运转不受程序影响的。而实际中发现该控制器的时钟是无中断处理的（无中断控制器触发），时钟前进是在每一次程序循环的结尾才由系统扫描处理。如果在同一个程序循环中设置了时钟初值又去判断时间差的话，永远得不到等待的差值，而且要使时钟比较精确，每一循环执行的程序必须尽量简短。而时钟在自动控制系统中极为重要（如延时、定时、关联设备的次序控制等）。这一细节性的技术问题，使项目组不得不重新设计，从头再来。
在一个大型的应用系统中，应用数据的组织非常复杂，大部分用户需求也迟迟不能明确，你为了及早进入开发，并减少以后其他需求明确时带来的影响，于是计划采用将部分对象移到数据库一端的设计方式（一般对象都放在程序一端，数据库主要作数据存储），这种方式可以通过数据库对象的调整来适应需求变化及数据结构的变化，减少已完成程序的修改。在此中，你采用的数据库是否支持会话标识，是否能透明地存储/获取会话数据，对你的设计将有比较大的影响，因为它对今后的优化数据获取方式、转换慢速视图等都是非常重要的。你需要通过实际编写例子去确证。

能否准确地意识到项目中的关键技术细节，与项目经理的知识范围、经验直接相关。项目经理要虚心，多听取各个方面及组员的意见，并要多查阅相关资料。清楚地了解项目中存在的关键技术细节，对项目经理来说是需要的，项目经理才能科学地制定计划、组织人员、把握方向/整体进度、正确评价组员业绩等等。
项目经理要善于从复杂的技术问题中抽象出模型来，这样才能及早发现项目中隐藏的技术卡点。将主要干线流程列出，模拟前进走一遍，将每一步都较详细地写出来，然后召集组员对照模拟步骤思考/讨论，能发现大部分的关键技术细节问题。仅在头脑中思考，人们很容易将多个步骤的条件混淆起来，而不大能感觉到其中的问题；将模拟步骤写出来，每一步的当前环境、条件都比较清楚，人们能更容易地觉察出一个步骤中某些细微条件的不足，而能更好地发现关键技术细节。

结语

对于项目规模，一般是从该项目参与人数、计划时间长短来衡量的。同样的项目，由不同的项目经理来领导、来看待，其规模会有所不同。如开发一个关系型数据库系统，一个公司可能会计划投入一百以上的程序员，花几年的时间。这时，它是一个大规模项目。另一个公司来做同样的项目，因为该公司人才杰出，可能计划投入十以下的人员，两年的时间。这时，它是一个中等规模的项目。两个公司实施项目的结果可能是相同的，比如都取得同等标准的成功。
项目规模越大，所设管理层次可能越多。无论管理层次如何设置，对其中任一层的管理者来说，其工作机制是类似的：接受上层管理者的领导，管理好直属下层人员的工作。管理控制观念强的管理者可能参与管理隶属下面两层或更多层的人员。本文所述项目经理主要针对国内极典型的一种项目管理形式：一个项目经理，配置一个项目团队，由项目经理自行决定项目人员的实际管理层次、组织方式。
有时被指任为项目经理，而实际只履行着参与了解项目进展，进行概念性指导、协调一些多边联系的职能，这只是名义上的项目经理。真正意义上的项目经理是对项目负责，管理、协调项目全过程，对项目的人员、可用资金、工作内容、进度等各个方面因素进行统筹调度、合理计划，督查项目实施过程，解决项目进行中各类矛盾、确使项目成功的一种角色。
一旦被指任项目经理，对项目组来说，你具有了高的领导和决策权力。项目执行过程中，如果把握好了上级、人员、技术这三个支点，项目的成功一般是指日可待的。上级这一支点较变化莫测，有时候难处理，你需要有较好的沟通技巧和深广的胸怀；人员在你的领导之下，是一个能以精神、制度等主客观因素共同作用的支点，你管理的方式/手段都比较多；技术支点是偏重于客观的，对你的知识、经验、智慧、精神有着较高、较全面的要求。之所以将上级、人员、技术作为项目管理的三个支点，是因为：三因素的任一个与项目经理意图/目标完全相悖或完全失控，则项目必败无疑；从三因素入手，是适于概括项目中各种现象、矛盾的，是项目经理可从之出发拟订方案/措施/计划并终回归之以判断效果/结果的。