

首页  思维导图  详情



IT技术团队项目管理流程

2022-06-08 16:32:39   2  举报





AI智能生成

IT技术团队项目组团队管理项目管理流程

项目管理

项目流程

IT技术团队

人员管理

管理

模版推荐

作者其他创作

大纲/内容

项目规划

整理工作规划与项目阶段、历程碑等

需求分析：确定用户业务目标

补齐追获材料

推进任务

催进度、同步消息

阶段演示、里程碑验收

项目管理

架构

明确架构理念

明确架构风格（DDD六边形架构）

明确各中间件及组件

技术选项

（不需要自己培训）    选择第三方大众熟悉有限

 （dapper、hibernate、hibernate缩小老手和新手差距，防止太大差异）     选择兼容性差异好的

代码管理

vs装企业版，在做功能时参考代码图，看是否清晰

代码

规范

项目命名

微服务命名

镜像命名

容器命名

代码规范

统一标题、分类、对应标志、内容等，方便查找与统计分类等。     日志规范

（使用后要关闭所有应用再离开服务器）   服务器使用规范

代码检查

技术领导检查

小组交叉检查

功能

可靠

功能必须可靠，即使出错也要记录或重试机制，比如基于消息队列的要有本地事件。

可用

任何时候都要能可用或者能替代

可查

每个操作都要有记录日志，并且可视，有页面可以让非技术人员也能清晰的了解过程。

一场可以分为系统异常和业务异常

系统异常：例如程序错误等给开发看的

业务异常：校验不通过，流程数据缺少等给业务看的，将业务问题抛给业务人员处理，减少开发处理。

容错

系统要有容错率，必须要能够让非技术人员也能矫正问题，比如推送再失败后要有页面能够看到推送的过程，失败了有原因可以看到，解决原因后自己手动重新推送。

测试

测试方向

验证功能完整性

验证数据完整性

验证流程完整性

验证数据正确性

bug交互流通

在禅道上前后端联调，后端接口完成，将任务转前端对接，可以将自己设为抄送人，在前端对接完成后，计较测试时，自己也可以知道当前任务状态和进行完整测试

测试流程

自测

交叉测试

测试技巧

将所有功能点分布到思维导图上，包括流程、功能、进度等

开发与测试在功能思维导图上或者excel等可视化界面上操作测试进度

在体测的时候开发自测功能图上流程和功能、编辑进度，在提交给测试，测试再对每个功能和流程做回归测试

自动化测试

使用apifox等设计测试用例，执行用例流程，造数据等

性能测试

使用apifox导出的测试用例再jmeter中进行压力测试等

上线

可以将线上数据库备份到测试数据库先模拟上线一次

可以减少线上数据库的配置缺失问题和未知问题

灰度发布

代码理念

统一理念

在需求分析，模型设计，代码落实等统一思想（如DDD）

代码编写理念

职责单一、可复用、可扩展等

文档管理

模型设计历史文件

需求文档等历史文件

流程图脑图时序图等历史文件

阶段里程碑等历史文件

前后端对接负责模块等历史文件

接口文档

swagger+yapi   自动生成文档+自动同步+mock+权限

项目流程文档

包含项目需求来源，各服务的作用，关联与执行顺序，产出结果等

项目关系文档

项目代码与数据库的关系文档，防止改动一处，处处报错

数据库关系文档

数据库的各种关联关系，包含外键关联或其它关联的数据

部署

云服务器

镜像发布

CICD

交付流水线

镜像根据环境分支发布

项目多服务使用正则匹配但服务更新

镜像根据版本/分支创建有特殊标识的镜像

明确各版本/环境的镜像，防止镜像错乱导致功能紊乱

本地推送+云托管

接方服务器镜像生成压力

本地推送可能会因为每个人的电脑不通而不够稳定，也不能确实的保证本地发布的追溯版本，必须约定先提交后生成，不然无法保证当前发布的分支版本代码后面是不是改了再提交，导致提交分支代码与镜像不一致

k8s容器编排管理

微服务管理

云数据库等中间件

无感知服务发布

只允许子账号进行发布，主账号用来控制权限与强制规则

比如开发阶段只能操作dev不能操作发布环境防止发布错乱

版本管理

sourcetree工作流管理

功能

发布版本

补丁

 多版本并行管理

线上版本分支

版本分支

发布版本镜像

发布版本数据库

测试分支

测试版本分支

测试数据库

测试版本分支数据库脚本等版本修改文件

本地

本地数据库

本地新功能分支/修复分支

本地数据库脚本等版本修改文件

镜像命名规则

