#思考 公司趣事
明天就要上大版本了，前端，后端，测试大家都忙得不亦乐乎。
“思涛，快过来。有个问题找你确认下，快来快来～”
在叫我的是我们新晋产品经理：蘑菇，刚刚从我们开发团队转型做产品经理。
“稍等下，过来了”，我不急不慢地走过去。
“思涛，这个提示文案提示得不对啊。为什么没有title呢？”
“没有吧，蘑菇。这个页面的提示文案就是长这个样子啊。橘子，你把PRD文档打开给蘑菇看下”。橘子是我们的测试妹子。
“我不管，我就是要这个提示文案”
… …
… …
然后我和蘑菇同学就开始了唇枪舌战，一顿争论后。我服软了，开始看代码，看看怎么改代码（没办法，产品最大）。看了一会儿后，我发现这个代码没有这么简单，文案和code都是耦合在一起的，所以我不敢随便修改了。
最后只好跟蘑菇说，“蘑菇，这个代码没法改，只能明天找架构聊一聊才能修改。文案和code 是有耦合关系的”。
蘑菇只好无奈地说，“你就今天改掉嘛，还等什么明天。”
……..
然后又是一顿争论，最后在我的坚持下，代码还是明天等和架构讨论完后再修改。晚上下班的路上，我就开始回忆关于这件事情的过程。自己的沟通，自己的表达，自己的态度是不是存在问题？然后又想到蘑菇对这件事情的处理是否存在任何不妥。然后越想就一发不可收拾，根本停不下来。
首先我想到的是蘑菇同学对于这件事情的态度有问题，Ta并没有主动承认这个问题属于需求变更。换句话说，Ta并没有直面自己的错误，Ta在逃避。因为在整个过程中Ta都没有主动强调这个属于需求变更，我自己也有问题，我也忽视了这一点。然后又联想到了最近蘑菇同学靠着和我们团队成员的关系（蘑菇以前是我们团队的人），居然直接把需求变更发给我们开发，让我们开发改“没有任何邮件的需求变更”。然后我突然就楞了一下，然后意识到——我们和蘑菇的交情，不应该成为蘑菇产品经理道路上的绊脚石。蘑菇同学这是在玩火，不能这么玩的，这么玩Ta只会自己坑自己。慢慢地，Ta会养成一个习惯，认为测试阶段发生的需求变更没什么，反正开发团队和我的关系好，我一句话他们就改完了。需求变更没什么的，没有什么不好意思的，产品文档肯定会有需求变更的，不可能在设计阶段考虑得那么全面的。于是在下次PRD中，Ta也不会考虑得那么全面，反正后面发现哪里有逻辑漏洞，遗漏细节，我和开发说一下就搞定了，都不用上升到需求变更的层面。这样的话，蘑菇同学的PRD质量只会越来越差，不会越来越好的。
然后，我又想到了我们公司小明和蟋蟀的故事。
小明
小明，男，二十四岁。工作中的小明是这样的一个人。
只要你有机会在公司走廊中遇到他，都不用看他的脸，都能猜到他当时的面部表情——没表情；你欠我钱还没还；别看我，没心思和你打招呼——永远都是这一系列的表情。
工作中小明给人的感觉就是——得理不饶人，与他人沟通时咄咄逼人，更何况有时候他以为的理还不成立。这就是小明平时工作中的状态，然后一直如此，从来没有任何改变。
终于有一天，大部分同事们都受不了小明的沟通方式了，集体反馈小明的沟通问题，最后小明被辞退。
小明的辞退结果没有什么意外，我们好奇的是小明的性格是如何养成的？
至少有一点是可以确认的，他成长过程中没有遇到一个“执拗的好人”告诉他这样的性格与人相处是有问题的。从初中、高中、大学、到工作，从朋友到同事、到兄弟都没有。再或者有人告诉他了，他自己不以为然。
蟋蟀
上次常规，蟋蟀有需求要上生产，所以没有正常下班。计划着等上完生产验证一下没问题了，心里的石头落地了，他的需求才算上完生产了。
“发包完毕～”。
蟋蟀大哥开始验自己的需求。噫，怎么我的广告图怎么出不来，赶紧反馈给开发。攻城狮开始破案，最后发现所有的图片都出不来了，因为是前端没有改图片的接口。后来前端紧急发包，最后常规才算真正发布完成。蟋蟀大哥功不可没！
要知道，蟋蟀大哥以前可是大版本上线都不在的人，变成现在连一个小小的常规发布都有始有终负责到底的人。
揣测其中的原因，无非就是以下几点：
1，被我们开发部门的老大“骂”多了，所以责任心强了很多。
2，产品评审会上，被我们开发diss得多了。密密麻麻写作文似的产品文档；订单列表页还要坚持放取消按钮的坚持。。。。
以上，得出的结论是。当某人在工作中的存在的问题，平时工作相关协同办公的同事应该一起帮助他，把我们发现的问题告诉他，提醒他，监督他，大家共同成长。这才是一个团结互利的团队。
思涛 2017年09月30日00:16:11