产品和研发
我比较喜欢的一个观点是，产品经理是业务方，研发的上游，某种程度上是研发的客户。从目前我就职过的公司来看，客户永远是第一位的，毕竟谁也不会和财神爷闹别扭，虽然研发的工资和产品经理没有毛关系，但是要知道代码本身通常没有任何价值（底层科技不算），产品经理的需求决定了产品的卖相，以及用户是否愿意掏钱买你的东西，只有用户愿意付钱，并且能够盈利，业务才有做下去的必要，产品和研发才有在公司的价值，可谓是一荣俱荣，一损俱损。
需求流程
一般就是下面这个流程 粗评-》详评-》实例化-》排期-》开发-》自测+联调-》测试-》上线
需求粗评------感性认知以及吐槽大会
粗评一般产品会拿完整的或者非完整的（但是整体逻辑已有，不是只有一句话的这种）prd，拉上研发、测试、UI、DA，一起对这个需求有个感性的认知，让你明白我要搞什么，这个流程我之前待过的公司是省略开会的，在详评前几天发出完整的prd，给相关方一段时间自己熟悉下。这个时候研发除了要捋清整体流程外，往往还要对一些模糊点，一些边界case进行质疑或者评论，甚至是这个需求到底有没有意义（想起了那个app跟随手机壳改变主题色的梗），毕竟有的时候产品可能也没有思考的那么全面。粗评和详评，是研发少有的可以反客为主的阶段，吐槽需求的时候建议不留情面。
需求详评------规章制度上墙
粗评后，产品修修改改，研发看看代码，就该进行详评了，这个时候，作为专业的研发，一定要慎重小心，各种边界case、模糊地带、可行性，一定要弄的明明白白清清楚楚，而且一定要落到prd的修改上，毕竟详评后往往就意味着规章制度的板子已经打印出来了，马上就要挂到墙上了，这个时候如果因为研发没有考虑到等引出的需求变更或者功能不全，那就显得咱们不专业了。
实例化------先弄个草稿吧
现在的公司在写需求前要写实例化文档，之前我们的公司叫写RFC，核心是一致的，确定需求功能的架构设计和代码实现，拉上相应的研发进行评审，避免在开发过程发现不可挽回的坑点，保证项目质量和进度。 实例化文档还是很有用的，之前的公司最早大家是不用写实例化文档的，代码整体体现了一个"百家争鸣"的局面，看代码的人憋屈，后续迭代的人难受。但是研发很多时候其实写实例化文档会流于形式，变成找在哪里写代码，这样的话往往就只考虑了整体的核心流程，忘记了边界case和异常处理，但是往往这里最容易出问题。有的实例化文档上虽然标识了异常情况和边界case，但是往往流于形式，范围过大或者忘记了验证。但是，最近我悟了。TDD（测试驱动开发）就是在编写实际代码之前先编写测试用例，因为强调编写测试用例，这有助于确保代码在不断演进中仍能够正常工作。每个测试用例都相当于一个期望，有助于捕获潜在的缺陷和问题。但是这种开发方式在客户端比较难搞，因为客户端跑一遍单测如果只是逻辑处理，还好，但是涉及到UI，跑遍测试UI用例对于大的项目跑一次几分钟，而TDD又强调频繁跑用例，就很麻烦。那么为何不找一个简易方案呢？有啊，将每个用例对应为一条日志，将所有用例对应输出的日志全部写在实例化文档里，并且在开发过程中不断维护，当代码开发完成后，需要验证到每行日志都能走到，这样尽可能的保证功能完整性和质量，同时对于后续cr实例化文档或者cr代码的人，也可以参考实例化文档里的日志输出，一目了然。我称之为有客户端特色的TDD
排期
实例化后基本上就可以知道自己的开发工时了，但是还是要根据需求的复杂度、业务的熟悉程度、开发者的水平，留一些buffer，毕竟延期了就显得不专业了。
开发/自测/联调/测试------力气活儿
真正的编码阶段，力气活儿了，没啥好说的。唯一要注意的是如果在测试阶段发现了bug，而且这个bug并没有包含在你的日志链路里，那么写进实例化文档，并且最好重新验证下你的日志链路。
上线------最后一哆嗦
上线完成才是最后一哆嗦，让你的产品真正直面用户了，产品、研发、测试、UI等所有人的心血都在这一哆嗦了，提前确定好放量节奏，并且保证客户端的开关等按期打开，盯一下数据指标，保证大家的心血不要付之东流。
需求变更------蝎子蛰青蛙
《伊索寓言》里有个经典的寓言就是蝎子和青蛙，蝎子求青蛙驮它过河，青蛙不愿因，因为蝎子喜欢蛰青蛙，但是蝎子保证不会，青蛙就驮蝎子过河，游到一半蝎子还是忍不住蛰了青蛙，青蛙不解，你不是不蛰我吗？蝎子说，没办法，这是我的天性。最后双双坠入河里。 这就是产品和研发的关系，产品需求变更是天性使然，但是研发不能做青蛙，需求变更要走需求变更的流程，研发默默消化是会带来开发风险的，当然这个事情要见机行事，人家就让你改个文案，你非得走个需求变更，那就是有点不近人情了。
最后
如果有什么是我想说的，那就是"请尊重流程，这样流程才能尊重你"。 
关注我的公众号：'滑板上的老砒霜'