页面原型(白板)评审和模板评审

Posted by | Posted in 项目流程管理 | Posted on 06-09-2009

上周去杭州评审,主要是对一个项目的模板(vm)进行评审,参与人员包括PM、PD,PA,UI,WD,后台开发、测试等。人是比较齐全,目的是针对整个流程进行以便梳理,以便发现之前评审没有发现的问题。

之前项目已经进行了PRD评审、页面原型也就是白板评审。很少会有接下来的模板评审,但是一旦一个项目进行了模板评审,就能发现很多意想不到的收获。找出许多之前根本没有想到的点和建议,尤其是比较大的项目中。这次也是一样,虽然问题都是比较细节的地方,比如搜索条件的排列顺序,文案的措辞,是当前页面跳转还是新开窗口等等。但是这些琐碎的点放在后期开发再提出来的话,测试人员的工作量会大大提升,同时问题的责任归宿以及沟通成本也是无形中加大了许多。

工作了1年多,深刻体会到问题及早发现并制定解决方案的重要性。很多时候项目做到开发后期甚至是要发布的时候,却发现一系列很小的点都没有确定解决掉,帮助文案的链接没加、提示的cms没有做、按钮的样式不兼容等等。为什么在前期那么多时间中不能把这些问题梳理一下,做成一个文档,后期跟进解决也会高效很多。

现在公司的发展速度和招人速度令人咂舌,流程的复杂和执行的低效也让人无语。一个项目真正的开发时间远远小于一系列的评审和宣讲时间。如果这些评审和宣讲能够真正解决问题倒也罢了,关键是到后期,开发过程中还会出现一系列需求变更、业务规则变化、功能无法实现等等让人想骂娘的事情。开发的沟通成本很高,解决效率不高,因为大多时间都在确认问题和走流程上去了。这些都怪谁?我无从考证,也无意去评价什么。只能说从我的角色来最大程度减小这种时间的浪费和效率的低下。

页面原型评审,能发现的问题越多越好,但是为什么到模板(静态页面)出来之后还是会有一系列的问题?总结一下:

1,原型的制作质量。现在制作原型的工具是Axure,很好用,但是也有一定的缺陷,比如不能添加一些ajax效果,交互效果有效等。原型的精细程度一直以来大家都在争论,有人说既然是原型就简单一点,几个框几个按钮就可以了,后面还有视觉设计进行细化;也有人说能精细最好,因为视觉稿很多时候会破坏原型最初的想法,项目成员也不会拿视觉稿去评审,他们看到的原型和真实页面的差别不能太大,否则很多问题无法感知。这些说法都有自己的道理,在一系列交互和视觉规范都已经制定好了的前提下,我觉得原型还是要高质量一点。

2,需求和功能点的描述清晰度。在原型产出的前期,产品需求文档就产出了。这份文档包含了产品的所有涉及到的功能点需求。开发和测试人员很少去看原型,但是一定会对这份PRD文档烂熟一通。他们的基本点都是在这个文档上,所以这份文档的重要性可见一斑。如果这份文档质量不高,很直接就影响到后面原型的产出和问题的梳理。

3,开发测试人员的经历。这个也是很普遍的现象,设想一个经常测试页面的测试和一个测试后台的测试在看原型的时候,谁会更有感觉?同样一个做过页面开发的后台程序员,会更加明白前台页面对整个产品开发的重要性。尤其是在力推前后端分离的大背景下,开发人员需要更加关注页面,约定实现方式和接口信息。而测试人员也要明白常见的页面问题和解决办法,欣慰的是我捡到很多测试都用起了firebug~

4,项目经理的关注点。我一直坚信人的作用大于一切,不管是做事还是做人。项目经理在项目中发挥的作用不应该仅仅在保证流程进度和问题整理上,也不是每周开开列会发发项目周报而已。好的项目经理应该明确各个项目成员职位的性质和职责,大致知道每个岗位的问题影响点。最反感一味催促进度却不了解实情的pm,最完美的项目经理应该是前后台都做过,需求分析也接触过的人。这样的人来保证项目进度,他说的话谁还会说是门外汉了呢?

当然除了以上4点之外,还有很多小的点,比如文档的书写和负责人的确定等,这里就不一一列出了。总之,人很多,项目也很多,如何花最小的成本让这么多人都能做实事而不是浪费时间,每个人都有自己的想法。我想公司也在一直研究这个问题,作为最底层的民工,还是好好工作,认真加班,期待一年一次的加薪吧~

Write a comment