一线产品经理的工作感想
产品经理感悟心得体会(3篇)
第1篇作为一名产品经理，我深知自己肩负着推动产品从无到有、从有到优的重任。
在过去的工作中，我经历了无数次的挑战与成长，以下是我的一些感悟和心得体会。
一、明确产品定位，找准市场需求产品经理的首要任务就是明确产品的定位，这是产品能否成功的关键。
在定位过程中，我们要深入分析市场需求，了解用户痛点，挖掘潜在用户需求。
以下是我总结的几点心得：1. 研究市场：通过市场调研、竞品分析等手段，全面了解行业现状、发展趋势以及竞争对手的产品特点。
2. 用户画像：根据市场调研结果，绘制用户画像，明确目标用户群体，为产品设计提供依据。
3. 确定产品定位：在充分了解市场需求和用户需求的基础上，为产品确定一个清晰、独特的定位。
4. 不断调整：在产品迭代过程中，根据市场反馈和用户需求，不断调整产品定位，确保产品始终符合市场需求。
二、把握产品生命周期，做好规划与执行产品生命周期是产品经理必须关注的一个重要环节。
从产品策划、设计、开发、上线到运营，每个阶段都需要我们做好规划与执行。
以下是我的一些心得体会：1. 策划阶段：明确产品目标、功能、特性，制定详细的策划方案，确保产品能够满足用户需求。
2. 设计阶段：与设计师、开发团队紧密合作，确保产品界面美观、易用，提升用户体验。
3. 开发阶段：与开发团队沟通，跟踪项目进度，确保产品按时上线。
4. 上线运营阶段：制定运营策略，提升产品活跃度、用户留存率，扩大市场份额。
5. 优化迭代：根据用户反馈和市场需求，不断优化产品功能、性能，提升产品竞争力。
三、提升团队协作能力，共同推动产品发展产品经理不仅是产品的负责人，更是团队的领导者。
以下是我的一些心得体会：1. 沟通与协调：与团队成员保持良好的沟通，及时了解他们的需求和困难，共同解决问题。
2. 分配任务：合理分配任务，充分发挥团队成员的优势，提高团队整体执行力。
3. 激励与反馈：对团队成员进行激励，关注他们的成长，及时给予反馈，提升团队凝聚力。
产品经理的个人感悟
产品经理的个人感悟
作为一名产品经理，我在我的职业生涯中学到了许多宝贵的经验。
以下是我个人的一些感悟：
1.用户至上：无论在产品的设计还是改进过程中，我们都需要始终将用户的需求放在首位。
了解用户的需求，解决用户的问题，才能创造出真正有价值的产品。
2.数据驱动：数据是指导我们决策的重要依据。
通过收集和分析数据，我们可以了解产品的性能，发现产品的问题，并针对性地进行优化。
3.团队协作：产品开发是一个团队协作的过程。
我们需要与设计师、工程师、销售等各个团队紧密合作，才能将产品推向市场。
4.持续学习：技术日新月异，作为产品经理，我们需要持续学习新知识，了解行业动态，才能跟上时代的步伐。
5.勇于创新：在竞争激烈的市场环境中，只有不断创新，才能在竞争中脱颖而出。
我们需要敢于尝试新的想法，接受新的挑战。
6.重视反馈：无论是用户的反馈还是同事的意见，都是我们改进产品的重要参考。
我们需要认真对待每一个反馈，从中吸取经验教训。
7.追求平衡：在追求产品的功能和性能的同时，我们还需要关注产品的易用性和用户体验。
只有平衡了各方需求，才能创造出真正优秀的产品。
以上是我作为一名产品经理的个人感悟。
我相信这些经验不仅对我自己的工作有指导意义，也能对其他产品经理有所启发。
产品经理的工作职责感想
首先，产品经理需要具备敏锐的市场洞察力。
在竞争激烈的市场环境中，产品经理要时刻关注行业动态、用户需求和市场趋势，以便为产品定位和迭代提供有力支持。
只有深入了解市场和用户，才能设计出符合市场需求的产品，从而在激烈的市场竞争中脱颖而出。
其次，产品经理要具备良好的沟通协调能力。
产品经理需要与开发团队、设计团队、市场团队和运营团队等多方沟通协作，确保产品从规划到落地都能顺利进行。
在这个过程中，产品经理要充分调动各方资源，解决项目中遇到的问题，确保项目按时按质完成。
第三，产品经理需要具备较强的数据分析能力。
数据分析是产品经理工作中不可或缺的一环，通过对数据的挖掘和分析，产品经理可以了解产品的性能、用户行为和市场需求，为产品优化和迭代提供有力依据。
同时，数据分析还能帮助产品经理评估产品的市场表现，为决策提供数据支持。
第四，产品经理要具备一定的技术背景。
虽然产品经理不需要像开发人员那样精通编程，但了解基本的技术原理和产品开发流程是必不可少的。
这样，产品经理在与开发团队沟通时才能更加顺畅，更好地理解开发人员的痛点，从而提出更有针对性的解决方案。
第五，产品经理要具备创新思维。
在快速发展的互联网时代，创新是推动产品不断迭代升级的关键。
产品经理要敢于尝试新的技术和理念，勇于打破传统思维，为用户提供更加优质、便捷的产品体验。
第六，产品经理要具备良好的抗压能力。
产品经理的工作往往面临着巨大的压力，如项目进度紧张、市场变化迅速等。
在这种情况下，产品经理要保持冷静，积极应对各种挑战，确保产品顺利推进。
总之，产品经理的工作职责是多方面的，既要关注市场，又要协调团队，还要具备数据分析和技术背景。
以下是我对产品经理工作职责的几点感想：1. 产品经理是连接用户、市场和开发团队的关键桥梁，肩负着推动产品成功的重要使命。
2. 产品经理要具备敏锐的市场洞察力、良好的沟通协调能力、较强的数据分析能力、一定的技术背景和创新思维。
3. 产品经理需要具备良好的抗压能力，积极应对各种挑战，确保产品顺利推进。
产品经理每周工作感想
时光荏苒，转眼间又到了一周的尾声，回顾本周的工作，我感慨颇多。
作为一名产品经理，我深知自己的责任重大，既要关注产品的整体规划和战略布局，又要关注产品的细节设计和用户体验。
以下是我本周的一些工作感想。
一、用户体验是产品的灵魂本周，我们团队针对一款新产品进行了多次用户调研，从用户需求、使用场景、操作流程等方面进行了深入分析。
我发现，在产品设计过程中，用户体验始终是核心。
只有深入了解用户，才能打造出真正符合用户需求的产品。
因此，在接下来的工作中，我将更加注重用户体验，努力提升产品的易用性和满意度。
二、沟通协作是团队发展的基石本周，我与团队成员进行了多次沟通，确保项目进度和目标明确。
在沟通中，我发现团队成员各有所长，大家互相学习、互相支持，共同进步。
沟通协作不仅有助于提升工作效率，还能增强团队凝聚力。
在今后的工作中，我将进一步加强与团队成员的沟通，共同为产品的发展贡献力量。
三、数据分析助力产品优化本周，我们对产品进行了数据分析，通过用户行为、留存率、活跃度等关键指标，对产品进行了全面评估。
数据分析结果显示，部分功能存在使用率较低、用户体验不佳等问题。
针对这些问题，我们制定了相应的优化方案，旨在提升产品品质。
在今后的工作中，我将更加重视数据分析，为产品优化提供有力支持。
四、学习与成长是永恒的主题本周，我参加了公司组织的产品经理培训，学习了产品经理的职责、技能和职业素养。
通过培训，我对产品经理的工作有了更深刻的认识，也明确了自己的职业发展方向。
在今后的工作中，我将不断学习，提升自己的专业素养，为团队和公司创造更多价值。
五、创新思维是产品发展的动力本周，我们团队针对现有产品进行了一次创新研讨。
在研讨过程中，大家积极提出自己的想法和建议，为产品注入了新的活力。
创新思维是产品发展的动力，只有不断创新，才能在激烈的市场竞争中立于不败之地。
在今后的工作中，我将鼓励团队成员发挥创新思维，为产品注入更多亮点。
总结本周的工作，我深感责任重大，但也充满信心。
优秀产品经理感悟心得体会(3篇)
第1篇作为一名产品经理，我深知这个岗位的重要性和挑战性。
在过去的工作中，我积累了丰富的经验，也收获了许多感悟。
以下是我对优秀产品经理的一些心得体会，希望能对同行们有所帮助。
一、明确目标，把握方向优秀的产品经理首先要明确自己的目标，这个目标不仅包括短期目标，还要有长期目标。
在制定目标时，要充分考虑市场需求、用户需求以及公司战略，确保产品发展方向与公司整体战略相一致。
1. 市场需求：深入了解市场动态，关注竞争对手的产品特点、优劣势，把握市场趋势，为产品定位提供依据。
2. 用户需求：通过用户调研、数据分析等方式，了解用户需求，将用户需求转化为产品功能，提升用户体验。
3. 公司战略：结合公司战略，明确产品发展方向，确保产品在市场上具有竞争力。
二、团队协作，共同成长产品经理在工作中需要与多个部门进行协作，如研发、设计、市场、运营等。
因此，团队协作能力至关重要。
1. 沟通能力：与团队成员保持良好的沟通，确保信息畅通，提高工作效率。
2. 协调能力：协调各部门资源，确保项目顺利进行。
3. 激励能力：关注团队成员成长，激发团队活力，共同提升团队实力。
三、关注细节，精益求精产品经理要关注产品的每一个细节，从用户体验、功能设计、性能优化等方面入手，力求打造出优质的产品。
1. 用户体验：站在用户角度思考问题，关注用户在使用过程中的痛点，不断优化产品。
2. 功能设计：根据用户需求，设计合理的产品功能，提高产品易用性。
3. 性能优化：关注产品性能，提高运行速度，降低故障率。
四、创新思维，勇于突破优秀的产品经理要有创新思维，不断寻求突破，为产品注入新鲜血液。
1. 市场调研：关注行业动态，了解用户需求，挖掘潜在商机。
2. 技术创新：与技术团队紧密合作，引入新技术，提升产品竞争力。
3. 产品创新：不断优化产品结构，创新产品形态，满足用户多样化需求。
五、数据分析，精准决策优秀的产品经理要具备数据分析能力，通过对数据的挖掘和分析，为产品决策提供有力支持。
产品经理工作总结与反思
产品经理工作总结与反思一、工作总结作为一名产品经理，我深知自己的职责是为公司和用户提供优质的产品。
在过去一段时间的工作中，我不断学习和成长，积累了一些经验和教训。
在这里，我将对自己的工作进行总结，并提出一些反思和改进的建议。
1. 项目管理能力在项目管理上，我始终保持高度的责任心和积极的态度。
我努力与团队成员沟通合作，确保项目按计划完成。
我意识到在项目启动前更加深入地研究和了解用户需求的重要性，这样可以更好地制定产品规划并有效地分配资源。
此外，我还发现在项目执行过程中更加注重细节，做好风险管理和问题解决，可以更好地提高项目的成功率。
2. 用户需求分析用户需求分析是产品经理的关键工作之一。
在过去的工作中，我通过用户调研、市场调查和竞品分析等方法，了解用户的真实需求，并将其转化为具体的产品需求。
然而，我也意识到自己在需求分析中存在一些问题。
有时候，我可能过于关注内部技术的可行性，忽略了用户的真实需求。
为了提高需求分析的准确性和针对性，我计划加强对用户行为和市场趋势的研究，并更多地进行用户访谈和反馈收集。
3. 创新能力作为产品经理，创新是非常重要的素质。
我深知只有不断创新才能在激烈的市场竞争中脱颖而出。
在过去的工作中，我不断思考和探索新的创新点和解决方案。
然而，我也明白自己在创新能力方面还有提升的空间。
在未来的工作中，我打算加强对行业前沿技术和趋势的研究，与研发团队密切合作，共同开展创新项目，并推动创新文化的培养。
4. 团队合作在团队合作方面，我意识到沟通和协调能力的重要性。
在过去的工作中，我尽量与团队成员保持良好的沟通，确保大家对产品目标和计划有清晰的认识。
但是，我也注意到自己在一些关键问题上可能没有及时和全面地与团队成员进行讨论和协商。
为了加强团队合作，我计划提高自己的沟通和协商能力，并营造一个积极互助的团队氛围。
二、反思与改进通过对自己过去工作的总结，我深感产品经理这个职位的挑战与压力。
产品经理既要了解用户需求，又要关注市场竞争力，同时还要与团队协作，推动产品的开发与推广。
作为产品经理的工作总结与反思
作为产品经理的工作总结与反思作为一名产品经理，我在过去的一段时间里积累了丰富的经验和知识。
在这篇文章中，我将对我的工作进行总结与反思，分享我在产品管理方面的成长与收获。
首先，作为产品经理，我深刻认识到产品的核心是用户。
在产品的开发过程中，我始终将用户需求放在首位，通过调研和用户反馈来了解他们的真实需求。
我学会了倾听用户的声音，从而更好地理解他们的痛点和期望。
这种用户导向的思维方式，帮助我更好地设计和优化产品，提高用户体验。
其次，作为产品经理，我注重团队合作与沟通。
在产品开发的过程中，我与设计师、开发人员、市场人员等多个团队紧密合作，确保产品的顺利推进。
我学会了与不同背景和专业的人合作，了解他们的视角和需求，以便更好地协调工作。
通过有效的沟通和协作，我能够更好地推动项目的进展，实现团队的共同目标。
另外，作为产品经理，我注重数据分析和决策。
通过收集和分析用户数据，我能够了解产品的使用情况和用户行为，从而做出有针对性的决策。
我学会了运用数据驱动的方法，将数据转化为有意义的见解和策略。
这种数据驱动的决策方式，使我能够更好地优化产品功能和推动产品的发展。
在工作中，我也遇到了一些挑战和困难。
例如，需求变更和时间压力常常让我感到困扰。
然而，我学会了灵活应对变化，并通过合理的时间管理和优先级设定来应对时间压力。
我意识到，在快速变化的市场环境下，灵活性和适应能力是非常重要的。
此外，我还发现自己在某些方面需要进一步提升。
例如，我希望能更好地理解市场趋势和竞争对手的动态，以便更好地把握机会和应对挑战。
我也希望能够进一步提升我的项目管理能力，更好地协调和管理团队资源。
总结起来，作为产品经理，我在过去的工作中不断成长与进步。
通过注重用户、团队合作、数据分析和决策，我能够更好地设计和优化产品，提升用户体验。
同时，我也面临着一些挑战和需要提升的方面。
我将继续努力学习和成长，不断提升自己在产品管理领域的专业能力。
以上是我作为产品经理的工作总结与反思，希望能对我未来的工作有所启发和帮助。
产品经理人员个人总结范文5篇
产品经理人员个人总结范文5篇第1篇示例：产品经理是一种极具挑战性的工作岗位，需要具备强大的项目管理能力、市场分析能力、团队协作能力和创新思维能力。
以下是我作为产品经理的个人总结：作为产品经理，我深知自己需要具备敏锐的市场洞察力。
在市场竞争激烈的环境下，产品经理需要对行业动态、竞争对手的产品特点、用户需求变化等有着敏锐的嗅觉。
通过市场调研、用户反馈等方式，及时发现市场的变化，对产品进行优化升级，保持产品的竞争力。
作为产品经理，我注重团队合作。
产品的研发过程需要多个部门的密切配合，包括市场部门、研发部门、销售部门等。
我非常重视团队合作，注重团队沟通，协调各部门之间的关系，促进团队的协作效率，共同推动产品的研发进程。
作为产品经理，我持续追求创新。
创新是推动产品不断前行的关键。
我积极跟踪新技术、新理念，不断寻求产品的创新点，提升产品的用户体验，增强产品的市场竞争力。
我也注重挖掘团队成员的创新潜力，鼓励他们提出建设性的意见和建议，促进团队的创新氛围。
在工作中，我也非常重视产品的规划和管理。
我会制定详细的产品规划和目标，明确产品的定位、目标用户群和产品特点，并制定相应的产品推广策略。
我也注重产品的进度管理和风险管控，及时发现问题，调整产品研发方向，确保产品按时交付，并保证产品的品质。
我也具备较强的沟通能力和解决问题的能力。
在与各部门合作中，我能够清晰、有效地传达产品目标、需求等信息，协调各部门的工作;我也能够快速定位问题，找到解决问题的方法，确保产品的顺利推出。
第2篇示例：产品经理是一项需要不断学习和成长的职业，通过不断地总结和反思自己的工作经验，才能更好地提高自己的能力和水平。
以下是我个人作为产品经理的个人总结。
在工作中，我不断学习各种专业知识，如项目管理、市场营销、用户体验等方面的知识，不断提升自己的综合能力。
在实际的项目中，我经常借助各种工具和方法，如数据分析工具、用户调研方法等，搜集和分析市场和用户数据，使产品和市场有机的结合在一起。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
一线产品经理的工作感想
只是个人的工作心得和所思所想，信马由缰一通，做产品的人能大致看得懂就行了。
没啥铺垫的，直入正题，一块块来：先上一张图
需求文档看不看
当你辛辛苦苦写出来一堆需求文档，跟UED的同学定好交互、视觉、重构;满以为技术会认真对待，但是你会发现，技术同学基本不会看你准备的一堆东西，基本是按照自己的理解来开发，当开发不下去，第一时间也不是看文档，而是看测试用例，或者直接跟产品沟通;基本文档只是QA同学对着写用例。
刚刚开始工作的时候，对于技术不按照文档开发，是比较着急上火的，经历一段时间后，发现重点就好了。
产品的本质是保证产品核心功能的质量，保障用户体验，用户端和商户端的功能不能含糊;运营后台、客服后台之类的，保障功能完整和业务流畅的基础上，可以给技术适当的自由发挥;就算是前台页面，多听听技术的意见，让技术同学参与进来;开发过程中，保持沟通，对于技术提出的问题，最快速度的响应。
什么样的需求要写文档?对于功能性、涉及业务流转，状态切换，边界条件灰常多的需求，流程图、交互、PRD一个都不能少;对于非功能性的需求，提升用户体验的部分，文档可以不准备，准备好原型图，然后在上面标注出重点，交付的时候讲清楚。
todolist与优先级
产品在迭代过程中，不断有新的需求，不断有需求被完成，通过list来管理这些需求，整理的过程也是对产品思考的过程，不停问自己，这个需求用户是谁，解决什么问题，是否必要，以及是否必要现在就做?
list的好处就是，可以尽量多的记录所有需求，虽然有些天生就是被砍的命，但是list 一堆需要完成的事情，对整个项目组都会有紧迫感;一句话讲清楚每个需求，标明优先级，负责人，对应的开发，开始时间，完成时间，完成状态，让项目组所有人(包括老板)，都知道我们现在有多少事情在做，已完成来多少，接下来做什么。
需求永远做不完，对于优先级安排，平时工作中最常用的就是四象限法，重要又紧急，重要不紧急，紧急不重要，不紧急也不重要，根据项目实际来做判断。
需求会议
2014年都是一周一次迭代，每周都会有下次迭代的需求会议，并不是真正意义上的需求评审，产品驱动的公司，基本就是需求讲解，交付，以及相关时间点确认
需求准备要充分
在需求会议上，面对技术和QA，甚至老大们的挑战，这是正常的，他们会问为啥要这么做，为啥不那么做，甚至直接对你的需求提出挑战：这个东西不靠谱，不可能;拍桌子打板凳的事情也时有发生;唯一避免发生的情况，就是对于需求的准备要充分;不管面对何种挑战，讲清楚数据、用户需要、和竞争对手怎么做的，基本就能说服;一般只要保持平和的心态，不会有大问题。
真有自己无法立即解答的，快速承认错误：不好意思，这个是我没有准备好，会后我再去做详细调研和准备，快速跳过这个问题，继续下面有把握的内容;会后再去完整论证，并把问题描述清楚，邮件给大家;既可以避免冲突，会后大家平和心态来对待，也便于解决。
讲好我的故事
这里应该是讲好用户的故事，为啥叫讲好我的故事，因为产品需要把自己代入到各个角色中;做过几次用户访谈，很多用户描述这样一个场景，我快下班了，拿出点评App搜索附近找吃的;运营说这个这个很烦，我需要这么这么做，其实可以这样就解决了;
客服说，这个信息在这里查，那个信息在另外一个页面，每条记录处理的时间增加多少分钟;
最有意思的是商户端，商户那边有签合同的、店长、负责人、前台、收银，会计，每个人都有可能来用我们的后台，去商户端做访谈的时候，观察他们如何使用点评的产品;
讲需求的时候，先描述用户遇到的困境，绘声绘色，动人心弦;如何做到，代入自己的角色，不要假装用过，而是自己真正使用过程中的痛点，放大再放大，感情方式来打动技术。
描述痛点只是第一步，可以清楚描述，如果这个需求做来，运营效率可以提升多少，节约多少成本，最终转化率预计提高多少，以及ROI(投入产出比)，所有功能点的改进，最后都可以结算为Money，因为钱，会让所有人兴奋，并集中精力来解决问题。
让更多的人参与需求讨论
需求被挑战，会有点不舒服;但是若所有人都表现出对你的需求漠不关心，那才是最难受的。
如何让技术更多的参与需求讨论：首先可以挖掘对业务有兴趣的人，多跟他们聊，他们会主动告知他们的想法。
一般工作几年的技术比刚刚工作的童鞋更关心;其次让技术有存在感，定时告知他们相关的产品数据，月用户数，月增长量，收入等，根据技术所开发的功能点，细化到此功能带来的数据，以及同比环比数据;最后在Scrum中，计划扑克能够让所有人都参与到需求当中，因为每个人都要评估task的工作量，目前来看，效果还不错。
确定好时间点和相关责任人
Scrum确实是一个好的方式，能够估算出工作量，并且技术自发领取任务，直至每个人工作内容都填充满整个sprint。
在未开始Scrum之前，每周一次需求会议，只是交付好相关需求，由开发主管来指派任务，并定好工作计划表，然后QA同学补充相关测试安排，最后敲定上线时间。
其实不管何种方式，最终的结果导向就是，产品尽快上线，且以最有效、风险最小的方式。
适当地砍需求
产品是不需要懂技术，但是如果能根据需求大致预估工作量，排期更简单;每次我都会提前多准备一些，连交互和重构都准备好，摆出一副不做此需求是誓不罢休的架势;资源充分时，技术童鞋会主动领取需求的，但是当工作都排的比较满的时候，就很难了;所以需求评审时，每个需求的优先级都排的高高的，将用户痛点描述的栩栩如生，如果技术实在抱怨太多，或是总拿那样的婚恋网站来举例，那就象征性地砍掉一部分，前提是保证核心必须完成，其实当时砍掉一部分，不会一直砍下去，而且心里也会有满足感;其次给技术紧迫感，赶紧完成，后面还有一堆事情呢，即使这次迭代不做，下次迭代也需要完成。
产品开发过程中
保持沟通
在产品开发过程中，技术都是非常有责任心的，会帮你考虑边界条件，作为产品积极响应技术提出来的各种疑问，是维系技术与产品之间很有效的方式。
虽然有一些问题，可能是技术对需求的理解并没有产品那么深刻，讲清楚就好了，没有必要上纲上线，因为最终大家的目的都是为了产品，另外公司开始实践的Scrum也对整个团队保持沟通，既是要求，更要成为一种习惯。
认真对待测试用例
测试用例，又是一个保证产品质量的利器;刚开始工作的时候，认为测试用例只是QA同学的工作，第一版本App上线做UAT的时候，发现对着需求文档并不能完整验证完所有需求，但是对着测试用例，所有的主流程，辅助流程，边界条件，非功能性需求，清晰明了，感觉太有用了。
所以每次都提前完成需求文档交付QA，QA在技术正式进入研发完成用例文档;在过测试用例时，产品同时参与，避免一些需求理解上的偏差，此外技术同学对着case开发，比需求文档描述更清晰，另外技术同学可以参与部分自测;UAT的时候，也是产品的参考。
需求变更与delay
需求变更是永恒的话题，Scrum中一般是不接受需求变更，其实不允许变更的本质不是需求定板不动，而是对产品提出了更好的要求，从需求调研、准备、设计、交付每一步都需要考虑周全和清楚;即使在要求严格的Scrum中，需求真的不能变更么?如果临时线上bug造成用户无法访问，技术同学是不是要停下手中工作，来排查线上故障呢。
作为一个产品，不
是神，尽量保证所有的需求都是合理且必要，并且将所有的需求准备工作做到位;如果还不能避免，就要影响甚至说服整个团队来拥抱变化。
正确处理需求变更
需求变更已经发生，那就赶紧处理吧。
如果是产品没考虑清楚，用户调研或者数据支持出错，果断向团队承认自己的错误，没有人会责怪一个真心诚意道歉的人;并在第一时间交付变更后的需求文档、交互、视觉、重构等，并跟技术沟通如何以最小的代价，完成此次实现;若技术的工作在本次迭代已经安排很满，那考虑需求的紧急程度，适当情况下，可以放到下个迭代去完成。
若是因为行业或者市场变动，产品转型等原因，直接向团队传达变更的原因，以及接下来的产品规划，让所有人都看到一个清晰明确的目标，技术会有疑问和挑战，耐心解答，通过行业数据、竞品等角度去阐述;遇到老板变更需求，那比较简单，因为老板的需求优先级永远是最高的，但是作为跟技术直接沟通的产品，要认真对待老板变更的部分，若老板频繁变更需求，烦的是技术，会不会以后合作留下影响呢。
关于产品delay
不管产品还是技术，没有人愿意看到delay的;面对delay，怎么处理?换个思路：就算delay了，只要用户还能用，服务照样跑，地球还照样转。
如果真的导致用户不能访问，整个技术团队肯定加班加点，不吃不喝也会搞好的。
一旦出现delay，整个团队一起来排查delay 原因，是需求变更，还是资源没到位，还是项目之间的耦合关系，前面小的改动，导致后面项目的延期，做好每次的总结会议，并在下一个迭代中避免此问题。
目前团队中正慢慢引入Scrum敏捷开发，而本篇总结，大部分是基于小瀑布模式的迭代;需要学习的还有很多，一转眼又过了两个月，正式工作已经八个月，需要走的路还有很多，跟随整个team一起成长。
算是工作总结吧，主要是自己梳理一下，路还长，继续跟着一班牛人加油呗！
3 定义、符号、缩略语。