多语言网站 用什么cms,yellow在线观看高清完整版,wordpress 发布api,电商常用的erp系统有哪些项目为什么容易延期#xff1f;
1、软件研发是一项创造性工作
项目延期是一种普遍现象#xff0c;管理者最为头疼的一个问题。但是外人并不理解。明明是你们自己做的计划#xff0c;怎么总会出现这么多问题。说到底#xff0c;这是由于我们的工作特性决定的。我们做的是一…项目为什么容易延期
1、软件研发是一项创造性工作
项目延期是一种普遍现象管理者最为头疼的一个问题。但是外人并不理解。明明是你们自己做的计划怎么总会出现这么多问题。说到底这是由于我们的工作特性决定的。我们做的是一个创造性的工作他不像建房子有特定的步骤。我们实现一个功能怎么写有多少行代码我们在写之前是不知道的。
基于我自己的经验我觉得项目延期还有以下两个方面的原因
2、工作中的突发事件多
我们在评估工作量的时候都是基于过往的经验。这种经验性评估在真实环境中并不可靠。你无法应对突发问题。而我们真实开发的过程中突发问题太多了。
3、协作之间的耦合性高
技术人员工作的耦合性太高。从最开始产品经理提出需求、UI设计原型、UE设计体验、程序员做系统设计写代码、测试人员编写测试用例。环环相扣其中一个环节出了“意外”时间就得往后延。
工作中常见的延期原因
我这里列了工作中常见的延期原因
需求变更一般指新增需求或者需求细节一直在变需求评估的工作量不足低估了功能实现的难度需求理解不对功能做错了。等最后测试或对接的时候才发现有临时需求插入。比如线上突然出现了一个bug需要修复新需求本身存在逻辑问题做之前都没发现在做的过程中才发现。自测不仔细测试发现问题太多bug越改越多临时人员变动偏离计划后没有做好应对措施技术难点调研出了问题实现方案得改
......
那是不是我们就没办法了呢也并不是。方法总比问题多只要所有出现的问题都有应对方案准时上线也是可能的。当然面对复杂问题想一次性解决很难但好在我们可以迭代。每一次项目结束都应该对项目做一次复盘。
如何解决项目延期问题
这是我应对项目延期的解决方案复盘 —— 找问题 —— 拆解问题 —— 制定解决方案 —— 迭代 —— 复盘
1、复盘找问题
复盘上一次我们延期的原因是什么把问题原因找出来。比如上次是需求变动导致的。
2、拆解问题制定解决方案
接着就是拆解问题。为什么需要变动因为这个功能更重要。这是答案是真的吗这个功能真的很重要吗好是真的。那么评判标准是什么如果没有。那么我需要制定出来。有了标准下次遇到新增需求我们就能很快决定是否加入到这个版本里。好我们还可以继续拆是新增需求导致的延期对因为新增需求而且并没有修改上线时间。那我们下一次面对新增需求是不是可以对外争取更长一点的开发时间
这个方法的优点是每次进步都能感受的到。缺点是时间周期太长。但好在我们别人的经验是可以学习的。别人趟过的坑我们没有必要再趟一次。
解决项目延期的关键三要素
基于我多年的项目管理经验我认为要解决项目延期问题必须做好三件事。
一、项目开始前需求管理
项目开始前的需求管理有四个关键步骤
1、达成需求优先级排序的共识
首先我们要达成给需求优先级排序的一个共识。什么样的需求是最重要的一定要完成的每个公司可能不一样。我自己是基于商业价值和用户价值两个维度来排序的。
商业价值就是那些直接给公司带来利润能够降低运营成本、完成公司长期战略目标等功能。而用户价值是那些能够提升用户体验、提高用户使用效率解决用户痛点问题的功能。
基于这两个维度我们可以画一个四象限图把我们所有的需求按照商业价值、用户价值两个维度给归类到不同象限里。对于商业价值高、用户价值高的产品。我们应该马上去做。至于优先级排第二的是商业价值高、用户价值低的需求还是商业价值低、用户价值高的需求要根据公司实际情况来定。
为什么要给需求分优先级时间有限要做的功能太多。如果根据商业价值和用户价值拆解后还有很多需求我们还可以继续用重要紧急两个维度来拆。
2、弄清楚需求的目的
达成了共识后第二步就是在需求评审时要求产品先讲解需求的目的。不只是说明我们要做什么还要说明我们要达到什么目标。这样做有两个好处。
让所有人参与其中发挥团队所有人的价值通过集体共创可以获得更好的解决方案。在事后我们可以很清晰的看到我们做的功能是不是往目标更前进了一步。如果没有。那么复盘的时候能更有指向性的去找问题的原因。
3、弄清楚需求细节
第三步就是开发者需要弄清楚需求细节。每一个开发人员都应该养成这样一个看透细节的能力。
代码的世界里只有0和1没有随便。产品在给我们讲需求的时候并不知道系统的具体实现。有些细节他也不知道。这会导致很多需求在做的过程中有很多细节需要反复确认如果做的不好很多细节问题都会在测试的时候体现出来。举个例子当产品说我们这次做一个活动用户下单满29包邮。看起来很简单的一个需求但如果你系统足够复杂开发人员应该要想到跨店的情况怎么办含虚拟商品怎么办如果店家设置了其他活动冲突了怎么办需求后期会不会变成49包邮如果这些在评审的时候没有想到那么在做的过程中一定要和产品保持沟通。有些新人刚来的时候不好意思问其实没啥每个人都是这么过来的。这种能力是需要时间积累的。
需求理清了也有两个好处
评估的工作量会跟精准。更早的发现需求里潜藏的问题。
4、输出完整的项目上线计划表
第四步就是上下同步需求生成需求计划表。首先我们拆解需求大需求变成小需求。然后评估小需求的工作量。输出自己的个人计划表。然后部门内部整合需求输出部门的计划完成表。最后是与团队其他成员生成整体的项目计划表。一般会做成甘特图。这样在做的过程中更容易发现问题。
异常情况
这四个关键步骤说起来简单但要真正做好不容易。如果能做到那需求管理基本不会存在大的问题了。当然也会有一些异常情况。比如需求确定后能不能变动一般需求确定下来后最好不要做临时变动。除非特殊情况。
那什么是特殊情况这就是制定需求优先级规则的好处了如果确实有更紧急、成本低的高商业价值、高用户价值的需求。我们可以变动。只要团队内成员都认可这个规则做需求变动就会比较好实施。
那如果是领导不按规则变动需求怎么办
谁担责谁决策。因为站的角度不一样我们认为的高价值任务不一定对。这是一条职场通用原则在需求确定做不做之前作为项目组成员你可以表达自己的建议但如果最终负责人拍板要做那就坚决执行。
二、项目开始中过程管理
过程管理的关键是要解决信息不同步的问题。我的解决方案是
1、每天都开站立晨会。
很多人说早上开晨会没有用是管理者没有其他办法只能通过会议来推进工作的一种表现。我倒不觉得晨会并不复杂也不会花费很多时间但正是因为有了这样一个固定”沟通“事项每个人心里都会想着这件事自然会把当下的工作按计划推进。这里我介绍一下我公司开站立晨会的具体步骤
首先团队之间达成共识。明确晨会的目的是协同而非汇报。每个人时间就2分钟。控制发言时间。确定汇报的内容。每个人讲讲当天的计划和实际进度是否一致。是否遇到了什么问题是否需要什么支持。固定发言顺序发言过程中其他人不评论不解答。具体的问题等到会后在找相关人员一起讨论。晨会的主持人很关键他需要控制流程和时间对于偏离主题的发言要给予提醒。最后就是要做会议纪要只记录某人遇到的问题或请求以及整个项目的进度是否正常。
开会时间推荐在正式上班时间30分钟后比如9点上班。9点30开始。10点前结束。备注我公司弹性上班可以9点半到公司。
晨会能很好的解决团队内部信息不对称的问题大家能更好地了解到彼此的项目进度并做好配合。而且人都要面子的如果自己制定的计划未完成还要自己当众说出来没按计划完成的原因是很有压力的这种压力会在潜意识里影响到自己每天任务的完成度以及专注度。
很多公司把晨会开成了汇报会最后就变成了一个没有太多信息量的务虚会议。并不是这个工具不好用而是你没有用对方法。记住上面我说的几个原则相信你能组织好一场适合团队的晨会。
2、如果是跨部门协作每日要进行对表
如果是跨部门协作。我们每天也要进行”对表“也就是同步信息。
3、关键节点的跟进。
千万不要等到上线了在来看项目进展这样即使发现问题你也没有时间来解决。
4、制定异常问题的处理机制。
所有的异常情况都需要设计一个应对的应对方案有了应对方案至少解决问题的流程有了心理就不会慌。解决起来就容易很多。
5、建立自己的问题清单库。
很多大公司都有这样一个产品问题清单库。客服同事在处理用户问题时候通过关键字搜索就能找到通用的解决方案。这极大地提高了客服处理问题的效率。同样的方式其实也可以用在开发上。也许很久之前某个同事遇到的问题其他同事也能遇到。这种情况下通过关键字搜索原来要花半天才能解决的问题可能一分钟就给解决了。需要注意的是在做这个问题清单库的时候一定要先定义好格式。这样才好管理。
那是不是做到上面这些就能保证项目能准时上线了也不一定。因为这里面最关键的是执行的人。人的管理是一门艺术。这里以后再详细讲。
三、项目结束后对项目做复盘。
复盘会全员参与
做的好的要想办法将其标准化、可复制。
做的不好的要想办法制定应对的方案。
防止项目延期的几个方案
最后说一下我在防止项目延期上的个人经验。
1、大项目要分阶段转测试。
不要把测试和设计工作都集中在一个时间段。版本迭代的时长也不要超过一个月。
2、预留测试时间
开发人员每次做完一个任务后都要预留测试时间。同时和开发人员要达成一个共识如果开过程中出现延期要自己通过加班时间赶上进度不能影响其他同事的进度。
3、制定常见异常情况的处理标准。
也就是最开始讲到的如果真的有需求变更那么就一定要做好变更需求的标准。需求可以变变了之后如何处理。这个也需要明确。有些是可以直接放到版本里通过加班解决有些可以舍弃掉一些需求。尽量不在要发布的时候做变更。
4、做好PLAN B计划。
遇到一些突发时间的预案是什么。比如有人员临时请求怎么办有技术难点攻克不了怎么办作为管理者需要提前想好备选方案。
5、制定两个发布计划。
一个计划是对内的根据大家工作计划整合之后的发布时间还有一个是对外上线的计划。我们团队要追求对内时间上线。但如果出现问题预留出的时间就是我们的缓冲带。当然也可以对外给出一个模糊的上线时间比如对内9月10号上线对外9月中旬上线。
以上是我应对项目延期的一些经验。希望给大家带来一些启发。
