存档

标签 ‘产品与设计’ 中的存档

产品团队发展史

2010年08月11日 Ben 0 条评论

“我们需要专职的PM

首先,我们是一家初创公司,在公司创立初期,就开始说这句话,一直到现在,才有结果。我的性格算比较单纯,而且能直言不讳,过去几年也因此吃过不少亏。如果这句话在腾讯说,可能老板会认为这是理所当然的,要这么做;但如果在一家传统的企业、在传统的组织构架下,跟一位传统的老板说这个事情,就不一定认为这是理所当然的了。

而我,就处于这样的环境下。过去3年网站没多大发展,或多或少和这个环境有关系。

========================分割一下=========================

回顾初创时期,根据传统的组织构架,公司分为技术、运营、市场三个大部门,各个部门从最底层开始往上堆(运营:客服、策划、营销推广、频道经理、运营经理、运营总监;技术:开发、测试、项目经理、技术经理、技术总监;市场:市场销售、市场总监),看上去其实也挺正常的,一层一层分的很清楚。

说实在的,这样的组织构架其实是没问题的。只是在开发新产品时,问题就来了。

技术说:这个产品,业务非常复杂,因此,这个产品应该让我们来设计,运营估计搞不定。运营回复:的确如此,那就你们设计吧,开发完成后提交给我们。

经过前期一系列研发工作,产品开发完成,提交给运营。运营拿到成品,在网站上做一些简单的推广(广告、软文、站内短信......)后,完事,从此以后,该产品就开始自生自灭了。

负责产品设计的人干嘛去了呢?技术说:我们也很忙,现在又在忙新的产品,而且时间很紧急,这些事情就先放放吧。产品没发展好,技术与运营开始相互指责,说你没做开发好,或者说你没运营好……到底谁是谁非,谁也说不清楚。

对于这个问题,在过去的三年中,试图去解决这个问题,做过很多尝试,试图说服各个层次的老板,我们是不是应该换一个思路,尝试实行产品制度,有专门的产品人,产品团队来做产品,而不是由技术、运营相关人员兼。产品团队对产品全权负责。

但这样的尝试,大多数情况下都失败了,老板的回复:PM,也就是说所有的事情都是PM干了,那怎么能行?

其实相信老板也是懂行的,之所以这样说也是有他自己的顾虑,毕竟这和现有的组织构架相冲突,可能会触动某些位高权重的领导的神经,本来是好事情,最后得罪人就不好了。

这个事情就这样耗了快3年的时间,经过中途经融危机的洗礼,网站访问量急剧下降,至今仍未恢复元气。老板们也急了,问题到底出在哪里?为什么我们的用户量上不来?为什么……?

========================分割一下=========================

既然老板开始重视这个问题,我想这应该是成立产品团队的最佳时机吧。于是拖出全盘方案,包括:产品团队组成、产品研发流程、产品线运作流程、各个职能单位的工作范围、考核、招聘、产品线状况等等。

老板说:可以就这样干吧,要招什么人,就招吧,尝试这样做一下吧。

就这样,产品团队成立了。但是,我们才刚起步,前面还有很多难题,毕竟,扁平化的产品团队与层次化的传统企业还是有很多相冲突的地方,我们需要的,仅仅是时间、耐心,还有一颗专注于互联网产品的心。 

再回顾一下整个过程,难道这是一个必然吗?初创的互联网企业,是否都会经历这样的阶段呢?就好比要进入共   义,必定会存在社会主义这样一个阶段吗?

产品设计流程中的关键评审点

2010年08月02日 Ben 2 条评论

产品设计流程中,比较关键的评审点有哪些呢,如下图:

 

iamben@关键评审点

(看不清,请猛击图片看大图)

如上,产品设计流程中,比较关键的评审点有产品介绍会议、需求评审、项目启动、原型设计评审。

产品介绍会议

作为专为老板定制的产品介绍会,其重要性当然不言而喻,相当关键。任何产品,在开工之前,一定需获得老板的支持,因此最好的办法就是做一个漂亮的PPT,然后把老板们召集起来,充分发挥你的口才,给老板们好好的生动的上一课。

在介绍会上,介绍一下为什么需要这个产品,都有哪些商业价值,能给公司带来何种的利益,尽力吹。

提出一个可行的产品规划,短期的、中期的、长期的都可以,让老板们觉得你是在认真的做这个产品。

最重要的一点,PPT中要提出对资源的要求,有多少人参与,都需要什么人。

总的来说,产品介绍会主要的目的就是给老板介绍产品,需获得老板的支持,向老板要人。

需求评审

“很好,就这样执行下去吧”,老板都这样说了,那就什么也别说,甩开膀子干吧。

等等,产品可大可小,我们到底做多少,做到什么程度,满足哪些需求,怎么定?

那就把相关人员聚在一起开一个需求评审会吧,大家讨论一下,本期产品的实现范围,给需求排个优先级。

