APP推广合作
联系“鸟哥笔记小乔”
内容运营部(产品经理必备:高效需求管理技能全面解析!)
2023-06-02 08:58:09

产品经理作为需求优先级管理主要负责人,在协同各方目标达成一致以及进行资源分配时,面临的难点主要有以下几个方面:其一,多部门间的目标取舍、排序问题。接下来,重点介绍两个需求优先级管理方法:定量分析法和定性分析法。

产品经理必备:高效需求管理技能全面解析

内容运营部(产品经理必备:高效需求管理技能全面解析!)

处理需求是每一位产品经理都需要面对的基础工作,如何安排好各个需求的排期?怎样合理安排工作?本文作者将结合自身工作经验和相关理论,为你讲解需求管理是什么,以及如何进行有效的需求管理,希望对你有帮助。

作为一名B2B产品经理,我的岗位主要职责之一就是需求管理。在我每天的工作中,我面临的主要挑战在于需要同时支持内部多个业务线,并为外部客户提供高度个性化的定制服务。这意味着,我的需求管理工作需要应对各种复杂场景,如内外部需求的平衡、多个业务线的协调以及多个开发团队的协作。

在本文中,我将结合自身工作经验和相关理论,为你讲解需求管理是什么,以及如何进行有效的需求管理。无论您是一名产品经理,还是对需求管理感兴趣的读者,我相信这篇文章会对您的工作和学习有所帮助。

首先,需要明确一个观点:需求管理并不仅仅是简单地管理需求优先级。真正的需求管理是涉及需求的整个生命周期,其中包含需求产生、需求分析、需求优先级、需求开发与测试、需求验证、需求结项以上六个方面。因此,只有同时关注以上六个方面,才能算得上真正全面的需求管理,也只有这样才能确保需求管理的有效性。

接下来,我们从上述六个方面出发,为您逐层进行分析和阐述需求管理的实现途径。请您仔细阅读每个方面的内容,以全面提高您对需求管理方案的认识和理解。

B2B产品经理的需求来源渠道众多,主要渠道有:业务部门、外部客户、研发、产品、运营、运维、老板等等。

上述渠道产生需求大致原因如下:

  • 业务部门:制定业务目标时,当发现产品功能无法支持业务目标实现,则会产生需求。
  • 外部客户:新的业务合作或已合作业务进行优化时,则会产生需求。
  • 研发部门:技术升级或技术架构调整,当需要产品经理配合时,则会产生需求。
  • 产品部门:产品经理自驱进行产品功能建设或重构时,则会产生需求。
  • 运营、运维部门:日常运营和运维时发现用户使用问题或可优化功能时,则会产生需求。
  • 老板:参加某些论坛或高层交流等情况时,则会产生需求。

接下来,以需求产生最多的渠道且最典型的“业务部门“为例,深入剖析需求产生的的底层逻辑。

首先,业务目标是需求的起点。业务为了自身发展,制定业务目标。业务为了完成目标,就会制定相应的业务策略,即行动路径,以达成目标。但这期间可能会发现,现有系统能力不支持业务的策略,不能支持达成目标,就会产生业务痛点。

业务痛点是代表在完成业务目标时,在行动过程中遇到了问题或障碍。但是在业务中,不同的人对痛点的认知和理解是存在差别的,高层管理者更清楚自己的业务痛点以及对目标的影响程度,而基层员工对痛点的理解更多停留在操作层面和自我层面。因此,业务痛点和业务目标关联性越强,越容易得到重视,也最容易产生业务需要。而对业务目标影响不大的痛点、业务可以忍受的痛点、甚至业务自己都不知道的业务痛点,反而极少产生业务需要。

业务需要是源于业务痛点的一种感觉缺失的状态,业务为了满足自己的需要,就会寻找解决方案。如果发现这个业务需要可通过内部流程优化、人工处理等方式暂时解决,那么就不会产生业务需求,只有当业务内部无法解决时,需要依靠外部(产品经理)解决时,才会产生业务需求。

综上,这个由“业务目标→业务策略→业务痛点→业务需要→业务需求”的转化过程,是产生需求的底层逻辑。

产生业务需求(MRD)需三个条件:

  • 系统现状不满足业务策略或计划。
  • 业务认为痛点必须当下解决。
  • 自己无法解决,只能寻找产品解决。

