一些做产品的项目经验:立项、流程、文档

标签: 设计思想 | 发表时间:2013-06-25 05:53 | 作者:纯银
出处:http://www.blogread.cn/it/

标签:   立项、流程、文档

▎关于立项
到目前为止,虽然我们只做了一个蝉游记,其实还做了另外四款App的设计,只是没时间研发,先搁着。

   

立项的过程是这样的,通常由我先提一个想法,跟大家聊聊;如果没遇到强烈反对,再跟几个亲朋好友聊聊。我心里有点底的时候,一边看同类产品一边出Axure原型——这很快,不会超过两天。但也有可能在过程中发现想法不靠谱,便放弃了。

   

低保真原型画出来之后,蝉小队会挤成一坨,听我讲解,提提意见。如果没遇到强烈反对,就请UI设计师抽空出PSD,通常只出主页面,次要的小页面都不用管。

   

然后我把视觉稿拷到手机里,遇到熟人就掏出来给他看看,听听外人怎么评价。

   

对于新项目,我会倾向于设计好了之后“放一段时间”,而不是立刻上马。当然,也是我们没时间立刻投入研发。放一放会让想法渐渐成熟,也从外人那里得到更多反馈来改进设计。一款App在开始编码之前,可能已经大改过几次原型,修正了不少细节。

   

蝉游记采用同样的处理方式,经常把排期在半年后的模块先设计出来,放半年,反复改。这样可以抵消一部分快速设计带来的冒失。对着一套成型的东西,才会有更细致的思考。想法需要快速转化成有说服力的原型,否则单凭拍脑袋拍出来的点子,没资格讨论做不做,上不上。

   

▎关于一个完整的版本流程
蝉游记的一个正常App版本迭代,通常用3-5周的时间。

   

版本计划里的小功能点由我直接定,大功能点要提前征询工程师的意见,走一遍原型评审。说是评审,其实是大家挤成一坨,听我讲解原型。讲完了没人反对,我便在Tower上把视觉任务排好日程,跟UI设计师确认好时间,设计师按着白纸黑字的排期出PSD(Tower真协作神器也)。

   

在新版本研发开动之前,我会准备好全部的PSD,版本计划在Tower上用蓝色标签标识出来。事先跟工程师约定好大概用几周时间,每研发完一个功能点,就在Tower勾掉,每天看Tower知进度,晨会都不用开。

   

如果按4周的版本迭代来计算,最初2周我在作下一个版本准备,从第3周开始,我介入测试,对着Tower上勾掉的蓝色标签一条条测,再把调试需求用红色标签记录下来。第3周会完成功能研发,预留1周半时间调试。新版本需求全部搞掂后,我用一整天的时间全面回归测试一轮,蝉小队接着全员测试一轮,通过之后提交。提交之后工程师到我旁边来,这时蓝色标签已经整理好了,对着Tower听我讲下一个版本计划。

   

善用tower.im,可以让项目有条不紊,清晰透明地推进。

   

▎关于文档
我有个观点,大公司里完备的产品文档其实没几个人看,主要是用于扯皮。“我在文档里写得很清楚,是你没有实现!”“你的需求和文档不一致,工期必须延后!”

   

蝉小队组建初期,还用DOC来记录需求,后来熟了,默契了,就大力简化流程。UI设计师对着低保真Axure原型出PSD,工程师则对着PSD编码。交互效果主要靠口头交流,简单的功能算法也口头交流,复杂的就作为一则功能点,在Tower上单列出来详细备注。

   

当然,这是特别默契的做法。

   

还在磨合期的时候,我会出一份更完整的草图原型,把交互效果,功能算法,设计思路都标注在上面,方便工程师建立对产品的整体印象。但我是懒得做原型动态效果的,标注全用文字,像黄色便签纸一样贴在草图旁边,佐以口头讲解。再后来,工程师对产品设计滚瓜烂熟了,就甩开原型直接看更直观的PSD,对应Tower上的功能点,一看就明白。

   

这样做的坏处是,缺乏完整的产品记录,一旦忘了什么立马傻眼。且慢……我还有一份特别详细的测试用例,单单App就列举了接近500个细碎的测试点。虽然它是用mindmanager写的,可读性特别差,绝逼只有我自己能看懂,但涵盖了绝大部分的功能点。当产品进入稳定期,正规期之后,对照着测试用例,很容易能整理出规范的产品文档来。在那之前,由于需求多变,在测试用例上直接修订会便捷得多。

   

▎关于tower.im
写到后面,我发现这篇文章基本上变成Tower的广告贴了。没错,我就是Tower的脑残粉。有人说它复制了那谁谁,然后我就得忍受极慢速度与英文界面去使用原版,以彰显我的道德优越感?别扯了。

   

用Tower有这么几个好处。第一是条理性特别强,任务被一条条分解出来,对应人头,对应日期,十分的清晰。

   

第二是弹性特别好,配合分项目、分组与标签,可以记录版本需求、调试意见、疑难问题、视觉排期、运营计划,不论啥玩意儿都可以装进去。

   

