零、背景
本文灵感来自《人人都是产品经理 2.0》
位置：7.4.2 如何做一个让 Ta 们讨厌的人
作为一个研发，工作过程中如果能及时发现如下场景，
及时给对方负反馈，否则受伤的是整个团队。
看了这本书之后，感觉对产品有新的认知，
知道他们在做什么，怎么做，后续可以更好的与他们沟通。
而且里面的内容对于研发来讲也是适用的。
一、开始实施之前
1.1 不说清需求价值
技术问”为什么要做”时：
1、时支支吾吾
2、这是老板(XXX)要的，假装自己是个传话筒
3、我接的是二手需求，什么都不知道
随说：其实正确的做法是追溯这个需求的初衷，有利于评估 ROI (投入产出比)，以及排优先级，以及增进对业务的理解。
1.2 不去想细节功能
技术问细节(业务细节，非技术细节)时：
1、装作自己完全没有想过
2、那就这样做
3、肯能那样做也可以
4、要不你来定吧
随说：这些表现其实都是不负责的！没有明确的需要，后期容易扯皮，也可能做出来的东西有问题。
1.3 帮技术评估工作量
1、这不是很简单嘛，就改个 XXX，几行代码就搞定
2、这些我都评估过了，都能做
3、不要偷懒，不要忽悠我，我抖动
随说：评估真是个高难度的活，往往只见树木不见森林
1.4 逼着技术团队承诺
1、任何时候只知道公事公办，技术承诺了却做不到，自己就没有责任了。
随说：互联网企业更多的只是一个”预测”，而非”承诺”，因为变化太快，承诺是技术对产品的责任，而预测是产研一起担责。
二、实施过程中
2.1 做了一半改需求
1、经常在某个迭代周期内做”非受迫的需求变更”，这招杀伤力很大，技术同学一般受不了。
随说：非受迫，意味着是产品没有想清楚，然后导致研发无谓劳动。万万不可取。
2.2 开发过程中消失
1、可以想各种办法隔绝与研发的联系。
随说：一般都需要多次沟通，反复确认细节。
2.3 过度关注细节
1、帮技术确定各种技术方案，这个应该这样实现…
随说：这种一般少见，研发转岗产品的多一些
三、产品发布之后
3.1 没有发布后的反馈
1、发布之后，犹如石沉大海，不告诉大家任何结果，甚至庆功宴都不叫 Ta 们，紧接着继续安排他们干活。
随说：技术人员也需要从市场、用户那里获得反馈，从而对自己做的事情产生价值感和成就感。
3.2 任务无节奏感
1、让研发一阵忙一阵闲，发布之后再开始研究接下来做什么。
2、一会儿让研发有着天天通宵的高强度，给 deadline，下死命令，做完之后不知道做什么。
随说：保持合理的安排，让研发有个合理的预期比较好。而不是等你们上了大学就自由了这种…
四、全程适用
4.1 优柔挂断
1、你定吧，你说往哪儿走我们照办
2、啊…那个…方案各有利弊，我也不知道怎么办，你们有什么好想法
随说：自己左手和右手互搏，思考清楚之后给大家一个明确的结果。
4.2 报喜不报忧
1、藏着噎着一些坏消息，eg:老板正考虑干掉这个项目等，大家只能通过小道消息得知
随说：这样很破坏信任感
4.3 不把 Ta 们当人看
1、只关注结果，不关注人的成长，永远把合作伙伴当”资源”
随说：结果导向没有问题，但是没有成长，留不住人。