来M公司刚好四个月，实习接近尾声，想对这段时间的工作做个总结，回顾这段时间收获的同时，也为即将到来的秋季校招打下基础。主要分四部分进行总结，一是谈谈这四个月在M公司参与的几个项目，二是对M公司整体的感受，三是对如M公司这样2B产品工作的感受，最后谈谈对产品经理这份职业的感受。（前两部分可能像流水账，嫌麻烦的可以从第三部分看起。。。）
一、所做项目感受
由于最初被分配到采销产品部门，且公司业务为自营B2B生鲜，因此主要需求就是内部业务人员提出的，设计的是供内部人员使用的系统，因此产品设计追求的是业务流程的合理性，能够跑通流程，对现有的业务设计出供业务人员高效使用的系统，帮助公司业务线高效快速发展。
至今，参与过三个项目：1.供应商评价体系设计 2.供应商平台web设计 3.供应商POP
1.供应商评价体系设计
刚来公司接触的第一个项目，需要考虑从几个不同的维度去评价供应商的，还需要与其他系统结合，考虑每个评价维度的数据来源，其他系统输出的数据是否可以用来对供应商某一个维度进行评价。通过设计数据与数据之间的组合方式，每个维度输出一个评价公式，要谨慎考虑公式的合理性，公式中的数据来源是否合理，是否会存在漏洞（主要是防止刷分，防止作弊），在业务上是否能客观反应出供应商的优劣。
最重要是，想清楚为什么要如此设计某一项评价维度，根源来自于哪？对公司业务有什么影响？多想想为什么这样评价，才能设计出更好的指标，从而促进供应商能够“良币驱逐劣币”，提高供应商的整体水平，更好的支撑公司业务的发展。
在此项目中，我最开始查阅大量资料，主要了解了现在主流的供应商评价体系，体系中都分了哪几个部分，各个部分之间的关系是什么，各个维度都是通过什么数据来衡量的。结合采销系统（SRM PMS WMS等系统），思考了系统产出的哪些数据可以用来设计指标，就这样圈定了一个大范围，然后再思考了优先级和指标的必要性，最后决定先设计价格评价指标（在已有评价体系的基础上添加了价格指标），将价格拆解为两个方便：价格竞争性（高低）和波动性（浮动情况），通过PMS中供应商报价的各个数据设计了两个指标的计算公式，将报价情况转换为两个指数，来反映供应商在价格方面的表现。在组内前辈的指点下，对公式进行了一些修改，问题主要在于没有考虑一些极端情况，导致指标的公式出现漏洞。
收获：设计任何产品功能前，思考为什么要设计这个功能，这个功能如果设计出来能带来哪些好处，影响了其他哪些模块；要考虑不同的情况，不同的情景，穷尽思考，以保证功能不会出现漏洞。
2.供应商平台web
在这之前，公司的供应商管理都是内部人员（通常是采购）替供应商进行管理（包括注册、资质合同、商品货架管理等），系统为内部系统，而为了尽快搭建开放平台，供应商管理需要由自身来管理，同时开放外部注册，将内部模块都放到对外开放平台中。将内部功能搬到对外平台，这其中就涉及到内部与外部的定位不同，功能权限也有所差异，比如：一些内部系统开放的功能，肯定不能开放到外部平台；一些内部系统直接操作的功能，外部平台进行操作时就要有所限制（如审核等）。
当然这个项目最重要的是定位问题，对外的供应商平台今后是否将会发展为卖家平台（或者说是类似阿里巴巴的商家后台），而加入采购商城为买家前端，结合起来就是一个很大的B2C或B2B平台。定位决定了很多功能做不做，很多功能以怎样的规则逻辑去设计，这方面我还没有一个清晰的认识，对公司整体业务的认识不够深刻，导致这方面我无法深入思考。
3.供应商POP平台
对应着供应商自营平台，就有供应商第三方平台，不同的是第三方属于纯平台性质，供应商可以直接将商品通过第三方平台审核后进入商城进行售卖，这样就没有了供应商自营平台中的很多业务模块，比如：合同管理、结账管理等，但也相应多了如评价系统的模块。产品设计基本上需要在供应商自营平台的基础上进行修改即可，不过由于业务性质的不同，第三方平台的定位、目标、业务规则、后期的运营策略都没有定下来，因此产品也被高层领导暂时block了。
在项目进行过程中，我主要辅助产品经理梳理了POP的模块和流程，在这个过程中参考了京东、阿里巴巴等2B的平台设计，不过需要注意的是M公司主营的很多产品都是非标品，这与京东有很大不同，导致产品设计上会有很大区别，且为重模式，因此也与阿里巴巴不同，所以在借鉴其他产品的时候也需要时刻考虑到自身业务的特点，吸取可以利用的产品设计方案与自身业务相结合，才能达到更好的效果。此外，在基础设施和基础决策未确定前，对这种公司内新兴业务的扩展，也需要十分谨慎，不可贸然进行产品的设计与开发。
二、对实习公司的感受
M这个公司的整体业务模式与美国sysco类似，均为生鲜食材B2B售卖，且都是自建物流和仓储的重模式（类似于京东），一方面靠地推销售先对各个小餐厅进行宣传获取买方用户，另一方面采购进行供应商洽谈，寻找各个品类的供应商获取卖方（对于M公司是卖方），而M就充当中间角色，建立平台整合买卖双方的需求，努力提高供应链效率降低供应链成本。因此，这个平台就需要庞大的后台系统来支撑，面向买方需要有商城系统，面向卖方需要有供应商平台，而衔接这两者中间的系统就数不胜数了，包括仓储管理系统，订单管理系统，采购系统，商品管理系统，财务系统，支付系统等等。
整体业务飞速扩张的同时，内部系统也在慢慢变得庞杂，我所在的采销产品部门也是其中之一，从我刚入职只有两个产品到现在有六、七个产品同时进行开发（已入职四个月），产品线扩张速度不可谓不快。而且采销产品涉及的业务与其他很多系统相关，在开发进度上很容易受到其他相关系统进度的影响，当你开发进度快时，若其他产品进度没有赶上你的节奏，那么等待你的可能是产品的暂时block，若无法保持接近的开发速度，必然会造成如此的互相拖累从而影响业务产品推进的效率。实习四个月来，我也深深感到公司一旦规模上来以后，必然会造成效率的下降，无法再想小型创业公司那样对产品进行迅速的反应和迭代，这是来自于多个方面的。一方面是由于人员组织架构庞大后，沟通效率下降，二是由于业务产品线扩大后，你的产品改动可能会影响其他产品线甚至影响整个公司业务，因此产品的改动迭代必须谨慎再谨慎。在我参与的一次产品测试中（该产品功能属于商品系统），就是由于商城系统的开发进度没有跟上，导致测试上线工作推迟了两周，还有就是财务系统的业务规则迟迟不定导致采购系统中的账单和发票管理模块开发也无法按计划进行。这种种的问题都是公司规模变大以后管理者必须面对的。
然后就是M公司的氛围，其实从进入M到现在，并没有感受到互联网公司的氛围，基本上与京东类似，都属于传统型互联网公司的气氛，毕竟核心的业务还是传统的采购零售，以及对供应链的改造，所以整体员工的年龄层次并不是很年轻，活力肯定不如新兴互联网行业活跃。不过整体的节奏上还是显示出了标准互联网公司的紧凑感，加班也是家常便饭，加班程度基本上是：开发>产品、测试>业务>其他，而且技术团队的工作量主要受业务影响，因为需求的来源几乎是业务方提出的，产品及开发也对业务进行反向反馈，提出自己的建议，总体上讲这种业务、技术团队分离的公司，必将有更高的沟通成本，效率上肯定不及业务产品融合的公司。
最后就是M的员工，给我的感觉就是人和人之间的关系还是比较融洽的，工作忙的时候大家潜心投入，产品人员投入到文档书写以及流程梳理，技术人员投入到编码开发，其他人员也各司其职，工作不太忙的时候大家也会聊聊天，至于话题，那就很广咯~ 公司还会定期举办各种性质的活动，如分享交流会，涉及的主题也很广泛，分享者有外面请来的行业专家，也有公司内部的员工，又如各种文体活动，羽毛球赛、篮球赛等等，各个团队的团建活动也是必不可少的。总之M的员工各方面都很nice，整体是个有爱的团队。（绝非广告。。。）
三、对不同产品设计差异的思考（2C和2B）
这次实习之前很少接触2B的产品，对2B与2C产品本质的不同并没有切身的体会，仅仅知道用户的区别，而产品层面的区别知之甚少。M是做2B产品的，产品线分为前端与后端，前端主要是对外面对商户，后端主要是内部人员使用的，作为支撑业务正常流转，保证效率的产品，这也让我感受到一个面向用户的产品背后有更多更复杂的后端产品在支撑，而且常常要比前端产品要更复杂，其设计时需要考虑的因素也更多。除了互联网产品通用的、基本的设计原则之外，2B的后端产品与我们平时使用的2C产品在设计上又不太相同的侧重点。
2C产品最为看重的是用户需求的满足和用户体验的顺畅，一个产品在满足核心需求的同时，其他方面则都是产品亮点，主要的工作还是深挖核心需求，更好的满足核心需求，并且追求更好的用户体验，因此总结起来就是单点的不断深挖以及其他功能的点缀与辅助。但2B产品都是基于线下庞大的业务，将业务抽象成产品，在线上更方便高效把控业务，由此提升效率的同时叶必然提升了收益，这也是互联网+的精髓所在。因此在做2B产品的时候，必须对现有业务逻辑有一个清晰的认知，对各个不同业务部门之间的关系，也需要站在公司全局的角度有清晰的认识。所以在上手设计产品之前，就需要对公司业务做大量功课，与业务需求方不断进行沟通，确定清楚自己对需求的理解是否正确，以免误解了需求，浪费开发资源是小，延误了公司整体产品线的进度才是最要命的。在产品设计过程中，需要考虑到各个所谓的“坑”，是否与其他系统在某些逻辑上不同？产品的输入输出是否形成了闭环？与其他系统接口的数据可行性？等等问题，要求产品经理在设计自己部门的产品时，不但要梳理清楚自身业务模块的逻辑，还要考虑相关业务模块，对其他产品的影响，或者其他产品的某些改动是否会影响到自身产品。总之在设计过程中需要缜密去check的点数不胜数。
而当产品设计完成时，还需要考虑到其上线运营所要遇到的很多问题，需要制定所谓的运营策略。比如产品在使用时可能遇到的异常情况，技术团队需要提供解决方案，或是给用户指引，或是团队自身有紧急预案，以保证产品设计过程中遗漏的问题，能够在上线后及时发现并解决，尽可能减少公司的损失。另外就是数据方面，对产品所产生的数据需要做一个统计规划，系统上线产生的数据是否需要报表，而报表又该怎样设计，这也是需要和业务需求方沟通的，还有就是垃圾数据以及老系统历史数据的处理，都是数据方面需要考虑的问题。
最终总结如下图：
四、对产品经理的理解和感受
我本科和研究生都学的是和互联网计算机无关的工科，可以说想走向产品经历这条道路有偶然因素，不过仔细想想这似乎也是一种必然。从0开始学习产品知识后，也对产品经理这个职业有了些模糊的认识，实习后也慢慢感受到了pm在互联网公司的特殊性，认识到了几大工种之间的联系，对互联网公司的玩法和pm职业有了结构性的了解。
在产品开发前，就是我们常说的需求阶段，这个阶段的pm就是需求分析师+产品设计的角色。需求分析包含三个阶段：需求来源、需求判别、划分优先级。在M公司，需求来源于业务部门或是CEO、CTO等高管，因此需求都是客观存在的，不需要像2C产品那样做大量用户研究调查，或从社会现象中洞察需求，基本来说要做什么不需要产品过多取考虑；判定需求的真伪，是每个产品必须要做的，对于M公司的产品只要搞清楚业务方的真实需求，即业务方要求的功能是否能真实解决业务上遇到的困难；判别完需求的真伪之后，将真实需求分解为不同模块、不同功能点，然后与需求方沟通各个功能点的优先级 ，以便之后进行的排期（这一点十分重要，便于抓住核心功能）。需求阶段之后，就是产品设计阶段，根据优先级与开发人员沟通排期，根据排期进行产品功能的落地设计，这个阶段就要考验pm的设计能力，如何将业务方的需求转化为系统的功能点并且以简洁的图表、文字表达出来，最终输出文档（包括业务场景、业务流程图、原型图、功能逻辑描述等等），需求评审后交付开发人员。
需求评审通过后，进入产品开发阶段，这个阶段pm同样闲不下来，首先要保持与开发沟通顺畅，保证开发对产品需求理解无误的同时提高开发效率，推进项目进度，这时pm与项目经理角色几乎一致。然后，还需要准备其他各种文档，包括：测试用例、操作手册、FAQ、上线运营策略、数据报表设计等，为产品上线做好铺垫。而产品在开发时，pm经常也就会继续进行另一项功能需求的设计了，也就是说pm同时经手的项目很可能是多个（心累）。
产品终于千呼万唤出来之后，需要与测试人员一起进行各种阶段的测试，上线前给业务需求方进行培训，发放操作手册，接受激动人心的时刻就到来了。然后产品上线之后pm们同样闲不下来，首先上线肯定会遇到各种问题，如果之前运营策略制定的好还罢了，如果运营策略没有制定完善，你将会进入到各种坑中，填了一个另一个冒出来，如此循环好一阵子。。。当你填好各种坑，产品终于可以正常使用之后，还需要对产品使用情况进行监控，通过数据发现问题，通过制定指标来评估产品是否达到预期，若达到了需要思考进一步的优化，若为达到考虑怎样弥补。总之产品上线之后的优化之路永无止境，2B产品需要优化业务逻辑层面，2C产品更多的是深度挖掘用户需求，进一步优化用户体验，我想很多半路接手产品的pm们，更多的是直接从产品开发后进入这个产品的设计者角色，因此更多的工作就是在产品满足用户部分核心需求之后，如何优化改善产品，让产品愈加趋近于完美。
产品经理被很多人戏称为“产品狗”，是有一定道理的，也表达了pm门勇于自黑戏谑的娱乐精神，要知道程序猿们痛恨产品乱改需求的背后，是pm要抗很多kpi的巨大压力和对产品一丝不苟的态度，有很多比喻来形容产品-开发-运营之间的关系，不管这些比喻是否恰当写实，这三个职业都是各个互联网公司向前发展不可缺少的有机整体，产品负责把控方向，开发负责技术实施，运营负责产品更发挥其最大效能，如果三者能互相理解，多站在对方角度看待问题，站在为公司利益前景着想的大局上讨论问题，那么这样公司必将是效率极高的，团队的战斗力也是最强的。
经过实习的磨练，对产品经理能力模型有了更加直观的认知，通过参与的项目也锻炼了自己各方面的能力。“我”是自己最重要的一款产品，几次产品实习也就是不断试错的过程，坚定自身大方向不变的前提下，每次实习及时调整小方向，及时分析自身优劣势，预测自己将会遇到的机会与挑战，希望在今后的日子中不断打磨“我”这款产品，make something different!
