项目问题

需求

  由于客户（需求方）IT知识缺乏，一开始自己也不知道要开发什么样的系统，或者懒于系统地整理出来，经常是走一步算一步，不断地提出和更改需求，使得实现方叫苦连天。

    另一方面，实现方由于行业知识的缺乏和设计人员水平的低下，不能完全理解客户的需求说明，而又没有加以严格的确认，经常是以想当然的方法进行系统设计，结果是推倒重来。因此，需求分析必须注重双方理解和认识的一致，逐项逐条地进行确认！

       与客户确认在不会变动的节点，梳理所有不变动的节点确定开发流程与业务环节，制定《工时计划》、《节点上线计划》将《节点上线计划》给客户并且在每个节点开发完成，测试通过之后发送给客户，已让客户及早知道项目进度与能让客户看到实际产品想的更明白，敲定版本与开发时间。客户需要变动开发内容，安排在下个开发周期中，小的文字图片修改1小时内的帮助解决。

    

工数估算

    软件开发的工数估算是一项很重要的工作，必须综合开发的阶段、人员的生产率、工作的复杂程度、历史经验等因素，将一些定性的内容定量化。对工数的重要性认识不足，经常用拍脑袋的方式草算，是最常见的问题。还有，软件开发经常会出现一些平时不可见的工作量，如人员的培训时间、各个开发阶段的评审时间等，经验不足的项目经理经常会遗漏。同时，还有如下一些原因也是很典型的：

   1. 出于客户和公司上层的压力在工数估算上予以妥协。例如，客户威胁要用工数更少的开发商，公司因经营困难必须削减费用、缩短工期，最后只能妥协，寄希望于员工加班。  

          给组员一个团队口号，早做完早下班，并且调休或加班工资不可避免另需要申请奖金与部门经费

    2. 开发者过于自信或出于自尊心问题，对一些技术问题不够重视，或者担心估算多被嘲笑。  

          开发时间+测试时间+需求讨论时间+修改bug时间

    3. 过分凭经验。由于有过去的成功经验，没有具体分析就认为这次项目估计也差不多，而没有想到这次项目可能规模更大、项目组成员更多、素质各异、新员工很多，而且是一个新的行业。  

          新员工、新行业试水几周在制定详细计划

   4.人员请假、离职(及时调整计划并上报)

       遇到离职情况因立即对工作计划进行调整，做出该人员离职对于项目进度的影响度，增加任务时间，由于 离职人员的业务、代码风格迥异，另一个员工需要熟悉，增加的时间不应该是原来人员的时间，需要添加上接手人员熟悉时间。

       请假情况出现，应该看看项目进度是否能如期上线，并且查看该员工工作效率与工作积极性

   5. 项目边开发，边添加人员

       进入之前对于项目不做调整，1周熟悉流程，2周生成能力，第3周做出工作计划变动.第2周随着项目的复杂度增加。

工作进度评估

工作质量评估

     因人而异，团队中会出现，细心与粗心的开发人员，对于细心的开发人员可以采取定期抽检，粗心必须安排一个跟进角色，尽可能短的时间审核一次。在节点上线的时候必须确保功能的质量。

项目风险

      新技术的引入

    人员变动

   

软件维护

在维护期间，除了纠错性维护外，客户可能提出需求变更（但是不支付费用），维护人员对客户妥协，导致维护工作量增大、成本增加。

如果是合同项目，用户对开发方依赖性比较大，不愿意自己解决粗浅的问题，经常叫开发方“干这干那”。开放不敢得罪客户，导致开放方做了许多不属于维护的工作，哑巴吃亏。

开发人员一边开发新项目，一边维护老项目。而维护体现不了业绩，有影响了新项目进度，开发人员容易心烦。

建议：指定软件维护规范，界定什么是免费维护，什么是有偿维护，以及相应的操作规则，提高维护效率并且降低维护成本。