IT解决方案基本步骤
在老布的blog上看见一个好文章 转了过来，以作保存 (老布的blog地址：http://blog.9zi.com)
1：阐述做这个事情的需求，必要性
2：描述现有解决此类需求的方法，以及有缺点
3：需要优化或者解决的问题（减轻做什么事情的负担，提高那方面效率，使用上什么工具，从哪里解放出来）
4：描述理想方法，简单原理（计算机、软硬件），优点,以及避免缺点的手段：例如：异常处理（自动处理出错的情况下），可以支持传统手法（作为补充），兼容旧模式，防止计算机系统出故障造成日常工作不正常。(导入导出)。把后顾之忧解决方法清清楚楚的展现给用户。
5：推出软硬件解决方案，架构方案，组成结构。
7：时间进度表，项目关键人员基本情况，（项目招标中需要的）
6：报价，成本预算。
这是从日本人一个小软件产品ＰＰＴ上总结过来的，简单几个Page就把软件的意义解释清楚了。
注意这里的重点是如何把问题解决，为什么要这么做，这些才是用户需要你提供的专业参考。无论是项目招标还是产品推销，都应该这么去做，但显然既然方案写得很实在可行（无过分吹嘘造假）也基本可以说明能把这个事情做好（因为现在的技术已经相当成熟，软件开发人才也足够多）。
至于你的技术架构、实现、采用什么技术，虽然是参考，但都不是重点。占的比例不能大。技术方面用户需要知道的是他最终的系统能够有效使用多少年，数据能否顺利迁移，你是否有能力做好服务。
回想微软的讲座：说中外方案不同点，中国人把所有技术概念ｃｏｐｙ到方案中，把简单的方案搞得很厚，看着爽啊。但是不解决问题，这是因为官场虚浮的原因（以厚度来评价质量，花国家的钱花得轻松，如果花的是自己的钱，相信决策者会仔细阅读、和做专场答辩的）
这样写不清楚的原因往往是，参考别人的方案，不知道为什么要这么设计，而简单的复制/粘贴，直接导致的原因就是需求不清晰，对用户没有起到帮助，对自己未来的项目建设没有指导价值。自然生产出的产品给用户来说是往往是花了大价钱搭建的形象工程。
这些在软件工程、项目管理中都有详细的描述，只不过被老外认为是基本概念，必须有的价值观。在理论中简单带过，虽然在理论中的篇幅占用很少，但是却把握着软件意义的命脉。我们没有经历反复的实践、碰壁，就直接接受这种理论教育，导致的最终结果自由教条注意软工，解决不了任何问题，甚至还不如几个人手工作坊修修补补来得实际。
社会等非技术原因导致了我们没有太多时间仔细思考软件的价值和意义。但在经历的痛苦过程中反复思考确实是件很有意义的事情，把游戏、看电影的休闲时间节约下来闭眼思考思考，人生从此充实很多。同时，在接受别人观点的同时也多结合自己的经历、理论多思考思考，会有很不同的效果。多思考、多交流，一辈子可以体验完几个人的生活，不至于总觉得无事可做。
分类：UCD ,04/12/27 4:42 下午 | 15,931 次浏览 |