133 lines
11 KiB
Markdown
133 lines
11 KiB
Markdown
# 答疑解惑 | 如何管理你的上级？
|
||
|
||
你好，我是郑晔。
|
||
|
||
在这个模块里，我围绕着“以终为始”这个原则为你进行了详细地讲解，还给你介绍了应用“以终为始”原则的一些行业最佳实践。
|
||
|
||
同学们的留言特别踊跃，很多同学表示有收获的同时，也提出了大量的问题，大家比较关心怎样将这些实践在自己的实际工作中落地，部分问题我已经在留言中回复了。在今天的答疑环节中，我挑选了一些非常典型的问题来更详细地回答一下。
|
||
|
||
## 问题1：领导要求的，无力反驳怎么办？
|
||
|
||
achenbj 同学提到
|
||
|
||
> 讲得很好，感觉落地还需努力。我们就是领导给了功能，跟你说下要做啥，就那么做就行。没有了。
|
||
> [—— 04 | 接到需求任务，你要先做哪件事？](http://time.geekbang.org/column/article/75100)
|
||
|
||
Alexdown 同学提到
|
||
|
||
> 考虑到地位的不对等以及我的“人设”已经定型了，实施起来有点难度。
|
||
> [—— 02 | 以终为始：如何让你的努力不白费？](http://time.geekbang.org/column/article/74834)
|
||
|
||
这类问题很经典，很多同学留言提到，我就不一一列举了。
|
||
|
||
在我的职业生涯中，无数次听到不同的人有过同样的抱怨。我最初也觉得这是一个无解的问题，直到后来我读到了一本书。
|
||
|
||
管理大师彼得·德鲁克有一本经典著作《卓有成效的管理者》，虽然标题上带着管理者几个字，但在我看来，这是一本告诉我们如何工作的书，每个人都可以读一下。
|
||
|
||
当年我读这本书时，其中的一个观点让我很受震撼：如何管理上级。
|
||
|
||
什么？上级也可以管理？这对于我们这些习惯了接受上级指挥的人来说，观念上的转变几乎是天翻地覆一般。
|
||
|
||
在很多人看来，自己累死累活，只是因为自己的笨蛋上级，没有很好地处理好他该处理好的事情，还把“锅”扣到了自己的头上。
|
||
|
||
不过，在德鲁克看来，上级也是人，一样有着长处和短处。我们应该发挥其长处，减少其短处带来的不良影响。管理上级，也就是要发挥上级的长处，不能唯命是从，应该从正确的事情入手，以上级能够接受的方式向其提出建议。
|
||
|
||
具体到我们的日常工作中该怎么管理上级呢？我给你一些小建议。
|
||
|
||
**我们要敢于管理上级，**对上级不合理的要求说“不”，这是一个思想上的转变。很多人受到传统官本位思想的影响，对上级的服从达到了不健康的程度。勇于改变，是有效管理上级的前提条件。如果不从思想上转变，我接下来的建议都是没有价值的。
|
||
|
||
那具体要从哪些方面着手呢？
|
||
|
||
**第一，管理上级的预期。**
|
||
|
||
上级问你：“一个产品特性，你多长时间能做完？两天？一天行不行？”你想了想，如果不写测试，确实能够省下不少时间，于是，你决定答应上级的要求。是的，大部分人就是这么妥协的。
|
||
|
||
妥协很容易，但再往回扳就不容易了。下次，他还会再进一步压缩：“半天能不能搞定？两小时行不行？”人的欲望是无限的，所以，就不要让上级有错误的预期。
|
||
|
||
如果是我，我会告诉上级，这个压缩会影响到什么。比如，要想做这个调整，你需要放弃的内容是什么；或者，我可以给出一个快速上线的临时方案，但接下来的几天，我需要调整，让代码回到一个正常的状态中。所以，你就不要给我安排新工作了。
|
||
|
||
**这个过程，相当于我把自己看到的问题暴露给上级，让他选择。**他有更多的上下文，他会平衡该做的事情。
|
||
|
||
**第二，帮助上级丰富知识。**
|
||
|
||
不是每个上级都是经验丰富的，知道所有事情。比如，有些成长得比较快的负责人，自己甚至都还没来得及了解软件开发全生命周期。在IT这个快速发展的行业里，这是非常可能出现的情况。所以，在某些局部，你比他了解得多是非常有可能的。
|
||
|
||
在那些他做得不够好的领域，他肯定有许多烦恼。比如，盲目给需求的产品经理，可能也会影响到他对需求的判断。
|
||
|
||
这个时候，你就不妨把自己知道的内容找个机会给他讲讲。一个简单的方式是，把我专栏的内容发给他，和他一起探讨怎么做是合理的。然后，大家一起协同，改进工作方式。因为你是在帮他解决问题，他会更愿意接受。
|
||
|
||
**第三，说出你的想法。**
|
||
|
||
如果你什么都不做，上级会按照他自己的理解安排工作。比如，小李擅长处理消息队列，那消息队列的活都给他。
|
||
|
||
如果你有自己的想法和打算，不妨提出来，主动承担一些职责。比如，你接下来打算多学点消息队列，那就大大方方地告诉上级，下次有相关的活，考虑一下自己，上级再安排工作的时候，他就会多想想。这其实就是我们熟悉的一个最简单的道理：会哭的孩子有奶吃。
|
||
|
||
如果经过你的种种努力，发现你的上级真的是完全没法影响，只能以令人无语的方式行事，那你需要仔细考虑一下与他合作的前景了。
|
||
|
||
不过，更可能出现的场景是，你还没去尝试改变就放弃了，将全部责任都归结于上级的问题。如果你是这种思考问题的逻辑，不论到哪个公司，结果都不会比现在更好。
|
||
|
||
## 问题2：产品经理总拿老板说事，怎么办？
|
||
|
||
此方彼方Francis 同学提到
|
||
|
||
> 很多时候产品要做这需求的理由就一个：老板要的！
|
||
> [——01 | 10x程序员是如何思考的？](http://time.geekbang.org/column/article/74471)
|
||
|
||
西西弗与卡夫卡 同学提到
|
||
|
||
> 有的产品经理会使出必杀技——这是老板的需求
|
||
> [——06 | 精益创业：产品经理不靠谱，你该怎么办？](http://time.geekbang.org/column/article/76260)
|
||
|
||
用老板来“甩锅”，这在软件行业中特别常见。
|
||
|
||
实际上，老板要求的是方向，不是产品特性。大老板不会安排那么细的细节。所以，一个产品经理该做的事就是把老板给的方向，变成一个个可以实现的产品特性，他要分析其中的合理与不合理。
|
||
|
||
**不合理的部分应该是他和老板去沟通的，而不是让开发团队来实现。**
|
||
|
||
在真实世界中，更有可能的情形是，产品经理“拿着鸡毛当令箭”，老板说的是试一下，到他这里就变成了必须完成。他不敢对老板提问，就只能压迫下游了。
|
||
|
||
这种情况，你就不妨和产品经理一起去见老板。我们在[《解决了很多技术问题，为什么你依然在”坑“里？》](http://time.geekbang.org/column/article/76567)这篇文章中提到，要扩大自己工作的上下文，这种做法也可以帮助你解决问题，在自己上下文中解决不了的问题，就放到更大的上下文中去解决。
|
||
|
||
## 问题3：别人能做的，我们也要做
|
||
|
||
Xunqf 同学提到
|
||
|
||
> 当你和产品经理理论的时候，他往往会拿出来一个现有的产品给你看:“人家怎么就能做到，人家能做到说明技术上是可行的，做吧。”时间久了你会发现他的需求全是抄的的别的APP，然后就觉得别人能做到的我们也一定能做。
|
||
> [——《06 | 精益创业：产品经理不靠谱，你该怎么办？》](http://time.geekbang.org/column/article/76260)
|
||
|
||
你会发现，在这个问题里，提到了两个与产品经理交流可能出现的典型问题：一个是竞争对手有的产品，我们也要有；另一个是人家能做到的，说明技术上可行，我们也能开发。
|
||
|
||
我带你来分别看下，这两种说法你该如何应对。
|
||
|
||
**第一，竞争对手有的产品，我们也要有。**
|
||
|
||
没有哪个企业是靠纯粹抄袭成功的。我知道，你想说腾讯。腾讯当年做 QQ，从形式上看，是和 ICQ 极其相似的，甚至名字都是极为相似的：OICQ。但腾讯却做了自己的微创新，它将信息保存到了服务器端，而 ICQ 是保存在客户端的。
|
||
|
||
正是有了这样看似微小的创新，让当时大部分家里没有电脑的普通用户，可以在网吧里不同的电脑上继续自己的网络社交，适应了时代发展的需要。腾讯“抄”得好的东西，都是有自己微创新的，包括如今的微信。
|
||
|
||
**“抄”不是问题，问题是无脑地抄。**
|
||
|
||
所以，如果你的产品经理只想无脑抄袭，本质上，他就是在偷懒，没干好他该干的活。竞争对手有这个特性，他为什么要做？他做这个特性与它其他特性是怎么配合的？我们做这个特性，在我们的产品里怎样发挥价值？作为产品经理，你必须给我讲清楚这些。
|
||
|
||
即便我们最终的结果是，做的与竞争对手一模一样，经过思考之后的“抄袭”也是一件价值更大的事。
|
||
|
||
**第二：人家能做到，说明技术上是可行的。**
|
||
|
||
关于这一点，我不得不说，产品经理说得对。别人能做到，说明技术上肯定是可行的。
|
||
|
||
**不过，我们必须分清楚两件事：需求和技术。**
|
||
|
||
要做什么是需求，怎么做是技术。与产品经理要确认的是，这个需求是不是合理，该不该做。技术上能否实现，这是开发团队要考虑的事情，并不是产品经理说事的理由。
|
||
|
||
还有一种情况是，需求确实合理，但技术实现的成本极高，所需花费的时间很长。在这种情况下，你和产品经理之间很难互相说服。
|
||
|
||
解决方案是，将问题升级，放到更大的上下文中，让上一层的领导来决定，此时此刻，在现有的资源约束下，是否要按照这种方式做。同时，你最好再提供一个可选的替换方案，这样领导才能更好做选择。
|
||
|
||
还有一些同学问了很好的问题。比如，程序员充当了太多角色，很困惑。这个问题我在专栏中已经回答了，在[《 接到需求任务，你要先做哪件事？》](http://time.geekbang.org/column/article/75100)中，我们说，每次扮演好一个角色。在[《 解决了很多技术问题，为什么你依然在“坑”里？》](http://time.geekbang.org/column/article/76567)中，我们提到程序员应该多了解不同的角色。
|
||
|
||
还有人问，计划赶不上变化快，怎么办？简单回答就是靠任务分解，因为这个话题涉及到“任务分解”这个模块的内容，等这个主题讲完之后，如果大家还有疑惑，我们再来详细讨论。
|
||
|
||
好，今天的答疑就到这里，请你回想一下，你在你工作中是否也遇到过类似的问题呢？你又是怎么解决的呢？欢迎在留言区写下你的想法。我会从中筛选出典型的问题，与大家进行互动交流。
|
||
|
||
感谢阅读，如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给你的朋友。
|
||
|