针对这些年旁观和经历过的技术产品场景，做一些个人的总结和判定，尽量不涉及争议性话题，比如对一个互联网公司而言，技术重要还是产品重要之类的，这种话题一扯开，各有道理，谁也别指望说服谁。
此外，加一个前缀，主要针对非技术领导者所面临的技术管理困境，在很多从传统企业转型或个人站转型的互联网企业里，这个问题较为突出。
以下一些产品经理 or Boss 面临的场景，不知道读者是否熟悉。
这么简单的需求?为什么开发告诉我要做那么久?
同行 or 竞争对手都做出来了，为什么我的开发说这个无法实现?
我明明说清楚了，开发也确认了，给我的产品怎么是这么奇怪的一坨?和我想要的完全不是一回事。
线下测试都ok，一上线就各种崩溃，诡异现象，弄得我们什么运营活动都搞不了.
请了个大公司出来的，工资巨高的，结果也没看出比便宜程序员好在哪里?
天哪，又给我说要重构!又是好几个月啥需求都做不了!
看上去，有没有同感?且慢，程序员也有话说。
你需求三天一改，两天一变，你以为我代码会72变，我多少工作打水漂了你知道不?
你说这个简单，你前面系统数据结构各种不支持，我不大改我根本支撑不了这需求，我跟你说数据结构你听么你?
你告诉我做A,B,C,D,E，我都按你说的做了，做完了你说不是你要的，鬼知道你要什么。
你就给我这点开发时间，我已经加班给你把事干了，我反正实现了，测试也通过了，线上出问题，你业务场景各种诡异，我哪里知道，又没早跟我说。
天天有事没事就拉我开会，你知道我思路多难集中么?完全没效率，你尊重过我的时间么?你以为写代码随时抽五分钟就能写一坨么?
这代码补丁打得，找一个小问题要一个下午，不重构你后续功能没一个可以顺利快速搞起来的，我替你考虑，你还埋怨我?
哎哎哎，上面的那位童鞋不要乱讲，我设计架构的时候，也没想到现在业务这么变态啊，当时我可是按照标准的流行业务模式设计的。你没理解我架构精髓，就知道重构，你有问题哦你。
好了，打住打住，架构这话题太大，程序员自己都会pk起来，不和谐。
下面说一下我的理解和相应的对策。
问题1：信息不对称
产品人员往往认为，描述了功能需求，甚至简单的给一个竞争对手的范例，工程师就能完美的实现所有业务需求;但是，工程师对业务的理解往往是欠缺的，因此在产品的塑造上，很可能因为个人理解偏差，带来极大的随意性;即便是产品经理具有超强的控制力和投入，保证技术在功能实现上与使用场景吻合，但往往因忽略了业务的性能诉求，导致线下ok的东西，线上各种问题。
微信扫码上方二维码，可领取2025年最新互联网创业项目！
项目收款截图
