摘要: 关于产品规划，可以从寻找用户问题、分析市场/竞品/产品数据、明确产品目标/路径、设计功能矩阵、业务&技术风险评估几方面开展，即围绕寻找问题->明确目标->设计路径形成产品演进。
1、用户问题
用户对产品反馈有哪些问题？哪些是用户刚需？哪些是非刚需？外部用户电话/QQ/微信沟通，内部用户面对面访谈。沟通前准备问题清单，沟通后将结果分类（如：功能操作易用性/手册帮助指导/客服沟通渠道/产品赋能力度），每类形成TOP3～5。

2、市场/竞品/产品数据
市场数据，可以通过企业收录平台、咨询报告平台获取，了解产品领域的用户群规模、用户群领域分布，掌握产品市场空间。
竞品数据，页面指标可以通过Alxea统计，系统指标可根据参加线下论坛/沙龙时收集的宣传数据、竞品网站页面内容反推（如：基于分类目录的商品列表估算SKU、商品列表页单价和使用人数估算GMV） 。
产品数据，针对用户问题通过报表平台或开发导表统计关键指标。  阅读全文      摘要: 做产品，每天跟各类人群沟通交流是常态，面对各种需求，我们可以从哪些方面去着手分析和判断，使产品的解决方案既解决了用户痛点甚至制造惊喜，又夯实了产品模型，而且沿产品策略又进了一步。下面梳理一些思考点：
需求是用户或组织在某个场景下存在的痛点以及诉求。而需求分析就是发现问题、去伪存真、解决问题的过程，分析维度含：
1、基于产品定位
在产品的定位和愿景下，需求是否违背产品初衷，是否偏离产品路线，这和产品是先定位出来还是渐进明晰找到定位不冲突，即使产品策略是分阶段实现，每个阶段的需求也都应该围绕产品定位去分析。  阅读全文      摘要: 产品工作过程这个话题，做过的同学想必不陌生，经历一些产品及功能的设计后，也梳理和总结产品工作过程，都有哪些工序，设计过程是怎样的，如何合作去完成产品以及过程中的一些感悟。
一、产品前期的那些工序
二、产品中期的设计过程
三、产品后期的工种合作
四、产品经历的一些感悟  阅读全文      摘要: 最近牵头的一个项目上线发布，涉及外部合作，除了一般的需求调研沟通、产品设计评审和研发过程管理之外，还多了对运维实施和合作方的沟通协调。过程中经历的一些场景和脑海里项目管理思路反复在碰撞，把它们梳理和提炼出来，分享和自勉，以更好地开展以后的产品工作。
对于兼容产品经理和项目经理的情况下，产品层面需要快速学习业务并结合产品现状整理业务点，为产品设计做铺垫。项目层面需要充分了解业务方期望以及项目任务（市场、运营、产品、开发、测试、运维方面）的进展现状及约束条件，为项目管理做铺垫。  阅读全文      摘要: 产品从0到1上线运行了大半年，上线初期为了里程碑、KPI，项目组难免会存在完成任务式的心态，尤其是项目成员由各方技术团队抽人拼凑而成、某些业务性强的模块开发过程中，技术在驱动产品的情况，产品可扩展性和健壮性的设计情况可想而知。在着手产品重构任务时，首先想到的便是了解现状，含：业务和技术两方面。技术方面，主要从表结构开始、跑产品的门户流程，通过门户流程看数据生成规则和数据流向来梳理产品现状。业务方面，和运营、用户沟通了解目前产品存在的痛点，优先级情况。在摸清楚业务和技术现状后，和市场、运营伙伴沟通业务规划、对标了解竞品业务、与用户沟通挖掘潜在需求则是下一步要做的工作，该阶段需要尽可能收集多的信息输入，以让设计可以考虑到更多的业务场景，使设计更加科学、合理和具备扩展性。  阅读全文      摘要: 大家都很清楚，互联网产品功能开发出来只是开始，不断的运营迭代才是关键。产品设计之前，除了我们常说做的市场调研、竞品分析外，条件允许的情况下尽可能在设计前期接触用户，了解一手需求并做梳理分析很重要。产品设计过程中上除了考虑交互、功能和流程，还需要思考该功能上线后如何积累到需要的数据，为产品迭代提供指导依据，否则很容易陷入经验主义，走偏方向。产品上线后，定期的看数据、解读数据，形成潜意识的习惯很重要。
产品工作没有成型的套路可以复用和一成不变，相信每个产品人都是在不断摸索和调整，包括我自己，下面结合实际的经验，梳理和分享一些设计观点，不对斧正。
观点一：点、线、面，逐步分析完善需求。  阅读全文      摘要: 互联网是一个野蛮生长的环境，面对大众的多样化需求、行业的快节奏决定了产品人必须要自我驱动，快速学习、系统思考，积极改变、拥抱变化，除了专业技能，对产品人的心态、观念和综合素质要求是比较高的，因为需求来源于用户的生活体验，这里的用户也包括自己。
经历过运营商产品工作，需求调研、系统分析、产品设计、需求编写/管理和交付能力属于基础技能，客户交流/售前/售中/售后支撑与引导能力可以认为是中阶，产品规划和经营能力则属于高阶。而互联网产品工作，除了需求分析和产品设计，市场/用户调研、头脑风暴、数据分析和运营思路也是必不可少的环节，中阶则更多是行业认知能力、体系化产品思路、观点分享能力和产品影响力。高阶，应该在于对行业走势的判断力、产品定位和路径规划能力、方法论输出能力和新人培养能力。  阅读全文      摘要: 最近在做一款前端产品的设计，产品前期的调研相对顺利，但在设计过程中挣扎过、纠结过、兴奋过也郁闷过，五味杂陈。技术出身的产品经理，设计产品时往往容易陷入技术思维的陷阱，将简单的功能复杂化、将用户想象成和自己一样的思维方式去过度设计，设计出来的原型稿历经几轮PK讨论下来，精疲力尽之余不断在反思和审视自己产品观念中的那些劣根，拔掉方能成长。
中/后台产品的设计从事较多，而在做过几轮前端产品设计后也逐渐发现它的可爱之处。于是想梳理一些对前台、中/后台产品设计方法上的区别之处，以更加全面的视角去看待产品的规划和设计。  阅读全文      摘要: 2015年初，从原来的虚拟运营商跨进云计算这个业务，领域的转变让自己在工作过程中逐渐了解云计算、开放平台这些以前不曾接触过的对象。产品工作不像开发、测试这类，相对来说没有通用的学习范本和标准，产品经理唯有在工作中结合实践总结工作方法并且根据新的实践不断反思和修正，才是正确的成长之道，他人的知识终究是他人的，你永远无法了解那些知识背后的逻辑，所以不能盲目借鉴，要善于辨别和吸收。
这一年集中阅读了《全新思维》、《学会提问》、《金字塔原理》、《浪潮之巅》、《社会心理学》、《影响力》，在工作过程中重读了《启示录》、《产品经理修炼之道》、《网站数据分析与实践》。思维方式的锻炼是这一年的重心，现在的产品工作和以前的研发、系统分析与设计工作相比涵盖面广、综合性强、要求全面，对个人思维中以前行业固有认识必须打破，学习和接收新的思维方式是首要任务。  阅读全文      摘要: 最近在做一个前台网站的产品改版设计，设计之前后将以前的产品笔记翻出来重新阅读了一遍，开展新产品的设计过程中，也来梳理一些心得体会。
一、设计任何一款产品之前，我习惯先用脑图将产品思路进行梳理：
1、思考
1）产品的用户群是什么？有哪些行为特点？
2）之前用户调研的痛点需求？运营反馈的痛点需求？
3）竞品都有哪些优缺点？
2、回答：
1）产品核心功能清单有哪些？
2）根据核心功能归纳产品定义的一句话描述？  阅读全文      摘要: 最近围绕平台产品开展需求调研、产品定义和产品设计的过程中，也在思考对于产品子系统间的规则约定和遵守，即如何设计产品规则并让各子系统共同遵守，从而更加合理地完成产品子系统间的交互&协同设计。
平台产品设计需要紧贴组织的业务定位，形成产品的定位，再结合现有的应用架构去进行产品定义和设计，这里不过多谈论理论方面的内容，只是结合这段时间的经历，分享自对产品子系统间如何交互&协同的一些看法：
1、业务场景规则
在设计产品子系统间的交互&协同时，从用户使用场景出发是必须的，但用户和数据流为何要经过子系统？有哪些用户和数据会经过子系统？用户和数据流经过子系统后都流向了哪些子系统？最终给用户提供什么样的数据输出？这些思考在做业务分析时开始考虑，定义好业务场景才能为产品子系统间的交互&协同规则提供规则约定。  阅读全文      摘要: 产品生命周期的概念都很熟悉，加入这个圈子前也做过大小各类项目，也负责过项目的从无到有直至上线。但严格意义上来讲，互联网产品从无到有的生命周期体验，还是首次接触。在这里不探讨产品方法，只记录和分享自己在产品不同阶段经历中的一些感触。

