今天我们要体验的产品不是一款 Mac 软件，也不是 app，而是一个企业级的一站式软件研发协作平台 。

经常来我站的朋友有很多从事软件开发、UI/UX 设计、产品设计等职业的，大家在各自的领域都会用到垂直领域内的协同工具，这里就不再赘述有哪些代表者，但这些工具也好，服务也好，就好像一座座孤岛，彼此之间的沟通协作并不能成为一个整体，对于出具规模的研发团队来说，如果提高团队的工作效率，协同沟通效率显然已成为当今互联网产品大生产场景下的刚性需求。

早年间我曾在一家专为企业级路由器系统研发公司担任测试工程师，当时还没有像 这样覆盖 " 产品→开发→测试 " 三大环节的研发管理系统，三个部门的人各自为营，沟通方式基本靠开会，研发组写完的代码灌入设备后给测试组，测试用例完全靠人肉文档，一遍又一遍，反馈给研发后，那边又不重视我们的报告，漏洞百出得不到有效记录，又被产品经理每天雪花般的新需求搞的想砍人；同时产品、研发、测试三方就需求设计、功能实现、产品可用性的探讨，甚至可以说是争执，已经严重占用了大部分的生产时间，最后还是得加班完成各自的任务。我一直在想，当时要是有 CODING 这样的平台就好了，严谨而科学的版本控制、代码质量管理、清晰的任务需求管理都可以帮助大家省去许多重复劳动和时间成本、健康成本。

使用 除了能克服上述问题，还能帮助一个研发团队从分支管理到代码评审，从任务分派到里程碑制定，再到文件系统和 Wiki 沉淀等诸多方面，诸多细节去帮助开发者更加高效地协作。

CODING 企业版（后面简称 CODING）是面向开发团队的 WEB 软件研发管理系统，整个团队成员可以在里面进行代码管理（重中之重）、需求管理、持续集成、测试管理、缺陷管理、任务分配等功能，适用于传统模式和敏捷模式的软件研发项目和产品运营，是一款真正意义上的 DevOps 全流程应用。

下面我们就来一一介绍 CODING 包含的各项核心功能，在正文展开前，大家先看一下 CODING 后台管理界面左侧的工具栏，一共 14 个项目，其中最核心的服务放在了中间，这么多的功能当然是面向不同工种的同事了，下面来看看这个 list：

各项目针对的使用人群及联系

项目 leader 负责在迭代、工作管理、任务管理等模块负责整个项目的进度、数据分析等工作；

产品经理负责在 Wiki、需求管理、文件系统中提供明确的产品需求；

研发工程师负责在代码仓库生产、维护代码，进行持续集成、环境部署等工作；

测试工程师负责在缺陷管理、测试管理中修 bug；

设计师负责在文件里上传设计文件。

当然，这里面有些项目不是专属于哪类人群，有些是大家共同进行协作沟通的地方，比如任务看板、Wiki、文件系统、工作管理等等。

产品经理在 CODING 里能做什么：

我们知道，作为产品经理，他的日常任务就是搜集用户需求、编写产品功能书，设计产品原型，并在用户反馈、UI/UX 设计、功能研发三个阵地来回穿梭，协调，最后给用户呈现一个令其满意的产品。CODING 里涉及到产品经理用的较多的应该是 Wiki、需求管理、任务看板。

CODING 支持将其他平台的项目直接导入其中使用 Wiki

不得不说 CODING 的 WEB 界面做的简洁而不失高效，Wiki 好似 Typora 的 Markdown 编辑界面，事实上这里也是支持 MD 语言编写文档的，产品经理可以在这里为工程师、设计师提供尽可能完善的产品交互原型、产品解析文档等等。

需求管理客观讲不光适用于产品经理，工程师的技术需求、其他部门人员的运营需求都可以提出来，然后由 leader 将此需求分配给对应负责人，这里就涉及到创建工作或关联工作了。

