误区
之前我没有项目经验, 在上一家公司的项目管理上, 我只是照葫芦画瓢.
产品发起, 整个项目没有项目经理这一说. 或者说有, 但却真的感受不到, 一丁点也感受不到.
产品发起会议, 或者开发发起会议. 无论谁来发起会议, 一般都会针对于某一具体需求或者某一具体实现方式.
没有具体的任务规划, 任务拆得不够细致. 这个和开发自身有关系. 当然那时的公司确实没有一些指导性质的模板和导师.
任务分得不够细致, 就会导致工期评估差距比较大.
各种 O 们的临时紧急需求, 很多 O 没有技术背景和项目管理背景. 很多时候提出的需求都是发生在项目开始过程中.
都是很急的需求, 不得不重新估算时间和排期. 开发为了避免延期风险, 就是让产品排优先级, 然后我们根据优先级估时.
直到有必要的需求都在这个迭代中计划上.
没人全局把控, 产品从产品角度, 开发从开发角度, 业务从业务角度. 始终没有一个最终的协调人.
产品在对各种 O 的对话中, 气场和身份不足, 导致需求基本是提出就会安排. 即便是请出青岛总负责人出面沟通, 最终的结果一般就是接受.
之前我们是青岛为开发, 北京为产品, UI, 前端, 测试. 异地沟通. 电话会议是常有的事情, 私下的临时沟通电话更是家常便饭.
信息同步, 开会, 理解程度 都会造成沟通上的成本增加.
紧急需求上线后, 三个月没人反馈. 问了才知道, 财务提的需求他们没用过.
开会一般都会临时决定, 发起人会准备资料, 但是其他人提前看资料准备问题的情况极少. 导致会议冗长效率低.
解决
现在来看, 无论如何, 我们在知道这些问题, 但是为什么不去处理呢? 应该还是习惯了, 即便是整个项目非常挣扎, 依然是按老规矩走. 大家都是困在了这个围墙中.
我现在也有了一年的项目管理经验, 初入门道. 只是对自己的过往进行一下分析解决.
以上的误区和问题, 我觉得需要一个有经验并且有点能力的人来带领这个项目团队.
1. 确认项目经理
但是按照我上家公司的情况, 一般会立经验丰富的主管直接管理这个项目.
当时的情况是, 项目主管在项目上的精力完全不够, 甚至说项目管理在项目主管心中的优先级比较低.
根本原因, 青岛作为研发中心, 技术基因强大. 很多技术管理人员, 没有意识到项目管理的重要性.
组织架构主要是垂直单线架构, 技术 - 主管 - 经理 - 总监 - CTO. 无非是自己下面的人多, 按照业务或者大项目分了组而已.
如果让开发作为项目经理,
首先这个开发是否愿意承担项目经理职责?
是否真的能够赋给项目经理一些实权?
是否有鼓励机制, 比如晋升优先或者奖金等?
建议:
加强项目管理意识;
加强项目管理能力;
必要的话可以作为量化指标来看;
加入一些激励机制;
2. 培养主动性
因为技术基因影响. 主管或者经理出于 "好心" 考虑.
他可能会考虑到, 如果把项目管理中的某些事情分配给组员, 会不会引起反感? 会不会影响在组员中的美好形象?
也算是确实分下来一些, 比如项目规划和估时以及排期. 但是我没经验的, 是不是可以稍微引导一下?
领导总想为老好人, 但是这样自己手头的任务分不下去.
下面的人也得不到成长.
建议
对组员有一定的规划和成长要求, 而不是放任其随意生长 (有一定风险)
领导应该提高自身的管理能力, 管理技巧. 而不是凭经验论.
定时关切 Review 分下去的任务, 从结果或者过程提出建议和优化.
3. 确认好需求边界
产品经理和负责人, 确认好需求边界. 飘忽不定的需求给项目的打击是很大的.
开发在摇摇坠坠重估时, 此时的估时肯定会有达量的冗余, 因为之前需求的变动, 上线时间一改再改.
在加上, 主管, 经理偶尔砍几刀. 所以开发在估工时都会冗余很多. 为了被砍, 为了需求不定.
建议:
确认好需求, 可将项目周期缩短, 小版本迭代.
强化项目上线时间约定, 锲约精神. 不仅仅是开发要遵守. 其他人员最好也能严格遵守.(当初这个做起来真的比较困难)
信心是做出来的, 几次项目的延期和需求的变更会严重打击大家的信心和士气. 所以按时上线很重要.
规划得有, 但是是不是可以考删掉远在 4 个月以后的需求.
4. 紧急需求
比如财务的一些紧急需求, 其实确实紧急, 但是使用频率很低.
是不是可以有另一种解决方案? 不一定非要按照财务提出的那种设想.
我们达到并满足了他们的目标, 后期再去做页面更加直观.
比如要一个订单查看页面. 那我使用程序定时拉取新订单推送到企业微信或者钉钉. 结果也是非常满意的.
不一定非要做一个页面, 很多时候做成一个页面, 大家会发挥自己的产品意识, 增加一些不必要的按钮, 功能和逻辑.
建议
深入了解需求, 而不仅仅是一句话, 也不是根据用户提出的需求来做, 用户到底想要什么?-- 他就想要有订单能及时知道.
紧急需求是否真紧急, 也得看使用频率. 使用频率低, 是否有其他方式实现.
能搁置的暂且搁置一下, 之前就我一个人开发, 很多原本紧急的需求因为开发不够, 搁置了也就搁置了. 然后甚至有的都自己消失了.
5. 高效开会
会议开始前, 大家几乎么有预习的习惯, 会上很多时候没有主持人, 大家就问题会讨论很深, 导致时间不可控.
有的会能一个电话解决的就没必要拉这个拉那个来开会. 这种仪式感不重要, 开会也不是拉家常.
为了让领导知道这次会议的重要性, 这个项目的重要性. 拉着领导一起开:
但是领导的事情多, 很多时候在会上他们是一直回复信息, 其实当时是比较尴尬的, 领导不能专心处理问题. 我们看着领导没用心听, 不了解的同事还以为领导漠不关心呢.
建议:
发起人拉群, 提前 @人提醒大家关注和看会议内容.
发起人做会议: 主题, 流程, 最终结论
确认会议主持人, 随时控制会议进度. 有些细节会后沟通.
领导可以不必参加需求讨论会, 把会上讨论的疑难问题, 会后单独和领导会报, 再拉一个小会议电话沟通确认即可.
重要项目启动会, 项目上线等会议尽量简短, 领导全身心参加. 保证大家的斗志, 统一思想达成一致. 有些形式必须要有的.
6. 相关方
开发与客户沟通少, 因为两地沟通, 基本是产品作为翻译官将业务转成需求转达给开发.
开发没有感知用户的存在.
建议
多听听用户怎么说.
大家达成一致, 每月电话会议或者视频会议沟通一次. 会议可以控制在 1 小时以内, 氛围可以轻松, 主要是手机需求以及反馈问题.
如果有多个业务部门都是相关方, 那么主要思想就是设置定期沟通 (规律的定期沟通)
7. 转变
优胜劣汰的企业付薪给我们, 我们就要服务于这个企业用户. 甚至说服务好用户.
我们开发也要主动从自身求变. 好好说话, 真心替我们的用户思考过问题.
从产品和业务角度认可业务优先级, 而不是紧紧盯着开发重构, 新技术的应用.
建议
转变意识: 我想为你们服务;
我能力不行, 但是我能主动学习项目管理知识和经验, 并在项目中实践, 反思, 再实践.
我要为我开发的产品负责, 它的迭代, 扔给它的需求, 和它相关方, 它的应变能力.
主动一点, 也许事情看起来并没有那么难.
现在的我, 我们
新的公司, 给了我很多的机会, 纠正了我很多认知, 我也从实践中反思了很多, 收获了很多.
公司的组织架构是矩形架构: 横向职能, 垂直项目
项目首先会有项目经理, 项目经理有一定的项目经理奖金. 当然项目经理要履行项目经理的职责. 都会有绩效.
项目经理, 开发, 产品, 测试, DBA, 运维, PMO 这些会组成一个项目组.
整个项目组会在项目经理的引导下, 开发项目直到上线. 然后迭代下一版本.
现在项目中, 有使用瀑布开发, 有使用敏捷开发.
我所认知的一点是, 各个职能团队人员虽然属于职能. 但是基本会长期泡在各个项目中.
项目中学习到的东西, 在项目中的成长也是很重要的. 所以项目经理有一定的敏捷角色中 PM 的角色: 引导大家, 赋能给大家.
我们正在尝试的敏捷 (尝试)
其他团队物理面板:
我们团队的面板: 非常简单
项目并行和项目特殊性, 我们采用周交付, 不确定哪一天交付什么 (特殊需求除外).
因为项目为运维性质的项目, 有开发, 紧急需求, 客户答疑问题较多. 实践不太可控.
并且大家积极性都很高, 没必要要求必须排满周开发任务.
自己开发完直接到需求池, 领取最优先级的需求, 或者帮助其他组员分解开发任务.
业务需求 + 技术需求 双向需求驱动, 占比 5:1.
周最高优先级占比 1:4
这样大家不会因为具体时间的冲突导致交付的压力. 周交付的任务为必须交付的最小单元 (本周必须交付).
没必要的会议去掉, 我们基本都坐在一起, 不去会议室. 工位周边就可以开会. 电脑操作随时记录, 会后发出来.
周五: 计划会 (15:00 ~ 15:30)
10 分钟, 材料都是平时积累, 会前整理完
地点: 工位
目的: 回顾上版本迭代精进结果. 分析过程问题原因, 总结问题. 认知好与不足, 下版本迭代重点要解决的问题.; 讨论新需求优先级; 达成一致周最小目标.
周五会后 + 周一开会前
对新需求进行任务拆分, 需求理解, 任务具体估时.
周一: 迭代会 (10:00 ~ 10:15)
15 分钟, 微调任务; 统一思想; 确认周迭代目标;
地点: 工位
周三: 如果需要可以开一个简短沟通会
我们自己维护的计划和交付, 简单高效. 团队协作, 互相可看.
我们的产品是刚毕业的新人, 我们互相指导学习.
他最近也在研究用户故事如何写好. 他打算下周先打印出来, 大家看看自己感受一下.
最近我看完了一本敏捷开发相关的书籍, 同时推荐给了他. 我们想单独摘出好的或者值得讨论的地方, 大家围在一起拿出半小时讨论一下也未尝不可.
还有一本我正在看, 可能我时间经验不足. 总是感觉一般般的感觉. 思路不是很清晰.
有读过的朋友可以发表一下看法.
总结
敏捷我们在路上. 不为敏捷而敏捷.
我们互相提高, 互相帮助, 能力提升, 升职加薪. 生活质量更好.
大街上敏捷一大堆, 根据实际情况摸索敏捷之道. 发挥大家的能力, 提升大家的能力. 为大家带来点实际的东西. 为企业带来点实际的东西.
项目管理根本目标是把项目管好, 项目管好, 大家更加自信, 互相也都信任. 所以项目管好是项目组良性循环的根本. 项目经理要多花大力气去关注, 去学习.
谢谢关注公众号
来源: https://www.cnblogs.com/sunchong/p/11917766.html