• 你的团队工作量饱和吗?


      参与软件开发的相关人员,虽然称为工程技术人员,但本质上其实就是手艺人。手艺嘛肯定是一技之长,里面多少有些门道,外行人做不了, 也很难完全搞清楚其中的门道,合作过程中就怕被坑上当 :-)。

      “你工作量饱和吗?”,“团队工作量饱和吗?” 这个对很多同学来说,相信是灵魂一问。近来锅叔就也“又”被问到了。这个问题可以从很多个角度来讨论,现在因为是老板问,这里就试着主要从面向老板的角度来做一个回答。  

     

      一、 效率低可能是因为需求过于追求高端

      “东西做的太慢,这点儿东西不应该2天搞定么, 为啥要10天”

      房屋装修是一个比较贴近生活的例子,把房子从毛坯装成“地中海",其中是涉及到很多工序,工艺,材料的。不同的工艺,材料,不同的施工要求,对成本的影响是很大的。多数时候,使用什么样的工艺,材料是通过先确定预算后,反推而来的。

      这体现了对于解决同一个“把房子装成地中海”的问题,是有很大的弹性空间的。如果遇到有钱的业主,表示不差钱,怎么好怎么来,那可能就会使用更好的材料,更复杂的工艺,以效果为主。如果遇到预算有限的业主,那可能就会推荐实惠的材料,比较易于施工的工艺,以价格为主。最终,豪装的地中海可能可以装同样面积的3套低配地中海。但,这显然不能说,豪装一套地中海的就是工作量不饱和。

      把这个问题换成软件领域的“开发一个网络商城”或者完成“XXX功能”,情景其实是完全一样的。好看的,性能高的,功能模块多的,没有bug的,支持100w人同时秒杀的,需要投入的成本时间一定比,从网上找个开源的稍作修改甚至不改,要贵若干若干倍。如果预算有限,那可以先降低下要求,不必要一步做出个淘宝,够用就好。这样就可以缩小投资,缩短开发周期,剩下的时间可以做别的项目,工作效率就更“高”了。

      作为领导者目标思路要定好说清,"怎么省钱怎么来"与 "怎么好怎么来",所得到的结果是不能单纯比较数量的。 比如如果对于一个功能的质量不怎么关心,那可以明确说。这个不重要,不需要规范测试, 能用就行。就可以省掉很多测试成本。如果对于用户体验要求不高,可以跟开发说怎么方便怎么做,不要追求交互和外观细节。

      所以,做的多不等于工作量饱和,做得慢不等于不饱和,需要先明确标准和重点。

      

      二、工作量饱和未必有益

      花钱雇人多数情况下是希望他不要闲着的,但是也有很多例外的情况,典型的一类例外是“以备不时之需”。所谓养兵千日,用兵一时。

      例如你雇佣了一名司机,他的工作职责应该是,在你需要出行的时候,安全驾驶把你带到目的地。这是你雇佣的目的,也是你的核心需求。你应该不会在你不需要他帮你开车的时候,因为怕他空下来,而安排他开车自己出去跑两圈,每天跑满8小时。

      回到软件领域,如果你的公司模式主要是做项目外包,那每个开发人员都别闲着无疑是你应该追求的,越快的交付时间意味着越低的成本,对应着越高的利润。

      而如果你的公司是在运营一个自己的产品,是否一直“饱和”就不再是问题的关键。你对研发的要求可能就变成,能不能及时响应的业务需求,有没有能力实现你的创意要求。因为通过拼命产出功能并不一定能带来对应的客户和业务增长。

      反而为了让研发饱和,不用白不用,而拼命加一些可有可无的需求,却可能会伤害你的系统的用户体验,技术上让你的系统难于维护,对硬件的需求成本变高。

      “知识产生于闲暇”,全都低头拉车,就难有人抬头看路了。

      

      三、考核过程细节的风险

      ——“老板开始严抓考勤,卫生,着装,说明你的公司一定在走下坡路了”。多数人应该会觉得这样的说法在科技类的公司是有道理的,因为这些细节通常并不是影响你的业务做的多少的主要因素。如果公司订单都做不完,肯定没空顾得上这个,大家工作量也自动饱和。

      管理者考核什么,那么通常就会得到什么,同时,有得必有失。如果你觉得大家工作不努力,考核大家的加班, 那最终就会得到加班统计上升。 但效率未必会提高,员工可能会想,反正也要加班的。把8小时的工作放到10个小时做好了。同时可能引起另外一些务实风格员工的不满,造成离职率提高,人员更替成本提高。

      如果通过考核代码数量来考核效率,那么也一定会得到更高的人日代码产出。但模块复用率可能会降低,大家都倾向于自己发明轮子,系统的可维护性降低,最终变成屎山。

      过程的因素很多,考核成本高昂,一般建议结果导向,如有没有如期交付, 用户是否满意,有没有赚到钱。同时也不建议考核到个人,最小粒度到团队应该就完全够用。过程和细节还是交给专业的管理人员去灵活把握,毕竟,管理还是以人为本的,这也是管理者的价值所在。

      业务才是结果,雇1个人接了10个人的订单量, 工作量不会不饱和。

      

      四、心理价位的确定

      锅叔的职业经历,多数都是在做自运营产品类项目的开发。其间从团队层面得到的肯定,是很有限的。因为自运营的东西除了首次上线这个节点外,后续就是在不停的收集各方需求迭代。这其中开发效率和技能对是否能赚到钱的影响,就非常的不容易体现。因此,老板们对于开发团队的阶段效率质量就很难产生一个心理价位,通常只会在交付时间影响业务开展时,催促你抓紧时间,尽快上线,或者研发支出太多,就着手裁员。

      研发的员工也是希望有一个反馈的,给点儿无论好坏的评价。而评价的基础就是目标,心理价位。

      结合现实生活,“能不能再便宜点儿?”“您多钱想要?”。这其实就是体现了交易过程中,首先要确定的就是心理价位,而且确定方通常最后是买家,也就是老板们。作为买家不能永远要求卖家“再便宜点儿?”,如果能给出一个心理价位,就会显得诚意满满,其乐融融。

      心理价位锚定了一个基准,卖家就知道,买的比这个价位低,那就是合作愉快。如果成本做不到这个价位, 那就会推荐你其他的商品或者解决方案, 也是以合作愉快为目的。

      老板们可能会觉得,我不懂研发,我怎么知道多少算贵,多少算便宜。实际上生活中我们买多数东西,你都很难知道它的成本是多少,但最终还是成交了。

      有了心理预期,才可能产生好坏的评价,才目标明确。

      

      五、结语

      当老板觉得大家工作量不饱和,通常就是两种情况。

      1. 公司的业务收入有限,研发预算的投入占比太高,通俗说养不活研发。这时如果业务短时间没信心做起来,那只能以成本限制为主,裁一些人,需求从简,质量要求降低,开发周期拉长点,摊子别铺太大。

      2. 感觉自己的研发不如别人家的研发,别人做的多快好省。可以直接提结果性的要求,如,这个必须什么时候上,必须生产上不能出大问题等。让专业的人去搞定过程细节,搞定了皆大欢喜,如果搞不定,就考察老板的洞察力了。是管理的不行,员工能力不行,还是别人忽悠你星球大战 ,需要老板们自行决断了。

      

      

  • 相关阅读:
    linux grep 加 正则表达式搜索
    Redis主从部署
    C# List<T>.IndexOf()方法的使用
    依赖注入的进阶:深度解析ApplicationContextAware
    Tower for Mac:Git管理的新境界
    AttributeError: ‘builtin_function_or_method‘ object has no attribute ‘shuffle‘
    1.pytorch学习:安装pytorch
    使用VSCode编辑与编译WSL2下源代码
    python基于django的校园公寓宿舍报修管理系统设计与实现
    HTTP长连接
  • 原文地址:https://www.cnblogs.com/uncleguo/p/16553244.html