本人一年多产品经验菜鸟，这篇文章主要是对自己的工作进行复盘之余，也希望能够为一些刚刚工作的或者正想入坑的产品新人一些理解和思考。
ps：本篇文章只是对工作流程的基础总结，每个工作节点不会特别细致的进行展开，没讲到位的地方大家互相交流，如有不合理处请指导，勿喷勿喷哈哈哈哈～～～
一、产品经理&项目经理职责边界
1、介绍
本菜鸟就职于一家致力于为B端做企业信息化服务解决方案的中小型公司，所以产品的输出形式基本上都是以项目的形式来进行和交付。在日常的工作中，我们产品经理不仅要做好职责之内的工作，同时我们也会有涉及到项目经理的一些工作。因此我们的工作职责相较于打造自研产品的互联网公司来说，可能更加琐碎，横向的学习和发展会更多一些，但是对于垂直行业的经验积淀来说，就比较少了。
2、产品经理职责
（1）机会评估
工作内容：整理产品方案、评估需求成本
主要节点：项目预研阶段
主要参与：项目经理（整理整体方案）、产品经理（整理产品方案）、技术经理（整理技术方案，评估技术可行性）、商务经理（配合对需求把关）
（2）需求收集
工作内容：包括但不限于以下几种方法：用户访谈、头脑风暴、卡片分类、问卷调查等等
主要节点：项目预研阶段
主要参与：整个项目组
（3）需求管理
工作内容：PRD需求文档、需求管理文档
主要节点：项目计划阶段
主要参与：产品经理
（4）需求设计
工作内容：产品架构图、功能结构图、业务流程图（UML）、UE原型
主要节点：项目实施阶段
主要参与：产品经理
（5）需求评审
工作内容：项目组成员评估需求可行性和工作量
主要节点：项目实施阶段
主要参与：整个项目组
（6）需求实施
工作内容：各岗位成员按照需求进行设计，并及时沟通需求细节
主要节点：项目监控阶段
主要参与：整个项目组
（7）产品验收
工作内容：根据需求和用例进行验收
主要节点：项目交付阶段
主要参与：产品经理
3、项目经理职责
项目经理的工作流程大致可以分为项目预研、项目启动、项目计划、项目实施、项目监控、项目交付几个阶段。
（1）项目预研：
项目组前期预备阶段，此时不一定会对该项目进行正式立项，仅仅作为售前支撑需要成立的临时项目组
工作内容：整理项目建设方案
主要参与：项目经理（整理整体方案）、产品经理（整理产品方案）、技术经理（整理技术方案，评估技术可行性）、商务经理（配合对需求把关）
（2）项目启动：
在此阶段我们首先应该成立项目组进行立项，正确的识别干系人，并将各岗位的人员确定下来，方便后续的工作正常进行。
工作内容：确定项目组成员、明确项目干系人的期望、明确项目目标、明确项目需求、项目计划排期
主要参与：整个项目组
（3）项目计划：
在此阶段主要是对需求进行拆解成任务进行分配，并由各岗位负责人对任务进行工期估算，进行排期
工作内容：任务分配、工期估算、时间进度安排（甘特、燃尽图）、风险控制、版本管理
主要参与：整个项目组
（4）项目实施：
在此阶段各岗位工作进入设计，并进行评审。
工作内容：需求设计&评审、UI设计&评审、代码设计&评审、测试用例&评审
主要参与：整个项目组
（5）项目监控：
在此阶段主要对项目进度进行跟进，及时更新任务状态，提前对风险进行预警
工作内容：每日例会、每日日报、每日任务更新、人员表现、风险预警
主要参与：项目经理
（6）项目交付：
在此阶段对项目进行内部验收，并整理需要交付的文档
工作内容：验收报告、上线报告、需求文档、数据库设计文档、接口文档
主要参与：项目经理
二、项目型产品经理工作流程
1、项目预研
项目预研阶段（各公司可能叫法不同），如字面意思就是项目在前期进行预先调研，研究。在此阶段会先成立一个临时项目组，甚至于可能就只有一个人去进行前期调研，按照以往相似的案例或者网上的案例整理出来项目的可行性方案和建设方案。以下图1为我们常用的建设方案文档结构目录。
大家可以发现，对于我们产品经理的工作而言，在第二部分（项目需求分析）和第四部分（平台功能介绍）是我们主要的工作内容。所以可能在项目之初，我们就要配合进行需求调研，输出一些初期的文档，如产品需求文档（以下节点再展开说明）、产品的架构图、产品功能结构图，根据客户需要甚至于会输出部分原型图。如下图2为我司预研的项目架构图，图3产品功能结构图
2、项目启动
在此阶段我们首先应该成立项目组进行立项（一般会组织开一次项目启动会议），正确的识别干系人，并将各岗位的人员确定下来，方便后续的工作正常进行。
工作内容如下：
（1）确定项目组成员
一个项目的启动，一般来说第一步是需要确定项目组的成员，然后必须明确项目经理即项目负责人。我们公司一般是在项目启动时，先自己大致评估需要的人员配置，然后和各部门的负责人评估和确定项目组成员。如下图4所示：
（2）明确项目干系人的期望
在《软件需求工程第3版》-KarlWiegers的书籍中有说到项目干系人应该包括所有和项目有关的人，包括商务和客户。所以在此处，项目经理或者产品经理需要阐述来自客户对该项目的期望，通俗的讲即为客户需求。同时可能还有包括来自项目干系人各方面的期望，比如小公司的老板可能也会直接参与项目，希望将该项目的某些文档，代码标准化下来作为案例能够对外进行销售。又比如说商务期望开发周期尽量缩短，先给客户交付一个基础产品，能够尽快回款。总之我们需要在启动会议将干系人的期望共同进行探讨，并达成项目组的共识。一般来说此处不一定会生成专门的文档，通常都是会议纪要同步邮件。
（3）明确项目目标
项目管理中，不论是瀑布开发还是敏捷开发模型，都必须会要确定项目目标。比如确定项目计划，确定里程碑，确定项目章程。还有包括交付时的流程，需要哪些文档，有什么交付标准（注意此处在很多小公司都很随意，但是我们公司是真实吃过亏的）我们有以前开发的一个项目当中，在项目前期由于客户对工期的要求比较紧急，而且项目初步预测是比较简单的，所以在商务阶段就过早将项目启动，然而交付的流程和交付标准都没有确定（因为一开始觉得客户还是很好说话的，所以大家都很配合）。结果天天加班赶着交付时间进行交付之后，由于没有明确的交付标准，所以客户反复提出更多一些想法，对体验的优化等等（当然我很理解客户希望能够收到一个心满意足的拥有极致体验的产品，但是用户的需求随着不同的阶段，使用的增加会有更多的需求，不然何来的敏捷开发呢哈哈），但是客观上来说，我们项目组预计本应该释放的资源缺迟迟抽不出来，几乎往后的很长一段时间都保持着极高频率的迭代优化期。
（4）明确项目需求
这一部分主要是对需求进行评审（由于在预研阶段产品经理基本都会对需求整理一份初步的文档），项目组成员对需求进行评审，除了砍掉不合理需求之外，也要对合理的需求按照优先级进行大致的排期。当成员达成共识后，由各岗位的负责人评估工作周期。
（5）项目计划排期
最后就是对项目计划进行排期，首先这个项目完全交付，分成几个阶段，每个阶段的时间安排周期，在这个阶段内，各岗位成员做什么，时间周期多久。都应该列出来一份文档，或者利用项目管理工具进行管理，此处可以用到甘特图进行管理，或者一些项目管理工具，如禅道、TAPD、Teambition等等，如下图5。（此时项目计划排期颗粒度还比较大，主要是明确每个岗位的工作节点）
3、需求收集
对于项目型产品来说，直接用户是相对较少的，而且我们的每一个客户基本都属于我们的特征客户（不然他们不会花钱来使用），所以客户来源相对容易，但是我认为需求收集还是至少要分成两种情况来确定收集方式。
情况一：项目还未交付
对于需求收集来说，从0到1阶段其实是比较难的。首先你的大部分需求是直接来自于你的客户，但是客户提出的需求很多是不合理的，并且可能并不是来自于他的真实诉求，可能说只是觉得同类型的产品有，那么就要。这个时候就比较考验产品经理的需求分析能力了，客户直接提出的必然是显性需求，那么你是否能够透过现象看到本质，挖掘出客户的隐形需求，并提出解决方案去给客户选择（此处《软件需求工程》有专门讲解显性需求和隐形需求）。
主要收集方式：
用户访谈：此方法是我在该情况下常用的方式，大佬们都说过让用户定义产品嘛。主要是通过和客户进行当面的沟通，通过一些事先准备的问题引导客户说出他们的需求。但是往往不专业的客户在没有看到实物的时候并不知道自己需要什么，想法和需求都来源于目前线下传统的流程之中。如果单纯按照客户的业务需求直接搬到线上来，其实是不一定会真正让客户获得优质的体验，甚至可能加大用户的使用门槛（毕竟很多传统行业的领导连智能手机和电脑都用不习惯，还只局限于通讯需求）
头脑风暴：此方法其实在行业内比较常见，主要就是让项目组成员能够针对该项目，提出自己的想法，设想可能存在的需求。因为从0到1阶段，客户是没有概念，他们甚至说不清楚他们要什么，所以我们可能会提前先通过网上找案例等方式先项目组讨论，确定一个我们都认为可以的需求，然后再去找客户去讲解，在这个过程中就经常能够引导出来用户的需求，客户经常会提出，这个地方我们可能不是这样做的，我们可能不需要。
卡片分类（项目组）：卡片分类也是行业内很常见的需求收集方式，主要是通过列出所有的需求，让每位成员按照自己的理解去对需求进行分类，划分结构层级。我在此方法后面加了个小括号（项目组），还是因为客户对需求没有概念，他可能都不知道这个功能有什么用，实现出来什么样子，怎么交互的。如果让客户在这个阶段参与这个过程会对分类造成很大的误差。所以我们暂且是靠项目组各位成员的经验来进行的。
客户需求评审：这一个阶段就是将整理好的需求，或者设计的原型给客户进行讲解、演示。在这样的情况下，客户大概能知道这个产品的雏形是什么样子，自然而然的就会提出一些他的需求（这个其实是效率比较高的方式）
情况二：至少已经有同类型交付的产品（或迭代期间）
在这样的情况下一般是客户已经比较了解同类型产品或者是已经在使用我们的产品。那么客户往往会提出各种各样的问题，这个时候主要的工作并不是需求来源，而是对需求的合理性进行把控，即便合理的需求也有可能很多（因为往往从0到1的产品功能比较基础，一般以满足客户的必备需求为主，所以还有很大的优化空间），这个时候你要将收集来的需求进行简化、并合理的进行排期。
主要收集方式：
客户建议反馈：在这种情况下最主要的需求来源必然是在使用我们产品客户，所以直接问客户就好了，当然你不问他他也会找你提出来的，具体把控下节“需求管理”再展开。（表示我现在被几个负责项目的客户穷追不舍）
测试反馈：如果你们公司有个好的测试真的会很幸运，一个好的测试能为产品经理减少很多麻烦。测试最主要的输出文档之一就是测试用例，测试用例理应覆盖整个产品的方方面面，那么在测试整理测试用例的时候，或者日常进行测试的时候。很有可能就会发现在评审之初没有发现的需求不合理之处，尤其是对于用户体验的问题测试经常能够发现。
4、需求管理
在此阶段至少需要两个文档：需求管理文档、PRD需求文档。
（1）需求管理文档：在上述需求收集中说过，客户可能会提出非常多的需求，并且中间包含很多不合理的需求。这个时候即便是经验很丰富的产品经理，也应该将所有的需求收集起来。一是因为你可能一时之间无法很清晰的作出决定来判断这个需求是否合理；二是因为客户经常提出的需求只是随口一说，说完就忘记了。当他下次再提出的时候，可能规则就改了，即便两种实现方式都是合理的，但如果你没有记录会导致项目组又会重新进行返工。所以我们需要一个需求管理文档来记录收集来的用户需求，如图6所示：
然后每过一段时间（具体按公司业务规范而定）项目组开会进行一次需求评审。一般来说影响业务流程的需求是优先级比较高的，客户的必备需求也是优先级比较高的，至于客户的期望需求，界面友好性的需求相对来说优先级会低一些。当然这是在开发资源有限的情况下不得不划分优先级。然后将评审通过的需求按照优先级进行排期，并将同期的需求建立一个文件夹，存放该期相关的资料。如下图7、图8所示：
（2）需求文档：
对于需求文档，网上已经有很多成熟的模版了，不一一展开细说。但是我们往往能看到大厂的需求文档非常全面，细致到无可挑剔，但是当我们做项目赶工期的时候，你可能连整理需求文档的时间都没有，更不用说做到那么细致了（其实这样在软件开发当中是很不规范的，因为没有想清楚的需求到后期再返工可能带来的工作量会非常大，但是出于现实客观情况，小公司为了业务会在极短的开发周期内交付，但是人员配置却不会增多）。这个时候可能要引用一句敏捷宣言即：工作的软件 高于 详尽的文档。当你来不及整理详尽的文档的时候，你就要善于利用工作的软件了，我将在第六节“需求设计”中展开说明（但是之后一定要要将需求文档补上，不然项目交接或者有新同事加入的时候可能会漏掉很多细节）。
5、项目计划
在此阶段主要是对需求进行拆解成任务进行分配，并由各岗位负责人对任务进行工期估算，进行排期。
在需求管理中已经说过要将需求进行评审的时候进行工期评估，将需求排期，那此处为何又要做一遍呢？这个我要解释一下：其实在很多大型软件项目开发中，可能是由很多个团队共同开发的，甚至可能细致到一个功能模块都有一个单独的团队进行开发。而进行一个需求实施时，测试要写用例，保证需求是可以测试，可以量化，是合理的。而前端开发又需要对开发的框架进行搭建、对页面进行布局、做接口联调几个流程，后端开发同样要搭建框架、部署服务器数据库、理解需求建立数据库表、再进行接口设计、以及配合前端进行接口联调等几个流程。所以一个需求要完整的实现，中间可能包括了项目组成员的很多个任务，这时就需要项目经理来对任务进行拆分，评估任务工期，来保证项目的可控。在此阶段我们公司使用的项目管理工具是禅道，所以我用禅道进行演示：
（1）任务分配：具体按公司的开发流程来拆解，如下图9所示：
（2）工期估算：这个因为每个人的工作效率不一样，肯定是不能由项目经理直接定的，一般是由各任务人员自己评估工期，再由项目经理检查，如下图10所示：
（3）时间进度安排：此处的进度安排是聚焦到每一个任务的安排始末时间，一般的项目管理软件都有这个功能，如下图11所示：
（4）风险控制：当你把以上事项做完之后，你就能够统计出来项目完成需要多久的时间，哪些任务容易完成，哪些任务不容易完成。如果时间超出了项目交付时间，你就不得不像负责人要人了，至少有数据支撑你也有底气一些对吧。在这部分主要确定整体完成时间，是否会延期、一些不容易完成的任务如何解决、部分任务需要提前准备其他条件（如部署小程序需要先申请注册小程序并微信认证之类的），当你收集好这些问题之后你作为负责人你就需要将这些问题进行反馈和跟进了。
（5）版本管理：你是否有遇过这样的情况，当你的V1.0版本还存在迭代的时候，V2.0的大版本就进行开发了，这是很常见的，那么此时你就需要安排好每个版本哪个项目组做什么任务。我们根据公司的开发现状定了一个版本管理的规范：
【生产环境】作为线上稳定正式版本，供所有用户开放使用。
【测试环境】作为上个版本号（即当前线上版本）bug维护，和交付给甲方测试验收使用。
【开发环境】对当前迭代版本进行开发、测试使用。
【版本示例V2.0.2.0513】各数字从左至右分别代表大版本号、迭代版本号、bug修订号、迭代版本开始时间
6、需求设计
工作内容：产品架构图、功能结构图、业务流程图（UML）、UE原型
需求设计阶段一般要整理产品架构图、功能结构图、如上图2、图3。但是如果要进行开发，最为重要的必然是流程图和原型了。
首先我们来说说流程图，目前比较规范的就是UML建模了。我们至少要从业务层面分析出来客户的业务流程，并整理或者优化为业务流程图同步给开发，比如活动图、时序图就是我平常用的比较多的（具体看开发和公司要求使用何种模型，有的公司可能还需要产品经理设计类图的），流程图对于开发来说尤为重要，比如业务流转，状态变更你自己可能很清楚，但是开发可能真的是一脸懵逼的。网上有很多成熟的规范我就不展开说了，上图：
接下来要说的就是产品经理最基础但是工作量最大的工作了，原型设计。我仍然会在此分为两种情况进行说明
情况一：用户预研阶段（或者用户评审）
在此情况下你要明确你的原型是给你的客户看的，目的是为了给他汇报你的方案，并挖掘客户的需求。所以在此阶段，原型只设计主要的页面即可，但是一定要尽量保真，这样才能让客户有真实的体验感，并反馈真实的想法。同样地，在原型上所有的说明标注都不应该有，因为在此阶段你把原型做到足够保真后，你完全可以借机拿客户做可用性测试，如果在没有说明帮助的情况下，客户仍然可以知道这些功能就是他们想要的，仍然可以走完整个流程，证明你的设计是基本符合客户需求的。如下图13所示：
图13：高保真原型
情况二：项目实施开发阶段
在此情况下你就要明确这份原型是给项目组成员看的，为的是能够以这份原型为开发的标准。所以每个页面都必须设计的非常详细，以上“需求管理”章节说了我们要善于利用工具整理需求，无论是架构图、产品功能结构图、流程图、需求说明还是交互都属于需求的每个部分，我们可以以Axure这样的原型工具作为需求文档的载体，在原型设计中加入每个功能点的说明、规则、流程、状态等等，这样开发也能够不用打开各种各样的文档增加负担。（其实开发看着你那几十上百页的需求文档根本都懒得看，换做是你，你会看得多认真哈哈～），还是上图：
7、需求评审
在此阶段，基本是需求已经全部设计完成之后，项目组开会一起来进行最后的需（吹）求（毛）评（求）审（疵）。评审要非常细致，不要怕大家怼需求或者开会时间过长，因为你在这个节点所有没有想清楚的需求最终你还是要背锅的，而且如果后期如果在开发过程中，却发现这个需求不可行，导致开发返工，开发生不生气是一回事，最重要的是这会导致整个项目组延期，这样的后果是非常严重的。
虽然是需求评审，但是一定要让项目组的每个成员都引起重视，需求一旦返工导致的是每个岗位的同时可能工作都要受到影响。而不能只是说产品一个人讲，其他人都模棱两可的听听就过了，那这样的评审毫无意义。（这个阶段我好像没有发现什么高效的技巧，还望大家给予建议）。
8、需求实施&项目实施
在此阶段各岗位工作进入设计，并进行评审。如需求设计&评审、UI设计&评审、代码设计&评审、测试用例&评审。作为项目经理兼产品经理你需要组织会议，来跟进各岗位输出的工作是否满足需求，是否有偏离预期的想法。我们一般会将大家的任务给量化，具体到工时每天进行跟踪，如图15、16:
9、项目监控
在此阶段主要对项目进度进行跟进，及时更新任务状态，提前对风险进行预警。此阶段算是项目经理非常核心的工作职责了，你要时刻跟进项目组成员的进度，工作完成度是不是有按照预定的计划进行。一般会有以下几种方式：
（1）每日例会：我记得在每本敏捷开发的书里都会提到这个15分钟每日例会，来跟进我们当前的进度，今天要完成的任务，以及有什么问题。当然我个人认为还是要看公司业务而定，规矩是死的人是活的，如果一个很简单的项目，项目组成员又不是很多，在可控的情况下通过日报和工作群的沟通就能发现问题，没有必要说一定要把大家召集起来开个例会。（因为组织大家可能会打断同事的工作状态，如果日报大家都没什么问题的话就没必要每天这么高频了）
（2）每日日报：这个应该算是各行各业的工作规范了，每天应该把今日完成的任务和明日计划完成的任务列出来，并在项目组内给其他成员同步。这样也好让大家互相了解整体的项目进度。（而且日报也是自己提前预警的一种方式，你可以在备注中将风险和情况如实汇报出来，如果领导认为这个任务不可控了，就会介入进来，即便未来发生了问题，至少提前做了汇报，总比一声不吭的要好）
（3）每日任务更新：不论是用软件工具还是通过文档等各种方式，对任务状态进行及时更新都是必要的一个环节，作为项目组各岗位的成员应该做到及时将自己完成的任务进行状态更新，方便项目经理同步进度。（当然在现实情况下就是你不催，大家必然不动，敌不动，我不动）
（4）人员表现：人员表现乃项目正常运行的基础（像什么喊口号或者人员积极性啥的这种主观的我就不再介绍了），这里我想说的是，任务需要量化才能够最直观的监控到每个人的表现，眼见不一定为实，数据更加直接。像大公司什么KPI，OKR等一些制度都非常完善了，也有很多开放的方法可供大家学习，小弟就不再展开介绍了。但是通过刚来公司大家的任务情况都靠口头汇报，和目前使用管理工具看到实时数据一对比，就会发现量化任务后大家的积极性和工作效率都相应的会有一定提升。我分析有如下可能：
项目组同事之间发现别人做的更快更多，自己相应的也会带动积极性，怕被比下去（比如以前我作为新人刚来公司的时候，和其他产品经理做一个项目，对方就会时刻关注我的工作，进度，和学习的一些小技巧）
管理软件的数据会对管理层开放，每个人都担心领导和决策层看到自己的表现（对于小公司来说领导和老板基本认识每一位同事）
管理工具会统计人员各方面维度的数据，如工时，任务数，出现bug数等等，综合起来大家不仅能看到自己哪方面问题比较多，同时也能针对性的去注意，倒逼成员在其它岗位的工作和评审中更加集中注意力
（5）风险预警：风险预警经常会来自于项目进度、交付质量、需求变更等等。首先对于项目进度来说，本身就难以控制，对需求和任务提前预测本身就是主观并且不准确的，尤其是我们做项目经常对行业并不是很熟悉，有可能对工作量的预判会有较大偏差。再来交付质量来说，由于交付时间明确，工期相对紧张，留给测试的时间自然会不够充裕。最后对于需求变更这种，可以说是最让人头疼的问题，对于软件产品来说，需求变更是非常常见的事情。而且时间一赶，就有可能出现许多需求细节想不清楚的地方，然而在进入一个项目从0到1开发时，由于项目组都没什么经验，评审的时候自然也就不够细致，从而在开发的过程中会有很多问题，这就有可能导致需求细节变更。而且对于我们做项目来说，我们的客户还会源源不断的提出各种想法（虽然按照规范流程来说，项目开发中是不再收集变更的需求。但是真正面临甲方的时候，你这个需求达不到甲方的意思，甲方根本就不验收，自然你的项目尾款就收不到。这个也是很头疼的问题，也导致我们公司目前交付通常都会拖一段时间，望各位建言献策）
10、交付验收
交付验收一般来说是一个项目期最后的一部分工作，自从进入公司以来看到公司所有的产品几乎都有一个情况，就是交付期一旦用户试用，必将会反馈各种各样的优化意见。所以在这里我们遵循一个敏捷概念叫“增量交付”（来自ACP敏捷项目管理应试指南），即：
使得工作产品更早地交付到客户手里，更快地交付价值
允许客户在项目未完成前先用系统，以便给需求变更留出时间，同时影响最小
不试图预先规划所有细节。相反，团队可以先规划一部分，交付一部分价值，得到有价值的反馈后再重复这个循环
优先处理最有价值的功能部分，以便把这最有价值的部分尽快交付到客户手里
同时，还有一些注意的地方。就是很多小公司在交付的时候经常是客户提出来交付什么文档就配合去整理，客户不提出来就不给了。这样是会减少一定的工作量，但是这也是对自己公司专业性的不负责任。交付文档是对这个项目的总结，不仅可以对当前系统设计规则做记录，也能够督促客户验收。以前我们就对一个已经开发完成的系统整合其它功能做开发，由于对方交付文档缺少，在数据割接这一块没有数据库的设计资料，导致开发很多数据迁移都有可能对不上的字段。总之一个项目期时间说短不短，说长不长，花点时间把交付文档整理完备做好最后的收尾是非常必要的。
三、总结
1、敏捷开发的一些思考
最近公司一直在学习并希望实践敏捷开发于公司的软件开发工作流程当中。然而效果往往不尽人意，我们可以先看看敏捷宣言（在《PMI-ACP敏捷项目管理》这本书中讲过遵循敏捷宣言代表了敏捷从业者的最高指导性原则）
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
那么我依照敏捷宣言的原则来映射到我们的公司业务中去，就会发现一些问题
（1）首先人与人之间的口头交互虽然在短期内提高了沟通效率，然后从长远来看，需求的不断完善、丰富、细节的修改，以及项目组成员的频繁调动，许多细节都可能被遗漏，甚至新接手的项目组成员根本无法快速上手到项目组的运行之中；并且在真实的开发当中，如果不严格遵循于流程规范，很有可能造成本可以提前阻止的小问题到了后期越滚越大。
比如按照流程来说，需求同步应该开会进行，但是有几次我为了提高效率，将一些细节只和对应的开发说了，导致项目组有几个同事都不知道这个细节，以致于大家测试的时候根本没有发现问题。还好没有导致严重的错误，但是这其实是不应该发生的（我理解此原则想表达的是个体互动的效率高于严格遵循流程流转的效率，然而在真实的开发场景中，如果当我们习惯于使用口头互动，那么你试问自己你真的会将每次口头表达的细节都详细的记录在文档上吗？至少在我们公司是没有做到的）
（2）第二就是适应变化，响应变化就会让我们的工期受到影响，强交付是做项目的基础标准，我们每一个项目都会在签署合同之前，对需求进行大致评估，虽然工期不一定特别精准，但是基本差不多。在开发并整理计划之初，我们就会将任务拆分出来将项目组成员的工作量安排饱满。如果在开发过程中进行需求变更，工期必然延后，就有可能导致我们原本签署的周期之内无法按时进行交付，违约对于公司来说会导致更为严重的后果。当然我有听过有同行建议过，在特殊的情况如果来不及交付就临时增添开发人员，但是在现实中经常是不适用的，对于大项目或者自研产品来说还好一点，一个是周期相对长，二是基本每一个人不论是不是产品岗位，都对需求有基础的认识，你要临时救火的确能快速上手；但是对于一些周期较短的小项目来说，除了项目组的这几个人，可能其他同事只听过这个项目的名字，需求完全不了解，尤其是对于开发来说，每个规则都要非常清楚，理解需求就要几天时间，可能很多细节还不知道（即便你整理一份再细致的需求文档，对于一个从0到1的项目来说有多少规则，多少功能，这会让开发在短时间内很难上手帮忙）。
最后我个人认为，无论是基于何种开发模型，规则是死的，人是活的，没有必要认为什么比较流行就去使用，适合自己公司的才是最好的。
2、自我思考
从大学毕业就直接进入了产品实习生的工作中，一眨眼就一年多过去了。公司也非常信任我的工作能力，很短的时间内就让我独立承担产品经理的工作做一些简单的产品。为了完善自己的工作规范和方法，我看过很多工作相关的书籍、论坛、帖子，但是绝大部分的思想和方法都很难应用于当前的公司业务当中，这是让我有点失落的（本来想着今年拿下PMP和NPDP两大项目管理认证的，奈何工资收入不允许，一直存不下来钱，只能先自己看书学习了）。总感觉自己设计出来的产品就像自己的小孩，刚刚长大一点就要交给别人，看不到他以后会是什么样，是会成为我期望他成为的样子还是变成我完全不认识的样子。大家幸幸苦苦一起将他孵化出来，我是希望它能真正的为我们的客户带来很大价值的，而不是流于形式。不知道自己未来会在哪个行业深耕下去，但是我认为这个职业一定会为我的生活带来些独特的体验。