科技猎面对微盟“删库跑路”事件 产品经理应该有哪些技术认知？
本周新冠肺炎疫情存量患者逐步降低，当属即将过去的2月最好的消息。科技圈内也爆出了新瓜，SaaS服务商微盟运维人员“删库跑路”，导致公司主营业务一度中断，微盟市值蒸发逾10亿+，从负面角度再次验证了技术影响之大。
相信大部分产品经理都不用天天写代码，市面上也不乏一些指点提升产品经理具体技术认知的文章，本篇抛开具体技术，谈谈产品经理从业者应该具有的对技术及技术人的一些认知。
业务驱动技术
科技圈不同公司对外宣称的口号多有不同，比如“产品驱动”、“技术驱动”、“业务驱动”都是比较主流的说法，为的是体现公司的侧重点或竞争力。从本质上来讲，产品驱动当属业务驱动之中，只是有些公司产品即业务，但技术驱动就比较难得通，因为技术作为达到产品或业务目标的工具，本身是服务产品或业务的，本身并非驱动力，而是产品或业务有了现实的需求，才会有优秀的技术应用去解决问题，而非先发明一个好轮子再找场景或应用。
拿阿里举例，淘宝双十一海量的用户和交易，驱动着淘宝去IOE架构，后期采用云端可伸缩的架构，并且为了模拟真实线上流量将问题预先暴露，落地了全链路压测系统。淘系内众多业务线发版及举办活动频繁，驱动着客户端应用插件化和热修复，并将活动抽象化为配置系统。
产品或业务需求驱动着技术应用，也促进了公司和行业技术能力提升。早年淘宝和阿里在科技圈并不属于技术人特别待见的目的地，但架不住有大量复杂的应用场景，包含云业务在内的各种技术逐步落地应用，在技术圈内口碑也逐步转变，现在技术人去阿里或京东，并不像早些年那般偷偷摸摸。
技术是一把手工程
科技圈内从业者日常并不难刷到，阿里云王坚博士成功之前被不少人称为“骗子”，好在马云“赌”对了，马云做到了“用人不疑，疑人不用”，支持王坚走到胜利的那刻。换做其他公司可能是另一番光景，一家科技公司，重视技术与否，从根上取决于老板是否理解并认同技术的价值，并且愿意持续投入。
早年在门户公司时，门户公司虽属互联网公司，但有非常强媒体的基因，重编辑和营销，轻产品和技术，集团内一直无CTO。虽然集团内业务众多，且有不少共性需求，但始终难以形成合力，重复造轮子问题不在少数，少数公共能力也因质量和性能问题，不被内部部门信任。从结果看，好像技术不重要，因为没有CTO、没有那么多中台，公司依然“欣欣向荣”。
作为对比地是字节跳动，由于张一鸣是技术出身，公司内部天生就讲求效率和通过技术解决问题。内部不乏推荐、a/b test、直播等中台能力，开发一个应用成本非常可控，低试错成本将字节跳动打造为业界领先的“APP工厂”。
门户公司和字节跳动都有海量的用户和众多应用场景，但由于一把手对技术理解和支持力度不同，走向了两个极端，市值上更是差了数百倍。
大公司优势
通过“业务驱动技术”不难发现，技术是会随着业务不断进化的。大公司相比于小公司或早期创业公司的好处是，有一定业务规模，有非常多的应用场景。但对小公司或早期创业公司来讲，可能很长时间都在0-1或生存的边缘，业务需求不深，此时如使用过度精深或高大上的技术略显多余。
就拿推荐来讲，淘宝在过去十年，经历了运营手动编排—>规则投放—>智能推荐，并非这些技术说应用就用上，而是随着淘宝用户数增长、业务线逐步增多和移动互联网浪潮共同叠加造就的结果。但假如拿现在淘宝的智能推荐去服务一个垂直电商，不说是否有技术浪费，就拿很多企业的用户体量和需求频次来讲，大概率推荐系统效果不会太好看。
大公司的优势可以转化为创业机会或资本，不少BAT出身的创业者，拿着之前在公司应用的技术，将应用场景扩展到更多行业或企业，垂直领域独角兽便呼之欲出，即“技术下乡”。但也需要注意，不要拿锤子找钉子，客户始终会为价值买单，而非技术的高大上。
技术人经验的价值
圈内很多公司由于起步不同，侧重点略有不同。在有些公司技术人地位并不高，甚至存在一类公司认为只要业务跑起来就行，技术不重要。在具体招聘策略上则是招募大量应届生，疯狂加班，扛不住走了再招一批。而在注重技术的公司，技术人的价值将会被充分的发挥，好的架构和设计，能避免后续非常多的问题，并非看起来越忙，就越有产出。
之前从事推荐业务，曾经历过推荐引擎多次重构的情况，正是因为缺少工程侧推荐系统架构师的角色，导致踩了坑爬出来又掉进坑里，一群人也没闲着，但始终在处理一样的问题。
作为产品人，一定要与技术牛人持续合作与学习。一方面，即便不写代码，还可以增长技术认知，即便哪天无优秀技术人共事，也知道该招募什么样的技术人。另一方面，增长技术认知，也是提升产品经理自身决策力与判断力的一部分，当面向一群技术小白面，即便不懂代码，也能给出好的解决方案或建议。
技术与产品有机的融合，才能更好地改变世界。
以上就是“面对微盟“删库跑路”事件 产品经理应该有哪些技术认知？”的内容了，如果你还想了解其他相关内容，可以来 产品壹佰 官方网站获取更多内容。
相信大部分产品经理都不用天天写代码，市面上也不乏一些指点提升产品经理具体技术认知的文章，本篇抛开具体技术，谈谈产品经理从业者应该具有的对技术及技术人的一些认知。
业务驱动技术
科技圈不同公司对外宣称的口号多有不同，比如“产品驱动”、“技术驱动”、“业务驱动”都是比较主流的说法，为的是体现公司的侧重点或竞争力。从本质上来讲，产品驱动当属业务驱动之中，只是有些公司产品即业务，但技术驱动就比较难得通，因为技术作为达到产品或业务目标的工具，本身是服务产品或业务的，本身并非驱动力，而是产品或业务有了现实的需求，才会有优秀的技术应用去解决问题，而非先发明一个好轮子再找场景或应用。
拿阿里举例，淘宝双十一海量的用户和交易，驱动着淘宝去IOE架构，后期采用云端可伸缩的架构，并且为了模拟真实线上流量将问题预先暴露，落地了全链路压测系统。淘系内众多业务线发版及举办活动频繁，驱动着客户端应用插件化和热修复，并将活动抽象化为配置系统。
产品或业务需求驱动着技术应用，也促进了公司和行业技术能力提升。早年淘宝和阿里在科技圈并不属于技术人特别待见的目的地，但架不住有大量复杂的应用场景，包含云业务在内的各种技术逐步落地应用，在技术圈内口碑也逐步转变，现在技术人去阿里或京东，并不像早些年那般偷偷摸摸。
技术是一把手工程
科技圈内从业者日常并不难刷到，阿里云王坚博士成功之前被不少人称为“骗子”，好在马云“赌”对了，马云做到了“用人不疑，疑人不用”，支持王坚走到胜利的那刻。换做其他公司可能是另一番光景，一家科技公司，重视技术与否，从根上取决于老板是否理解并认同技术的价值，并且愿意持续投入。
早年在门户公司时，门户公司虽属互联网公司，但有非常强媒体的基因，重编辑和营销，轻产品和技术，集团内一直无CTO。虽然集团内业务众多，且有不少共性需求，但始终难以形成合力，重复造轮子问题不在少数，少数公共能力也因质量和性能问题，不被内部部门信任。从结果看，好像技术不重要，因为没有CTO、没有那么多中台，公司依然“欣欣向荣”。
作为对比地是字节跳动，由于张一鸣是技术出身，公司内部天生就讲求效率和通过技术解决问题。内部不乏推荐、a/b test、直播等中台能力，开发一个应用成本非常可控，低试错成本将字节跳动打造为业界领先的“APP工厂”。
门户公司和字节跳动都有海量的用户和众多应用场景，但由于一把手对技术理解和支持力度不同，走向了两个极端，市值上更是差了数百倍。
大公司优势
通过“业务驱动技术”不难发现，技术是会随着业务不断进化的。大公司相比于小公司或早期创业公司的好处是，有一定业务规模，有非常多的应用场景。但对小公司或早期创业公司来讲，可能很长时间都在0-1或生存的边缘，业务需求不深，此时如使用过度精深或高大上的技术略显多余。
就拿推荐来讲，淘宝在过去十年，经历了运营手动编排—>规则投放—>智能推荐，并非这些技术说应用就用上，而是随着淘宝用户数增长、业务线逐步增多和移动互联网浪潮共同叠加造就的结果。但假如拿现在淘宝的智能推荐去服务一个垂直电商，不说是否有技术浪费，就拿很多企业的用户体量和需求频次来讲，大概率推荐系统效果不会太好看。
大公司的优势可以转化为创业机会或资本，不少BAT出身的创业者，拿着之前在公司应用的技术，将应用场景扩展到更多行业或企业，垂直领域独角兽便呼之欲出，即“技术下乡”。但也需要注意，不要拿锤子找钉子，客户始终会为价值买单，而非技术的高大上。
技术人经验的价值
圈内很多公司由于起步不同，侧重点略有不同。在有些公司技术人地位并不高，甚至存在一类公司认为只要业务跑起来就行，技术不重要。在具体招聘策略上则是招募大量应届生，疯狂加班，扛不住走了再招一批。而在注重技术的公司，技术人的价值将会被充分的发挥，好的架构和设计，能避免后续非常多的问题，并非看起来越忙，就越有产出。
之前从事推荐业务，曾经历过推荐引擎多次重构的情况，正是因为缺少工程侧推荐系统架构师的角色，导致踩了坑爬出来又掉进坑里，一群人也没闲着，但始终在处理一样的问题。
作为产品人，一定要与技术牛人持续合作与学习。一方面，即便不写代码，还可以增长技术认知，即便哪天无优秀技术人共事，也知道该招募什么样的技术人。另一方面，增长技术认知，也是提升产品经理自身决策力与判断力的一部分，当面向一群技术小白面，即便不懂代码，也能给出好的解决方案或建议。
技术与产品有机的融合，才能更好地改变世界。
以上就是“面对微盟“删库跑路”事件 产品经理应该有哪些技术认知？”的内容了，如果你还想了解其他相关内容，可以来 产品壹佰 官方网站获取更多内容。
