• 问题：人员未能按计划到位

• 原因分析：

  1.人员在其他项目组，无法撤离
  
  2.项目承接时低估了客户对于现场的执着
  

• 解决方案：

  1.拒绝驻场
  
  2.明确驻场时，明确人员调动计划
  

• 问题：代码质量太差

• 原因分析：

  1.缺乏技术经验
  
  2.缺乏代码规范
  
  3.缺乏最佳实践指导
  
  4.缺乏代码reiwew
  

• 解决方案：

  1.明确技术经理职责和人员
  

# 研发中心合作分析汇报

一、研发中心问题分析

以下分析源于实际工作。

1: 研发中心负责人关注人员买卖，而非项目建设目标

1. 研发中心的负责人不管项目质量和进度，一般理由是项目多，或团队自管理，实际效果基本就是没管理，没进度检查，没优先级协调。

   主要体现在A2项目后期

2. 包人模式下，不考虑实施效果，导致项目成本失控。

   例如在A1项目中，研发中心实际人力投入远远超过计划。

3. 按项目结算，只是控制人头投入，不重视进度，导致整个项目进度失控。

   当前的A3项目中，研发中心的开发进度已经严重延期。

2: 员工自己的工作目标太低，只懂得执行（具体工作），不懂得追求项目效果（客户价值）

1. 开发人员不学习业务，不知道自己在做的是什么。

   主要体现在A1项目，再A2项目中改进不少。但是，还是为了完成开发任务而学习业务，而不是为设计出更好用的产品 或 更减少开发量而学习。

2. 优先是做开发，而不是评估设计是否合理。

   各个项目都有体现，目前通过加强沟通、业务考核能够缓解一部分，但是很容易造不必要的投入.
   在项目售前工作量评估时，也出现过保守评估，导致报价是实施部门估算的2～3倍。
   更多时候愿意充当体力工作者，而不是脑力工作者。

3: 不是合格的团队，只是一群在一起完成工单的人

1. 团队内部缺乏必要交流。

   研发中心技术负责人来实施部门接受业务，回去做其他项目，内部不做任何交接，另一位交接人一无所知，浪费了宝贵的时间。

2. 缺乏技术领头人，技术问题无法解决，小问题大成本。

   定时任务、LDAP这类问题容易出现严重的超支超时。

3. 缺乏业务领头人，业务知识零散，无人能贯穿整个业务，更别说能够进行深入业务的设计。

   以前合作过一个团队，一名中级测试可以将复杂业务搞懂，解答开发问题。
   A1项目最为明显，B1项目基本上由实施部门控制业务，A2项目有所改善，A3项目又差了。

4. 合作力差。

   顺手能解决的问题，只要不是工单上的任务，就不会解决，轻易转给其他研发中心自己的开发或回给实施部门。

4: 个人能力普遍较差

1. 开发技能一般，略微复杂的业务，实现起来思路不清楚，需要反复修改，成本超支太多。

   A1项目的复杂报表、复杂业务基本重新写。
   并发处理、业务同步接口等技术性比较强的，个别中级可以，大部分中级开发无法胜任。
   A2项目的LDAP同步逻辑比一般项目复杂，修改了1个月。
   B1项目项目核心业务逻辑无法修改。
   实施部门也招聘过一个高级开发，在复杂业务逻辑上思路不清楚，直接开除。
   有时候技术解决方案只能针对一个具体问题，相似问题需要理解并思考，往往不会解决，需要再次提供解决方案。

2. 沟通能力差，一般的开发人员普遍都比较宅，研发中心开发团队尤其明显，不回答，不交流，不汇报。

   任务时间到了，需要主动问才有结果，不会提前沟通，解决遇到的阻碍。

3. 缺乏项目服务意识。

   客户急，实施部门实施团队急，研发中心团队不急。紧急问题约定好下班前交付，下班没有交付，再联系已经走人。

二、研发中心团队问题原因分析及建议

1: 脱离客户现场，缺乏项目使命感、责任感。

