|
这是芃篙君的第203篇原创 本文适合职场人。大概2000字，阅读需要7分钟。
你好呀，我是芃（péng）篙，一个相信思考和努力能够拿到结果的家伙。 01. 情况也不复杂，团队里有人离开，补员的招聘一直不太顺利。业务积压了不少，虽然从兄弟团队协调了一些资源，做了一些调整，但是时间久了，总是不好的。朋友说，没办法了，招聘继续。并且我在开始接需求了，业务压力确实很大。芃篙有点好奇，你这家伙有几年没有写业务代码了吧，还会写吗？朋友笑道，确实有点手生，但是见识还在，再不济不还有GPT嘛，问题不大。朋友认真的讲，敲代码本就是咱们安身立命的事情，有什么畏难的。说老实话，如果老板给我讲，别的事情你都别管了，就安安心心敲代码就行，我保证不开除你不降薪，我不知道得多开心。敲代码这个事情虽然复杂，但总是比面对市场、面对人心简单些。芃篙笑着说，你这么一说，让我想起了《亮剑》里，李云龙手下那个出身独立团老底子的团长了。
02. 技术团队里的事情，往往没有那么复杂。任何事情分清楚个轻重缓急，当缺口问题已经非常明显时，讲什么大道理都没有用，管理者自己顶上去，不要瞻前顾后，至少士气的问题就解决了大半。芃篙问，这次是一个比较“临时性”的问题，你有没有想过，后面把介入一线开发做成某种常态？朋友挺感兴趣的，你说的常态是什么意思，如果我的大部分精力放在一线开发中，团队其实很快就会受限于执行的角色。你知道的，这不是什么好事。芃篙摆了摆手，即便你想回归一线，你的老板也不会认的。单纯一线开发，招个年轻人，要求没你高，干得不见得比你差。“某种常态”是指，在这波顶过去之后，你的日常精力分配中，划出合适的部分，有选择的去承接一些一线需求，目的当然不是为了做需求。即便是现在在做的业务需求，你觉得除了完成业务需要，就没有什么别的价值能挖掘了吗？朋友说，昨天我在看一份参考的组件代码时，发现了好几个类，代码行数超过了一千行，头都看大了。某种程度上，颠覆了我的认知，我五年前就认为，自己团队里不应该有这样的代码。芃篙说，对呀，这就是其中的一种价值。一个类或者文件的复杂度要求，是C语言时代就有的编程规范了，为什么现在还会出现。这说明你过往在过程管理中是存在问题的。03. 其实，这只是技术债务的一种具体的表现形式，而技术债务又是源码的真实现状的一种体现。背后映射的是管理者对代码现状整体状态的了解程度。你不一定需要对所有代码都了然于胸，但是完全不了解生产代码的现状是肯定不行的。这是管理者重新介入到一线开发能够发掘出的最直接的价值。如果规则有、流程有、工具也有，但是依旧存在很多不应该存在的技术债务，以及债务对应的各种隐患，那就要去思考具体哪个步骤出了问题，需要优化。在代码之外，还可以去看整个开发流程。去看流程上是否有难点、痛点、卡点，特别是平时大家都习以为常但确实有待优化的点。团队成员讲过的痛点在管理者眼中永远不能100%的理解其中的真实感受，因为管理者可能限于自己过往的经验，用前朝的剑斩本朝的官。而实际体验一圈之后，就会有更强烈的同理心，去理解问题在哪，哪些需要解决。比如，需求的源头是否合理，需求的优先级定义是否合理；比如工程化效率是否存在阻碍，由于工程化导致的各种问题以及解法，是否在团队中完成了普及，大家是否可以更高效的去解决需求层次的问题；比如，跨团队协同中，各种问题的细节点到底在哪里，是否有更前置的解决办法，提高大家的配合程度。代码也好，流程也好，其实都是事情的维度。从具体的事情中，管理者可以更直观的感受到“人”的维度——大家的真实状态。单纯从汇报或者隔层汇报来看状态，无论怎么强调扁平化，都是存在隔阂的。沟通上势能的不同，就天然的会压抑一些真实想法。但是，在日常开发过程中，成为合作伙伴的话，就没有那么容易掩饰。可以更深入的理解大家的状态，也更容易共情。基于共情的引导，往往不会被理解为画饼，而是更具体更有效的指引。朋友说，你这么一扩展，感觉这次人员缺口的事情，算是一个挖掘出更多价值的契机了。很有意思，熬过这一段，我可以稍微梳理梳理，各个业务线在每个季度都捞一些合适的需求。该跳进去的时候跳进去，去发现问题，解决问题。芃篙笑道，俺就是动一动嘴，能做出多少提升，还是你自己的事情。朋友也笑道，你来提供理论，我来实践验证。真有效果的话，到时候请你吃饭。相关链接 “一线”里有什么？
带三五个人的技术团队算不算管理者？
一线管理者冲锋在前的利与弊
团队成熟之后中基层管理者就可以无为而治了吗？
好了，今天的分享就到这里，如果觉得有收获，不妨给点鼓励，点赞、关注、加加星标；转发、在看、多多益善～ 谢谢～ 共同成长，穿越周期！
|
