软件开发平台 DevCloud软件开发平台 DevCloud

计算
弹性云服务器 ECS
裸金属服务器 BMS
云手机 CPH
专属主机 DeH
弹性伸缩 AS
镜像服务 IMS
函数工作流 FunctionGraph
云耀云服务器 HECS
VR云渲游平台 CVR
特惠算力专区
存储
对象存储服务 OBS
云硬盘 EVS
云备份 CBR
弹性文件服务 SFS
存储容灾服务 SDRS
云硬盘备份 VBS
云服务器备份 CSBS
数据快递服务 DES
专属企业存储服务
云存储网关 CSG
专属分布式存储服务 DSS
CDN与智能边缘
内容分发网络 CDN
智能边缘云 IEC
智能边缘小站 IES
智能边缘平台 IEF
人工智能
AI开发平台ModelArts
华为HiLens
图引擎服务 GES
图像识别 Image
文字识别 OCR
自然语言处理 NLP
内容审核 Moderation
图像搜索 ImageSearch
医疗智能体 EIHealth
园区智能体 CampusGo
企业级AI应用开发专业套件 ModelArts Pro
人脸识别服务 FRS
对话机器人服务 CBS
视频分析服务 VAS
语音交互服务 SIS
知识图谱 KG
人证核身服务 IVS
IoT物联网
设备接入 IoTDA
设备管理 IoTDM(联通用户专用)
全球SIM联接 GSL
IoT数据分析
路网数字化服务 DRIS
IoT边缘 IoTEdge
设备发放 IoTDP
开发与运维
软件开发平台 DevCloud
项目管理 ProjectMan
代码托管 CodeHub
流水线 CloudPipeline
代码检查 CodeCheck
编译构建 CloudBuild
部署 CloudDeploy
云测 CloudTest
发布 CloudRelease
移动应用测试 MobileAPPTest
CloudIDE
Classroom
开源镜像站 Mirrors
应用魔方 AppCube
云性能测试服务 CPTS
应用管理与运维平台 ServiceStage
云应用引擎 CAE
视频
实时音视频 SparkRTC
视频直播 Live
视频点播 VOD
媒体处理 MPC
视频接入服务 VIS
管理与监管
统一身份认证服务 IAM
消息通知服务 SMN
云监控服务 CES
应用运维管理 AOM
应用性能管理 APM
云日志服务 LTS
云审计服务 CTS
标签管理服务 TMS
资源管理服务 RMS
应用身份管理服务 OneAccess
区块链
区块链服务 BCS
可信跨链服务 TCS
可信分布式身份服务
智能协作
IdeaHub
开发者工具
SDK开发指南
API签名指南
DevStar
HCloud CLI
Terraform
Ansible
云生态
云市场
合作伙伴中心
华为云培训中心
其他
管理控制台
消息中心
产品价格详情
系统权限
我的凭证
客户关联华为云合作伙伴须知
公共问题
宽限期保留期
奖励推广计划
活动
容器
云容器引擎 CCE
云容器实例 CCI
容器镜像服务 SWR
应用编排服务 AOS
多云容器平台 MCP
基因容器 GCS
容器洞察引擎 CIE
云原生服务中心 OSC
容器批量计算 BCE
容器交付流水线 ContainerOps
应用服务网格 ASM
网络
虚拟私有云 VPC
弹性公网IP EIP
弹性负载均衡 ELB
NAT网关 NAT
云专线 DC
虚拟专用网络 VPN
云连接 CC
VPC终端节点 VPCEP
数据库
云数据库 RDS
数据复制服务 DRS
文档数据库服务 DDS
分布式数据库中间件 DDM
云数据库 GaussDB (for openGauss)
云数据库 GaussDB(for MySQL)
云数据库 GaussDB NoSQL
数据管理服务 DAS
数据库和应用迁移 UGO
大数据
MapReduce服务 MRS
数据湖探索 DLI
表格存储服务 CloudTable
可信智能计算服务 TICS
推荐系统 RES
云搜索服务 CSS
数据可视化 DLV
数据湖治理中心 DGC
数据接入服务 DIS
数据仓库服务 GaussDB(DWS)
应用中间件
微服务引擎 CSE
分布式消息服务Kafka版
分布式消息服务RabbitMQ版
API网关 APIG
分布式缓存服务 DCS
分布式消息服务RocketMQ版
企业应用
域名注册服务 Domains
云解析服务 DNS
云速建站 CloudSite
网站备案
商标注册
华为云WeLink
会议
隐私保护通话 PrivateNumber
语音通话 VoiceCall
消息&短信 MSGSMS
云管理网络
SD-WAN 云服务
边缘数据中心管理 EDCM
云桌面 Workspace
应用与数据集成平台 ROMA Connect
ROMA资产中心 ROMAExchange
API全生命周期管理 ROMA API
安全与合规
安全技术与应用
DDoS防护 ADS
Web应用防火墙 WAF
云防火墙 CFW
应用信任中心 ATC
企业主机安全 HSS
容器安全服务 CGS
云堡垒机 CBH
数据库安全服务 DBSS
数据加密服务 DEW
数据安全中心 DSC
云证书管理服务 CCM
SSL证书管理 SCM
漏洞扫描服务 VSS
态势感知 SA
威胁检测服务 MTD
管理检测与响应 MDR
安全治理云图 Compass
认证测试中心 CTC
迁移
主机迁移服务 SMS
对象存储迁移服务 OMS
云数据迁移 CDM
专属云
专属计算集群 DCC
解决方案
高性能计算 HPC
SAP
混合云灾备
华为工业云平台 IMC
价格
成本优化最佳实践
专属云商业逻辑
用户服务
帐号中心
费用中心
成本中心
资源中心
企业管理
工单管理
客户运营能力
国际站常见问题
支持计划
专业服务
合作伙伴支持计划
更新时间:2021-03-18 GMT+08:00
分享

