疯狂

STANDING ON THE SHOULDERS OF GIANTS
posts - 481, comments - 486, trackbacks - 0, articles - 1
  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

项目规划与管理记录2

Posted on 2013-11-18 12:51 疯狂 阅读(1797) 评论(0)  编辑  收藏 所属分类: 项目管理
转载自:http://www.blogjava.net/cheneyfree/archive/2013/11/09/406169.html 
8、9、10三月,需求依旧爆棚,相比纯业务功能的开发,数据的汇聚、整理、分析、统计成为重点,具体细节不一一展开,按如下关键词:任务计划、项目沟通、项目流程、客户汇报、业务关注、时间评估、管理笔记做一些笔录,持续更新:
    1、任务计划:
      1.决策前考虑充分,决策后不再怀疑。
      2.任务精细、描述清晰,对内分解针对到负责人、给外汇报针对产品功能。
      3.计划制定时,请成员预审任务量,再和开发、测试确认时间,由成员承诺时间。
      4.安排任务多人完成时,指定一个牵头人。
      5.大的需求,组织讨论,小的需求,点对点沟通,最后要全部闸口到文档。
      6.任务分配:根据人员特点(善于思考型、认真较劲型、粗枝大叶型)安排难易程度对应的任务。
      7.紧急需求多时,一次尽可能给成员分配较少任务并约定完成时间、完成后再约定下一批任务。
      8.根据任务分配情况,了解到谁相对空闲,安排新任务给空闲的成员。
      9.碰到的问题整理一份清单,尽可能一次性地转交开发、测试人员。
      10.形成人员对开发任务的备份机制,不局限某个模块的开发,关注整体。
      11.每一轮版本,制定《风险管理清单》,协调、跟进、解决风险问题。
      12.加班如遇特殊情况不能陪同,托管工作给指定接口人。
      13.成员加班晚,第二天要根据情况保证人力参与白天工作。

   2、项目沟通
      1.重要事项亲历亲为。
      2.每周的项目周报,除了知悉公司外,同步知悉客户。
      3.需求的分析及客户确认用原型图。需求的确认启动开发,必须是业务部、信息化部、公司三方达成一致。
      4.技术实现上会就会,不会就不会,和时间的多少没有线性关系。
      5.控制好工作节奏,多和领导沟通,自己的经历正是人家过去经历的重现。
      6.沟通项目存在的问题时尊重客观事实和软件开发规律,做不完的跟客户说明原因,该拒绝的果断。
      7.上线前的客户运作,除了项目层面的客户沟通,也请领导高层向客户高层沟通。
      8.强调需求变更会影响项目计划的执行,变更需要付出代价(优先策略:时间调整、功能调整、人力调整)。
      9.遵循‘做得少但质量好,忌讳做的多却质量差’的原则。
      10.项目风险且一时对得不到公司资源倾斜时,也可借助客户的力量(下下策)。
      11.客户的跟催,多耐心少急躁,多自省少借口,多客观少主观。
      12.交付时间的答复,不能当下给出的待评估后再给。

   3、项目流程:
      需求频繁且变更较多时,建议0.5周~1周一轮版本。每次汇报后产生的新需求、遗留需求、待开发的功能:
      1.整理《项目跟踪表》,含:新需求、遗留问题、关联影响(指导测试做关联模块的验证)
      2.测试人员将已明确的开发任务登记到BUG管理系统
      3.需求人员与开发、测试人员评审需求
      4.负责人牵头需求、开发、测试人员确定开发、测试、发布时间计划。
      5.与客户反馈交付时间点(对于小需求的交付时间可以直接答复、大需求要内部讨论再答复)。
      6.项目进度跟踪,以天为单位,测试人员更新《项目跟踪表》。
      7.需求验证介入
        1)开发提交代码后,需求人员、测试人员分别开展系统测试(业务角度,关注界面交互、主干流程、数据展现)、业务测试(系统角度,关注功能操作及边界、业务流程输入输出)。
        2)需求人员发现的问题,属于开发BUG登记到BUG管理系统、需求BUG与开发人员、甚至客户澄清,如不影响版本发布时间直接加入在研版本、如影响则提交变更请求,与客户沟通得到变更认可或与开发沟通得到变更认可。
      9.升级前,针对环境数据的准备,编写《升级注意事项(含数据清理、数据准备等)》给测试人员交代。
      10.升级后,需求人员在演示环境走业务测试(建议离正式演示前2天完成升级验证,提前1天环境冻结。)
      11.上线前,与客户沟通准备事项(含压力测试、工程部署、资料交付、培训计划、试运行计划等)

   4、客户汇报:
      1.小型汇报,前一天,系统冻结,不再做升级,只做业务验证、回归。
      2.大型汇报,前三天,系统冻结,不再做升级,只做业务验证、回归。
      3.汇报前,拿用户的笔记本做预演,防止操作系统、浏览器兼容问题。
      4.汇报思路:
        1)以一个业务主线,给客户讲故事,结合不同客户关注的角度出发,让平台能融入不同客户的日常工作。
        2)信息化前是什么样,信息化后是什么样(提高日常办公的效率、平台统计的数据提升客户的业绩等)
      5.项目初期注意界面UI友好,中期注意数据的规范及业务流程正确,后期注重统计数据的真实、准确。
      6.版本的技术问题、项目进度的问题、用户需求的问题、沟通协调的问题,实事求是汇报客户。
      7.汇报前与客户业务接口人沟通汇报内容、汇报方式,掌握领导听取汇报时关注的点。
      8.汇报前,关注业务部门的需求、信息化部门的建议、更要关注客户领导的关心点。

   5、业务关注:
      1.关注平台的数据输入、处理、输出数据的完整性、准确性、关联性。
      2.抓住平台的建设理念,所有业务模块围绕该理念开展需求分析、设计。
      3.降低线上复杂的业务操作流程(更多考虑结果数据的录入、留痕,流程多了很难同时在线协同办公)。
      4.技术实现的同时要考虑业务机制的配套。
      5.考虑现实性[在现有业务规章制度的环境下运行]、前瞻性[业务层面的发展方向]、可行性[技术是否支持]。
      6.关注和周边平台的数据结构一致和标准
      7.<待补充>

   6、时间评估:
      1.每天列出当天要做的工作、每天下班前回顾当天工作,每周列出本周工作成果、下周工作计划。
      2.任务时间评估 = [成员评估 结合 自评估] + 开发冗余(根据平台特性、开发人员经验及态度判断) + 测试冗余(根据平台特性、测试人员经验及态度判断) + 需求冗余(根据平台特性、需求人员经验及态度判断)+ 其他冗余(如请假、生病、开会等非项目因素)

   7、一些管理笔记:
      1.任务精准、给予空间
      2.狠抓住干、适当放权
      3.敢于承担、顶住冲击
      4.讲究诚信、承诺到位
      5.规则考核、理解包容
      6.用人不疑、疑人不用
      7.功劳大家、黑锅自己


只有注册用户登录后才能发表评论。


网站导航: