作者：cloudxiao 产品经理
知乎：/people/cloudxiao
banner制作：早读课-猴雪莹
许多产品经理可能会经常面临这样的问题：公司现有技术资源不足以支持自己的产品设计和迭代周期，导致不得不妥协。而Boss或客户还不断要求采用『小步快跑，快速迭代』的方式看到产品成果，这时作为产品负责人的你该怎么办呢？
让我们设想这样一个背景，并以此展开讨论：
某个产品的研发团队是由1位3年经验的研发Leader带队，加上3位0.5~1年经验的新人组成。要求：敏捷开发模式，并以此制定每个版本的里程碑和发版计划，通过以往的经验你明白该团队远低于正常配置，但时间紧任务急资源少，你只有上路。
抱怨解决不了问题，以项目周期为时间段，在项目执行前、执行中从容应对，通过合理的控制和管理尽可能的达到目的。
明确状态，获取理解和支持
在评估完时间，资源和可行性后，PM需要做好充足的心里准备，分别列出最坏，适中和最好三个结果。这其中又以『最坏』为重中之重，因为这很可能就是真实的结果。PM应当明确告知领导可能出现的后果，打好预防针。如涉及到对外合作项目，还要在内部达成一致如何对客户进行告知。不要隐瞒后果期待奇迹发生，更不要企图自己承担后果。P.S.有职责较为明确的公司，该工作会由项目经理承担。
做最后努力，争取（额外）资源
有给力的研发负责人带队，一方面可以对团队把控，也可以让年轻人发挥主观能动性快速成长，也许他们未来都是公司的财富。如果团队中不具备这样的人，发挥人脉关系哪怕借一个来，都是非常有必要的。还是不行？不如放弃敏捷开发模式或重新衡量项目可行性，以免拖垮团队毁掉声誉。
制定可行的迭代周期
迭代周期不要过短（团队HOLD不住，时间都会浪费在代码分支合并，冲突检测，发版上），也不要太长（否则失去了敏捷开发的意义），每次发版时间在可以在标准值基础上+30~50%时间，给不成熟的团队留出充分的容错时间，所以需要具体情况具体分析。这时作为产品经理的你，需要和研发负责人探讨每个里程碑实现程度。请考虑以下两方面：1.是否会影响你的产品设计节奏；2.在每次交付时能否满足领导或客户的预期。
明确开发背景，不走回头路
包括开发框架，网站架构，语言数据库服务器部署要求等等（尤其设计到客户，一定要确定清楚，必要时有合同，邮件为证）。不要进行到一半发现完全跑偏，团队接收不了这样的惊喜。在此环节，产品经理的参与主要体现在明确表述在与需求方的接触过程中，对方有何『硬性』要求都要提出，以供整个团队做设计背景。
项目执行阶段
部门间彼此配合，适当的对结果打『折扣』
由于资源局限性，部门间更需要彼此理解和对目标认可。根据现实情况，在产品设计上做一些妥协，给功能列表减负，优先级低或者『令人尖叫』的功能先砍掉。举个极端的例子，注册验证码都搞不定的的人，就干脆去掉验证这步吧。如果是对已有产品进行大的版本更新，就要考虑更多的兄弟部门和联动意义，比如去掉某功能是否会影响该部门开展业务活动，作为PM不可能令谁都满意，只能考验自己的平衡和交流能力了。
会议的重要性
这点所有敏捷开发都会强调，包括通过站会汇报各自进度情况。能力不足更要保持信息畅通，不要让成员自钻牛角尖再给项目雪上加霜。产品经理在项目执行过程中，始终会保持与需求方的沟通。如果出现产品变更或需求变化，也要在会议上及时提出，如此反复修正复合当前情况的开发计划，并保证可行性。
适当的说不
在项目执行过程中，团队难免会受到各种各样的干扰和额外的工作要求，比如客户会要求你帮助部署服务器，测试线路等等。如果合同中有对应要求，可以协调兄弟部门作支持。但原本就超负荷的研发团队，最好合理的拒绝，避免再牵扯更多精力。
巧妙的进行汇报
虽然定期汇报项目情况是项目经理的工作，但产品经理需要通过在方案中植入相对感性化的描述，来弥补项目不足和客户的体验。举例来说，在重要又枯燥的数字（完成度，开发率等）之后，适当的可视化工作状态，比如放一些成员加班的照片，攻克问题的数字及内容和对下阶段的产品设想。核心思路是体现项目进度虽有一些延后和不尽如人意，但整体仍未失控。
额外：感情安抚
能力不足往往是团队年轻，但年轻人充满活力，加班到凌晨不眨眼，虽然解决的问题看似都『不值一提』。但长期如此消耗势必对团队成员的心里产生巨大的折磨和影响。端茶倒水零食饮料不能少，如果有『程序员安抚师』……想多了，有这预算不如在招个经验丰富的人。这期间大部分人的能力都在突飞猛进，没准也可以显露大牛天赋。
万事俱备只差一位产品经理来发号施令的理想状态，过去，现在和将来都未必会有。在这种状态下，产品经理更需要有一颗强大的内心，沉着冷静有条不紊的把资源利用到极致，对事情终局的判断，可以倒逼过程中的每个决策，这是你作为一名PM可以掌控的。随着研发能力的提高和彼此配合的加强，一切终究会慢慢走上正轨，而你和程序猿们在『战斗』中培养出来的坚定友谊，也会让身为产品经理的你在未来获益良多。
如果看到这段文字，证明您已经看完这篇文章了，有什么收获有什么感想有什么不赞同，我们期待您的留言评论，并诚挚邀请您加入“互联网早读课”QQ群，一同交流每天文章的心得并结识同行。官方10群：，加群密码“城市+职业+姓名”，否则不予通过，入群后请修改群名片。
10人左右的创业公司，Title就只是个Title，每个人的角色都是随着产品的不同发展阶段时刻变化的。
数据不可以改变风险，但是可以把风险量化，就如互联网金融其实改变不了金融的本质和风险，而是作为一项工具更加高效和透明去做金融。
大牛刘津博客中这篇竞品分析我读了很多遍，方法很不错，所以拿过来总结下，原文地址：“.cn/s/blog_453dx.html”
说明：我整合了两篇文章，也用到了原作者的例子，大家看个形式即可，详情参考原文博客
----------------------------------------------------------------------------
一.在竞品分析之前
分析讲究逻辑与方式，内容需要结构化的呈现给读者，不能想到什么就写什么。做分析首先要确定目标，这样产品才不会跑偏，听众才不会云里雾里
大牛的分析流程如下：
明确研究目
了解我们的产品
根据我们产品的特点，选定竞品
竞品分析（功能、内容、布局、细节、使用流程）
确立设计目标
二.选择竞品
1.了解产品：一句话描述产品定位、产品主要功能、特色是什么。针对这些提炼出联想关键词。比如“一款针对于资深&电影迷&的&影评&产品”
2.头脑风暴：结合关键词进行联想，具体方式有以下三种：
a.组合联想：把关键词拆分并重新组合。比如说道电影+评论，我想到“时光网”；说道资深+评论，我想到“知乎”；比如资深+迷，我想到“贴吧群组”
b.纵向联想：从一个关键词出发，纵向不断延展出新的关键词。比如“影评→内容→简书”“影评→深度→知乎”
c.横向联想：从关键词逐一发散。比如“影评→豆瓣”“资深用户→知乎”“电影→时光网”
3.确定关键词：按照图中的象限，把产品对应入内，并且筛选出几个产品。首先是相关度最高的、然后是其次和补
三.探索竞品
确定我们的产品和竞品的共同点和差异点，差异点非常重要！
比如“核心功能不同”，猫眼电影在于订票，核心用户都是没有看过电影的人，突出电影的基本信息。而豆瓣电影则重评论，看影评的人一般是看过电影的人，电影的介绍内容少。
注意到差异，才能不跑偏
四.分析重点
1.把竞品的名称、所属类别、地位、评价、分析重点和差异&制成表，并列出内容
2.和我们的产品进行对比。归纳共同点、差异点、可借鉴和需要规避的（有一部分和产品差异有关，还有一部分是产品设计不好的地方，以免我们再烦同样错误）
五.设计需求
根据前面的分析，来确定设计方向
可借鉴和规避点是我们的设计点
=========================================================
这周读了大神的博客，发现自己很多不足，我必须承认自己还只是个新手
大神的文章中说道“方式”，好的交互设计师可以根据不同的问题，找到最适合的解决方式。先别说最适合的方式，想想在工作中，我们是否真的梳理过自己的思路都是个问题！常常是产品给我们需求，就直接上手画图了吧？
看来我还有太长太长一段路要走，多总结，多实践，才能有所提高
如下准则有助于达成目标，做出选择、解决问题、判别真伪。Use notions要利用确定的概念或某个想法
使用有事实做依托的大想法
明白事情的真正意义
利用规则并且学会筛选
知道我要达成的目标
寻找并且考量替代方案
了解各种后续情况以及整体结果
搜寻各种根据，并在此基础上行事
能够反向思考
记住，要有大的成效，就需要诸多因素的总和
评估如果做错了会有什么后果
What is the issue?&
问题的解决
问题是什么？事情的实质是什么？
事情的核心或重点在哪里？相应的主要问题是什么？
什么是相关的？什么是可解决的？什么是重要的？什么是可知的？什么是可以适应的（Utility-applicability）？
我了解事情的全貌吗？为了使自己对事情有想法，我需要一些相关数据和基本知识储备，否则我就得承认“我不知道”。
我的判断比其他人好吗？
我必须对什么做出预测？它是可预测的吗？
需要做出决定吗？如果我不当机立断，会发生什么？为解决此事，我能做什么？“我”应该去做吗？
我对此问题的思考花了多少时间？此刻我思考到了哪一步？处于谁的立场上？
简化问题，先解决“不需大脑思索”的大问题，然后从自己的境地开始思考。
Understand what it means
理解背后的含义
把语言和各种想法翻译成我明白的方式。我能理解所用的语言和结论的真正含义和暗示吗？它意味着什么？它是否有助于我对未来做出有用的预测吗？
我是否了解事情发生和运转的方式和原因？它正在产生什么影响？为什么会有这样的影响？现在的情况如何？怎样及为何会发生如此情况？其结果会是什么（会有什么观察、发现、事件、体验）？
Filters and Rules
过滤和规则
利用规则和缺省规则来筛选——我可以如何检测？
改变规则，以适应我的心理特征、心理承受能力、心理优势和心理局限。
考虑我的价值观和偏好，由此判断事物的轻重缓急，以及希望规避的事情。
What do I specifically and measurable want to achieve and avoid and when and why?
我具体想达成和避免的是什么，什么时候达成，原因为何？
就数字而言，我想获得什么样的价值？目标数字是什么？目标效果是什么？所设定的时间范围是什么？
假设我已经达到了目标，那么这个目标如何反映在数字和效果上？接下来又需要达到什么？这个目标是否合理？如果从目标逆向回溯到现在，是否可行？
我是否有办法衡量目标的完成程度？这个标准的关键指标是什么？
如果我达到了目标，随之而来的会是什么？那是我希望得到的吗？
我可否把大的目标分成若干有期限的短期目标？
我做此事的真正原因何在？是因为我想这样还是因为我不得不这样？我在阐述目标时，是基于内外两方面的现实呢，还是受到了某些心理力量的影响？
我能否简短地阐述我的目标，以使人更容易明白我达到此目标的方式？
这是不是我真正希望达到的结果？
What is the cause of that?
成因何在？
为了达到目标，我必须知道能让我达成目标的各种成因。
通过哪些要素的组合可以达成的目标？我如何佐证此公式？
什么是我不希望获得的结果？可能促使“非目标”出现的原因是什么？我能如何规避？我必须不做什么，或者必须避免什么？
整个系统要运转起来，会受哪些变量的影响？这些关键性变量是什么？主要的未知因素何在？有哪些确定的因素可以帮助我评估和优化这些变量？
哪些变量有赖于其他变量（或情形、环境、背景、时机、行为）？哪些变量是独立于其他变量的？
什么外力才能促使某一变量出现？这些外力来源于何处？是短期还是长期外力？其相对优势是什么？这些外力之间如何组合、互动，效果会如何？我如何才能让诸多外力作用于共同的方向？缺乏了哪个外力会毁掉整个系统？这个外力来源于何处？可预测度有多高？这些外力如果出现，会促发什么样的合理结果？哪些外力是暂时性的，哪些外力是永久的？作用于变量的这些外力若发生变化，整个系统会发生怎样变化？
在这些变量和外力发生变化时，系统抵制这些变化的惯性有多强？变量和外力产生变化（上升或者下降）后，可能导致哪些希望的和不希望的短期和长期结果（数字或效果），如规模、体积、强度、密度、长度、时间维度、环境、参与者等？一组较小的外力如果长期发生作用，会怎样？如果作用于变量的某一外力长期发生作用，结果会如何？什么外力能加以改变？需要什么才能达到临界质量？添加了哪些外力后能达到临界质量？如何发生作用？如果我改变了一个变量或者外力，会导致其他事情发生吗？什么情况会让一个外力发生改变？这个改变会产生其他结果吗（请注意我感兴趣的是整个系统的效果和最终结果）？一个变量发生了变化，会对整体结果带来戏剧性的改变吗？属性是否也会随之改变？如果变量之间的关系发生变化，结果会如何？促发改变的那个点是什么？障碍是什么？催化剂是什么？引爆点是什么？拐点在哪里？暂停点在哪里？局限是什么？有多久时滞才能等到效果发生？反馈是什么？什么能令此成因加速？效果若要发生逆转，临界点在哪里？对这个公式，我能做什么改变，其他人能做什么改变？如何做？谁来做？什么时候做？我需要改变哪些变量才能达成目标？我如何度量变化的程度？Degree of sensitivity if I change the assumptions？对目标和路径会产生什么影响？如果某一变量保持不变，会如何？我在提高某一变量的同时降低另一变量呢？会有怎样的网络效应？如果一次只改变一个变量或者外力呢？外部环境中有什么会改变我的处境？如果对其中一个变量进行优化，会产生其他什么优势和劣势？什么才能导致最终结果发生变化？如果我改变了条件，变量还会成立吗？
这一公式会否出现例外，为什么？需要哪些条件才能达成目标？Has my goal different cause short-term and long-term？这个成因是否依赖于时间条件？通过观察效果，我能否追溯其成因？我有否采用不同的角度和立场来审视整个系统？对主题的考量依赖于什么东西？
限制我达成目标的主要力量是什么？
What available alternatives do I have to achieve my goal?
有没有现成的替代方案可以帮助我达成目标？
通过目标、主体问题、规则、因果、行为、佐证、反证、资金的机会成本、时间、其他资源、精力、理解力、风险和精神压力等因素，来对其他替代方案进行判断。
我有什么依据（包括模式）来判断这些替代方案很有可能帮我达成目标？
这些因素有赖于某些特定的时间点或者事件吗？
每一个行动可能产生的后果是什么？可能产生什么效用？可能性有多高？你对每个结果的期待值有多高？
如果现在采取某些行动，我是否会放弃未来的一些机会？
What are the consequences?
结果是什么？
通过对结果的预估，寻找最可能帮助我达成目标的替代方案。
如果我做出了一个选择，什么将随之发生，什么又不会发生？
每个替代方案（逻辑上）可能产生的想要的结果或者不想要（或不希望）的结果是什么（定性并定量）？结果之后的次生结果（短期内或者长期内产生的）会是什么？
会产生什么样不同的情形和结果？在这样的依据下，会产生什么长期或短期的效应？
什么可以帮助我预测事情的结果或其真伪？
为了达到目标，什么事情必须发生？必要事件发生以及发生在我身上的可能性分别有多高？如果我逆向而行，会有什么后果？
什么不确定因素会极大影响到结果？重复出现的效应或者复杂因素会产生什么不希望的结果？
错误的选择和正确的选择分别会产生什么后果？
我是否从不同的角度全面考虑了整个系统？我有否考虑过其社会、财务、生理和情感上的结果？别人可能会怎么做？依照我的经验和以前的行为，我会怎么应对？如果别人也照我这样做，会产生什么样的结果？
个人兴趣或者心理原因带来的会导致我产生误判的偏见，有何原因可以解释吗？
我所做出的结论或者选择的事实中，是否存在偏见？事实判断和价值判断分别是什么？&—&他有多可靠？他有足够的能力做出判断吗？如何加以证明？他做此判断的目的是什么？他有没有撒谎的动机？他如何判断正误？
The hypothesis
假设需要基于我想要达成的目标，并用此假设去检验我关于结果的预估。
对每个替代方案都要问：这个替代方案可能达成我的目标吗？对每个观点都要问：这个想法是对的吗？
我如何检验某个表述的真伪？在证实之前，我能否先证伪？
要检验这一表述，我需要知道些什么？首先，我必须知道什么公式能够让我的表述成立，然后我才能知道，对于判断未来的真正结果，什么才是最重要的。其次，我要知道能够支撑和推翻这一表述成立的证据。哪些表述是需要论证的？
最简单的假设是什么？
Look for evidence and judge the evidence
寻找依据，判断依据&
（促发目标、非目标和意见的）主要成因出现的可能性有多高？
对判断做出真伪评判时，去寻找其意义、动力、成因、后果和正反依据
如果判断是正确的，那么后果将意味着什么？后果会不会超乎逻辑或者不可思议？其中有任何可预测之处吗？
我怎样并且从哪里才能找到支持某一判断的代表性证据？已知的有哪些？哪些东西是毋庸置疑的？若反复加以检验或用其他方式的考量，会出现相同的结果吗？我能否对结果进行检验？这些依据都是基于已知因素吗？我是否正确理解了各项数据？依据在哪里？反面依据呢？我认可依据的理由是什么？这一依据的权重是多少？What is the quality of the evidence？可信度有多高？是否紧密依赖于外部环境？样本是否太少？结论跟手中的依据相符吗？有没有违反科学法则或自然法则？
我有什么代表性的信息？对其加以观察会出现发生什么？我能够通过实验来证实我的猜测吗？
对于将会发生什么（可行还是不可行），有没有相关的过往纪录（案例评估、变异性、平均率、随机程度、自身经历、环境、伙伴与对手，以及其他相关的因素）？有什么理由相信这些纪录对未来会发生的事情并不具有代表性？什么能让未来与以往大不相同？什么是恒在的，什么不是？
这能持续多久？现在的主要成因是什么？什么外力能让其持续、能带来改变、或者造成阻碍，为什么？可能性有多高？
如果我拿到了能够推翻我之前信念的依据，我必须自问：为什么会这样？现在是什么情况？我拿到的是什么样的依据？我接受这一依据的理由是什么？
Disprove my (or others) conclusion by thinking like a prosecutor
像检察官一样对我（或其他人）的结论提出反驳
思考会导致误判的原因
如何检验和证明我的结论是错误的？我可能犯错的理由是什么？从哪里可以找到证明我错误的依据？这个依据可信吗？有没有什么事实和依据与我的结论/观点不符？
我做的分析基于哪些主要假设？是基于真实情况吗？假设的结果符合逻辑吗？有人证明过我的假设是正确的吗？如果我的想法和假设是错误的，结果会是什么？
我有否忽视了什么？有没有更好的选择？我是否忽视了某些依据？当有人力介入时，我是否考虑到了其局限性？什么因素是不确定的，为什么？我是否只考虑到了目前的趋势？我有否误解了什么？我使用了正确的定义吗？我是否综合考虑了所有相关的因素？我采用了合适的衡量标准吗？我有否混淆了成因和相关性？如果我的目标是基于某个我认为正确但其实是错误的理念，会如何？其中会有随机性的或者系统性的错误吗？对于我所得到的结果，有没有其他原因可以解释？我有否考虑过，整个系统或者某些互动环节的可能会出现我不希望发生的变化？
我的想法是否存在偏见？在做出一个极具智慧的决定时，我的自我是否过于膨胀？我真的会创造历史纪录吗？我有否看到可能产生的反作用？
我没看到的是什么？其重要之处是什么？如果逆转我的假设，会否得到极度不合逻辑的结果？这个可能性是不是更高？有没有反例？什么依据可以证明我是错的（或者证明我无法达成目标）？实验（或者经验、观察）得出的证据中，有哪些是错误的？有更多支持性的证据吗？这些错误是如何导致的？
意义何在？我能否向人们证明正确假设所得到的结果是不可能出现的？如果我用数学的方式准确描述出来，其隐含的影响是什么？相反的方向是不是更有可能？如果是，那么现在的想法就是错误的。
负面影响表现在什么地方？
我会因何受到伤害？什么可能向错误的方向发展？什么会让事情走偏？如果这样，结果如何？
事情出错的频率如何？会否有意料之外的因素？什么事情发生后会极大改变整体结果？
可能发生的最坏的境况是什么？发生的可能性有多大？如果不幸发生了，我该怎么做？如果事情继续恶化，后果会是什么？这个后果的后果又会是什么？
如果我受到多种外力的阻碍，结果会如何？哪种有效效应是危害最低的？
执行中会面临什么风险？
我最不希望出现的是什么？我最不确定的是什么？
一个看上去是优势的因素有没有可能让我得到不希望的结果？我会怎样失去某个优势？
怎样构建系统才能将负面影响降到最低？有修正办法吗？发生了意想不到的事情，我有没有备选方案？我能加以修正吗？设定什么样的规则可以帮助我达成目标而规避不希望的结果？有没有内在的安全隐患？
What are the consequences if I am wrong?
如果我错了，后果会怎样？
我把赌注押在哪些关键要素上？我是否拿对我重要的东西去冒险，换取的有可能是对我效用相对较低的东西？
与现有的次优机会相比，我的正确决定所带来的益处和价值是什么，错误决定的成本（金钱、时间、精神压力等）是多少？
我这样做是因为我坚信其结果能最好地实现我的利益；或者我相信能符合我利益，但后来证明我错了；或者它根本就不符合我的利益。上述三个可能性给我的目标带来的短期和长期的后果会是什么（实际损失和机会成本）？我能否加以应对和/或还原？
我不这样做是因为我坚信其结果不能最好地实现我的利益；或者我相信不符合我利益，但后来证明我错了；或者它根本就符合我的利益。上述三个可能性给我的目标带来的短期和长期的后果会是什么（实际损失和机会成本）？我能否加以应对和/或还原？
如果我因为认为不必要而此刻不采取任何行动，但时候证明我错了，这给我的目标带来的短期和长期的后果是什么？我能否加以应对和/或还原？
What is the value?
价值是什么？
对我来说，每一个替代方案的实际效用和优势是什么？哪个方案最有利于我达到目标？它是否真的比其他选择更有吸引力？
我用什么标准来判断替代方案之间的优劣？
通过对每个替代方案的特点进行打分，我最看好的是哪一个？
这个选择能不能让我脱颖而出？能不能造成一定的影响？我是否愿意接受某种特定的结果？
What yardstick can be used to measure progress or to measure things against?
采用什么标杆来衡量事情的进展？
我采用了哪些标杆？用作决策依据的标杆是哪些？
我怎样才能容易地评估我向目标推进的程度？有哪些指标可供我对照？
我所构建的系统能否激励人们按照最有利于达成目标的方式去行动？或者，这个系统是否会阻碍目标的完成？
How act now?
现在如何行动？
我可以执行吗？我现在必须开始采取的特定行动是什么？首先需要做的是什么？
谁做什么，什么时候做，在哪里做，为什么做，以及如何做？
我知道决定性的点（时间和效果）在哪里吗？
我是否设置了一定的控制体系和规则？为什么这些规则是合适的？如果我不设置这些规则（或者不改变我做事的方式），结果会如何？这个规则要求我必须采取哪些管理和实践的举措？要遵循这个规则，会花费多少时间？我能否决定自己如何遵循这些规则？我可以设置一个有时间限定的规则吗？这些规则在哪些地方会失效？
Have I made an active decision?
我所做的是一个灵活的决定吗？
我是否准备好了改变决定，以适应新的信息和新的判断？
如某一特定事件发生，是否需要做出新的决定？如此问题今天就存在，我有否对其进行过评估？支持此决定的理性思考现在是否存在？有什么新的证据证明这个可能性能可以得到改变？我衡量进展的标准，是否能让我判断之后将要发生的事情？哪些事件是相关的，哪些是不相关的？我的目标会否因此发生改变（若不考虑时间长度）？
Post mortem or learning from mistakes
死后反思还是边学习边成长？
事情进展的情况有多好或者有多不好？我有否采取什么行动？我说到做到了吗？当时我是怎么考虑的？初衷和现实的出入在哪里？
为什么我会犯错？犯错的过程是什么？在哪里犯错了？机会成本有多大？
我如何判断现状是否会照此继续下去？我对错误有没有采取行动？如何才能不重演错误？我该做却未做的是什么？我应该把精力集中在哪里？我必须提高和学习的地方在哪？
What exactly is the problem?
问题的本质在哪？
我想达到的是什么？为什么我没有达成目标？发生了什么？怎么发生的？在哪里发生的？什么时候发生的？谁被影响了？
我的目标因何而达成？能够促使我达到目标的因素会受到什么干扰？这些因素是标还是本？对我达成目标构成限制的因素中最重要的是哪一个？我把目标建立在什么原则和假设上？如果这些原则和假设有误的话，结果会如何？假若不存在任何限制，最好的行为链是什么？其他可能的结果是什么？
WHAT ARE THE LIKELY CONSEQUENCES CONSIDERING HUMAN BEHAVIOR?
人类行为纳入考量后的结果
What is causing me to do this?
什么促使我这样去做？
目前我所处的环境和我的心理状态如何？如果避免了痛苦，我能获得什么好处？我如何判定什么是结果？它们让我难受还是愉悦？哪种心理趋向会影响我？这些因素会导致我做出误判吗？
What is the context?
做决策的语境是什么？
环境和参与者（包括其规模）是什么状况？谁是决策者，他做决策的标准是什么？谁获益，谁买单？谁为结果负责？参与者对现实结果的看法会受什么影响？
Can I judge him?
我能对他做出正确的判断吗？
我能判断他的角色是什么吗?他的经历如何？哪些临时性或者永久性的特征在影响着他（如年龄、文化背景、健康情况或者心情）？什么环境（内部或者外部的）或者处境会影响他？他是否意图向我出售什么？
What is in his self-interest to do?
他的个人利益在哪里？
什么会符合他的逻辑？他如果避免痛苦，可以获得什么益处？他将什么视为痛苦？他害怕什么，为什么？他想多得到一些什么，不想失去什么？什么“资源”会带给他动力？是他的健康、工作、家庭、职衔、声名、地位还是权力？什么会激发他，什么会打击他？什么会（被他视作）是对他的惩罚？他可以如何被评估？他怎样看待“非目标”的后果？对某事的相信（或者不相信）是否能给他带来优势/利益？
What are the psychological tendencies and shortcuts that influence him and can cause misjudgment?
什么心理取向或缺陷会导致他做出误判？
什么偏见会影响他得出的结论？有什么外在原因可能会影响他？哪些诱惑会符合他的个人利益？什么会激发他去行动？
What are the consequences?
结果是什么？
我最终的结果是什么？能达到我的目标吗？有利于他的东西是否也有利于我？我们建立的系统是否能让相关参与者的利益与我的目标相一致？他的错误决定是否会由这个系统来买单？他是否知道他的行为的结果？对他来说，短期或长期的结果是什么？责任链是什么？他对结果是否负有责任？如果换一个人也做同样的事情，会如何？
What system would I like to have if the roles were reversed?
如果交换角色，我希望构建什么样的体系？
如果将我的角色调换，我希望怎样被对待？什么会促使我去做我希望他做的事情？我能通过什么行为取向来影响他的行为？如果我执意要达成“非目标”，我需要怎么做？把角色转换回来后，我能够避免以上事情发生吗？
Is this the right system?
系统正确否？
我可以满足他的个人利益吗？我能否消除他对失去声名、金钱、地位，以及家庭的恐惧？我可以改变他对痛苦的看法吗？怎样架构体系才能使某些影响最小化？我有否告诉过他我的期望是什么？我有否检查过已经完成的事情？对于成功完成的事情，我是否给出了鼓励与支持？他掌握必需的技能、知识和相关的信息吗？他知道自己肩负的期望吗？他是否明白无误地知道目标是什么，如何达到，以及为何这是最优途径？他会评估自己的进度吗？这与他的日常行为有关吗？他是否负有责任并获得了授权？他所能得到的奖励是否和目标一致？我可以设定什么样的规则来应对人类共有的局限性？设置一个相反的规定会怎样？哪些改变是必须发生的？谁对此负有责任？发生改变的可能性会有多大？他的价值观是什么？他的目标？他会将什么视为结果？如果他如我们所希望的那样去做，他会如何看待结果？如果他不照我们希望的那样去做呢？
BUSINESS EVALUATION
Filter 1 - Can I understand the business - predictability?
：我能理解业务吗
需求的原因——我有多确定（并且能解释为何如此确定）人们将来仍会继续购买这类产品或服务？过去的情况是什么，未来可能发生什么？需求是否呈周期性？生产能力与需求的对比是什么样子？
回报能力——产业和公司的回报能力，以及其过去10年的发展状况是什么？
产业结构——竞争者的数字和规模？谁在该产业中拥有发言权？要在该产业中获利，什么因素是必须的？公司在产业中的地位如何？我是否知道谁会在这个市场上获利，为什么？
真正的消费者——谁对购买行为有决定权？其决定的标准是什么？
Filter 2 - Does it look like the business has some kind of sustainable competitive advantage?
：此业务是否有足够的竞争优势？
竞争优势——我有多确定（并且能解释为何如此确定）别人会购买我公司的产品或服务而不是其他人的？其中的原因是否10年来几无变化？在下一个10年会不会改变？
价值——我们的优势能有多强大和可持续？这些优势在若干年后会更强大更具持久性吗？什么会破坏或减少这些优势？市场进入壁垒？品牌忠诚度？受需求或价格变化的影响程度？是否容易复制？产品生命周期是否很长？客户改变供货商的成本和动机为何？每年能够抵御机竞争的价格差异（Annual cost differential against competition）？需要多大的资本投入？议价能力如何？产品过时的风险？客户新的替代选择是什么？购买习惯或购买力会有何改变？若成本结构相同，竞争对手会有多大的降价空间？需要做什么才能保持稳固的竞争优势？还有成长空间吗？市场对此产品的需求有上升的可能吗？定价能力如何？
盈利能力。竞争优势能否转化成利润，并且如何才能做到？公司怎样盈利？要实现收入增长，需要多少资本？财务特征：资本回报率（营业利润率和投入产出比）、毛利率、销售额增长、成本/资本结构及其使用效率？正常情况下的现金流是多少？有无规模优势？有无决定性的因素？
财政特征。资本回报（操作成本的富余和资本转化），毛利润，销售增长，成本和资本结构的效用率？正常的现金流？规模优势？
Filter 3 - Able and honest management?
：能干且诚信的管理层？&
组成管理团队的，是能力出众、诚实可信，并且理解和全力去创造价值的人吗？
Filter 4 - Is the price right?
：价格正确否？&
我能够以比其他选择有更好回报的价格买下这个产品么？需要有事实和数据为依据。
Filter 5 – Disprove
生意会怎样被毁掉？如果公司要彻底将一个竞争对手置于死地，这个对手会是谁？为什么？如果公司继续运营下去，5年之后谁会是竞争对手，为什么？公司业务抵抗不利因素的能力如何？如果公司花光了所有的股权投资，它还会不会有价值？会否出现某人获得大量资金和人才，在竞争中胜过公司？如果竞争对手并不在乎回报，他可以对公司产生多大的破坏？公司对经济衰退的敏感程度如何？执行时所面临的风险有多大？新技术会有益还是有害？
Filter 6 - What are the consequences if I'm wrong?
：如果我错了，结果会如何？
做产品设计的时候每天都会需要做各种决策，这种决策如果没有一个产品原则指导的话根本做不下去，因为往往两个方案都各有利弊，你的取舍没有依据。对于产品原则的理解，在这次听genie分享有了非常深的感悟，干货和大家一起分享。Genie是腾讯唯一一个p4（专家级）女产品经理，也是我知道的唯一一个p4产品经理，是从无到有搭建出微信的产品负责人，如果张小龙是上帝，那genie就是为上帝造人的那个人，坊间称之为“天朝第一产品经理”，这是第一次genie和大家系统的讲述微信的产品原则吧，这要感谢“产品＋”这个课程，不仅都是干货，而且都是高品质的精华。最难的是大概道理我们都懂，但没抽离出来形成自己的产品原则，更难的是，你都知道，但是没消化成自己的东西，在做产品策划的时候还在不断犯这些错误。废话不说，直接来吧。对于熟人社交而言，三个价值导向：越亲密的关系越有价值越近的消息越有价值（所有最近的消息倒序在最顶上）越原创的内容越有价值根据这三条，在创建产品时很多产品逻辑和后台算法就能清晰的做出权重分配排序了。微信十条产品原则：1.隐私vs便利：隐私重要性大于便利。案例：常有用户抱怨为什么换一台手机所有聊天记录都没了，为什么登陆网页版每次聊天记录都是从零开始，为什么聊天记录不能每次同步存储，因为一旦换设备/微信网页版每次登陆都显示之前的聊天记录，很可能别人在其他设备登陆你微信，所有记录都看到了，这种隐私泄漏给你带来的风险比聊天记录清零带来的伤害大得多，基于隐私性大于便利性原则，即使聊天记录清零可能带来不便利，依旧优先隐私性。所以微信在手机本地聊天记录不保存，宁可不够便利，也不牺牲隐私体验；2.发送方vs接收方：你觉得发送方和接收方哪个更重要？保护两端感受，但当两方有冲突时，更保护的是接收方，微信的产品理念认为接收方体验大于发送方。案例：a.因为这个产品原则，所以微信到现在没做已读体验。而阿里做社交的产品理念认为发送方比接收方重要，所以之前阿里的叮叮（不确定来往是不是）每发一条信息都会告知你已读未读状态，这让发送方很爽，我希望知道你是否看到了我的信息，但让接收方很有压力，因为我看到了不代表我现在想回你，但你知道我看到了，我不回你就显得没礼貌了，所以，用的时候压力很大，老板喜欢这样的功能，员工用的很受罪。所有产品体验都是基于产品原则作出的决策，对于从无到有创造一个产品，需要先建立起自己的产品原则。b.接收方体验优于发送方第二个细节：白底黑字比绿底黑字更清楚，所以微信里白底黑字展示给了好友发的信息，而自己发的话自己本来就清楚，所以自己发的文字底色是绿底黑字。c.接收方体验优于发送方第三个细节：很多人提为什么短视频不支持自拍功能，因为自拍需求大多是女生的需求，这让自拍的人挺爽，但试想一下当朋友圈被各种妹子自拍占领，就一个头，还会动，对于接收方而言，其实看的没那么爽，而且还挺恐怖，所以考虑到接收方体验没有做小视频自拍3.缺乏价值支撑的流量，事倍功半：这句话需要很深入的去理解，因为我们经常犯这样的错误，现在大多数app的思路还是引流，拉下载，框用户，流量是一千万有1%的用户转化，就有10万真实用户，所以不断找流量，而大多流量被浪费了，如果将思路放在提高被浪费的99%的转化，走精准路线，或许100万流量就能达到10万用户了；除此外，会员增值／游戏付费／谈n个风投也是一样的道理，基于拉过来的人多了，里面总有愿意掏钱的，走的都是海量流量低转化率的思路，这种就是缺乏价值支撑的流量，太浪费了，而小而精的模式就是公测1000人，500人活跃，200人愿意付费，这种就是现在越来越多人走的垂直化精细化的运营方式，不需要买那么多没用的流量，保证高转化就行。4. 对用户而言固定路径是最近路径：案例：很多人在问为什么不能让最近发送的表情在最近的位置；原因是每次发表情都会改变表情顺序，每次打开表情顺序都被改动，反而会延迟找到想要表情的时间，觉得表情不好用。最快的路径永远是固定的路径。5. 不一定按数据说话，按用户需求和价值说话：这条我是真的很佩服微信，是微信很牛的地方，也是绝大部分产品很难做到的地方。我们习惯了一切按数据说话，数据不好的产品就下线，数据不好的功能就下架，不赚钱的东西就撤掉，也是因为这么浮躁的心态，让极致的好产品出不来。案例：小视频发送入口有两个：一个是顶上下拉发小视频，另一个是朋友圈右上角发小视频，请问你认为哪个入口使用人数更多呢？停顿两秒让自己思考下吧。答：朋友圈右上角?占95%，上方下拉只占了5%，朋友圈右上角加号入口虽然更深，但用户已形成通过右上角加号发新内容的操作体验，而下拉体验用户没有形成习惯那么，为什么只有5%的用户通过下拉来拍摄小视频，还没把这个入口干掉，如果按数据说话应该干掉这个入口，那为什么没干掉？答：因为我们不是完全按数据说话的产品，更重视用户体验：主界面快捷方式对于要拍摄稍纵即逝的瞬间，需要最短路径马上拍摄，如果撤掉，当遇到非常好瞬间要拍摄的时候，拍摄路径太长会导致错过很多好的瞬间，并且这些稍纵即逝的瞬间的内容价值可能远高于慢慢从固定路径录制的内容价值。Os：清醒地知道产品每个功能的价值，数据只是反应现状的参考指标，而不是结果本身。6. 效率价值对大化value/time（单位时间内的信息量）：文字 图片 url 视频哪个性价比最高，哪个信息量最大：url信息量最大，图片性价比最高，视频的信息量很大但性价比最低。微信里体现价值信息最大化原则案例：1.朋友圈点赞没有头像，2.小视频自动播放，3.url的弱化，4.文字太长时折叠，5.单图vs多图：单图缩略图很大，最高效率，不用点开大图也可以看清楚，而多图的时候会变成小的缩略图，这时候接收方的诉求是要第一时间知道这九张图核心要说的信息是什么，点开大图再看具体内容。7. 不同很易，更好很难案例1：当时apple watch邀请微信做一个适合watch的产品，第一个版本微信做了雷达加好友，放在watch上看很创新又帅气，但apple没有采用雷达加好友这个方案，why?答：1.附近没几个人带手表，2.在手机上都没几个人用雷达加好友，何况手表上呢，这个属于然并卵的功能。比如新浪微博做的watch版app的功能是跑步记步功能，但微博属于信息类的，做个计步器和微博有啥关系，无法体现产品核心价值；所以最后还是选择把收发消息，看朋友圈，赞等基础核心功能发上去，做实用性的东西比做帅气不同的东西更有价值，不为创新而创新，不为不同而不同。案例2:为什么要做小视频：1.视频信息含量是最高的，是文字和图片无法比拟的；2.有些场景是很难用文字描述的，视频可以解决；而做小视频是因为大视频信息量很大，收看时间长，信息价值不高，所以用6秒小视频来做到既有信息量，又保证信息价值。反例是qq空间，空间一直有长视频，看到微信出了短视频，也把自己的长视频改成短视频，结果被用户投诉的要死，这就是产品经理没有想清楚自己的产品定位，一味模仿追随，空间最擅长的是沉淀，长视频是最好的沉淀形式之一，更别说空间还有pc阅读特性等差别。不同很易，更好很难。微信最大的价值是有关系链有朋友，不用通过和同类产品比内容价值来凸显自己：我不是为了拍一个有趣的视频给你，而是告诉你我在哪在干嘛。如果微信要做小视频，要做的是信息，而不是内容，不是视频美化。很清晰的看到自己的位置，不盲目的和同类产品攀比，从来不是与外部赛跑，而是与自己pk的过程。小视频定位：极快 极易 高价值 核心定位是消息 朋友圈8. 简洁的原则：简洁不是简单，简洁不是简单的把功能裁掉。案例：为什么iPhone刚开始的icon是拟物设计，这种设计实际是很复杂的，在一个图标上每个角度纹理都要处理，但对于用户而言拟物很真实，学习成本更低，在智能手机刚面世的时候可以降低学习成本。为什么现在的iPhone要做扁平化，不再坚持拟物：因为智能机的普及，每个icon是做什么的，用户已经都理解了，不需要再用拟物的方式去普及，而扁平的icon并没有比拟物的简单，反而在设计上可能是更复杂了，需要用更简洁的方式让用理解icon。9. 逻辑原则vs线性原则：避免用tabs，保持一个入口。如果你有两个tab的话，就会有一个主tab，按已有的数据显示2个tab会二八分配，80%的流量在主tab，只剩下20%的流量到第二个tab。如果你已经能决定哪个tab是核心，那为什么还需要第二个tab，如果你没办法决定哪个最重要，那分tab也没办法为你决定，还是会二八分流，专注主要功能，把所有流量聚焦在一个tab，不作无谓分流。不用多tab展示，一个地方不要两个按钮。（这点很多app都在犯这个错误）。在逻辑原理和线性原则相冲突的时候，优先线性原则：案例：微信的搜索原本是放在顶上加号旁边放一个放大镜的icon，但最后还是把搜索框直接加在聊天记录顶部的搜索框，而不是右上角放一个?一个 两个icon（抗拒两个icon，坚持线性原则）10. 真实vs噱头：真实性大于噱头，真实的内容才有生命力，噱头往往是对信息的破坏。案例：美拍等视频拍摄工具都有配音，加特效等功能，美化后让整个视频变的很好看，但微信不会做这些，因为美化后的视频，去掉了声音等，无法还原给朋友传递信息的真实现场。真实性还体现在微信的所有数据，各种对外的方式都秉持真实性。打磨精品，注重产品细节：注重细节：收到多条语音，会自动播放语音；语音可以上滑取消等极致的细节分享：细节1:小视频播放完后从最后一秒到第一秒循环时直接切换会导致视觉上闪过一下，脑子里会闪过一条白线，为了让这个闪不那么不舒服，在小视频最后一秒做了颜色渐弱，通过一秒弱化让用户视觉舒服地过渡。绝大部分用户是不会感知到微信做了这个体验优化的，好的产品让人用的爽，而不需要让人知道他们为什么爽。细节2:视频和照片的夜视效果在爱疯上不是特别好，所以微信的小视频和照片在监测到光线比较暗时，会提示加亮效果（为了这个小细节微信团队找过世面上所有产品比对各种相机产品，将加亮模式做到极致）常见的坑和注意事项：1.从目标倒推方案：比如我们要50万用户，那倒推要三件事每件事引流10万 20万 20万，按此方式可能会达到kpi目标，但很可能会背离你设计这个产品的初衷，用手段而不是产品功能达到目标，但这不是真的解决问题的方法案例：提升海外活跃度：发现当用户好友数超过15个时，活跃度会增加很多；所以当时的做法是引导加好友，然后又引导加陌生人，好友数还不够，就改版附近的人，这种就是按目标倒推数据方案的反例。数据可以帮助你了解原因，但不会告诉你原因。一个成功的决策，不知道原因，比一个失败的决策更危险。（这点非常重要，很多团队觉得达到kpi了就万事大吉，而不去分析是用的牺牲未来的短期营销达到的，还是真的是产品优质达到的；这个错误是每天每个产品，团队都在犯的，能意识到这点的存在本身已经很不容易。）2.关于AB test（分组测试）：AB test可以用来对比效果，而不是选择方案，用的越多，表明产品经理判断力越弱使用AB test时要有很明确的选择，并且知道影响因素是不可控的。3.普通用户没法告诉你他们自己还不知道的需求，需求是产品经理去观察发现的。不要去问用户你觉得我怎么做会比较好，因为他不知道，或者只是他以为他知道。很多人用mac觉得很好用，但在mac出来前你会知道你需要的好用的电脑是酱紫的么？比如很多用户使用任务软件时，主动设置很多任务，并且都加上了提醒，当用户主动加提醒时觉得自己想要被提醒，但当每天都被提醒n次时就开始烦了，关掉提醒甚至直接删除这个app。4.能用标准方法／标准控件解决问题就不要用特殊处理以上是一整个下午听genie分享产品原则记录下来的笔记和心得，也是在听过的众多产品课程里最有收获和启发的一场，有的产品是被抬到神坛的，而有的产品是靠实力走上去的，我从不搞什么个人崇拜，但觉得genie以及微信在产品设计上做出的每个决策都有自己的产品原则作为方向标，是非常值得欣赏的，不是微信从没决策失误过，而是每个精良的产品都是在不断试错中越来越完美的，对于创建一个新产品亦是如此，不怕一遍遍试错，就怕不思考不知道错。很感谢genie和如此好的产品精品课程，受益良多。上述产品原则和体验就我自己而言感悟很深，很多原则需要再多次反复消化，对未来做产品很有启发，被提炼出的真理难的是在从无到有的提炼过程，而享受前人成果时，我们太容易因为理所当然，而忽略了每个真理对于现实运用的意义。作者：微型商人
来源：其他跟进项目是产品同学的工作内容之一。任何一个项目都可以划分为以下三个阶段：1. 前期：确保目标合理，需求明确，人员到位。尽全力让大家对目标，工作内容，进度，分工及接口人，预期效果，理解一致。2. 中期：设检查点，反复确认沟通无漏斗，理解一致。发现风险，控制进度。3. 后期：效果反馈，反馈给所有人，并感谢。重点在前期，前期工作多细致周到都不为过。下面谈谈风险：1. 目标不合理。产品目标制定主参考项是市场形势，不能抢占制高点，后续成本急剧攀升，或许再无机会。目标要和上级沟通好，有风险及时反馈。2. 需求盲点。前期未明确或者未想到的问题，理解不一致的地方都是风险高发区。3. 人员配备。项目执行中，需要各种技能的人员，需求定义与分析，交互设计，视觉设计，前端开发，客户端开发，服务端开发，算法研发，功能测试，性能测试，产品运营，数据分析师，DBA等等。根据项目不同，所需技能水平亦有不同，一个人可以cover多个技能，承担多项责任。项目主要负责人，需要知道特定项目需要具备哪些技能的人，在哪个水平线上，时间能不能保证，那一块是有风险的，强度如何，备选方案是什么。3. 检查点。关注项目进展是否顺利，阶段产出是否按时保质完成。设计图，接口定义要先行。测试沟通、数据统计与评估方案也是要早期完成的工作。早启动早完成早确认。4. 根据数据情况，反馈项目效果，同时出具后续方案。开始新一轮迭代。把做什么想明白，成功了三分之一。让项目成员都明白，目标一致紧密配合，又成功了三分之一。可以说一半以上的工作是前期完成的。
微信——腾讯战略级产品，创造移动互联网增速记录，10个月5000万手机用户，433天之内完成用户数从零到一亿的增长过程，千万级用户同时在线，摇一摇每天次数过亿...&&&在技术架构上，微信是如何做到的？日前，在腾讯大讲堂在中山大学校园宣讲活动上，腾讯广研助理总经理、微信技术总监周颢在两小时的演讲中揭开了微信背后的秘密。
周颢，2001年毕业于华南理工大学，计算机专业硕士。2005年加入腾讯广州研发部，历任QQ邮箱架构师，广研技术总监，T4技术专家，微信中心助理总经理。
周颢把微信的成功归结于腾讯式的“三位一体”策略：产品精准、项目敏捷、技术支撑。
微信的成功是在三个方面的结合比较好，能够超出绝大多数同行或对手，使得微信走到比较前的位置。所谓产品精准，通俗的讲就是在恰当的时机做了恰当的事，推出了重量级功能，在合适的时间以最符合大家需求的方式推出去。他认为在整个微信的成功中，产品精准占了很大一部分权重。
敏捷是一种态度&敏捷就是试错
微信研发团队里鼓励一种试错的信仰：他们坚信，在互联网开发里，如果能够有一个团队在更短的时间内尝试了更多机会(并能改进过来)，就能有(更多的)机会胜出。敏捷是一种态度，在软件开发过程中，项目管理者都会非常忌讳“变更”这个词，但是在微信的项目运作中是不可以的。因为微信必须要容忍说哪怕在发布前的十分钟，也要允许他变更。这是非常大的挑战，因为打破了所有传统项目开发的常识。所有人都说不可能做到的，但微信做到了。研发团队所做的一切都是要给产品决策者有最大的自由度，而这个决策正是微信能够胜出的关键。
海量系统上的敏捷&无异于悬崖边的跳舞。敏捷有很多困境，如果做一个单机版程序，是可以做到很敏捷的，但是腾讯正在运作的是一个海量系统，有千万级用户同时在线，在一个单独的功能上每天有百亿级的访问，同时还要保证99.95%的可用性。在海量系统上应对项目开发会有很严谨的规范，都说要尽可能少的变化，因为90%-95%的错误都是在变更中产生的，如果系统一直不变更会获得非常高的稳定度，但是微信就是要在悬崖边跳舞。微信的研发团队要做一些事情，让敏捷开发变得更简单。
如何做到这一切？周颢认为，首先，必须建立起一种狂热的技术信念，就是一定是可以做到的。然后，需要用一些稳固的技术(理念)来支撑，例如大系统小做、让一切可扩展、必须有基础组件、轻松上线(灰度、灰度、再灰度；精细监控；迅速响应)...等等来支撑。
四大法器：大系统小做、让一切可扩展、要有基础组件、轻松上线
1）&大系统小做：当设计庞大系统的时候，应该尽量分割成更小的颗粒，使得项目之间的影响是最小的。
2）&一切可扩展：在高稳定度、高性能的系统中间，为了稳定性能把它设计成不变化的系统，但为了支持敏捷需要让一切的东西都要变得可以扩展。
4）&必须建立基础组件：要解决复杂问题的时候，需要将已有的经验固化下来，固化下来的东西会成为系统中的一部分。
4）&轻松上线：当做了变化并把它从开发环境中部署到现有的运营环境中去，在这个过程中，“灰度”这个词非常关键，就是在黑和白之间的选择，必须要变成一种小规模尝试，再逐步扩展到海量过程中的一个问题。
大系统小做——仅仅把模块变得更为清晰，这在海量系统设计开发中是不够的，还需要在物理环境上进行分离部署，出现问题的时候可以快速发现，并且在最快的情况下解决掉。
大系统小做&混搭模式
将不同的应用逻辑物理分割独立出来，用户注册登录、LBS逻辑、摇一摇逻辑、漂流瓶逻辑、消息逻辑独立开来。把关键的逻辑混搭在一起，当所有的逻辑部署在同一个服务器上，确实也会带来很大敏捷上的好处，因为不需要额外的考虑部署和监控的问题。在整个微信的逻辑中，可能现在已经有上百种不同的逻辑，因为会在逻辑的分割上拆分成8-10种做分离部署。
一切可扩展——网络协议可扩展、数据存储可扩展
扩展的关键点有两块。一个是网络协议需要扩展，当要升级一个新功能的时候，会有一些比较大的困难，所以所有协议设计都比较向前兼容，但是向前兼容还是不够的，因为网络协议设计本身有非常多的功能也会有比较大的字段，相关的代码可能会有数千行，这一块不能通过手写方式完成。可以通过XML描述，再通过工具自动生成所有的代码，这是微信获得快速开发的一个重要的点。
另外一块就是在数据存储方面是必须可扩展的。在2005年绝大多数海量系统的设计都是采用固定字段的存储，但是在现代系统中会意识到这个问题，会采用KV或者TLV的方式，微信也做了不同的设计。
把复杂逻辑都固化下来，成为基础软件。在微信后台会有几种不同的基础组件。大致包括：
Svrkit——Client/Server自动代码生成框架:10分钟搭建内部服务器
LogicServer——逻辑容器：随时添加新逻辑
OssAgent——监控/统计框架：所见即所得的监控报表
存储组件——屏蔽容灾/扩容等复杂问题
灰度、灰度、再灰度&
在变更后的部署方式上，微信在一些规则会限定不能一次把所有的逻辑变更上去，每一次变更一小点观察到每一个环节没有问题的时候，才能布局到全网上去。微信后台每一天可以支撑超过20个后台变更，在业界来说，通常做到5个已经是比较快了，但是微信可以做到快4倍。&
腾讯内部的上线系统&
而所谓灰度发布，是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面&来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。(在腾讯，灰度发布是最常采用的发布方式之一)&
孙子兵法：古之所谓善战者，胜于易胜者也&
常识上，解决一个复杂问题的时候，会用高明的技巧解决复杂的问题，这个不是微信团队的目标，追求的要做到让所有问题很自然和简单的方式解决掉。在周颢看来，微信架构的技术复杂点在四个要点：协议、容灾、轻重、监控。&
协议：&手机终端跟后台服务器之间的交互协议，这个协议的设计是整个系统的骨架，在这一点做好设计可以使得系统的复杂度大大降低。
容灾：&当系统出现了若干服务器或若干支架(宕机的时候)，仍然需要让系统尽可能的提供正常的服务。
轻重：&如何在系统架构中分布功能，在哪一个点实现哪一个功能，代表系统中间的功能配置。
监控：&为系统提供一个智能仪表盘。&
在协议设计上，移动互联网和常规互联网有很大的区别。首先有CMWAP和CMNET的不同，在中国现在有相当多的手机用户使用WMWAP连接，还有就是在线和离线的概念，当QQ下线的时候叫离线，当你登录的时候叫在线。但是在移动互联网这两个概念比较模糊。从微信的设计中，不管在线还是离线系统表现都应该是一致的。还有一个是连接不稳定的问题，由于手机信号强弱的变化，当时信号很好，5秒钟走到信号不好的地区，连接就必须断掉。这个中间带来不稳定的因素为协议设计带来较大困难。此外就是资费敏感的问题，因为移动互联网是按照流量计费的，这个计费会使得在协议设计中如何最小化传输的问题。最后就是高延迟的问题。&
对此，业界标准的解决方案：Messaging And Presence Protocol：
XMPP; SIP/SIMPLE。它的优点是简单，大量开源实现。
而缺点同样明显：1)流量大：状态初始化；2)消息不可靠。&
微信在系统中做了特殊设计，叫SYNC协议，是参考Activesyec来实现的。特点首先是基于状态同步的协议，假定说收发消息本身是状态同步的过程，假定终端和服务器状态已经被迟了，在服务器端收到最新的消息，当客户端、终端向服务器对接的时候，收取消息的过程实际上可以简单的归纳为状态同步的过程，收消息以及收取你好友状态更新都是相同的。在这样的模式之下，我们会也许会把交互的模式统一化，只需要推送一个消息到达的通知就可以了，终端收到这个通知就来做消息的同步。在这样的简化模式之下，安卓和塞班都可以得到统一。这样的系统本身的实现是更为复杂的，但是获得很多额外的好处。&
让剩下系统实现的部分更加简单，简化了交互模式，状态同步可以通过状态同步的差值获得最小的数据变更，通过增量的传输得到最小的数据传输量。通过这样的协议设计，微信可以确保消息是稳定到达的，而且是按序到达。引用一句俗话：比它炫的没它简单，比它简单的没它快，没谁比他更快，哪怕在GPRS下，微信也能把进度条轻易推到底。&
在容灾之前面向最坏的思考，如果系统真的挂了，需要做一些事情，首先是防止雪崩，避免蝴蝶效应。如果关注春节订火车票就知道了，用户的请求量会因为系统服务不了而不断的重试，意味着发生雪崩的时候，系统可能会承载原先3-10倍的流量，使得所有的事情更加恶化。所以微信有很多“放雪”功能的设计。第二个词是柔性可用，在任何的系统中不要追求完美设计，追求完美设计的是团队是不能胜任海量服务的。如果在一个系统出现问题的时候，这个系统就挂了，那么这是一个不好的设计，最好的做法是提供0-1中间的选择。举一个例子，当一个用户向另外一个用户发消息的时候，可能会通过一个垃圾信息过滤的检测，如果垃圾信息过滤这个模块突然挂掉了，这个消息难道就不能达到了吗？在这样的情况下，要忽略掉这个错误，使得消息正常达到对方。要精确定位出哪一个环节是最为重要的，把不是重要的错误尽可能的忽略掉。当不能做到完美的时候，尽可能为用户提供服务。另外一个重要方面叫做“保护点前置”，最前的一个点就是终端，在手机终端上蕴埋更多的保护点，这样会为用户系统赢得更大的处理空间。如果终端具备这样的能力，会获得更大的反应空间。&
周颢介绍了在微信上具体容灾设计的做法。在所有的容灾中存储层的容灾是最难的，一个系统的设计分为三层：接入层、逻辑层、存储层。接入层和逻辑层的容灾都有比较成熟的方案。逻辑层的容灾相对来说比较简单，尽量不要有状态的设计，比如说当你做上一个请求的时候，会保持一些状态，要使得下一个请求发到下一个服务器。如果任何一个请求之间互相不关联的话，这个就是无状态的设计，只要做到这一点逻辑层的容灾可以随意的切换。在回到存储层本身的容灾设计上，相对来说困难一些，但是微信研发团队采用了一些技巧，叫分而治之，分离业务场景，寻求简单的设计，并不会寻求大而同一的解决方案，因为这样会使得系统的复杂度大幅度上升，而微信会尽可能把产品拆细，寻求简化的设计。&
第一种是主备容灾，这是最常见的方案。在有一些业务场景中是可以容忍最终一致性的，比如账号系统的设计，每天写入账号系统的请求是非常少的，但是访问的请求非常多，这个差异可能会达到数万倍的规模，在这样的场景下，微信会在账号系统中采用简化的方案，也可以获得比较大的稳定度。&
SET模型＋双写
第二种容灾的模式叫双写，两台Master的机器，当一台机故障的时候，另外一台机还是可以接收到写请求，当两台机交错启动的时候，会得到数据的丢失。但是有一些场景是可以容忍轻度数据丢失的，比如说会有一个存储专门记录用户终端的类型，比如说安卓还是塞班以及他们使用终端的微信版本是什么，这样的数据是可以容忍轻度数据丢失的，因为偶尔有一些丢失的话，下一次访问会把这些数据带上来，会尽快的修复所有的数据。双写也是非常简单的模式。&
微信的研发团队做了一个叫Simple Quorum的机制，在微信的后台中，同步协议有一个很重要的基石叫序列发生器，这样的一个序列发生器需要有极高的稳定度。首先可以看到序列号有一个特点永远是递增的，用递增方式往前推进的时候，最大的序列号就是最新的系列号。有一个毕业才加入广研的毕业生想到一个绝佳的方案，按SET分布，从2G减到200K。
周颢还谈到了轻重的概念。这个概念的提出主要是从终端本身的一些困境所带来的。首先在终端上需要表现最多的一个产品的逻辑，逻辑非常复杂，变更的成本也非常高，当需要修复的时候必须发布一个新版本，这个新版必须由自己下载才能完成，下载的成本非常高。在这样的前提下，如果手机终端产生了任何变化的时候，如果这个变化有非常大的问题就会有极大的困境，所以需要在每一个发布之前做一些充分的数据，确保不会发生致命问题。如果一旦出现致命问题难以修复，需要把关键的点从终端移到后台实现，把功能点后移，来充分发挥后台快速变更的能力。&
接入优化：从GSLB到IP重定向。在接入层的优化，速度很重要的因素，是不是能够就近接入一个最优的节点，比如说移动用户最好接入移动的节点，海外的用户可能需要寻找更佳的路由，有的时候可能无法自动做到这一点，一点是在终端上做测速，微信会通过在后台IP逆向的能力，通过后台指挥微信终端联网的能力，寻找最优的接入点。
如何解决“偷流量”的问题——当国内类微信类产品发布的时候出现一个大的问题就是“偷流量”，当用户在某一些逻辑下进行一个死循环，不断访问某一些数据，这样的死循环是非常可怕的，如果在用户不知觉的情况之下，可能会在一个小时之内偷到数10兆甚至数百兆的流量。有非常多业内的同行都需要花大量的精力解决这个问题，微信研发团队用了非常强大的方式解决它。通过在后台建立起严厉的监控系统，对每一个用户的行为做一个监控，当发现异常的时候，后台会给终端发出指令，使得微信终端在一段时间无法联网，但是可以保证用户流量不会白白的使用掉。&
功能适配的例子——第一期微信版本发布的时候，当时没有群聊的功能，第二版发布的时候做了这个功能。当时有两个选择，对于早期版本的用户，因为不支持群聊，就无法享用到这个功能，但是微信希望提供更好的选择，想让早期不支持群聊的版本，也可以被拉到一个群里面收消息、发消息，通过后台功能的适配也能做到这个事情。&
对于一个海量系统来说，一个精密的仪表盘非常重要。监控是非常痛苦的，对于这样一个系统来说，每小时会产生数百G的监控日志。微信希望在1分钟之内监控的数据就能够显示在报表上，因为只有这样的精准和实时度才能够赢得处理故障的时间。微信会做关联统计，通过摇一摇加了好友，他们活跃度如何，过了一段时间他们的活跃度变化情况又是如何。这种需求是需要通过大量日志的关联统计来获得的。研发团队也花了一段时间来理解这个问题，发现了中间一个重要的经验叫做“鱼和熊掌不能兼得”。&
为了让监控数值更敏感，需要把监控细化再细化，上面数据表示每一栏子系统的数据，下面这个是按微信版本号来划分的，这里的数据项是非常多。&
微信还需要采集一些异常的点，如果有异常的话会发布紧急的版本，尽可能快的替换它。对收发消息延时做的监控，比如说0—1秒端到端的速度，会对不同的区段做一些统计，当某一个环节出现异常的时候，通常会在中间的延时上体现出来。有一个很重要的点叫自动报警，现在有数千项的数据，不可能每一项都靠人工去看的，必须要跟自动报警相关联，微信有一些智能的算法，是不是在正常的范围内，跟历史的数值进行对比，如果有异常的话，会通过短信、邮件还有微信本身来发出报警信息。&
把监控嵌入基础框架&
微信会把监控嵌入到基础框架里面去，因为并不是每一个人都会意识到在需要的地方嵌入一个监控点，所以在基础框架本身内置很重要的监控点，比如说这个表上的栏目，非常多的栏目大概会有数百项的栏目，都不需要程序员自己去写，当用基础组件搭建一个系统的时候，就可以直接观测系统数据。&
在谈到微信未来的技术挑战时，周颢首先希望能够让微信成为可用性99.99%的系统；设计出面向现在10倍容量的系统以及完全的IDC容灾。&
网上盛传的凌晨两点，腾讯大厦那多层大片大片的灯光和楼下那长长的出租车队伍说明了一切。引用一句话做结尾，可怕的不是微信，真正可怕的是，比你领先比你更有天赋的团队比你更努力。
转载声明：&本文转自&
近几年在年初年尾的时候总碰到这样的事：“现在的小老板都用个小本本记帐，太不方便了，我们今年要给中小企业提供一个管理财务的工具，这样就可以帮助中小企业把钱管起来了”，“给客户做个电子传真的功能吧，他们就可以节约大量的传真费用和纸了”。“给客户做个在线买软件服务的开放平台吧，这样他们就能在这里买到所有需要的软件服务了”……&当我们决定做什么的时候，成功还是失败，50%就已经注定了。那究竟什么是靠谱的呢？貌似只有做了才知道，那有办法提高成功率吗？有一次卫哲来做走动管理，对每一条产品线都问了3+1个问题，令我印象深刻：&当时我们正在做一款淘宝卖家的管理工具，其中有一个功能是帮助淘宝卖家研究市场行情的，接着问题就来了：&卫：“你们怎么想到要做这个产品的？”&我：“我们在和卖家接触的时候发现有很多人花很多时间了解竞争对手的情况和市场上什么好卖。”&卫：“有多少卖家做这件事？多久做一次”&我：“大部分卖家每周都会做几次”&卫：“他们现在是怎么了解竞争对手的情况和市场上什么好卖的？”&我：“他们现在每天都会上淘宝进行搜索，找到同类商品卖得好的卖家，然后看他的关键字设置有什么特点，价格是多少，卖了多少个，做了什么活动，每周要花好几小时。”&卫：“那用了你们的产品，他们怎么做这件事？”&我：“用了我们的产品，他们一方面可以看到针对他的某个宝贝，同行的类似宝贝有哪些，价格如何，销量如何。另一方面可以看到某一类目下特定关键字下，哪些宝贝卖得最好。”&卫：“也就是说你们是帮他们节约时间？小企业的时间是不值钱的，中国是这样，美国也是这样。”&我：“…”&卫：“这些数据他们自己在网上能看到吗？”&我：“能，但有些统计和分析，比如平均价格，有多少人比他价格高之类的他不知道。”&卫：“那知道了这些信息之后呢？他能做什么？”&我：“他可以做一些关键字的修改，价格的修改，或者换一下推广的商品，做直通车的时候可以更有的放矢。”&卫：“那我们的功能有没有和推广挂钩，比如和直通车做整合？直接让他做直通车的优化？”&我一愣，这个问题我还没有想过，但立刻意识到这可能是个方向：“还没有，不过的确是个很好的方向。”&卫：“那客户在用了你们的产品后，网站数据上会有什么反应？”&我：“也许卖家的搜索行为会减少吧，修改的次数会增加”&……&1个月后产品上线，在一个月内就吸引了上万的付费客户，但是这些客户的留存率却很低，很多人都反映一个问题：这些问题告诉我了，然后呢？&到这里，再回顾一下这次谈话，有几点是很令人惊讶的：&1.&卫哲其实没有接触过我们的业务，也许也没有接触过淘宝的客户，但通过这些问题，却很快的延伸出了几个有价值的问题，使得业务的本质显露出来。如：“那用了你们的产品，他们怎么做这件事？”&2.&所有的信息都是我们给出的，但很多问题却是我们之前没有想过的，结论也是我们之前没有想到的。&于是我们思考：是否这套分析思路可以适用于任何的陌生环境和陌生业务，让我们通过问出正确的问题来了解更多有价值的信息，然后做出判断。&卫哲把这套问问题的方法称为3+1：&3：&需求是从哪里来的？目标客户是谁？&有多少人有这样的需求？这个需求紧迫吗？&他们的痛是什么？场景是什么？（用产品之前/之后）&+1：&解决之后在网站数据上会有什么表现？&前3个问题能够帮我们切入问题的本质，引发更多的思考，后一个问题让我们思考到底要什么样的结果，如何衡量。&第一问：需求从哪里来，目标客户是谁&这个问题要一分为二，先说“需求从哪里来”，个人感觉这是最强大一个问题，直接把半数以上不靠谱的需求都枪毙了：到底是我们想做，还是客户想要？我们常常发现很多的需求是我们想要，或者我们觉得客户想要。比如“我们做一个财务管理的软件，就可以帮小企业把钱都管起来了，现在他们记账太混乱了”。可是当产品出来了，我们访问小企业的时候，大部分人不觉得这是个问题：“我们这么小的企业，弄个本子记记就行了”“我们已经请了兼职的会计，她都能搞定的。”这个项目其实还有点小插曲：做财务软件其实是大老板的战略规划，我们常常碰到这样的项目，基于集团的战略，我们决定向某个方向进军，可是做的时候呢，我们很容易把“行动方向”变成了“行动计划”。比如这个项目，老板要的是一个财务方面的产品，但我们在执行的时候，直接就变成了一个财务软件，但说不定某种“财务服务”才是客户需要的呢？&再来说说“目标客户是谁”，这是个老生常谈了，但还是很关键，我们最常犯的毛病就是把目标客户群给笼统化，扩大化了：最近我们在做一个推荐物流的项目，就是让阿里巴巴的诚信通客户来网上用德邦/新邦物流的时候能享受VIP价格，比他自己寄更便宜。这里的目标客户是谁？“所有诚信通的企业”当然是最正确的回答，但没有用，不能解决问题。接下来就要问：“谁最需要这样的推荐物流的服务？”当然是一年物流发得多的人。什么样的人物流发得多？生意好的人。如何判断生意好？网站交易量/浏览量大的人。BINGO,我们发现了要做好推荐物流应该和交易及浏览挂钩，优先对这部分人进行营销和服务。这时候就可以开始指导实践了，一大堆相关的想法开始蹦出来：是否给成交额在**以上的客户提供额外的优惠？是否对客户网站成交之后进行针对性引导？是否在客户成交之后根据其所在地精准推荐物流线路？……你看，好问题带来好想法！当然前面“生意好的人”不是唯一的答案，也有可能是“发货东西比较重，比较大的客户”，那后面推出的可能就是特定的行业做精准的营销和服务，比如五金行业。&第二问：有多少人有这样的需求？这个需求紧迫吗？&这也是个很牛的问题，有多少人有这样的需求意味着市场的容量，紧迫程度意味着解决需求的价值。容量+价值=有没有意义做。二者缺一不可。之前我们做的网店管理的工具就是这样的情况，的确很多人都有这样的需求，也愿意来使用以节省时间，但是对他来说扩大生意，找到新的客户才是最迫切的，因此，虽然付费的人很多，但注定我们无法在这上面收很高的费用，因为我们带来的价值是“省时间”，而小企业的时间不值钱（与此相关，iamsujie同期的一篇文章）。最近有个做英语培训学校的同学和我在聊天，说他发现其实他们的学生出国前都需要购置很多东西，他希望开办一个网站来告诉学生需要买哪些东西，同时可以在他的网站买。这些学生出国准备的资讯虽然是需要的，但决不是最迫切的。有多少人愿意为此买单不太好说。&如何了解市场容量和紧迫性呢？一般来说，紧迫性是我们通过深访就可以得到，比如我们去找10个小老板聊聊，就会有个直观的感觉，有多少人觉得财务管理很迫切。（当然这里要注意自己不要带着主观意愿去和他们诱导式地聊，否则听到的就只是我们想听的结果。）市场容量就复杂了，在线调研之类的常常容易使那些最有需求的人来填问卷，从而给我们错误的结论。采用随机抽样后的访谈要相对好一些，如果一个人听到你的来意之后不愿跟你多聊，基本上这事他不太需要。&第三问：他们的痛是什么？场景是什么（用产品之前/之后）&这一问是从战略到执行落地的关键一环，一件事情靠不靠谱其实光看方向是看不出来的，个人的感觉是“没有靠谱的方向，只有靠谱的做法。”而做法从哪里来呢？其实就是这里谈到的两个问题：&1.&客户的问题的场景我们是不是真的找到了？（用产品之前的场景）&2.&我们为产品设定的使用场景是否真的会发生？（用产品之后的场景）&这让我想起阿里巴巴最近在做的B2C业务：无名良品，简单的说就是阿里巴巴把B2B的供应商引入到淘宝，开辟一块独立的市场，从工厂直接向消费者提供产品。我们的出发点是B2B的供应商多（都？）是工厂，因此会比淘宝的卖家拥有更好的货源，能够给消费者提供更好的商品。在这件事情中，最终的客户是消费者，用这个问题来问一下的话，我们要问“消费者的痛是什么？”现在消费者来到淘宝，愿意花时间淘便宜货，喜欢讨价还价的就去集市，想要快速买到质量有保证的货的就去商城。“痛点”在哪？能想到的有“他们想要买工厂的一手货源，不想买经销商的”，“他们想买外贸尾单”，“他们想要更高质量的服务”。定位在不同的痛点会延伸出后续不同的做法。从目前来看，无名良品还是定位在“厂货”和“外贸尾单”。那么买家能否在淘宝买到“厂货”和“尾单”呢？搜一下你就会发现，大把的存在，且真伪难辨。那么无名良品能分辨吗？目前不能。那要去分辨吗？也许，但得先问问上一个问题：目前有多少人在淘宝上想找工厂货和外贸货但是不满意，才能决定有没有意义把它作为核心策略。如果我们还无法明确定位客户目前的痛的时候，客户的痛解决以后的场景自然无从谈起。所以虽然我不了解目前无名良品的运营状况，但我想作为我自己也是一个消费者，我始终会问一个问题：我到了淘宝，什么情况下该去无名良品买东西呢？求解…&又想起一个例子，最近在和淘宝的同事讨论淘宝开超市的事，简单来说就是淘宝在上海开一家网上超市，卖传统超市里的商品。这里我们也来拿这两个问题套一套：&问：“客户的痛是什么？”&答：“现在在淘宝买不到一箱可乐，一大卷卫生纸，或是一箱方便面”&问：“有人想在淘宝上买这些东西吗？”&答：“我也想啊”&问：“为什么不买呢？”&答：“运费太贵了，另外没有一家店能买到上述的三样东西” OK，客户的痛出来了，那我们应该给客户提供什么样的价值也顿时明确了（使用后的场景）：让客户能够在一家店用比较低的运费买到上述生活日用品。&+1：解决之后在网站数据上会有什么表现？&我们认为自己是在为客户提供价值，那总得用点啥来衡量价值有没有被认可，提供了多大的价值。比如：搜索优化了，那客户在搜索后列表页面点击率应该会提升，首页优化了，那首页点击率应该会上升。付款流程优化了，付款成功的人会上升。这个问题会逼我们去思考到底我们的客户价值到底是什么？什么是我们想要的结果，从而制订出有意义的KPI。大到一个部门，小到一个功能，都是这样。&最近我们在做一个网页呼叫的功能，让买家在网站上可以免费给卖家打电话，而不用担心长途费。这样的功能能得到认可吗？当然，付费用户数是一个很好的指标，但它跟太多的因素有关，那有什么标准能帮我们清晰地看到我们提供了多大的价值吗？我们找到了一个指标：每天接通的电话数，包括总数和人均。逻辑是这个产品的价值就是买家的呼叫，如果有买家愿意打这电话，就意味着产生了价值，所以通过关注这个指标，我们开始关注：“为什么买家没有打电话”，是因为“按钮不够明显”，还是“本来到卖家商铺的买家就太少”，还是“打电话的流程中还有很多担忧（比如资费）”，还是“买家本来就不喜欢打电话”。于是我们开始做几件事：“多布点，把按钮做得更明显”，“针对询盘多的卖家优先开通，推广”，“针对客户担忧比较多的问题在流程中做重点说明”。这个问题逼我们去思考如何提供并传递客户价值。试想如果我们的关注重点如果是“付费客户数”，也许我们关心的就更多的是付款流程，订购流程，打包出售之类的东西了。
我们做产品设计的设计师日常工作粗略分一下，可以分为两类，一类是ToC产品，面向消费者的产品，一类是ToB产品，面向企业或者特定用户群体的面商类产品。平常大家讨论比较多的是ToC类产品，因为大家都在使用，且设计师很多在从事ToC类产品的设计工作。
在知乎、微信、微博等平台，有不少设计师朋友来问我，做ToB类产品，信息架构复杂，功能繁多，流程很绕，怎么才能设计好呢？正好最近在做一个很复杂很绕的产品设计，这里正好一并总结回答。
为了方便描述，我这里极端一点，描述ToC类产品为信息架构相对简单的产品，例如微信，核心故事为聊天、朋友圈、支付等，因人而异，每个用户的核心场景不算多。而ToB类产品动辄就是上百个核心故事，各种功能模块繁杂且对用户的亲切性低，使用起来学习成本高，例如银行交易系统、电信客服系统等。
简单类比一下，信息架构复杂程度的感觉由弱到强是这样的。
设计或者操控以下交通工具：
宇宙飞船……
现在基本了解了信息架构复杂产品的样子，咱们一起来看一下一些设计这类产品需要注意的点。
1，逻辑清晰。
设计复杂信息架构产品，第一要素，就是设计师逻辑要非常清晰。这类产品伴随的海量功能、大量模块、错综复杂的交互流程、难以理解的业务技术背景，都是对设计师达到逻辑清晰的挑战。
如果极端简化一个ToC类产品的任务流程，可能是这样的：
一个机智的用户来使用是这样：
一个不太机智的用户来使用是这样：
然后看一个ToB类产品，信息架构复杂的时候，如果设计师没有达到逻辑清晰，那设计出来的任务流程可能是这样的：
萌萌的用户会：-_-''''
默默的用户会：呵呵……
凶狠的用户会：设计师你过来我保证不砍你……
所以做ToB类产品设计，一定不能像写散文一样，随心而至，随时下笔，得像写议论文那样，做足功课，想清楚重点和逻辑，脑中成图，再动手画稿。
2，角色与场景。
虽然ToC和ToB设计的特性差异明显，但是基本的设计方法还是通用的。角色与场景设计依然是复杂信息架构产品设计的法宝。有着1000个功能的产品，先分角色，降低每个角色模块需要思考的信息量和业务逻辑量，然后再根据真实用户的使用情况，来划分场景进行场景设计。把一大块任务有逻辑地细分到小任务，才有逐步实现的可能。
切记，最好不要仅仅依靠业务功能来划分模块，不然体验设计会乱得一塌糊涂。
角色设计需要对用户群体有清晰的了解和划分，能做到业务使用的共感。
场景设计需要设计师有足够的全局观，不然分开了场景，完成了设计，合不起来，就麻烦了。
一个复杂信息架构产品，分角色，划场景，可以让设计师对产品目的了解更深刻，全局把握更强，另外在页面层级上，会把之前需要10层的功能任务流打薄到2-3层，大大提升用户的使用效率和舒适度。
3，学习成本
做产品设计的一个基本要求，就是要保证用户学习成本足够低，低到没有最好。做ToC产品这个目标很明确，也很容易靠拢，而做ToB产品很难。
我见过一个中国电信客服的界面，一个PC界面密密麻麻上百个功能，业务员完全凭借自己的记忆力和习惯来进行操作，没有太多的任务流清晰度可言。这样的产品使用，是需要一定时间的学习才能达到基本使用，学习成本肯定不低。
还有不少ToB产品，需要有专门的培训和讲解，才能勉强让新用户开始使用。
这个时候，如果单纯以学习成本低到没有来要求ToB类产品，非常难。信息架构复杂起来，是很难通过认知设计、视觉设计、交互流程简化来解决学习成本高的问题。
有几个点可以帮助到，一是灵活有效的提示（生僻专业术语提示、关键操作提示、报警监控提示等），二是充足有价值的用户测试，保证不出现设计师以为很好用，用户学到哭的情况，三是深刻理解业务，设计师的业务理解水平接近架构师和产品经理的水平，才能从体验侧做一定范围的有效改动，来帮助产品的可用性得到提升。
设计复杂信息架构产品时，想做到学习成本低到没有，这时的设计方法应该是，虽不能至，心向往之。
4，业务理解度
做复杂信息架构产品，最难的就是业务理解入门。例如做微信、QQ音乐等产品，设计师相对好入手，因为设计师本身也是用户群体。而复杂信息架构产品一般不是给普通用户使用的，是给一个特定群体的用户使用的，大部分情况，设计师与这个特定群体是没有交集的。
例如设计师接到一个任务，做银行交易系统，首先，设计师没有在银行工作过，对银行交易流程基本不了解，第二，设计师完全不知道使用这个交易系统的用户的心理模型、工作状态、用户场景、喜怒哀乐。如果这个银行交易系统是给尼日利亚的某个银行做的，可能设计师连当面和用户交流的机会都没有。
所以做这类产品时，动工前，设计师大部分时候业务理解度无限趋近于0……
最好的方式，我是建议设计师能自己跑去真实使用场景做做自己的用户访谈，例如到用户群体做一天的跟踪访谈、用户深访、任务流程记录、用户痛点记录等，这些真实的感受和体验带来的价值远远大于架构师或者产品经理给设计师描述带来的价值。
自我经验的比较也是一个好方法。没有设计师能站出来说，我做过任何类型的产品设计，但是优秀的设计师可以找到一些让以前自己成功的设计经验适用到现有产品的方法。
做一个云平台的服务购买场景，虽然设计师可能没有接触过云平台，但是能否类比到去京东淘宝买零食的流程，来看看有没有共性可以利用。其实是有的，因为人性是相通的。
做复杂信息架构产品，最难的一点是拉通。
做一个ToC类产品，可能一个设计讨论会，来4-5位产品与开发的同事就能启动讨论，且很快会有结论和执行项。做一个复杂信息架构的ToB类产品，一个模块拉通会轻轻松松就是来30多人，一个讨论就能引发2个小时的混战。
这个时候对设计师的全局观和项目把控能力的要求是非常高的。不然就会出现一个情况，拉30多人讨论10个设计点，讨论到第2个设计点的时候，大家争起来了，很快就争论到商业、业务、技术、平台等非设计的论题，吵了3个小时然后大家都崩溃了就散会了。这个时候设计师才想起来，还有9个设计点没有讨论……
拉通需要设计师有掌握全场讨论的能力，控制时间，控制争论方向，避免没有结果的讨论，主动提出并控制设计的执行项。
6，做减法。
有很多ToC类的设计黄金准则，在ToB类设计不一定适用。例如做减法。一个页面，产品经理提出了20个功能，设计师说，简洁！减法！砍成3个！产品经理说，不行，10个！设计师说，好了，5个，赶紧的我还要出图呢。这个减法讨论就结束了。（当然，简单信息架构产品做减法也是需要技巧和思考的）
而ToB类产品，一个模块100个功能可能来自20个不同的业务需求群体，这个时候砍任何功能，都会造成整个大功能模块闭环的缺失。所以单纯的砍功能做减法不一定在ToB类产品设计上适用。
7，设计师的成就感。
很多设计师在网上给我抱怨，说做的产品是ToB的，密密麻麻的功能、表格、筛选、流程图，一点美感都没有，不像做一个音乐、聊天、工具的ToC产品那么有成就感。
的确，做一款好的ToC产品，首先，样子足够好看（能放弃一些次级功能追求简洁和美观），第二，大众使用，App Store有人夸，家人朋友可以点赞。
做ToB产品，先不说好不好看，一般来说ToB产品的交互价值远远大于视觉暂时，而且主要是没人夸。设计师花半年给南美一个运营商做一个大数据分析系统，做的再好，南美那边也不会有用户跑来赞你啊，要是真有一天有个用户高兴的不行，给你打一个电话，你也听不懂啊……&哈哈哈
我觉得换一个角度来想。
找到乐趣。
做什么设计都是有乐趣的。做ToC产品，把一个首页做的漂亮精致，肯定是有成就感的。做ToB产品，把一个需要10步的流程通过打散、整合、聚集等方式减少到3步，也是一种乐趣。
设计复杂信息架构的时候，设计师千万不要放弃自己对专业的美好理想，让自己完全受制于业务和技术来出稿，而是时刻记得自己的专业能否帮助整个系统得到提升，这样的乐趣和成就感也是很大的。