进度安排与跟进经验和提议

1.       进度安排

以本次XX平台项目为例,3月6日从校方返回深圳后,已经整理好了客户的需求列表,但需要细化,并且产品人员还要按照产品升级的计划加入一些额外需求进来,如加强用户体验与UI效果改进等。项目的开始阶段是艰难的,进度安排遇到的主要问题如下:

l  需求仍未得到校方的签字确认,而产品人员加入产品升级的需求进一步扩散了项目范围

l  立项难,通常需求要非常明确、计划安排也精确的情况下才立项(由于绩效等各类因素的影响),这段期间通常较长(该期间进展缓慢),对于项目周期本身只有1~2个月的项目来说会拖延时间,开销较大

l  由于急于给用户计划和报告进度把时间定为4月中旬(客户当时提到4月初),当时未考虑产品升级方面需求的情况下做出的,存在无法兑现承诺的风险。

经过分析与沟通,发现部分需求分三部分:

l  是比较明确了可以简单沟通后立即进入开发,如某些显示、BUG等修改方比较固定

l  而另一些需求可能存在较为复杂的设计,如学期的支持,这一块涉及到非常多的相关联数据,需求与产品一起设计出方案与校方沟通确认后才能明确,这部分仅给出大概的工作量估算;

l  还有一些的产品升级自发提出的需求,由于已承诺了交付日期这部分按照优先级不保证全部完成;

精确的安排所有工作,工作量大,且在日后很大概率出现偏差及修改,分析以上情况后,按照明确的需求快速地制订本周和下周的工作计划,而较远日期只在较高层次(或较粗模块)做大概的估算,即采用“滚动式”日程安排。“一波还未平息,一波又来侵袭”,在整理产品提出的需求过程中,发现同一个需求点的几个子需求分散到不同的需求项中,这时日程活动需要将相关的需求点进行整理,容易漏掉某些需求点,测试用例也将很分散。立即与产品沟通,需求的整理做好“高内聚”工作,把相关的功能尽可能的归到一起,方便与日程活动一致,如一个选课相关的方式变化、查询选项增加、UI修改三项工作关联度高应归为一个需求或一个需求下的几个子需求。另外我也提议立项可以依据情况尽早进行(立项后将被关注接收更多监控),而立项可以不要求给出精确的每个阶段时间范围,简化后续变更过程,鼓励主动承认延期责任者。

 

2.       进度跟进

好的日程安排如果没有跟进执行,也是“空中楼阁”,所以必须实际落地做实。当前情况是:

l  有人员将要离职,意味着工作状态可能存在不能完全投入风险,另外还存在很多交接工作和其它潜在的影响

l  有2位新进入员工,他们需要融入到团队中,熟悉业务、开发框架等,有一段“震荡期”

l  每个员工的工作积极性、责任心、技术水平存在较大差异

l  工作过程中涉及到的交互多,如一个需求开发可能需要WEB前端、UI、UED的配合

征对以上情况,首先采用了证明较有效的方式是每日5分钟左右非正式的讨论晨会,简单地报告和讨论进展与遇到的问题,既能加强成员的参入度,对进度不正常的组员无形中施加了潜在的紧迫感(如某个员工报告工作未完成而其他成员进度正常时),对正常的进行表扬等。

另外更重要的是单独的跟进工作,通常会采用乐观与悲观两种策略(McGregor的Y理论和X理论),如果该组员积极、责任感强、善于沟通与反馈则会采用乐观的态度充分的发挥该组员的成就感,较少的干涉,甚至接给他一些较多协调处理的任务,更多的让他发挥,对其进度也认为是乐观的,从而可从中节省时间处理薄弱环节;而对于新进入员工作、态度消极、有问题少反馈、有关键性技术问题等情况下则将重点跟踪,包含详细代码走查、实现思路指导、更详细的日程计划、更频繁的检查等。

 

3.       进度安排CMMI流程、文档提议

有关CMMI流程和文档,可能理解不够的原因,仅以列表方式提出困惑和我个人认为较好的一个参考提议

困惑

参考提议

部分文档实际作用小(仅个人认为),编写维护工作量大;部分文档存在事后“赶出来”或者大量拷贝其它文档,基本只起应付检查作用,对于过程型文档几乎无实际意义,有些内容不具备后续实际参考作用

尽可能减少不必要的文档,过程性文档(如工作量估算、日程安排、工作周报、会议纪要)等应在项目过程使用阶段检查;验收时重点关注项目结束后仍需使用的文档;注重内容本身抽查,而非形式(如需求编号、文档编号、作者与审批者等)检查,不应过度注重“招式”

文档结构目录太深,找文档时目录层次太多,不易查找,如日程表经常会查看更新,在第四层文件夹中

路径偏平化,第一级目录文件目录要增多,应基本包要在第二级时出现所有常用文档,尤其是高频率使用的文档甚至可直接放在一级目录

部分文档模板设计不合理

l  需求文档中不应过度注重数据字段列表

l  项目周报不应重复录入日期信息,如文件按日期项目命名则不用再录入日期和项目名称

l  很多文档都要重复项目阶段时间范围

尽可能精简实用

 

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

RocChenKing

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值