看下图，举例，产品经理根据用户使用情况记录并新建了一个需求，这个需求默认状态是 " 未激活 "，而 leader 看到需求后邀请研发、设计的同事进来关注，经过讨论沟通，认为可以执行添加此需求，则 leader 可以将需求状态改为 " 已计划 "，设计侧的同事接手开始干后标记为 " 设计中 "、然后交付给研发同事，状态标记为 " 研发中 "，以此类推，直到需求被实现标记为 " 已关闭 "，在这个过程中，团队成员可以随时看到需求实现状态，看到活动日志以及关联的各种附件、里程碑、任务、合并请求。

研发工程师的好伙伴：Git 代码管理

CODING 的核心服务对象是研发工程师，关于对代码库的维护能力当然是 CODING 最关注的地方，Git 也是这套系统里的重中之重，代码的浏览、分支管理、发布管理、版本对比、合并请求当然都不在话下。

在介绍代码管理的几个子功能前还是跟大家科普一下 Git 这套分布式代码管理系统的基本原理。

传统的代码管理都是点对点的同步部署，也就是你和你的同事在各自的本地机器编译完传输（或者也叫同步吧）到远程服务器或者直接发给架构师 /leader，然后由架构师 /leader 将你们的代码揉在一起，但这个过程很容易出问题，而 Git 则是由主开发者将代码上传到服务器后，其他开发者可以从服务器 get 到完整的代码然后根据任务开发功能后创建为一个分支版本，并从自己本地机器测试后将生成的代码推送回服务器。在这个过程中，主开发者可以发起代码评审、处理代码合并请求、有效控制产品版本，各个分支版本之间的代码冲突也可以获得有效避免。

代码浏览是最基础的功能模块，包括默认分支 master 在内的所有分支版本，主开发者（leader）都可以在这里看到，当然也可以操作代码的浏览、新建、上传、下载；代码支持在线编辑、路径复制、按行查看等功能。

我们可以通过左上角的隐藏菜单切换到各个分支版本进行代码预览。

接下来是分支管理，一个代码仓库建立后会自动生成一个默认分支 master，但一般情况都不会在这上面进行代码修改，就像前文我们提到的，团队成员会按照 leader 分解的任务去实现对应的功能模块，而这个模块都会有自己的分支版本，这样各个功能在合并前都会自行演进，互不干扰。

在你的代码完成后可以进行推送到服务器上，发起合并请求

Leader 可以在接到你的合并请求时，可以在对应界面添加代码评审者，标签、关注者，这些人会是架构师、测试工程师、产品经理。

同时你可以在合并请求里看到代码的改动具体情况，代码变动部分会用绿色背景标注。你可以关联里程碑、任务、合并请求等，或者最底部留言输入评论内容，比如 " 小李这功能做得好，这代码不错等等等… "

在创建合并请求时你会遇到 " 版本对比 "，在 " 版本对比 " 界面选择或输入两个不同的分支、标签、修订版本号进行对比，查看差异；版本对比可对代码进行审查与评论，系统会检测比较版本能否自动合并。

当完成一个里程碑的所有任务开发之后，你就可以在某个节点将此时的默认分支标记为一个版本，并发布这个版本。

除了上传代码，你需要详细的记录每个版本的 " 更新日期 "、" 改动说明 "、" 版本对比 "、" 版本规划 " 等内容，CODING 支持预发布版本标记。

持续集成的概念诞生自 1991 年，就像我开头提到的传统协作方式遇到的诸多弊端，持续集成的推出就是为了解决开发团队每天大量的重复性编译、测试工作，提高交付效率，在枯燥的电脑前，人类创造了像 Jenkins 这样的自动化集成系统，它可以帮助人类完成每次版本诞生前枯燥的编译、部署、自动化测试工作，让工程师们专注于开发。

CODING 项目可直接集成到腾讯云平台上，同时支持多种运行环境

在创建持续集成时你需要 " 代码更新触发 " 还是 " 手动触发 "，选择推送到某个指定分支时触发，以及用常规模式 or 云服务器模式进行集成的执行，云服务模式就是允许用户可以将执行环境部署到云端服务器，并且自行创建容器来执行集成的构建。

项目 leader 统筹规划靠这些功能

