设计人员和开发人员如何协作，如何与开发团队高效协作？

本文是关于开发者团队协作-开发团队高效协作

大多数产品开发周期都是以设计开始，以开发结束，但我认为，好的产品从一开始就将设计和技术结合在一起，综合考虑技术和设计可以减少两者间的切换（以及低效率的问题），释放出两种技能的创造潜力。

通过这种合作方式，Work＆Co成功推出像Virgin America的iOS版本和Android的APP版本，这个项目是依赖创新的技术解决方案来实现我们的设计想法。

现在我想分享设计和开发协作的5个方面，从而推出更好的产品。

组建团队，一起决策

设计和开发在一开始就应该作为团队一起协作，这个团队还应包括我们的客户，他们会经常参与定期的评估和反馈，这样就不需要花时间去等待确认可行性，我们将业务，设计和技术想法从一开始就整合到项目中。

最近我们为一个视频平台创建了APP，这个项目的成功离不开这种协作方法。这个视频平台APP产品概念是围绕创新的色彩采样技术，可以调整UI的颜色以实时匹配视频。

为了测试这个想法，我们团队（包括设计师和产品经理）立即开始构建原型，这样就了解颜色变化是否需要更快，或更慢，或定时变化。与先画线框图，再出PSD文件的协作方式相比，我们节省了很多时间，并且确认得更快。这也意味着当我们开发时，我们知道真正的设计意图。

省去设计和技术间的切换，出现问题大家也不会相互推卸责任，大家作为一个团队朝一个目标不断完善产品。

项目开始时就让开发人员参与进来

在许多公司中，开发人员只有在在开发的时候才参与到项目中。

开发人员其实可以验证设计可行性，并从技术的角度指出未来可能出现的问题（或令人兴奋的新想法）。

开发人员的洞察力是任何项目成功的关键。没有开发人员的技术角度，创意团队就会面临将精力投入到无法实现的想法的风险。将技术引入到设计过程中可以发现新的想法，同时确保设计想法得到实现。

为了进一步强化合作，开发人员和设计师不需要循规蹈矩，参与到项目团队并肩作战中，讨论各自工作的可行性，而不仅仅局限于一些重要的评估环节，由此反馈时间更短，产品的流程更顺畅。

建立开放沟通的环境

开放式对话可以使团队中的每个人都能够开拓思路，探索新的想法。开发人员参与早期设计评估环节。产品构建过程中设计人员不断完善设计。我们需要创造的环境是，打破沟通壁垒，每个团队成员都能得到他人的反馈和想法。

我们的团队必须相互信任，尊重每个人的意见，从而带来更加有建设性的对话，并朝着同一个目标努力。

养成验证的习惯

我们希望帮助我们的客户承担更大的风险，并推出更多的创新产品，但我们也有责任确保更大的成功可能性。

我们发现，通过一开始验证，我们可以更快地确定哪些策略起作用。我们不断地迭代，尝试新的方法来解决问题，通常在项目开始的最初几周内，我们就可以得到数十种想法和原型。我们在构想的视频APP时，在确认最终解决方案之前，我们先后做了75个用户界面和交互的原型设计。

这种验证方法使我们能够进行高度针对性的用户实验，无论是关于UX，技术可行性，甚至是产品的任何其他方面。

把精力更多放在原型上，而不是演示上

早在项目开始的第一周，我们就进行原型设计。团队协作意味着我们可以减少演示次数，而是花更多时间去评估正在构建的原型的可行性。与其把花时间和精力放在演示上，不如进行用户测试，邀请用户与功能完整的产品进行交互。这样，设计师和开发人员只需在第一周内就产品进行协作，而不是接下来好几个月来来回回配合。通常来说，设计开发相互协作，在项目开始后一个月内至少得到一个产品原型。

下一次当你准备启动一个新项目时，多花一些时间去评估参与进来设计师和开发人员的想法和专业知识，以及他们如何合作，你可以减少两者间的切换，并促进评估之外的沟通。

设计开发协作这5个方面能使你的团队更活跃，更有成效，并推出更好的数字产品。

开发团队是每一个产品经理和产品负责人的重要合作伙伴：是团队来设计和建造实际产品。但是，要高效地引导并与团队一起工作并不是一件容易的事情。这篇文章将分享 8 个使开发团队更高效合作的小技巧，从而提高创造成功产品的机会。

1.管理产品，而不是团队

作为产品经理或产品所有者，要专注于你的工作，要管理产品而不是团队。对产品提供指导，包括它的市场，价值主张，业务目标和主要功能。要明确分工，让 ScrumMaster 或指导人员来制定流程和组织问题；让开发团队来指出需要怎么做才能实现用户故事和其他产品积压事项。

这里有一个常见的错误，那就是介入并扮演 ScrumMaster 的角色，在没有 ScrumMaster 或者如果个人正在努力做好工作的时候。虽然这可能会在短期内会有一定的成效，但从长远来看，肯定是弊大于利的。承担太多的责任意味着会过于分散自己的精力：不知不觉就会让某些东西悄然溜走。要么你会忽略一些产品责任，要么将你的健康置之脑后。两者皆非你所愿。

2.将团队当作平等的伙伴

