做一个有产品思维的程序员

针对这些年旁观和经历过的技术产品场景，做一些个人的总结和判定，尽量不涉及争议性话题，比如对一个互联网公司而言，技术重要还是产品重要之类的，这种话题一扯开，各有道理，谁也别指望说服谁。

此外，加一个前缀，主要针对非技术领导者所面临的技术管理困境，在很多从传统企业转型或个人站转型的互联网企业里，这个问题较为突出。

以下一些产品经理 or Boss 面临的场景，不知道读者是否熟悉。

这么简单的需求？为什么开发告诉我要做那么久？

同行 or 竞争对手都做出来了，为什么我的开发说这个无法实现？

我明明说清楚了，开发也确认了，给我的产品怎么是这么奇怪的一坨？和我想要的完全不是一回事。

线下测试都ok，一上线就各种崩溃，诡异现象，弄得我们什么运营活动都搞不了.

请了个大公司出来的，工资巨高的，结果也没看出比便宜程序员好在哪里？

天哪，又给我说要重构！又是好几个月啥需求都做不了！

看上去，有没有同感？且慢，程序员也有话说。

你需求三天一改，两天一变，你以为我代码会72变，我多少工作打水漂了你知道不？

你说这个简单，你前面系统数据结构各种不支持，我不大改我根本支撑不了这需求，我跟你说数据结构你听么你？

你告诉我做A,B,C,D,E，我都按你说的做了，做完了你说不是你要的，鬼知道你要什么。

你就给我这点开发时间，我已经加班给你把事干了，我反正实现了，测试也通过了，线上出问题，你业务场景各种诡异，我哪里知道，又没早跟我说。

天天有事没事就拉我开会，你知道我思路多难集中么？完全没效率，你尊重过我的时间么？你以为写代码随时抽五分钟就能写一坨么？

这代码补丁打得，找一个小问题要一个下午，不重构你后续功能没一个可以顺利快速搞起来的，我替你考虑，你还埋怨我？

哎哎哎，上面的那位童鞋不要乱讲，我设计架构的时候，也没想到现在业务这么变态啊，当时我可是按照标准的流行业务模式设计的。你没理解我架构精髓，就知道重构，你有问题哦你。

好了，打住打住，架构这话题太大，程序员自己都会pk起来，不和谐。

下面说一下我的理解和相应的对策。

问题1：信息不对称

产品人员往往认为，描述了功能需求，甚至简单的给一个竞争对手的范例，工程师就能完美的实现所有业务需求；但是，工程师对业务的理解往往是欠缺的，因此在产品的塑造上，很可能因为个人理解偏差，带来极大的随意性；即便是产品经理具有超强的控制力和投入，保证技术在功能实现上与使用场景吻合，但往往因忽略了业务的性能诉求，导致线下ok的东西，线上各种问题。

个人认为，让技术充分了解业务诉求，并参与业务讨论，是有必要的，只有这样，才能深刻理解产品的设计目标和设计要点，这样才能减少产品跑偏，与需求不符的现象。

问题2：尊重技术人员的时间观

工程师什么时候开发效率最高？我相信不止我一个人会有这样的感觉，凌晨1点-2点这段是时间，夜深人静，无人打扰，开发效率最高。应尽可能营造无打扰，无中断的开发环境；从设计代码到编程到测试，开发需要整段的时间来思考和实现，比如下午4点有个会，哪怕只有10分钟，等于一个下午没有效率。至少以我个人而言，是做不到可以随时中断，随时继续的开发水准。我几年前比较多的编程都是在半夜完成的。

所以，产品人员应当与技术人员勤沟通不错，但是请尽量将完整时间给工程师，比如早上上班后开沟通会，保证后续的完整性，下午午饭后立即开沟通会，或者用午餐会的形式，留给完整的下午时间给工程师，都是值得建议的方案。

问题3：理想主义情绪

开发人员往往有理想主义情节，希望所设计的架构可以支撑更广泛更持续的应用诉求；有时候产品人员也会有这样的想法，过于追求远大的宏伟目标；理想主义往往导致投入太多的无用功到无谓的兼容性设计上，而实际上，随着业务的发展和市场的变换，往往大部分提前准备的或者按照高端目标准备的设计，都是浪费的；其实，最重要的是把握当下的市场，互联网产品淘汰更新频率太快，未来是怎样，很多不确定的因素。

一个典型的架构悖论是，为了支撑更多更复杂的业务诉求，而设计了一个非常宏伟庞大的架构，但是新的诉求出现的时候，很抱歉，互联网发展太快，新的诉求超出了最初的预期，然后，因为架构太复杂太庞大，所以无法实现。

这事在著名的互联网上市公司是经常出现的。

轻架构，着重当下，代码做好低耦合就可以了，不用把架构弄得太复杂，而且，个人认为，最好的设计是，让后续的程序员（中等水平），不读文档，只看代码就能接手。