用户名+版本+git提交版本名+时间戳

人员

任务透明化

每个人可能不需要知道同事具体处理什么，但需要知道在负责什么

职责明确化

明确自身团队中职责

明确项目中职责

明确并且区分耦合的职责

沟通统一化

命令下达时需要成员回应

同步认知

责任确定

查验执行情况

落实命令

业务沟通要在统一平台

例如同一业务群等

激励机制

明确奖罚

有罚必有奖

多劳多得

正向激励

手段与目的清晰明确

例如扣成员钱并没有什么正向反馈，可以用义务加班代替扣钱

将阶级矛盾转化为人民内部矛盾

测试以测出bug做绩效奖金评判标准，开发以bug数量做绩效奖金标准。让同一木桥的两个阵营对立，用发奖金刺激控制bug数量

员工归属感

认同感

认可与采用方案

使命感

参与团队内容

拥有自己的负责的内容

成就感

认同的前提下给与使命与结果

不要强制员工

尽量不要让员工产生不良情绪波动

团队日常

日报/周报

工作总结与监督

员工工作意见也有可能会写在里面

周会

汇报一周工作

周总结

下周工作规划与安排

团队参与感

团队人员熟悉与交互

技术分享会

同步技术与理念

团队成员归属感途径

问题与困难分享会

可替代化

同一个项目至少两人一组

去孤独话

有可替代性

分担工作

紧急时轮换工作时间

确保领导权威

征服成员的信任

认同成员的能力与方案

在可沟通范围内可以采取成员的更优解方案

没有人是完美的，犯错并且坚持不认错是会导致权威下降，信任危机

确保团队氛围是积极的，团队氛围影响团队稳定性与积极性

当你是天降领导时的问题

内部圈子已经构成，圈子内团结对外，沟通同步迅速。

自身如果能力不够或技能不足会难以形成权威

内部团队形成阶级，也有可能形成内卷。总之新来的难以服众

新的团队成员更容易承认新领导

一朝天子一朝臣

用详细的制度去保证执行效率，用制度替代圈子代表的关系链

完善的制度

管理之与下属应维持同事关系。阶级对立的天然关系导致和员工太多接近，导致团队不稳定。比如员工心理不平衡等。依赖制度弱化管理者印象。不让员工为人际关系产生波动，导致效率波动。

通过完善的制度将工作流程化、标准化

越大的团队越依赖完善的制度越小的团队越依赖人员

领导

建立自己的形象，参考商鞅事迹，通过小事建立自己言必行的形象

例如画饼，画完饼，当你实现它的时候，你的话语权就提升了，你言必行的形象就深入人心了，人们会相信你、依赖你、认可你

任务

任务分配可视化（如tapd）

进度可视化，工作饱和度可视化，职责可视化

任务分配

tapd新建任务，分配人员、时间

确定分配理念

完全上级分配方式

要求上级熟悉业务，好处时上级清晰掌握任务内容与进度，坏处是任务分散职责分离，负责人完全由上级主导

相应负责人负责方式

要求模块或对应项目负责人熟悉业务并且富有责任心，好处是分权下去，团队人员自发性高，坏处是上级难以把控所有细节

任务穿插

任务评审

对穿插的任务进行评审，评估其必要性、关联性、对原计划的影响

分配与调整

tapd新建穿插任务，分配人员时间，原本任务时间调配

任务拆分

任务之间保证耦合少或不耦合

分而治之

任务同步

进度推荐

进度消息同步

问题与困难同步

时间同步

任务流转同步

当前任务在谁手上，做到什么程度，遇到什么困难

例如：自己在处理的时候插入的任务，没有想到的问题，他人负责或流转到他人手上等都要记录在tapd上

进度把控与问题发现后及时调整方案与人员

任务界面化、可视化

例如excel人员时间任务表

主要表现在什么时间做什么事，谁有空先，谁时间不够等

任务把控

需求把控

产出需求文档

产出功能分解文档

产出流程文档

产出领域模型

人员把控

产出人员任务时间分配表

分配了人员与任务却没有分配时间，是导致互相等待的重要原因

分配时间与需要交互的人员保持一致，防止我做好了功能，要联调或需要你的功能进行下一步，你却还在忙其它项目，还没开始，导致不断拖延

任务分配表

进度把控

产出里程碑表

同步与把控项目的问题与进度

工期把控

质量把控

自由主题

 Collect

Get Started

如何管理团队

 Collect

Get Started

项目管理+需求分析+技术分析+系统工程

 Collect

Get Started

如何管理团队

 Collect

Get Started

项目管理





0 条评论

下一页