标签：char 服务器 处理 批评 chat 项目 相关 核心 意思
PS：此文为个人认知，不足处请多多批评。
近期在一线leader（经理）身上发现了几个case，然后又回想起前几年自己做的一些傻事，可能都属于明面上leader不会说什么，但私下会有情绪的类型：
Case 1：下游背锅——声量小的成本。
有一次作为技术负责人跟一个产品线leader（某一条产品线负责人，非总产品负责人）去开会，讨论我们是否需要采购一套系统。
首先，系统各种信息，对面公司都不愿意透露太多细节参数，所以很难做判断，然后对方明确表明不会提供源码，只愿意开放KPI对接，而我们自己业务方甚至有些二五仔的一直催着赶紧上系统。
作为老司机，我当然微微一笑，类似这种不明不白的系统采购进来绝对是坑自己的技术兄弟，但是技术层面一般来说没太多决策权，只有风险预警和方案选择建议，于是便push产品leader正面回绝。
谁知这个产品犊子（产品果然是技术永远的敌人），说了几句“不合理”、“不合适”、“有冲突”、“我们有这个功能了”，之后便全程被业务方盖住了声音，于是产品端口的控制权便旁落给业务方或者产品端口开始事实上的缺位了。
我见势不妙，急忙说了几个实施难点，以及准备了一个清单，让第三方准备，不愉快的结束了会议，不做任何承诺，先搁置。
事后质问产品leader为什么不硬刚，你知道接进来成本多高的时候，那狗犊子来了一句，我已经说了啊，他们不听，我有什么办法，我懒得跟他们争......
这傻犊子，不知道他的所谓不争会导致技术团队好大的坑......
Case 2：事不关己高高挂起。
某条线的业务方（非上述业务方），之前着急忙慌的跑模型，非要去外面采购一套系统自己运营。
一段时间后，找着我们CTO（我的leader）哭闹，说是外面系统太不稳定，性能也差，数据稍微上量后便各种卡，外包团队的意思大概是服务器有问题，他们没法解决。业务方现在希望部署回来，并且以后由我们维护迭代......
这个业务线并不是我们核心业务领域，属于可接可不接类型，考虑当前资源情况，和后续的坑点，当然是尽量不接呢。刚好，这个事情又落到了上面那个产品leader手上，这瘪犊子可能认为坑主要是技术团队的，又是CTO倾向接住的业务，便又开始事不关己高高挂起了。
于是，得罪人的事情又落到了区区在下身上，这里是直接阐述了该项目有哪些风险，以及我们当前的资源瓶颈，最终只答应帮忙部署到我们自己服务器，但是维护以及迭代不会参与，由于态度有些强硬，我私下瞟了下CTO脸色貌似不太好......
最后，此事也确实慢慢无疾而终，没产生什么影响。
Case 3：无来由的锅——好人我做，背锅leader来。
这个Case来源于此文原型：【周复盘】复盘机制如何在新团队落地？
这里其实还有一段聊天记录，大概是这样的：第一次产品同学做CaseStudy，有点担心是批斗会，不太想参加，于是质效leader将这个锅算是完全的抛给了其leader。
很简短的对话中，其leader（区区在下）被连续当挡箭牌工具人用了两次，而且类似这种案例在很多场景下发生......
Case 4：跟着躺平——一个团队不能有两个思考的人。
我这边接手了一块产品业务线，于是与原来该产品线leader说了下分工，大概意思就是我是过来学习的，也能给团队提供更多的资源（技术资源也是资源啊！），初期我会有一些规划，团队内的工作你自己继续管理，之前的规划也继续做，不要等我，于是在愉快（真的愉快）的相处下，进入到本周周会。
周会上，我发现一旦是该团队有疏漏的地方，这位产品leader，自然而然、骄傲的说道，这块XX哥会做规划，这块XX哥下来会组织，这块我下来跟XX哥聊聊，听听他的意见，这块XX哥说不需要提供......尼玛，我马上又成为背锅侠了！
PS：这里要注意，这个产品同学绝对不是因为不满意我的存在而这样说的！
总结下来，出现这种情况的主要原因是：
团队中如果出现一个新leader（可能最强的人）后，那么其余人甚至是之前的leader，更倾向于停止思考，事事请示，躺平等待带飞...
以上Case，如果对应权责利模型，其结果貌似又是很合理的，但都有点奇怪的是，这类同学在晋升，或重大机会来临时往往不会被作为首选，甚至可能会被认为没有担当，责任心、有担当对于往后的路，都是重要的特质，因为会遇到更多可做可不做的三不管情况，如果再进一步的时候，这种锅该怎么甩呢？
PS：这里是说通用情况，不是针对上述同学！！！
其实上述同学能做到leader还是很聪明的，一定是其“本质”工作做的没什么问题了，专业知识不会有太大问题，但是有些“聪明”在很多模糊地带，三不管地带，甚至明确非自身领域的偏冲突地带就会被着色，什么“老好人”、“不得罪人”、“和稀泥”之类的法宝慢慢就出来了。
“事情到我为止”、“事事有回应，件件有回响”也未必是完全正确的事情，我们要不要做一件事情，有一个标准；我们要把一件事情做到什么程度，也要有自己的判断。
有些事情，多做一点深陷泥潭；少做一点又满盘皆输，这个度便是各位leader要修行、要掌握的要点，这可能就是所谓管理的火候吧，需要知行合一，多加修炼！
下面提供一个日常案例结束此文，仅仅是抛砖引玉。
最近出了一个case：
在我们的业务中有【自营店】以及【合作店】两种用户触点，自营店各方面成本最优、体验最好，但不能保证总是有足够的存货，所以有时候依旧需要从合作店拿一些货，这里涉及到拆单，会产生额外的物流成本，用户多次收获体验也不是太好。
对应销售部门本身有成本压力，不希望有这种成本浪费，于是反馈到产研这边来了，处理的产品同学大概是这样回答的（PS：这里不方便透露业务详情，只列概要）：
1）描述情况；（这点没问题）
2）描述销售部门期望情况；（作为简报，这点也没问题）
3）产出结果；（这里问题就来了）
这个同学（我那条产品线的...）直接求助到产品负责人了，也没提什么具体的方案，就把作业全部交给leader了，我这里当然是先喷啊（不能等别人骂）：
于是，下来找到该同学落实了下处理节奏：
1）详细描述该问题出现的原因；
2）提供自营店、合作店近2个月的数据情况，合作店销量的占比；
3）综合【成本】【毛利】【用户体验】【收入规模】等因素做出一个基础的决策模型；
4）给出临时短期方案建议；
5）给出长期方案规划；
6）与供应链侧达成共识，与销售端口达成基本一致；
7）发出邮件，开始实施......；
这里有几个点要注意：
1）具体到产品线的某个领域，你的leader比你更专业的概率很低，你要提供相关的建议，以及支撑建议的相关论据，能数据化、多维度数据化最佳；
2）思考解决方案的时候，至少要思考多一步，比如上诉问题，首先是销售策略问题，其次是产研设计问题，而最终可能是整个公司的供应链服务能力，要切实解决这一切，要从基础的供应链侧全链路优化；
无论从专业度还是“担当”这个点来说，尽量不要让leader决策，尽量不要拿leader当工具人（傻逼或者救世主），除非自己确实拿不准；
碰到具体事项时，尽量别让leader帮你思考，也尽量别让leader帮你背锅，如果可以的话，请尽量别让下游团队帮你背锅，提供你的专业意见，提供你的【决策模型】，提供你对当前事项决策所用的论据，最后跟相关方尽量做到信息同步，再请leader拍板即可，这里所谓的担当更多的是对你自己，未必是对你leader。
标签：char 服务器 处理 批评 chat 项目 相关 核心 意思
原文地址：https://www.cnblogs.com/yexiaochai/p/15068576.html
