ifttt提供的服务，程序员最容易理解 - if xxx then xxx，对于一个程序员来说 if then 包含了所有的可能。

ifttt的几个特性：

1. 事件驱动

互联网形形色色的应用提供了用户监控各种事件的可能，不仅仅是博客收到某些人的留言这样的事件，甚至上海/北京/西藏同时下雨这样的事件。而事件本身其实又是另一事件的结果。

2. 指令互联网

当各种各样的智能设备接入互联网后，ifttt提供的服务可以让普通人更简单的”编程“。其实编程还不就是一堆ifthen吗？随着这种智能化需求的增加，也许有人还能靠编写各种指令来赚钱。规则和模式其实也是一大堆的ifthen

3. 集成/自动化

集成各种资源到这条”总线“变为可能，集成商需要做的是拿来各种应用接口，然后适配到这条”总线“上，供各种各样的用户使用（自助集成）。很多工作都可以实现信息的自动化流转。

以上纯属yy，希望国内的模仿哥不要仅仅把这个概念作为同步微博的东东。

赞一个, 道理很简单, 将互相换书读搬到网上,解决了豆瓣无法解决的换书问题. 为什么豆瓣就没有想到呢?

在没有这个网站之前, 我想要和别人换书读会想到种种问题:

1. 我怎么知道别人有什么书是我感兴趣的

2. 也许别人愿意用来交换的书都是不好的书

3. 怎么保证不见面交换的可靠性

这些都被摆摆书架解决了,怎么解决的可以自己发现.

不过 目前的可靠性是通过内部的邀请来做到的, 还没有公开化.

甚至还做了一个chrome插件提供消息提醒和豆瓣网的widget - 可以在浏览豆瓣网时看到书架上有没有这本书.

不得不赞!

今天和小小兔工作室(xiaoxiaotu.com)的杨同学聊了聊.关于互联网,android,产品创新,职业发展,创业...

简单自我介绍之后,就是关于互联网创业的一些想法和观点.很赞同他的一些观点:

1.做事情要布局,先是做一个个点,然后要把这些点连起来形成面,形成网络. - 不懂得布局的结局就是各种无法关联起来的独立"点",最终把事情变成重复劳动,无法形成系统.警惕!!

2.想法可以有,但还是要做出来. - 这点我很惭愧,相当惭愧!!

3.精确的时间管理 - 这个不是一时半会可以解决的,是性格使然.

4.要有自己的东西,避免完全依赖别人,但可以借鉴或部分取用. -关于集成api的地方.

5.做事情的成败最终归结到人(团队)的素质 - 一个人可以做到事情,总有人会超过你.好的团队是很难被超越的.

6.坚持/专注 - 很通用

呵呵,相见恨晚啊.很nice的. 虽然目前工作室并没有明显的成功案例,但我很看好.

BRD
　　Business Requirements Document，商业需求文档。这是产品声明周期中最早的问的文档，再早就应该是脑中的构思了，其内容涉及市场分析，销售策略，盈利预测等，通常是和老大们过的ppt，所以也就比较短小精炼，没有产品细节。

　　商业需求文档重点放在定义项目的商业需求。BRD要能说出客户碰到的一个或多个商业问题，并且通过公司的产品能够解决这些问题。接着建议一个方案 —— 通常是新产品或者现有产品的改进来解决这些问题。BRD也可能包括一个高级的商业案例，例如收益预测，市场竞争分析和销售/营销策略。BRD通常是由拥有 产品经理，产品营销经理或者行业分析师头衔的人撰写的。在小公司，可能由高级主管或者甚至创始人撰写。BRD通常是一份连续的1-3页Word文档，或者 不超过10页的Powerpoint文档。
MRD
　　Market Requirements Document，市场需求文档。获得老大的认同后，产品进入实施，需要先出MRD，具体来说要有更细致的市场与竞争对手分析，通过哪些功能来实现商业目 的，功能/非功能需求分哪几块，功能的优先级等等。实际工作中，这个阶段PD可能的产出物有Mind Manager的思维图，Excel的Feature List等。
　　市场需求文档（MRD）重点放在为一个被提议的新产品或者现有产品的改进定义市场需求。与BRD指出商业问题和解决这些问题的解决方案不同，MRD更深入提议解决方案的细节。它包括一些或者所有这些细节：
            a. 解决商业问题所需要的特色
            b. 市场竞争分析
            c. 功能和非功能需求
            d. 特色/需求的优先级
            e. 用例
