原文：Weekdone 博客，作者 Külli Koort，译文首发创之

一个积极向上的团队，工作效率也绝对不会差。因此，如果团队成员不能和谐共事，你就应该提高警惕。这是一个早期信号，不久后团队表现以及工作效率也会受到影响。而且如果真的这样。。大家都知道，责任在谁头上。

为避免类似情况，你就应该未雨绸缪，而非亡羊补牢。虽然确保公司正常运转、内部沟通顺畅很重要，但及时发现并掌握那些可能导致团队表现不佳的因素也至关重要。

多次研究后，我们将结果汇总到一张信息图中，其中列出了团队负责人容易犯的十种错误。而针对这些错误，我们也总结了一些简单的解决方式。

总结信息图中提及的内容，影响团队表现和工作效率的十大问题分别是什么？

1. 没有给团队成员应得激励

当然，激励并不总指那些看得见摸得着的“身外之物”。研究表明，有 26% 员工会因为仅仅 5% 的加薪就跳槽。合理的薪资制度不仅促使员工专心工作，对你也有好处——至少你不用经常担心人员流失，而且它还提升了团队幸福感。一般来说，拿高薪的员工总是要开心一点的。这点我们在文章开头已经提过了。

或许你现在就应该确认，公司的奖励机制能否给员工相应的回报。建立一个开放、有效的奖励机制可以帮你大幅降低员工跳槽的几率。

2. 没有提供利于工作的环境

开放式办公环境的出现可以追溯到 19 世纪 50 年代，最初是德国人想出了这样一种方法，便于员工间互相交流。此后，开放式办公环境开始在各大公司中流行起来。但一个好主意往往也会伴随着缺点，近年来，一些研究表明，在开放式环境中工作可能会影响员工注意力、创造力、工作效率以及满意度。此外，在开放环境工作的员工请病假的概率也会增加 62%。是该好好想想办公室要怎么装修了。

3. 没有为员工提供学习机会

即使你不能像 Google 一样，让员工拿出 20% 时间来研究自己感兴趣的项目；你也可以提供一些其他机会。团队激励的重要方式之一就是让员工无论作为团队一员还是从个人角度都得以学习成长。在如今快节奏的环境下，你的公司同样面临不进则退的危险。不能把员工培训仅仅看作公司支出，它对公司的存活与发展至为重要。

4. 不给团队成员发言权

不采纳员工意见对他们今后的表现并没有实质性帮助。就像员工等待你的反馈一样，你也应该经常询问他们的意见。让员工觉得自己受重视的一个方法就是采用项目进度报告的方式，并针对其内容进行有效沟通。

5. 不关注员工情绪

不得不说，负面情绪传播比正面情绪快得多。24% 经常不配合工作的员工还会将负面情绪传播给同事，所以他们影响到认真工作的人不过是早晚的事。尤其是大家都在开放式环境中办公时，这种效应尤为显著。

问题在于，你不能插手那些无法控制的事。所以我们才将情绪管理这一项也列入了 Weekdone 调查报告中，因为了解每个团队以及整个公司的感受至关重要。它就像团队的脉搏或者血压一样重要。写周报时，你会在最后看到一个问题：「本周你工作快乐吗？」我们用五颗星来代表快乐的不同程度，你可以像打分一样，根据自己情况选择。

6. 没有建立起开放的公司文化

恐惧并不能转化为动力。实际上，最影响团队表现的因素便是畏惧失败。越是担心，人们就越倾向于停留在自己的舒适区域，而这将从多方面影响其成功几率。你的任务就是建立一种开放的公司文化，不仅对工作中的错误持宽容态度，还需要鼓励员工开诚布公地交流。要达到这一目的，你可以采用一种很棒的管理方式——PPP（progress, plans, problems；即进展、计划、困难）。它会提醒你经常关注以上三个问题。

7. 不能制定清晰目标

如果你的团队有明确的工作目标，他们也愿意更努力工作。但如果目标经常变化，人们难以找到工作重点，相应地工作动力也会降低。可以试着用 OKR（Objectives and Key Results）来管理团队，许多公司都用它制定工作目标并收割成果。OKR 的主要目的是让个人、团队的工作目标与整个公司相关联，便于管理工作成果，并促使员工向着相同的目标努力。

