弹性工作时间是什么意思,产品经理必看：如何应对项目延期的问题

导读：弹性你说的工作时间是什么意思？产品经理必看:如何应对项目延期的问题。项目延期是产品经理职业生涯中常见的问题，但延期意味着某个环节出现了问题，也会对后续运营产生影响。如

弹性你说的工作时间是什么意思？产品经理必看:如何应对项目延期的问题。

项目延期是产品经理职业生涯中常见的问题，但延期意味着某个环节出现了问题，也会对后续运营产生影响。如何才能尽量避免项目延期？笔者对此进行分析，希望对你有所帮助。

1.为什么项目容易拖延？

1.软件研发是一项创造性的工作。

项目延期是普遍现象，也是管理者最头疼的问题。但是外人不了解。明明是你自己做的计划，所以总是有那么多问题。归根结底，这是我们工作的特点决定的。我们做的是创造性的工作。不像盖房子，有具体步骤。我们实现一个函数，怎么写，写了多少行代码才知道。

根据我自己的经验，我认为项目延期有两个原因:

2.工作上有很多突发事件。

我们在评估工作量的时候，都是基于以往的经验。这种经验性的评价在现实环境中并不可靠，你无法应对突发问题，我们现实的开发过程中有太多的突发问题。

3.协作之间的耦合度很高

技术人员工作耦合度太高。从一开始，产品经理提出需求，UI设计原型，UE设计经验，程序员做系统设计，写代码，测试人员写测试用例。环环相扣，其中一个环节出了“意外”，时间就得耽误。

二、延误工作的常见原因

以下是工作延迟的常见原因:

需求变更，一般指新增需求或者需求细节一直在变；需求评估的工作量不足，低估了功能实现的难度；需求理解不对，功能做错了。等最后测试或对接的时候才发现；有临时需求插入。比如线上突然出现了一个bug，需要修复；新需求本身存在逻辑问题，做之前都没发现，在做的过程中才发现。自测不仔细，测试发现问题太多，bug越改越多；临时人员变动；偏离计划后没有做好应对措施；技术难点调研出了问题，实现方案得改；……

我们无能为力了吗？不完全是。方法永远比问题多。只要出现的问题都有解决方案，就有可能按时上线。当然，面对复杂的问题，很难一下子解决，但好在可以迭代。在每个项目结束时，应对项目进行评审。

三、如何解决项目延期的问题？

这是我对项目延期的解决方案:复盘——发现问题——拆除问题——制定解决方案——迭代——复盘。

1.重新报价，发现问题

重新报价:上次我们延误的原因是什么？找出问题的原因。比如上一次是需求变化导致的。

2.拆解问题，制定解决方案。

然后就是拆解的问题。为什么需要改变？因为这个功能更重要。这个答案是真的吗？这个功能真的很重要吗？好吧，是真的。那么标准是什么呢？如果没有。那我需要解决它。有了标准，下次遇到新的需求，就可以快速决定是否加入这个版本。好了，可以继续拆了。是新需求导致的延迟吗？是的，因为新的需求和在线时间没有被修改。那么，下次面对新的需求时，能否争取更长的开发时间呢？

这种方法的好处是每一次进步都能感受到。缺点是时间周期太长。幸运的是，我们可以借鉴他人的经验。我们没有必要再去参观别人参观过的坑。

四、解决工程延期的三个关键要素

根据我多年的项目管理经验，我认为解决项目延期问题必须做好三件事。

1.项目开始前:需求管理

在项目开始之前，需求管理有四个关键步骤。

1)就需求优先级达成共识。

首先，我们应该就优先化需求达成共识。什么样的需求最重要，必须满足？每个公司可能都不一样。我根据两个维度给自己排名:商业价值和用户价值。

商业价值是指直接给公司带来利润、降低运营成本、完成公司长期战略目标的那些职能。用户价值就是那些能够改善用户体验，提高用户效率，解决用户痛点的功能。

基于这两个维度，我们可以画一个四象限图，把我们所有的需求按照商业价值和用户价值这两个维度划分到不同的象限。对于商业价值高，用户价值高的产品。我们应该马上做它。第二优先级是商业价值高，用户价值低的需求；还是商业价值低，用户价值高的需求，要看公司的实际情况。

为什么要优先考虑需求？时间有限，要做的功能太多。如果按照商业价值和用户价值拆解后还有很多需求，可以从重要性和紧迫性两个维度继续拆解。

2)弄清楚需求的目的

达成共识后，第二步是要求产品在需求评审时先说明需求的目的。不仅是我们想做的，还有我们想达到的。这有两个好处。

让所有人参与其中，发挥团队所有人的价值，通过集体共创可以获得更好的解决方案。在事后，我们可以很清晰的看到，我们做的功能是不是往目标更前进了一步。如果没有。那么复盘的时候，能更有指向性的去找问题的原因。

3)找出需求的细节。

第三步是开发人员需要弄清楚需求细节。每个开发者都应该养成这样一种看透细节的能力。

代码的世界只有0和1，没有什么随便的。当产品告诉我们需求的时候，我们并不知道系统的具体实现。他也不知道一些细节。这就会导致在做很多细节的过程中会有很多要求需要反复确认。如果做得不好，很多细节都会在测试中体现出来。

比如产品说我们这次要做一个活动，用户就下单29包邮。这看起来是一个简单的需求，但是如果你的系统足够复杂，开发人员应该会想，跨商店的情况怎么办？虚拟商品呢？店家设置其他活动，发生冲突怎么办？以后需求会变成49包吗？如果在评审过程中没有想到这些，那么你必须在评审过程中与产品保持联系。有些新人刚到都不好意思问。其实也没什么。每个人都这样来这里。这种能力是需要时间积累的。

澄清需求还有两个好处:

