Getting Real把握现实学习笔记.docx
- 文档编号:7567901
- 上传时间:2023-01-25
- 格式:DOCX
- 页数:19
- 大小:39.77KB
Getting Real把握现实学习笔记.docx
《Getting Real把握现实学习笔记.docx》由会员分享,可在线阅读,更多相关《Getting Real把握现实学习笔记.docx(19页珍藏版)》请在冰豆网上搜索。
GettingReal把握现实学习笔记
GettingReal(把握现实)学习笔记
一、前言
Web应用服务先行者37Signals,是一家位于芝加哥的小公司,他们提供订阅收费的软件服务(面向中小企业和团队的在线协同服务软件,Basecamp和Backpack),而不是传统的打包出售软件,现在已经有超过50万的用户在使用他们的软件服务,同时还提出了一套颠覆传统的研发方式和经营理念——贵在神速,小即是美。
37Signals在引领新网络应用的潮流,拥抱开源(让Ruby这个被冷落的语言成为了大家关注的焦点)、宣扬概念(Ajax、ROR模式)、成功的实现了服务订阅收费的盈利模式,最后还有教育大众。
他们周游各国,举办各种网络技术的研讨会,并推荐他们的成功宝典《GettingReal》。
商业周刊中文版将书名翻译成《把握现实》,是否合理,大家读过之后就能体会。
我觉得每个准备或者已经投身到Web2.0服务开发中的团队都应该倾听一下成功者的经验之谈,无论你是否认可,GettingReal告诉我们了走向Web开发成功的过程,而不是最终结果。
至少我觉得它能够让我们更加专心的完成一个目标,不会把时间浪费在繁杂的规划、设计、沟通和实现之中。
GettingReal-Thesmarter,faster,easierwaytobuildasuccessfulwebapplication
如果你是一位企业家、设计师、程序员或市场人员,如果你有一个伟大的想法,当你发现那些旧的软件开发流程、模式和经验已经无法适用时,你应该看看这本书。
GettingReal将告诉你:
为什么保持小巧是一件好事
尽量少做功能
如何快速的从想法变成现实
如何搭建你的团队
为什么需要从外在的设计开始
为什么书写至关重要
如何推广你的服务
还有更多…
现在37Siganls已将在网络上发布了GettingReal的免费版本,优秀的成功经验终于可以和大家分享了。
我将完整的学习笔记内容在这里整理出来,其实也不能算是”笔记”了,应该叫做原文内容的”概要翻译”,希望能够用简洁的表达形式将原书内容的精髓传达给大家。
l设定你的起跑线
先满足自己的需求、从自己的投资开始、限定时间和预算、设定一个假想敌
l保持精简
保持小规模和低成本、开发三人组、做回你自己
l学会把握优先级
抓住最主要的想法、在初期要忽略细节、找对你的用户群、以后再考虑扩展性、让你的软件保持风格
l功能选择
先实现最关键的功能、从说不开始、做你可以控制的事情、给用户最大的自主权、问问用户不需要什么
l执行过程
让你的软件尽快地运行起来、用跌代的方式开发、从想法到实现、真实测试、缩短计划周期
l团队组织
尽可能的整合人员、提供独立的时间、避免会议、庆祝小小的胜利
l关于雇员
尽可能的少雇人、炒掉不合格的人、雇佣能力全面的人、不要只说不做、你需要”语言大师”
l界面设计
界面优先、核心式设计、注意初始化界面、防止错误的设计、文字也是界面、统一界面
l关于编码
小巧的软件、为快乐而编码、倾听你的代码、使用开放的格式
l关于文档
不需要冗长的功能说明、给我讲述一个故事、使用真实的内容、拟人化的产品
l服务定价
提供免费使用、避免长期的租约、制定有弹性的价格策略
l产品推广
好莱坞式的产品发布、建一个强大的推广网站、利用BLOG来宣传、以教育的方式推广、跟踪用户的访问记录、取一个有吸引力的名字
l用户支持
感受用户的痛苦、零培训、快速解答、坚持自己的原则、将失误公诸于众
l产品推出之后的工作
每月更新、持续更新、不要拿”beta”当借口、不要对”bug”一视同仁、关注你的竞争对手
二、设定你的起跑线
少量构建:
在传统的模式之中,尤其是软件开发,要击败竞争对手就是要做比对手更多的功能,好像冷战时期的军事对抗赛一样。
你会为这样的行为付出高昂的成本,而且总是处于跟随竞争对手的状态。
因此开始你伟大的计划之初,要坚持少量构建原则!
用少而精来击败竞争者,我们需要的是:
少量的功能特性
少量的用户选项
少量的人员与精简的企业结构
少量的会议
少量的承诺
满足自己的需求:
创作一个软件的最好形式就是解决自己的需要,自己才是最好的观众,知道什么重要、什么不重要。
能够满足自己的需求,才会有热情投入,同时也以为之你会真正的去使用它和关心它。
这种热情同样也会感染其他有相同需求的用户。
从自己投资开始:
不要一开始就想着拿别人的投资。
与人钱财,替人消灾,这是常理。
大多数投资者都向快速的获取回报,不可预期的决策与外部环境将会影响你的计划。
随着硬件与带宽成本的降低,启动一个小型的Web应用服务的投入其实是很少的,初期的费用自己能够承担就自己来了。
还有一个好处,那就是“约束激发创新”。
限定时间与预算:
一定要在预算之内准时地上线,不要花费过多的时间和金钱在一个问题上面,你可以合理的调整你的规划来保证时间和预算。
区分好功能的重要性,什么是一开始应该有的,什么是需要增强的;如果你希望完全按时,按预算,按规划的来实施,你不可能创造一个完美的产品;能够应时而变是关键,你的规划需要有弹性,不要把它制定的太完美和长远,它需要经验来逐步完善。
设定一个假想敌:
某些时候,明确产品能做什么的最好方法就是明确他不能做什么。
设定一个假想敌,不是去模仿它增加更多的功能,而是寻找两者之间的不同点。
37Signals的Basecamp就以微软的Project软件为直接的竞争对手,而且这个对手还异常强大!
简化复杂的功能,突出项目成员的协作性,满足那些希望快速简便的用户的需求。
大多数情况下,用户都会对产品进行比较,你需要给你的用户讲述一个他们希望听到的故事(如何去实现目标),而不是阐述你的产品有多么的优秀和快速。
三、保持精简
保持小规模:
物体越大,它需要的能量越多,这个自然界的定律同时也适用于商界。
在Web开发领域也一样,你需要能够容易并且低成本的转变,因此你必须要会控制自己的规模。
规模通常在下列情况下膨胀:
时间过长的契约
雇佣过多的人员
长期不变的决定
为了开会而开会
过程繁重
投资(物理上或者精神上的)
硬件、软件或者是技术的瓶颈
私有的数据格式
用过去的观点来约束未来
时间过长的规划
官僚!
!
同样,也会因这些情况缩减:
合时的思考方式
能够胜任多任务的团队
在约束的环境下工作
少量编码
少量特性
精简的团队
简单
减少交互的接口
使用开源软件
使用开放格式
开放式的组织架构可以减少决策上的错误
保持低成本的转变:
记住,灵活的转变将是你最好的朋友,这一点尤其是用户互联网行业。
如果你的竞争对手能够比你更灵活的转变,你将处于劣势;如果他的转变成本更低,那么你将会输掉竞争。
你的小巧才是那些巨头们内心深处的恶魔,你可以在一天之内完成一个大型团队需要数周才能完成的转变。
廉价与快捷才是一个小型团队制胜的秘密武器。
开发三人组:
只用三个人的小组来开发产品的1.0版,这是你最精简的团队组成,他会满足你初期的人力需求,并且拥有足够灵活性。
一个开发人员、一个设计人员(注重交互设计)和一个多面手(组织管理、策划推广与公共关系),不过前提是你必须找对合适的人,优秀的人才是不会花费无尽的资源的。
如果你感觉人力不足,那么就应该尽早的调整任务的优先级,要记住的就是一定要保证第一个版本的小巧与紧凑。
“沟通的成本是团队成员的人数平方倍!
”——梅特卡夫定律(Metcalfe’sLaw)
拥抱约束:
有限的条件会激发你创造更好的解决方案。
我们总是感觉资源不足,时间不够、人力不足、资金短缺,这是好事,它会使你更加的专注。
37Signals在开始Basecamp开发的时候,只有一个设计、手头还有其他客户的工作、一个远在丹麦的开发人员(还有7小时的时差)、一个小团队并且没有外部投资。
面对条件苛刻的限制,他们将任务分解成小块,按不同的优先级来完成;同时减少人与人之间的会议,利用IM与EMail沟通,迫使自己快速的向目标前进。
做回你自己:
很多小公司都将自己扮演成大公司那样去运作,这是一个致命的错误。
个性化与友善是你与那些大公司最大的不同,小公司可以享受没有成规与官僚的约束,拥有更多的自由,而且更加容易亲近你的用户。
利用BLOG来取那些官方的发言与公告(当然很多大公司也开始这样做),让用户能够实时的融入进你的产品开发,并感觉你在及时地响应他们的反馈。
保持小巧的最好的一个原因就是减少内部的沟通流程,它将大幅降低你的成本。
四、学会把握优先级
抓住最主要的想法:
在你开始设计与编码之前,你需要知道你做产品的目的——产品定位。
它为什么存在,与竞争者有什么不同。
产品的定位会指导你的决策,让你坚定路线。
你的产品定位应该尽量清晰,最好能够用一句话来简单描述。
同在大家都把这样的描述追加在产品名的后面!
例如37Signals的产品:
Basecamp-ProjectManagementisCommunication
很清晰的定位,抓住项目沟通的重点。
去掉传统项目管理系统中那些繁琐的表格、状态、报表,而将产品的重点定位在消息、评论、任务跟踪与文件共享上面,让客户能够即时的了解到项目的状态并获取到相关的资源。
因此,为你产品的大方向做个定位,它会让你每个细节的决定都很明确。
在初期要忽略细节:
我们都为细节疯狂过。
虽然细节决定成败,但是细节也不是决定成败的唯一条件。
你会发现停滞、意见不一、会议和延时也会磨灭你的团队的积极性,并降低成功的机率。
你可能经常会为一个按钮的设计耗费一整天的时间,而且这些还经常出现在你产品开发的初期,其实有充足的时间让你的产品变得完美,就是不要在早期做这些事情。
尽早的让产品工作起来,再去完善那些细节。
Workfromlargetosmall.Always!
——PatrickLafleur,CreationObjectInc.(fromSignalvsNoise)
当问题发生时再去处理它:
把要浪费时间在还没有发生的问题上。
你是否真的需要担心10万用户的压力当你还需要2年的时间才能达到这个数字,或者一下子就雇佣八个工程师当你只需要三个的时候。
Basecamp刚推出的时候还没有用户支付功能,他们在系统运行后花了一个月时间去实现。
当你的系统出现由于用户增长带来的访问压力时(基础规划还是要做好的),你只需要真诚的向你的用户解释清楚,并且尽快在1-2周内解决,用户还是可以理解的,当然处理的速度要足够的快。
找对你的用户群:
为你的产品找到核心市场,并想办法去解决他们的需求。
客户的意见并不一定都是正确的,你需要分辨对与错,不要盲目的客户建议。
还好互联网将这个过程变得前所未有的简单。
如果你试图让所有人都满意,那么所有人都不会满意,这是真理!
Basecamp最初将他们的核心用户锁定在设计公司,满足他们与客户之间项目沟通的需求,这样其他类似的用户群体也会来尝试他们的产品。
所以Basecamp最终以狭窄的市场定位获得了成功。
以后再考虑扩展性:
在开始你优先要考虑的是建造一个牢靠的可以运行的产品,而不是去考虑它的可扩展性和使用服务器集群。
一个伟大的程序只需当它在非常流行的情况下再去考虑其扩展性,否则你将浪费能量、时间和金钱在那些永远都不会发生的事情上面。
因此你最关键的问题不是去考虑如何扩展,而是在何时去扩展。
让你的软件保持风格:
很多人常说一个好的软件是如何如何的灵活,有多少多少特性,其实那是胡说!
好的软件有它的定位和特点。
人们用软件不是来欣赏功能的,而是要实现自己的目地。
一个很好的例子就是wiki的设计,它去掉那些无用的文档修饰和可视化的编辑,将协同写作的特性发挥到极致,这种特性让wikipedia获得了巨大的成功。
因此,不要期望让所有的人都来用你的软件,除非他们的目的和你的产品定位相同。
五、功能选择
宁要半成品:
不要将那些单独看起来很棒的功能随便添加到产品中去,除非你想开发一个质量打折的产品。
你需要知道那些是真正核心的,将它们列成一个特性清单(FeatureTable),想象你的产品将会是什么样的,然后将这些功能分半实现。
也就是先实现一个拥有主要功能的半成品,除去那些无关的特性。
先实现最关键的功能:
忽略那些无关紧要的功能,这是实现一个伟大产品的先决条件。
就像那些优秀的设计师和开发人员,他们并不一定拥有最好的技术、有灵巧的双手、或者能够熟练的使用Photoshop,而是他们知道如何去分辨那些是至关紧要的,那些是可以忽略的。
不要将大量的时间花费在不重要的功能之上,如果你能够把握好这一点,那么你就一定可以创造出优秀的产品来。
从说不开始:
当你承诺要实现一个功能,你需要从设计开始,然后是实现、测试,经过一个完整的产品周期,你最终把这个功能推出给用户,观察用户对它的反映,并倾听用户的建议。
每一个功能你都必须付出精力和时间,但并不是每一个功能都能够得到用户的认可。
所以说那些来自用户或者是自己的新功能建议,应该把它记下来而不是立刻去实现它,然后给出我们现在不会实现这个功能的答复。
你应该尽量的让你的用户相信现在的功能足够满足他们的需求,你要让用户喜欢你的产品是因为它不会让100个毫不相关的功能来迷惑他们,要让用户忠诚于你现有的功能,然后期待新的功能!
发现隐藏的成本:
在你开始计划一个新的功能时,你需要分析清楚那些潜在的隐藏成本。
当37Signals决定在Basecamp中加入一个会议功能时,它需要牵扯到地点、时间、与会人员、日历集成和相关的文档,许多原先并没有的新特性会因为增加一个功能而产生。
还有那些不容易被人注意到的界面预览、推广形式、相关的法律条文、客户支持等等。
有时候一个新的功能会像滚雪球那样将你的成本越滚越大,所以每一个功能都需要慎重。
做你可以控制的事情:
你有能力免费的为每个用户提供1G的存储空间吗?
仅仅是因为Google为他所有的用户提供了1G的邮件空间。
或许你应该从100兆的开始,也可以对你的空间进行收费,这一切都应该量力而行。
记住,你的底线是你提供的产品和服务必须是你可以控制的,这样容易兑现给用户的承诺。
你所做的任何事都应该是你可以支撑的,包括组织、战略和资金上的。
给用户最大的自主权:
不要强制约束用户的行为,让你的产品实现最基本的概念,然后鼓励用户按照自己的想法去使用并解决问题。
如果你总是认为你能够为用户考虑的很全面,任何一步操作你都想得很周到,这样不仅限制了产品的灵活性,也束缚了用户的思维,同时还会带来更多产品BUG与使用障碍。
所以将你的基本功能做好,让用户在你所规划的框架之下能够自由的完成自己的任务。
忘掉用户的功能需求:
用户会希望你的产品拥有他们想要的任何功能,你基本上会被这种功能请求给淹没!
在前面已经提及过,这时你最好的回应就是说“不”。
对于那些功能请求,你只需看看就可以扔掉了,当然你不能直接向用户表现出置之不理的态度!
其实用户会提醒你什么是最重要的,如果一个需求真的值得被记住,用户会反复的提及它直到你无法忘记为止。
虽然有些粗暴,不过这也是一个行之有效的办法,当大多数用户反复的提及同一个功能需求的时候,你确实应该将它列入功能计划表了。
问问用户不需要什么:
大多数的软件调查和问卷都围绕着需要什么功能为中心,其实可以反过来思考一下。
问问用户什么功能是可以去掉的,如果去掉之后会怎么样,那些功能是他们从来没有用到过的。
让用户来裁剪功能,可以有效地限制无用功能的膨胀。
最后引用一句名言:
InnovationComesFromSayingNo!
——SteveJobs,CEO,Apple(fromTheSeedofApple’sInnovation)
六、执行过程
尽快让你的软件运行起来:
一个可以运行的软件是激励你团队最好的兴奋剂,还能让你暂时不去考虑那些无法使用的功能。
这就意味着你要从最简单的功能开始,绕开细节的纠缠,用快速的方式去取得阶段性的成功,如果你做到这一点了,你就能够更加精确的控制过程,这远比那些完美的规划、框架以及HTML页面的演示来的实在得多。
一个看的到的可以运行的程序,可以让你和客户能够更清晰的理解自己需要什么、在做什么,还能够避免讨论方案所浪费的时间。
使用迭代的方式开发:
不要期待你开始的设计都是正确可行的。
随着你的系统的逐渐完善,它会告诉你如何改进才是正确的,你必须要接受开发期的变化,其实它带来的是系统的进化。
因为Web程序不像那些传统的软件,需要封版发布,你可以在任何时候对你的程序进行调整,一遍一遍的直到满意为止。
系统运行起来之后,用户的反馈将对你的设计和开发更有帮助。
从想法到实现:
这里介绍的是37Signals的方法,从头脑风暴到草图到HTML页面,最后再是代码实现,他们用这个简单的流程来实现每个功能和产品。
头脑风暴:
先收集众人的想法,大家一起找出自己的需求,产品可以做什么,这里不需要制定太多的细节,只需要给产品一个轮廓,后面你可以慢慢再去完善它。
画出草图:
这是你表达想法的最廉价的方法,用简单的线条把你想象中的轮廓画在纸上,系统的结构、功能的流程和界面,这些都是尝试性的表达,所以不需要浪费过多的时间去争论对错。
实现HTML预览:
用网页来实现你勾勒的界面,让所有人都能看到它的样子。
这是你还不需要写任何程序代码,仅仅HTML+CSS就足够了,这样可以让你的设计与编码并行。
编码实现:
当你觉得前面的过程已经足够表达你的想法了,就可以开始编码了。
上面的过程可以针对具体的功能和目标重复进行,以迭代的方式直到完成所有功能的开发。
避免过多选项:
大家都希望通过选项来满足用户可以订制系统的需求,这样看起来系统很灵活,给了用户更多的自主性,但同时也给用户带来了更多的困惑,他们会为满屏幕的选项而头痛。
用默认的习惯和最佳设置来取代那些不必要的选项,这样或许对用户更友善一些。
还有就是过多的选项会给你的程序带来过多的代码和界面,也意味着有可能产生过多的BUGS。
以”搞掂”为目标:
当你实现一个目标就意味着你可以继续向前进,不要为了某些错误的决定而停止前进。
碰到问题你应该及时回头,而不是想办法去完成一个无法完成的任务。
每一次目标的实现就像是一次小战役的胜利,值得庆祝和纪念。
让你的团队保持这种持续前进的士气,去完成那些正确的目标。
要记住一点,好的执行力要远远比好的想法和目标重要。
真实测试:
在真实的环境里面测试你的程序,获得真实的数据和反馈,再用这些来改进你的程序,因为实验室里的检测永远无法反映出实际的情况。
所以要提前让用户体验你的Beta版本,你可以在用户使用的同时持续的完善功能,及时获得用户的反馈才是最重要的事。
缩短计划周期:
制定一个需要数周或者数月才能完成的计划几乎是个不切实际的幻想,因为你根本就不可能预知这段时间内会发生什么事情。
所以缩短计划周期,将时间分片,你可以把一个需要12周的计划分解成12个只需一周完成的小计划;把需要30-40个小时完成的任务细化到6-7个小时能够完成的每日任务。
同样的理论也适用于问题的解决,你可以把一个大的问题分解成若干个小的部分,然后逐一解决。
SmallerTasksandSmallerTimelines——GinaTrapani,WebdeveloperandeditorofLifehacker,theproductivityandsoftwareguide
七、团队组织
尽可能的整合:
很多公司将设计、开发、文档撰写、支持和市场划分为不同的运作部门,这样做得优势是更加的专业化,但是这种隔离似的划分会让每个部门陷入到自己的信息孤岛之中。
因此对于一个小的团队,要尽可能的整合人员,取得沟通中的平衡,不要让你的团队迷失在繁杂的沟通与交流里面。
你可以尝试让你的设计人员做一些文档撰写工作,也可以让开发人员做一些客户支持,当然最好的情况就是雇佣能够胜任多种工作的能人了。
提供独立的时间:
不要让你的团队成员在工作的时候被打断思路,因为要重新集中精力需要花费很多的时间。
这也就是为什么很多人希望在深夜或者是清晨工作,这些时段通常都不会被人打扰。
在独立的时段里面,思路会更加灵活、效率也会比平时高很多。
你可以尝试把早上10点到下午2点作为独立时段(午饭时间除外),这段时间里面团队成员不需要沟通,没有会议、电话、即时通讯、邮件的干扰,只有静心工作,通常这样的工作方式会比整天的忙碌要更有效率。
会议就象毒药:
尽可能的避免会议,如果你突然有个想法需要和大家交流一下,可以先尝试即时通讯或者邮件沟通,因为非面对面的交流思路会更加严密一些。
会议会打乱你一天的正常工作流程,一群人在一起通常会为一些无关竟要的想法讨论半天(跑题),而且总会有些人会为一些愚蠢的问题浪费大家的时间。
如果实在是要开会,那么坚持下面的原则:
将时间控制在30分钟之内
只让相关的人员参加(与会人员要尽量少,不然就成了演讲报告)
一定要有清晰的议题
寻找并庆祝小小的胜利:
在开发过程中作重要的东西就是成员的热情与动力,阶段性的胜利是激发团队斗志的最好方法。
如果你把胜利的周期拉的太长,成员的斗志会被消磨,也就不可能开发出优秀的产品。
如果你处在长达一个月的产品周期里面,争取每周来个阶段性的成功。
当然最好的情况就是每天都能够有个小小的胜利,你可以通过下面的方式来界定阶段性的成功:
实现一个小功能
增强一个现有的功能
重写一些帮助文字来降低客户支持的成本
移除一个你不需要的功能特性
持续性的成功会让你的团队保持最高的开发热情!
八、关于雇员
尽可能少的雇人:
其实不需要过早的让你的团队规模膨胀,也许今后也不需要。
如果真的需要100个人的话,你也不用一次性的把他们都招回来,从来都没有一个有效的办法让很多人快速的融入到一个工作环境之中的。
过多的人员会让你为培训而头痛、时常发生的个人摩擦、无法避免的沟通障碍,大家各自有各自的主张,总之是十分麻烦!
所以,尽可能的避免雇人,同时想想其它的办法来解决人手不足的问题。
看看负担是否过重,那件事情是否需要去实现,或者用其它的办法来解决,总之最后再考虑增加人手。
GE的前任CEOJackWelch在雇用一个人之前都会考虑一下如果没有这个人情况将会怎样,因为通常都不会向你所想象的那样需要那么多的人。
炒掉不合格的人:
除了看简历、了解雇用人员的工作经历之外,试用也是一个非常重要的过程。
在你正式录用一个人之前,你应该给一个小项目让他去尝试一下。
你可以了解到他是如何处理这个项目、如何沟通、如何工作的,如果你有机会在屏幕前看看他的编码和设计,你将会了解到更多的细节,这些对于考察一个人是否合格非常有用。
不要只说不做:
用来考查一名技术人员,OpenSource是一件非常棒的礼物,如果他参与过开源项目(国内好像太少了),你很容易就可以从中可以看出他的能力和对技术的热情,那些只说不做的应聘者很快就会在你的眼前露出马脚。
你可以通过下面的条件来判断一个开发人员的能力:
工作质量、对于文化的看法、热情程度、完成度和社交能力。
37Signals只雇用参与过开源项目的开发人员,要知道真正热爱开发的人才是你的团队所需要的。
雇用能力全面的人:
对于一个小的团队,更多需要的是能力全面的多面手,而不是某一个领域的专家。
你需要一个善于书写的设计师,一个有设计能力的开发人员。
每个人都有系统架构的能力,善于组织自己的思维,并且能够和客户沟通。
因为小的团队经常需要快速的改变决策方向,所以你的团队成员也必须有很强的学习能力,能够快速的适应决策的变化。
热情是不可能伪造的:
你所需要的并不是一名技术专家或业界名人,通常第一个跳槽的就是这类人。
对于你来说,一个快乐的、能力稍逊的人要比一个经常抱怨的专家适合的多,因为热情是不可能伪造的。
你应该雇用那些
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Getting Real把握现实学习笔记 Real 把握 现实 学习 笔记