8. 不给员工自由

没有人会喜欢在一个控制狂老板手下做事。38% 员工宁愿去做一些不喜欢的事，例如找更多活干或者坐在大声吃东西的同事旁边，也不愿意离自己的老板太近。其实管理与控制间的界限非常模糊，但事实就是：如果员工感觉自己无时无刻不处在老板的监视之下，那他们的表现只能停在很低的水平。解决方法就是借助工具或其他方式了解员工的进步与工作计划，而非自己亲力亲为。

9. 会议安排不合理

首先必须承认，团队会议非常重要，但每周在没效率的会上浪费 3.8 小时听起来就不是那么回事了。如果不能合理安排会议，那你就等着失败吧。下次开会前，先提醒自己高效的会议长什么样。

10. 浪费员工时间

如果员工时间都花在刀刃上，他们也愿意更努力工作。每天忙碌的不只是你，也有你勤奋的团队。因此，要确保所有邮件、会议都目标清晰。约会（预约会议）前，记得再发一封邮件，告知大家新的内容，并保证收件人都是相关人员。

如果你参照了以上方法，那就坐等你的团队工作效率和动力都直线上升吧。

网易将于 13 日正式发布基于 PAAS 的 IM 云服务“云信”。开发者可以通过客户端 SDK 和云端 REST API 让自己的应用快速轻松接入聊天功能。据介绍，网易新闻客户端的跟帖与私信功能采用的就是和“云信”一致的技术平台。

网易表示，云信的背后是网易 POPO 和网易即时通等产品积累的长达 15 年的即时通讯开发经验。产品优势在于可以为开发者提供更成熟的样本经验、更丰富性的模式选择、更稳定的CDN服务（多节点）。

官方资料称，网易拥有“业内最大”的服务集群架构，已成功发送1000亿条消息。经第三方权威测试，每日上亿条消息100%到达。基于POPO的私有精简二进制协议，可以提供更快的速度和更好的性能。

对接入后的开发者，云信将提供7*24小时实时运维监控，技术工程师全天候响应，定期开展免费培训课程和技术沙龙。

网易自己的网易新闻、网易云音乐、网易云课堂、网易花田等APP、以及顺丰快递、传化物流、家校无忧、企业书屋、上海清算所等单位都已经应用了云信的服务。

网易云信

单纯接入第三方支付很容易，只要团队中有开发经验稍微丰富的人，一般最多一周就能完成一家支付公司整体的接入，但如果要考虑与核心业务流程整合、可运营性、架构扩展、安全等问题时候，涉及的东西就很多。

作为一个产品经理，在设计支付产品时候，依赖于你公司及团队发展阶段，对应支付产品的设计策略及方案也不同。

第一阶段：业务发展初期/接入支付平台初期

此阶段的目标是跑通核心的业务流程，验证整体的业务模式，支付业务量较少。

因此对于支付本身的要求不高，在渠道上只需要接入一到两家支付渠道，业务上能够跑通完整支付流程就行。在核心业务系统上，对支付系统业务过多要求。

此时候的接入策略很简单：一般第三方支付都提供了接入的文档及对应语言的Demo程序，直接按照其文档及例子接入联调即可。

除了标准的支付、查询、充值、退款、转账、对账、结算等交易流程外，还需要重点注意如下几点：

1、差错的处理机制，包括掉单后的补单/查询机制、重复支付处理机制、结算对账时候的长短款处理机制等。
2、为清结算人员、运营人员提供完善的工具，降低开发人员介入日常运营的维护成本。
3、一定要有信息安全意识，包括支付相关数据安全、通讯安全、系统安全、网络安全等等。

当然在创业初期，如果团队缺少交易系统构建经验，也可以适当考虑诸如ping++、beecloud这样的厂商，优劣可以参考： 使用第三方支付集成有何风险，例如 Beecloud 或者 Ping++ ? - 梁川的回答

第二阶段：多种支付渠道整合

此阶段，核心业务已经形成一定规模，支付已经成为核心业务流程的一环，支付的成功率、用户体验、费率、安全性等都成为业务核心竞争力。

同时基于成本、风险、运营等角度考虑，一般会同时接入多家支付平台，一方面能够为用户提供多种选择，另外一方面可以在多个渠道间做路由切换（基于成本、流量、营销活动等等）。