由此及彼,其它渠道也遵循上述需求产生的底层逻辑,读者可以把上述图片中“业务”替换为“其它渠道目标”进行理解。如:外部客户因某个业务增长目标,产生新的需求;研发因为某个降本增效的研发目标,产生新的需求;运营部门因为某个体验运营目标,产生新的需求等等。

产品经理承接来自各渠道的需求,并且投入大量精力实现业务需求。但是,却经常出现需求中途废止、上线后不符合业务诉求、未取得预期结果等问题。虽然造成以上问题的原因很复杂,但其中一个最关键的因素就是产品经理错误地分析了业务需求。

需求分析是什么?需求分析是:通过分析需求产生过程,识别真正的需求并排除虚假的需求。其中,分析需求产生过程,就是分析“目标→策略→痛点→需要→需求”的过程。那么,如何进行有效的需求分析呢?接下来,我介绍两种需求分析方法,都是产品经理日常工作中常用的方法。

方法一:使用5why分析法分析需求产生过程

首先,我们从高维度进行需求分析,即对需求产生过程进行分析。从需求产生过程来看,一个业务需求的形成,到最终传达至产品经理,是需要经过漫长的流程和多重决策,信息在传递过程中必然会失真。我们可以通过5why方法,分析过程是否存在问题,以保证需求的真实可靠。

因此,产品经理在分析需求产生过程时,可以尝试问以下问题:

  • 业务目标是否合理?目标是否过高或者过低?是否可量化?
  • 实现业务目标的策略,是正确路径么?
  • 业务痛点真实么?是高层的痛点,还是基层员工的痛点?现状无法满足么,还是他们不会操作?真的影响业务策略么?
  • 业务需要是对业务痛点的真实反馈么?必须现在解决么?
  • 业务需求的方案是唯一解决方案么,合理么?业务内部不能自行解决么?
  • 上线后能否助力目标达成?能为目标贡献多少?投入产出比合理么?

以上罗列的问题仅抛砖引玉,建议产品经理在实践中尝试从不同角度、不同环节进行分析,锻炼需求分析的能力。

方法二:使用“场景、角色or系统、流程”分析方法

接下来,我们从细维度进行需求分析,即对需求内容进行分析。首先,使用“场景、角色、流程”方法,进行业务流程梳理,从而设计出正确、合理、可执行的业务流程。其次,使用“场景、系统、流程”方法,并结合产品架构能力,将业务流程设计成正确、合理、高效的系统流程。通过以上两个方法,可以产出业务流程图和系统流程图,是产品经理设计方案的关键内容。

案例:

业务背景:我司属于物流平台公司,面向物流市场中大客户及中小客户销售物流服务产品,为客户提供物流配送及仓储行业解决方案。因此,需要与客户签约,并进行合同单据管理,以作为合同物流凭证。

首先,通过“场景、角色、流程”梳理业务流程。从中发现大客户与中小客户合同签约流程不同,大客户流程更复杂、更长,而中小客户流程相对简化和标准。如下图:

