项目经验感想分享

上周参加协会的一个 项目经验分享的一个论坛，感触颇深。写下来供大家分享

1.对项目计划的制定,必须有规模的估算.
没有估算,随意制定版本发布计划是非常不科学的.而且后期也很难控制.
2.需求变更的控制.
需求变更是任何软件企业都非常头疼的事情.需求不是不能变更,而是如何做到有效的控制.HP针对需求的实例是:超过15%的需求变更,采取的策略:第一,重新和客户签订合同,重新确定开发周期.10%--15%的需求,如果是可以接受的,需要追加时间和费用.低于10%,评估后可以酌情添加.
结合不同公司的情况,产品需求对研发的变更还存在,而且研发对于需求变更的评估也总是很乐观.
3.milestone点(里程碑点)的设定.
milestone点(里程碑点)的设定一定要科学.不能太随意性.策略:有易到难;由关键到一般.即,在设定里程碑点的时候,对于关键模块开发完成,进行充分测试.采用8/2原则.即80%的时间集中在20%关键模块的设计和研发上.
结合不同公司的情况,对于关键模块的优先级排序还不是很明确.不能做到全体人员对模块关键性理解的一致.
4.沟通
项目经理最重要的职责就是和各个部门和研发人员的沟通.沟通占其总工作量的70%以上.占总工作量的80%以上.对每天产生的关键性缺陷要进行日推动.即,每天都要对产生的关键性问题进行Review.明确解决计划.
5.产品的总体规划
产品规划要做到系统性和持续性.特别是不成熟的产品,一定要注意系统性,不成熟的思路一定不能做为研发的基础.否则,很容易出现,研发针对功能一改在改的局面.无形中增加研发成本和周期.对于已经开发的功能点要有一定周期的连续性.
6.测试
测试需要注意有效性和测试效率的集合.建立对人员的量化标准.
对于产品开发周期内的阶段,测试重点有所不同.尽量做到前期测试充分.保证每一轮测试的周期.防止关键性问题到后期版本才被发现.即,前期版本发布频率要低,做到充分的测试.后期版本由于前期测试充分,问题会比较少,可以增加发布频率.

7. 研发过程数据的度量
由于公司度量目前涉及的比较少.在此不做论述.

8.针对产品和销售向客户承诺的问题,一般来讲,客户的满意度表现在:一,提交给客户的版本质量比较高,缺陷少.二,如果版本质量不高,则对客户反馈的问题能快速反应;三,产品的性能,友好性,健壮性,安全性等.而客户在前期反应最大的是产品提交的及时性:即是否能按时提交.因此,一般公司在向客户承诺提交版本的交付日期时,尽可能的给自己争取最大的余地.以保证产品研发过程中的不可控性(风险)和产品质量.

举例说明:如果产品的内部发布时间是11-3号.则市场和销售向客户承诺是不能以11-3号为日期的.因为,万一中间有一些不可控的因素发生.发布不了,岂不是把自己束束起来.同时,影响客户对公司开发能力的怀疑.即使客户不说,稍后的发布,客户也比较谨慎.

换一种思路:假设内部设定发布时间是11-3号.根据公司以往的经验,应该向后推迟10-15个工作日,即向客户承诺11月末.明智的客户一般不会挑剔,因为她并不知道你的内部发布时间是11-3号.如果我们11-3号发布的版本确实很稳定.提前5个工作日向客户提交.相信客户的满意度肯定会增加.对公司的研发实力也不会怀疑.

给自己束束,满足不了客户承诺.造成客户不满
给自己点处理不可控问题的时间.提前满足客户承诺.外松内紧.