实施部门员工也不是一开始就有责任感的，在客户现场能够感受到不一样的气氛，客户的责骂也是促使成长的必要动力。
建议：加强项目使命感的宣传，进入项目开发不仅仅是一项工作，也是一次与客户共同成长的机会。

2: 结算容易，缺乏竞争，缺乏危机感。

包人是稳稳的结算，实施部门项目高峰期，人员也没有其他选择，只能选择研发中心，所以结算根本不愁。
项目结算和执行人员估计是不挂钩的，做好做坏影响不大，就算是项目结算，没有很好的员工利益绑定，也难以激发员工动力。
建议1：拆分为2～3个独立中心，实施部门可以发布项目，内部采用竞标机制，通过费用、人员、时间、质量几个方面考核，优胜者得标。
建议2：引进2～3个社会研发团队，高并发可以雇佣，平时也可以衡量内部报价的高低。
建议3：框架合同增加延期、低质量等扣款条例。

3: 缺乏长远规划。

实施部门团队重视长远规划，参加项目不是完成工作，而是实现长远目标的一个必要步骤。
研发中心如果只重视结算，通过高流动弥补项目空缺，长期容易产生疲劳，做项目容易混日子。

建议：加强项目使命感的宣传，进入项目开发不仅仅是一项工作，也是一次与客户共同成长的机会。

4: 低级开发太多，缺乏高级人员。

传帮带很重要，缺乏领路人，自行摸索费时费力，目前据了解只有研发中心管理者在做传授，但这远远不足，研发中心技术负责人更倾向于自己完成，并没有很好的担当领路人的角色，甚至与研发中心个别开发不睦，造成很多不必要的浪费。

建议：最少一名高级开发，并且愿意带领大家前进。初中级日常需要有人指导工作，避免大量低级错误，减少摸索造成的浪费。

三、实施部门招聘还是继续与研发中心合作

总体倾向与保留与研发中心的合作

1: 研发中心合作利大于弊

全年难免会出现空档期，以项目合作的方式，可以有效减少空挡期的损失，通过努力可以提高研发中心的效率，两者比较，合作优势大于本地扩招。

2: 研发中心有上升的空间

开发虽然差，但是态度可以，也比较努力，只是经验不足，随着项目增加，差距在缩小。
实施部门通过努力，可以有效提升研发中心工作效率。
制度问题公司一直在优化，会越来越好。
合作是趋势，与研发中心合作不顺，也有很多实施部门团队自身没有意识和改正的问题，已着力解决自身问题，没必要因噎废食。

3: 实施部门重点业务、开拓、现场服务，大规模作业可以远程。

未来仍是以开拓、现场服务、口碑为主，大规模作业及管理能外包就外包。

4: 存在部分适合实施部门实施的项目。

B2项目现场驻场的项目，但不多，以后争取异地开发。
客户不要求驻场的项目，可以远程。
以上项目可以会占用实施部门大部分人力，其他项目就需要研发中心团队大力支持。

四、研发中心定价

研发中心项目售前成本估算约为实施部门报价的2～3倍，实际实施约为1.5倍左右，并且严重依赖实施部门需求及测试，等于缺乏业务能力和自我质量保证，建议规格调整如下：
高级：说明：能力可以，独立实施能力强，但缺乏带队能力
中级：能力一般般，主要实施简单逻辑，复杂逻辑成本超值严重
初级：说明：要靠人带，产量低、质量差、不考虑购买，除非都是复制工作

乙方角度 针对甲方

• 项目人员
  • 明确双方以里程碑任务为目标，甲方不干预乙方人力调度
• 项目驻场
  • 乙方根据里程碑计划，视情况安排人员到现场调研需求、支持上线。
  • 乙方不在甲方现场开发。
• 项目计划
  • 提供甲方项目里程碑计划
  • 里程碑计划发生重大变更，会提供甲方新的里程碑计划
  • 里程碑计划中明确甲方提交关键成果物的时间，并明确延期造成的影响及责任
  • 里程碑计划中明确甲方关键活动中负责人的职责和参与时间，并明确延期造成的影响及责任
• 项目模版
  • 项目所有模版以乙方模版为准
  • 项目启动，乙方项目经理提供模版给甲方确认
