一、笔记时间

  2021年7月10日

二、详情

  前面我们简单聊了一下产品与协议的关系，那么今天来聊一下在产品开发前，要不要先指定协议？

  这个不同的人会有不同的看法，有些人认为产品开发前指定协议会有极大的好处；而有些人认为产品开发前没必要指定协议，而是在开发的过程中来指定协议。这两种说法其实都有它的支撑点，比如说有协议的可以提前规避一些问题，且显得更加有规划；边开发边制定协议他会更加的灵便，也就是灵活性更高。

  那么到底要不要先制定协议呢？其实我是偏向于先制定协议的，我认为这样会有诸多好处，尤其是大项目或者多人/多团队合作的项目，提前制定协议是非常合适的。

  但是并不是所有项目都是大项目啊，那么非大项目是否可以不先制定协议呢？我觉得也可以，比如说产品工作量很小，而且是一个人就能完成的项目，像这种我们可以考虑边做边制定协议。因为这种小项目影响面积不大，但我不推荐这种方式。

  原因很简单，边做边制定协议会变得没规划、没计划，这样随机性过大，因此对于项目周期的把控度也很难。更何况边做边制定协议也就意味着会有很多事项会考虑不周全，很难做到以面的角度来看点的问题。我这样说其实也不难理解啊，因为人是有惯性思维的，一旦你进入到某一个细节去追求细节完美的时候，你就很难去全面的考虑问题。这一点对于我这种程序猿来说更加好理解，因为我们程序猿在做一个事情的时候思维是固定的，很难跳脱出来做很全面的测试，因此就出现了测试的岗位，测试为产品进行查漏补缺，而且往往程序猿与测试的比例是一比多，既一个程序猿得配多个测试人员。

  说了这么多，都是在说不先制定协议的缺陷，那接下来就说说先制定协议的俩大点优势吧。

  第一点优势是制定协议的过程是我们思考产品业务逻辑的过程。我是有亲身体验的，因为我最开始做产品规划的时候，想了很多，自认为已经思考很全了。另外加上我还把产品原型图做出来了，产品的前前后后我都已经思考过无数遍了。可最后制定软件协议的时候，却发现之前原型图中的产品不够完善，总是会漏掉一些小细节，让产品看上去有些缺胳膊少腿。缺胳膊少腿也许说得太严重了，但最起码把产品比作人的话，我们的产品不是一个非常健康的人。因此协议制定的过程是辅助我们完善产品的过程。

  第二点优势是多人或者多团队协作开发的优势。如果是一个比较大的产品，那么我们的产品往往是需要多个团队合作才能完成，那么怎么保证多个团队之间的粘合度？怎么保证团队间的工作效率？怎么让团队间的工作解绑？我觉得协议就是其中很重要的一部分。

  为什么说协议有助于解决第二点中的三个问题呢？以我初浅的认知，我认为协议的主要作用就是解决模块间的沟通问题。因此有了协议之后，我们负责各模块间的团队就都围着协议转了，这样我们所有的沟通就是产品和协议上的沟通，解决问题比较直观也比较快捷，这样就能够把我们开发产品的团队凝聚到一起，自然产品也就凝聚到一起了。

  再来看看团队间的工作效率和解绑问题。协议之所以能解决模块间的沟通问题，它的原因也是它的核心就是协议是有标准的。我们不同的团队都按这个协议标准来，那么我们的开发团队就能同时开工，不会出现谁需要等谁的情况，这样我们把串行的工作变成了并行效率怎么能不提高呢？因此协议能让我们的产品在尽量少出错的情况下有效的完成。而由于协议是有标准的，各团队之间只是根据协议来进行合作，因此各团队之间相对于来说是解绑状态，也正因为是这样我们不同团队才能同时开工从而提高效率。

  以上只是我的初浅认知和想法，欢迎各位道友指正！