此时候的接入策略不再是接入本身，而是：怎样让支付与核心业务系统整合？怎样做多渠道的整合，提高结算、运营的效率，降低运营的成本？

此时候需要从系统架构上做整体规划（实际上应当在第一阶段就做），包括系统的：
1、客户、用户、账户模型
2、支付网关
3、交易系统
4、账务系统
5、清结算系统（多个支付渠道）
6、多支付渠道渠道路由系统
7、风控系统/反欺诈系统（例如网游反欺诈）
8、支付相关的运营系统功能
等等

以上功能貌似包含了一个完整支付平台的相关功能，但作为商家的平台，其侧重点与支付平台并不相同。例如客户、用户、账户系统，对商家平台（例如电商平台）而言一般就是会员系统。

第三阶段：自建支付平台

此阶段，平台除了第三方支付外，还会自己接入一些银行渠道等金融机构资源，另外在业务创新上也会结合支付做一些创新（例如面向平台商户的供应链融资、面向平台用户的授信）。此时候，支付本身已经逐步演变为类第三方支付的支付平台。
此时候面临的问题基本上就是一个支付平台构建的所有问题。

回到题主的问题，由于一直是做客户端开发的，缺少支付及交易系统相关的经验。既然你们公司自己在搭建支付平台，强烈建议让公司做支付架构师、产品经理来参与你们的系统设计，避免走弯路。虽然接入第三方支付貌似很简单，相信你们几天就能完整接入微信支付/支付宝，但如果要考虑到未来系统的扩展性、安全、算清楚账等问题，还是让专业的人来干这事情。

关于平台资金流转的问题，以前的一个类似回答，供参考。美团、饿了么这些平台先收消费者的钱，然后再转账给商户，在财务上是怎么处理的？ - 梁川的回答

• 整体架构
• 数据采集
• 数据存储与分析
• 数据共享
• 数据应用
• 实时计算
• 任务调度与监控
• 元数据管理
• 总结

一直想整理一下这块内容，既然是漫谈，就想起什么说什么吧。我一直是在互联网行业，就以互联网行业来说。
先大概列一下互联网行业数据仓库、数据平台的用途：

1. 整合公司所有业务数据，建立统一的数据中心；
2. 提供各种报表，有给高层的，有给各个业务的；
3. 为网站运营提供运营上的数据支持，就是通过数据，让运营及时了解网站和产品的运营效果；
4. 为各个业务提供线上或线下的数据支持，成为公司统一的数据交换与提供平台；
5. 分析用户行为数据，通过数据挖掘来降低投入成本，提高投入效果；比如广告定向精准投放、用户个性化推荐等；
6. 开发数据产品，直接或间接为公司盈利；
7. 建设开放数据平台，开放公司数据；

上面列出的内容看上去和传统行业数据仓库用途差不多，并且都要求数据仓库/数据平台有很好的稳定性、可靠性；但在互联网行业，除了数据量大之外，越来越多的业务要求时效性，甚至很多是要求实时的 ，另外，互联网行业的业务变化非常快，不可能像传统行业一样，可以使用自顶向下的方法建立数据仓库，一劳永逸，它要求新的业务很快能融入数据仓库中来，老的下线的业务，能很方便的从现有的数据仓库中下线；

其实，互联网行业的数据仓库就是所谓的敏捷数据仓库，不但要求能快速的响应数据，也要求能快速的响应业务；

建设敏捷数据仓库，除了对架构技术上的要求之外，还有一个很重要的方面，就是数据建模，如果一上来就想着建立一套能兼容所有数据和业务的数据模型，那就又回到传统数据仓库的建设上了，很难满足对业务变化的快速响应。应对这种情况，一般是先将核心的持久化的业务进行深度建模（比如：基于网站日志建立的网站统计分析模型和用户浏览轨迹模型；基于公司核心用户数据建立的用户模型），其它的业务一般都采用维度+宽表的方式来建立数据模型。这块是后话。

整体架构

下面的图是我们目前使用的数据平台架构图，其实大多公司应该都差不多：

逻辑上，一般都有数据采集层、数据存储与分析层、数据共享层、数据应用层。可能叫法有所不同，本质上的角色都大同小异。
我们从下往上看：

数据采集

