会员登录
会员注册对于短期的Web小型项目， 无论是开发周期、成本，还是技术上都有很大的风险。然而许多人对此认识不足， 导致项目失败，或是产品发布日期一拖再拖、成本大幅上升，或是匆忙发布后漏洞百出。 本文从项目管理的角度说明，即使在小型项目中，项目经理也不能将项目全权委托给技术主管， 而应当建立合适的体制，从几个方面对项目进行控制，这样才能保证项目的顺利进行。
通常的项目体制不适合短期开发
在大型机上花费几年的时间构建大型系统时，项目经理通常仅负责一个项目， 手下也聚集着许多软件工程师。在需求定义阶段，项目经理直接与客户进行交涉， 在需求定义中发挥着领导的作用。
这种体制本来十分理想，但对于开发期间只有几周到几个月的小型Web系统来说， 却不尽人意。团队的实际情况是，项目经理和技术主管通常会兼任数个项目， 设计、编码的工作全部交给年轻的工程师或合作方的工程师们。 这时，项目经理的一部分职责通常会交给技术主管分担。
职责、分工不明确
开发Web系统时，客户企业经常会要求使用EJB、XML、Web Service等较新的技术。 项目经理为了满足客户企业在技术上的要求，不得不依赖于技术主管。 另外，项目经理通常要照看多个项目，因此与之相比，技术主管接触客户的机会更多一些。
这样，在Web开发中技术主管的职责范围变得非常广泛。因此，项目经理和技术主管的 职责分工很容易变得模糊不清。绝大多数情况下，职责分工问题不仅没能形成书面文档， 甚至连简单的协议都做不到。极端的例子就是“除了钱的问题，其他全部委托给技术主管”。
这种现象并不鲜见，但是在大规模项目中，通常会有足够多的时间和人力来规避风险， 因此即使发生问题，也总有办法解决掉。但是小规模、短期的Web项目中，由于职责分工不明确 而导致项目内部的意见不一、决策效率低下等，是项目失败的直接原因。
项目经理无法掌握项目的状况
让我们具体地看一看，在项目最重要的任务之一——需求定义中，职责分工不明确会造成怎样的问题。
在Web系统开发中，客户企业经常会在开发途中增加、改变需求，因此完整的需求在项目初期很难确定。 再加上项目经理要兼任多个项目，无暇顾及每个项目的需求定义，只得将其全权委托给技术主管。
这种条件下，技术主管仅从技术的观点来接受客户的要求，导致项目超过预算、超过预定工期的可能性非常大。 另外，项目经理无法详细把握需求定义，因此无法把握项目的状况，导致项目的范围失控。 最终结果必然是，当问题的征兆出现时，根本无法采取任何对策，如与客户交涉“先实现优先的功能，其他无关紧要的功能下次再实现”等。
想象一下，技术主管完全根据自己的判断来回答客户企业的重要问题时会出现什么后果。 项目经理和技术主管的意见一致时尚可，意见不一致时，必然会招致客户的混乱。 此外，项目经理对技术主管过于依赖，会导致不好的结果。例如，带着“他会做好的”、 “这件事儿是他的责任”的想法，通过邮件给技术主管分配任务，其结果通常是该做的事情 没人负责。
建立职责分工的规则
为避免这样的问题，项目经理和技术主管必须事先决定职责分工。那么应当如何分工呢? 不同的项目千差万别，所以并不存在万能的灵药。应当综合各种方法，并结合项目的实际来决定。 以此为前提，首先应当制定职责分工的规则。具体来说，要制定以下的规则。
(1) 在需求定义结束之前，实现哪些功能、采用什么开发工具、安全实现到什么程度、 如何应对繁忙时的业务量等，这些关系到系统需求的重要事项必须由项目经理和技术主管协商决定。
(2) 在设计阶段之后，不影响进度、人员计划的功能追加、修改等项目范围内的事项， 首先由技术主管做出判断，交由项目经理确认之后再做决定。可能会导致合同变动的项目范围外的事项， 技术主管应当将判断权交给项目经理。用这种规则，就能回避职责不明确导致的混乱。
共同制作业务场景
同时，也应当建立项目经理和技术主管共享信息的方法。这里，我们以需求定义阶段 项目经理和技术主管合作制作“业务场景”的方法为例进行介绍。
新业务的场景，即根据客户询问、头脑风暴、JAD、原型、现有业务资料调查等方式获得的信息， 来描述新系统的样子的东西。
业务场景可以用讲故事的方式写成，附以图表就更完美了。也可以开发一套能实际运行的原型系统。 制作业务场景的过程中要不断与客户确认，以此为基础来确定详细的系统需求。
场景制作的材料可以完全委托给团队成员，但场景本身必须由项目经理和技术主管协同客户方负责人一起制作。 项目经理和技术主管经过不断的交涉，提炼材料，从开发的角度看哪些重要，现行系统的哪一部分在新系统中如何变化等， 这些问题项目经理和技术主管都要充分认识。这样，两者才能获得一致的意见。
技术主管通过制作业务场景来获得与项目经理一致的意见，在确定需求时才能更容易地获得客户的新人。 另一方面，项目经理也有充分的自信能够“完美地控制项目”。当然，场景的详细程度需按照项目来定。