• 业务需求
  • 提供项目需求文档,并与甲方召开冻结会议，让甲方签字确认
  • 提供设计线框图,让甲方冻结并签字确认
  • 提供高保真页面Demo,让甲方冻结并签字确认
• 非功能性需求
  • 满足项目业未来1年的业务性能要求。
  • 提供我司的页面设计规范，并让甲方确认。
  • 默认不提供安全漏洞修复工作
  • 默认不提供开发规范报告
  • 默认不提供数据备份
  • 默认不提供数据迁移
  • 默认不提供测试环境、生产环境的服务器搭建
  • 默认不提供上线操作
• 需求变更
  • 需求变更优先拒绝
  • 无法拒绝的需求变更记录到清单中，在UAT通过后选择修正。
  • 未来会造成不确定因素的变更，通过商务直接拒绝
• 项目技术架构
  • 我方定义架构设计文档，甲方确认
• 接口设计
  • 提供独立的接口设计文档
  • 明确甲方|第三方提供接口的时间、数据、联调环境，并告知延期造成的后果及责任。
  • 明确甲方提供对接接口的真实测试数据
• 配置管理
  • 代码验收前，统一提交给甲方
  • 不支持在开发阶段提交代码到甲方仓库中
• 项目演示
  • 项目阶段启动后，每2周演示一次项目开发成果，要求甲方业务负责人参加，并明确提出项目问题。
• 测试报告汇报频率
  • UAT启动前，提供一次集成测试报告
  • 上生产前，提供一次集成测试报告
• 上线标准
  • 无二级Bug为上线标准
• BUG等级定义
  • 依据乙方的Bug定义标准
  • 每个Bug等级的评定权归乙方所有
  • 存在争议的Bug，结项前做一次协商，确定修改范围。
• UAT阶段 Bug修复时间要求
  • 一级、二级Bug本周内修复
• 试运行阶段 Bug修复时间要求
  • 一级Bug 24H内修复
  • 二级Bug 5个工作日内内修复
• 缺陷提交方式
  • 甲方所有提出的问题（含Bug、改进、新增）通过乙方《问题管理表》统一提交给乙方项目经理
• 测试数据
  • 测试用例数据要求以真实数据为准，由甲方提供
• 测试报告
  • 提供集成测试报告
• 上线规范
  • 提供甲方可执行程序包
  • 提供上线初始化脚本
• 上线保障
  • 上线第二天，现场进行运维保障1天。
• 代码规范
  • 符合乙方的代码规范检查
  • 符合甲方的代码注释率标准（30%）
• 项目交接
  • 按计划甲方需要提供交接人员参与交接，并保证交接时间
  • 交接完毕后，以交接邮件为准
• 项目运维
  • 项目正式上线后，提供1个自然月内，累计40H的运维服务
• 验收标准
  • 完成合同要求的工作内容
  • 提交所有合同约定的成果物
  • 上线稳定运行5个工作日
  • 项目交接完成

PS1: 甲方需要提供交接成果物的样例
例如：需求文档模版、上线初始化脚本的模版、测试用例、测试报告的模版

关于Scrum Backlog、迭代在开发中的使用

前提：

• 需求已经冻结

• 里程碑计划确认

• 架构设计完成

• 开发环境搭建完毕

现状：

• 启动明确每月的工作目标

• 明确当前2周内的工作目标及工作细节

• 每周开发任务沟通Jiar分配给开发人员

• 每周的Bug通过Jira工单分配给开发人员

• 每周的周会，回顾当周任务的完成程度，延期的推迟到下周

• 当周任务根据里程碑计划明确月目标

• 质量标准是每周冒烟通过

• 开发两周给客户做一次演示，客户验收或者带问题的验收，目的是确保开发方向没有与预定存在偏差或者严重失误，开发中途不接受变更。

现状由来：

• 项目管理者关注任务的完成程度，对业务熟悉度不高

现状问题：从产品经理角度看

• 缺乏完整的Backlog

• 缺乏以业务功能为核心的迭代规划

