为什么PM应该懂技术

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

事情大概是这样的:PM让我把A和D结合到一起,让A给D发消息,这样就能把消息发给用户了。所以一开始的数据流是这样的: A → D → u s e r A \to D \to user ADuser

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

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

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

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

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

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

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

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

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

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

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

你可能感兴趣的:(开发实记)