项目阶段汇报用不用写？该怎么写?这里有个模板大家都说好，送给您

2020-04-08 15:02:02 浏览数 (1)

一、项目汇报是论功行赏的依据

先来回答第一个问题，用不用写？回答：不仅要写！更要认真写！ ^0^

项目汇报是工作成果的最好展现方式，没有之一。 即能展示员工在项目中的辛苦付出，又能让老板用最快捷省时的方式了解项目的进度和可能潜在问题，及时发现并解决。

说的更直白点，项目汇报写的好不好，很大程度上是论功行赏依据。

敲黑板，这里要考！！~

因此！如果你和同事一起做项目，在项目结尾收工输出项目报告时，如果你同事做的少，但却要求项目报告他来写，你可要留意了：一是项目报告你一定要看一遍，是否有抢功隐劳的问题；二是这样的同事有抢功劳的嫌疑和心机，以后的合作你可要留意了。

我就遇过到这样的同事，还是跨部门的同事。

记得当时两个部门合作做一个比较大性能优化的项目。在项目结束要出项目报告向老板做汇报，有2种方式：

  • 会上各部门做自我工作汇报
  • 汇总到一起，由会议发起人统一汇报

这2种形式，我都比较认可，但问题就出在第2个方式上。会议发起人「也是项目一员」在汇总报告时，竟然不是将大家的PPT结合在一起，而是把大家的内容整合删改后，融合到他自己的PPT内，淡化其它部门的辛苦付出。最后，年终时他们部门因为项目得获年度最佳优秀团队，而其它项目成员只是以项目组的方式得获项目奖。

这里抛开老板的得人识人管理问题，单单这位同事的行为是非常不地道的。不仅仅是在个人影响力，还在公司内部文化氛围塑造上都是“杀鸡取卵”式的毒瘤。

二、好的项目报告是以老板为视角，而不是以写作能力为导向

什么是好的项目报告？

图文并茂？用词专业？数据详实可靠？遵循文档标准格式？ 都不是！

这些只是好的文档所需要具备的基本元素，而不是项目报告！举个例子：

如图是一篇项目报告目录，

文章框架专业吗？专业!

case 详实有效吗？当然！

遵循WORD文档标准格式规范了吗？显然！

用词专业吗？必须的，满满都是专业词汇！

是一篇好的项目报告吗？ 对不起，不是！！

为什么呢？很简单，写报告的人没有真正的 换位思考

换位思考也是一项很重要的能力！

想想看，如果你是老板，你想在项目报告中看见什么？

是的！结果！ 我只需要看到结果就行了。其它的专业性、数据有效性、文档传承性等等，这是你应有的保证和专业范畴。我是老板，不些不是我要关心的！

提供一篇大家都说还算好的项目报告。敬请查阅，如有收获，敬请关注。

三、项目报告模板

[START] 我是分隔线

  • 一、项目汇报是论功行赏的依据
  • 二、好的项目报告是以老板为视角，而不是以写作能力为导向
  • 一、压测结果
  • 二、二期计划
  • 三、结果概览
  • 1、概述
    • 1.1 测试目标
    • 1.2 名词解释
  • 2、压测环境说明
    • 2.1 环境配置
    • 2.2 测试方案
  • 3、压测结果
    • 3.1 生产 Tomcat 环境压测结果
    • 3.2 生产 Nginx Proxy 环境压测结果
    • 3.3 生产 Nginx 转发 Tomcat 环境压测结果
  • 4、其它
    • 4.1 压测过程中的配置优化项
    • 4.2 压测过程中遇到的问题
    • 4.3 建议
  • 5、附件

【阶段报告】Nginx & Tomcat 压测性能报告

一、压测结果

project

TPS

ResponseTime

Error

Tomcat

1800

0.1-0.6s

0

Nginx

8000

0.15s

0

Nginx To Tomcat

2000

0.5s

0

二、二期计划

二期计划

开始时间

预计耗时

验证纵向扩容后的效果

2020.04.02

3天

研究 TPS 一直上不去的“问题”

2020.04.07

暂没找到问题，暂规划5天

DB 类组件压测

和 DBA 沟通协调后同步安排

配置优化测试

DB 类组件压测结束后安排

三、结果概览