分布式开发的喜与忧

关于办公场景

无论是异地分布式软件开发或是外包,可以接触到实际客户的一端称为On-Site,另一端则称为Off-Site。而Off-Site又可以根据地理位置分为三类:On-Shore(在岸,指在同一个国家或同一个时区内),Near-Shore(近岸,在接近的国家和地区中)和Off-Shore(离岸,通常在时差6小时以上),如下表所示。

Off-Site

On-Shore

Near-Shore

Off-Shore

分布式开发

北京办公室:成都办公室

印度分公司:中国分公司

硅谷总公司:中国或印度分公司

软件外包

北京某公司:成都另一公司

东京某公司:大连另一公司

欧洲某公司:中国另一公司

关于彼得原理

彼得原理是美国学者劳伦斯·彼得在对组织中人员晋升的相关现象研究后得出的一个结论。在各种组织中,由于习惯于对在某个等级上称职的人员进行晋升提拔,因而雇员总是趋向于晋升到其不称职的地位。彼得原理有时也被称为“向上爬原理”。

彼得指出,每一个员工由于在原有职位上工作成绩表现好(胜任),就将被提升到更高一级职位;其后,如果继续胜任,则将进一步被提升,直至到达他所不能胜任的职位。由此导出的彼得推论是,每一个职位最终都将被一个不能胜任其工作的员工所占据。层级组织的工作任务多半是由尚未达到不胜任阶层的员工完成的。

这个过程往往是单向的、不可逆的,也就是说,很少被提升者会回到原来他所胜任的岗位上去。因此,这样“提升”的最终结果是企业中绝大部分职位都由不胜任的人担任。这个推断听来似乎有些可笑,但绝非危言耸听,甚至不少企业中的实际情况确实如此。这样的现象还会产生另外一种后遗症,就是不胜任的领导可能会阻塞了胜任者提升的途径,其危害之大可见一斑。

因为这种情况最终会把一个晋升的梯子摆在每个管理人员面前,让每个人都成为排队木偶。为了避免人们都成为排队木偶,扭转“体系萧条”的颓势,彼得博士提出了“彼得处方”——《彼得原理》。

关于团队建设

团队建设也是有生命周期的。必然要经历组建期(Forming)、风暴期(Storming)、规范期(Norming),然后才是高绩效期(Performing)。管理到一定程度后,一定是全生命周期的管理,应该是一个闭环和持续改进的过程。

第一步,选人。千里马常有,而伯乐不常有。因为我们都不可能是专职的伯乐,所以要打破应聘要求的条条框框,多花时间在简历分析和面试沟通上。要亲自参与面试,而不是简单地给出需求,全部交给HR部门来完成。更重要的是换位思考,选择一个人才进入团队的时候,首先要考虑他能够带给成员的是什么,是否适合这个团队。如果团队中每个成员的胜任力都很优秀的话,自然能够带来优秀的业绩和团队绩效。

在找到了合适的人后,第二个重点就是为合适的人分配适合的工作。我们需要看到每个人的短处,但是我们关注的却是各尽所能地发挥每个人的长处。所以要对人员的技能做评估,对团队角色的职责做出明确定义和划分,定义好团队之间的操作规程和流程。

第三步,通过团队建设来保持整个团队的积极性和热情。首先是要建立团队愿景,很重要,是树立团队精神和建立大家共同价值观的基础。然后是制定团队的规则和纪律,这应该是大家共同制定出来的、必须要遵守的。对于团队的建设,一方面是偏重应用的,主要是指团队学习和培训组织等,提升团队的知识技能;另一方面是关于价值观、时间管理、心态、职业精神等方面的培训,便于形成团队共有的价值观。团队之所以不同于团伙,正在于团队中所有成员的价值观都是和团队价值观同向,共同的愿景才可能产生共同的合力。