除了工程师、产品经理会频繁用到代码维护、Wiki、文件系统外，项目 leader 也可以使用 CODING 里的任务系统和工作管理两个模块。

在任务系统里核心当然是 " 里程碑 " 了，这个开发人员都很熟悉，CODING 支持在列表与甘特图之间随时切换查看里程碑，在里程碑详情页面你可以清晰的看到整个计划的完成度、是否超时，每项任务的完成情况，完成进度，持续天数。

如果一个里程碑已经 reach，那么 leader 就可以选择对应版本创建版本发布，总之一句话，在 CODING 中你会发现设计者会将各个模块尽可能的耦合在一起，尽最大努力方便使用者提高工作效率与协调效率。

看到工作管理这个模块，多少有些让人有些迷惑，不是有任务系统了吗？怎么还有一个工作管理，我想这个模块纯粹是为 leader 们设计的吧，工作管理中的事务是独立于项目本身的，leader 们可以在里面分配一些时效性强、需要临时突击解决的问题，在里面可以关联产品经理发布的 " 需求 "，或是关联项目资源（里程碑、任务、合并请求）。

总的来说，CODING 是一个面向开发者的云端开发平台，提供 Git/SVN 代码托管、任务管理、在线 WebIDE、Cloud Studio、开发协作、文件管理、Wiki 管理、提供个人服务及企业服务，其中实现了 DevOps 流程全自动化，为企业提供软件研发全流程管理工具，打通了从团队构建、产品策划、开发测试到部署上线的全过程。「CODING 持续集成」集成了 Jenkins 等主流企业开发流程工具。

CODING 面向 5 人（含 5 人）以下团队提供免费试用，团队可以享有所有功能，并且不限项目和仓库数量，开箱即用，无需部署，而且他家还实行灵活的按人天扣费，也就是每人每天 1 元钱，涵盖 DevOps 全部所需，比如你的团队有 10 个人，那么每天的费用也仅为 10 元，如果是按年计费则是 3650 元，非常简单对不对。另外 CODING 还为企业提供私有化方案，你可以将 CODING 部署在公司自己的服务器上，在保障公司隐私的同时享受更多的定制化服务。

本文发表自 Mac 玩儿法，转载请注明转自《》

你还可以通过微博：@Mac 玩儿法 ; 微信公众号： @Mac 玩儿法，或者到各大自媒体平台关注我们的同名账号（Mac 玩儿法或玩儿法），获取最新鲜的应用产品内容推荐。

Mac 玩儿法 - 应用提高设备生产力（ ）

刚接手的一个团队，非常没有凝聚力，做事很散漫，也许是因为激励机制存在问题，导致大家工作情绪不高，投入精力不足，如何改变现状呢？

1、首先要确保公司是否有激励政策，通过考核的方式来进行评级，而如何考核，本人认为，通过完成的工作来衡量，每天日报，每周周报来汇报完成工作的情况，加与完成工作的质量审核，就IT来说，核查功能是否已经实现，及偶尔抽查式代码评审；

2、积极与成员沟通，可以正式沟通与私下沟通配合，了解成员的情况及处事的原因；

1、首先就先搞清楚这个“也许”，不能猜测，通过分别谈话交流，形式不限，搞清楚核心问题；

2、如果真的是激励机制引起的，一方面搞搞团建激发一下团队氛围和大家的积极心态，一方面找领导沟通下机制落实或改善，大激励兑现不了，小激励也应该争取一些，调动大家的积极性，都搞不定就自己乖乖走人吧，因为你已经没有价值了；

3、如果是企业文化和工作氛围引起的工作惰性问题，就要人治治人了，多激发年轻成员的工作热情，画大饼给面包，年轻人对未来还是有梦想的，对老油条拉关系搞渗透讲兄弟情义，老老实实不搞事就好，不得已时杀两只鸡。

1. 先和老板沟通，是否能争取到预算。

2. 如果无法争取到足够的预算，先识别团队中责任感强的人给予高头衔，树立榜样，只向钱看的人怎么都留不住，不如放弃。

3. 如果能争取到一定预算， 加强核心人员的待遇，三个臭皮匠怎么也顶不过一个诸葛亮的， 让核心人员带动整个团队的工作情绪。

