一、
手边一个项目，是从别处接手过来的。经过几天开发，进入测试流程。
既然测试，就代表项目已经稳定，除了bug修复，不会再有新的需求。
但产品试用的时候，发现输身份证时软键盘没展示数字，提了禅道。
我在浏览bug时看到了，心里不乐意，找负责人沟通。
我主要表明了两点，1 原项目里没这个需求 2 即使增加也应该在开发阶段而不是测试。
我语气里的抱怨，负责人当然感受到了，安慰说好改的话就顺手改了吧。
抱怨归抱怨，改还是要改的。
我以为也就这样了。
第二天晨会结束，我找产品沟通另外的问题。负责人正好在附近，看见了，直接参与进来，顺便和产品说，“xx反映的确实是问题，没提的需求她当然不会做。回头你把常用输入框需要的软键盘输入类型总结下，写个文档，之后输入框直接按总结的来做就行，你也不用每次都注意这点，xx也不会漏做”。
旁边的我惊呆了。没想到我的抱怨在负责人那里居然变成一条意见，他居然还为此想了解决方案～职业素养立马可见。
我学到两点，1.不受同事情绪影响，只关注问题。2.不仅仅只是注意到问题，还要想方案解决，避免问题再次发生。
后来我也反思，出现“测试中提新需求”这种问题，产品也是无意。她入职没多久，没使用过之前版本，当然不知道是否有问题，万一该有的需求已经做过了呢？！工作上打的是配合，配合的条件是相互包容，这点我以后注意。
二、
重新理解了“产品经理与开发是死对头”这一经典话题。
转变发生于订阅了二爷的《邱岳的产品实战》。
改禅道上的问题，有一个是流程优化相关的。正改着呢，脑袋里默默流出这样一个想法～“产经站在用户角度，瞄准的目标是应用好用，节省用户的使用成本。开发是苦劳力，产品出优化一下，之前开发的成果就付诸东流了。产品提需求，开发不愿意改，矛盾自然就产生了”。
角度不同，是矛盾发生的根本原因。
看了二爷的产品实战，尝试着从产经角度理解问题，以后发生矛盾的概率应该会小很多，当然不可避免开发的工作量也会增大很多。一款产品的成功，决定于用户的使用，当然用户的使用体验更重要，这也是产经的职责所在。开发当然也要为用户体验全力以赴，而不能只关注手机的所谓“技术深度”。
三、
多看点书总是有好处的，书里的智慧会默默影响你的思维。
就像上边的，完全是在看了《产经实战》后生出的想法。
