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