4)输出完整的项目在线进度。

第四步，自上而下同步需求，生成需求计划表。第一，我们把需求拆解，大需求变成小需求。然后评估小需求的工作量。输出自己的个人日程。然后整合部门内部的需求，输出部门的计划完成表。最后，与其他团队成员一起制定总体项目进度表。通常会做成甘特图。这样做的过程中更容易发现问题。

异常情况:

这四个关键步骤说起来简单，做好却不容易。如果能做到，需求管理就不会有大问题。当然也会有一些不正常的情况。比如需求确定后，是否可以更改？大致需求确定后，最好不要临时改动。除非有特殊情况。

什么是特例？这就是制定需求优先规则的好处，如果有更迫切的低成本的高商业价值和高用户价值的需求。我们可以改变。只要团队成员认同这个规则，就能更好地实施需求变更。

领导不按规则改需求怎么办？

谁负责谁决策。因为我们站的角度不同，所以我们认为的高价值任务不一定是对的。这是职场通用的原则。作为项目组的一员，在需求确定做不做之前，你可以发表自己的建议，但如果最终负责人做出了做的决定，那就坚决执行。

2.项目初期:过程管理

流程管理的关键是解决信息不同步的问题。我的解决方案是:

1)每天召开一次晨会

很多人说，上午开早会没用，这是管理者除了通过会议推动工作没有别的办法的表现。我觉得晨会并不复杂，也不会占用很多时间，但正是因为有了这样一个固定的“交流”，大家心里才会有所思考，自然会按计划推进当前的工作。在这里，我给大家介绍一下在我公司召开常务晨会的具体步骤:

首先团队之间达成共识。明确晨会的目的是协同，而非汇报。每个人时间就2分钟。控制发言时间。确定汇报的内容。每个人讲讲当天的计划和实际进度是否一致。是否遇到了什么问题，是否需要什么支持。固定发言顺序，发言过程中，其他人不评论，不解答。具体的问题等到会后在找相关人员一起讨论。晨会的主持人很关键，他需要控制流程和时间，对于偏离主题的发言要给予提醒。最后就是要做会议纪要，只记录某人遇到的问题或请求以及整个项目的进度是否正常。

会议时间建议在正式工作时间后30分钟，比如9点。九点半开始。10点前结束。备注:我们公司弹性可以9: 30到公司上班。

晨会可以解决团队内部信息不对称的问题，大家可以更好的了解彼此的项目进展，很好的合作。而且，大家都是骄傲的。如果自己的计划没有完成，当众说出自己的理由，压力很大。这种压力会下意识地影响一个人每天的任务完成和注意力的集中。

很多公司把晨会变成汇报会，最后变成了没有多少信息的务虚会。不是这个工具不好用，而是你用的方法不对。记住以上原则，相信你也能组织一个适合自己团队的晨会。

2)如果是跨部门协作，每天都要进行“表对账”。

如果是跨部门协作。我们还要每天“查表”，也就是同步信息。

3)关键节点的跟踪

不要等到上了网才看到项目进展，这样即使发现问题也来不及解决。

4)制定异常问题的处理机制。

在所有的异常情况下，都需要设计一个应对方案。有了应对方案，至少解决问题的过程不会慌。就好解决多了。

5)建立自己的问题清单。

很多大公司都有这样的产品问题清单。同事在处理用户问题时，可以通过关键词搜索找到常用的解决方法。这大大提高了客服处理问题的效率。同样的方式其实也可以用在开发中。也许一个同事很久以前遇到的问题，其他同事也能遇到。这种情况下，原本需要半天才能通过关键词搜索解决的问题，可能一分钟就能解决。需要注意的是，制作这个问题列表库时，必须先定义格式。很容易管理。

做好以上几点，是否能保证项目按时上线？不一定。因为这里最重要的是执行的人。人的管理是一门艺术，后面再详细讲。

3.项目结束后:对项目做一个回顾。

复会:全员参与。

做得好的，就尽量标准化，复制。

做得不好，就要想办法制定应对方案。

五、防止工程延期的几种方案

最后说一下我个人在防止项目延期方面的经验。

1.大型项目应该分阶段测试。

不要将测试和设计工作集中在一个时间段。迭代的持续时间不应超过一个月。

2.预留测试时间

开发者每完成一个任务，都要预留一个测试时间。同时要和开发人员达成共识，如果开发过程中有延误，要加班赶进度，不影响其他同事的进度。

3.制定常见异常情况的处理标准。

也就是说，在开始的时候，如果真的有需求变化，那么就要做好需求变化的标准。需求是可以变化的，变化后如何应对。这一点也需要明确。有的可以直接放入版本，通过加班解决，有的可以舍弃一些需求。当你想发布它们的时候，尽量不要做改变。

4.好好计划B

一些意想不到的时候有什么计划。比如有人临时提出要求怎么办？有技术上的困难克服不了怎么办？作为一个管理者，你需要提前想好替代方案。

5.制定两个发布计划。

一个计划是内部的，根据大家工作计划整合后的发布时间，还有一个计划是对外推出的。我们的团队应该追求在线的内部时间。但是如果出了问题，预留的时间就是我们的缓冲区。当然，你也可以给外界一个模糊的上线时间，比如内部9月10日上线，外部9月中旬上线。

以上是我处理工程延期的经验。希望能给你一些启发。

本文由@石云生原创发布。每个人都是产品经理。未经许可，禁止复制。

题目来自Unsplash，基于CC0协议。

此观点仅代表作者本人，大家都是产品经理。平台只提供信息存储空间服务。

总结:以上内容是对弹性工时问题的详细介绍，产品经理必看:如何应对项目延期。文章内容部分转载自网络，希望对你了解弹性工作意味着什么有帮助和价值。