团队的技术形象

文/Tim Yang

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

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

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

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

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

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