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

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

　　项目进行过程中遭遇到的直接影响到进度的技术问题不妨称之为技术卡点。如果项目进行前对技术卡点没有全部认识到，或认识有误，带来的后果是严重的。首先是打乱了项目计划(全局的或阶段的)，然后是会使公司、上级怀疑你的能力及职业忠诚度问题(他们可能认为你是在故意制造事件、拖延怠工、养患自重…)，会使你在各种明暗竞争中处于被动地位，甚至直接危及你管理的项目。当然，如果你确实感到能力不济，也要坦然承认。

　　在一个自动控制系统中，项目经理采用了一种新型的PLC控制器。他看了控制器的一些技术资料，觉得与他以前用过的控制器基本相近，于是他排好了计划，带领组员做好了设计，开始编程实现。相当部分的程序编好了，但他的组员遇到一个问题：控制器对时钟的处理方式与他们设计时理解的不同。设计时他们认为控制器的时钟是通过中断处理的，是不断运转不受程序影响的。而实际中发现该控制器的时钟是无中断处理的(无中断控制器触发)，时钟前进是在每一次程序循环的结尾才由系统扫描处理。如果在同一个程序循环中设置了时钟初值又去判断时间差的话，永远得不到等待的差值，而且要使时钟比较精确，每一循环执行的程序必须尽量简短。而时钟在自动控制系统中极为重要(如延时、定时、关联设备的次序控制等)。这一细节性的技术问题，使项目组不得不重新设计，从头再来。

　　在一个大型的应用系统中，应用数据的组织非常复杂，大部分用户需求也迟迟不能明确，你为了及早进入开发，并减少以后其他需求明确时带来的影响，于是计划采用将部分对象移到数据库一端的设计方式(一般对象都放在程序一端，数据库主要作数据存储)，这种方式可以通过数据库对象的调整来适应需求变化及数据结构的变化，减少已完成程序的修改。在此中，你采用的数据库是否支持会话标识，是否能透明地存储/获取会话数据，对你的设计将有比较大的影响，因为它对今后的优化数据获取方式、转换慢速视图等都是非常重要的。你需要通过实际编写例子去确证。

　　能否准确地意识到项目中的关键技术细节，与项目经理的知识范围、经验直接相关。项目经理要虚心，多听取各个方面及组员的意见，并要多查阅相关资料。清楚地了解项目中存在的关键技术细节，对项目经理来说是需要的，项目经理才能科学地制定计划、组织人员、把握方向/整体进度、正确评价组员业绩等等。

　　项目经理要善于从复杂的技术问题中抽象出模型来，这样才能及早发现项目中隐藏的技术卡点。将主要干线流程列出，模拟前进走一遍，将每一步都较详细地写出来，然后召集组员对照模拟步骤思考/讨论，能发现大部分的关键技术细节问题。仅在头脑中思考，人们很容易将多个步骤的条件混淆起来，而不大能感觉到其中的问题;将模拟步骤写出来，每一步的当前环境、条件都比较清楚，人们能更容易地觉察出一个步骤中某些细微条件的不足，而能更好地发现关键技术细节。

　　结语

　　对于项目规模，一般是从该项目参与人数、计划时间长短来衡量的。同样的项目，由不同的项目经理来领导、来看待，其规模会有所不同。如开发一个关系型数据库系统，一个公司可能会计划投入一百以上的程序员，花几年的时间。这时，它是一个大规模项目。另一个公司来做同样的项目，因为该公司人才杰出，可能计划投入十以下的人员，两年的时间。这时，它是一个中等规模的项目。两个公司实施项目的结果可能是相同的，比如都取得同等标准的成功。

　　项目规模越大，所设管理层次可能越多。无论管理层次如何设置，对其中任一层的管理者来说，其工作机制是类似的：接受上层管理者的领导，管理好直属下层人员的工作。管理控制观念强的管理者可能参与管理隶属下面两层或更多层的人员。本文所述项目经理主要针对国内极典型的一种项目管理形式：一个项目经理，配置一个项目团队，由项目经理自行决定项目人员的实际管理层次、组织方式。

上一页  [1] [2] [3] [4]