tapd敏捷团队の定义

设计团队如何更加高效地工作——设计流程工具化！

电商用户体验设计部(简称ecd)早期的设计管理是通过各leader跟产品经理收集和手工排需求的形式，但随着产品需求的激增，团队的扩大，每周的设计需求已从每周几十单激增到几百单，部门顺应组建设计管理组，聚焦在流程和项目如何更高效，今天跟大家分享其中的工具化心得。

早期的设计部门的流程是这样的： 互联网的一些事 产品经理写一个设计需求的文档，汇总多个需求到一个填写规范的表格在每周统一时间写给设计排期人(一般是leader，也有的是专门的项目PM)排期人拿到表格后在另外一份排期表格上填写各类需求，处理人，完成时间等期间还需要通过电话和RTX沟通需要调整的需求，再把表格复制到邮件上发送邮件，整个流程下来需要多个表格样式来记录这些信息。

也不方便后续统计需求和相关信息。

后来公司大规模使用TAPD来提交需求，做信息需求管理， 在这个基础上，设计管理部门开始考虑研发一整套流程工具来优化整个流程的方式。

第一步：配置TAPD模版 第二步：研发排期工具和CP排期工具 第三步：研发具有展示作品和发送设计确认邮件的工具 配置适合设计部使用的TAPD模版 TAPD是公司引入的一套敏捷迭代的需求提交工具，是面向全公司使用，提交需求页面有很多不需要的信息，会干扰到提交需求的人，样式可以通过配置模版来解决，前期在配置模版样式的时候，想地比较简单，结果碰到不少钉子，产品同学不乐意配合使用新流程，后面通过与产品单独沟通了解，产品提交的需求是分2个阶段，设计和开发(部分产品项目不同)，在设计阶段的需求，只需要产品填写需求标题，设计详细信息，启动时间，处理人即可，包括附件的交互稿，以前的设计需求都是跟开发配置的入口一起提交的，不方便统计需求量和模版样式，了解到设计和开发需求分开后，根据各设计中心的情况，配置了各自的入口，产品经理只需要找到设计中心自己产品组的入口提交需求就可以正常提交需求，优化后的模版减轻了产品经理填写需求的工作量。

减少了收集人的角色，不用每周拉群去喊人收集需求，她是最有动力去帮你推进这流程的，有她帮助，后续给产品同学做相应的培训也简单好多，所以这次模版调整最大感受就是简单易用的流程能减轻工作量的才能推动别人使用。

排期工具 互联网的一些事 产品经理在规定时间提交填写了需求，设计这边的排期PM使用排期工具进行一键拉取需求，需求对应就显示在不同角色的处理人的下周日期内，PM在排期表里进行调整处理人时间和需求分类等信息。

再通过调取邮件端口的形式，直接把排期表发送给相关的人员。

在2期迭代的计划里，还能在这个排期工具里实现提交需求的入口，会更简单容易操作，如果遇到内部需求消化不完，还能通过迁移需求的方式，把需求转到CP排期系统里(不在这里具体描述CP系统)，形成一站式提交的闭环流程。

具有展示作品和发送确认邮件的工具 以前的设计师缺少一个作品展示和沉淀的平台，发送设计待确认的邮件需要翻找以前的邮件模版修改标题和相关样式发送邮件，解决这2个的问题的工具样式就应运而生，它是一个类似花瓣页面的工具平台来统一展示，在这里除了可以展示作品，还能存储设计作品源文件，通过直接拖拉的方式把PSD文件拖到页面里进行保存，保存好的图样样式通过一键发送邮件会调用设置好的待确认邮件模版完成发送邮件操作，大大减轻发送邮件需要修改之前样式的负担。

通过上面的简单介绍，我们了解到ECD是如何通过工具化来解决流程效率的问题的。

那么我们总结出工具化的主要特征是： – 以完成一项或多项任务为目的 – 注重操作流程引导 – 强调快速完成任务 – 非完成目标的唯一手段，只是协助用户更高效完成该目标 通过一系列的工具使用，在流程上能给设计师带来更轻松的操作体验，工具非完成目标的唯一手段，只是协助用户更高效完成该目标。

产品经理需要掌握的工具一般都有哪些

