事情是这样的...
研发进度沟通会，又陷入了死一般的寂静。
我们的研发团队已经在一个第三方集成的项目上奋斗三个星期了。然而，三 周后提测的这一天，我们才意识到：
方案设计行不通……
要死。
后端要进行重大修改，项目将延期至少两周……
此刻，我默默地责备工程师们不够勤奋慎重。但其实，他们肯定也在责怪我没有给他们足够的时间去研究。
最终我们接受了现实：团队决定再重新做方案调研。 我们最终交付了这个项目，代价是大大落后于原来的时间表。
在我们进行迭代回顾的时候，有一件事变得很清楚： 我作为产品经理做了一些预设；这些预设被放进了方案里；技术团队相信这些预设是真的，并且开始工作。
问题：我没有花时间去了解这个项目的复杂性。如果我在早期就让技术团队参与进来，我们不会落得如此下场。
我得到的教训也很直接：作为一个产品经理，理解技术对于项目成功来说至关重要。
接下来，我将讨论新手PM可能会遇到一些问题，并给出我的回答。
为什么PM应该了解技术
了解技术可以在以下方面帮助每一个产品经理：
有助于在你的团队中建立信任：开发者喜欢那些试图理解他们的难点并愿意协作配合解决这些问题的PM。
提高想法的质量：在了解技术之后。你能知道什么是可能的，什么是不可能的，所以你的想法是以现实为基础和可实施的。
在确定项目的范围方面变得更准确细致：如果你了解什么会增加技术的复杂性，你就可以更好地进行权衡。作出权衡是按时交货的一个非常重要的技能。
提高效率：你的产品需求和规范文件将会更加全面。因为与技术负责人/EM的合作良好，大部分重要的技术考虑都被提前搞定了。
识别项目相关的复杂性：你能更好地理解和项目相关的复杂性。这有助于你了解可能会遇到的风险并设法把风险降低。非常复杂的项目通常需要在全面开始之前先进行POC测试。
产品经理需要了解多少技术？
只有对技术的理解达到一个较高层次, 你才能够回答以下问题：
构成你产品的不同技术栈是什么？
这些系统中的运行逻辑是什么？
与各系统相关的主要风险有哪些，怎么规避？
哪个系统是由哪个团队管理的？
这些系统之间是如何关联的？ (例如: APIs)
产品经理如何了解一项技术？
话不多说，看图。
在会议结束时，你应该已经有了一张简易的流程图或架构图…
你可能不会理解所有的细节。那也没关系。专注于理解所使用的术语以及它们所起的作用是什么更为重要。
重复以上循环，日积月累，你对技术的理解力自然会提升。
进阶技巧：加深对技术的理解
其实仅仅和工程师坐一坐聊一聊并不能让你了解完整的情况，了解技术是很难的，需要产品经理们的不懈努力壮志雄心。
以下tips非常有用，请有志精益求精者认真食用~
把每个新项目作为学习机会
一旦你决定优先考虑某项功能，就请技术团队参与进来。 从他们那里了解：
- 哪些层面会受到影响？前端，后端，基础设施等……
- 每一层会涉及多少量级的开发工作？ 理解构建该功能所涉及的技术难点。
这将使你对技术架构、所涉及的系统、复杂性的来源，都有清晰的认识。一个项目涉及的层数越多，复杂度就越大。
从技术故障中学习
生产环境中的问题和技术难点，是另一个了解技术架构的绝佳机会。
如果这个问题影响了你关注的领域，请与工程师坐下来了解具体情况：
1）哪个系统受到影响？2)原因是什么？3)我们能做什么来防止问题复现？
重复这个循环，将帮助你建立围绕系统本身及其薄弱的环节的分析框架。
或许一段时间后，你会发现：
提升系统鲁棒性是优先级更高的事。
我还应该牢记什么？
当你开始这段学习的过程时，还必须牢记以下几点。
不要害怕问问题：不管这些问题有多蠢，总是要去问。你问得越多，你得到的信息就越清晰；
可视化有助于你更快地理解事情：在与工程师交谈时，如果事情超出你的想象，请他们在纸上画出来解释。
工程师们喜欢那些试图理解他们的语言和难点的PM：不要对他们的关切置之不理。与他们一起工作，认识到他们预见的难点和如何解决这些问题的方法。
不要用你新发现的知识告诉开发人员 "如何实施"：这样会被暴打，而且你会显得很傲慢且瞎指挥。
深度学习技术方案有无数的好处，因此产品经理最好不要犹豫，在项目初始就开始了解它。这件事起步可能很容易，但最重要的是如何坚持这样做。
当然也不必过于紧张，这将是一个非常有价值的学习过程。