项目管理的思考

原创未完待续思考

思考

发布日期: 2024-03-02

更新日期: 2024-03-18

文章字数: 1.2k

阅读时长: 4 分

阅读次数:

最近逐渐开始上手管理起公司的项目。我理解我的工作重心需要转移到对客户需求的落地上来，重点关注项目实施过中的风险，积极推动项目的进展。我也不知道我理解的对不对，在这里先做一些记录。

我期望的发开模式是所谓的敏捷开发，能做到随时随地的修改和发布，起到快速响应客户的诉求，任重而道远。

现阶段是在整理、总结、制定项目实施规范的阶段。我主要思考了些如何更合理的安排工作、拆分任务，以及与业务方约定适合的沟通交流机制。

最近用了redmine,发现其一些方法论啥的,在此记录。

用户提出问题,我们解决问题

我们的用户提出的所有诉求，我们统一抽象称之为"问题",而我们的价值就在于能够帮用户解决"问题"。这样，我先进行了第一层次的认知。

问题的分类和转换

简化用户的提问方式和习惯

但是如果让用户自己提问题的时候给我归档为 “需求”、“任务”、“缺陷” 的话。他们势必要去区分这些名字的含义

需求(REQ) : 因系统没有而需要实现功能而提出的问题
缺陷(BUG)：因系统已有得功能但不符合预期而提出需要修复的问题
支持(HELP)：因系统已有得功能但不符合预期而提出需要排查原因的问题

这势必引起他们的反感。“我提个问题，我还要区分到底是什么类型，有些问题模棱两可，既可以归结为需求也可以归结为缺陷”，他们会说。因此我们要简化用户的提问方式和习惯。

用户应该只用关系提出需求，我们自己把用户的需求转换归类到对应的类型中去

其实这个事情可以安排一个专门的人在每天的时候分一下就行。业务提出问题，项目管理员负责讲问题归结为需求(REQ)、缺陷(BUG)、支持(HELP)，然后指派到对应的人员进行解决。

敏捷之迭代

Target Version 1.3.1 目标版本，也称之为迭代，以周为单位进行划分，以里程碑为界进行升级，以点分数字进行表示。

迭代- V x.y.z

第一位x代表版本

第二位y代表月份

第三位z代表当月的第几周
eg: 1.3.1 代表第一个版本中的3月份的第一周。那么第5个版本中在12月份的第3周则表示为 5.12.3

迭代之问题

每个迭代会安排两种事项

已确定需求的实现
未确定需求的沟通

解释:
已确定指的是双方就需求需要明确落地的功能点或原型已达成一致意见，并约定在本迭代或双周迭代内交付的需求。
未确定指的是双方未就需求需要明确落地的功能点或原型达成一致意见，需要进一步澄清或沟通的需求。参考需求确认制度

问题之合并拆分机制

问题之产研沟通&任务指派机制

问题生命周期(精简)

验收机制

问题响应机制

周例会机制

时间：双周，周五，15:00-16:00。遇到月初(因各业务比较忙)，顺延一个工作日，时间控制在一小时。

1.已经解决问题汇报。(只展示已经解决的问题,不深入讨论)
2.待验收的问题收尾。(没有及时验收的问题询问原因是否有未完成的功能)
3.新问题明确优先级。(针对新增问题现场标记业务方认为高优的需求，如没有人发言，进入下一项议题）
4.风险问题进度汇报。(历史风险解决进度汇报以及新增风险明确联系人,如不能明确的将会一直阻塞某一需求的完成的风险升级领导)
5.本次迭代需求昭示。(如有异议现场提出，根据需求的紧急程度进行需求的调整)