ifttt是个什么东西?

说实话,自己到现在还没有捞到ifttt的邀请,也没兴趣使用国内的快速山寨产品。

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

ifttt的几个特性:

1. 事件驱动

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

2. 指令互联网

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

3. 集成/自动化

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

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

摆摆书架~赞

果然是卧虎藏龙的地方, 一个同事做了这个牛x的东西 – 摆摆书架 bookfor.us

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

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

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

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

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

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

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

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

不得不赞!

 

小小兔工作室

今天和小小兔工作室的杨同学聊了聊.
关于互联网,android,产品创新,职业发展,创业…
互相简单自我介绍之后,就是关于互联网创业的一些想法和观点.很赞同他的一些观点:
1.做事情要布局,先是做一个个点,然后要把这些点连起来形成面,形成网络
2.想法可以有,但还是要做出来. – 这点我很惭愧.
3.精确的时间管理
4.要有自己的东西,避免依赖别人,但可以借鉴.
5.做事情的成败最终归结到人(团队)的素质
6.坚持/专注

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

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

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

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

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

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

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

6.坚持/专注 – 很通用

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

互联网产品经理必备文档介绍(转)

转自 http://bbs.bianews.com/thread-69395-1-1.html

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(产品经理)该如何写文档

原文地址

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

作 为互联网公司的PM(产品经理),我们需要面对众多部门,因为自己就是项链里的那根线。需要书写各种文档,最常见的就是PRD(产品需求文档),当然根据 重量级和时间等多因素,可以提交不同类别的,例如DRD(设计需求文档)和ERD(工程需求文档)。嘿嘿,DRD和ERD是我自己发明的。更多小的ECR 级别项目中,文档大家写的都很自由。

  今天晚上在跟工程师讨论中,得到了一些启发,摘录部分。

  给工程师看的文档
  1 工程师喜欢看结构化文档,不喜欢看描述性文档。
  描述性文档也要给工程师看,并且最好亲口说,因为这对理解产品策略和发展方向有帮助,工程师可以帮助PM弥补没考虑到的地方

  2 工程师喜欢流程图甚于Mockup,而Mockup是给领导给Marketing等成员看最合适;
  并不绝对,初级工程师反倒喜欢mockup,而高级工程师经验多了两者没区别

  3 Mockup是画大饼,产生食欲,争取资源和获得理解的方式。“有照片的菜单永远比只列菜名的菜单受欢迎”,这是马总说过的;
  Mockup务必不要过于精细,否则累的是PM,领导和其他团队会一开始就进入细节盘问阶段,不利于表述产品目的和大的功能模块

  4 工程师更喜欢菜谱,而且是西式菜谱。做一道菜需要几分钟,几滴色拉油,烤炉温度和时间,需要哪些工序,前后顺序和量化归纳。
  这个并不绝对,聪明的工程师不喜欢菜谱,不喜欢纯粹编码。有些时候不妨像做中国菜一样,给对方发挥余地。只是碰上好搭档的概率不多,更多情况下菜谱更保险

   5 软件工程是西方的泊来物,标准化文档非常重要。很多老外PM希望达到一种境界,进行完详尽的分析和文档后,开发人员按部就班就行了。中国人做菜喜欢个性发 挥,油盐酱醋通常都需要自己拿捏,菜谱上多“少许、半勺、少量”等描述性词语。有时候PM也希望工程师这样做菜,我们想吃甜味,但放多少克糖是需要厨师自 己揣摩。

  6 自己揣摩有利有弊,好处是PM省心,坏处是项目不可控。如果从风险角度考虑,软件工程中的过程改进及文档管理是受欢迎的。

  给界面设计师看的文档

  除了工程师,那么UI设计师的DRD(设计需求文档)又该怎样拿捏?

  MS Office的Visio在PM中比较受欢迎,对于那种没有FW和PS操作经验的PM来说就更重要了。当然你也可以使用Word,但Word在画框图方面可视为不专业,对于入门级PM或者轻量级设计框图也适用。

  对Word下了这么个定论,非常惭愧。工具是死的,人是活的,高级PM也能做到拈花折枝即可杀人的境界

   根据我的经验,如果项目一旦正式启动,PM最好不要采用Photoshop或者Fireworks等软件自己来做设计。那样会让自己陷入细节,总想着跟 UED去PK设计技巧,做了自己不该做的事。因为Visio已经将模块做成控件,所以自己不需要拉框线,做精细的按钮。

  对于界面设计,除了正常的界面文案外,其他辅助性文字尽量使用一整块的灰块表示,PM不要陷入按钮和字体设计中。PM的眼睛应该像眺望远方一样,看到的只是起伏的群山轮廓,至于山上长的树是什么颜色,相信UED。

   倘若PM有空余时间,而且项目并非公司会投入UE资源去做的,还处于idea阶段。那么自己不妨用PS或FW做些精细设计。毕竟在立项前,PPT中配上 能看上的图,会增色很多,也更有说服力。让每个人头脑中不会出现1000个想象的产品,可以统一起来。至于精细到多细,要自己把握,这很花费时间的。一个 半成品的Demo专业UED也需要2-3个工作日,拿业余时间设计是不可能精细到那种地步。如果非要有个衡量标准,那就是图层尽量控制在100个以内,不 要使用需鼠标贝赛尔曲线效果,少用染色效果,不用滤镜。

  给UED的设计稿,参考纸媒在版排前的草图,那种黑白框线,文字用灰色细条代替。有空我再思考总结如何具体把握。如下图:




名词解释:
RD:Research and Development,在这里是指研发人员,就是公司的工程师
Mockup:图样,原型图,在这里的意思是初始设计图
UED:User Experience Designer ,用户体验设计。

原来人们这么讨厌植入广告

在网上看到有的人因为Mofire会在日志的最后一行加一个”Powered by mofire”而弃用,原本以为这样的东西无伤大雅,但却犯了和我所喜欢的scribefire一样的错误。- 大家都不喜欢自己的领地被植入。
那么如果这个东东是收费的呢?为什么大家都喜欢既免费又要随心所欲的东东呢?mofire的出发点是自用并共享,所以,恩哼?
Powered by MoFire

互联网知名公司项目经理面试中常被问到的问题

转载
以下是典型的项目管理面试中通常会问到的问题(期望的回答):很多的问题的答案是主观的,面试官想知道你的观点是否和他们的及公司一致。问题的构成如下:
1. 项目管理软件工具知识
2. 编制项目计划的技术
3. 人员管理技能
4. 沟通技能
5. 原理体系知识(标准开发生命周期和项目管理)。
项目管理软件工具知识
问题1:工期和工作量之间的差异是什么?
答案1:工期是商业/日历上的天数,与人数和工作量无关。工作量是与日历天数无关的人的工作。例如: 一天的工作量对于一个一只花50%在时间在上面的人来说,他的工期就是两天。如果两个人全职工作,工期是1天,而工作量是两个工作日。

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

问题3:你怎样将人的工作步调与计划结合?
Continue reading “互联网知名公司项目经理面试中常被问到的问题”