IT技术团队项目组团队管理项目管理流程
2021-05-14 10:14:42 21 举报AI智能生成
登录查看完整内容
IT技术团队的项目组管理流程通常包括以下几个步骤：首先，项目启动，明确项目目标、范围和时间表；其次，需求分析，收集并理解客户的需求和期望；然后，设计和开发，根据需求制定详细的设计方案并进行编码实现；接着，测试阶段，对产品进行全面的功能和性能测试，确保满足客户需求；最后，项目上线和维护，将产品部署到生产环境，并根据用户反馈进行持续优化。在整个过程中，项目经理需要协调团队成员的工作，确保项目按计划进行，同时还要与客户保持良好的沟通，及时了解并解决可能出现的问题。
作者其他创作
大纲/内容
每个人可能不需要知道同事具体处理什么，但需要知道在负责处理什么
任务透明化
倾向于个人在团队中的角色，比如你是项目负责人，那么你的职责就是流程管理，需求确认，任务拆分，人员分配，进度把控，结果验收等等，比如你是开发，那么你的职责便是完成分配给自己的任务
明确自身团队中职责
这个倾向项目中的角色，比如进入到一个项目中，有项目经理，产品经理，测试，开发等等，每个人在每个岗位上有自己的职责，需要的是每个岗位的人对自己在项目中的职责保证，比如产品经理，必须要保证需求的完整性与正确性，不能在开发或者开发完测试时提出新的需求，对任务与进度添加新的难度，或许这些新提的可以放在下一期或一个优化小版本里，比如测试人员，必须保证测试的完整性和正确性，保证任何场景都有足够的安全性
明确项目中职责
明确并且区分耦合的职责
职责明确化
责任确定
同步认知
落实命令
查验执行情况
命令下达时需要成员回应
业务沟通要在同一平台 ：例如同一个业务群等
沟通统一化
有罚必有奖
明确奖罚
正向激励
多劳多得
例如扣成员钱并没有什么正向反馈，可以用义务加班代替扣钱
这就是个例子，就是达到目标的手段，最终在执行的时候，手段变成了执行的目标
例子，政府是想除蛇，但人们只想拿蛇卖钱，所以集体的目标和个人的目标冲突，导致了目标最终的偏差
比如以前蛇横行，政府出赏金去除蛇，并以收到的蛇数据为绩效并奖励，开始蛇的数量的确变少了，但时间长了，政府发现蛇不仅没少，还变的更多了！一调查，原来是人为了绩效，竟然故意养蛇！然后上交养的蛇获取奖励
从顶层目标一步步同化目标，最终让所有人的目标要达成的效果与顶层目标一致，手段可以不一样
手段与目的清晰明确
注意：这个只是个例子，缺点是可能会损失员工积极性，因为多劳的人必定失误的概率越大，这个必须与正向激励绑定，否则会导致没人愿意做更多的事，开始踢皮球最终导致员工为了bug数做努力，而不是为了项目更好做努力，手段与目的最终失去联系，让手段变成了目的
例子：测试以测出bug做绩效奖金评判标准，开发以bug数量做绩效奖金标准。让同一目标的两个阵营对立，用奖金刺激控制bug数量
狼羊狮子分肉故事
比如一个系统，让团队每个人在某个时间段里必须指出多少个问题，并做激励处理，比如最关键最有用的那个加分啥的，这样在不断卷的过程中不断优化
将阶级矛盾转化为人民内部矛盾（前提是需要人员职责模块规划清晰）
多劳多得，才会有不劳不得
激励机制
认可与采用方案
认同感
参与团队内容
拥有自己的负责内容
使命感
认同的前提下给予使命与结果
成就感
员工归属感
工作总结与监督
员工工作意见也有可能会写在里面
日报/周报
汇报一周工作
周总结
下一周工作规划与安排
团队参与感
团队人员熟悉与交互
周会
同步技术与理念
团队成员归属感途径
技术分享会
问题与困难分享会
团队日常
去孤独化
有可替代性
分担工作
紧急时轮换工作时间
同一个项目至少2人一组
可替代化
征服成员的信任
认同成员的能力与方案
在可沟通范围内可以采取成员的更优解方案
确保领导权威
内部圈子已经构成，圈子内团结对外，沟通同步迅速。
自身如果能力不够或技能不足会难以形成权威
内部团队形成阶级，也有可能形成内卷。总之新来的难以服众
新的团队成员更容易承认新的领导
一朝天子一朝臣
当你是天降领导时的问题
管理者与下属应该维持同事关系。阶级对立的天然关系导致和员工太过接近，导致团队不稳定。比如员工心理不平衡等。依赖制度弱化管理者印象。不让员工因为人际关系产生波动，导致效率波动
完善的制度
例子：画饼，画完饼，当你实现它的时候，你的话语权就提升了，你言必行的形象深入人心了，人们会相信你，依赖你，认可你
建立自己的形象，参考商鞅事迹，通过小事建立自己言必行的形象
领导
将自己不专业的事交给专业的人
将自己做不过来的事交给信任的人/专业的人
为团队内对应职位的人相匹配的权限与责任
放权
正向
反向
考核
有个故事，叫在自己的领域里，哪怕是爱因斯坦都不会比自己出色。比如100以内的加减法，如果你算的比爱因斯坦快，那你在这块领域里，是比爱因斯坦更强的每个人在自己擅长的领域里，都是天才所以识别到每个人的天赋，并让他在自己擅长的领域里发挥出实力，是成为一名伯乐必备的技能
比如我们普通企业的升级制度，比如在一线做了10年的老人，提升至管理层，不再负责一线的事务，专职管理这个是明显违反这个理论的，因为这个人做了10年的一线，他在这个领域里如鱼得水，而他在管理这块是从头开始，甚至不一定有这个天赋，这种粗暴的升级方式，得到的结果往往事倍功半所谓循序渐进，应该是升级的过程不能脱离自己擅长的领域，不然升级的意义就不存在了循序渐进，应该是比如一线员工升为一线领导，以一线的熟悉去掌控这个领域，当在一线领导这个位置很久很熟悉了，再升级为二线领导，对一线领导的工作做统筹掌控
伯乐
人员
确保团队氛围是积极的，团队氛围影响团队稳定性与积极性
用详细的制度去保证执行效率，用制度替代圈子代表的关系链
越大的团队越依赖完善的制度越小的团队越依赖人员
主要是对职责的正确划分，认知与保证，明确各自的职责，对自己的环节进行保证
进度可视化，工作饱和度可视化，职责可视化
任务分配可视化：例如tapd
要求上级熟悉业务，好处是上级清晰掌控任务内容与进度，坏处是任务分散职责分离，负责人完全有上级主导
完全上级分配方式
要求模块或对应项目负责人熟悉业务并且富有责任心，好处是分权下去，团队人员自发性高，坏处是上级难以把控所有细节
相应负责人负责方式
确定分配理念
任务分配
对穿插的任务进行评审，评估其必要性，关联性，对原计划的影响
任务评审
tapd新建穿插任务，分配人员时间，原本任务时间调配
分配与调整
任务穿插
任务之间保证耦合少，不耦合
分而治之
任务拆分
进度推进
进度消息同步
问题与困难同步
时间同步
任务流转同步:当前任务在谁手上，做到什么程度，遇到什么困难例如：自己在处理的时候插入的任务，没有想到的问题，他人负责流转到他人手上等都要记录在tapd上
任务同步
主要表现谁在什么时间做什么事，谁有空闲，谁时间不够等
例如execl人员时间任务表
任务进度界面化，可视化
产出需求文档
产出功能分解文档
产出流程文档
产出领域模型
需求把控
分配了人员与任务却没有分配时间，是导致互相等待的重要原因
分配时间与需要交互的人员保持一致，防止我做好了功能，要联调或需要你的功能进行下一步，你却还在忙其他项目还没开始，导致不断拖延
产出人员任务时间分配表
任务分配表
人员把控
产出里程碑表
同步与把控项目的问题与进度
进度把控
工期把控
质量把控
任务把控
任务
进度把控与问题发现后及时调整方案与人员
需求分析重要：确定用户业务目标
补齐追获资料
统一设计风格
催进度/同步消息
任务推进
阶段演示/里程碑验收
项目规划
明确架构理念
例：DDD六边形架构
明确架构风格
明确各中间件及组件
不需要自己培训
选择第三方大众熟悉优先
选择兼容差异好的
技术选项
架构
vs装企业版，在做功能时参考下代码图，看是否清晰
项目命名
微服务命名
镜像命名
容器命名
代码规范
统一标题，分类，对应标志，内容。方便查找与统计分类等
日志规范
例如：使用后要关闭所有应用再离开服务器
服务器使用规范
规范
技术领导检查
小组交叉检查
代码检查
代码
功能必须可靠，哪怕出错了也要有记录或重试机制。比如基于消息队列的要有本地事件表保证事务与可靠性
可靠
任何时候都要能可用或者能替代
可用
每个操作都要有记录日志，并且可视，有页面可以让非技术人员也能清晰的了解过程，能够捕捉甚至回溯整个事件
异常可以分为系统异常和业务异常，系统异常例如程序错误等给开发看的，业务如此例如校验不通过，流程数据缺少等给业务看的，两方面的监控与处理，将业务问题抛给业务人员处理，减少开发处理
可查
系统要有容错率，必须要能够让非技术人员也能矫正问题，比如推送在失败后要有页面能看到推送的过程，失败了有原因可以看到，解决原因后非技术人员可以自己手动重新推送
容错
功能
验证功能完整性
验证数据完整性
验证流程完整性
验证数据正确性
测试方向
例如：在禅道上前后端联调，后端接口完成，将任务转前端对接，可以将自己设为抄送人，在前端对接完成后，提交测试时，自己也可以知道当前任务状态和进行完整的测试
bug交互流通
自测
交叉测试
测试流程
将所有功能点分布到思维导图上，包括流程，功能，进度等
例如：在提测的时候开发自测功能图上的流程和功能，编辑进度，再提交给测试，测试再对每个功能和流程做回归测试
开发与测试在功能思维导图上或者execl等可视化界面上操作测试进度
测试技巧
使用apifox等设计测试用例，执行用例流程，造数据等
自动化测试
使用apifox导出的测试用例在jmeter中进行压力测试等
性能测试
可以减少线上数据库的配置缺失问题和未知问题
可以将线上数据库备份到测试库先模拟上线一次
灰度发布
上线
测试
例如：DDD 在需求分析，模型设计，代码落实等统一思想
统一理念
例如：职责单一，可复用，可扩展等
代码编写理念
代码理念
模型设计历史文件
需求文档等历史文件
流程图脑图时序图等历史文件
阶段里程碑等历史文件
前后端对接负责模块等历史文件
自动生成文档+自动同步+mock+权限
swagger+yapi
接口文档
包含项目需求来源，各服务的作用，关联与执行顺序，产出结果等
项目流程文档
项目代码与数据库的关系文档，防止改动一处，处处报错
项目关系文档
数据库的各种关联关系，包含外键关联或其他关联的数据
数据库关系文档
文档管理
代码管理
必须保证数据的可靠性与正确性，失败后重试与记录，这样才不会出问题像个无头苍蝇必须要有操作记录，每一个数据更改都要记录，这样可以进行事件回溯必须要有查看操作失败的页面，可以查看到原因步骤怎么处理等，可以让技术人员也能矫正流程。不然技术人员将陷入出现问题找原因改数据的循环中
交付流水线
镜像根据环境分支发布
项目多服务使用正则匹配单服务更新
镜像根据版本/分支创建有特殊标识的镜像
CICD
解放服务器镜像生成等的压力
本地推送可能会因为每个人电脑不同而不够稳定，也不能确实的保证本地发布的追溯版本，必须约定先提交后生成，不然无法保证当前发布的分支版本代码后面是不是改了后再提交，导致提交分支代码与镜像不一致
本地推送+云托管
镜像发布
明确各版本/环境的镜像，防止镜像错乱导致功能紊乱
k8s容器编排管理
微服务管理
云服务器
云数据库等等中间件
k8s自带pod无缝更新
请求加版本号，网关更具版本号路由
重试+高可用
无感知发布不影响微服务团队其他人的测试与调用
无感知服务发布
只允许子账号进行发布，主账号用来控制权限与强制规则，比如开发阶段只能操作dev不能操作发布环境等防止发布错乱
部署
发布版本
补丁
sourcetree工作流管理
版本分支 例：1.0
发布版本镜像
发布版本数据库
线上版本版本分支 例：1.0
测试版本镜像
测试数据库
测试版本分支数据库脚本等版本修改文件
测试分支 例：1.0
多版本并行管理
测试分支 例：2.0
本地数据库
本地新功能分支/修复分支
本地数据库脚本等版本修改文件
本地
用户名+版本+git提交版本名+时间戳
镜像命名规则
版本管理
项目管理
项目组团队
0 条评论
回复 删除
下一页