1、产品调研期
集中办公，各产品人员分工调研，编写和评审调研报告，随时头脑风暴，早晚沟通讨论（回答市场有什么）。一天下来的工作重点侧重在：调研、讨论、讲解。一天的时间基本都泡在各大市场分析网站和竞品上面。
其中，注册帐号使用竞品的过程中一般是结合业务咨询，做抽象归纳。

2、产品需求分析期
集中办公，各产品人员根据调研成果进行业务需求分析和讨论（回答产品要做什么），根据业务需求梳理出产品需求，最终输出产品需求说明和原型。一天下来的工作重点侧重在：讨论、方案PK、汇报。  阅读全文      摘要: 在大公司工作，首先要面对的是公司现有的流程、规定和条框。其次，基于成本考虑，多数大公司都采取矩阵式管理，核心部门都是共享资源，产品经理要确保争取到足够的资源才能研发出产品。作为一名初来咋到的产品经理，更是要理解这两点才能高效地开展日常工作。

对于公司现有的流程、规定和条框等硬性政策可以自主去学习了解，但对于如何在矩阵式架构中充分开展工作，在与Leader、伙伴的学习之余，更多还是要结合个人情况去揣摩、理解、总结和反思，形成一套自己的工作方法。日常工作中，大部分时间都在与市场部、UED部、开发部、测试部、运营部的伙伴进行产品沟通、需求评审及问题跟踪，不同部门承担的职能不同，使得产品经理在与这些伙伴的工作配合中除了发挥自身专业之外，对于软技能的运用也是非常重要的。  阅读全文      摘要: 需求分析能力是开展产品工作的基础技能，也是产品经理的立身之本，需求分析方法论的指导固然重要，但更多还是要去实践和思考。
最近在做平台型的产品工作，相对于垂直类产品的小而美特点不同，平台型产品更加注重生态建设，根据公司自身特色，依托现有平台资源，瞄准服务对象，从而推出一整套的解决方案。同时，相对于以前做运营商产品规划不同，互联网产品规划侧重竞品分析，业务讨论，主动规划。没有人告诉你需求是什么，BOSS定方向，产品经理基于大方向开展一系列调研、分析、头脑风暴、评审、汇报工作，最终在规定的时间产出业务和产品需求。
结合实际工作中的一些经历和体会，分5个部分谈谈对产品需求分析思路的理解，和各位交流学习，同时附上指导自己开展需求分析工作的一些方法论。  阅读全文      摘要: 加入互联网产品圈子之前看过一些互联网产品书籍，对于产品思维的感触，在自己真正踏入这个圈子的实际工作中才有了一些切身的体会和感受。下面在写给自己的同时，希望也能对准备转到这个行业的同学有一些帮助：
1、工作方式
1.广泛倾听
互联网产品面向大众用户，在做产品规划和设计时，需要广泛吸收各方意见，不管是公司内部各部门同事还是外部用户，学会主动宣传、推广和倾听用户声音是一项基本能力。
2.积极参与
和做企业级产品面向企业内部用户的需求调研和产品设计不同，在互联网上增加自己的曝光度、提高社交网络参与度、关注社会热点事件，参加线下活动认识圈内朋友，这些是以前不曾感受到的。  阅读全文      摘要: 产品需求从无到有，经历了头脑风暴、调研沟通、业务讨论、架构讨论、产品评审、开发评审。沟通无处不在，和业务人员、架构师、产品人员、技术人员、领导的各种沟通协调、汇报，一路下来梳理些沟通的方式方法，自勉和改进。
1、心态：一句很感同身受的话：开放的心态是我们要做的第一件事情，全局控制的想法其实是错觉。你不能控制人或者任何事情。你可以影响他们，但绝不是控制。
2、与业务、产品人员的沟通：
1.沟通业务背景，了解产品流程背后的原因。
2.沟通产品故事，了解产品为用户带来什么价值。
3.讨论产品方案，建设性提问并带自己的建议方案。  阅读全文      摘要: 因业务方向调整，今年1月开始投入新业务的产品工作，和之前垂直类产品不同的是，这次属于平台型产品。经历了竞品调研、业务需求分析、产品需求分析、产品规划之后，来回顾一些过去工作中的收获和反思。
相对于垂直类产品的小而美特点（追求极致体验、制造运营感、数据驱动、快速迭代）不同，平台型产品更加注重生态建设，根据公司自身特色，依托现有平台资源，瞄准服务对象，从而推出一整套的解决方案。
相对于以前做设备厂商的产品规划（根据客户需求推出解决方案、业务规划成分少系统设计成分多）不同，电商类产品规划侧重竞品分析，业务讨论，主动规划，业务需求梳理，产品需求分析。即没有人告诉你需求是什么，领导定一个方向，产品人员负责基于大方向开展一系列如调研、分析、头脑风暴、评审、汇报工作，最终在规定的时间产出业务需求和产品需求。  阅读全文      摘要: 第一次做互联网C端产品，可以将以前看过的书籍知识运用和实践，是很HIGH的一件事。刚开始投入工作时，产品感觉还比较朦胧，经过这段时间的摸爬滚打和同事的支持，思路被逐渐打开了许多。需求从无到有，横跨多个中心及部门，还涉及外部合作方，在项目沟通协调、业务逻辑分析、需求沟通评审上可以继承以前的经验，但面对赤裸裸的产品设计，火候的把握还需要继续学习。记以此文，希望在接下来的工作生活，能坚持去观察、思考和总结。  阅读全文      摘要: 互联网产品经理神话这几年在整个IT行业被各种炒，有发展红利的大背景，也离不开媒体宣传的各种产品故事。产品人为了实现自己的产品理想也好，还是为了经理title而趋之若鹜也罢，不可否认，互联网产品确实很大程度地改变、影响了我们的生活方式，让我们的生活变得更有爱和有趣。看过《人人都是产品经理》或《产品经理修炼之道》的朋友应该都比较了解这个岗位在企业中的定位、职责及发展方向。下面结合自己这半年以来的实际工作，分享自己对该岗位的理解：
产品经理定义：对产品的生命周期负责，基于公司/中心的业务方向规划产品的发展路线，管理产品规划及设计，跟进产品研发上线及运营。
产品经理职责：负责产品的市场调研、用户调研、竞品分析、头脑风暴、原型/流程设计、规划分析、产品汇报、产品立项、产品研发/上线/运营跟踪，与市场、UED、开发、测试、运营、客服等部门的同事密切配合，在产品发展的不同阶段，组织与相关部门同事开展产品沟通、讨论、评审、决策，推进产品规划和设计方案的落地、关注产品研发的迭代节奏，关注产品上线后的运营推广。  阅读全文      摘要: 进入这个互联网圈子以来，相对容易的是新业务学习、日常沟通以及项目管理，而困难的是要去改变沿袭多年的产品思路。所谓痛则通，对于这个转变的过程，自己有准备。
结合自己在通信和互联网行业做产品经历，谈谈它们的差异，主要在组织文化、组织架构、工作流程、日常沟通、需求分析、产品规划、产品设计、产品运营方面。
组织文化：传统行业组织文化偏行政权威，而互联网组织文化崇尚开放自由，团队负责人和大家打成一片，言传身教的同时注重平等开放的合作。
组织架构：传统行业的组织架构崇尚垂直式管理，行政级别划分明显。而互联网组织架构崇尚矩阵式管理，淡化行政级别，去中心化，团队负责人更多关注产品的规划和发展、团队的成长和建设，日常行政工作由专门的PMO负责。  阅读全文      摘要: 互联网，从今年5月~7月的准备，再到8月入职至今的半年以来，感受和经历有很多。年末岁尾、空闲之余，来梳理那些日子里还记忆尤新的片段。
毕业后开始做程序员、工作第3年转做了系统分析师，第5年转做项目经理，1年之后投入互联网产品至今。7.5年的职业生涯里，在收获各阶段经历的同时也在感受着互联网行业带来的各种变化。而对于转互联网的初衷及时机，概括来说有如下几点：
1.互联网产品更加贴近生活、更有趣、更喜欢
2.积累了软件开发、产品及项目管理工作经验
3.积累了互联网产品规划、设计、管理及运营等书籍阅读和笔记
4.积累了对一些互联网产品的看法和见解
从开始关注互联网产品，到感兴趣和不间断关注，到最后加入这个圈子，那些过往的情景还历历在目：  阅读全文      摘要: 高速发展的世界，需要我们迭代地开发和改进业务问题的解决方案，我们需要一些方法来持续探索业务及其问题，将这些要求告诉技术专家，他们为业务提供技术解决方案。
许多组织机构不是等待需求的所有细节都得到定义，而是更喜欢迭代完成这些业务活动，定义一些需求，开发一部分解决方案，定义更多的需求，这样增量式交付发行版本，直到解决方案被判定完成。这种迭代的方式意味着，业务环境和开发环境中的关注点、想法和变化更加同步。使开发者更了解今天的业务问题，工作的产品适合今天的业务环境。
这种持续的工作探索意味着，业务分析师持续地将新故事或需求加入分析列表，这个列表又持续地按价值进行分析，最重要的是按业务价值来分析。列表根据价值和紧急性来排列优先级，最高优先级的需求交给开发者开发。  阅读全文      摘要: 今天的大多数软件都不是拥有它的组织机构开发的，而是购买的。考虑到这些开发和解决方案选项，今天的业务分析师有一项额外任务：即决定最佳的策略来发现和沟通需求，不论组织机构决定采用哪种方式实现自动化。
以需求策略作为指导，决定从哪里开始，是否有足够的细节，你需要哪个迭代循环，记录知识时采用哪种形式，何时复查，何时让哪些利益相关者参与，何时构建原型，何时以及如何做大量的事情，让你的工作更接近为业务产生最优价值，每个项目的情况不同，有必要采用不同的做事顺序、做事细节、沟通形式。  阅读全文      摘要: 需求评审环节检查了单项需求，确保它表述正确、无二义性、在范围内、可测试、可追踪、不是镀金需求，从而确定制有正确的原子需求才包含在需求规格说明中。
接下来，必须考虑需求规格说明是否完整，这意味着将规格说明作为一个整体来复查，确保应该有的部分都有。
这种复查可以在任何时候进行，而不只是在发布之前，它可以是一项持续的活动。
  阅读全文      摘要: 需求来自于人，人们并非总能确定他们需要什么，并非总能解释他们想要什么，需求也并非总是编写地很小心，完整无二义。
