IT技术团队项目管理流程
2022-06-08 16:32:39 2 举报AI智能生成
登录查看完整内容
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人员时间任务表
任务界面化、可视化
产出需求文档
产出功能分解文档
产出流程文档
产出领域模型
需求把控
分配了人员与任务却没有分配时间，是导致互相等待的重要原因
分配时间与需要交互的人员保持一致，防止我做好了功能，要联调或需要你的功能进行下一步，你却还在忙其它项目，还没开始，导致不断拖延
产出人员任务时间分配表
任务分配表
人员把控
产出里程碑表
同步与把控项目的问题与进度
进度把控
工期把控
质量把控
任务把控
任务
自由主题
项目技术团队
0 条评论
回复 删除
下一页