最后,通过“场景、系统、流程”设计系统流程。(此处作者有意简述,实际业务场景、系统角色会更加复杂。且针对业务流程与系统流程如何制作,此处不再进行详述,读者可以参考BRD、PRD写作规范进行学习。产品架构能力可参考作者之前文章:
https://www.woshipm.com/pd/5794522.html

从需求优先级的表象看,是在对需求进行排序和取舍,但其背后的实质是:协同业务、研发、测试等部门达成目标一致, 且高效、合理的利用资源,从而 保证目标达成。

产品经理作为需求优先级管理主要负责人,在协同各方目标达成一致以及进行资源分配时,面临的难点主要有以下几个方面:

其一,多部门间的目标取舍、排序问题。需求会同时来自多个渠道,会存在多个目标,如业务、产品、研发、运营等目标,对不同部门间的目标取舍、排序是很困难的。

其二,多业务线间的目标取舍、排序问题。面对不同业务线时,当不同业务线的发展阶段不同、业务规模大小不同时,对不同业务间的目标取舍、排序是很困难的。(该问题虽被第一点包含,但此处仍被提及,是因为相比多部门间的目标取舍,它更难)

其三,多目标并行时资源分配问题。需求虽有先后顺序,但实际工作中都是多需求并行。所以,如何分配资源并保障多目标都完成是很困难的。

其四,临时且紧急需求的处理问题。临时且紧急需求会对现有排序造成巨大冲击,导致需要重新排序、重新分配资源。因此,既要处理已排好需求,又要满足紧急需求是很困难的。

通过以上难点不难看出,需求优先级管理考验的就是:当产品经理面对跨业务线、跨部门 等复杂场景时的 协同沟通能力。

接下来,重点介绍两个需求优先级管理方法:定量分析法和定性分析法。首先,要先声明一点,需求优先级管理工作是十分复杂的,上述两个方法仅能起到辅助作用。若想做好需求优先级管理工作,仍需先具备优秀的协同沟通能力,再结合方法的使用才可做好。

优先级的评估如果仅凭个人感性判断的话,会很难让多位相关方对优先级达成一致。为了尽量避免个人喜好或偏见带来的影响,我们需要引入更科学的方法,通过综合评分打分评价法(或加权求和法)来对需求优先级进行量化。具体步骤如下:

第一步:确定标准。选取和制定优先级衡量标准时,要与其它部门充分沟通,确保衡量标准得到多方认可。

案例:以某工作单位为例,优先级衡量标准有“目标类型、需求来源、重要&紧急程度、收益类型”4个,其中,每个标准下子类目有:

目标类型:公司战略目标、业务战略目标、产品目标、迭代优化目标等。

需求来源:业务部门、外部客户、研发部门、体验部门等。

重要&紧急程度:重要紧急、重要不紧急、不重要紧急、不重要不紧急。

收益类型:业务规模增长类、效率提升类、体验提升类、创新类等。

第二步:确定打分标准。制定各标准及标准子类目分值,也要与其它部门充分沟通,并得到多方认可。

案例:仍以上述单位为例,共计4项标准,总分数为80,每个标准均为20分。其中:

  • 目标类型(公司战略目标-20分、业务战略目标-15分、产品目标-10分、迭代优化目标-5分)
  • 需求来源(业务部门-20分、外部客户-20分、研发部门-10分、体验部门-5分)
  • 重要&紧急程度(重要紧急-20分、重要不紧急-15分、不重要紧急-10分、不重要不紧急-5分)
  • 收益类型(业务规模增长类-20分、创新类-15分、效率提升类-10分、体验提升类-5分)

针对打分标准,有以下几点补充说明:

  • 需求优先级管理中,“综合打分评价法”相比“加权求和法”应用的更多,因为不同标准间相关性较差,标准间不同权重与实际情况不符。如:目标类型与需求来源之间,无法制定谁的权重更高。
  • 综合打分评价法的分值问题。采取各标准分值相同策略,理由同上。如:若目标类型为30分,需求来源10分,这样划分是不合理的。
  • 加权求和法使用问题。常见应用于各标准之间可区分重要程度的场景下,读者可以依据实际情况采用。如:A30%+B20%+C20%+D30%=100%。

第三步:打分。针对不同需求进行打分,确定最终得分。

案例:以上述单位为例,最终打分结果如下:

针对打分,有以下几点补充说明:

  • 打分的前提是:只有详细了解需求的目标、收益等信息后,才能做出客观、正确的判断。
  • 打分的结果要定期回顾与评估。因为外部环境时刻都在发生变化。如:不紧急需求变成紧急需求、业务部门目标变成公司战略目标等,分值在变化。

内容运营部(产品经理必备:高效需求管理技能全面解析!)

需求优先级管理仅依靠定量分析法,是不能解决全部问题的。因为,定量分析法不能覆盖全部场景。所以,为使得需求优先级管理更加全面、合理、灵活,还需要使用定性分析方法。

定性分析法属于感性的判断,笔者认为定性分析法更多的是来自经验的积累,凭借“经验”进行需求优先级管理。我总结了以下经验,分享给读者:

  • 开发周期短的需求,可以搭车其它相关项目或见缝插针进行开发。
  • 产研需求可选择搭车业务需求,通过一个需求,达成多目标。
  • 产品方案设计时,要考虑产品长期规划目标。说服业务接受更长周期但更合理的产品方案,既满足业务目标,又能达成产品长期规划目标。
  • 重点关注“重要不紧急”需求,避免变成“重要紧急”需求。
  • 周期较长的需求,若上线时间紧张,可采用分批次、分阶段实现。
  • 老板或客户的紧急需求。首先,不要盲目执行和推进。其次,尝试与老板、客户沟通了解背景及原因等。最终可能发现是伪需求或非紧急需求。
  • 资源紧张无法按期望上线时,可以尝试运营、业务线下方案临时兜底。
  • 建议优先处理外部客户需求,再处理内部需求。一方面以客户为中心,避免客户投诉或流失,另一方面,内部需求属于内部矛盾,可以关起门来解决。
  • 线上BUG不要进入需求池管理,而应及时解决。

需求进入开发测试阶段后,大部分产品经理认为无需进行需求管理工作,只需等待上线即可。其实不然,若在该阶段出现延期、开发测试质量等问题,仍会影响需求的交付。因此,在该阶段,需求管理工作仍必不可少!

接下来,分别从“需求开发”与“需求测试”详述产品经理应做哪些需求管理工作,以保证需求顺利交付。

在需求开发阶段,产品经理要重点关注以下两点:其一,关注开发是否按计划进行,有无风险。其二,关注开发质量,保证高质量交付。

首先,关于第一点。产品经理应熟练掌握项目管理相关技能,并对需求进行常态化项目管理。例如组织产、研、测日站会、项目周会、需求进度沟通会等。通过定期与研发盘点开发进展及问题,从而提前识别风险,并及时采取措施,避免延期。

其次,关于第二点。虽然产品经理不参加开发工作,无法直接为代码质量负责,但可以通过建设合理的开发流程,以实现高质量的交付。建议:①增加“技术方案概要设计、技术方案详细设计”评审环节,且产品经理参与评审,把控技术方案符合产品诉求。②增加“代码评审”环节,架构师参与评审,把控代码质量。(Ps:如果读者公司没有以上流程,产品经理可以发起流程变革,但确实无法增加,那么只能自求多福了。)

在需求测试阶段,产品经理要重点关注以下两点:其一,关注测试是否按计划进行,有无风险。其二,关注测试质量,保证高质量交付。

首先,关于第一点。参考上文需求开发第一点。读者可同时管控开发、测试进展及问题。

其次,关于第二点。建议:

  • 增加“测试用例评审”环节,且产品经理参与评审,把控测试场景覆盖全部功能场景。
  • 要求测试人员记录并反馈测试问题,并追查问题产生原因,以提升产品、研发、测试质量。
  • 测试完成后,产品经理要进行线上验收。

这个环节是最容易被产品经理忽略的环节。大多数产品经理认为,需求上线后就完成了自己的工作,对需求目标是否达成不太关心,并将这视为业务部门的职责。然而,这种想法往往会导致我们错失成功的机会。所以,作为产品经理,我们必须“以始为终”,始终牢记需求的初衷,在需求验证环节中确保需求目标得到充分的实现。只有这样,我们才能最终摘取成功的果实,也才能让需求管理的旅程更加完美圆满!

接下来,讲解在需求验证阶段,产品经理应该采取哪些需求管理工作。

首先,产品经理应该重点关注和参与“三个计划”的制定与执行。“三个计划”即:灰度计划、推广计划、运营计划。虽然它们从职责上是属于业务方(需求提出方)工作,但它们却是影响需求能否取得业务结果的关键因素。

产品经理应采取如下管理动作:

  • 其一,灰度计划。与业务协同制定灰度目标、场景、时间等,确保灰度期间快速验证产品方案的可用性及可行性。
  • 其二,推广计划。与业务协同制定推广目标、范围、时间等,确保产品方案可复制,达成业务预期目标。
  • 其三,运营计划。与业务协同制定稳定、长期、高效的日常运营流程,确保产品方案持续产生稳定的业务结果。(读者尤其要注意,以上三个计划,虽有先后顺序,但尽量一起制定,避免脱节。)

其次,在制定和执行三个计划时,同时要建立业务数据指标体系。数据指标体系应包含可衡量项目过程和结果表现的指标。指标体系应是客观的、可量化的,以便更好地监测和评估项目进展以及业务成果。建议参考亚马逊:Input、Output、观测指标方法。

最后,迭代产品方案或调整计划。通过对数据指标体系的监控及分析,找出产品方案、灰度&推广&运营计划中存在的问题,分析原因并制定解决方案,及时调整计划或迭代产品方案。

需求结项是需求管理旅程的最后一个环节。一般情况下,只有单独立项或较大项目才会有这个环节,其它需求在需求验证通过后就已结束。需求结项阶段的核心工作是进行需求结项文档编写,并组织结项会议,完成项目的结项。

作为产品经理,需要完成结项文档的编写及结项会议的召开。接下来,分别从“结项文档”和“结项会议”讲解产品经理如何进行需求管理。

首先,结项文档内容主要包含四个方面内容:回顾目标、评估结果、分析原因、总结规律。其中,回顾目标:主要是编写当初的目标是什么。评估结果:评估现有结果,判断是超额完成目标、符合预期目标,还是未完成目标。分析原因:分析实际结果与当初目标差异原因。总结做的好或不好的原因是什么。总结规律:通过对问题的原因分析,从中总结经验和规律,为以后工作起到指导作用。

其次,结项会议要组织相关业务、产品、研发、测试等人员参加,针对结项文档进行阅读和讨论,共同学习经验和规律,促进团队成长。

最后,关于需求结项工作,有几点需要着重关注。首先,结项文档的撰写应该客观、实事求是,不扭曲事实。其次,在讨论问题时应强调事情本身,而不是关注个人责任。第三,结项会议旨在总结经验、教训和规律,而不是追究责任或抱怨。最后,我们需要总结好的经验和规律,同时也需要总结不良经验,即我们在过程中遇到的问题和诸多挑战,进而汲取教训,防止重蹈覆辙。

需求管理是产品经理日常工作中非常重要的一环。本文详细地讲述了如何从需求产生、需求分析、需求优先级、需求开发与测试、需求验证、需求结项六个方面实现有效的需求管理。但要更好地完成需求管理工作,读者必须不断练习和多次应用,积累经验并不断优化。愿读者通过此文的指南和建议有所进步,也欢迎各位读者留言交流经验!

这个故事是这样的,我有个业务项目,需协同其它研发团队开发。但是评审完成后,该研发团队反馈暂时没有资源开发,等待资源释放后再定。给出的理由主要有两条:

第一、相比其它业务线项目,项目收益太低,以后再做。(潜台词:项目太小,成绩不显著,不想做,要做就做大的)

第二、如果想做,那各业务线之间先协调下项目优先级。(潜台词:资源就这么多,我能怎么办?业务线自己PK去吧,谁赢了做谁的)

作为业务体量较小的产品经理,你是不是也遇到过上述场景?是不是很卑微、无助且可怜?接下来,让我告诉你,我是如何处理并解决这个问题。

针对第一个理由“相比其它业务线项目,项目收益太低,以后再做”。

首先,你要了解各业务线发展情况,以及自身业务线处在什么阶段,要做到知彼知己。结合自身业务实际,我是这样处理回复的。

第一,不同业务线的市场规模是有大小之分的,这是天生属性,进行横向收益对比是不公平的。虽然我们业务线市场规模小,但都是关键头部客户,也是公司整体重要市场之一。因此规模不是衡量收益的唯一准绳,而应看项目对业务本身发展的重要程度。

——潜台词:对不起,你的排期逻辑我不认可。如果按照你的逻辑排期,那么市场规模小的业务线项目收益永远最低,岂不永远无法排到?

第二,我们业务线产品建设阶段已经从“初期大规模建设”发展为“功能迭代优化建设”。去年已经完成大规模基础建设,现阶段就是针对上阶段进行补充和优化。该阶段项目的特点就是项目小、收益低。这是产品生命周期发展的必经阶段,预计未来会长期处于该阶段,大家需要有清晰的认知和共识。

——潜台词:要认清不同阶段,工作是不同的。这个阶段工作就是这个特点,难道这个阶段的项目都不做了么?

针对第二个理由“如果想做,那各业务线之间先协调下项目优先级”。

这个理由也是研发常使用的,往往产品经理此时也会让业务内部进行横向沟通,其实是不对的。我是这样处理回复的。

第一,各业务线仅为自身发展负责,不为其它业务线发展负责,也仅知道哪个项目对自己最重要。

——潜台词:哪个业务会舍弃自身发展,而成全其它业务线发展,不管自己的绩效了?通俗点,都是屁股决定脑袋,两个业务都觉得自己最重要,怎么办?

第二,需求管理的职责应在平台型研发部,而不在各业务。各业务线需求应单独管理,且应预估各业务线需求量,提前准备和分配研发资源。避免各业务线资源冲突,否则就会出现被业务投诉资源安排不合理、贻误业务发展等问题。

——潜台词:认清自身职责,不要甩锅,甩锅的结果就是被反噬,不如提前做好需求管理工作。

以上,就是我处理该问题的方式,你也可以结合自身情况调整策略,抓紧试下吧!当然,虽然场景是发生在产品与研发之间,你可以进行总结归纳,灵活应用到不同公司不同岗位上。

作者:泽哥产品笔记,微信公众号:泽哥手记(id:xmind1016)

本文由 @泽哥产品笔记 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

内容运营部(产品经理必备:高效需求管理技能全面解析!)
关键词
运营那些事儿
分享到朋友圈
收藏
收藏
评分

综合评分:

我的评分
Xinstall 15天会员特权
Xinstall是专业的数据分析服务商,帮企业追踪渠道安装来源、裂变拉新统计、广告流量指导等,广泛应用于广告效果统计、APP地推与CPS/CPA归属统计等方面。
20羽毛
立即兑换
超级nice便签砖
超级超级超级奈斯!
1000羽毛
立即兑换
鸟哥笔记限定畅饮吸管杯600ml
超大容量,让你爱上喝水
2000羽毛
立即兑换
运营那些事儿
运营那些事儿
发表文章30421
确认要消耗 羽毛购买
内容运营部(产品经理必备:高效需求管理技能全面解析!)吗?
考虑一下
很遗憾,羽毛不足
我知道了

我们致力于提供一个高质量内容的交流平台。为落实国家互联网信息办公室“依法管网、依法办网、依法上网”的要求,为完善跟帖评论自律管理,为了保护用户创造的内容、维护开放、真实、专业的平台氛围,我们团队将依据本公约中的条款对注册用户和发布在本平台的内容进行管理。平台鼓励用户创作、发布优质内容,同时也将采取必要措施管理违法、侵权或有其他不良影响的网络信息。


一、根据《网络信息内容生态治理规定》《中华人民共和国未成年人保护法》等法律法规,对以下违法、不良信息或存在危害的行为进行处理。
1. 违反法律法规的信息,主要表现为:
    1)反对宪法所确定的基本原则;
    2)危害国家安全,泄露国家秘密,颠覆国家政权,破坏国家统一,损害国家荣誉和利益;
    3)侮辱、滥用英烈形象,歪曲、丑化、亵渎、否定英雄烈士事迹和精神,以侮辱、诽谤或者其他方式侵害英雄烈士的姓名、肖像、名誉、荣誉;
    4)宣扬恐怖主义、极端主义或者煽动实施恐怖活动、极端主义活动;
    5)煽动民族仇恨、民族歧视,破坏民族团结;
    6)破坏国家宗教政策,宣扬邪教和封建迷信;
    7)散布谣言,扰乱社会秩序,破坏社会稳定;
    8)宣扬淫秽、色情、赌博、暴力、凶杀、恐怖或者教唆犯罪;
    9)煽动非法集会、结社、游行、示威、聚众扰乱社会秩序;
    10)侮辱或者诽谤他人,侵害他人名誉、隐私和其他合法权益;
    11)通过网络以文字、图片、音视频等形式,对未成年人实施侮辱、诽谤、威胁或者恶意损害未成年人形象进行网络欺凌的;
    12)危害未成年人身心健康的;
    13)含有法律、行政法规禁止的其他内容;