数据繁多，截图不在报告中体现，有需要请随需查看附件

压测过程明细如下

1、概述

XX业务2C场景需求日益变强，对并发服务的稳定性要求越来越高，了解当下生产环境软硬件配置最大承载，摸底业务服务上限越来越重要且迫在眉捷。

1.1 测试目标

  • 了解生产技术栈裸框架最大承载上限
  • 为业务横/纵扩容提供数据支持
  • 优化生产服务参数、系统配置

1.2 名词解释

缩写

名词解释

RT

请求响应时长(Respon Time)

EP

错误率(Error Percentiles)

SL

服务器负载(Server Loader)

NETSTAT

服务器TCP各状态统计

TPS

服务器每秒处理事务数(Transactions Per Second)

2、压测环境说明

受压环境系统、软件配置和生产保持一致，4台压测机，1台受压机

2.1 环境配置

ip

配置

应用

角色

10.1.ip.39

8c16g

Docker * 4

受压环境

10.1.ip.41

8c16g

jemter

主压测机

10.1.ip.42

8c16g

jemter

压测机

10.1.ip.43

4c8g

Docker * 2

受压环境

10.1.ip.44

8c16g

jemter

受压环境

10.1.ip.45

8c16g

jemter

受压环境

2.2 测试方案

  1. 找出压力上限位: 压测机使用生产环境配置，依次调高压测机线程数，直至压测结果出现 ERROR。分别记录出现ERROR前的配置(A)和 0.01% ERROR率的配置(B)
  2. 压测 8C16G硬件 (A) 压测配置
  3. 压测 8C16G硬件 (B) 压测配置
  4. 压测 16C16G硬件 (A) 压测配置
  5. 压测 16C16G硬件 (B) 压测配置

3、压测结果

3.1 生产 Tomcat 环境压测结果

  • 重点

TPS

ResponseTime

Error

1800

0.1-0.6s

0

3.2 生产 Nginx Proxy 环境压测结果

  • 重点

TPS

ResponseTime

Error

8000

0.15s

0

3.3 生产 Nginx 转发 Tomcat 环境压测结果

  • 重点

TPS

ResponseTime

Error

2000

0.5s

0

4、其它

4.1 压测过程中的配置优化项

优化项

效果

JAVA_OPTS

暂无效，有待进步测试

worker_processes

暂无效，有待进步测试

ulimit

有效，建议做成默认系统镜像

net.ipv4.tcp_tw*

暂无效，有待进步测试

maxThreads

暂无效，有待进步测试

maxThreads

暂无效，有待进步测试

connectionTimeout

暂无效，有待进步测试

4.2 压测过程中遇到的问题

遇到的问题

处理

压测机负载爆炸

已解决

TPS 一直上不去，但压测机和受压机负载刚过 50%

有待进一步测试

某台压测机频繁关机

已解决

压测环境和生产环境配置不同步

已解决

配置优化后，TPS反而降低

有待进一步测试

所有机器在同一台宿主机上

待解决

4.3 建议

暂无，二期结束后给出。

5、附件

内容: 每次压测报告及数据截图附件目录及命名方式:

代码语言：javascript复制
result
├── 16C16G
│   ├── 优化前
│   │   ├── nginx-1000
│   │   ├── nginx-2000
│   │   ├── nginx2tomcat-1000
│   │   ├── nginx2tomcat-2000
│   │   ├── tomcat-1000
│   │   └── tomcat-2000
│   └── 优化后
│       ├── nginx-1000
│       ├── nginx-2000
│       ├── nginx2tomcat-1000
│       ├── nginx2tomcat-2000
│       ├── tomcat-1000
│       └── tomcat-2000
└── 8C16G
    ├── 优化前
    │   ├── nginx-1000
    │   ├── nginx-2000
    │   ├── nginx2tomcat-1000
    │   ├── nginx2tomcat-2000
    │   ├── tomcat-1000
    │   └── tomcat-2000
    └── 优化后
        ├── nginx-1000
        ├── nginx-2000
        ├── nginx2tomcat-1000
        ├── nginx2tomcat-2000
        ├── tomcat-1000
        └── tomcat-2000
腾讯云测试服务 nginx tomcat 容器镜像服务 rubyonrails

0 人点赞