还记住 Golden Rule 吗？你想如何被别人对待，就应该以同样的方式对待他人。团队成员不是你的资源，但却是创造你的产品的人。如果你与团队的关系很差，那么你的产品很可能会受到影响。尊重团队成员的 UX / UI 和技术决策，以及他们决定如何完成工作的权利。要诚实和开放。提供建设性的反馈意见并说出你的担忧。但是，不要吩咐别人怎么做他们自己的工作，也要克制分配任务的欲望。开发团队需要能够管理他们自己的工作（使用 Sprint backlog 或看板）。如果团队有斗争，那么帮助团队是 ScrumMaster 的工作——而不是你的（正如上面所讨论的那样）。

3.帮助团队看到更大的蓝图

开发一个成功的数码产品需要的不仅仅是技术知识。在不了解产品上下文的情况下，包括客户和用户是谁，产品为他们创建什么样的价值，什么使得产品与众不同，以及它将如何有利于企业等，制定正确的解决方案几乎是不可能。因此，你应该帮助团队获得相关的市场和领域知识——例如，让团队参与研究和验证工作，邀请他们和你一起访问客户——确保他们知道产品战略和产品发展蓝图，以及企业目标和 KPI。这不仅会带来更好的技术决策和更优的产品。还可以简化了你的工作量：了解更大的蓝图可以让你的团队来帮助创建用户故事，并支持你管理产品积压。

4.让团队参与到产品决策

当你拥有和管理产品的时候，开发团队应该理解和支持重要的产品决策。实现双赢的最好办法是让团队成员参与到决策过程。这也充分利用他们的创造力和知识，并将可能导致更优的决策。有一些技术可以帮助你实现双赢，例如：

要清楚的是，合作需要领导。作为产品的负责人，你应该是开放和协作的，但同时又果决。目标是让开发团队建立共识，但不回避艰难的交互。不要满足于最小的共同点，能够在意见不能一致的时候勇于做出决定：伟大的产品不会因为是少数而服从多数。

5.在团队上花足够的时间，但不要忽视你的其他职责

花时间和团队一起合作以工作于用户故事，回答问题，以及参加会议。如果你不具备或难以达到这样的条件，那么你并非是在指导团队。在最坏的情况下，人们会厌倦等着你来给答案，因此不再咨询你。因此，你最终可能会得到一个需要额外返工或者功能发布不了的产品。

但是，如果你对团队的问题不堪重负，那么要指导团队帮助大家看到更大的蓝图，并让团队参与到产品积压管理和用户故事创建中。这将使他们能够自主开展工作，并且减少你不得不回答的问题量，在你的团队实现用户故事的全速冲刺中。

虽然在团队上留足足够的时间是如此重要，但也不要忽视其他产品管理的工作，例如与用户接洽，工作与产品战略和路线图，以及管理利益相关者。如果你过于以团队为重点，那么你的产品很可能会受到影响。

6.期待高标准，但不要逼迫大家

对团队负责，期待大家做好工作——即保持承诺和尊重达成的协议，交付冲刺目标，团队遵守完成定义以及创建可工作，文档化和测试过了的软件。但是要认识到，软件开发是具有挑战性的，而且是人就会犯错误。如果有一次冲刺目标错过了，也不要对团队发火。但是如果团队屡次不能发布承诺过的事情，那就需要介入了。调查原因，并探讨如何帮助，例如，可以创建较小的用户故事或更优的验收标准。

不要强迫开发团队工作，不要要求完成比他们实际能应付的更多的任务。否则，团队会变得失去动力，并开始走像牺牲质量和忽略文档这样的捷径。在最坏的情况下，大家会生病或跳槽。相反，让团队参与设置一个有意义的冲刺目标，不但能够为团队提供动力和指导，还可以尊重团队决定工作如何完成的权利。这将建立一种可持续的速度，并让你的团队保持动力。

7.给团队空间来试验和学习

为了创造价值，产品需要提供一些新的东西；它需要创新。为了帮助你的产品在将来创造价值，团队需要时间来学习他们的技能，研究新的技术和工具。但是，如果你一直要求大家工作于新的功能，那么这些就都不可能。因此，你应该给予团队足够的空间来试验新的点子，掌握新的知识。有些团队使用 gold cards 来分配时间以便于冲刺试验和学习；有些人使用 hack days。无论哪种方式对你的团队有用，这都将有利于你的产品和团队士气。

8.全面参与会议（或不露面）

这似乎是一个微不足道的忠告，但是从客观上来说，我看到有不少人敷衍了事地参加开发团队的会议。参加会议前要做好准备，全面参与——电话静音，收起你的笔记本电脑和平板电脑——或者干脆不要参加。

在 Scrum 的背景下，产品经理和产品负责人的两个最重要的会议，通常是冲刺规划和冲刺审查。你应该总是致力于出席这些会议，并做好必要的准备工作，比如，优先产品积压和提炼用户故事以用于冲刺计划或邀请合适的人，并选择合适的产品验证技术用于审查会议。但不要促进这些会话。让 ScrumMaster 来担当这个角色。

以上就是小编为大家整理的开发者团队协作-开发团队高效协作

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。