数据采集层的任务就是把数据从各种数据源中采集和存储到数据存储上，期间有可能会做一些简单的清洗。
数据源的种类比较多：

• 网站日志：

作为互联网行业，网站日志占的份额最大，网站日志存储在多台网站日志服务器上，
一般是在每台网站日志服务器上部署flume agent，实时的收集网站日志并存储到HDFS上；

• 业务数据库：

业务数据库的种类也是多种多样，有Mysql、Oracle、SqlServer等，这时候，我们迫切的需要一种能从各种数据库中将数据同步到HDFS上的工具，Sqoop是一种，但是Sqoop太过繁重，而且不管数据量大小，都需要启动MapReduce来执行，而且需要Hadoop集群的每台机器都能访问业务数据库；

应对此场景，淘宝开源的DataX，是一个很好的解决方案（可参考文章 《异构数据源海量数据交换工具-Taobao DataX 下载和使用》），有资源的话，可以基于DataX之上做二次开发，就能非常好的解决，我们目前使用的DataHub也是。当然，Flume通过配置与开发，也可以实时的从数据库中同步数据到HDFS。

• 来自于Ftp/Http的数据源：

有可能一些合作伙伴提供的数据，需要通过Ftp/Http等定时获取，DataX也可以满足该需求；

• 其他数据源：

比如一些手工录入的数据，只需要提供一个接口或小程序，即可完成；

数据存储与分析

毋庸置疑，HDFS是大数据环境下数据仓库/数据平台最完美的数据存储解决方案。

离线数据分析与计算，也就是对实时性要求不高的部分，在我看来，Hive还是首当其冲的选择，丰富的数据类型、内置函数；压缩比非常高的ORC文件存储格式；非常方便的SQL支持，使得Hive在基于结构化数据上的统计分析远远比MapReduce要高效的多，一句SQL可以完成的需求，开发MR可能需要上百行代码；

当然，使用Hadoop框架自然而然也提供了MapReduce接口，如果真的很乐意开发Java，或者对SQL不熟，那么也可以使用MapReduce来做分析与计算；

Spark是这两年非常火的，经过实践，它的性能的确比MapReduce要好很多，而且和Hive、Yarn结合的越来越好，因此，必须支持使用Spark和SparkSQL来做分析和计算。因为已经有Hadoop Yarn，使用Spark其实是非常容易的，不用单独部署Spark集群，关于Spark On Yarn的相关文章，可参考：《Spark On Yarn系列文章》
实时计算部分，后面单独说。

数据共享

这里的数据共享，其实指的是前面数据分析与计算后的结果存放的地方，其实就是关系型数据库和NOSQL数据库；

前面使用Hive、MR、Spark、SparkSQL分析和计算的结果，还是在HDFS上，但大多业务和应用不可能直接从HDFS上获取数据，那么就需要一个数据共享的地方，使得各业务和产品能方便的获取数据；

和数据采集层到HDFS刚好相反，这里需要一个从HDFS将数据同步至其他目标数据源的工具，同样，DataX也可以满足。

另外，一些实时计算的结果数据可能由实时计算模块直接写入数据共享。

数据应用

• 业务产品

业务产品所使用的数据，已经存在于数据共享层，他们直接从数据共享层访问即可；

• 报表

同业务产品，报表所使用的数据，一般也是已经统计汇总好的，存放于数据共享层；

• 即席查询

即席查询的用户有很多，有可能是数据开发人员、网站和产品运营人员、数据分析人员、甚至是部门老大，他们都有即席查询数据的需求；

这种即席查询通常是现有的报表和数据共享层的数据并不能满足他们的需求，需要从数据存储层直接查询。

即席查询一般是通过SQL完成，最大的难度在于响应速度上，使用Hive有点慢，目前我的解决方案是SparkSQL，它的响应速度较Hive快很多，而且能很好的与Hive兼容。

当然，你也可以使用Impala，如果不在乎平台中再多一个框架的话。

• OLAP

目前，很多的OLAP工具不能很好的支持从HDFS上直接获取数据，都是通过将需要的数据同步到关系型数据库中做OLAP，但如果数据量巨大的话，关系型数据库显然不行；

这时候，需要做相应的开发，从HDFS或者HBase中获取数据，完成OLAP的功能；