1、Axure RP（Rapid Prototyping） Axure（读音为Ack-Sure）无疑是目前最受关注的原型开发工具，其能通过组件的方式帮助网站或软件设计师快速建立带有注释的原型（流程图、线框图），并凭借自定义可重用的元件、动态面板以及丰富的script能够建立基本功能或页面逻辑的动态演示文件。

Axure借鉴了office的界面，能够让用户快速上手，并且提供了丰富的组件样式修改，使得通过其能够创建低保真、高保真甚至接近于实际效果的界面。

然而最让人称道的是，Axure的丰富的脚本模式，可以通过点击和选择能够快速完成界面元素的交互，如链接、state切换、动态变化等效果，使得Axure能够生成十分接近于真实产品的原型。

另一方面，Axure能够导入其他人创建的元件库，使得Axure能够满足绝大多数类型产品的设计。

但Axure仍然有一个让人头痛的问题：对于中文的支持不太友好。

在小部分元件上输入中午的时候，经常需要像碰运气似的反复切换输入法，破坏了咱们设计师的用户体验。

瑕不掩瑜，Axure仍然是交互设计师的首选原型工具。

2、Microsoft Office Visio Visio在2000年被微软收购，并在2002年成为office2003套件中的一个组件，最新版本是2007。

Visio能够获得推荐的原因是因为Visio的适用性非常之广，从网站界面、数据库模型，到平面布置图到工艺流程图，Visio都提供了相应的元件库和模板来进行快速创建。

相较Axure而言，Visio更适合于传统行业的生产或流程设计，或者软件及互联网行业中的信息、数据和流程的说明，而不太适用于web界面。

因为其的基于web的元件库还是比较少，并且形式和结构也更类似于word中的图形工具，因此在原型开发效率上都有所不足。

3、Balsamiq Mockups 这个基于Adobe AIR Runtime的工具实在是有让人眼前一亮的感觉，手绘风格的元件样式粗犷淋漓，能创建接近于纸上手绘的原型文件。

其提供了丰富的手绘风格的web常用元件，包括常用的html控件、以及一些组合控件，如多媒体控制器、标签页、列表、Iphone界面元件等。

Mockups最值得赞赏之处在于其提供的多数组件都可定制外观，对于中文的支持也不错（选择View > Use System Fonts）。

4、Mockflow Mockflow和以上工具最大的不同在于Mockflow是一项基于Adobe Flex技术开发在线服务，提供了与Balsamiq Mockups基本相似的功能，甚至更丰富的组件，虽然其元件定制化不够强大，但其提供的元件库默认样式却非常适合用来做商业产品原型的搭建。

有一个让我爱不释手的功能是模板，可以设置基于任何页面的模板来进行新的页面设计。

与其他模板工具相比，mockflow有一个非常特色的功能，基于web的存储可以在任意电脑上联机打开，同时可以其他人进行快速的分享，并收集在线反馈意见，非常适合虚拟团队的原型设计交流。

虽然在线服务的基本帐号只能创建一个文件，但单个文件却没有限制页数，因此也基本上足够使用。

5、Pencil sketch Pencil 是一款基于Firefox的扩展组件，安装之后即可在Firefox的工具菜单中打开Pencil的绘图面板。

功能比较简单，仅能用以日常简单工作的辅助 说明。

提供的默认元件都是基于软件工程，因此更适合用于windows桌面程序的简易界面搭建，或者是基本的页面功能说明，并不适用于严肃的原型开发，但 好在体积小、又轻便，能够方便将网页中的元素直接拖到或者复制到当前的画布中，这也是Pencil安装在Firefox所带来的便利之一吧。

更多工具... 在以上列举的原型开发工具都是较为常用的，也是在国内的交互设计师们比较常讨论的，但其实和Axure功能相似的软件还有很多，下面也就一些简单说明： 6、GUI Design Studio 这 是一款真的非常强大的原型制作工具，没有在上面推荐的原因是因为我还没有实际体验过，但冲着这工程级的界面设计就没有去尝试的冲动，但是从官方网站的截图 和视频演示来看，这款软件的操作模式和前面的原型工具大有不同。

Axure之类多是基于页面的原型设计，对于web网站尽管很实用，但是对于软件界面的流 程设计却略显繁琐。

