标签：style tar color get 使用 strong
关键点：
无论什么时候，文档一定要同步，一定要重视，其一是因为有统一标准，其二为后期，或者下个版本的升级，重构，增加功能省了一半以上的时间，与没文档的相比较（至于团队等方面比较泛的东西，你懂滴）
需求：
需求人员（其实业务人员写需求分析可能会更好，因为他对业务灰常了解）需站在用户的角度去想问题，定位清晰的目标人群，切忌模糊不清的需求，看着办或者边做边修改的思想，后期的修改后会让你付出惨重的代价。
通常用户也不理解，描述不清该功能应该怎么实现才好，这时候，作为业务人员必须清晰了解，其目的是什么，从目的出发，从而提出合理性的建议，为开发人员省时间，减小用户的修改率。越牛B的公司越注重需求，好像我们公司的其中一个项目，就是因为需求不清楚，结果程序人员改到三更，也不能让用户满意，用户的想法太多了，一会儿说东，一会儿说西，需求需用户签字，就是确定某一个版本功能，使用户不能三心二意。
用户不当的需求也要懂得拒绝，就像要一个人唱歌，同时又要他沉默，不可能的是吧，类似这时候的需求要拒绝，反正你应该懂的。
架构设计：
架构设计，这个相当的重要，要明确开发语言，数据库，还有服务器承载的压力，从大的方面出发，大功能实现了，再慢慢细化。
架构方面一定要想得长远一点，整个轮廓比需求还要清晰，其实关键点在于算法，用恰当的算法会为你的项目的性能方面添加不少的亮色，切忌用转几个弯才能到达的算法。
接口文档，这时候需要定好，还有整体的思想框架也需要定义好，需要注意的是，如果在设计过程中，遇到了错误，或者有不当，第一想的是直接修正它，而不是找替代品，代替它，虽然短期效果很好，但长期来看，直接修改，前期会痛苦，后期就轻轻松松，因为有可能后期的修改会与那个错误或不当有关系，如果当时没有直接修改，那这时你就纠结的了。我们公司的另一个项目就遇到这个问题，测试的时候出现了一个功能不合理，他用补的形式，现在就杯具了。
编码
统一标准，统一的格式，规范化的提示语等等
数据库语句尽量精简，例如，一句SQL语句能行的，就不要多条
还有，参数原则，不要写死，要不然后期改动很大，甚至会牵一发而动全身，这就不太好；多用重构的思想。
测试
越早介入测试越好，测试计划——测试用例——执行测试——测试结果——反馈——回归测试
鉴于一二版本的系统很不稳定的，所以这时候对系统的主要功能进行测试就行了
第三版本之后，就进入具体的功能测试，性能测试，越细节越好，如果是网站方面的测试，一般使用的测试工具是Loadrunner.
美工
一般都是用PS的啦，好的图片要不买，要不自己设计，对了，美工做得好的话，会让网站增加不少的色彩，但切记太炫，返归自然，是一种不变的规律。前期的成本投入不多的时候，可以考虑看轻，但也需要让人看得舒服。
Anyway，现在好的产品都是好用+运维的，所以在设计方面好之外，还要加上运维的。还有产品好不好，是用户说了算滴，千万不要想当然，如果满足大部分用户的需求，这产品就差不多了。性能，稳定性都OK的情况下，大胆让用户试一下，后期逐渐改进。
附带资料：
灰度法则：需求度，速度，灵活度，冗余度，开放协作度，创新度，进化度
在研究过程中，腾讯形成了一个“10/100/1000法则”：产品经理每个月必须做10个用户调查，关注100个用户博客，收集反馈1000个用户体验。这个方法看起来有些笨，但很管用。（用户反馈，产品方面的）
清晰、简单、自然、好用的设计和产品，这是人对美最自然的感受和追求。
速度：快速实现单点突破，角度，锐度尤其是速度，是产品在生态中存在发展的根本。（小步快跑，快速迭代）
灵活度：敏捷企业，快速迭代产品的关键是主动变化，主动变化比应变能力更重要。
冗余度：容忍失败，允许适度浪费，鼓励内部竞争内部试错，不尝试失败就没有成功
开放协作度：最大程度地扩展协作，互联网很多恶性竞争都可以转向协作型创新
鉴于我没登录进去查看信息，所以只能模糊地说下我自己的看法，纯属个人意见，关于市场方面的话，我相信，你比我更清楚，应该有一份需求在你手上的，你可以研究一下，再查看市场动态，工作是每个人的必须，提供的这样一个平台，自然有市场，但市场大还是小呢？你是想霸占哪个领域呢？你的特色又在哪里呢？（因为同行毕竟不少）等等，一系列的东西，定位好了，就赶紧行动，行动才是硬道理，在实践在不断地改进，相信会越来越好的，记得反思与总结，最后祝你好运！
标签：style tar color get 使用 strong
原文地址：http://blog.csdn.net/isharestudio/article/details/32731461