　　MRD通常是由拥有产品经理，产品营销经理或者行业分析师头衔的人撰写的。MRD通常是一份连续的5-25页Word文档，或者正如之后描述那样在一些机构中甚至更长。
PRD
　　Product Requirements Document，产品需求文档。进步一细化，这部分是PD写得最多的内容，也就是传统意义上的需求分析，我们这里主要指UC（use case）文档。主要内容有，功能使用的具体描述（每个UC一般有用例简述、行为者、前置条件、后置条件、UI描述、流程/子流程/分支流程，等几大 块），Visio做的功能点业务流程，界面的说明，demo等。Demo方面，可能用dreamweaver、ps甚至画图板简单画一下，有时候也会有 UI/UE支持，出高保真的demo，开发将来可以直接用的那种。
　　产品需求文档（PRD）重点放在为一个被提议的新产品或者现有产品的改进定义市场需求。与MRD侧重于从市场需要角度看需求的不同，PRD侧重于从产 品本身角度看待需求。通常在特点和功能需求上更深入细节，并也可能包括屏幕截图和用户界面流程。在那些MRD不包括具体需求和用例的机构中，PRD就包含 这些具体内容。PRD通常是由拥有产品经理，行业分析师或者产品分析师头衔的人撰写的。PRD通常是一份连续的20-50页Word文档，或者针对复杂产 品甚至更长。
　　提醒：一些机构将这里描述的MRD和PRD合并成一个文档，并称最后的文档为MRD。在这种情况下，MRD包括本段描述的内容，也包括上一段描述PRD的内容，并且可能超过50页。
FSD
　　Functional Specifications Document，功能详细说明。有一点像“概要设计”，这步就开始往开发衔接了，产品UI、业务逻辑的细节都要确定，细化文档并保持更新。相应的，有很多内容，比如表结构设计，要由项目经理来编写了。
　　功能规格文档（FSD）把焦点集中在实现，定义产品功能需求的全部细节。FSD可能通过一张张的截屏和一条条功能点来定义产品规格。这是一份可以直接 让工程师创建产品的文档。与MRD和PRD侧重于以市场需要和产品角度看需求不同，FSD把重点放在了以表格形式定义产品细节，再让工程师实现这些细节。 FSD也可能包括完整的屏幕截图和UI设计细节。FSD通常是由拥有产品分析师，工程领导或者项目经理头衔的人撰写的 – 作者通常属于工程部门。通常一个连续几十页的Word或类似文档。

互联网公司的PM(产品经理)该如何写文档

问题2：怎样和为什么要在编制项目计划时考虑依赖关系？
答案2：根据使用的软件包，依赖关系可以通过将任务及其后续任务的标识符进行关联来表示。依赖关系说明了任务之间关联/并列的要求。依赖关系可以是指在另 一个任务能开始之前有一个任务必须完成。例如，逻辑模型必须在物理模型前完成。但测试并不是要在所有编程工作完成之后才开始，如果没有完成的程序对线性测 试没有影响。项目计划加入依赖关系，就能找出项目的关键路径并且能够确定它对项目工期的影响。

问题3：你怎样将人的工作步调与计划结合？
答案3：根据组织使用的具体的工具，可以将资源拆成更小的资源/单位，或者可以将任务拆成更小的任务。

问题4：你怎样将培训，假日和个人教育时间表结合起来？
答案4：每个产品都有标明不工作的天数的公司/全球的日历。每个产品都也有个人的资源日历标明个人不工作的时间。如果项目需要教育和培训，应该把它们象任务那样写在项目计划上。

问题5：你怎样安排类似状态会议这样贯穿整个项目但只需要极少的时间和工作量的任务？
答案5：它的工期将和整个项目时间一样长，占工作量的百分比很小。被分配给任务的每个人花在该任务的时间占他时间的百分比极低。

问题6：实况报告对计划的作用以及实况与最初预计的比较有何价值？
答案6：根据组织使用的特定的工具，每个工具都为实况报告中输入相互独立的要素/域信息。也可以将报表进行分类，来向团队成员和其他相关团体说明关键路径 的变化或时间表的调整。这些报告对已实现工作评价和作为在计划下一个工程或阶段的输入有价值。另一个把估计和实况报告比较的有价值的用途是把范围变更对项 目的影响记录下来。 　做项目计划的技能

