其实我这个人比较笨，很多事情需要亲自尝试或者体验了之后才能理解，所以这些年工作下来尝试和体验过很多方向。虽然谈不上好学，但是这些年磨炼出来观察、抽象、反思的能力。最近和很多小朋友聊天发现其实很多问题都是通病，这里也把我踩过的坑都总结一下，感兴趣的朋友可以看看是否可以少踩坑。
准备技术、产品、销售、运营、人力资源、财务几个方面来谈谈不同的理解：
先说技术，因为做技术时间最长也算全栈工程师，做过前端、后端、客户端，从程序猿干到架构师，从架构师干到研发经理。技术同学最单纯，他们脑子里面想的最多的就是抽象、抽象、抽象、复用、复用、复用。而且经常不能理解业务和产品经常为什么会提很多重复需求或者看似无理的需求。因为技术是业务实现的最后一环，所以技术同学最关系的就是可实现性。我做技术的时候其实会关注两个方面纯技术框架复用和提升和基于业务的技术架构解决方案。我的理解不一定对，我认为框架部分其实没必要重复造轮子运营开源项目是最好的解决方案，没必要从底层重新构建，除非目前的框架不能满足业务体量的支撑。天朝大多数项目都属于应用层的项目，所以在架构设计上面是非常有挑战的，架构的设计取决于的业务的理解，只有对业务足够的理解才能很好的抽象各业务能复用整合的部分，并预留弹性的发展空间。业务永远是变化的，所以原来适应的一套技术架构和框架当业务重组的时候有时候也会成为瓶颈，因为相较于重构业务流程和组织结构，重构技术架构和平台是非常困难的。互联网公司技术是核心竞争力，因为技术是最大杠杆。
再说产品，干“产品”这个角色也快8年了，因为技术出身所以更擅长信息、工具、商业类产品，因为社交白痴对社交产品不来电。做过用户产品，现在在做商业产品，现在发现商业产品还挺适合我的，因为这个里面要解决的问题更多，很多情况不是纯“产品”能解决的问题，这个里面更多需要怎么结合行业和公司现状来看问题，产品只是最后的表达。产品经理这个角色是1927年宝洁公司创造，其实最早那会儿在国内互联网公司没有产品经理这个角色，原来在软件行业大家叫这种人需求分析师，依稀记得好像在Google起来之后这个岗位被固化下来，主要是把原来的需求管理和项目管理两个职能做了一些结合。其实很多产品经理只能称之为功能经理或者模块经理，真正去理解“产品”的产品经理真的不多。大家所看到的产品更多是需求的具象表达，但是产品是为了解决那个Product背后的人需求问题。既然产品背后是人的需求，人又是一个善变的动物，产品永远都在尝试去找到当下最优那个解，或许永远都找不到，所以只能最小代价的不停尝试。所以产品经理不要总盯着眼前那点事儿，想想真正帮用户、帮客户、帮公司、帮行业解决了什么问题。
BTW:这篇文章写一半没动力了后面几个角色不想写了，就这样吧！
