本文共 1071 字,大约阅读时间需要 3 分钟。
— 扫描二维码 —加入架构集结群
对技术感兴趣的同学可进群(备注:Java)
最近一直在思考技术转管理过程中需要注意到的一些事情,现在就总结下分享给大家看看
不论项目大小,一定要有目标,有目标才能让所有人看到方向,明确每天工作的意义。单纯技术人员应该切换思维为全局性,而不局限于技术层面,现在个人的成功而不是成功,团队的成功才算最终的成功,应该多思考怎么样才能让团队高质量的绩效产出。
项目开始时候,需明确知道目前团队有哪些资源,比如人员,技术风险点及物理硬件采集。只有了解了需要哪些资源,我们才能更好的完成定下的团队目标
这个在整个项目过程中都有所体现,具体怎么实现,我们可以拆分为三大块
业务管理
团队管理
技术管理
业务管理,主要就是管理我们需要处理的业务需求。其实我们可分为这几大块
每天的任务分配与分解
制定大致的开发排期
每天了解开发进度
讨论与跟进各种具体的技术问题
协调一些产品需求变更
响应一些市场同事的需求
跟进功能上线
关于敏捷开发,针对不一样的团队、不同的产品,具体实践方式是不同的。不过重要的是每过段时间,需要做总结,来反思过去的一段时间中,是否出现变坏的趋势,然后在针对性的改进。总结下「敏捷是态度而不是流程,是氛围而不是方法」。
具体实践有下面 4 个部分组成
计划会议
每日站会
评审会议
回顾会议
困难的地方很多,或者说当坐上管理岗位后,承担的责任就变重很多,体现在以下 5 个方面
需求变更
线上紧急事故处理
业务临时需求
跨部门沟通
开发进度风险
及时试用产品
观察燃尽图
多沟通
40% - 60%
前同事
内部推荐
技术分享
指导新人
技术细节讲解
code review
工作方式与态度
工作上指导
非工作上的帮助
mentor要与新人成为朋友
如果一件事情你熟悉了,不要做,交给新人做
鼓励新人提问
一对一沟通
建立舒适的沟通环境
保持真诚
让对方主动说,适当引导
沟通频率
沟通时长
构建私密,轻松,真诚,有效的环境,两个人一起讨论问题与互相学习
团队活动
30%
技术架构是否合理?
流量增长,现在架构能否胜任
活动期间,突发流量多少,能否承受压力
未来架构如何变化
客户端投入哪些技术方案
推进技术wiki的使用
推进技术分享
推进code review
推进追求代码质量
10%
转载地址:http://nacfn.baihongyu.com/