第三是进展特别透明,谁分配了多少任务,完成度如何,所有人都看得到。

   

适应Tower一段时间之后,每个人每天刷一下Tower,既知道自己做什么,也知道别人做什么。既能接受我安排的任务,也可以自己给自己下任务。因为所有的工作安排都平铺在上面,都有着明确的截止时间,很容易制定出合理的时间计划来。

   

但适应Tower有一个前提,你本身就得是一个很有条理性的人。Tower并不会改变你的工作方式,而是让你原有的工作条理变得更清晰,更透明,更有效率。如果你很少1、2、3地给自己下任务,给别人下任务,很少将任务分解成细颗粒度,也很少进行严格的时间规划,那是玩不转Tower的。而且我也不认为那样的人有提升效率的意愿和能力。

您可能还对下面的文章感兴趣:

很抱歉,暂时没有......

相关 [产品 项目 经验] 推荐:

一些做产品的项目经验:立项、流程、文档

- - IT技术博客大学习
标签:   立项、流程、文档. 到目前为止,虽然我们只做了一个蝉游记,其实还做了另外四款App的设计,只是没时间研发,先搁着. 立项的过程是这样的,通常由我先提一个想法,跟大家聊聊;如果没遇到强烈反对,再跟几个亲朋好友聊聊. 我心里有点底的时候,一边看同类产品一边出Axure原型——这很快,不会超过两天.

一些项目管理经验(1)

- - 曉生
要尽早的参与到产品的需求当中,在讨论过程中给出自己的专业建议. 设计是整个团队的一部分,考虑的不只限于我应该做什么,而是可以为整个产品做什么. 设计与产品不可避免会有意见上的冲突,设计抱怨产品策略没有想清楚,强调流程上产品给出明确的文档之后设计再开始参与. 如前期能帮助制定产品策略,会扩大设计的影响力.

项目性能优化经验--ZY(二)

- - 行业应用 - ITeye博客
项目中,用了很多的LAZY级联,在页面用到的时候再去load,这样就使用Open Session In View的功能,在大并发且网络不好的情况下,会导致session迟迟不能释放(session要等页面request请求完全结束之后才close),即connection也没法释放. 之前项目都是使用EAGER,JSON数据传递的方式来处理,整个连接池太小不过100就能顶住1000+的并发下单.

项目性能优化经验--ZY(三)

- - 行业应用 - ITeye博客
读写分离,不是想做就做的,说分就分的,随便找个中间件把请求一转发就OK的. 比如,在项目中有个模块是购物车(现在的电子商务一般都需要存储购物车内容,因为存在PC,MOBILE等不同的终端),客户先点击添加购物车,然后结算(这时候会做个判断购物车是否有商品),在大并发情况下,mysql的读库和写库的同步(beanlog)严重的delay,导致购物车一直判断为空,订单无法下.

项目性能优化经验--ZY项目

- - 行业应用 - ITeye博客
最近负责给公司某个ZY项目进行性能优化的一些经验分析. 压力测试到100并发,任何一个场景CPU暴高,接近100%. 查询jstack日志,发现大部分的线程block在tomcat 的 http11.connect 的poll方法上 或者是c3p0连接池的获取上. 同时发现该项目数据库连接池配置了2000+,仍然不够用,100并发.

产品运营设计经验闲谈

- - 百度MUX
但是产品发版、公司活动都需要你的设计参与,运营设计是这一切工作的基础. 各种紧急的重要的需求,都需要保质保量完成. 不断的积累运营设计经验,也是自己的安生立命之本. 运营设计是一道大餐,很愿意和大家一起分享,欢迎大家一起讨论. 这要先说说产品的流程,移动产品从出生到和用户见面大多都会经历这么几个阶段:.

纯银:一些产品经验

- - 博客园_新闻
我原本说,产品落地生根,就把这其中的曲折与经验都写出来. 结果落地容易生根难,还没到阶段性总结的时候. 近来手痒,先写几条实践过的,鸡毛蒜皮的产品经验吧. 刚开始设计蝉游记的时候,我就没留独立注册的位置,只支持新浪/腾讯/豆瓣账户登录. 在微博上谈起过这事,当时支持与反对数大约是 1 比1. 答:微博封我,还有 QQ 嘛;QQ 封我,还有微博嘛.

产品运营设计经验分享

- - 人人都是产品经理
运营设计是一道大餐,很愿意和大家一起分享,欢迎大家一起讨论. 这要先说说产品的流程,移动产品从出生到和用户见面大多都会经历这么几个阶段: 功能定位——交互流程( Ui )——视觉界面( GUI )——开发和测试——发版运营. 由此可见运营就是产品出生的过程,没有好的运营,酝酿已久的产品也见不到更多的用户.

Google+项目负责人分享产品细节

- Fung - TechCrunch中文站
TechCrunch的资深记者MG Siegler上周预先专访了(或许是被约谈)负责Google+项目的两位高层Vic Gundotra和Bradley Horowitz. 按照他们的描述,Google+不仅是一款社交产品,甚至超出社交战略的范畴,它是Google自身的延伸,所以叫做Google+.