如何评价项目的好坏(从客户角度)
功能:按期,效益,体验,稳定性(性能),扩展
按期完成功能是一定的,不然会被辞退,绩效考核才是最重要的
稳定性的指标:可用性
绩效考核指标:(分钟-故障分钟)/总分钟
一个项目的开发流程:
需求(文档)
->>>原型(需求可行性)
->>>设计(技术选型)(技术,测试人员测试,UI设计) UI,里程碑,原型对客户重要,影响体验
->>>分工开发(分阶段,里程碑,哪个阶段完成哪些东西)
怎样把项目做好(高质量)客户认同
最重要的是要让客户看到项目的可控性,需要做到以下三点
1.需求阶段:
三家公司,都能做到,选哪一个
抓住客户的需求,如何做到
业务决定技术(一个好的架构师很重要)
认同客户想法:
哪些要砍掉,哪些保留,哪个UI适合你
不是只是完成技术任务,那是初级开发人员干的
好的程序员是告诉你需求,自己去处理
2. 原型阶段:
生成草图,可能只是某个控件,如何跳转,布局
理清流程,整个流程过一遍
3. 设计
UI:
用户喜欢,和潮流符合,不落后
动画,特效
技术:
安全性、业务逻辑序列图看得懂
功能可以横向扩展
不会导致系统完全崩溃,如数据库数据丢失
可测试的
做到上面三点,让客户明白团队在项目的每一个环节都把控的很好,也就会放心了。
出故障如何快速解决问题:
按分钟算故障,自己能不能升值很重要
如何避免?
1. 入口校验,数据进入时校验,也就是服务器校验
有人说客户端校验就行,用所谓的提高性能来说话,其实这种说法是大错特错的。
如果一个项目是因为进行了服务器校验拉低性能,那这个项目一点是搞笑的,连代码层面上的故障都不能排除,还能干什么呢?
或者说,明知道错误的数据很有可能容易出现故障,可以及时处理,但是就是不处理,这是多么的愚蠢,难道要等到以后出错了才处理吗?
2. 异常:日志,可查
日志是一定要有的,在可能出错的地方都给打算日志。
3. 项目流程方案部署文档清晰,知道是哪个地方有问题,部署架构图一定要有
部署架构图有什么用?能让我们了解这个项目的架构,通过日志能够知道定位出错位置
4. 监控系统,配合各种指标,预警:出错能够提醒,访问量爆增,错误日志一直在增加
CPU占用率飙升,磁盘空间达到90% ,JDK FULL GC消耗时间长,响应时间变长
用户数新增的减少(注册故障)
如何监控:涉及调用链,每个接口的调用数记录,智能拦截IP,每个过程跟踪
记得开会的时候有人说专门找人定时查看日志,Leader反问:你觉得可能实现吗?他自己都笑着说不能。
所以说监控系统是很重要的,大家很容易忽略
如何快速解决?
1. 制定应急方案,备份:每个部分都有备份(热备),可以回滚
灰度发布,有100万,用1万用户用到新发布的版本上,其他用旧的,几天没问题,转为50%,最后再100%
2. 异常日志:能打的都打,日志不仅要包含业务的,还有查看与sql连通日志 ,GC日志
我们最常见的就时听到伙伴说在我这里还跑的好好的,到你那里就不行了。
不允许e.printStack();
3. 代码
用户使用者范围
解决使用者的什么问题
讲解项目内容是有方法的,不要这讲一块,那讲一块,不仅别人不懂,连自己都搞懵了。
原文:http://www.cnblogs.com/zourui4271/p/4990128.html