问题7：你为什么制定项目计划？
答案7：项目计划是实现成功的系统的路线图。它提供了一种手段来通知每个人希望他们做什么及何时完成。它帮助项目经理使管理层，商务用户和支持团体了解项 目状态和调整特殊的资源。逐项列记的“一览表”协助对任何变动的影响进行迅速评估。当实况报告与计划联系起来后，项目计划为今后项目的任务划分和估算提供 了有用的信息。

问题8：你将怎样着手做项目的计划？
答案8：进程安排是一门艺术。根据已知有关业务目标的事实，公司一般标准，以及可以利用的过去的经验。可以从清楚地定义范围和目标开始。把项目的风险和制 约做成文件。差的估计源于对业务知识和项目范围缺乏了解。可以从项目任务分解入手，例如先划分阶段，然后定义每个阶段的活动，再定义每个活动中的任务。识 别和文档化里程碑和可交付产品。项目计划是当信息变得可以利用的时，不断细化的有生命文件。很好地记录进度的变化对项目经理，开发团队，支持团队，以及管 理层，商业用户都有益处。

问题9：你将怎样着手制定项目计划？
答案9：在适当的活动和阶段或其他的概括的标准说明下，输入确定的任务。将适当的可交付产品及里程碑和特定的任务联系起来。连接全部需要依赖关联的任务。 把资源角色或资源名字加到每个任务上。应用度量结果确定事先的任务工作量，把更多的时间用于需求收集，设计和测试。考虑所有已知的节假日，培训，休假或其 他的资源停工时间。计划草案将同支持团体，管理层和商务用户一起复查，做为补充性的输入和最终的批准。

问题10：怎样确定人员需求？
答案10：不考虑资源限制进行计划开发。在任务旁边加上诸如数据模型制作者，业务分析员和用户等角色。再加上能将任务重叠起来的补充性的资源。在计划中要 考虑开发团队包括支持团队和用户代表失去一个或多个资源的情况，要在每个任务上增加15%的余量。要使项目小组的组成容易理解，要有角色所必备的技术水平 的说明。

问题11：给项目加上测量标准有什么价值？
答案11：如果使用得当，测量标准是一个有价值的工具。它们提供测定开发系统的复杂性和工作量的方法。度量结果为制定项目计划提供了信息输入资源，并且是确定发展方向的有价值的历史信息。软件测量标准将有助于开发更好的软件。不过，最好有3年的历史资料。

问题12：你怎样在计划中运用新技术？
答案12：在增加培训任务的同时要扩大工作量，缩小每个工作单元。在评价新技术在开发中的影响的过程中加上额外的原型和检查点（里程碑）。

人员管理技能
问题13：你作为项目经理要做的第一件事情是什么？
答案13：除了注意公司的发展方向并从中发现自己的发展道路外，在头脑中要建立项目经理所关注事物（商务，公司，项目，团队，个人，技术和方法论的变化） 的优先顺序。因此，和部门经理开会确定优先顺序，安排用户和职员会议，得到全部成员的状态报告和评价。重要的是能尽快处理业务，项目和个人有关的事情。

问题14：当你的职员减少了30 %你将怎样着手完成公司的项目？
答案14：首先，确定和区分项目的优先次序，哪些项目是必须在今后的18个月内完成的。把绝对的最小的总人数与每个项目联系起来。向管理者和用户说明对进 度表的影响。因为两者都也许不愿意接受进度表的变化，因此或许可以给你一些例外。 减掉顾问比去掉一个雇员要好。每个项目的顾问也许可以用雇员代替。坚持运用学习曲线理论并逐步减少顾问人数。可以把一些顾问的工作从一周降低到一星期中的 2或3天以应付人员削减。 如果公司有提前退休的一览子法案，赶紧寻找一些有资历的、适用的雇员。牢牢记住失去“老资格的人”你也许就失去了有价值的知识。尽可能将一个快退休的人和 新手组合在一起。 以满足业务目标为前提，确定剩下员工的重要性以及他们在每个项目中的重要性。使新手和经验丰富人员的比例适当。两者都是确保项目和公司不断成功的财富。

