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