比如：根据用户在界面上选择的不定的维度和指标，通过开发接口，从HBase中获取数据来展示。

• 其它数据接口

这种接口有通用的，有定制的。比如：一个从Redis中获取用户属性的接口是通用的，所有的业务都可以调用这个接口来获取用户属性。

实时计算

现在业务对数据仓库实时性的需求越来越多，比如：实时的了解网站的整体流量；实时的获取一个广告的曝光和点击；

在海量数据下，依靠传统数据库和传统实现方法基本完成不了，需要的是一种分布式的、高吞吐量的、延时低的、高可靠的实时计算框架；

Storm在这块是比较成熟了，但我选择Spark Streaming，原因很简单，不想多引入一个框架到平台中，另外，Spark Streaming比Storm延时性高那么一点点，那对于我们的需要可以忽略。

我们目前使用Spark Streaming实现了实时的网站流量统计、实时的广告效果统计两块功能。

做法也很简单，由Flume在前端日志服务器上收集网站日志和广告日志，实时的发送给Spark Streaming，由Spark Streaming完成统计，将数据存储至Redis，业务通过访问Redis实时获取。

任务调度与监控

在数据仓库/数据平台中，有各种各样非常多的程序和任务，比如：数据采集任务、数据同步任务、数据分析任务等；

这些任务除了定时调度，还存在非常复杂的任务依赖关系，比如：数据分析任务必须等相应的数据采集任务完成后才能开始；数据同步任务需要等数据分析任务完成后才能开始；

这就需要一个非常完善的任务调度与监控系统，它作为数据仓库/数据平台的中枢，负责调度和监控所有任务的分配与运行。

前面有写过文章，《大数据平台中的任务调度与监控》,这里不再累赘。

元数据管理

这块想要做好，非常复杂，我觉得是且价值小于成本，因此我们暂不考虑这块。目前只有每天任务运行的元数据。

总结

在我看来，架构，并不是技术越多越新越好，而是在可以满足需求的情况下，越简单越稳定越好。目前在我们的数据平台中，开发更多的是关注业务，而不是技术，他们把业务和需求搞清楚了，基本上只需要做简单的SQL开发，然后配置到调度系统就可以了，如果任务异常，会收到告警。这样，可以使更多的资源专注于业务之上。

相关阅读：
大数据平台任务调度与监控系统
Spark On Yarn系列文章
异构数据源海量数据交换工具-Taobao DataX 下载和使用

好了，就这些吧，后面想到了再漫谈吧。码字很累的，希望多多支持我的博客。
转载请注明：lxw的大数据田地 » 大数据环境下互联网行业数据仓库/数据平台的架构之漫谈

【李楠的回答(119票)】:

我可能比较“老派”。。

1 github

一个付费的 github 我认为是最必要的。它可以一下子解决代码托管， issues ， wiki 三个小团队最需要的东西。

2 testflight

团队管理中最容易忽视的，却最重要的东西是。。。

“发布”

无论一切多么井井有条，不能频繁发布的团队也是危险的。

所以，可控制灰度的空中测试工具也很重要。移动项目导入 testflight 是必要的。

3 invision

另外， github 不适合设计的交流，和 basecamp 比较，个人更喜欢 invision 。

4 微信群

相信我，你们需要一个微信群 － 他非常有利于实时的消息共享。

5 最后的话

github + invision + testflight ＋ 微信群基本可以解决：

需求文档（ github wiki ） －> 课题跟踪( github issues ) -> 设计讨论( invision ) -> 代码托管( github ) -> 灰度发布( testflight ) 的整个的流程。

6 工具之外的话

但是，工具之外，更重要的是你的团队组织和管理方法。

团队都有什么角色？如何分工？需要那些规定和流程（会议安排，迭代周期等等）？

个人的推荐是 SCRUM 。

其实，只要组织和管理方法定了，工具反而不重要了，Low-tech 也可以很高效：

7 广告

有没有把“方法”和“工具”更好的结合在一起的团队协作工具？目前真的没有看到很好的。

不过，也许过一段我们会拿出一个。。。敬请期待。

【马力的回答(36票)】:

小团队协作，首先要明确的是协作的目的是为了提高效率，辅助沟通，帮助记录，而不是为了流程而流程，为了看起来理想的套路，盲目的希望通过工具来标准化大家的行为，这样往往会适得其反，最终难以推行下去。

