🔥 热搜 🔥
百度今日热点微信公众平台贴吧opggdnf私服百度贴吧知乎dnf公益服百度傻逼
分类
社会娱乐国际人权科技经济其它
🔥 热搜 🔥
百度今日热点微信公众平台贴吧opggdnf私服百度贴吧知乎dnf公益服百度傻逼
分类
社会娱乐国际人权科技经济其它
查看原文
其他

荒唐的企业软件

zartbot.Net zartbot 2023-07-25
从思科Webex出走的袁征带来的Zoom的故事不必多说，但Zoom的答案简单的出奇：“做市场上最好的产品，一个真正好用的产品”，这一句简单的话却掏出了整个2B市场2B的本质：面向标书的编程。
每个做2B市场的产品经理都会经历很多痛苦的事情，真正用产品的人没有决定权，而做决定的领导往往也不知道自己在干嘛。常年来大家都干着一系列荒唐的事情，用BDM(for Business Decision Maker) PPT搞定用户高层领导，用TDM（Technical Decision Maker）PPT搞定用户技术主管，然后产品符合和客户领导一起讨论出来的RFP就好，至于最后用的员工，谁管你用的好不好。最后客户反馈用的不好，产品部门还要对前端销售说：“你需要Educate your customer follow our process",刚好前几天看到一篇文章很有代表性，不是我软件做的不好，而是你不会用。最终是研发不知道用户用什么，客户不知道自己买的是什么，用户不知道用的是什么。

如果你觉得市面上的HR软件不能满足你企业应用需求的话，那不是HR软件的问题，而是你企业的HR管理有问题

GEORGE陈果，公众号：陈果GeorgeIT战略 ｜ 企业软件，自研还是外购
所以乔帮主也曾说过一句话：

我们存在的意义，就是制造更好的产品。我喜欢消费者市场的原因，同时也是我讨厌企业市场的原因：就是我们设计出一款产品，每个人都为自己投票，他们很简单地回答要或不要，如果很多人说要，我们明天起来还能上班，这就是消费者市场，非常简单。而企业市场就没那么简单，真正用产品的人没决定权，而做决定的人往往不知道自己在干嘛。我们只想为大家做最好的产品，他们会用钞票投票我们是否做了一件好东西。

乔布斯
Zoom的故事告诉我们了一个最简单的道理：“得民心者得天下”，道理讲太多谁都听不进去，咱就说点荒唐事吧。
有句玩笑话，两个人男人在一起最后要么是比大小，要么就是比完大小真在一起了。企业软件中常见的荒唐事之一就是比跑分，因为“好用”没法量化。所以广域网专线只有100M的，招标买了一个10G路由器，10G的比友商1G的便宜，还带8口交换机。而很多广域网安全流控这些功能都被排除在标书之外，最终用户想用的功能都是独家的，单一来源的麻烦事采购才懒得管你呢。
记得以前有个非常资深的产品总监教过我某司产品设计的原则，首先你要规划好用户的Profile，例如这是一个分支机构的设备，机构人员调研出来大概规模有多大，广域网带宽和运营商一起看看未来几年的Roadmap和用户业务部门谈谈带宽需求或者根据现有的Netflow数据做时间序列分析预测趋势。这些都订好了，再回来根据用户可接受的成本选择芯片和设计路由器，然后在满足这个性能的同时尽力的添加用户想用的功能，让用户用的开心。
去年某一个集采，一个企业用户招标SDWAN，最后有家H的S路由器为了性能，做的基于流表的转发，可以打到100G的流量，但是却扛不住一个源IP地址利用随机源端口对另一个IP地址随机目的端口1Gbps的流量， 这些都是面对标书编程带来的灾难，大就是小的灾难，而另一家H公司的N路由器和C公司的A路由器最后火拼到BGP路由表打6M，同时ACL打到128K，也暴露出来H的问题来自于TCAM容量的限制和分布式部署的问题，而C在10多年前就考虑到了这个问题，路由查表做了特殊的器件不用TCAM了，然后这人后来去了J家也做了同样的事情。
最后荒唐的是C的一个100G的路由器居然打败了另两个H家的Tbit级路由器拿了技术分第一，然后商务上的事情就不多说了，赵家买C就是错。而用户自己真正关心的IPsec加密性能，VPN隧道数，大规模组网下的收敛能力，QoS能力压根就没测，只是因为招标测试设备的限制。而客户真的需要的带宽最多10G就够了。
再来说另外一个荒唐的事，监控运维的软件。很多RFP里需要有Per-flow的信息统计，我昨天大概推算了一下，按照一个分支机构设备挂50个用户，每个设备每秒产生20个flow来计算，一个1000台设备的集群需要1M/s的flow日志处理能力，1M/s的日志折合一天就是80亿条，还要用elasticsearch处理加工聚合和存储，没个50台服务器够么？客户真的那么有钱愿意花这50台的钱去看一些有的没的日志？几年前我就说过一定要做预聚合，预聚合针对Audit和用户行为场景做session window聚合，针对监控场景做Tumbling window聚合，聚合需要发生在数据采集的节点，并逐级汇聚。只可惜苦口婆心讲了两年三年，代码都写完了，如今还在讲这个问题，总有人很多的人面对RFP编程也是没办法的事情。
还有更荒唐的事，正经的产品不好好做，却把排错软件做的超级牛逼，为了监控性能好，测量出来的值标准差大于均值，一个好的软件一定是软件结构想的相对清晰，error case尽量的少，而不是通过一些error和logging分支来反过来控制软件行为。想起一个大师讲过的一句话：
软件设计分两种，一种是简单到你完全看不出bug，另一种是把排错软件做到极致的复杂以至于客户完全看不出bug。

刚写了一小段就有点红楼梦的感觉了，只因为“满纸荒唐言，一把辛酸泪”。有些东西对公司而言，它这产品能出数，是高层的希望，市场的趋势，就此打住罢了，你好我好大家好其乐融融开心工作不是更好么？只是有一句话不知道当不当讲

恰逢立冬，“Winter is coming”

您可能也对以下帖子感兴趣

文章有问题？点此查看未经处理的缓存