讨论完毕,一定记得冻结需求,并形成需求文档。后期的详细产品特性以及项目计划,都已这份需求文档为准,对于后续执行过程中的新增需求,一律作为后续需求,补充在后续的版本中,这点很重要。

项目启动会

好了,产品的实现范围确定,相信产品特性也就确定了。

这个时候,可以把产品组相关人员都聚集起来,如策划、运营、开发、测试、美工、市场等相关人员。

给大家说说,这是什么样的产品,要实现哪些功能,完成后,我们能得到什么。

另外,需在会议上提出初略的产品计划,更详细的计划,需进一步与相关部门的负责人沟通后才能得出。

总之,就是要给大家说清楚,接下来我们要做什么事情,大致的范围是怎样的,具体有哪些人参会,项目的大概计划如何。

产品设计评审

需求确定后,即可开始产品的原型设计。在之前,需产品设计师充分理解需求,并将需求转化为产品特性,以原型的形式展现出来,并提供给开发、美工、测试人员。

在原型设计完成后,需对原型进行评审。通常,评审会并不是一次性通过,都会来回好几次。

好的产品是“磨"出来的,没有哪个产品一做出来就是完美的,都需要不断的调整、完善。同样,我们做原型,也应该有这样的态度,原型也是产品,不能因为是原型就马虎对待。

原型设计评审通过后,产品的前期工作已基本完毕,对于产品后期的工作,已基本没有太大的障碍,各条线继续按照产品计划往下走即可。

值得注意的是,如果资源充足,在原型设计评审期间,还可开展一些可用性测试,相信在可用性测试期间,还会发现不少可用性问题。至于如何进行可用性测试,此处不再详述,留在以后的篇幅中吧。

为什么要成立产品团队

2010年07月31日 Ben 0 条评论

加入数米3年,刚好也是公司成立3年时间。回顾这过去的3年,我们的确做了很多事,网站不断改版,不断推出新功能、新产品,风风火火。在经历了07~08大牛市行情后,世界卷入金融危机的漩涡,国内资本市场遭重创,数米作为基金服务行业,也难幸免。到如今,网站的状况和3年前一样,好像又回到了起点。这一过程好比过山车。

如果用数米网的流量画一条曲线,我想这应该和中国资本市场的发展曲线是一样的。

我们就是这样的“靠天吃饭”。

我们和资本市场一起玩起了过山车。

--------------------------分割线----------------------------

数米的用户,从来不缺乏粘性。数米用户对某些产品粘性非常高,高到每天只需要上来用一下这个产品即可,其他一切都可以不用理会。

因此,当我投资基金的时候,我上数米看看;当我不投资基金的时候,就不用上数米。但是,当我做投资时,我必定会上数米,忠心不二,绝无他想。

可是,过去的3年,数米却并没有好好的,认认真真的运营过这些具备高度粘性的产品。主要精力投入在思考如何达到财务指标这类事情上,这也许就是中国式互联网企业的发展模式,创业初期,首先得想办法活下来,尤其身处低谷时。

如今,形势好转,我们挺过了最艰难的时期。我们需要重新捡起互联网,我们需要认真对待产品、用户,我们需要有一些小变化。

我们正在成立产品团队,正在投入,去认认真真的做产品,去解决“从用户中来,到用户中去”这一过程中的所有问题。我们在原地走了太长时间,是时候向前走了。

Web前端页面结构要素

2010年05月10日 Ben 0 条评论

整理一下个人感觉在制作Web前端页面时需要注的要点,我不是SEO行家,只是记录一下平时工作中的了解到的东西:

1、Keywords & Description

描述与关键词元数据,介绍本页面是什么页面,包含什么内容,都有哪些关键词。与其让搜索引擎去分析网站都包含什么样的内容,还不如你直接告诉他,从一定程度上说有利于搜索引擎。

2、title

尽量简短,突出要点。

3、robots.txt

哪些内容不需要搜索引擎抓取,哪些内容需要抓取。sitemap位置等,都可以在这里指定。

4、sitemap.xml

站点地图,往往搜索引擎是比较喜欢站点地图的,也是搜索优先考虑抓取的内容。

5、follow & nofollow

记住,页面上不是所有内容都欢迎搜索引擎来抓取的,比如一些外部链接、登陆页面、错误页面、非链接的链接标签等。

6、shortcut

设计一个适合你网站的图标,然后让浏览器来显示她。

7、简洁的布局结构

使用简洁、优雅的布局HTML结构,如用div、ul、ol、li、span等来布局。搜索引擎不喜欢冗长杂乱的内容。

8、尽量少文件引用

目的是减少连接数,图标尽量合并,尽量使用少的样式与脚本文件。

9、简洁的URL结构

搜索引擎不喜欢冗长的URL地址,尽量不要使用&=方式提供参数,因为要让搜索引擎去区分 ? & = 是一件比较费事的事情。