• Feeds

  • Archive for February, 2015


    团队的技术形象

    当一个app不好用时候,用户会说团队的产品不行;当系统可用性有问题时(比如访问慢或频繁宕机),用户会说这个团队技术不行。

    发生频繁宕机并不常见,宕机通常会由程序bug或者访问压力过大引起。bug最终会被修复;在不过分在意成本的情况下,访问压力最终可以用硬件来扛住。另外系统升级及功能变更也会带来可用性与稳定性的问题,但大多数系统会最终相对稳定下来,大的变更会越来越少,系统也会趋于稳定。

    技术成本的控制通常不是一个很紧迫的问题,一方面公司的业务模式也不是靠省服务器做出来的,其次技术团队可以通过投入时间去优化改善来降低成本(但大部分团队更愿意将研发资源投入到新功能开发上去)。因而通常只要达到基本可用,则成本合理性问题不会得到充分关注。另外成本也很难直接对比,一个公司比另外一个公司服务器少些,但是各自功能场景有差异,没有直接可比性。因此较难从技术成本合理性角度衡量某个团队技术好不好。讽刺的大部分现实是,只要系统基本可用,则会被视为一支有战斗力的团队;如果能达到一定体量(虽然不是技术团队直接带来的),那则会被视为超强的技术团队。

    软件质量在大部分公司走不出测试或者“质量保证”部门,很少有团队会认为步子不够快是由于软件质量问题造成。开发效率同样没有直接可比性,“努力”有时候会掩盖一切,朋友圈时常会看到这样的总结,“虽然走了一些弯路,但兄弟们加班加点将进度追了回来,感动……”。比软件质量问题更糟糕的是业务方向的不确定性,方向不确定带来的消耗比软件质量的问题更大,走错方向导致一两个月努力泡汤的事情也很常见,因此不是最短板的软件质量的重视通常就无从提起了。

    隔洋对岸则有一些技术主导的公司,Mark Zuckerberg曾说过,Facebook在早期时,非技术岗位如HR及市场也招聘有技术背景的人担任。这些公司尽量招聘最顶级的技术人才,这些人能够在公司中享受技术的乐趣。但这也只有平台级的公司才有可能。这些公司商业模式的门槛足够高,从而有持续的利润来支持这一愿景。而剩下绝大多数公司,需要首先去考虑生存的问题,这也很正常,头部的公司如果失去垄断地位,也马上没有机会去维持纯技术形象。

    技术行不行是一个很无力的目标,技术很强的团队未必能改变世界,不强的团队很多时候也生存得很好。业界很多业务模式短板并不在技术上,更混乱的是,出现技术问题有时反而被当做PR事件及段子去炒作。当然,在技术较差的团队,软件质量及技术创新无从谈起。处在风口的猪,也会遇到前文所说的重复踩进同一个坑的无力感。