2. 不友善:不尊重用户及其所贡献内容的信息或行为。主要表现为:
    1)轻蔑:贬低、轻视他人及其劳动成果;
    2)诽谤:捏造、散布虚假事实,损害他人名誉;
    3)嘲讽:以比喻、夸张、侮辱性的手法对他人或其行为进行揭露或描述,以此来激怒他人;
    4)挑衅:以不友好的方式激怒他人,意图使对方对自己的言论作出回应,蓄意制造事端;
    5)羞辱:贬低他人的能力、行为、生理或身份特征,让对方难堪;
    6)谩骂:以不文明的语言对他人进行负面评价;
    7)歧视:煽动人群歧视、地域歧视等,针对他人的民族、种族、宗教、性取向、性别、年龄、地域、生理特征等身份或者归类的攻击;
    8)威胁:许诺以不良的后果来迫使他人服从自己的意志;


3. 发布垃圾广告信息:以推广曝光为目的,发布影响用户体验、扰乱本网站秩序的内容,或进行相关行为。主要表现为:
    1)多次发布包含售卖产品、提供服务、宣传推广内容的垃圾广告。包括但不限于以下几种形式:
    2)单个帐号多次发布包含垃圾广告的内容;
    3)多个广告帐号互相配合发布、传播包含垃圾广告的内容;
    4)多次发布包含欺骗性外链的内容,如未注明的淘宝客链接、跳转网站等,诱骗用户点击链接
    5)发布大量包含推广链接、产品、品牌等内容获取搜索引擎中的不正当曝光;
    6)购买或出售帐号之间虚假地互动,发布干扰网站秩序的推广内容及相关交易。
    7)发布包含欺骗性的恶意营销内容,如通过伪造经历、冒充他人等方式进行恶意营销;
    8)使用特殊符号、图片等方式规避垃圾广告内容审核的广告内容。