而GUI Design Studio却另辟蹊径，直接以建立元素与元素之间的关联的方式来自动化的创建动作流程，而从视频演示来看，这样的确很大程度上提升了软件界面原型搭建的 效率。

7、Prototype Composer Serena 公司免费提供的原型开发工具，功能确实强大，提供了基于项目管理主要流程的产出物文档模板、原型工具以及开发流程控制，这个软件的开发理念非常好，用这一 款工具来满足项目开发流程中各个环节的沟通和决策。

但软件的学习和使用成本比较高，要了解其中的全部功能，貌似需要花不少时间。

另外软件的效率和稳定性还 有待提高，试用的过程中多次出错及停止响应。

8、Lucid Spec 由 Elegance科技推出的Lucid Spec是一款很类似Pencil的原型工具，仅仅是提供了更多控件。

不过Lucid Spec强调了生成干净的说明文档的功能，这可能是针对于多数原型工具的自动化生成规范的冗余而言的，不过老实说Lucid Spec提供的原型界面太过简陋，并且生成的说明文档也未见优化有怎样的提升。

视频介绍 9、Irise Professional Edition Irise与其他原型工具相比其中一个特色在于提供了样本数据的功能，这是类似于excel表的一个样本数据库，可以通过界面元素直接获取样本数据库中的数据，这样所生成的原型甚至可以使动态数据更新的。

10、Adobe Reader Adobe reader？没错。

其实理论上任何可以创建图形和文本的工具都可以用来原型开发，因为原型本身就是对于业务逻辑和功能界面的模拟或仿真，因此有何理由不能使用PDF格式呢？BoxandArrow的这篇文章《PDF Prototype》提醒了我们，所有的原型工具都只是工具，而不是设计本身。

个人推荐: 原型 ? Axure 7.0 ? UIDesigner 思维 ? Mindmanager ? Xmind 流程 ? Visio 2013 ? EDraw Max 知识 ? 有道云笔记 ? 印象笔记 时间 ? Todolist ? Worktile 图形 ? Photoshop ? Colorpix 交互 ? 快现 ? UIDesiger 我这里有小楼的AXURE7.0 从入门到精通78集视频教程，要的密我。

先送一集~ 另外还有大量产品经理相关的书籍~~~

在腾讯开发 QQ IM 的工作体验是怎样的

作者：高昌健 链接：https:///question/20672463/answer/15809516 来源：知乎 著作权归作者所有。

商业转载请联系作者获得授权，非商业转载请注明出处。

我之前在 PC QQ（以下简称 QQ）部门做过一段时间客户端开发，就讲讲我的一些经历。

开发每个人有两台联想台式机，预装 Win 7 和一堆内网监控软件，你懂的。

配置还可以，不过其实开发 QQ 有时候还是会有点吃力。

一台接入开发网，只能用来开发和上公司内网。

另一台接入办公网，可以上外网，但是腾讯内部有白名单，非腾讯自家客户端上网也必须设代理，所以有时候就比较尴尬，比如如果某个软件不支持代理就傻了。

我曾经想 push 代码到 GitHub，后以失败告终。

总部大厦几乎每个地方都有免费 Wi-Fi，所以如果你自带电脑的话上网还是可以比较爽的。

开发环境 Visual Studio 2005，我因为习惯了 Vim，所以都是在 Vim 里敲代码，然后拿 VS 来编译和跑程序。

强烈推荐再装上「小番茄」[1]，至于我们有没有交钱这个你也懂的。

版本控制是 ClearCase（大槽点之一。

。

。

以下简称 CC），CC 绝对是我见过的最逆天、最无敌的软件，安装文件硕大无比，用的时候卡得一逼。

QQ 内部对版本控制系统的使用要求比较严格，当你需要开发一个新需求的时候要先发一封邮件给 CC 管理员（居然有单独的管理员！），让他给你建一个子流（相当于建分支，建分支居然还要申请！）。

然后从 CC 服务器上把新建的子流拉到本地，注意，虽然这只是一个分支，但是你需要把整个 QQ 代码都再重新下载一遍！所以一般这种时候你可以去喝杯水看看风景啥的，时间取决于网速，一般 30 分钟至数小时不等。

