产品和研制

我比较喜爱的一个观念是，产品司理是事务方，研制的上游，某种程度上是研制的客户。从目前我就职过的公司来看，客户永远是第一位的，毕竟谁也不会和财神爷闹别扭，尽管研制的薪酬和产品司理没有毛联系，可是要知道代码本身一般没有任何价值（底层科技不算），产品司理的需求决定了产品的卖相，以及用户是否愿意掏钱买你的东西，只要用户愿意付钱，而且能够盈余，事务才有做下去的必要，产品和研制才有在公司的价值，可谓是一荣俱荣，一损俱损。

需求流程

一般便是下面这个流程 粗评-》详评-》实例化-》排期-》开发-》自测+联调-》测验-》上线

需求粗评——感性认知以及吐槽大会

粗评一般产品会拿完整的或许非完整的（可是全体逻辑已有，不是只要一句话的这种）prd，拉上研制、测验、UI、DA，一起对这个需求有个感性的认知，让你理解我要搞什么，这个流程我之前待过的公司是省略开会的，在详评前几天宣布完整的prd，给相关方一段时间自己了解下。这个时分研制除了要捋清全体流程外，往往还要对一些模糊点，一些鸿沟case进行质疑或许评论，甚至是这个需求到底有没有意义（想起了那个app跟从手机壳改动主题色的梗），毕竟有的时分产品或许也没有思考的那么全面。粗评和详评，是研制罕见的能够反客为主的阶段，吐槽需求的时分主张不留情面。

需求详评——规章制度上墙

粗评后，产品修修改改，研制看看代码，就该进行详评了，这个时分，作为专业的研制，一定要慎重小心，各种鸿沟case、模糊地带、可行性，一定要弄的明理解白清清楚楚，而且一定要落到prd的修改上，毕竟详评后往往就意味着规章制度的板子已经打印出来了，立刻就要挂到墙上了，这个时分假如由于研制没有考虑到等引出的需求改变或许功用不全，那就显得咱们不专业了。

实例化——先弄个草稿吧

现在的公司在写需求前要写实例化文档，之前我们的公司叫写RFC，中心是共同的，确定需求功用的架构规划和代码完成，拉上相应的研制进行评审，避免在开发过程发现不可挽回的坑点，确保项目质量和进度。 实例化文档仍是很有用的，之前的公司最早大家是不必写实例化文档的，代码全体表现了一个“百家争鸣”的局势，看代码的人憋屈，后续迭代的人难过。可是研制许多时分其实写实例化文档会流于形式，变成找在哪里写代码，这样的话往往就只考虑了全体的中心流程，忘记了鸿沟case和反常处理，可是往往这儿最简单出问题。有的实例化文档上尽管标识了反常情况和鸿沟case，可是往往流于形式，规模过大或许忘记了验证。可是，最近我悟了。TDD（测验驱动开发）便是在编写实践代码之前先编写测验用例，由于强调编写测验用例，这有助于确保代码在不断演进中仍能够正常作业。每个测验用例都相当于一个期望，有助于捕获潜在的缺点和问题。可是这种开发方式在客户端比较难搞，由于客户端跑一遍单测假如仅仅逻辑处理，还好，可是涉及到UI，跑遍测验UI用例关于大的项目跑一次几分钟，而TDD又强调频繁跑用例，就很麻烦。那么为何不找一个简易计划呢？有啊，将每个用例对应为一条日志，将所有用例对应输出的日志悉数写在实例化文档里，而且在开发过程中不断维护，当代码开发完成后，需要验证到每行日志都能走到，这样尽或许的确保功用完整性和质量，一起关于后续cr实例化文档或许cr代码的人，也能够参考实例化文档里的日志输出，一望而知。我称之为有客户端特色的TDD

排期

实例化后基本上就能够知道自己的开发工时了，可是仍是要根据需求的复杂度、事务的了解程度、开发者的水平，留一些buffer，毕竟延期了就显得不专业了。

开发/自测/联调/测验——力气活儿

真正的编码阶段，力气活儿了，没啥好说的。仅有要注意的是假如在测验阶段发现了bug，而且这个bug并没有包含在你的日志链路里，那么写进实例化文档，而且最好重新验证下你的日志链路。

上线——最终一颤抖

上线完成才是最终一颤抖，让你的产品真正直面用户了，产品、研制、测验、UI等所有人的汗水都在这一颤抖了，提前确定好放量节奏，而且确保客户端的开关等按期打开，盯一下数据目标，确保大家的汗水不要付之东流。

需求改变——蝎子蛰青蛙

《伊索寓言》里有个经典的寓言便是蝎子和青蛙，蝎子求青蛙驮它过河，青蛙不愿因，由于蝎子喜爱蛰青蛙，可是蝎子确保不会，青蛙就驮蝎子过河，游到一半蝎子仍是忍不住蛰了青蛙，青蛙不解，你不是不蛰我吗？蝎子说，没办法，这是我的天分。最终双双坠入河里。 这便是产品和研制的联系，产品需求改变是天分使然，可是研制不能做青蛙，需求改变要走需求改变的流程，研制默默消化是会带来开发风险的，当然这个事情要见机行事，人家就让你改个文案，你非得走个需求改变，那便是有点不近人情了。

最终

假如有什么是我想说的，那便是“请尊重流程，这样流程才能尊重你”。

关注我的大众号：’滑板上的老砒霜‘