• 工作执行缺乏以Backlog为核心，而不是以任务为核心，容易造成无效任务，或者遗漏任务

• Bug修复等级，缺乏从产品角度实施

• 总体感觉是在完成任务，不是在做产品，类似于外包开发的感觉

• 迭代长度过长（月），起始&终止 不明显，感觉不到一个迭代的成就感和紧迫感。

• 缺乏冲刺，容易延期。

• 缺乏每日例会，产品负责人缺乏与开发人员的沟通，日常开发沦落成技术开发，而非产品实现。典型现象是开发人员不知道自己做的业务和目标亮点

• 缺乏在整个产品实施中，追求更好的冲动，及时在成本、时间优先的情况下也可以出合适的改变，而非遵循既定流程一路到底。

• 以验证最初目的的演示，与追求更好的产品理念不符合。

• 每周、每月迭代的成果物与用户故事、业务目标没有明显的关系。

改进方案

• 始终维护完整的Backlog

• 按照业务优先级，划分Backlog，通过迭代来实现

• 迭代中实现Backlog，顺序依赖Backlog的优先级

• 随时调整产品远景，通过Backlog优先级体现，可以与迭代中的Backlog替换。

• 迭代中的Backlog最好能够闭环成为一个独立的业务模块。

• 减少迭代包含的Backlog数量，做到小步快跑。

• 产品负责人负责对产品定位、功能的全部把控

• 每一次迭代是完成一个功能目标，可以是一个或者一组用户故事

• 迭代最好的成果物是对应Backlog的可运行产品，而不是被关闭了的一堆工单

Markdown 语法和 MWeb 写作使用说明

Markdown 的设计哲学

Markdown 的目標是實現「易讀易寫」。
不過最需要強調的便是它的可讀性。一份使用 Markdown 格式撰寫的文件應該可以直接以純文字發佈，並且看起來不會像是由許多標籤或是格式指令所構成。
Markdown 的語法有個主要的目的：用來作為一種網路內容的寫作用語言。

本文约定

如果有写 效果如下：， 在 MWeb 编辑状态下只有用 CMD + 4 或 CMD + R 预览才可以看效果。

标题

Markdown 语法：

# 第一级标题 `<h1>` 
## 第二级标题 `<h2>` 
###### 第六级标题 `<h6>` 

效果如下：

第一级标题 <h1>

第二级标题 <h2>

第六级标题 <h6>

强调

Markdown 语法：

*这些文字会生成`<em>`*
_这些文字会生成`<u>`_

**这些文字会生成`<strong>`**
__这些文字会生成`<strong>`__

在 MWeb 中的快捷键为： CMD + U、CMD + I、CMD + B
效果如下：

这些文字会生成<em>
这些文字会生成<u>

这些文字会生成<strong>
这些文字会生成<strong>

换行

四个及以上空格加回车。
如果不想打这么多空格，只要回车就为换行，请勾选：Preferences - Themes - Translate newlines to <br> tags

列表

无序列表

Markdown 语法：

* 项目一 无序列表 `* + 空格键`
* 项目二
* 项目二的子项目一 无序列表 `TAB + * + 空格键`
* 项目二的子项目二

在 MWeb 中的快捷键为： Option + U
效果如下：

• 项目一 无序列表 * + 空格键
• 项目二
• 项目二的子项目一 无序列表 TAB + * + 空格键
• 项目二的子项目二

有序列表

Markdown 语法：

1. 项目一 有序列表 `数字 + . + 空格键`
2. 项目二 
3. 项目三
1. 项目三的子项目一 有序列表 `TAB + 数字 + . + 空格键`
2. 项目三的子项目二

效果如下：

1. 项目一 有序列表 数字 + . + 空格键
2. 项目二
3. 项目三
4. 项目三的子项目一 有序列表 TAB + 数字 + . + 空格键
5. 项目三的子项目二

任务列表（Task lists）

Markdown 语法：

- [ ] 任务一 未做任务 `- + 空格 + [ ]`
- [x] 任务二 已做任务 `- + 空格 + [x]`

效果如下：