4. 色情低俗信息,主要表现为:
    1)包含自己或他人性经验的细节描述或露骨的感受描述;
    2)涉及色情段子、两性笑话的低俗内容;
    3)配图、头图中包含庸俗或挑逗性图片的内容;
    4)带有性暗示、性挑逗等易使人产生性联想;
    5)展现血腥、惊悚、残忍等致人身心不适;
    6)炒作绯闻、丑闻、劣迹等;
    7)宣扬低俗、庸俗、媚俗内容。


5. 不实信息,主要表现为:
    1)可能存在事实性错误或者造谣等内容;
    2)存在事实夸大、伪造虚假经历等误导他人的内容;
    3)伪造身份、冒充他人,通过头像、用户名等个人信息暗示自己具有特定身份,或与特定机构或个人存在关联。


6. 传播封建迷信,主要表现为:
    1)找人算命、测字、占卜、解梦、化解厄运、使用迷信方式治病;
    2)求推荐算命看相大师;
    3)针对具体风水等问题进行求助或咨询;
    4)问自己或他人的八字、六爻、星盘、手相、面相、五行缺失,包括通过占卜方法问婚姻、前程、运势,东西宠物丢了能不能找回、取名改名等;


7. 文章标题党,主要表现为:
    1)以各种夸张、猎奇、不合常理的表现手法等行为来诱导用户;
    2)内容与标题之间存在严重不实或者原意扭曲;
    3)使用夸张标题,内容与标题严重不符的。