这里的关键点在于，根据团队和工作的特点，把握好人机分工的度，哪些是需要通过流程解决，用计算机来辅助解决，哪些是留给人的空间，给人足够的自由度，避免工具反过来成为制约。常犯的错误是对后者的忽视。

我们在选择工具时，伙伴做了很多探索（感谢我们的 Geek伙伴），几乎主流的工具都品味了一下，最终选择了 Trello。我自己现在的体会是，Trello 好在你以什么样的程度去用都可以，简单当看板用也可以，再复杂点支持更多项目管理内容也能用，没有一个高学习成本和固化的套路，这很好。

我们非常注意何时将其用作流程工具、何时用作沟通工具、何时用作记录工具。例如，昨天我们还进行了一个小的讨论，某件工作本身是流程化的，我们在探讨是否应该使用工具来固化下来流程，在每一个步骤大家应该在工具里做什么样的操作、标记等等。但是后来发现，在这里其实有好几个主要环节，由人直接去线下实施，而不是先让信息在计算机里绕一圈，会更有效率，只需要将结果记录在工具中即可，过程可以非常有弹性。最终我们的结论是，只需要明确流程（哪怕是以邮件或口头通知的形式），在线下流程已经有效率的情况下，无需再使用工具来看起来「很规范」。

对于小团队，中国的团队，工具越简单越好，越轻量级越好，越灵活越好，越能够根据团队和实际工作选择性使用越好，而不是盲目追求强大，追求自动化。

Trello:

其他工具，例如 Github 等，也非常有帮助。

【李会军的回答(28票)】:

以前回答过类似的问题 http://www.zhihu.com/question/20114578/answer/21067452，我觉的答案非常适合这个问题，等有机会再写一篇文章专门讨论。

大部分朋友都推荐一堆的工具，我个人认为对于创业团队未必适合使用这么多的沟通交流以及团队协作工具：

1. 工具比团队人数多

简单统计一下，有邮件Email、即时通讯IM、日程管理 Google Calendar、文档协作Google Docs、项目管理Basecamp、群组聊天 Campfire 、文件共享Dropbox、缺陷跟踪 Lighthouse，这就已经有八个工具了，试想对于小创业公司来说，团队成员人数都不一定能有这么多，少则两三人、多则七八人。每个成员还要分别注册不同的系统帐号，才能跟大家一起工作，这是在提高效率，还是在降低效率？

2. 各个工具的数据无法共享

使用太多的工具造成的另外一个问题就是各个系统之间的数据无法共享，邮件分散的各自的邮箱里，IM聊天记录在各个成员的电脑里，Dropbox里的文件怎么跟Basecamp结合，怎么跟缺陷跟踪工具结合？经常想起一件事的时候，不知道应该去Dropbox里找文件还是去Email里面查找附件，又或者去Basecamp里找。工具应该是为人服务，人不应该被工具所牵绊。

3. 简单够用就好

结合以上两点，我认为在创业团队中，不需要太多的工具，下面是我们团队的使用情况：

1）Email：Email的地位始终无法取代，Email是必须的，我们使用的是 腾讯企业邮箱，Gmail由于众所周知的原因，无奈放弃。

2）GitHub ：源码管理，放弃自己搭建git、svn服务器的想法吧，在Github每月支付几美元就够用了，一年也花不了几个钱。我们所有的源代码都放在Github。

3）Worktile ：我们团队自己的产品，自产自销。用它做项目管理、缺陷跟踪、文件共享、群组聊天和文档协作，各个元素之间可以很好的互相配合。有朋友会问，Worktile做了这么多，估计哪个都做不专。这点我承认，文件共享我们不如Dropbox，文档协作不如Google Docs，但是仔细想想，我们真的用了Google Docs的全部功能了吗，还是那么句话，够用就好。再补充一点，Worktile可以很好的跟Email结合，通过Email创建任务、发起讨论，这样不就把把团队的资源连接起来了吗？

总结，我们内心始终在追求强大的工具，却忽略了寻找工具是为了解决团队问题。选择适合你的团队、满足需要的少数几个工具足以，用好工具才是关键，对于创业团队尤为重要。切记，别让你的团队使用的工具数比团队人数还多！