码迷,mamicode.com
首页 > 其他好文 > 详细

关于2011年meng-meng组产品《豆酱》的Review

时间:2014-08-31 00:22:20      阅读:258      评论:0      收藏:0      [点我收藏+]

标签:blog   使用   数据   问题   log   sp   工作   on   时间   

这个组是当年唯一一个做手机应用的组,比较有特色。

经过我们的一致讨论,得出我们组对前辈的有关选题、团队、产品等几个方面的看法,以及我们的感想。

 

选题的特点:

这个选题对于一个短期项目来说是很合适的,经过较为详细的NABC分析过后该团队初步定下了豆酱的功能及按照功能进行团队分工。

简单来讲,他们通过使用豆瓣api来获取数据,并显示到UI上。

1:不需要太多的设计内容,他们可以参考豆瓣现有的app的功能来完善自己的设计。

2:难度适中

3:有一定基础的用户。

 

该团队具有的优点:

1、选题适当,参考上面的说法

2、分工明确,成员按照实现功能来分工。

3、目标明确,每个人每天完成的内容以及次日目标明确。

4、勤于分享,积极将工作中遇到的难题及解决方案分享到blog上。在实现的过程中meng-meng团队除了正常的Scrum blog之外还经常分享其攻坚难题所获得的经验、读书心得等。

5、很好的应用了风险管理,避免了不可抗因素对进度的影响,为任务留出充足的缓冲时间。

6、充分利用时间,在饭桌上讨论问题。

7、在team project中用到了pair programming,测试中,采用组间互测的测试方法,对软件进行了充分而合理的测试。

 

产品的优点如下:

1. 缓存功能,缓存图片,节约流量,虽然在demo里显示的速度仍然很慢。

2. 豆邮,对于社交软件,这种通信工具的整合是必须的。

3. 作为阅读工具来讲,功能比较简单齐全,使用简单是大众化的基础。

4. 从系统的完整性和功能性上来说,这个项目做的客户端可以算是比较完整的。基本上能够实现作为豆瓣第三方客户端的功能了。

5. 从工程和工作时间,工作人数的角度考虑,五六个人能做到这样也还是值得肯定的。

6. 他们为app加了缓存的功能,一方面可以为用户节省流量,另一方面又可以加快访问速度,给用户提供更好的体验

7. 他们没有采用豆瓣评论的API,而是采用了“看过”这个API,因为“看过”可以写短评,而普通的评论必须在150字以上,在手机上输入150字是个很痛苦的过程

8. 他们允许用户在不绑定账户的情况下使用部分功能,充分为用户考虑

9. 基于以上几点,可见他们还是有较强的用户体验意识的。

 

产品的缺点如下:

1. 登陆豆瓣的时候居然是浏览器打开的,还需要手动放大才能填写登录信息和点击登陆。用户体验不够好,但是可能局限性在于登陆时候的验证码。从评论来看,不能保存登陆信息,每次都得这么来一遍,用户表示不满。

如果是我们来做,我们会做一个登陆界面的UI,而不是只充当网页的浏览器,而至于验证码,如果没有API,我们可以把验证码图片抓下来让用户输入,至少比网页的体验要好。

 

2. demo中没有展示豆邮收到消息的反应,所以我猜想没有消息推送功能。

如果是我们来做,我们可能是希望这种消息信息能推送给用户。

 

3. 界面设计不够好,有些页面字体大小不合适,标题字体的设置与正文字体大小的不协调,图标大小的设置,背景单一,交互界面给人一种不太精致的感觉,不过能让用户自己来调节可能会更好。

如果是我们来做,我们可能希望加入手势功能来进行缩放字体大小来满足用户的需求。

 

4. 我没有看到推荐功能。我认为,豆瓣是这种以兴趣为基础的平台,推荐电影,推荐阅读等等都是必不可少的功能。

如果是我们来做,我们可能希望引入当下比较热门的推荐算法或是使用豆瓣自带的推荐。

 

5. 现在的豆瓣有了更多的东西,像豆瓣FM,豆瓣音乐,豆瓣小组等等,所以固定的功能键的起始页可能就会显得杂乱。

如果是我们来做,我们会让起始页面能够让用户来定制,类似pin一个图标之类的,提高用户使用效率。

 

6. APP的反应速度和加载速度较慢(当然这有一部分是因为网速和手机硬件的因素)

如果是我们来做,现在手机硬件性能提升,应该会做的更好。

 

7. 从市场定位角度来说,虽然豆瓣没有官方的WP应用,但是非官方的应用还是有很多,如何做出自己的差异和创新,如何定义和打造自己的核心竞争力。在这些方面这个产品是比较模糊的。目前来说,经过我们调研,《豆芽》这款应用是同类应用中最好的,相比之下我们这个应用还是有很多不足的。

如果是我们来做,会先试用一下其他同类的WP应用看看效果。

 

我们对这一款产品的感想:

1,关于分析,也是要做好前期的分析工作,软件做出来要大家用的,没人用也就没有做的意义。需求分析、用户分析、功能分析……肯定要做到位。

2,关于分工,小组分工我不太会采用他们这样的分工形式,每个人负责一个功能,从数据到UI设计都需要个人实现,这样可能会出现的问题就是每个功能的风格不统一,而后期大家整合的时候需要花很大功夫来调整UI。可以参照MVC来分工,做UI的就做UI,做交互就做交互,做底层就做底层,由PM商定好接口就可以各司其职了,这样对以后修改、扩展都有好处。不过我们小组人比较少所以可能大家工作量相对大一些。

3,关于测试,因为人数比较少所以每个人也要同时担当起测试员,而测试工作不能等到临近发布才开始,白盒测试基本上可以和工程同步进行。黑盒可以在基本成型时开始进行。

4,关于设计,同样会参考豆瓣自身及其app,结合winphone特点来设计我们的UI。‍

 

如果是我们做这款产品

首先,从市场定位和目标用户核心需求的角度来说,豆瓣的核心用户群是具有良好教育背景的都市青年,包括白领及大学生。他们热爱生活,除了阅读、看电影、听音乐,更活跃于豆瓣小组、小站,对吃、穿、住、用、行等进行热烈的讨论。针对这些特点,一个思路是做一个豆瓣产品的整合者,将豆瓣FM,豆瓣读书,豆瓣电影,豆瓣同城,豆瓣小组等豆瓣产品进行高效整合,这条思路的重点在于整合要简洁高效,不能比用户分别使用这些APP麻烦,且响应速度要快,用户界面要精致。”豆酱“是朝着这个方向去的,但是这个方向需要有比较强大的技术和时间的支持。所以如果是我们做,我觉得我们会选择另外一条路,即用个性化推荐的方式进行资源整合。豆瓣本身就是一个以兴趣会友的地方,用个性化推荐的方式会非常有效。同时,充分利用了豆瓣平台太多以及人的精力有限的特点,突出跨平台个性化推荐这一核心竞争力。而且这样,我们的UI界面可以做的非常简单,只需要像刷新闻或刷微博那样,只有一个界面,简单明了。但内容又是跨平台的,确保用户能以最短的时间最快的速度浏览到他最兴趣的内容。而技术方面,后台的支持系统会利用同一个用户账号,得到用户在所有豆瓣平台上的订阅内容,再基于推荐算法先做一次推荐。之后,基于用户的反馈信息,进行不断的学习。

关于2011年meng-meng组产品《豆酱》的Review

标签:blog   使用   数据   问题   log   sp   工作   on   时间   

原文地址:http://www.cnblogs.com/saint-west-campus/p/3947108.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!