客户对it项目的要求高体现在哪些方面

有人说，我们项目功能稳定不就行了，要什么这文档那文档，需要什么问我就行，都在我脑子里面装着呢。
这只能说是一厢情愿，或者说单纯的站在开发的角度来考虑，而不是站在客户的角度来考虑。

试想，客户领导问客户项目经理：
1、这个项目的架构设计明天汇报下吧。
2、这个项目的性能指标发下吧。
。。。
光有个项目怎么够的，明显处理不了这种场景。

因此，这类资料其实是需要的。而且，越是大的公司，对这类偏展示偏汇报的材料就越有要求。

架构文档相关

技术架构相关

技术组件清单
技术架构图

部署相关

部署单元(服务列表)
逻辑部署图
物理部署图
资源列表(服务器配置、数据库、redis、负载均衡、mq)

性能指标

压测指标

功能模块	并发量	平均响应时间	tps	错误率	备注
用户查询	800	3000ms内	10	<1%
用户新增	600	2500ms内	8	<1%

约束操作

sql约束

最明显的就是数据库权限，为了防止修改数据，大公司基本都不给数据库权限，需要执行sql提交给dba。

有的时候开发任务重，时间紧，或者版本更迭较频繁，sql和功能之间的对应很难精确并及时。
如果有sql权限，那么一切不是问题，报错了，执行下即可。 但是没权限呢? 就要一次性提给dba，如果某一两条sql有问题还可以调整下，再多的话人家就不乐意了，甚至干脆不执行了，那么还能上线不?

服务器约束和变更约束

当然还有服务器约束，例如非变更窗口没有root权限，如果磁盘满了，或者服务需要重启或发布，有权限很好处理，但是没权限就比较麻爪了，需要提紧急变更，关键变更次数是考评指标，还有次数限制。

安全及健康相关

安全漏洞

垂直越权漏洞
水平越权漏洞
swagger漏洞

数据库健康检查

无主键或唯一索引
无效对象
text/blob 大文件对象
外键
索引超量 (单表索引超过5个)
大表(数据量超过一定条数)
cpu(数据库cpu占比)
IO(IOPS使用率大于50%)
长事务
慢查询
dba帐号(指的跨帐号操作)

其他特点

数量大机构少 机构多数量少

数量大机构少：

数量少机构多：
可能因为账户引发一些其他问题。

业务系统多

业务系统多，对项目百分百有影响。

接口改造需要重点考虑兼容

如果是个新接口，功能满足就可以。
如果是个老接口，很多业务系统都在用，很明显让每个业务系统来改是不合适的，因为至少有以下几个问题。
1、沟通成本很高，需要拉通所有系统。
2、业务系统是否有预算及资源可以改造。
3、改造就可能出问题，风险成本及回归测试成本。

所以，进行适配改造是较优方案。实际上，兼容开发有时比完全开发个新功能复杂很多。

方案沟通成本高

每个业务系统的场景可能不同。需要根据场景选择合适的方法，这个沟通很频繁，而且无法量贩。

对接联调成本高

接口文档虽然比较全，但是实际对接中很难说一看文档就直接调通的。尤其较复杂的接口，报错的场景有很多，客户又很难直接理解，一个接口就要支持很多次。
有些场景需要造数据，也是一笔开销。