为什么PM应该懂技术

出于保密的目的，我隐去所有的技术细节以及项目名称，讲述一个真实的故事。

事情大概是这样的：PM让我把A和D结合到一起，让A给D发消息，这样就能把消息发给用户了。所以一开始的数据流是这样的： $A \to D \to user$

我去问了D项目组的同事，说除非是以前就用到了D的代码，否则请使用C，C会把消息转发给D。所以数据流变成了这样： $A \to C \to D \to user$

在这种情况下，似乎已经变得非常靠谱了，于是我就去把A和C两个项目进行对接。但是又找别的同事聊了聊天，发现还是不对，因为会丢失信息，需要再加一个中间层B。所以数据流是这样的： $A \to B \to C \to D \to user$

$A \to B$实际上就写在我们A的项目代码里面。B能够到C几乎是所有人都知道的事情。C和D在外界看来就是同一个东西。

因此，我的分析是，对于PM，如果他说让我把A和D结合起来，本质上是和说把A和C结合到一起是一个意思。如果这里他知道这么一件事情，那么事情会变得更简单一些，但是不知道也不怪他，因为只有接触过这两样东西的人才知道。

我假设PM并不是少数人，他也是知道B可以到C的，但是他不知道A可以到B，因此就告诉我应该从A到D。而实际上他懂技术的话，就可以告诉我任务实际上是 $A \to B \to C$ ，一下可以省去很多交流成本。

所以，我认为PM该懂技术，实际上并不一定要搞懂技术细节，而应该搞懂一项技术与外部的交互是什么样子的。

=================================================================================

再从另外一个角度讲述这个相同的故事。

PM让我在一个动态监视的代码中加一部分静态监视代码。这个是不可行的。这个不会涉及到很深层的技术细节，只需要少部分的计算机常识。动态监测必须是主动发出信号，在我们组使用的方法是轮询。轮询会占用大量的资源。静态代码的主要好处是占用很少的资源。如果把静态监视放到动态监视当中，就会占用大量的资源，就失去优势了。因此不应该这么做。所以如果PM懂技术，那么就不会有这样的想法了。

=================================================================================
问题的解决方案已经有了，就是用 $A \to B \to C \to D \to user$ ，因为 $B \to C$的过程中，可以屏蔽掉轮询的环节，达到节约资源的目的。

很久没有写博客了，又太忙了，就简单写一下吧。格式什么的请不要在意。