项目评审机制在一个产品诞生过程中，占有非常重要的地位。在一个产品从立项到发布的每一步都需要经过专业的评审：需求分析时需要评审，原型设计时需要评审，交互DEMO后需要评审，视觉设计时需要评审。每一步的评审都伴随着专业的评审结果文档，方便其它同事以其为标准进行下一步的工作或修正现有的工作内容
当然，这些是在非常成熟的大公司里才可能走的流程。发展中的小公司基本上是老板拍脑袋定需求----设计人员拍脑袋做设计----技术人员拍脑袋写代码----测试人员拍脑袋测试。我所在的公司也一直处于这种状况了很长时间，最终结果就是----老板郁闷于大家的工作效率低，员工郁闷于老板的善变。不过经过一年多的磨合，我公司现在的总经理也已经算是半开窍了，从一个实业经营者变成了半个互联网产品专家，也开始慢慢的接受一些文档的制作、开会的研讨等项目开发的基本流程。
我，就是在这样的背景下从技术中心调出来做产品策划（未来有可能是产品经理吧 - -。)，光杆司令一个，目前还隶属于技术中心。不过我有信心慢慢的改变这一状况。祝福我吧，哈哈。
回到正题。前一段时间经过开会，老总也同意走一些流程化管理。目前的基本流程是这样：我主导几位部门负责人开会总结老大的需求---做原型图（用axure）----开会过原型图（策划、设计、技术人员）----我写功能交互说明文档---设计师开始设计页面（中间可能有些小沟通）----最后把原型图、说明文档、设计稿一起并给技术中心老大和相关人员（发邮件）----技术中心开始（前端人员、编码人员）工作---------------交付工作结果。
这样的工作流程是多么完美。这样的流程在小公司已经算是老总开明了。但实际情况是，到了技术中心这里流水线就断掉或完全就走偏了。这样的情况在我调岚后已经经过了几个小项目的测试，期间也开会提醒过技术部门老大要把关，但最后交付出来的作品还是问题一堆---很多低级的小错误，明显一看就知道是没有任何人把关的作品。
基于这种情况，我想来想去，还是要把“项目评审”这一步提上日程，不能漏掉。但我们的评审又没办法像大公司那么专业，在产品管理的过程中每一步都有专业的人来参与。最终我想用一种“评分”制来取代专业的“项目评审”机制。
如图所示：草稿版本
这张“评分”表格还不是特别细化，也没有达到“评分”的目的，这是要拿去公司周例会的时候讨论用的，具体要不要执行还不知道，但初步想到的则是可能遇到可种阻力......因为这张表格是要技术中心来填写的。
这样的表格我计划是让技术中心负责填写，产品的每一阶段都有专人负责填写这样的表格并为之负责。否则在一个没有测试部门和测试人员的公司，怎么对产品质量把关呢？
我暂时没有其它好办法了。
