自从2006年12月25日加入公司，屈指一算也快四年了。从07年6月份开始，开始有意识的积累自己对产品设计和研发的知识和经验，历经 技术支持，Discuz!NT开发部，Discuz！开发部，运营部门，期间扮演过开发，测试，需求分析，产品设计等诸多角色。四年来多次针对公司的产品研发提出过一些想法，也和一些相关人交流过，基本上都石沉大海，最近听说公司终于决心在这方面有所改进，心里有一种酸酸的感觉，眼睛似乎也微微湿热。
大约一个月前leader提醒我把再一次把自己的想法整理一下，我便开始整理。 由于这些日子一直忙于暨阳社区的事情，这个整理过程放慢了。 上次和老大打招呼就是因为这个整理过程完成了想和你聊聊这个事情。希望把我在这方面的思考和实践分享给公司，产生真正的价值！ （我的总结主要来自于两个方面 ，一个是这几年来从事各方面工作的切肤之痛，一方面是大量的对别人经验分享的理解。）
附件中是我画的一个产品研发流程图，图比较概括，我又稍微补充了一个文档作说明。但是还是不能把一些方面详细的描述。如果需要 可以随时找我面谈，我会描述各个环节中 各种角色的人员配置等问题。我会尽力把我知道的分享给大家。
很久以来，我总觉得 我们改造自己的勇气太小了，改造用户的胆子太大了 .
整理用户反馈
抱怨型：后台删除用户真不好用
用户往往只说明某处存在问题（例如：后台删除用户真不好用），但没有说明问题出在什么地方
出谋划策型：
用户会针对问题给出解决方法，但往往没有表露其解决方法背后隐藏的问题根源。
高瞻远瞩型：
用户从产品方向，市场方向等层面高谈阔论
搜集,分类,确定级别。
探求问题根源
不好用（操作复杂，需要重复多次，速度慢等），
不能用（bug，性能问题），
不知怎么用（缺乏引导），
根本没有用。
把用户的要求，变成产品需求.
设计解决方案：
设计解决用户真实问题的方法，并同时设计检测问题解决效果的方法和标准。
制作产品原型：
产品原型是不断演化的， 在多次迭代中不断丰富成型，最终形成可发布版本。
内部审议：
对本次迭代周期内的产品运行进行评审。
每日构建：
产品原型在任何里程碑阶段都是对用户可见的。这个过程的实施策略是以自动为主，手动为辅，保证每{yt}用户都能看到一个可用版本。 这个过程的真实目的是 通过允许用户随时能拿到一个可更新的版本,来加快用户研究过程,提高用户需求分析质量
发布与部署:
产品包，补丁包，直接部署。
效果跟踪
用户反馈
统计数据