• 任务一 未做任务 - + 空格 + [ ]
• 任务二 已做任务 - + 空格 + [x]

图片

Markdown 语法：

![GitHub set up](http://zh.mweb.im/asset/img/set-up-git.gif)
格式: ![Alt Text](url)

Control + Shift + I 可插入Markdown语法。
如果是 MWeb 的文档库中的文档，还可以用拖放图片、CMD + V 粘贴、CMD + Option + I 导入这三种方式来增加图片。
效果如下：

MWeb 引入的特别的语法来设置图片宽度，方法是在图片描述后加 -w + 图片宽度 即可，比如说要设置上面的图片的宽度为 140，语法如下：

链接

Markdown 语法：

email <[email protected]>
[GitHub](http://github.com)
自动生成连接  <http://www.github.com/>

Control + Shift + L 可插入Markdown语法。
如果是 MWeb 的文档库中的文档，拖放或CMD + Option + I 导入非图片时，会生成连接。
效果如下：

Email 连接： [email protected]
连接标题Github网站
自动生成连接像： http://www.github.com/ 这样

区块引用

Markdown 语法：

某某说:
> 第一行引用
> 第二行费用文字

CMD + Shift + B 可插入Markdown语法。
效果如下：

某某说:

第一行引用
第二行费用文字

行内代码

Markdown 语法：

像这样即可：`<addr>` `code`

CMD + K 可插入Markdown语法。
效果如下：

像这样即可：<addr> code

多行或者一段代码

Markdown 语法：

```js
function fancyAlert(arg) {
    if(arg) {
    $.facebox({div:'#foo'})
    }

}
```

CMD + Shift + K 可插入Markdown语法。
效果如下：

function fancyAlert(arg) {
    if(arg) {
    $.facebox({div:'#foo'})
    }

}

顺序图或流程图

Markdown 语法：

```sequence
张三->李四: 嘿，小四儿, 写博客了没?
Note right of 李四: 李四愣了一下，说：
李四-->张三: 忙得吐血，哪有时间写。
```

```flow
st=>start: 开始
e=>end: 结束
op=>operation: 我的操作
cond=>condition: 确认？

st->op->cond
cond(yes)->e
cond(no)->op
```

效果如下（ Preferences - Themes - Enable sequence & flow chart 才会看到效果 ）：

张三->李四: 嘿，小四儿, 写博客了没?
Note right of 李四: 李四愣了一下，说：
李四-->张三: 忙得吐血，哪有时间写。

st=>start: 开始
e=>end: 结束
op=>operation: 我的操作
cond=>condition: 确认？

st->op->cond
cond(yes)->e
cond(no)->op

更多请参考：http://bramp.github.io/js-sequence-diagrams/, http://adrai.github.io/flowchart.js/

表格

Markdown 语法：

第一格表头 | 第二格表头
--------- | -------------
内容单元格 第一列第一格 | 内容单元格第二列第一格
内容单元格 第一列第二格 多加文字 | 内容单元格第二列第二格

效果如下：

删除线

Markdown 语法：

加删除线像这样用： 删除这些

效果如下：

加删除线像这样用： 删除这些

分隔线

以下三种方式都可以生成分隔线：

***

*****

- - -

效果如下：

MathJax

Markdown 语法：

块级公式：
$$	x = \dfrac{-b \pm \sqrt{b^2 - 4ac}}{2a} $$

\\[ \frac{1}{\Bigl(\sqrt{\phi \sqrt{5}}-\phi\Bigr) e^{\frac25 \pi}} =
1+\frac{e^{-2\pi}} {1+\frac{e^{-4\pi}} {1+\frac{e^{-6\pi}}
{1+\frac{e^{-8\pi}} {1+\ldots} } } } \\]

行内公式： $\Gamma(n) = (n-1)!\quad\forall n\in\mathbb N$

效果如下（Preferences - Themes - Enable MathJax 才会看到效果）：

块级公式：
$$ x = \dfrac{-b \pm \sqrt{b^2 - 4ac}}{2a} $$

\[ \frac{1}{\Bigl(\sqrt{\phi \sqrt{5}}-\phi\Bigr) e^{\frac25 \pi}} =
1+\frac{e^{-2\pi}} {1+\frac{e^{-4\pi}} {1+\frac{e^{-6\pi}}
{1+\frac{e^{-8\pi}} {1+\ldots} } } } \]

行内公式： $\Gamma(n) = (n-1)!\quad\forall n\in\mathbb N$

脚注（Footnote）

Markdown 语法：

这是一个脚注：[^sample_footnote]

效果如下：

这是一个脚注：¹

注释和阅读更多

Actions->Insert Read More Comment 或者 Command + .
注 阅读更多的功能只用在生成网站或博客时，插入时注意要后空一行。

TOC

Markdown 语法：

[TOC]

效果如下：

[TOC]

前提（不可变）

• 项目合同固定

• 我方人员能力=中级Java开发

• 要求驻场开发

背景（起始状态）

• 项目规范流程未裁剪

• 甲方流程未明确告知

• 时间要求非常短（2个月）

• 没有全新技术

• 新业务，难度一般

造成超值的主要原因

原因分析

成本计算工时：

  总成本 = 各个阶段投入之和 = 需求阶段投入（20%） + 设计阶段投入（10%） + 开发阶段投入（40%） + 测试阶段投入（10%） + UAT阶段投入（10%） + 上线运维接口投入（5%） + 管理投入（5%）

项目总成本

 75k

需求阶段投入：

 主要人员: 业务负责人
 主要成本预算：总成本20%，实际费用15k，作业标准1K/天
 主要工作内容：明确作业范围、明确业务流程、明确客户价值点
 作业参考时间：可用15天，实际8天（3+5）
 公司要主要成果物：SOW、BRD、整体架构PPT、线框图、业务流程、实体关系图、用例图
 成果物作业时间: 5天 
 精简策略：①业务专家要求熟悉业务领域，从客户价值点出发，引出必要的需求，拒绝镀金。②收集业务场景，而非客户设计，减少投入的偏差。
 **文档策略**：①相似案例减少文档编写工作。

设计阶段投入：

 主要人员: 架构师+开发组长
 主要成本预算：总成本10%，实际费用7.5k，组长作业标准0.8K/天，架构师单价1.5k/天
 主要工作内容：全业务实现逻辑推导、重点业务实现逻辑明确、重点业务逻辑传授开发人员
 作业参考时间：可用10天，实际-天。
 公司要主要成果物：整体架构PPT、功能详细设计、接口定义
 成果物作业时间: 5天 
 本项目领域：接口业务逻辑，外部服务器S3调用逻辑、Redis使用逻辑
 参考领域：系统接口业务逻辑，系统定时任务业务逻辑，库存并发业务逻辑，SSO相关实现、工作流
 起步工作：SVN、选择开发框架、业务培训、工作场地组织、Demo编写、开发环境确认、开发规范确认
 起步成本：5天
 **精简策略**：①项目尽量大一些，太小起步成本很高 ②周期长一些，前期安排一名高级开发做一些准备工作。

甲方角度

• 项目人员
  • 提供项目所有人员名单、联系方式、简历
  • 项目人员非工作日请假，要求通过甲方PM的审批
  • 项目人员离职，需要提前10天通知甲方PM
• 项目驻场
  • 优先驻场开发
• 项目计划
  • 提供甲方项目里程碑计划
  • 项目计划发生变更，需要周知甲方
  • 包括接口联调计划
  • 包括关键成果物甲乙双发最终提交及确认时间
• 业务需求
  • 提供项目需求文档
  • 需求文档以用户故事形式描述业务场景
  • 满足甲方需求文档格式
  • 提供设计线框图，包含所有页面及关键提示信息
  • 提供高保真页面Demo
• 非功能性需求
  • 满足项目业未来3年的业务性能要求
  • 在最大预期数据量下进行压力测试。
  • 满足甲方页面设计规范
• 代码可维护性
  • 采用Log4j日志格式
  • 对于所有的异常必须全部打印到日志上
  • 对于交易等关键数据，要求打印到日志上
  • 代码命名规范符合甲方命名规范要求
  • 接口的数据必须记录原始接收和发送数据，并且独立日志
• 需求变更
  • 需求问冻结的需求讨论结果应整合到需求文档中，并提供给甲方PM
  • 需求冻结后的需求变更，应整理到需求变更清单中，并提供给甲方PM
• 项目技术架构
  • 提供架构设计文档，满足甲方架构设计文档格式要求
  • 满足甲方技术路线
• 接口设计
  • 提供独立的接口设计文档
  • 包括接口的命名、使用业务场景、接口输入输出定义、真实样例数据
  • 包括接口异常下的流程设计
  • 提供接口的单元测试用例
• 配置管理
  • 日常开发代码提交到甲方的配置仓库中
• 项目演示
  • 项目阶段启动后，要求每2周演示一次项目开发成果
• 测试报告汇报频率
  • UAT启动后，要求乙方测试负责人，每日汇报所有Bug修复情况
• 上线标准
  • 上线标准不等同于最后交付验收的标准
• BUG等级定义
  • 甲方提出
  • 每个Bug等级的评定权归甲方所有
• 缺陷修复时间要求
  • 一级缺陷要求当日内修复并完成上线
  • 二级缺陷要求次日内修复并完成上线
  • 其他缺陷要求5日内修复并完成上线
• 缺陷管理
  • 所有问题要求登陆到甲方系统的Jira上
  • 修复完毕的问题要求将更新甲方的Jira
• 安全性测试
  • 满足甲方安全性测试标准
  • 通过甲方安全性测试
• 集成测试用例
  • 需要覆盖需求文档内容
  • 提供场景化的测试用例
  • 测试用例数据要求以真实数据为准
• 测试报告
  • 提供功能性集成测试结果
  • 提供性能测试结果
  • 提供安全性测试结果
• 上线规范
  • 遵循甲方上线流程
  • 符合甲方的部署方式要求
  • 提供上线初始化脚本
• 上线支撑
  • 上线工作要求开发负责人到现场支撑
• 上线保障
  • 上线第二天，要求负责人现场进行运维保障0.5天。
• 代码规范
  • 符合甲方的代码规范检查
  • 符合甲方的代码命名规范
  • 符合甲方的代码注释率标准
• 技术框架
  • 满足甲方的技术框架规范
• 技术评审
  • 满足甲方技术专家的评审（明确的标准之外的内容）
  • 提供5人日技术评审意见修改的工作量
• 迭代优化
  • 项目UAT阶段要求执行2轮迭代优化
  • 预计每轮在2周，每次迭代工作量10人日，请包含在报价中
  • 迭代优化内容由甲方PM确定并发布
• 项目交接
  • 项目主力开发人员负责交接
  • 交接需要由甲方技术负责人确认
• 项目运维
  • 项目正式上线后，提供3个自然月的运维服务
  • 运维包括30人日的工作内容。
• 验收标准
  • 达成合同要求的内容
  • 上线稳定运行30个工作日
  • 满足安全漏洞检查
  • 修复所有发现的bug（1、2、3级）
  • 项目交接完成

PS1：防止事情拖沓，可以增加记分机制：

• 项目款中10%用于记分机制
• 总分100分，每次出现延期或者违约扣1分
• 95～100分之间，不扣款
• 95以下扣款，每扣一份扣20%的费用
• 90%分的全部扣除费用

PS2: 甲方需要提供交接成果物的样例
例如：需求文档模版、上线初始化脚本的模版、测试用例、测试报告的模版

项目问题
代码质量偏低

• 缺少调试Log

• HardCode导致测试环境可以，生产不行

• 夸JVM的Redis使用问题多多

• 接口调试没有考虑异常情况下的HTTP CODE

回顾历史项目也存在类似问题

• 接口调试时间超长

• 后台任务反复错误

• 多人并发库存反复错误

综上，结合项目自身人员问题，缺少技术经理的岗位

技术经理

• 提供技术框架

• 对业务的实现进行代码review

• 提供复杂业务下的最佳实践