1.上面统一命令，根据每个人的能力制定日清日结；

2.完不成任务的，扣绩效；

3.自己带团队，一定要让队员看到希望，项目的最终目标和你带队的愿景要表达出来。有希望跟着才会有动力。

这要看所谓的散漫，导致的工作结果是怎么样的。

有一种散漫是积极的，只是你眼中的散漫而已。每个人的工作风格都不一样，或者这些员工喜欢这种办工模式，可以自由激发思绪，提高工作效率呢。

如果这个散漫是消极的，严重拖延项目进度，就必须要执行纪律，并通过激励、发挥PM魅力等手段整顿。

如果是积极的，就接受这种办公模式（比较著名的谷歌好像提倡，没体验过，只是听说）

1、利用各种场合（正式的、非正式的）了解各成员的需求，并看是否有人带头散漫，重点整顿带头大哥；

2、结合公司的激励机制，适当打鸡血；

3、多些团体活动，提高成员们之间的亲和力；

4、是否提供足够的培训环境（公司培训、自学奖励等），让成员胜任当前的工作，如果力不从心，也会导致散漫。

1 好的做法，招新人进来，让血液流动，让他们有压迫感；

2.坏的做法，找他们的领导，直接把他们的绩效以及现在项目的风险汇报给他们的职能经理和项目发起人吧，让他们的领导去处置并尽快替换人员加入项目，保证项目正常运行。

3. 先分析原因，团队懒散有很多原因，工作计划被安排，而没有计划主动性？还是工作太多没有头绪和重点？还是绩效机制缺乏激励作用？

4. 人性是两面的, 你管理哪一面, 哪一面就反弹, 从正面领导力角度看要给团队主动权, 相信团队、激发团队。

5. 我感觉你们团队是软件研发团队, 技术人员实际上是有压力和动力的, 尤其上海高消费城市。

6. 软件研发团队的激发, 我建议用看板+Scrum, 用物理看板加站会可视化任务、可视化资源分配、可视化进度、可视化风险和问题, 形成同行压力和协作互助氛围。

7. 然后用scrum让团队自组织, 团队自己挑选故事,拆分任务, 做计划承诺, 然后用每日站会团队自我检视自我管理, 演示会上让每个人演示会自己的开发成果给产品验收。

8. 你这有点像激活休克鱼的案例, 团队不是没有激情或能力, 只是在现有机制和环境下休克了,你可以查下海尔激活休克鱼的案例和方法。

9.团队状态激发可以用很多引导方法, 比如生命召唤、深度破冰、帆船模型等激发团队每个人内心的追求和梦想, 让每个人思考他追求的是什么。

10.用团队愿景, 产品愿景, 竞品分析, 商业画布等方法明确团队和产品愿景和使命, 再用立场分析分析团队的成就和过去, 再用帆船模型、气球升降等分析团队的挑战和困难, 再一起共创团队改进和行动计划。

11. 找到团队骨干和火种, 先激活他们, 找这些人做火种和托, 和这些HIP人员一起做他们的职业规划和行动计划。

12. 然后可以扩展到整个团队, 为每个人做职业规划和发展计划, 为每个人安排导师（HIP骨干需要有做导师kpi）。

13. (奇招来了) 懒散团队可以考虑引导+视觉化+游戏化激发, 引导工作坊可以激发自主性和自发共创, 让团队找到成就感, 还可以做一些团建游戏, 各种会议和回顾总结换各种游戏花样来玩。

14. 最后是绩效考核和晋升管理, 如强化目标结果导向的考核而不是过程数据, 年度绩效、晋升考核都看结果而不是看人情和过程数据, 也可以试点积分制、点赞制这种可视化绩效管理方法。

使用创新的方法 提高团队的执行力，案例有两个要点:

1.用物理看板+scrum可视化一切(初期还是物理看板好用)。

2.用引导+团队激发方法激发个人内在追求动力。

3.找火种, 拉同盟, 淘汰害群之马和落后者(HR付点赔偿费也值得)。

接手这样一种情况的团队对于负责人来说是件比较棘手也是非常有挑战性的问题。

