上一篇咱们现已承认了 PRD 和 UI，接下来咱们持续了解「研制测验」的进程。
尽管标题是叫「研制测验」，可是咱们千万不要以为这个进程只要研制小哥哥和测验小姐妹的参加。是的，作为产品 owner 的产品司理和参加规划的 UI 同学都是需求参加「研制测验」这个进程的。仅仅产品司理参加度比较深，需求和各个人物协同沟通；UI 同学参加度略微比较浅，大多只需求和前端沟通，确保前端同学最大复原自己的规划稿。
作为产品司理，你必定不要成为沦落到只写 PRD 或只画原型。由于假如仅仅纯规划，不参加开发进程，许多规划问题你彻底是认识不到的。比方：咱们在做操作日志的时分，有个规矩是人物「管理员」能够看到所有人的操作日志，其他人物只能看到自己的操作日志。
其时，我在规划【操作日志】界面的查找时，便是共同依照「操作人」、「操作时刻」做为筛选项，可是在真实开发进程中，由于需求对「操作人」做权限判别，就略微比较费事，终究经过评论，咱们将「查找项」拆分为：
其实假如不是深度参加整个开发进程，一些规划的问题自己或许很难发现。当然，相似的比方还有许多。
之前听过这样一个比方，领导把研制做的终究界面发到群里：“这是谁规划的界面”，群里一片幽静。做规划图的 UI 跟我讲，由于研制做出来的作用和自己的规划图彻底不相符，乃至能够说是两张图，那我为什么要供认。
我不知道这位 UI 在说这句话的时分有没有认识到这个问题，可是我信任有许多 UI 面临着相同的疑问。研制不依照我的规划图开发的时分，应该怎样做？
其实 UI 参加研制测验的进程就能够处理这个问题了，作为 UI 千万不要以为你的图做完了，你的作业就做完了。我之前一直在考虑UI 规划的结尾，是完结 UI 图？仍是检验前端开发成果？乃至是盯梢线上用户反应，并依据用户反应改善规划？尽管我还没想到更合理的答案，但我以为从完结 UI 图到依据用户反应改善规划，每往前走一步，对 UI 来说都是一个里程碑式的前进。
研制阶段和测验阶段的分界点，能够简略经过测验人员是否介入来判别。假如测验人员没有开端测验，那便是研制阶段；假如测验人员开端测验，那便是测验阶段。
瀑布开发形式瀑布开发形式，也叫瀑布模型（Waterfall Model），是指软件开发进程是依照一系列次序打开的，刚开端是需求剖析，然后是产品规划，然后是编码，然后是测验，然后才是上线。由于开发进程是一步一步进行的，所以才被成为瀑布模型。和瀑布模型相对应的也是现在业界比较盛行的是「灵敏开发」，感兴趣的小伙伴能够了解下。
单调的流程介绍完了，咱们来看下每次项目发动的严重时刻。首要，这儿是把产品的一个开发周期（或一个迭代）称为项目。
主要是产品司理预备啦，平常我都是提早预备好 PRD、UI 图，然后定好会议室，等候这一严重的时刻到来。
每次都会提早一天左右预备好这些材料，可是在会前做终究的查看时，总是会发现这样或那样的小问题。有人告知我，今日的规划明日在来看的时分，或许又会有新的主意冒出来。嗯，总是感觉不到终究一刻，我就不会中止修正。
所谓的项目发动，能够了解为把需求参加这个项目的人拉在一个会议室里开个会，告知咱们：
嗯，是的，这儿没有阐明「Deadline」。假如你定了一个 Deadline，而你的团队成员都不认可，其实这个 Deadline 是形同虚设的。咱们在做项目的时分，都是在发动会之后给团队成员半响到一天的时刻了解需求，然后让咱们来领使命，然后每个人预估时刻，预估完结之后进行终究的调整，并设置一个咱们都认可的 Deadline 作为项目的截止时刻。
有读者跟我说，你这个系列讲需求，都讲了许多篇了，自始至终都是再讲需求。我……没办法，产品便是离不开需求，假如你不了解，只能说你还需求修炼。
由于项目发动的时分需求跟团队成员解说需求，所以此刻需求也会有小规模的调整，可是大规模的需求列表（也便是当时项目要做哪些需求，即项目的规模）是不太简单变化的。除非老板要求这个版别提早上线，咱们会暂时砍掉一些需求以确保上线时刻。其它时分，不太简单有项目规模的变化。
换句话说，项目发动之后，需求列表就承认了，也便是俗称的「需求冻住」。需求冻住之后，不是说需求就不能改了，仅仅不能再添加了。
假如一味地往一个项目里添加需求，一来团队成员总觉得需求做不完，或许冲击团队成员的积极性，二来项目发动其实就没什么含义了，由于开不开作用是相同的。
至于项目发动之后，需求能改动到什么程度，主要看团队成员之间的协作。假如是初度协作，不主张改。当然，这并不是意味着协作次数多了，就能够随意改。好吧，我更正上句的说法，不管是什么时分，最好不要更改。当然，从我本身的经历看，这点的确很难做到，不过，能够极力一试～
削减现有的需求列表删需求对咱们来说都是一件功德，究竟咱们都能够少做点作业。不过，决定做这件「大快人心」的作业时，仍是需求跟团队成员解说为什么要这么做，让团队成员之间不要有误解，也不要有不信任。究竟，你想，假如人家刚做完，你就给人把需求砍了，这谁心里会舒畅啊。
调整现有需求列表的细节最好能不调整，可是假如真的要调整，最好在沟通需求的时分就阐明「这儿还需求承认，后续承认之后再沟通……」，让团队成员心里有底。假如后续真的需求调整，咱们心里也会略微舒畅点，一同，提早沟通好后续或许会有的变化，咱们在预估作业时刻的时分也会留有余地，避免后续由于需求的调整使得某位成员加班赶工期而导致其心里不爽快。
添加需求相对来说，「添加需求」这一点最难处理。假如你直接以「老板说的」为托言，其实仍是很好处理的。可是一朝一夕，会给他人一种「你没有独立思考才能」的感觉，由于你凡事都是「听老板的」。我现在能想到的更合理的做法是，先「讲道理」阐明为什么必定要这么做，然后「从头评价需求优先级」，由于有需求暂时「参加」，看有没有哪些需求能够暂时移到下一个版别。这样经过调整之后，咱们心里略微舒畅些。一同，假如真的无法把其它需求移到下一个版别，咱们也略微能了解。
项目发动之后，咱们就开端完结自己的使命了。作为产品司理，要及时和研制沟通，避免由于规划不合理或许规矩不合理导致研制使命很难完结。比方：最近咱们有个「完毕日期不选即为至今」的需求，研制在完结的进程中就遇到了许多问题。由于在许多人的了解中，「至今 = 今日」，这样的了解会有一个潜在的规矩「开端日期不能晚于今日」，否则会进入一个悖论的状况。
经过沟通，我才发现「至今」的案牍不行精确，由于我想要表达的是「开端日期之后的某一天」，而「至今」在冥冥之中添加了一条规矩，而「开端日期晚于今日」在事务上是合理的。比方：咱们在定 OKR 或做年度计划的时分，「开端日期」肯定是会晚于今日的。这样的状况在实践作业中还会遇到许多，举这个比方仅仅想阐明，研制进程中的沟通是十分必要的。
新人产品司理还会常犯一个过错便是，当产品司理和研制 A 沟通之后，然后就不自觉地以为现已沟通完了。但真的是这样吗？莫非不需求和团队其它成员同步沟通成果吗？
刚开端作业的时分，我总会忘掉和团队其它成员同步沟通成果，这就导致和 A 说过的作业，测验 B 要问一遍，项管 C 还要问一遍，沟通功率极低，并且从心情上也会有所冲突。其实，便是在群里发个音讯，一句话的作业就能处理的问题，为啥非要搞这么费事呢？自此，我就学聪明晰。
产品司理参加是为了确保测验了解的需求和自己想要的共同，由于产品终究是由测验来检验的，假如测验和产品司理了解的不共同，那终究出来的产品会和幻想之中距离比较大。
为什么研制需求参加？由于测验用例和研制编写的代码休戚相关。灵敏开发中有一条便是要求研制依据测验用例编码，以下降 Bug 率。
作为产品司理，免不了要跟其它部分的人协作。那怎样处理跨部分沟通的作业呢？
由于跨部分协作的时分，经常出现所谓的「职责不明确」现象，文字留底是为了维护自己。
好的，今日这篇文章到这儿就完毕了，咱们的《一个项目带你走进产品司理的国际》系列文章完结进展如下：黄色为当时进展～
佐珥，微信大众号：产品碎月（ID：pm_lab），人人都是产品司理专栏作家，专心互联网产品，乐于经过幽默诙谐、图文并茂、结合实践的文字共享自己的产品经历，希望同咱们一同高兴生长
我想问一下，您这个研制测验与项目发动是分隔的吧？项目发动指的是迭代？仍是？
听到许多言论说在我国程序员是吃芳华饭的，那么产品司理呢，也吃芳华饭吗？
人人都是产品司理（是以产品司理、运营为中心的学习、沟通、共享渠道，集媒体、训练、社群为一体，全方位服务产品人和运营人，建立9年举行在线+期，线+场，产品司理大会、运营大会20+场，掩盖北上广深杭成都等15个城市，在职业有较高的影响力和闻名度。渠道聚集了很多BAT美团京东滴滴360小米网易等闻名互联网公司产品总监和运营总监，他们在这儿与你一同生长。
