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

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  很多文档都要重复项目阶段时间范围	尽可能精简实用