我的项目笔记

正文:

我的项目笔记

我的项目笔记(1)--角色转变

经过近两周的忙碌,项目总算步入正规了!从项目立项,资源管理计划,风险跟踪,概要评审,工作量评估,资源协调,争议项跟踪,决策,分配任务,执行,进度跟踪等等,彻底的完成了从一个程序员到一个项目管理者的转变,第一感觉是,偶从原来的代码编写者,成了文档编写者。呵呵!!不同的角色承担者完全不同的工作内容,原来单一的工作变的烦杂而凌乱,但你又必须去理顺这一切,至少在项目组内这是你的本职工作,整个项目的事务要靠你去处理和推动。

一个程序员和一个项目经理工作的不同。

1、程序员每周只需开项目组例会即可,涉及本项目组的各种评审会。

项目经理每周要开资源部门(IPD)例会,大项目例会,整个产品线的项目例会,组织本项目组项目例会;项目总体规划评审,总体设计评审,跨项目组评审,争议项协调会,组织本项目组各种评审及相关评审。

2、程序员只需关注自己任务的按计划完成即可。

项目经理要制定整个项目的进度计划;关注跟踪项目组每个成员单个项目任务进度;进度延迟跟踪处理;技术决议;争议项确认讨论决议;跨项目进度协调;风险预防和处理。

3、程序员的压力在于项目任务能否按时达成,压力通常在于进度和技术。

项目经理的压力在项目目标达成,压力在工作量,时间,人力的平衡,通常都是人力和时间紧张;同时存在目标变更,资源突变,人员能力限制等诸多问题,项目间带来的问题也是很大风险。

4、程序员除了完成自己的任务,只需提高个人能力即可。

项目经理除了要达成项目目标,除个人能力提升,整个团队成员的技术能力,沟通能力,工作素养,职业发展,都需要在项目过程中培养和提高。

从员工到项目经理的转变,主要是工作角色,工作性质,工作内容,工作范围,工作目标,工组责任发生了变化,但不管怎样,项目经理坚持编码还是很重要,只有这样才可能将一切掌握在可控制范围内。项目进行了将近一个月了,在这段时间产生很多问题主要涉及以下几个方面:

需求本身冲突,需求文档出现不一致状况。

需求和设计开发的冲突,主要是展现形式和技术实现的冲突

跨项目组维护同一工程之代码和脚本冲突

项目组间协调冲突

基础系统和业务系统冲突

下面就各种冲突的表现和最终解决方案做简单的描述和概括:

1.需求冲突:

需求冲突主要表现为项目组内需求不一致,总体需求和单个需求不一致,组间需求不一致。

对于项目组内的需求不一致主要是不同的需求人员对同一类业务展现方式的理解不一致造成的,如树的应用范围,树的展现方式,查询界面布局,分配界面的操作等问题,这些问题在审阅单个需求文档是很难发现,但在抽取统一的应用需求,做设计时就被发觉出来。此时要求需求项目组统一规定所有类似应用场景的操作模式,展现方法,达到整个产品的统一性。走需求变更流程。

对于总体需求和单个需求不一致,主要表现为单个需求违反或者没有遵守总体需求的统一要求,此类问题通常在项目间会议交流过程中发现,此时就要求需求人员修改需求。走需求变更流程。

组间需求不一致的表现为,在不同的项目组可能实现同一业务,出现两者之间均描述需求,或者两者直接均没有此需求描述,这时就要有发现人召集两边开发项目经理和需求项目经理协调,确认该功能点的负责方。确认后,需求修改走变更。

2.需求和设计开发的冲突

主要表现为需求和技术实现上的冲突,进一步分为两类:一、需求要求的东西不能实现,此类需求通常打回修改需求,二、需求要求的东西可以实现,但技术风险大,沟通后下版本在处理,当然本次版本设计时会考虑扩展。

3.跨项目的维护冲突