需求工作的要点是要确保交给开发者的东西是准确的、完整的、无二义的，陈述了真正的需求。任何不足都有违需求工作的初衷。开发者可以构建任何东西，但他们首先必须知道他们必须构建什么。  阅读全文      摘要: 如果产品有一项需求，要执行某个功能或具备某种属性，那么测试活动必须展示产品确实执行了该项功能，或具备了该项期望的属性。为了进行这样的测试，需求必须有一个测试基准，这样测试者才能比较提交的产品和最初的需求。要注意的是，这里的验收标准既不是测试，也不是对测试的设计，而是测试提交的产品必须采用的测试基准，是构建测试用例的输入信息。  阅读全文      摘要: 为什么所谓的‘非功能需求’也很重要？请考虑一个真实发生的故事：客户拒绝了交付的服务台软件。功能是正确的，但客户不想要它。为什么？因为客户拒绝使用它，更愿意采用原来的人工过程。这就是需求团队几乎没有注意非功能性需求。
只所以需要这些非功能需求，不是因为它们是产品的功能活动（诸如计算、操作数据活动），而是因为用户希望这些活动以特定的方式执行，并达到特定的品质。
例如，亚马逊网站很容易导航，这让客户容易找到对象，它也很友好，让你觉得自己是尊贵的顾客，你可以写评论，通过购物伙伴和亚马逊推荐得到指引，很容易查看和安排送货，等等。  阅读全文      摘要: 通过产品用例（PUC）场景展示和确定了解决方案后，下面就需要PUC场景转换到功能需求。
功能需求指明了产品必须做的事情，即产品为了满足它存在的根本理由而必须执行的一些动作。需求分析师理解了产品必需的功能后，他要用功能需求告诉开发者要构建什么。
  阅读全文      摘要: 当需求人员和客户之间针对需求沟通中的业务本质问题达成一致时，接下来就是沟通和确定多少业务将通过产品来实现自动化。作为需求分析人员，需要在业务需求、包含的功能、用户体验、非功能需求、开发成本、技术可行性、限制条件这些因素之间取得平衡和折中来完成解决方案的确定和发布。