然后你终于开始了「愉快」的开发生活，你会发现每当你要修改一个文件的时候，你需要先 checkout 它（注意跟 Git 的 checkout 没有半毛钱关系），checkout 完之后就只有你能改这个文件，如果刚好有人和你在同一个子流开发，必须等到你 checkin 之后才能 checkout 这个文件。

当然如果你等不及别人 checkin，你可以先 hijack 这个文件，改完之后再跟别人的修改合并。

写好代码想编译下看看效果，首次编译 QQ 的话耗时巨长无比（而且每次拉了新的子流后都要经历一次），所以你又可以去喝杯水看看风景啥的，时间取决于机器性能，一般 1 小时至数小时不等。

并且编译过程中开发机基本处于卡死状态，根本没法用，于是我通常都是吃饭前或者下班回家前干这种事情。

开发完成之后没有 code review，况且要通过 CC 来看更改也极为麻烦。

这时需要制作一个安装包给测试人员，打安装包这种事情一般交给编译机，时间 20 分钟左右，最快记录貌似是 8 分钟，当时负责优化性能的同学还拿了奖啥的。

测试过程中使用内部系统 TAPD 进行 bug tracking，每个 bug 分高、中、低三个等级，QQ 这边的 QA 对于质量要求很严格，需要同时通过功能测试和性能测试，通常要求是 0 个高单和中单（俗称 0 bug 合入），少量低单是允许的。

在经过严格的测试之后就可以合入主流了，使用 CC 的 deliver 功能来完成。

但最好是先 rebase 主流（相当于 merge 主流，同样跟 Git 没有半毛钱关系），确保没有问题之后再 deliver。

至此你的开发任务已经完成，接下来就是等待版本发布。

QQ 内部有一套成熟的客户端框架，代号 Hummer（蜂鸟），提供了诸如代码解藕、公共库、插件机制、国际化等功能。

自研的皮肤引擎，代号 GF（GUI Foundation），用来实现各种界面效果。

这两块是作为 QQ 开发者必须要掌握的，同时围绕这两块还开发了一堆小工具，最常用的就是 LogViewer，用来查看日志文件，还有性能工具用来分析代码性能。

底层代码和应用层代码是分离的，因此有时在 debug 时会遇到部分代码无法查看的情况。

企业微信tapd什么意思

TAPD是腾讯高效协作平台，凝聚腾讯多年团队协作理念和敏捷研发精髓。

提供看板、文档、迭代计划&跟踪、产品需求规划、缺陷跟踪管理等丰富功能，帮助团队可视化工作进展、沉淀分享项目知识、提升团队协作效率

tapd前端用什么写的

TAPD，是腾讯敏捷产品研发平台，强调敏捷迭代、小步快跑，使用范围包含腾讯和腾讯的合作伙伴。

目前TAPD已开放SASS服务，助力业界提升团队研发效率。

/ 敏捷研发 最早接触软件研发方法论是在大学软件工程的课程上。

老师给我们讲的是瀑布模型，毕业设计也是按照瀑布模型的方式完成的。

可行性研究，需求分析，基本设计，详细设计，编码，测试，维护。

这种开发模式对传统大型软件研发是很适用的。

完善的开发流程，精细的设计，详尽的文档，角色各司其职，对软件质量和维护有很强的适应性。

毕业后，从事互联网工作，开始了敏捷研发的’熏陶‘。

起初对这种方式有些排斥，经常开会（晨会，需求评审，测试用例）。

需求经常变更。

没有时间顾及代码质量。

进入新项目时，需要看旧代码才能理解设计意图，看别人的代码更是一种煎熬。

对开发人员来说，没有注释和文档的代码，真是一种煎熬。

在紧凑的迭代周期中，代码设计也没法顾虑过多，反复的变更导致代码可读性差。

公司存在的目的是盈利，蛋糕只有这么大，快速占领市场才是王炸。

敏捷研发对互联网公司来说，尤其是移动互联网软件开发而言是更适应的。

敏捷研发的核心在于快速迭代，拥抱变化。

目标是让客户满意(以用户价值为依归)，保证软件灵活度以适应极速变化的市场。

通俗一点说，更快的适应市场，更好的赚钱。

敏捷团队の定义

敏捷的团队是自我反省、持续调整的团队 一、敏捷项目管理： （1）Iteration 软件开发模型经历了从瀑布到螺旋再到敏捷的过程，迭代不是敏捷独有的创造，无论在RUP还是在MSF中迭代都是其核心特性之一。