历史工程由于项目重组后,出现多个项目组维护统一子代码工程和数据库脚本的问题,虽然使用了cvs和VSS等版本管理工具,仍然会出现代码被相互覆盖、错误提交等问题,错误排查时造成责任不清。对于此类子工程需确立主要负责人,出现问题即为第一责任人,尤其负责排查,相关项目组义务协助,相关人员必须高优先级解决,直至问题Over。

4.项目组间协调的冲突

主要表现为功能界定不清晰,接口定义模糊,责任不清,很大程度是需求和规划人员本身界定不清晰延续下来的问题。这类问题发现一个跟踪一个,明确责任。

5.基础系统和业务系统冲突

表现为也些功能是有基础系统做还是业务系统做?是有框架实现还是项目组自己实现?通常是由于业务系统的扩展,原来的框架和体系不能满足业务的需求造成的,最合理的办法是扩展框架和基础系统支持,但最常用的办法却是业务系统先自己实现,框架和基础下版本支持(这是一个现在还没有找到很好解决的问题,即,服务系统可能落户于客户系统的需求)。

另外还有,架构设计与概要设计、详细设计边界界定的问题,目前交叉区域比较大。

(在第一篇笔记中有兄弟提出不喜欢条条框框的列举,不知道这样会不会好一些)工作量、资源、时间作为项目的三个要素永远与每一个项目交织在一起,每个PM都为此绞尽脑汁,费尽心智。

在开始之前有必要讲一下项目的基本状况和客观条件:

基本状况:项目预计为68工作日,由于前期工作产生的一些问题(项目组不可控因素),实际开始设计开发时间只有35人天,工作量评估约为451人天,实际人力6人(含PM),一名系统设计人员,四名开发人员,其中两人为新入职员工,三人为仅毕业一年的员工,大项目经验不足。实际人力=1(设计)+2*1(开发)+2×0.5(新员工按照0.5人力计算)+0.5(PM按照0.5计算)=4.5人,实际可完成工作量=35×4.5=157.1。

客观条件:工作量不可砍,发版日期不能推迟。

451/157.1=3~,呵呵,几乎三倍的工作量,NND,当看到这些数字和要求的时候,终于知道以前开发的时候为什么天天加班了!心里直骂娘啊,这不是哪我们程序员当机器用么!?中国的每一个PM几乎都是有开发人员转过来的,都明白开发的辛苦和艰辛,每天按时下班是我们每一个人的梦想。是的,也是我第一次做PM对项目的要求,追求目标!工作不应该毁掉生活,程序员8小时外的生活也本应该丰富多彩,而不是白天顶着烈日晚上披着星辰,回家到头就睡,拔开眼镜就要上班。。。。

在工作量,时间都不可变的情况下唯一可以改变的就是添加人力了,于是和老大磨了很长时间,老大终于开口说中期加入两个有效人力,不过从目前实际状况,希望渺茫啊。俗话说,靠天靠地不如靠自己,在外界无法帮助的状况下只有靠我们,那么工作时间不能延长、还要求同样的时间出三倍的活,那么只能从效率上改善。为了提高效率采取以下措施:

1.奖金的额度按照实际完成的预估工作量计算(估算工作量经过专家评审),也就是说完成的越多奖金就越多,从制度上体现多劳多得。

2.每次分配任务时和实际执行人协商完成日期,而不是按照估算得工作人天分派,和执行人将任务细分到每天,并且每日下班前检查进度偏差,找出原因,调整计划。从目前状况看,还是非常乐观的。。。

3.每个任务提供设计和技术上完全支持,在开发人员层面清除所有技术风险,保证进度。

4.创造项目组成员间的工作热情,对于提前完成者,给予表扬,并记入项目关键事件,在最终考核时考虑加分。

5.PM一身作则,身体力行,为项目组成员创造解决所有问题的条件。

6.明确我们的共同目标,制定可行计划(记住不是理想计划),不加班,按时发版,只要按照我们的计划,我们确实可以达成,那不是空中楼阁。

7.和成员之间多做工作外的交流,在项目组中间形成兄弟情谊的氛围,团队核心精神得到真正的体现。

Our Team`s dream must be realized!

----------------------------------------




-=[看新闻]=-
-=[看好文]=-