第四步,建立竞争机制。在团队内营造一份良好的、积极向上的竞争氛围。

第五步,建立奖惩制度。驱动人们的理由无非有两个,一个是赢得欢乐,另一个就是逃离痛苦。这也就是管理大师们常说的X/Y理论。

最后,就是回顾并不断地调整团队,重新回到起点。

领导力

领导力应该体现在影响力上,而不是依靠组织赋予的地位权利(Position Power)。在一个团队中,影响力和说服力要比权力更重要,团队成员之所以相信你,愿意跟随你,不是因为恐惧,而是因为真的爱你、相信你。有些人可能不是一个团队领导,但却有无比的影响力和号召力,这尤其说明了这一点。

作为团队领导,很关键的一点就是看你是不是真的“用心去领导”。我觉得关键的一点就是要去了解团队每一个成员的需求与渴望,去跟他们进行心与心的沟通。这一点也是符合马斯洛的需求层次理论的。

作为团队领导人,首先需要了解你的团队成员在每个阶段的需求,然后尽可能地满足。要跟X理论和Y理论有机地结合起来。

通过Scrum管理和协调异地团队的指导原则

通过Scrum管理和协调两个不同地理位置的团队,是一个非常有挑战性的工作。

最高指导原则就是沟通、沟通、再沟通。对于一个分布式团队,最重要的就是解决沟通的问题。因为缺乏面对面的沟通,还由于时间、文化、语言的不同,需要付出更多的人力和财力才能获得预期的结果,而且小的误解也会迅速放大。这需要在团队建立之初,就考虑好这个问题。沟通不要怕多,一定要充分才行。对这个问题,有一个非常著名的康威定律(Conway's Law)。

康威定律的原始表述是这么说的:让四个人开发编译器,你就会得到四个编译器。

这个表述更具有一般性:“产品必然是其组织通讯结构的缩影”。简言之就是“方法决定结果”或是“过程变为产品”。这个定律无非在告诉我们开发人员间的高效面对面的沟通,对于好的产品和设计是至关重要的,由于沟通不顺畅,分布式的团队往往会损害到软件设计。

坚持每日站立会议。有条件的话,最好进行可视会议,这样双方都可以看到对方的表情,感受到对方的情绪变化。无论如何,面对面地交流才是最有效的方式。如果你们有条件的话,要让处于两地的团队到对方出差,互相熟悉,特别是Off-Site一端要到On-Site一端去,去与客户进行交流,了解客户需求与环境,这样才能更容易理解On-Site一端的语义上下文和环境。

方式方法会有很多,关键还是要建立好一个沟通交流机制与规则,如每天立会的时间、能否准时开会、问题的跟踪解决机制等。

指导原则之二是使用正确的实践和工具。成功的软件开发团队所使用的实践中,众所周知的有:共同的编码标准、源代码控制服务器、一键建立和部署脚本、持续集成、单元测试、错误跟踪、设计模式以及应用程序块。与本地团队相比,分布式团队必须以更严格的标准应用这些实践。

分布式开发,如何让对方知道对方、乃至整个团队任务的最新进展,单单靠每日的立会是不够的。最好采用一些在线工具进行项目跟踪,现在已经有了一些很好的在线敏捷项目管理工具。

采用工具进行代码管理,才能保证双方的每日提交,更容易集成起来。持续集成对于异地团队至关重要。

要把需求和验收条件描述清楚、简单明了,尽可能地减少误解。做到DoR(Definition of Ready,就绪的定义)。

Sprint的计划会议一定要一起开,最好是一方的人员到对方去,大家坐在一起,面对面地制订计划。而演示,可以远程进行,但也要所有的团队成员都参加才好,因为这是一个很好的分享成果的机会。而回顾完全可以分别进行,然后再相互交流回顾结果与改进计划。

分布式开发的要点

  1. 招聘员工准则:聘之以态度,授之以技能(hiring for attitude, training for skills)。
  2. 团队建设的生命周期准则如下:
    • 选择合适的人才。
    • 设立清晰的愿景、明确的目标。
    • 合理用人。人尽其才,才尽其用,充分发挥每个人的优势。
    • 建立良性竞争机制。
    • 建立奖惩与监督制度。
    • 建立完善的培训系统,关注员工的个人发展。
    • 评估并不断改进团队。
  3. 领导力应该体现在他的影响力上,而不是依靠组织赋予的Position Power。
  4. 用心去领导。要了解团队每一个成员的需求与渴望,去跟他们进行心与心的沟通。按照马斯洛的需求层次理论进行针对性的激励。
  5. 情境领导力。根据情境去领导(Situational Leadership)。没有最好的领导力,只有最适合的领导风格,管理者要根据员工的不同情境灵活调整自己的领导风格和领导形态。
  6. 尽管一个组织必须重视管理人员成长可能性,并通过提供更大的发展空间等手段来激发他们的潜能,但彼得原理可以作为一种告诫:不要轻易地进行选拔和提拔。

    解决这个问题最主要有以下三大措施:

    • 提升的标准更需要重视潜力而不仅仅是绩效。应当以能否胜任未来的岗位为标准,而非仅仅在现在岗位上是否出色。
    • 能上能下绝不能只是一句空话,要在企业中真正形成这样的良性机制。一个不胜任经理的人,也许是一个很好的主管,只有通过这种机制找到每个人最胜任的角色,挖掘出每个人的最大潜力,企业才能“人尽其才”。
    • 为了慎重地考察一个人能否胜任更高的职位,最好采用临时性和非正式性“提拔”的方法来观察他的能力和表现,以尽量避免降职所带来的负面影响。如设立经理助理的职位,在委员会或项目小组这类组织中赋予更大的职责,特殊情况下先让他担任代理职位等。
  7. 成功企业有以下两大用人之道:
    • 适当引进外来人才,避开“彼得原理”所涉及的后果。
    • 在企业内部逐步提升,重视潜力,重要的职位大多数由胜任的人担任。

用经营产品的方式经营团队

产品面临的环境是复杂的,培养一个团队也是。产品需要经营和维护,培养一个团队也是。经营产品,与经营团队有许多异曲同工之处。用经营产品的方式来经营团队,我们来看看这里有哪些可以借鉴之处。

  1. 产品需要不断探索和尝试,去发现产品被客户认可的点,并将其发挥到极致;管理中,识别你希望看到的行为,让其变成持续不断的实践,然后用纪律来保证这些实践顺利进行。
  2. 产品会做A/B测试,同样的,领导者也可以尝试用不同的方式来管理团队流程,不断设定方向,获得反馈,主动试验,持续优化。循序渐进的试验,正如同产品演进一样。
  3. 伟大的产品,会让每个参与在内的人激动不已;伟大的团队,会让成员愿意和团队一起解决问题,共同奋斗,获取成功。
  4. 大而全的产品未必人人喜欢,小而美但解决具体问题的产品会更受欢迎;团队也是一样,人多力量大是错觉,要认识到小而精的团队的威力。
  5. 不要违反人性,产品如此,团队也是如此。
  6. 产品操作要简单,步骤要简洁,不要让用户思考,不要设置障碍;团队管理要遵循尽可能简洁的工作流程,不要束缚团队成员的动力。
  7. 做正确的产品,比正确地做产品更重要;公司建立起各种规章制度,目的是让人正确地做事,而员工通常更需要知道的是,他们最需要完成的工作是什么,即什么是正确的事情。用正确的人,做正确的事,然后才是正确地做事。
  8. 尊重用户,不要试图控制和欺骗;遵循成年人法则,像对待成年人那样对待员工,尊重、坦诚、透明,而且他们很喜欢这样。
  9. 商业环境瞬息万变,产品需要小步冲刺,快速迭代;经营团队,不要再制定什么年度计划,而是更多的时间来做季度计划。
  10. 伟大的产品自己会说话;伟大的团队员工能讲(真)话。
  11. 站在用户的角度设计产品,以同理心去共情;要培养基层员工的高层视角,员工需要以高层管理者的视角看事物,感受到自己与所有层级,所有部门,必须解决的问题建立真正的联系,公司才能发现每个环节上的问题,员工才是真正的合伙人。
  12. 不要质疑用户的问题,每一个反馈,每一个无法满足的诉求,都可能是产品改进的点。领导者不要把员工的提问当成挑战,永远不要低估问题与想法的价值,回答不上来的问题,是最好的改进机会,而不是尴尬的事情,把每一次问答,当作学习的机会。
  13. 把员工当客户,重视员工的体验和感受;不要想当然的主观臆断用户如何使用产品;员工对业务的无知,是领导者的失职,用简单直白的方式对业务进行解释并非一件易事,公司和全体员工分享的信息通常不是太多,而是少得可怜。
  14. 简单,勇气,沟通,透明,反馈,对产品和员工都适用。
  15. 如果你想知道用户怎么想,去现场调研;如果你想知道员工在想什么,没有比直接询问他们更好的办法了。

本文内容节选自《敏捷无敌之DevOps时代》,作者:王立杰、许舟平、姚冬(清华大学出版社)。

分享:

    相关文档

    相关产品

关闭导读