而在Tencent特别强调的是并行迭代，即多个版本并行，最大程度发挥资源的效率。

Release（发布）可理解成当实现的产品Feature累积到一定用户价值时的正式发布，它是比Iteration更大的概念；Iteration（迭代）是在固定时间内开发Feature的过程，Release一般包括多次Iteration。

（2）TimeBox TimeBox（时间箱）反映了敏捷开发的节奏，即在固定时间内实现不固定特性的周期，抛开需求定义阶段，从设计-实现-测试到部署，在Tencent一般一至两周时间居多。

（3）Planning Game 对敏捷的一种常见误解是不要计划，其实在敏捷的体系中不仅强调计划，甚至区分Release计划、Iteration计划和Task计划等多种不同粒度、不同时长的计划。

Planning Game突出的是让用户代表参与，由用户代表评估UserStory/Feature的优先级，开发人员评估任务的开发时间，由用户代表+项目经理+核心成员三方共同排序、组合，确定本次迭代计划需要实现的Feature List。

在Tencent用户代表就是产品经理。

（4）IterationPlanningMeeting IterationPlanningMeeting就是Planning Game实现的管理形式，通过会议沟通达成。

（5）Stand-up Meeting 团队成员围成一圈，逐个说明3个问题：昨天做了什么，今天计划做什么，有没有困难并计划如何解决。

对Team而言这是检查进度、快速调整非常有效的形式，在Tencent这已经成为大家每天早上的固定习惯。

（6）ShowCase 提交测试前由开发人员演示实现的功能，产品经理到场Review是否符合当初的设想，避免接近发布时才反馈。

（7）Retrospect 每个迭代结束后，项目经理组织或轮流组织所有Team成员共同回顾本次迭代的得与失，整理Well/LessWell，因为敏捷的团队是自我反省、持续调整的团队。

二、敏捷软件开发： （1）Story Card/Story Wall/Feature List StoryCard是XP中推荐的需求定义方法，要求符合Invest和Moscow原则；StoryWall则用于跟踪StoryCard的变化状态，而FeatureList是Tencent一直沿用的需求表达形式，在Tencent的TAPD工具中已经实现了类似ThoughtWorks 的Mingle的StoryCard管理功能，对于需求跟踪而言这是不错的方法，一目了然。

（2）Refactoring 相信我们都听过这句话：好的代码不是设计出来的，而是重构出来的。

（3）TDD “测试驱动开发”在Tencent执行地并不太好，Tencent的产品以Web形式居多、业务逻辑相对简单，C++下的单元测试有些力不从心。

相反自动化测试在Tencent比较盛行，因为有测试部门专门的自动化测试Team在推动，而且链接的是正式生产环境，可以即时反映产品当前的状态。

（4）Pair Programming 理论上结对编程可以提高代码的质量，而且并不会降低开发效率，但Tencent的业务繁忙，资源上不允许两人结对。

（5）CI 持续集成可以降低发布前集成阶段的难度与成本，Tencent的自动化构建系统推行的比较早，覆盖了大多数产品，而且正在朝自动化构建-自动化测试-自动化发布三者协同的目标迈进。

（6）灰度发布 灰度发布是Tencent的又一创新，它将产品试用扩大到海量用户一端，在小范围及时吸取用户反馈，分析用户行为和喜好，持续修正自己产品的功能体验。

当然开发方法和流程确定了还远远不够，更难的是如何将它推动落地。

首先Tencent组织开发了承载敏捷思想的TAPD项目管理工具，它类似 ThoughtWorks的Mingle；然后推出了敏捷能力模型，类似CMM成熟度模型一样对Team评级加以引导；同时还推出了敏捷指数排行榜形成竞争，营造你追我赶的声势氛围。

文章写到这里行将结束，最后我们分析Tencent为什么选择Google和ThoughtWorks，其实是由互联网行业本身的特点决定的，互联网的生存法则就是大鱼吃小鱼、快鱼吃慢鱼，谁转身的快、谁拥抱变化、谁更关注用户，谁才可以笑到最后。

阿里巴巴董事局主席马云说过：今天很残酷，明天更残酷，后天很美好，但绝大多数人都死在明天晚上，却见不到后天的太阳。