TMS（运输管理系统）是一个物流运输平台，它是供应链管理系统（SCM）的一部分。广义的TMS平台涉及面较广，不同企业的业务模式不一样。 运营方按照一定的运输规则处理，做这个规则处理的过程，一般称之为计划，计划的形式有多种，主要有拼单、拆单、规划线路图、地图合单等，然后再将计划好的这个订单分派给合适的承运方。 最常见的手段是拼单，又称零担运输。将多个货主订单合并拼成一个派车订单，一般规则的处理条件有：订单量、装载能力、价格、路线、发货时间、收货时间等。 计划的手段除零担集货外，还有大单拆分、长单分段等，主要目的来达到成本分摊的作用。计划的手段有智能计算，和人工处理+半自动计算。 承运方接受订单，并将订单分配给司机，由司机执行完成运输任务，这个阶段又称之为调度。运营方将计划的订单分配给承运方，生成最终的运输订单，它是运营方同下游承运方的唯一标识，这个凭证会关联到订单的跟踪监控和应付结算等功能。 基础资料的建立，对TMS的需求任务单和调度非常重要，只有建立了合作关系，才能在客户需求订单上选择到正确（有合作关系）的客户，在计划调度的时候才能匹配到正确（有合作关系）的承运方。 录入货主、承运方的信息，以便于后期订单的生成， 这些信息的维护可以保证每个订单都有归属客户，方便订单的管理。

    SaaS是一种通过Internet提供软件的模式，软件的开发、管理、部署都交给第三方，不需要关心技术问题，可以拿来就用，如今很多企业也都在开发SaaS系统。 从全球范围看，软件业的SaaS化已是大势所趋。传统软件厂商大多在推进云化、平台化，典型如Adobe、WPS、万兴；新兴厂商如Figma、墨刀、石墨文档等，则从创业之初就坚定走在云端。 可有意思的是，大家在内部会上听的是连连点头，但私下交流时却很难对SaaS说出个所以然；有人认为它等于ToB，有人认为它就是公有云，也有人认为它是通过浏览器访问使用、无需下载的应用。
      起初我以为这只是个别的理解偏差。后来看了市面上的相关资讯和资料，并且与部分业内人士交流后，我发现原来不少人，包括部分科普者，对于SaaS的理解也存在相当的局限性；于是决定写篇文章，整理下目前大家在SaaS理解上的几个争议，以及自己对SaaS的一些观察和思考。 SaaS平台供应商将应用软件统一部署在自己的服务器上，客户可以根据工作实际需求，通过互联网向厂商定购所需的应用软件服务，按定购的服务多少和时间长短向厂商支付费用，并通过互联网获得SaaS平台供应商提供的服务。 简单翻译过来就是，服务器在云端，按照客户定购需求，通过网络提供应用软件服务的，都算是SaaS；比如大家看视频常用的优爱腾，存资源用的百度网盘、阿里云盘，办公必备的Office 365、Adobe CC，等等。 与SaaS软件相对的，是需要下载到本地运行的传统软件，典型如未转型前的Office和Abode；后者需要按版本购买，获取license（软件序列号）激活。
     软件license在市场上进行买卖，本质是一种单纯的售卖关系，用户通过一次买断的方式获得传统软件的永久使用权；它区别于SaaS模式（普遍采取订阅付费），后者售卖的内容从软件license转变为服务，软件成为服务的载体。软件提供商与用户的关系，从一锤子买卖转变为长期服务关系。![0a8d89f9-a878-4a40-9a27-9575c9a5aa2a-image.png](https://upyfuntask.suwis.com/xnit.funtask.club/f73cce0c-fb3a-4450-ae81-f3e523f5cc54.png)

短视频要养号的必要性：从平台的角度来看更希望把流量给那些正常的、能创作高质量、垂直内容的账号。正常的账号，在初期，抖音都会有流量扶持。通过对账号的前3-5个视频进行标签测试后，抖音会在后续推荐更多精准的用户，以便于这些账号产生的优质视频获得更多互动（转评赞）和推荐。前提是我们得让系统知道我们是真人用户，不是机器注册的黑产号。 什么情况需要养号？刚注册的新生号：这个比较好理解，新生号得靠养号的动作让系统知道你是个正常号，不是机器营销号，更好的让系统识别；废弃的老号：为什么废弃过的老号也要养？原因同上，证明下自己的正常用户；被拉过小黑屋或者警告过的号：毋庸置疑这种号能出来一定要展现给系统看你不会再疯狂的营销，或者发布其他违禁内容； 但我的观点是所谓“养号”，也就是发视频之前正常刷刷视频，让系统知道你不是恶意注册的机器号就行了，并不是刻意的去营造些所谓的“标签”之类的，这个官方已经辟谣了，没必要再浪费时间去花精力了。记住了：你看什么不重要，你能在短视频APP上为用户创造什么才是关键！ 所谓养号，仅仅只是像系统表明你不是机器注册，是真人用户，以及向你推荐对应的标签视频，这里的标签是指你是用户。所以需要不需要像网上培训所说花一周时间来养号呢？答案很明显，不需要！完全没必要。科普一下，官方明确公示过，抖音的标签有两个：用户标签和创作者标签，你每天刷的视频类型构成了你的用户标签，你账号发的内容才决定你的创作者标签。这两个是不冲突，也没关联的。 善于运用热门的梗：抖音每隔一段时间就会出一个热门的梗，可以尝试做一下排名评分类视频，这样的话有不同的意见，评论区也会有人去讨论带动评论区讨论；

如今随着互联网的不断发展，更多企业会利用互联网做营销推广，互联网的各种渠道进行宣发触达，利用各种数据进行分析，是如今很适用的一种营销方式。 一场营销活动的全流程，涉及：活动物料制作：活动h5、小程序、海报等；渠道分发：线上渠道（微信群、公众号、APP等）、线下渠道（门店、网点、卖场等）；运营策略：用户挽回、生日关怀、裂变拉新等；用户触达：通过短信、微信模板消息、app push等方式触达用户；用户数据沉淀：身份信息、行为信息；BI展示/数据分析：访问量、分享数、转化率等报表展示与分析。 针对以上营销活动的全流程所需的基础设施进行抽象，可以得到营销系统所需要的功能模块：活动编辑器：活动制作能力复用。（不建议划到营销系统的范畴）；渠道管理：渠道新建、删除、修改以及以渠道为维度的数据统计查看等；营销自动化：根据既定营销策略，根据事件触发，自动化对客营销。比如生日前3天自动给客户推送生日券等；触达：短信推送、邮件推送、微信模板消息推送等； 客户档案：客户标签系统；大数据底层：数据采集与处理；BI：数据可视化展示。 以上可以归结到业务基础设施的范畴，解决的是营销活动发起的效率与成本问题；目前业内大部分的营销系统，基本都包含以上模块。 在具体项目中跑模型，跑出成功的模型后，扩大到同行业其他客户甚至跨行业客户，验证成功后对模型进行产品化；最后由这一个个经过成功验证的产品组成提供跨行业的一站式解决方案的营销平台。 系统的设计者需要积累成功实践才能做出有价值的系统，而系统的使用者又需要一定的经验积累才能让系统产生价值达到系统设计之初的目的。

如今随着互联网的不断发展，更多企业会利用互联网做营销推广，互联网的各种渠道进行宣发触达，利用各种数据进行分析，是如今很适用的一种营销方式。 一场营销活动的全流程，涉及：活动物料制作：活动h5、小程序、海报等；渠道分发：线上渠道（微信群、公众号、APP等）、线下渠道（门店、网点、卖场等）；运营策略：用户挽回、生日关怀、裂变拉新等；用户触达：通过短信、微信模板消息、app push等方式触达用户；用户数据沉淀：身份信息、行为信息；BI展示/数据分析：访问量、分享数、转化率等报表展示与分析。 针对以上营销活动的全流程所需的基础设施进行抽象，可以得到营销系统所需要的功能模块：活动编辑器：活动制作能力复用。（不建议划到营销系统的范畴）；渠道管理：渠道新建、删除、修改以及以渠道为维度的数据统计查看等；营销自动化：根据既定营销策略，根据事件触发，自动化对客营销。比如生日前3天自动给客户推送生日券等；触达：短信推送、邮件推送、微信模板消息推送等； 客户档案：客户标签系统；大数据底层：数据采集与处理；BI：数据可视化展示。 以上可以归结到业务基础设施的范畴，解决的是营销活动发起的效率与成本问题；目前业内大部分的营销系统，基本都包含以上模块。 在具体项目中跑模型，跑出成功的模型后，扩大到同行业其他客户甚至跨行业客户，验证成功后对模型进行产品化；最后由这一个个经过成功验证的产品组成提供跨行业的一站式解决方案的营销平台。 系统的设计者需要积累成功实践才能做出有价值的系统，而系统的使用者又需要一定的经验积累才能让系统产生价值达到系统设计之初的目的。

产品经理在经理面试时，面试官经常会提出一些产品经理高频问题，这些问题都是在考验产品经理对岗位的理解或者潜力如何。 简单的自我介绍，良好的开端是成功的一半，向面试官展示自我亮点的重要机会，可让他对我们产生兴趣，介绍时长控制1-3min。 自我介绍要保持良好的心态，心理暗示这只是和朋友简单交流，自信且充满热情。表达口语化，不要过于官方和呆板，就像讲故事或人物采访一样就好，切忌简历内容背诵出来。清晰结构化，搭建一个清晰的框架，反复练习调整，自我介绍是概括性的，“点到为止”让面试官感兴趣主动来问你，即设置”埋点”，让场子“热起来”进行有效互动。 结构化思维是将事物结构化，从整体到局部、层级分明地引导思维和表达的一种思考模式，传达出一种有层次、有条理、脉络清晰的感觉。 最后再总结下整个项目因为自己的很多付出而获得收益，同时自己也获得了很大突破和成就。 你怎么看待加班这个问题，面试官是希望听到“认同加班”的回答，这个问题了解我们对加班的看法，是否一刀切地排斥加班；我们不必为了迎合公司而宣称自己“365天24小时做牛做马在所不惜”，更不要去问面试官是否有加班费，会让面试官认为我们眼界太小太在乎钱。 建议是表明自己觉得加班是可接受的，并且举例说在之前某个工作经历中，我们也因为产品赶进度或临时紧急处理任务会积极无条件加班完成，当然加班是因为工作效率低这种情况，那就会努力调整提升能力或做好时间管理规划。 如果问道：你为什么想要离职？切忌说前公司的坏话，相反我是会说前公司的好，因为有它给了我提供很好的成长机会和发展空间，也再次强调我因此具备的核心能力和优势，也突出我们有明确的规划目标，主要从行业、公司和个人发展来回答：行业：例如传统行业效率比较低下，节奏比较慢，成长也比较慢，而互联网相对来说节奏比较快，工作比较有挑战性，所以自己也可以比较快速的成长。 公司和个人发展：任何人都希望在一个有发展前景的公司发展，随着公司一起成长，希望有一个更加成熟和强大的产品团队，这样可以在工作上获得更多的思想碰撞和交流指导等。 回答这个问题的时候一定要注意，尽量不要说公司的坏话，从公司的角度说一些客观存在且自己无力改变的事实；比如：公司频繁的转型，一直没有找到合适的方向，自己职责也一直跟着变化，导致目前的工作内容与最开始的预期不符，或没有标准的工作流程以及培养体系，所以想找一个更大的平台发展。

预判设计（Anticipatory Design）是一种能够引导用户、缩短用户行为路径的有效设计手段。预判设计，可以根据用户的行为/用户所在的场景，让功能主动找到用户，并让用户与之产生自然的交互。 这种操作模式符合我们对于绝大多数产品使用的认知，交互设计师在设计用户行为路径时，往往是以功能为出发点，通过功能优先级，将功能分布排列，用户在界面中找到功能并进行操作。 这本质上还是依赖于用户的主动触发，一般来讲，如果用户不主动触发，就不会产生后续行为。 设计心理学中提到，当用户操作一个设备，他们会面对两个心理鸿沟：一个是执行的鸿沟，在这里，用户试图弄清楚如何操作；另一个是评估的鸿沟，在那里，他们试图弄清楚设备处于什么状态，他们采取的行动是否实现了目的。 预判设计侧重于解决第一个鸿沟：执行的鸿沟。在产品功能纷繁复杂的当下，界面中的功能元素、信息元素愈发复杂，有的时候，用户想要在一个界面中找到某个功能、操作某个功能并不轻松。预判设计，可以根据用户的行为/用户所在的场景，让功能主动找到用户，并让用户与之产生自然的交互。 预判设计首先是基于用户本身的，即系统预测用户即将做的事情，并且帮助用户缩短操作路径，整个过程虽然是系统主动发起，整体上却是符合用户整体预期的。而如果单纯只由系统主动触发，却与用户当前行为没有任何联系，就不算预判设计。 用户的交互行为是多样，常见的有复制/剪切、截图、手势（如摇一摇）等，从理论上讲，用户的各种行为都存在提供预判设计指引的可能性。 预判设计与用户行为、功能场景是紧密关联的，或者说，系统基于用户操作的行为或用户所处的场景才能形成合理的预判，否则很容易引起用户反感。 同一个行为，在不同场景，也会存在不同的预判设计方向。

产品经理的任务就不仅仅在于完成产品策划，还需要承担项目管理工作，跟进项目进度，必要时还得出面协调和争取研发资源、解决冲突，以确保项目按时、按计划完成上线。但如果不是专业项目经理出身，应该怎么做来保障项目按时上线呢？ 按照管理学对项目管理这一分支学科的定义，项目管理是指 “在项目活动中运用专门的知识、技能、工具和方法，使项目能够在有限资源限定条件下，实现或超过设定的需求和期望的过程”。 简言之，就是要懂得如何在复杂多变的环境中做好一件事，使这件事最终能达成目标。按照PMP（项目管理专业人士资格认证）的知识体系，项目管理的全过程分为5大过程组、10大知识领域、49个过程活动。 就国内的情况而言，大多数公司普遍更适合敏捷项目管理方法，一下内容分享的也正是本人基于敏捷思维下的项目管理实践经验：我们可以将一个项目从头到尾主要分为3个阶段：启动阶段、实施阶段、收尾阶段，每个阶段再梳理出关键事项，就形成了项目管理三阶段。 一份好的产品策划案需要具备以下几点要素：清晰的项目背景和价值阐述；明确的项目目标；不用过于追求原型的美观与酷炫的动效。产品经理应该注重需求的完整性以及清晰表达，但有时候简单的一个交互动效会比长篇累牍的文字描述要高效许多，恰到好处即可。 在项目启动阶段的重点是做计划，计划为纲，包括产品策划、提前识别风险、完成需求评审会，得出项目排期表。 在项目实施阶段的重点是监控进度，监控进度有几个工具：项目排期表、任务进度表、每日站会，而且项目计划需要在实施阶段根据实际情况动态调整（如需求变动、未知风险发生甚至目标变化等）；完成项目上线不是项目的终点，在收尾阶段的重点应是复盘总结，沉淀项目经验教训，为后续项目沉淀经验资产。

在这个流量为王的时代，流量的获取并不容易，而留存则更不简单。一味的强调获取流量并不是明智之举，如何抓住流量是应该考虑的重点问题。随着互联网人口红利的褪去，不少用户会同时使用几种同类型的产品，做不到留存就得不到忠实用户。产品留存，决定着一个产品的生死。 在以往流量时代，许多公司都在强调用户增长，想要用一切的力量去达到用户增长这个目的，不增长，不成功，彷佛产品一旦出现停滞的增长，就很难生存下去。 但是近年来，随着新用户转化成本的逐年上升，互联网人口红利减少，产品和用户越来越多出现同质化和用户同量化。一个用户，可能既是A产品的用户，又是竞品B产品的用户，交叉相互使用。 所以近年来，也越来越多的企业认识到存量时长的重要性，更加意识到产品留存的重要性。产品留存就像一个水池的出水管一样，这根管子的大小，流失的快慢决定着池子里能存多少水，在很大程度上也决定着产品是否达到MVP模型，决定着一个产品的生死。 提到产品留存，就一定会提高大家都非常熟悉的AARRR模型。在这个模型中，用户留存处于激活和变现的中间位置。 如何提高产品留存，达到用户增长的目的？但是，在我看来，产品留存不应该只是处于中间位置，链接激活和变现，它应该贯穿在整个用户的生命周期，最终实现商业变现和用户增长的目的。激活也是为了更好地提高留存，转化也是提高留存的一种手段和方式，比如各大平台推出的会员产品。 产品留存的本质是产品能够持续地满足用户的需求，并且随着使用时长的增加，产品的替换成本越来越高，用户也就更加倾向于在原来使用的产品中继续留存。替换成本越来越高，用户也就更加倾向于在原来使用的产品中继续留存。产品的长期价值成立和稳定，是产品留存能够产生意义的提前，也就是说产品本身能够解决用户的痛点，痒点，满足用户的爽点的。 但是不同的产品类型和变现模式，在确定留存指标的时候也存在明显的差异。广告模式变现的产品，更加主动使用的使用时长和单次广告的曝光价值，内容社区一方面注重内容的生产情况，另外一方面也注重消费用户的消费情况。 针对产品的核心价值和功能点，可以满足不同用户长期留存的需求。功能越完善，越可能满足众多用户的需求，但是也并不是越多越好，如果核心功能不能很好地做好用户留存，那么再多的功能都只能是拯救产品。

说到产品经理的基本技能，很多人第一时间都会想到需求文档，需求文档是产品经理日常工作输出最重要的文档。对于许多初级产品经理来说，最迫切想要提升的，应该是写需求文档的能力。同时，写需求文档的过程，更是变相地锻炼产品经理的逻辑能力、全局能力、判定需求真伪能力、排需求优先级能力的良性过程。 产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档。当然，这个定义针对的是一个全新的产品。广义上来讲，产品需求的描述，应该包含有产品的战略和战术，战略是指：产品定位、目标市场、目标用户、竞争对手等。战术是指产品的结构、核心业务流程、具体用例描述、功能&内容描述等。 PRD的主要使用对象有：开发、测试、项目经理、交互设计师、运营及其他业务人员。开发可以根据PRD获知整个产品的逻辑；测试可以根据PRD建用例；项目经理可以根据PRD拆分工作包，并分配开发人员；交互设计师可以通过PRD来设计交互细节。PRD是项目启动之前，必须要通过评审确定的最重要文档。 每个产品经理的需求文档，长得可能都不一样，每个人都有表达自己逻辑的方式和习惯。但是对于初级产品经理来说，还没有形成自己的风格之前，需要先了解需求文档的通用组成部分，以及尽可能多的参考和学习其他产品经理写的需求文档，以此来吸取精华，去其糟粕，后期再逐渐形成自己的风格。 这部分对于开发和测试没那么重要，但是对于产品经理本身却是最重要的部分。这部分的主要工作，就是梳理这个需求的来源、背景、方案、价值。任何一个需求的提出和落地，都离不开背景、方案、价值的思考，产品经理务必在认真思考清楚这3个方面之后，才着手整理更细的逻辑方案。 查阅需求文档的人，除了产品经理自身，还有开发、测试、UI、老板、其他产品经理，因此，这个需求值不值得做，做，这个方案是否是最优解？最好了，有什么用？这几个问题，产品经理需要先说服自己，才能说服其他人。