Tag Archive for '互联网'

网站优惠券推销模式

已经有很多类似的模式,其实就是优惠券批发,这里主要强调的是易操作性-可以商家自助完成优惠券发布,发布商主要是网站自助完成优惠券渠道申请,中间的平台做到统计和监控以及防滥用。
Powered by MoFire

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

转自 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

笔记 – 互联网产品业务级别划分

摘自支付宝架构师程立的演讲ppt - SOA在互联网系统中的应用

mindmap – 第三方电子支付平台业务系统

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

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

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

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

SOA 就是 OpenAPI

两个时髦的玩意,原来就是一回事。并不是很难理解,只是大家习惯了接受各种各样新名词,而又惯性的没有去把二者联系起来。知道在wikipedia的SOA词条里看到这句话:

A mature rollout of SOA effectively defines the API of the organization.

任何系统无论是复杂的商用系统还是简单的个人博客,都在提供或多或少的服务。将这些服务分割成独立的,无状态的服务单元,然后通过HTTP(webservice)或者是其他的连接方式连起来。接下来,如何compose这些服务单元又是新的问题,ESB和BPM就大行其道了。将来有一天,用网站提供的OpenAPI进行网站之间的整合,互操作,信息交换一定会催生出更多有趣的东西。

中心思想:互联网和企业应用同样都需要整合,而且整合方向和方法应该都是一样的。

纯属YY

猪八戒,真的憨厚老实吗?

早就听说猪八戒是中国最大的威客网站,今天试着在上面发了一个小任务试了一下。
很快就有客服(猪八戒称为任务秘书)给我电话,大概是审核。我问了一下流程,得到的答案是:
发布任务之后,有7天时间收集稿子,再有7天时间给你审核。如果有,那么很简单,收东西,给钱。如果没有满意的,那么只有两种选择:
1.加钱,再来一轮
2.从“不满意”的稿件中选一个
总之,钱是不会退的。我跟他们说,这样对发包人是很不利的,因为完全有可能“猪八戒”雇用一帮垃圾交垃圾稿,(而且我确定今天已经收到一个垃圾搞,什么都没有  -- 就一张代码截图)。最终很有可能是从这一大堆垃圾搞中选择一个。
在网上随便搜了一下就看到这些说猪八戒是骗子的人,而且不仅仅是发包人被骗,还有很多设计师被骗,手段也很恶心。

我会继续跟进。。。

老年人的网站

孤陋寡闻了,刚刚听说百度的老年搜索 - 123.baidu.com
不过除了域名简单一点字体大一点好像也没什么。
为什么不能把其他网站的内容frame进来,然后再转换为大字体呢?否则老年人点击链接转到其他网站还不是一样晕吗?百度还是只走了一小步。不过国内那些网站,网页什么时候都填的满满的,不小心改个字体,八成都没法浏览了。