没有公式化的方法能得到最佳的解决方案，需要实际过程中考虑和权衡。  阅读全文      摘要: "我知道这是我提出的,但这不是我想要的。”你不必在IT这行待很长时间就能听到这句话，看着期待的笑容从开发者脸上消失，因为这事经常发生。开发者交付了客户提出的需求，但结果却不能解决他们的业务问题。为什么？因为真正的问题从未阐明，所以从未正确理解。
在做需求调研和收集时如果听到的都是客户关于解决方案的想法，而不是描述背后要解决的问题，这可能是个好的解决方案，但更有可能的是，它受限于客户的经验和想象力。而且，你不清楚它是否解决了正确的问题。所以，作为需求分析人员，你的任务就是解释客户所说的内容，揭示它的本质。  阅读全文      摘要: 不论哪种工作，试图改变之前先对它有充分的理解，如果一头冲进去，对你要改变的东西几乎没有理解，就进行‘改进’，那么结果不如意也不奇怪。当你开始理解原有的工作时，肯定会产生一些想法，知道如何改进它。
这里探讨的比较常用的Brow Cow模型和一些用于发现业务过程的调研方法，而实际过程中不可避免地需要多种调研技巧组合使用，具体情况需要具体应对。  阅读全文      摘要: 项目启动过程建立了工作的范围，即要研究的业务领域，业务领域其中的一部分将通过预期的产品实现自动化。而实际上，这个工作范围可能太大，难以作为一个单元进行研究，正如吃东西之前先要将它切成小块一样，需要将工作范围分解为一些可管理的部分，然后再来研究它以发现产品的需求。这里将需求过程中涉及到主要对象以及它们的分工界面通过一张关系图来展示：  阅读全文      摘要: 从通信行业的产品工作到政府行业的项目工作，一直在和‘需求’打交道，不同的行业特点和项目环境需要针对性的需求发现和实现方法，但围绕需求调研、分析、编写、评审、验证到需求交付这几个过程基本是相通的。经历从瀑布型项目需求策略到迭代型需求策略的转变和实践过程，回过头来看《软件开发方法学-掌握需求过程》，进行摘录和梳理的同时，也加深和沉淀一些对需求的理解和认识。以此片文章开始，分享一些读书笔记：  阅读全文      摘要: 刚给大辉发完邮件准备去上班，微信群里热闹不已，原来是pmp成绩出来了，尽管考试完后心里基本有底，但听老师说这次考试偏难，等在待结果出来的前夕，还是不免忐忑。
2013年年初报名直到2014年3月份才考试，倒也是好事，实际工作中的那些事和那些人，总能在复习的过程中让自己反复思考和碰撞。而4m1p的成绩单，算是给自己交了一份满意的答卷，在这里简单回顾一下，有兴趣的同学可参考：
【复习历程】：
1、 关于教材划分（含：1本教材（2012版）、3套模拟题、1本辅导书），自己是按下面四部分来分批阅读：
第1章 项目引论、第2章 组织影响和项目生命周期、第3章 项目管理过程
第4章 项目整合管理
第5章 项目范围管理、第6章 项目时间管理、第7章 项目成本管理、第8章 项目质量管理
第9章 项目人力资源管理、第10章 项目沟通管理、第11章 项目风险管理、第12章 项目采购管理、  阅读全文      摘要: 这段时间以来的产品使用过程，界面性能和易用性成为关注的重点。相比运营商项目不同，政企项目验收过程相对简单，没有严格的测试用例，以是客户组织的项目评审会，公司汇报阶段进展、客户做业务测试的方式开展。
简单回顾上线期间一些工作：
1）公司侧提供《需求规格说明书》、《产品使用手册》、《角色权限清单》
2）业务部门整理《用户申请表》、《业务制度管理办法》
3）业务部门组织上线前项目例会
3）业务部门发布系统上线公告
4）业务部门组织用户培训
5）公司和业务部门提供产品使用支持，解答最终用户的操作疑问、收集产品反馈。  阅读全文      摘要: 项目进入试用阶段，版本节奏也相对平缓，对于需求&开发&测试过程中的一些管理，分享一些个人体会，欢迎指正。开始正文之前，存在下面前置条件：
1.本轮版本要交付的功能及时间已已评估并与客户达成一致，是以交付时间倒推来管理《需求规划》和《研发计划表》的方式。
2.团队资源：有测试组长，开发组长是临时支持（同时兼顾其他项目）。
3.开发4人、测试2人、需求1人，迭代周期1～2周。
4.需求、开发和测试在一起办公。  阅读全文      摘要: 项目接近尾声，需求也逐渐收敛。面对需求变化频繁、迭代版本周期较短的客观情况，传统模式已不能在此生搬硬套。虽现有的开发过程谈不上正规敏捷，也算接近小步快跑的节奏。下面分‘需求开发&代码开发、版本控制、版本发布、增量升级’几个部分，记录一些体会，欢迎指正：
（1）需求沟通&代码开发：
1、针对有可以复用的现有模块时，和开发人员沟通主体思路，由开发人员着手开发，开发人员在开发期间与需求人员充分沟通，碰到疑问及时澄清、解决。
2、针对没有可复用的模块且涉及较复杂的业务流程时，需求人员画原型图（紧急情况手绘草画），开发人员按原型图或草图着手开发。
3、需求人员记录开发过程中和开发人员、客户沟通的需求变化点。
4、功能开发完成、客户验收后，及时补充到《需求规格说明书》。
（2）版本控制：
1、代码提交前做比较再合入版本库（严禁合入非自己修改的文件）。
2、合入代码需填写修改信息，新版本开发只填写修改信息，优化修改还需在BU  阅读全文