工作过程中，专业技能没有那么的重要，最重要的是解决问题的能力。
从八月份开始接触onesdk，到现在快俩个月的时间。从零了解到现在熟悉了基本的流程和业务，学习的时间有些慢了。在这个过程中，也认识到自己的好多问题。
onesdk分为三个模块：客户端、打包工具、官网(前台、后台)。第一月，我的关注点只在打包工具和官网的前台展现上，具体的实现以及整个产品的认识(产品整体方向和三个模块联系)都没有去深入了解。以至于作为onesdk的产品经理，对整体产品都不了解。第二个月，leader在产品会议里面拎出我来：你对产品的整体规划一点都不了解，具体每个模块的进度也是未知。其实事实的确是：就算是单纯的前台界面也没有做的很好，前期和team沟通严重不足。
后面这几周的时间，我尝试去梳理整体的业务流程。产品的整体规划，产品时间节点，去和技术沟通具体的实现细节以及一些不明确的需求，每周尽量去确认相应模块的时间节点和任务状态。
list一下最近的处理方法，这样解决问题还是比较高效的：
1、专注产品，关注产品的目标。
2、完成产品规划表，列出产品任务(待处理事项)优先级清单以及相关配合部门
3、发现问题，找到关键节点，积极主动解决
4、找到问题相关责任人，具体落实问题细节和交付物
5、在交付时间内落实交付产品及质量
6、调整已完成清单列表，重新梳理优先级列表
7、及时根据产品运营和后期规划的变化调整产品计划表
过程中遇到的问题及我犯的几个错误：
技术类问题：由于是一个技术类工具，前期参加产品技术会议的时候，我对具体的细节处于不知状态。框架实现，具体参数，细化功能...后面和技术沟通了之后，才明白具体前台展现如何。解决：及时和技术沟通，不懂实现无妨，但是要明确前台展现，以及和其他模块可能的关联关系。
需求类问题：工具类产品大体的需求方都是技术研发类需求，作为产品的我筛选需求的较少，主要集中于页面的呈现和流程的优化。但是产品的流程优化方法，不一定适应于技术的实际操作，好些矛盾。解决：提供几个选择，供技术选择。
UI类问题：前期是借鉴其他产品，所以功能和UI相似的概率比较高。在网站和工具的设计过程中，第一版本是参考其他，整体团队的反馈都说太相似；后面UI从新做调整，也跳不出相似的框架来；以至于UI要求我换人从新设计(我也无奈了，和UI沟通的时候：发现自己有时候仅列出一个框架，所有的形式都要UI去构想，但是这样的做法，仅适用于部分UI人员；大部分的UI都只会去按照原型做东西，基本不会有太多自己的想法)。解决：现有团队，尽量细化原型细节点。
运营沟通问题：1、前期基本上没有和运营沟通，后期涉及推广的时候，也是leader的提醒下，我才去主动和运营沟通产品细节，这一块，太失职了。2、作为产品，在整个产品过程中，没有做到主动去主导整个产品的过程。运营介入了之后，从命名到产品规划，从外界看，都是运营在主导(其实作为一个技术工具类产品，运营只是产品的辅导)。3、运营其实对产品的了解不足(因为当前产品较多，运营对各个产品的区别都不是很了解)，这个是整个产品部门的缺失，对整体产品的划分不明确。解决：产品应该主动整个产品，list出产品线内容、让运营明确不同产品推广规划和集合点。
和leader的沟通问题：前期对于页面策划和设计图，我都是具体完成了，才去汇报沟通；其实几次的汇报下来，效率极低而且修改很多。解决：原型或者UI有初期的效果之后即可确认或者评审，在边做的过程中边调整。后期的汇报的沟通的过程中，大体的工作及时汇报；每周都做产品的汇报。
关于产品的问题：作为产品，我的大部分时间都在：项目进度跟进和现有产品完善，对于产品下一版本的规划想法很少。而且一直以来，对新产品的敏锐度、对行业发展的嗅觉、如何商业化这些思考的都不够。解决：及时根据需求的反馈，做好下一个版本的迭代规划和计划；多关注一些行业内容，切实到每周做一项相关行业分析报告。
