• 团队管理之高效开发基础认知


    前置信息:

    分享主题名称

    我认为的高效团队之团队意志和devops工具链的法力加持

    内容类型

    管理类

    重要声明

    以下分享内容,仅代表个人观点,尽可斧正,感激不尽。

    核心理念

    高效产出的基础:团队素质第一,自动化管理工具第二,两者相辅如虎添翼。

    核心对象

    前端及有需要伙伴

    针对技术领域

    前端,以及有需要的领域

    分享目的

    讨论行之有效的提高研发效率的方案到底路在何方?我们应该如何反思哪些?

    先介绍我个人工作心得

    开发者基本心得

    1. 程序员的工作特点不断挑战各种难题,每天都在bug和需求之间挣扎与成长。必须不能停止学习,躺平即淘汰。
    2. 对我的代码,产品负责。工作意识觉醒的第一步,就是我的代码,产品就像我的孩子,希望他茁壮成长,不被诟病。

    管理实践总结来的心得

    1. 永远没有通用的管理方法,所有所谓的理论都是不断借鉴,摸索,实践,总结而来,包括我今天所分享的内容,或许只适合我。但希望对诸位有点滴参考价值
    2. 作为管理者,我不轻言放弃任何一个项目,任何一个bug,任何一个人。为的是打造更好的项目,培养更好的人才,更重要的,是建立我们之间的信任。当然我不会钻牛角尖,因为有一种爱叫做放手。
    3. 管理者的状态如果每天被业务深埋,而无暇在技术,工具,管理有所建树,就算忙死,或许你是一个很好的员工,大概率你不是一个好管理者。
    4. 小团队选人,大团队选将,有德有才,大力培养,有德无才,尽力培养。有才无德,酌情引导,无德无才,立马滚蛋。

    我的管理必要心法:沙盘策略

    1. 明确商场如战场,企业发展无非就是在沙盘中攻城略地。
    2. 沙盘策略在明确公司发展发向,明确直属领导战略方针下而迅速产出的作战策略,迅速进行战力最大化布局,分配。
    3. 根据实际情况战斗方式很多,但必须进可攻,退可守。
    4. 优先最大化发挥单一兵种能力,在没有前置经验的前提下,不做跨兵种作战承诺,不做没把握承诺。
    5. 策略即行军布阵,既然是布阵,战阵之中互相照应,一动而全动。将团队战力切实凝结。
    6. 你要坚信,战场中,一直素质高的团队,所向披靡。一个人活不了。

    我的管理必要技能:点将

    1. 单一兵种,会限制作战范围及方向。一个特种兵在复杂严苛的情况下可独当一面。一群特种兵,可以在沙盘中根据作战方向切换随时切换兵种,切换配合方向,切换配合位置,以奇制胜,以强正名。
    2. 在单兵能力达到一定程度后,根据实际情况,大力培养其他专题技术,以随时转为商用为前提,大力培养,并有实际产出,在最短时间内,培养出多专多能的人才。
    3. 蓄势待发,培养全能。当领域内技能素质达到瓶颈,再酌情考虑,直到跨界而来…
    4. 即使铁打的营盘,流水的兵,若干年后,你回忆起来,我们的团队也应当是每个人职业生涯中最耀眼的一段。

    正题:

    关于高效绕不开问题

    敏捷开发的个人拙见

    • 个人反思:高效开发等于敏捷开发?
    • 个人拙见一:高效开发是一个团队的生产状态,而敏捷开发是一个“以人为核心”为了达到“高效”生产状态而总结出来出来人与工具相结合与协调的推动工作高效进展的方法论。所以既然是方法论,就存在一定的适应性,所以东西是好东西,适合所有团队?或者说适合我们?见仁见智。
    • 个人拙见二:不符合这套规则那就不属于敏捷开发嘛?那不一定…
    • 个人拙见二之实证举例:当前我们的团队不高效嘛?相信诸位都会对比,相比而言我们每周处理的问题的实际工作量其实,在国内甲方公司,能超过大部分公司,所以很明显,我们反思的点应该不在这。
    • 个人拙见三:曾几何时敏捷开发的概念,火的一塌糊涂,相信不少管理者将这套规则看成《独孤九剑》,只要方案落地,必然能战力暴涨,于是乎一番折腾下来,发现这门功夫确实厉害,但有点类似《葵花宝典》,如果你非要练,根据理论确实是可以天下无敌的路子,但你一定要痛下决心,但最终能不能无敌,还得看修为…所以时间沉淀下来,诸位可曾历经过据书中记载的那种敏捷开发的团队吗?所以当前来看“敏捷开发”的概念,在国内成了范本,我们研究它的精义,取有用部分理论以适应于国内技术团队的环境,绝大部分根据业务不同,客户不同,企业文化,以及团队掌控者的性格风格不同等等不同直接决定了技术团队的实际生产风格不同,所以国内技术团队管理风格不尽相同。毕竟影响因素太多了。
    • 个人拙见四:敏捷开发在国内为什么遍地不开花?原因太多了。国内外开发者思维基本不同,遇到问题战法不同,团队意志不同,突围能力不同。他们产出环境大部分以技术导向或者产品为导向,驱动力更多在技术,设计和产品升级。,他们更在乎的工作时精力高度集中那几个小时的有效产出。所以他们的高效率体现在“极客”,所以如果有一套方案将一群极客联动状态激活,确实对一个研发团队而言,效率立竿见影。国内技术团队的驱动力更多是市场,市场是多变,是残酷的,更多压力来自于技术产出去助力业务抢占市场时,要同时应对市场的变化,客户的刁钻需求,要质量,要速度,还要见招拆招,对于体能,心理来说,中国的程序员,其实面临的更大的考验,是我们不够快?不…只是我们满足市场的需求,疲于奔命,不够优雅罢了…你看,说来说去,还是人的问题。这就如同某音的一段视频说,如果打死了一个美国士兵,其他的有可能被吓跑。但是如果你在战场上打死了一个中国士兵,剩下的会跟你拼命…所以如果商场如战场,技术团队还想迅速突围,相比之下我觉得《孙子兵法》的诸多策略,可能更加适合。
    • 总结:敏捷大法虽好,但有时只能参考。但“天时,地利,人和”一切都在变,“因地制宜”才更易于落地。

    什么是团队意志?

    • 一个前置问题

      • 你能用一秒钟时间立马回答出你的团队是个什么样的团队吗?
    • 所谓团队意志,可以理解成团队的交付状态。强大的交付状态,一定来自一套高效的协作流程。那必定有一套符合实际流程的协作规范,高效的协作规范一定来自于对生产状态的不断总结,优化,最后衍生出符合该企业游戏规则的一套行之有效的高速协作机制。这是一个总结,优化的过程。实践中出真知的过程。那可以理论推动高效方案落地,见仁见智。

    • 归根结底,这是一个围绕“人”的议题,是指对人的管理吗?我更认为是leader的自我修养。千万别谈管理。我们最多谈的是协调和互相成就。

    • 如果面对一场攻坚任务需要天时地利人和,人和是成功的底线

      1. 古人讲:人心齐,泰山移。这句话今天看来,适用于所有团队。这算一种团队意志。
      2. 今天讲:狼性团队,不一定适用所有团队,但这也是一种团队意志。
      3. 敢打必胜的信念也是一种团队意志。
    • 形成团队意志的最佳时间点,就是团队初始时期。时间推的越晚成本越大,越难,越疼.

    怎么形成团队意志

    • 个人觉得leader的意志品质和行事风格基本决定了团队意志
    • 所以如果作为管理者,我们需要反思有没有这种信念。如果我们自己没有,又如何期盼着自己的团队所向披靡?
    • 所以从一定角度上来说,leader的意志品质就是也是一种团队意志。leader意志品质坚韧,指挥作战进退有序,必然战果累累,攻必取,战必胜。这也是一个leader最累的地方。因为leader尽可能不要出错,一子落错,全军受累。
    • 老说话:天地不可见,人心不可测。那如何能让一个团队听从指挥,整齐划一的有节奏的发力呢?这才是难点。
    • 总结:
      1. 高效开发的大前提,还是团队的协调性,就是一个团队被指挥得当,目标明确,行动高效若一,必然高效。
      2. leader的反思和自我修养很重要,基本决定一个队伍的战斗力。只有更强的人才能带出更强的队伍。

    关于建立团队意志的几条建议

    1. 观察与反思:观察你的团队吧,不该有的状态,反思为什么会这样。距离你期望的状态,这个团队到底缺什么?
    2. 查缺补漏,轻装上阵:多听你战友的诉求,成为他们工作上的防线,让你的战友有所依靠,为他们解决痛点。将心比心,在你需要的时候,相信他们也不会让你失望。
    3. 建立信任:冲锋的路上你可以相信的只有你身旁的战友,如果这一点都做不到,那么枪声还没响,就可能团灭
    4. 不要画饼:大家都在职场多年,智力差距不会太大。作为leader绝不能打空炮,随便画大饼,不要承诺超职权以外,不可控的事情,因为那都是在消耗你的公信力。
    5. 规则:由简入深,从无到有,设立管理,项目的工作规则,让无序变的有序,让工作有节奏。划分清楚责任,恪守原则。
    6. 自由:确认对团队管理与实际产出都有益的工作导向,不要做无谓的挣扎,所有的努力应该都为了有效的产出,但也不要以过度消耗团队成员私人时间为代价,除非他们主动愿意为你高昂的薪水买单。
    7. 赏罚分明,注意收集有意义的数据,一定要让付出更多的人收获更多,既怀柔,也要有铁血的一面,如果战功卓越的人得不到回报,那攻城拔寨的激情在哪里?还不如躺平…反正都一样…
    8. 慎重决策:leader的决策影响团队,在任何情况下都要想办法进可攻退可守,严守边界。横在上下之间,承担着必要的压力,要合理布局,游刃有余,才能整个团队不至于被动。
    9. 放权:相信你的团队成员,放权让每个人敢想,敢折腾,勇于发表他们自己真实的想法,对的采纳,错的沟通。互相学习。
    10. 阶段总结,这个总结可以是因事可以因为人,甚至可以在发呆(沉思)之后做,就团队现状,未来可能性,总结优劣,阶段性不断调整。

    什么要提这个devops?

    1. 如果团队协调力很好,雷厉风行是从人的层面建设的很好,devops工具链,自动,快速,高效,流水线式的生产环节,无疑在快速交付的节奏上锦上添花。
    2. 同理,如果上面这一步关于“人”都还没有协调好,直接来这个工具链,单项目还好,多项目复杂环境的管理,只会各种糟糕,绝大部分情况下,猪八戒照镜子,里外不是,所以团队质量是devops发挥价值的基础。

    什么是devops?

    1. 开发,运维工具链
    • 研发交付工具链,在整个软件开发周期(构建,测试,部署,监控等)自动化执行,减少人为错误,规避明显问题,消除瓶颈,减少返工,极大提高交付速度,也是用来提效

    目前我们应该用devops?用谁?

    1. 徐徐图之。
    2. 纵观我们当下的项目实际情况,比如我们现在服务器走的是阿里系,并且我们想搭建devops,那么阿里云效是目前部署代价最低的方案。

    团队意志和devops哪个重要?

    • 个人觉得,那肯定是团队的意志品质。
    • 如果兵强马壮,工具使如虎添翼。
    • 工具再强,是死的
    • 优秀的开发工具链,至少会在高效人工开发的基础上个人体会提效不低于50%,甚至更高

    个人管理层面基本总结(适用前端,仅供参考)

    avatar

    总结

    1. 想高效交付,首先要建设优良的团队氛围,形成的强大的交付意志,规范且强有力的规范,强力的执行力,至于具体精神形态如狼?似虎?不尽相同,强就完了。
    2. 如果团队执行力,攻坚能力超强,当人力操作遇到瓶颈,辅以自动化开发运维工具,如虎添翼。两者结合,效率之高肉眼可见
    3. 建设高效交付能力的团队因素很多,越早越好,否则成本越来越高。
  • 相关阅读:
    win10 本地通过docker提供kafka服务
    在Spring Boot项目中使用Redisson
    MyBatis
    java冠军体育用品购物网站计算机毕业设计MyBatis+系统+LW文档+源码+调试部署
    代码规范常见错误
    有哪些手机赚钱的副业?
    浅谈HTTP 和 HTTPS (中间人问题)
    C++ string 类相关知识
    迁移学习是什么?
    Chromium127调试指南 Windows篇 - 安装C++扩展与配置(五)
  • 原文地址:https://blog.csdn.net/qq_38560742/article/details/126372098