8.「饭圈」乱象行为,主要表现为:
    1)诱导未成年人应援集资、高额消费、投票打榜
    2)粉丝互撕谩骂、拉踩引战、造谣攻击、人肉搜索、侵犯隐私
    3)鼓动「饭圈」粉丝攀比炫富、奢靡享乐等行为
    4)以号召粉丝、雇用网络水军、「养号」形式刷量控评等行为
    5)通过「蹭热点」、制造话题等形式干扰舆论,影响传播秩序


9. 其他危害行为或内容,主要表现为:
    1)可能引发未成年人模仿不安全行为和违反社会公德行为、诱导未成年人不良嗜好影响未成年人身心健康的;
    2)不当评述自然灾害、重大事故等灾难的;
    3)美化、粉饰侵略战争行为的;
    4)法律、行政法规禁止,或可能对网络生态造成不良影响的其他内容。


二、违规处罚
本网站通过主动发现和接受用户举报两种方式收集违规行为信息。所有有意的降低内容质量、伤害平台氛围及欺凌未成年人或危害未成年人身心健康的行为都是不能容忍的。
当一个用户发布违规内容时,本网站将依据相关用户违规情节严重程度,对帐号进行禁言 1 天、7 天、15 天直至永久禁言或封停账号的处罚。当涉及欺凌未成年人、危害未成年人身心健康、通过作弊手段注册、使用帐号,或者滥用多个帐号发布违规内容时,本网站将加重处罚。


三、申诉
随着平台管理经验的不断丰富,本网站出于维护本网站氛围和秩序的目的,将不断完善本公约。
如果本网站用户对本网站基于本公约规定做出的处理有异议,可以通过「建议反馈」功能向本网站进行反馈。
(规则的最终解释权归属本网站所有)

我知道了
恭喜你~答对了
+5羽毛
下一次认真读哦
成功推荐给其他人
+ 10羽毛
评论成功且进入审核!审核通过后,您将获得10羽毛的奖励。分享本文章给好友阅读最高再得15羽毛~
(羽毛可至 "羽毛精选" 兑换礼品)
好友微信扫一扫
复制链接