问题15：你的团队主要是由新手组成的，并且进度已经落后。你将做什么？
答案15：需要记住一个项目很少因为在截止时间内没有完成而被取消的。项目被取消，主要是诸如缺少资金，用户支持或不能满足的业务目标。 因此，要做的第一件事是培训，无论在室内还是室外，在课堂或通过录像带。另一种附加方法就是让资深的雇员或高级顾问充当教师。 举办针对个人评估和辅导的会议。帮助每个员工准确评价他们各自的优点和缺点。同时明确任务，将所有必须遵守的标准或准则阐述清楚。为每个员工提供从成功项 目中得到的模板作为指南，还要允许他们发挥自己的才能。如果需要，和他们一起工作。对任何问题或完成的任务做出迅速的反馈。 对于较大的任务，看看他们的计划，有助于确定他们是否了解任务的范围和目标，以便了解他们是否能完成任务。倾听员工的观点，也许他们会有完成任务的正确的 方法和途径。然而也要防止雇员陷入挫折和士气低落的困境中。

问题16：你将怎样和与你竞争相同职位的员工相处？
答案16：这是经常发生的不愉快情况。雇员总是认为他们能胜任某个职位而管理层还没有意识到这一点。因此，要进行如下调查： 发现员工的管理能力 阅读评估和状态报告 当雇员变得不合作时试图发现一些变通的方法并且针对这种状况进行一些个人谈话，谈话内容包括： 弄清楚状况；与员工一起分析他/她具有的能使他/她得到提升的资历；强调在初期协作的必要性和管理层是如何高度重视合作关系的。

问题17：在决策和工作风格方面你会给你手下多大的自由？
答案17：自由的大小取决于每个人的技能和专业水平。一个好的经理是“面向结果的”并且能创造一个能使团队广泛交流的环境。无论如何，每个员工每周需提交项目和商业目标有关的状态报告并且经理要进行审查。这有利于加强组织建设并使每个员工致力于他们自己应完成的工作。

问题18：如何对待即将退休的员工？
答案18：即将退休的员工能提供大量的信息。一个人在把所有业务知识和关系网拒之门外时必须三思而后行。因此，要利用这些人的能力：他们在某些特殊技能方 面可以作为新手的老师。明确主要的工作利益，要使项目能充分利用这些技能，可以利用他们从非正规途径得到的必要支持（不用通过正规的，官僚的途径完成工 作）

问题19：对一个一贯迟到的员工你会怎么办？
答案19：好的经理是通过结果与所花时间来评价一个员工的。然而，还需要了解迟到会在公司和团队中造成什么影响。一个人经常迟到人们会感到领导在徇私并且 会影响团队的士气。这个人也许可以按期完成自己的任务但可能会影响到别人的进度。职业特性包括可靠性。如果别人的工作进度取决于他们的工作进度，那么，他 们的进度对于整个团队就很重要。 首先判断这些员工的模式。换句话说，是偶尔还是一贯如此。其次，明确公司有关考勤方面的政策，确定迟到及其相关处理方法。要了解该员工的工作是否与进度相 符并了解与他一起工作的人对他迟到的反应。最后，必须与他们进行客观的谈话，谈话的主题包括： 公司的规章制度 对团队的影响 对个人评价的影响 强调时间进度 达成谅解

问题20：在费用削减的情况下，你将怎样鼓舞士气？
答案20：钱不是仅有的激励因素。人们需要了解他们是否对项目有积极的贡献。因此，要强调拥有的自豪感并且举行业务会议，在会上让用户谈谈他们对项目组的 良好印象。同时，让用户对他们的功能和业务提出一个概括。培训是一个激励因素。因此，状况会议可以作为一个非正式的培训课程。不定期地举办有关新技术的内 部研讨会。如果培训课程费用太昂贵，可以租赁技术录像带。订阅杂志，有许多技术杂志是免费的。必须记住的是，忽视培训将使团队的精神低落。这样会影响产品 的质量和数量。

问题21：你如何雇人？
答案21：首先做一个工作所需技能的描述。如果你不了解现在的需求就很难雇到合适的人。接下来要了解团队成员的个性。列出团队现在缺乏的技能或工作风格。 与人力资源部门讨论所有这些情况，包括调动现有员工。当候选人到来，针对现有工作进行面试，同时还要了解他是否具有新岗位所需的技能。

问题22：你将如何解决团队中的个人冲突？
答案22：辨别出人的不同个性。分别向员工表述每种风格的价值。当与冲突双方讨论试图分析申诉或冲突的原因时应持有客观的态度。

