最近项目已经进入开发，也算是稍微可以给自己一点时间，抽出来更新笔记谈谈小感悟了。进入新公司1个半月，这2点感触最深：
1. 别因为开发难度而妥协。
上上周在做 APP 后台时，对于一个功能的交互跟我司某“资深”开发争执最大。这个功能是这样的，在我们的 APP 首页上，对于课程的展示，我们设计了“推荐区”，可以理解为像是商场里的一个货架，你可以自定义这个货架的名称，比如“XXXX年度人气”，然后往这个货架上放课程。于是为了后期运营的灵活性，我们对于推荐区的名称、推荐区的排序、推荐区内推的课程以及课程的排序都希望可以做成自定义的。于是后台我设计成了这样：
点击 图1 的“编辑”，进入如下页面：
可以编辑该推荐区的名称，然后再往推荐区添加课程，点击添加课程：
于是对于编辑/新建货架以及往货架塞货物的操作一气呵成。
然而“资深”开发不乐意了，他搬出了以往类似业务逻辑的页面来“教育”我这样的是“不好”的。而以往对于类似业务的处理大致简单描述下就是：先在一个页面建货架；然后再去另一个页面塞货物，并且这个赛货物的页面是一堆货物的列表，你在没有进行任何操作的情况下根本无法一眼识别出哪些货物在哪个货架上，还得通过各种筛选的操作查看......这简直反人类。于是本汪的小情绪就来了，虽说是一个内部用的用具，但不代表可以马虎到可以毫不考虑操作便利，甚至为了开发可以少干活而选用反人类的方式。“资深”开发对我甩出了一堆理由，归结下来就是一句话：“开发起来麻烦，需要更多的时间，但是项目时间安排得又十分紧张，要想我们按时交工，必须得按我说的来。”相持不下我只能求助组长，我们试图讨论出两方都可以接受的方案，然而这位开发在讨论末尾又开始 argue 工作量。大概组长也是不能忍了，“我们的需求设计和安排上次开会就已经定下来了，如果你觉得开发上有难度，XXX（部门老大）会负责协调，是找别的 team 帮忙，还是找出更好的实现方式，提高效率。但是这是你们开发该考虑的事情。”
此前的工作中，我总是会下意识地考虑开发成本，在评审需求的时候，总会问上一句：“这样开发难度大不大？能不能实现？”大概是因为在 lls 的那段时间曾多次看见各种会议上产品经理和开发们争得面红耳赤， CTO在电脑前咆哮：啊！我要杀了产品经理！此后的很长一段时间，开发们总像是跟产品们结下了多大仇似的，于是那个时候就留下了心理阴影。当然，出现这样的局面原因有很多在这里就不探讨了。
后来在 wf 的时候， Yorkie 给了我一句建议，现在让我回想起来都感觉很暖：“建议你多从用户体验和产品的角度考虑问题，而不要太多考虑开发实现上的问题，不管怎样开发都是可以做的。” 这句话体现了跟现在我司这位“资深”开发截然不同的工作态度，当然这不是一篇批判文，而你身边的同事也有自己的自由去决定如何对待工作，并不是每件事都如你期盼的那样完美。
产品和设计的思维本身就是天马行空的，这里并不是说完全不考虑开发实现成本，而是在现有逻辑都考虑顺畅的情况下，去努力大胆创新，不要被太多的顾虑禁锢住，而如果过多被开发限制，那你大概是不会有任何创新的可能性了。
2.做一个产品经理该做的事，你不是功能经理。
在 lls 的时候，大概是一直习惯了接老板的需求，某个时期，老板突然要做一个功能，然后被委任“产品经理/专员”，就开始着手立项了，而且大概是自带某种下架属性，之前过手的项目或功能最终都被下架或砍掉了。
这次终于不一样了，公司老板不会过多具体干预产品。在组长的影响下，我们一步步找到了自己在公司业务当中的定位，慢慢挖掘我们应该和能够为公司产生的价值，再朝着公司的战略目标，找出该着手的战场，再去调研、思考、讨论具体的方案，可能是一个新产品或新功能或者其他。并且当我们把想法拿去跟老板讨论时，老板大大给出了高度的赞赏，只要方向和想法是他想要和认同的，接下来的事情就交给“产品经理”这个角色去做了。
这是第一次让我最深刻体会到什么才是“产品经理”这个岗位应该存在的价值。明确方向，找准策略，确定方案，推进项目……而不是一个功能的翻译机器。
最后，我真心觉得现在这样挺好，有更多的主动性，也有更多的可能性，还有，可以抽出时间做一点感兴趣的小设计。
好了，今天想说的就是这样了，浅薄之见，不喜请轻喷^_^
