惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

U
Unit 42
罗磊的独立博客
T
Tailwind CSS Blog
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Jina AI
Jina AI
V
V2EX
美团技术团队
阮一峰的网络日志
阮一峰的网络日志
酷 壳 – CoolShell
酷 壳 – CoolShell
月光博客
月光博客
量子位
MyScale Blog
MyScale Blog
G
Google Developers Blog
M
MIT News - Artificial intelligence
L
LangChain Blog
Microsoft Azure Blog
Microsoft Azure Blog
Recent Announcements
Recent Announcements
MongoDB | Blog
MongoDB | Blog
N
Netflix TechBlog - Medium
有赞技术团队
有赞技术团队
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
D
DataBreaches.Net
云风的 BLOG
云风的 BLOG
B
Blog

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
当领导说“这个需求明天我就要上线”时,你该怎么办?
菜根老谭 · 2024-06-11 · via 人人都是产品经理

本文深入探讨了面对领导紧急需求时的应对策略,从需求分析到资源评估,再到沟通协调,为产品经理提供了一套完整的处理流程。了解这些实用技巧,希望对你有所帮助,让你在职场上游刃有余。

昨天我们老板跟我提了个系统的需求,说要明天上线,我看了下这个需求,其实也没那么紧急,对比了当前的资源分配,还有正在处理的需求优先级更高的,于是我跟老板沟通了下,延后了上线时间。

我们现实工作中,肯定会出现这种,临时需求,挺多还很棘手,如果遇到了,我们该怎么办?

一、先分析这个临时需求

不管接到什么需求,先分析下再说,看看什么样子,再决定后续规划。

分析需求可以按照下面的步骤:

1)首先是要理解需求,多沟通,确保完全理解需求的目的和细节。

2)明确需求背景,重点了解这个需求为什么会是“临时需求”,它背后的业务逻辑是什么,有没有一些特殊的市场机会。

3)抓住需求核心内容,快速识别核心点,比如功能要求。

4)评估需求影响范围,涉及哪些系统、功能影响,涉及哪些使用部门影响。

5)评估需求实现可行性,技术上、产品方案上,是否是可行的,有哪些实施难度。

6)确定需求的紧急程度,是否值得作为高优先级处理,是否需要特殊处理。

如果这一些需求分析结果,是确实挺紧急的,要优先处理,那第一步就过了,我们先接下这个需求,再看看下一节。

如果分析结果是不需要处理,或者不那么紧急,那就直接看第3节。

二、综合当前资源对比

需求确定要做,也是紧急做,但到底要多紧急,什么时候上线,这个是要对比当前资源的。

我这里说几个对比的点,可以参考看看:

1)需求的相对价值

2)需求的相对紧急程度

3)需求的相对占用资源程度

4)当前团队资源情况

综合这些,看看这个临时需求应该放在什么时间处理合适。

三、与涉及需求方沟通

这里的涉及需求方,有两个:

一是这个临时需求的需求方。

二是如果调整了优先级,影响了其他需求的需求方,毕竟人家本身是正常上线,你这突然延后,总得解释一下。

沟通,需要把所有的事项说清楚,比如说:

1)解释原因,临时需求为什么不会优先处理,说下,临时需求如果优先处理了,影响的其他需求,也跟人家说下,是因为有其他优先级更高的需求顶替了。

2)展示影响,最好是提供一些具体的数据,这个需求不及时上线,会造成哪些影响。

3)寻求理解,要跟两边的需求方讲下,这样决定是基于整体考虑,并寻求双方的理解,你只要说清楚了,大家都会理解的。

4)寻找替代方案,我们做任何事,都要有一个B计划,尤其是在拒绝掉用户的需求,或者要调整他们的需求时,除了解释原因,还要有个替代方案,提出你的计划,尽可能减少相关影响。

说到这,我额外说个工作技巧,如果你向你领导汇报工作,遇到问题,不单单只是提出这个问题,有问题很正常,但是你得有你的思考,要附带你觉得合适的解决方案,这样,你的领导才会对你刮目相看。

四、反思当前的需求流程

我一直认为,从公司层面讲,我们所有的工作都要依赖于合理的工作流程,并加以特殊情况处理。

如果这个临时需求的增加,对你们的工作影响很大,并且很难处理,你就要反思下当下的需求流程了,是否合理,对于临时需求这方面,还有哪些流程上是有问题的,要及时调整。

我们的工作不是完美的,但发现问题就要修正。

尤其是对于很多流程上没那么完善的小公司,出现这种情况都是正常的,都要一步步来,随着时间、人员、内容等因素越来越多,这些流程都会逐步完善。

五、如果有一些需求外的情况

最后一个,我们就聊几个需求外的情况,毕竟这是职场。

如果需求方特别强势,这个指的是你领导,是老板,不好说话,那就调整你们当前的安排,加进去吧,毕竟人家是老板,沟通无效,接受就好。

记住,前提就是你老板这种,如果是其他部门,再强势,也要按前面的流程处理,很多工作原则一旦打破,后续将一发不可收拾。

如果有一些人情往来的,这个很现实,因为只要有人,就会有人际关系,这个自己把握处理就好。

本文由人人都是产品经理作者【菜根老谭】,微信公众号:【菜根老谭】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。