问题23：你将如何监控/管理顾问？
答案23：顾问也是人，也需要得到尊重。他们还需要明确的目标和任务。坚持做工作周报，将工作时间和工作完成情况联系起来。

问题24：你将如何管理外援？
答案24：和管理顾问的方法相同。不过，他们可能有一个经理来负责外包合作。首先要和这个经理一起组织日常会议。坚持做工作周报和可交付产品的拷贝。

问题25：你将如何同一个似乎总是不能按时完成工作的员工一起工作？
答案25：直到找到问题的原因时，问题才能解决。原因不一定是分析问题或解决问题的能力差。可能是一个管理方面的问题。该员工可能没有得到适当的培训，他 的工作可能超出了他的能力范围。另外一种可能是这个人有太多的事情要做而且这些事情都是最重要的或者他不清楚交付日期。如果不是上述原因，要注意观察，找 出原因所在。例如当所有人遇到问题时，都会找这个人。那么，这个人的工作经常会被无数次地打断。

沟通技巧
问题26：你将怎样使用户参与和了解项目的每个阶段？
答案26：贯穿整个项目的原型是得到用户肯定的方法。让用户对有形和无形的利益进行研究，以做出成本效益分析。和用户一起开发测试数据，测试大纲和验收标准。e-mail里程碑状态报告和更新/修改的项目计划。在项目进行阶段性检查时的同时对可交付产品进行检查。

问题27：你将如何发现和解决内部和外部问题？
答案27：从所有可能的资源获取实情并客观地记录下来。然后在相关方参与下，尽量自己解决问题。如果这种方法无效，按照组织的管理结构提出问题并参照可能的解决方法。

问题28：你将如何得到供应商的一贯支持？
答案28：虽然供应商是在管理范围之外的，但也可以将他们包含进来，如果他们：得到尊重；了解业务目标；预先购买；将供应作为计划的输入，这样会对他们产生影响；参与设计，因此，在项目的早期阶段就应该考虑供应商的管理。确保他们了解业务目标和工作的利益。

问题29：如何处理“是否能破除一些规矩”现象？
答案29：单纯为了技术而采用某种技术是不能说服用户或领导的。任何人都可能抵制那些会改变现状的变化。然而，如果将技术与商业利润联系起来，用户会支持你的建议。

问题30：你如何应对不同的商业用户，如果他： a) 拒绝确认需求 b) 经常改变主意 c) 不肯花时间 d) 坚持不现实的截止日期
答案30：无论客户有多难应付，都应该记住正因为他们我们才有工作做。他们是客户。必须以高度的职业精神，完全尊重他们。 因为他们不能了解我们的工作正如我们不能完全了解他们的那样，沟通变得比较复杂。因此，我们要花时间作规划并解释其中包含的内容。用户需要感到他们没有浪 费时间，正在取得成果，并且他们的意图被很好地理解。制作原型是一个有用的工具。它提供了一幅用户能理解的、灵活的图画。 另外，对工作风格的理解也很重要。拒绝承认或不断地改变想法可能源于对问题缺乏理解，或是对未来的担心。 用户往往不愿意花时间与IT人员交谈并认为这样做是浪费时间，因为IT人员过分关注他们自己的任务。应该对过去交付产品的历史进行检查。如果用户来了多次 但并未发看到有价值的输出，他们将拒绝花更多的时间。在这种情况下，你应该做你擅长的商业领域的项目以期得到用户的尊重。 召开一个历时一小时（并且要限定在该时间范围内）的需求讨论会来讨论特殊的问题。会议结束时应让用户知道下一步该怎么做（并要取得共识）。用户的观点被记 录在“会谈纪要”上。这些会让用户感到他们的意见已被听取并且允许他们更改错误。 一个项目被取消往往是由于没有经济合理地达到用户的业务要求。如果在项目的整个过程中，一直保持与用户的有效沟通，他们将看到他们的要求正在逐步达到。项 目很少因为延期而被取消。要注意范围变更。在原有的截止日期上增加额外的任务，将会产生不现实的截止日期。

问题31：在一个不编程，就认为你没在工作的环境中，你如何开展工作？
答案31：如果用户认为你了解了他们的业务目标，他们就希望早些开始编程。以一种他们能够理解的形式制作需求文档，提供一种开放的沟通方式，并让他们知道 你了解什么，你正在做什么。通过项目计划，状态报告和原型同样能够表明项目的进展。通过让用户审查需求，原型和状态报告的形式，让用户参与项目