1.负责人首先有良好的状态和积极的状态，并要保持下去，因为改变团队现状并不是三五天就能解决的事情；

2.通过面谈的方式，和项目成员多进行沟通，了解每个成员的基本状况和心态，积极设法争取部分人员的支持，要想改变光靠自己肯定不行；

3.完善部门管理制定，并明确内部奖惩机制，这是后期调动大家的积极性以及处理部门存在问题的基础（奖惩可能需要公司支持，我们一个项目经理找老板申请了不少费用，一下子让原有散漫的团队凝聚了好多，至少大家拿到钱了不干活也不好意思不是）；

4.分析那几个散漫人员的工作内容，这非常重要：如果担任主要工作，就需要做长期规划，不能强硬解决，前期在没有大的问题前提下尽量维持现状，保证工作的正常开展！思想工作同时进行，如果没有合作的余地，那就要规划人员分担他的工作了；

如果担任普通工作，直接明确要求，给定期限更改，无法改变，那只能淘汰。有点欺软怕硬了哈，其实不是，只是因人而异！

1、PM着手奖惩机制；

2、项目的任务分配尽可能细；

3、每天进行任务情况检查汇总。

4、改变激励机制，超过几次就直接离开。

5、打一巴掌，再给个枣，恩威并施。

6、如果前面两个还不管用就杀鸡儆猴，找个刺头开刀。

通过讨论正在进行的工作、提问、共享状态和阐明出现的问题来提高团队效率。

你的团队聊天室提供了一个用于建立各地团队成员之间的通信环境和捕获通信的区域。

通过使用团队聊天室而非电子邮件线程，可以自动接收对话和决策的审核记录。 通过查看存档，可以让你在出差或位于不同时区时快速赶上团队进度。

1. 从团队的主页，打开房间。 如果未找到聊天室磁贴，请。

   如果无法进入该聊天室，请添加为成员。

2. 若要切换到另一个团队聊天室，请从**“聊天室”**列表中将其打开。

   你将看到你有权进入的所有聊天室。

• 将消息发送给团队成员：键入 @用户名。

• 打开链接对象，如工作项、变更集、生成定义等。

• 查看前一天的消息：从日历中选择日期。

你可以邀请其他 TFS 参与者加入你的团队聊天室。

1. 如果你不是团队管理员，则。

2. 打开**“管理成员”**。

   只有团队管理员才可以查看管理用户和管理事件的链接。

添加事件可让你的团队了解生成完成、源代码签入、工作项更新和出现代码评审请求的时间。

1. 打开**“配置事件”**。

   如果看不到**“管理事件”**链接，则。

2. 聊天室事件与对象的超链接一起显示。虽然团队聊天室用户可以查看事件，但可能无权打开对象。若要了解更多信息，请参见 。

添加其他聊天室可为临时讨论、跨团队交互、虚拟团队或社交讨论提供区域。

1. 添加聊天室。 如果**“新建”**链接未激活，则。

2. 将成员添加到聊天室，如添加成员中所述。

问：其他团队如何使用聊天室？

**答：**下面是团队使用聊天室的一些方法：

• 每日站立会议：回顾前一天发生的事情并基于实际历史记录讨论任何问题或难点。

• 远程团队成员：分散在不同地区的团队成员可以与不同时区的成员保持进度一致。 当团队成员具有不同的语言熟练程度时，这将非常有用。

• 内存流：配置所有事件后将生成一个存档，以便你统一查看变更集、工作项更新和生成进度。

**答：**选择 音频图标以打开或关闭声音。

问：如何退出团队聊天室？

**答：**若要完全退出团队聊天室，请关闭已在其中登录团队聊天室的所有浏览器实例。

问：什么因素会导致工作项事件显示在聊天室中？

**答：**状态或分配的任何更改都会导致在聊天室中显示一个事件。

问：我如何添加我的头像？

**答：**更改个人资料的图片。

问：我如何添加其他团队？

**答：**当你时，将自动创建团队聊天室。

问：我如何向我的团队添加成员？

答：可自动访问团队聊天室。