腾讯一直推广敏捷开发，也在强调敏捷开发，但你会发现，即便如此，还是会陷入以下情景

• 又丑又长的讨论会
• 好像人手永远不够
• 不切实际的想法
• 悬而不决的功能点
• 无穷尽的偏好设置
• 越来越多纠缠不清的细节
• 项目依然延期

我们如何构建一个更轻巧的开发流程，让我们更快更好的交付结果？作为一个设计师，如何成为敏捷的一分子？以下是一些心得方法，希望和大家分享

1 界面先行

作为设计师，最简单能让大家明白你的想法就是先把它画出来，不要用晦涩的语言和结构图，毕竟不是所有人都能把你的语言转化为图像。而且界面（视觉，交互）设计是相对轻量级的，修改起来也简单，成本也低。但修改程序就远不是那么回事了。保持界面先行可以让你非常灵活，至少在开始🅠开发之前可以随意修改。

界面先行另一个最重要的原因就是，对于用户来讲，界面就是你的产品，界面可以帮助你从用户角度看待自己的产品，如何展现，如何操作，给人感觉怎么样，是不是易用。只有当你面对真正界面的时候才能回答这些问题，文档概要并不能帮你解决实际用户体验问题。

2 初期不需要太关注细节

虽然大家总说，成功来源于细节，当然，这非常对。但前期过分关注细节的同时也会令你止步不前。先把大框架确定下来，而💯不是一直纠结于

• 这条提示怎么写更合适？
• 文字字号用16还是14？
• 要不再往左挪1像素？
• 这里加个高光把
• 把2像素的描边变成1像素

你需要关注细节，但不是现在。♍所有事情都要从大到小的去做。先把他做🅺出来，把该放的东西放上去，然后实际去用一下。

细节是你在使用的过程中才会慢慢显露出来，只有在使用中你才会发现哪些更值得关注。如果你有足够的时间，当然可以面面俱到，如果🌠没有，请先把精力放在最重要的事情上。

3 不要纠结那些还没有成为问题的问题

“当我们的用户用了这个功能以后还想跟另一个功能配合使用怎么办？”

如果想快速推出版本，就先解决当下。不要花太多时间去考虑还没有成为麻烦的问题。别担心，你还有后꧂续版本。

而且你就真那么确定用户想跟另一个功能配合使ᩚᩚᩚᩚᩚᩚ⁤⁤⁤⁤ᩚ⁤⁤⁤⁤ᩚ⁤⁤⁤⁤ᩚ𒀱ᩚᩚᩚ用么？如果不是，就先放一边，🅺等问题真正浮出水面的时候再去快速解决。

4 帮助产品经理精简功能

好像大家都在弩着一股劲，比谁做的多。竞争对手的产品如果做了**，我们就要做***，他们有4个功能，我们就要做5𒈔个。如果不做，拿什么跟他们竞争♛？

这种方式是行不通的，因为你会发现，永远是赶超，永远没有自己领跑的那一天。怎么办？

做少

通过做少来打败他们

做的功能越多，功能间的交互就会越复杂，用户的学习成本就会越高𝐆。而我们的用户真的用的上那些高深的功能么？他们会不会已经被那些多如牛毛，但我们自以为高明的设置搞得疲惫不堪？试𓄧着少做一点，让自己的产品更加轻巧而更具备亲和力——没有人会喜欢使用显得自己很笨的软件。

5 功能间更少的牵扯

把一个功能点做的尽量独立，能保证需求改变时更为快速，更为灵活。

如果功能间的牵扯太多，就如同你身上沾满了蜘蛛丝，每做一点改变，其他的都要进行改变，从设计，到开发，到测试。当你发现改变的代价太🐽大时，你就会放弃，然后依旧背负着带有缺陷的功♏能一路走下去。

为什么不开始就尽量少牵扯呢，这样更加来去自如

6 要有自己的主张

虽然交互设计通常都会处在不黑不白的阶段，因为没有绝对的对与错。但我们还是需要坚定自己的🥀主张。也许果断的观ꦗ点看起来目中无人，但总比那些“嗯……其实这样也成……”模棱两可要好的多。敏捷开发中需要的就是快速做决定，而不是唯唯诺诺和稀泥。

————————————————————————————————

也许并不是所有的项目都适合，毕竟初期不考虑细节必然要考虑后ಞ期更改的成本。但对于一个新产品，快速触达用户，让用户来使用，验证，反馈，得到的数据更加真实有效。根据这些反馈作出的调整总是比自己拍脑袋来的简单，更加符合用户需求。

敏捷，并不只是站立晨会，迭代总结，理论，文档，更需要的做的是，把它做出来。

原文：//wsd.tencent.com/2010/08/smaller_faster_and_smarter%e2%80%94%e2%80%94how_could_we_mak🅘e_a_agile_workteam.html