真假敏捷开发产品交互视觉开发间的合作
Posted 未来演化师
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了真假敏捷开发产品交互视觉开发间的合作相关的知识，希望对你有一定的参考价值。
0、先来一张导图
1、概念
简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。
换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷最大的特色是迭代式开发。
2、优势
1、敏捷开发属于增量式开发，对于需求范围不明确，需求变更较多的项目而言，可以很大程度上响应及拥抱变化。
2、对于互联网产品而言，市场风向转变很快，需要一种及时快速的交付形式，而敏捷开发则能更好地适用于此。
3、敏捷开发可最大程度体现80/20法则的价值，通过增量迭代，每次都优先交付那能产生80%价值效益的20%功能。能最大化单位成本收益。
3、误区
4、特点
5、核心原则
6、捷开发与瀑布模型开发
瀑布模型开发
敏捷开发
某博主po的一个很有趣的“敏捷和瀑布”对比例子，给大家作为阅读参考：
6.1、敏捷开发
客人到餐馆来点菜（新项目）
不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）
根据图文菜单，客人点了是个菜（根据原型和设计稿，基本确定了需求）
后厨开始准备（项目启动）
配菜、炒菜，先上了两盘，让客人尝了尝味道（先提供可用实例给客户用）
客人说还不错，后厨继续准备后面的菜，陆续上菜（不断迭代，不断测试）
上菜过程中，客人突然发现有个菜的味道太淡了，让后厨加了点盐又端上来了（敏捷的好处，可以不断测试和需求变更）
又上了两盘，不够辣，又拿到后厨加了辣（敏捷的坏处，需求没有提前明确，反复迭代，增加了工作量）
到最后两盘时，客人要求换两个菜，还好没炒（迭代的好处，随时接受需求变更）
客人吃完，很满意（基本满足了全部的要求）
6.2、瀑布模型开发
客人到餐馆来点菜（新项目）
不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）
根据图文菜单，客人点了十个菜（根据原型和设计稿，基本确定了需求）
后厨开始准备（项目启动）
根据客人的下单配菜，炒菜（基本上不会主动去了解完整需求）
半个小时了，菜还没上桌，客人饿极了（项目启动后很长一段时间客户什么都看不到）
再过了二十分钟，十个菜都一起上来了（项目最终一次交付）
客人说，有几个菜挺好的，但是有个菜味道淡了，有两个不够辣，还有两盘重复了想换掉（我是买单的，我要变需求）
这时候大堂经理来了，说，“味道淡了可以加盐，不辣可以加辣，但是换菜不行，已经炒好的那两盘菜也是要算成本的”（瀑布的坏处，需求变更比较麻烦）
于是，后厨只给客户加了盐，加了辣
客人吃完，不是很满意，下次不来了（没有满足需求）
7、总结
但总的来说，在现在管理项目过程中，并没有严格的按照完全的敏捷或者完全的瀑布模式，都是各自掺杂了其他的方式。在实际项目过程中，过于强调模式并没有意义，重要的是能不能预防问题的发生，在问题发生之后能不能用最小的成本解决，模式更多起一个参考作用
最后借用民国时候的一句话：少研究一些主义，多关注一些实际问题
从半年之前，为了快速相应市场的变化和为无数的ABtest做基础准备，产品开始初步响应敏捷的速度，版本由每月一个发布改为做每周一个版本。
一个月之前，团队迎来了敏捷教练，在敏捷教练的带领下，我们逐步由“假敏捷”渐渐开始尝试 “真敏捷”，作为产品经理的我，也开始了和敏捷相爱相杀的过程。
这里总结和分享下：
什么是假敏捷和真敏捷？
用户故事的魔力
敏捷中的团队精神
敏捷给产品经理带来的成长。
一、真敏捷还是假敏捷？
事业部是在去年年底开始实时每周一个版本的迭代，那个时候,在全公司我所在的项目组是第一个开始做频繁发布的。
在变幻莫测的互联网环境下，快速的响应和发布是非常必要的，并且能得到ABtest的快速验证。
但是在这种快速迭代的初步尝试中，团队慢慢出现了一些问题。
1.假敏捷-7个团队各自为营
我们从一个需求从产生到落地的过程来看，首先需求的来源有一些问题。
3月份在敏捷诊断的时候，几乎所有的产品都把最需要解决的问题投给了“产品定位”。
产品定位可以没有明文规定，但是在快速奔跑的过程中，每个人都要有一致的目标。
当项目组的每个人对产品的理解不一致的时候，我们传达给用户的，也是一些非常矛盾的东西。
同时，需求的产生是在每一条业务线中产生的；按照不同的业务线，产品、开发、测试被分成了7个团队，团队之间更多的是一些同步的工作，缺乏沟通和讨论。
没有总体的共识，一个APP被分为7个团队，需求的产生比较分离，没有重点。
在需求迭代的过程中，每个组是只有一个开发和测试加入到需求讨论中，最后把会议精神带回团队;更多开发和测试的同学是直接按照PRD进行开发和测试的——团队缺乏沟通，对需求细节的把控没有那么到位。
最后，在需求交付的时候，功能核对大概几种是在上线前1-2天。
这会导致很多风险项都没有办法提前暴露，需求理解不一致的情况没有办法得到有效的处理。
2.真迭代-两个团队试点，每周一个敏捷冲刺
敏捷项目启动初期，在面对一个需求从开始到落地的五个环节：“产品定位”-“用户定位”-“需求挖掘”-“需求开发”-“需求跟踪”时，几乎项目组所有核心人员都把最紧急、最缺失的一票投给了“产品定位”。
我们发现，因为没有清晰的产品定位，所以每个人的着力点是不同的；大家像一盘散沙，看似忙碌充实却绵软无力。
最致命的是：因为没有清晰的RoadMap，大家走一步算一步的状态影响团队士气和凝聚力。
于是，产品团队利用将近一个月时间的依据公司战略、产品目标、用户需求和市场环境确定了清晰的产品定位“打造用户的专属摄影师”，以及根据产品定位确定了接下来1-2年的长期目标和近三个月的短期目标。同时，每条线也根据共同目标制定了版本迭代的计划。
“计划的结果是无意义的，价值在与计划的过程本身”，在互联网瞬息万变的环境下，RoadMap肯定是会变的，但RoadMap能够让全项目成员做到“心中有数”，往同一个方向一起冲刺，这就是它最大的价值所在。
在同一个产品目标下，我们把小组分为几个线，在产品内部共同讨论下形成了需求池。
在需求迭代对过程中，我们也发生了一些改变。
例如产品经理开始用用户故事去表达和拆解需求（用户故事会在接下来展开来说），基于用户故事，开发测试的同学参与到了需求细节的讨论中，逐步达成共识。
在需求交付时，大家能够按照故事点做得点对点的每天交付，甚至为了迭代目标的达成，出现交叉开发、交叉测试的现象。
3.Srum Master是谁？
在需求迭代和落地的过程中，敏捷引进了一个非常重要的角色“Scrum Master”（以下简称SM）；项目组渐渐弱化项目经理的角色，开始培养每一个团队的SM角色。
SM是一个对产品迭代推进帮助特别大的人。
目前跑下来在产品看来，SM可以帮忙解决这样几个问题：
a.服务产品，确保每个团队成员都尽可能的理解目标和需求细节;
b.服务开发，移除开发工作中的障碍，帮助开发梳理交付流程；
c.服务组织，带领每一个迭代的进行并持续提升效率。
SM和传统的项目经理最大的区别在于：驱动形式不同。
项目经理是以任务范围驱动时间和资源成本，而SM则是要以时间去驱动任务范围，保证产品以一个节奏持续得往前走。
在敏捷框架下，每周一个迭代是死的（这个死是相对的死，可以根据实际情况做调整）。
每个团队都像赶火车一样在固定的时间点上车，如果没有赶上，把优先级高的需求先保证发布，这样就能保证我们总是在做有价值的事情。
所以每一周，我们就是一个冲刺——时间点基本上是固定的，整个产品是有节奏的一步一步向前。
二、用户故事的魔力
第二部分，想分享一下敏捷实施以来，产品这边最大的一个感受：需求思考和表达的维度从原本的流程图变为了用户故事。
我们首先来看一下：用户故事解决了一个什么样的致命的问题。
我们必须承认的是：文档并不等于共识。
在敏捷的框架中有一个价值观——可交付的版本大于详尽的文档。文档写得再详尽，如果团队成员不够理解，在快速的迭代开发中会大大的影响效率和交付的质量。
我们看这样一张图，当需求评审的时候，大家都说“我懂了”，但是在每个人心里，其实对需求的理解是不一致的；大家需要通过反复的沟通去保证，每个人心中对细节的把控大体一致。
不能够出现产品经理、开发、测试在进入迭代的过程中，最后的交付和产品的预想不一致。
用户故事就是一个梳理需求的框架，它最大的价值是能在迭代开始之前，用这个框架让团队成员迅速对需求达成共识。
用户故事到底是什么样的呢？
就是：一个角色，需要完成什么样的活动，最终达成什么样的目的。
用户故事是一个帮助产品和团队梳理需求的一个很好的框架，我们来看一个实例：
左边是用“界面框图+跳转逻辑+逻辑细节”组成的需求，右边是用用户故事+界面框图表达的需求，我们会发现，左边的表达逻辑比较零碎，而右边结构清晰，考虑到所有的场景不会产生遗漏。
用用户故事表达需求的时候，我们会发现用户故事的几个大优点：
1. 测试和开发不一定有产品视角，但一定会有用户视角，用用户故事去梳理需求能够让大家对该需求的理解更加迅速、深入。
2. 按照场景拆分，需求在整理把控和细节处理上更容易暴露出问题。
3. 拆分之后，按照提供给用户的价值划分优先级，甚至帮助产品找到MVP。
4. 按照用户故事做后期的迭代交付。
三、敏捷中的团队精神
敏捷走了一个月的时候，我们开了一次总结会，回顾敏捷前、敏捷后、敏捷中你认为最大的变化。
开发、测试的同学都在最大的变化的关键词几乎都写上了同一个词，那就是“参与感”——之前的需求评审的时候，产品和开发、测试有一种对立的感觉。
产品像是接受检阅，开发和测试像是被通知。这是一种很神奇的社会心理，当人拿出一个经过自己谨慎思考的方案的时候，其实是难以接受修改和质疑的。
产品经理面对一个自以为很周全的需求的时候，实际上把需求框住了，把自己的思路和别人的思路一同框住。
一旦别人提出一些质疑，会本能的抗拒——这是一种思维定势练。
需求应该是在团队的讨论下涌现得到的，这个团队不仅包括测试、开发，也包括团队里的任何一个角色。
产品把控方向，团队在讨论中不断得巩固和涌现细节。而且在讨论的过程中，我们经常会发现：开发和测试的同学也会有一些新奇的创意，其实他们渴望表达，渴望产品听到他们的意见；并且产品的方案如何落地，细节的部分开发、测试同学会更了解并提出宝贵的想法。
当然我也做了自我的检讨，但是整个回顾会的过程就会让人觉得：大家是一个集体，没有人会默默甩锅给别人。
四、敏捷给产品经理带来的成长
在敏捷的大框架之下，对产品经理有了更高的要求。
不仅是对需求细节对把控能力，更是对整个产品方向和roadmap的把控能力都需要产品经理跟随敏捷的节奏一起成长。
在这短短一个多月的时间里，非常有幸能够参与到敏捷中，同时我也切切实实的感受到了一些成长上的变化：
1.在需求的不断拆分中重新思考需求的价值。如何在有限的时间里做最有价值的事情，如果需求可以拆分，那么MVP是什么？我们在用户视角去拆分需求的时候，会重新定义MVP。
2.用户故事，强迫产品经理始终从用户视角和用户使用场景去思考需求的价值，这个思维转变非常重要。
3.让产品经理从全局和细节对需求有更多的思考。（1）全局的场景拆分（2）注重验收标准的细节，如果丢失重要的细节部分，产品经理需要背锅
4.团队沟通，带团队的能力得到锻炼。让产品经理更参与到团队协作的方式中和团队文化建设的氛围中，我觉得为未来做一个管理的角色有铺垫作用。
做任何改变都是需要付出一些代价的。
经历过一番痛苦的挣扎，我相信在正确的使用敏捷后，团队中的每个人都能收获一定的成长，产品也能在这样的思路和框架下有更大的提升。
PM、交互、视觉、开发是一个产品上线不可或缺的四个角色。现在让我们一起从四个不同角色的不同视角出发，有哪些心酸、埋怨甚至泪水你也有过的，一起来看看解决方案。请将心比心、宽容理解，记得分享给他看。
不做大项目，很难理解多人合作有多么艰难。真正参与到项目中，才发现责任分配模糊、懒于沟通、越俎代庖干涉他人决策等都会让项目进展陷入僵局。虽然合作中常能感受到别人给自己带来的麻烦，但我们却很难发觉自己也在给别人带去痛苦。越是自信，越难发现自己的失误。
花了些时间，总结了下自己的经验教训，又访谈了不同职位的合作伙伴和好朋友，总结了一些各个职位与其他职位合作时最头疼的事。兴许可以帮大家看一下别人眼中的自己。
一、产品经理
面对交互设计师的痛苦：
1. 不主动帮忙提供解决方案，而是先PK需求。
怎么办好呢：交互认清自己和岗位定义，采取积极配合的态度，多提建设性的意见；同时在需求构思阶段产品最好能拉上交互一起讨论，同时为需求寻求客观的用户数据支持。
2. 闷头画稿不沟通，画出一套自己满意的稿，却和自己预期相差很大。
怎么办好呢：建议交互画粗糙纸面稿，经频繁沟通讨论，再绘制精细纸面稿。再次确认沟通后，才用软件绘制精细线框图。逐渐细化，把矛盾逐批解决，不至于积累到最后爆发。
针对交付衔接：
1. 各个角色在交付文档后，承接人的理解会走形。
怎么办好呢：各种交付物在交接时要由负责人在交付评审会上逐条讲解，以实现充分理解。交付物只是用来备案的，不是用来沟通的。
2. 对上游的交付物和交付时间有疑问，不直接询问相关责任人，而是先来询问产品，再由产品转告。
怎么办好呢：对特定角色的工作有疑问，要直接咨询此人，同时确保产品被知会到。
二、交互设计师
面对产品经理的痛苦：
1. 功能点照抄竞争对手，以至于界面无需思考，照抄即可。
怎么办好呢：请产品经理讲清楚每个功能点背后的用户需求和真实的生活场景，描绘该产品对用户的生活会带来怎样的帮助。
2. 需求思考不清楚，经常变更。
怎么办好呢：争取参与前期的需求制定阶段，辅助产品经理讨论清楚用户使用场景和功能点，然后再列述下来。各合作方在需求评审会上公开确认需求。
3. 过度干涉控件布局等细节。
怎么办好呢：产品经理应首先专注于挖掘靠谱的用户需求，并清晰地列述功能点和帮助用户实现的目标。这些用户目标就是用来衡量交互方案是否有效的客观目标。切忌用主观标准否定设计方案。
面对视觉设计师的痛苦：
1. 以美观之名更换控件，扰乱任务流，忽视对相关页面的影响。
怎么办好呢：交互应该设计中期就拉入视觉一起讨论，让视觉知道每个控件的用意，同时坦然接受视觉对交互方式提出的合理建议。
2. 调整控件布局，扰乱元素的主次关系
怎么办好呢：同上。
三、视觉设计师
面对产品经理的痛苦：
1. 用主观的“我不喜欢、我觉得不好看”来否定设计稿，无法用客观的词汇描述预期效果。
怎么办好呢：产品经理应该将对视觉方案的要求书面留档，并以此为作为评估设计方案的客观标准。
2. 经常变更需求，并且天真地认为所需要做的调整超级简单，一秒搞定
怎么办好呢：产品不要低估调整视觉方案的工作量。视觉也可以在初稿阶段试试产品经理的口味，多倾听一下彼此的意见。
3. 对自己的审美能力很自信，对设计稿指指点点说“要这样移、那样调”
怎么办好呢：视觉风格方面产品经理应充分信任视觉设计师的审美能力，给建议时也要态度诚恳，淡化盛气凌人的感觉。
面对交互设计师的痛苦：
1. 布局控件时不与视觉沟通，直接丢一套线框过来。
怎么办好呢：交互邀请视觉参与线框图的设计阶段。
2. 设计的交互稿没新意，太老套死板，了无趣味。
怎么办好呢：交互要多玩多看多体验，丰富自己的设计储备库，以便厚积薄发提出让人眼前一亮的设计。
面对开发工程师的痛苦：
1. 改参数，并坚称自己做的更美观。
怎么办好呢：视觉对于自己责任范围内的设计稿参数标注要尽量详尽，给出完备的视觉设计稿作为客观的衡量标准。在开发完成后要及时走查，并跟进问题的解决。
2. 不用切图素材，用代码来实现效果。
怎么办好呢：视觉首先要确保给出的切图素材十分完备；开发也要克服惰性，将视觉素材充分利用起来。
3. 对像素、肌理、阴影不敏感，看设计稿不仔细，实现效果与视觉稿差异很大。
怎么办好呢：对开发容易忽略的视觉细节，视觉设计师要与面向开发讲述。交付的设计稿只是备案，不是高效的沟通方式。开发同志们是没有视觉那样的像素眼的。
四、开发工程师
面对产品经理的痛苦：
1. 对产品前景没有充足考虑，每次发新版本代码都需要推到重来。
怎么办好呢：产品经理要明确产品发展的大方向，并将远景清晰地阐述给合作伙伴，以便开发在搭建程序时为未来留好空间。
面对交互设计师的痛苦：
1. 设计稿缺少细节：每个页面可响应事件的区域，响应的动作，操作成功和失败的反馈。
怎么办好呢：交互设计师除了描绘页面之间的跳转关系，还应该将页面内部所有的事件响应文档化，减少开发的误解。不要怕麻烦。
面对视觉设计师的痛苦：
1. 没有定量标注设计稿的每一个细节。
怎么办好呢：请视觉认识到定量标注细节对于开发无损地实现视觉稿的重要性。开发是没有精力去猜或者量一个特定参数的。
2. 切图不完备，遗漏细节，需要开发自己用代码补。
怎么办好呢：每一个细节的素材都切图切出来，并系统地使用文件名命名方法，帮助开发理解。
小结
一遍看下来，有没有觉得背上冒冷汗呢？一切依着自己的性子往前走，真的很难发现自己有哪些地方做的不对，不知不觉就给别人留下了心灵的创伤。其实合作也很简单，多积极参与一下上游的决策，知根知底；多耐心向下游讲解一下那些只存在于自己脑子中的主观想法，倾听一下他们的建议和疑惑。多往彼此那边靠一靠，心就能挨得近一点。记得分享给那个他看看哦。
以上是关于真假敏捷开发产品交互视觉开发间的合作的主要内容，如果未能解决你的问题，请参考以下文章