业务驱动下的技术逆袭

1、业务驱动下的技术逆袭技术创新 变革未来摘要多数组织中，技术团队常常成为象牙塔中的人他们被刻意地隐藏在产品团队或业务分析团队这样的前置团队的背后，并将其工作结果依照流程交付给下游的运维实施实施团队。而另一方面，多年来对研发人员的描述过多的理想化和简单化，使他们看起来像一群敏感、单纯、更喜欢和机器打交道的Nerd。基于这样的分工与暗示，技术团队往往被动或主动地定位成需求的实现者或系统的制造者，习惯于成为流水线上的一环。但在业务高速发展的阶段，在大量业务需求要快速交付以及现有业务要高效运转的压力下，技术团队及其系统的表现却差强人意。此时，技术团队和业务团队往往陷入相互指责境地。技术团队的效率、质量等

2、问题往往是有着实际证据，但技术团队的压力并不轻松，工作认同度很低，团队气氛压抑，创新匮乏，人心浮动虽然多数团队会尝试流程上的改进，以及使用新技术再建系统，但如何能够在业务高速运转的情况下保证成功的实施。更进一步，在这一过程中如何积极的进行团队构建，触及问题的根本，将技术团队打造成为创新的驱动力量，彻底跳出新一轮的问题循环。业务驱动下的技术逆袭亚马逊的EFP是外部供应链平台。在20122014年，其技术团队分布在西雅图和北京，而业务团队则分布在美国、英国、法国、德国、日本、印度和中国等国家。中国团队主要负责了供应商入驻、业务处理系统的核心、后台管理系统，以及数据分析工具（后期建立）。2012年1

3、2月，我从研发（SDE）转技术管理（SDM），由需求预测团队加入负责供应商入驻的技术团队。其时，在2012年全年，供应商入驻系统的线上报障有近3000+，而Sev2的问题一周8个左右。业务层面，供应商的入驻时间平均需要3个月。而新业务的尝试和调整需要大量的代码改动（业务逻辑分布在几十个文件中）和长时间的交付。这种情况下，业务团队和技术团队的冲突非常强烈，技术团队的士气很低，团队内部氛围相互推脱指责，EFP整个团队的业务和技术人员流动率非常高。接管该团队至2013年9月，使用DDD重构的整个Onboarding系统上线，在线报障逐步降低了%60+，Serv2问题降低到23个月1个。同时，新功能的

4、开发时间大大缩短。之后，技术团队开始主动为业务的运营提供支持，在技术团队的推动下，供应商入驻时间从50天降低到1周，并为进一步优化打好基础。另外，技术团队和业务团队建立起良好的合作反馈机制。团队成员从最初的4人扩张至8人。9个月的时间从工程师到技术管理从疲于应付到有执行力从老系统到新系统从被业务指责到驱动业务优化发生了什么？问题、应对和思考1. 试探2. 分析3. 冲突4. 团建5. 逆袭复盘EPISODE I 试探（14周）1. 认识团队2. 认识系统与业务1. 了解团队开发情况2. 了解整体流程3. 认识业务方4. 收集业务方初步反馈1. 建立（梳理）业务与研发的沟通与反馈渠道2. 规范计

5、划过程3. 调理团队氛围团队成员：空降的情况下，要尽快了解团队成员的情况。如果有条件，可以单独和资深员工私下先接触。通过其他人侧面了解团队成员的情况：性格特点，技术能力，是否负责任等等系统与业务：收集与系统和业务相关的资料安排团队相关人员讲解具体业务和系统。讲解过程中可以重点询问系统和业务存在的问题（从研发的角度）了解上下游系统与业务，并了解其接口人，尽早进行接触自己开发，问题多自己开发，问题多基于公司标准，问题少每周1次电话会议邮件需求不多主要是维护，问题不多邮件新需求多（来自供应商的，来自EFPM）问题多工作量不饱和工作量过饱和业务方与团队情况：了解需求的来源（业务方）渠道与沟通方式了解各

6、业务方的情况：需求量，对应系统的情况等。尤其是业务方对研发情况的反馈。了解当前项目进展的情况，了解团队成员的工作安排需求研发+运维了解整体流程：需求的提报方式方法研发如何排期和开发测试和运维如何进行了解各阶段的衔接情况：如何衔接，是否有瓶颈等研发人员完成全部工作，包括7*24oncall有一套非常完善的基础设施，研发和部署效率很高重点举措构建信任感：依据业务初步反馈，找到重点问题解决，快速建立业务和研发的信任感。进行初步团队建设，调理团队氛围，建立团队成员之间的信任感。构筑管理者与团队的信任感。业务反馈研发慢研发不透明反馈不及时系统问题多团队反馈业务杂事多系统问题多成员之间有隔阂沟通混乱缺乏信

7、任目标不一致构建沟通渠道需求渠道所有需求先归口到经理，由经理统一管理。业务人员不能直接找研发人员。问题反馈建立业务与研发的定期对接，安排每周一次与业务的对接会议，了解需要帮忙跟进的事项。执行反馈在周报中关注研发计划和问题根据，将业务方作为周报的关注者，使其了解进展情况。规范计划过程场景走查相关人员（甚至是整个组）在业务流程和系统操作流程上将PRD的需求串联起来，这样做有如下好处：让研发人员对所做的事情达成共识构建整体业务流程的全貌形成整体产品的感觉防止业务和功能上的遗漏统一研发和业务的沟通语言规范计划和沟通过程敏捷计划在场景走查基础上，由团队将任务切分到23人天，以此安排两周内的工作。引入任务

8、墙，以便第一时间了解项目的进展状态以及资源安排情况每日站会站会起到两个作用：第一，让团队成员有一个时间彼此沟通，第二，每日跟进项目推进的情况回顾/复盘早期采用标准的回顾会议方式，几次后由于团队人数有限，我们开始以座谈的方式进行复盘，识别改进点。调理团队氛围每日站会团队在固定的时间相互沟通和熟悉调整座位将FNLP的两位同事调整到DS的大团队中，整个团队坐到一起，加强归属感，并消除沟通上障碍。调整团队名称将DS Onboarding和FNLP统一为EFP NM（Node Management），对外对内统一对团队责任的认知。责任共担革命友谊的建立需要一起扛枪打仗，因此，工作上必须有交集。这种交集早

9、期通过共同轮值来建立。从长期看，FC方面的需求会越来越少，而DS问题很多，后期需求会一直稳定。因此，负责FNLP的两位研发同事必须介入到DS的开发中，但此时他们仍需处理FC方面的需求，所以，负责FNLP的两位同事先参与到DS的轮值工作（oncall）中来，并明确DS的两位同事在初期必须全力辅助配合。与大龄强力程序员建立频繁的非正式沟通：放低姿态，增加熟悉程度。借抽烟一起聊天，聊孩子、聊摄影、聊团队了解他的想法，也让他了解我的想法，并征求他的意见我的感受：茫然焦虑紧张团队的感受：陌生怀疑EPISODE II 分析（58周）稳定推进新举措面向问题，深入分析建立1对1沟通深层问题浮现与处理：浅层问题

10、处理见效快，易于获得好的反馈，利于构建信任感和自信心。深层问题之后会逐渐出现，它们需要更多数据、更深入的分析，需要关注长期的解决方案，也需要更好的执行力进行推进。在团队的层面上，需要更深层次的了解团队和团队成员，建立一种定期的、有目的性的沟通机制。1对1沟通：每2周与团队成员进行3060分钟的单独沟通沟通内容：团队成员的感受（满意的地方，不爽的地方有什么建议或需要帮助推进的地方）团队成员的个人目标（最好与团队目标相契合，一起分析，落实到计划和双方的行动，每次沟通进行检查）对团队成员进行反馈（好的正面肯定，不好的一起分析，给出建议：行为-影响-建议）好处：成员情绪管理，及早了解可能的异动帮助成员

11、进行目标管理按自己的领导风格对团队进行改造重点举措需求研发为什么慢？研发人员负责开发与运维2012年，3000+ tickets，其中workflow的ticket有1000+，而operation request的ticket有1000+2013年平均每周60个ticket，其中8个Serv2 ticket需求对接研发+运维从数据入手，分析运维工作的情况，如何应对？Serv2 ticket非常影响研发人员的工作，必须尽一切可能消除。因此，对每周Serv2进行RCA分析，给出到短期和长期解决方案，落实到人（外部团队）和时间，积极推动。（1个月后每周Serv2降低到2个左右，2个月后降低到每周1

12、个，重构开始前已降低到每月1个左右）归类分析所有Operation Request，将重复出现的工作工具化，提供给业务方使用。（修改IOG等）分析前一年的所有workflow问题，进行归类，按重复次数和修改的难易度进行归类和排定处理顺序，落实到人和时间，积极推动。（deprecate stanza等）关注每周、每月、每季度ticket数量，了解运维工作变化趋势，持续向合理推进。（以上工作的在重构前使ticket每周降低到30个左右）通过分析还发现：DSC系统设计很差、耦合度高，业务逻辑散布在不同的JSP和Java文件中，这是造成研发慢重要原因之一。旧workflow欠缺很多机制，有些相关tic

13、ket无法从根本上解决。看似要重构DSC和workflow，但无法第一时间做。（为什么不立即做？因为没有明确重构的目的和必要性，缺乏数据支持）通过1对1沟通逐步构建出团队画像团队画像：我的感受：茫然焦虑团队的感受：开始感受正面反馈初步信任相互开始熟悉，但无深入合作EPISODE III 冲突（912周）明确技术方向明确研发方向（与资源准备）凝聚团队人才盘点与梯队建设成员冲突处理绩效考核与人员取舍技术方向：团队要在技术的采用上达成一致的认识。可以通过团队的tenet来明确技术与业务的关系。优先使用成熟技术，不要盲目尝新。如果公司提供了基础架构和工具，就不轻易重复造轮子。后续业务，不再使用有问题的

14、技术或工具，停止产生新问题（技术债）。自己开发，问题多公司有DJS历史悠久自己开发，问题多基于公司标准技术成熟问题少无法维护耦合，问题多需要重构不直观要废弃研发方向：明确产品（或业务）的演进路线图（在一个具体的时间跨度内，业务或产品将要处理的工作）。可以自己与业务对接确定，取决于产品（或业务）情况以及相关人员的水平，路线图的时间跨度可长可短，内容可以细致也可以粗略。让团队明确今后的研发重点，因此，需要整个团队参与。可以根据研发方向及早明确资源（HC）的准备计划。人才盘点与梯队建设：明确关键岗位的要求，明确关键岗位对人员的要求通过关键维度来衡量团队成员，识别关键人才。简单的考虑绩效和潜力，复杂的

15、可以考虑目标和价值观（亚马逊使用Leadership Principle）。重点找出核心成员和高潜力成员，重点关注和培养，优先防范核心成员的流失。核心成员必须建立后备，针对后备制定培养计划。防止由人员造成的知识单点，做好成员互备，知识积累。通过项目促使核心成员培养新人，释放和固化知识与非技术能力（责任感和执行力）。成员冲突：鼓励一定程度的观念冲突。但要对事不对人，批评必须要有建设性。团队领导要以身作则。一旦开始针对人，早介入，早处理，防止扩大化。一旦发生严重问题，明确原则，及时止损，做好各方安抚，避免矛盾再次发生。必要时要做好丢车保帅的准备（牺牲非核心员工），迅速解决。要从人员之间的矛盾寻找根

16、源，针对性解决根本原因。绩效考核：要有客观的数据，简单的可以考察交付的数量与质量直接领导的评价360度反馈，考察来自同事和客户（业务）的意见。重要性按照：数据直接领导评价360反馈要避免更高层领导的干预。尽量公平（平时要注意防止团队马太效应）重点举措关键项目：在明确了技术方向的基础上，我们需要一个新业务的开发，证明未来系统重构的业务价值，同时建立新的开发规范和团队协作氛围。业务价值的考虑上是为了统一业务和研发的目标，将未来大系统的重构落地到业务层面上。OP1&OP2：需要和团队一起讨论确定大致了解未来的研发重点以及安排人员招聘的数量半年期计划：按月计划相对粗粒度但侧重点要清晰360反馈提高是目

17、的，不是为批评围绕Leadership Principle打分，并使用行为-影响-建立来反馈。人才盘点：绩效/业绩能力潜力动力满意度离职风险业绩/绩效潜力+动力需要成长满足期望无潜力有潜力高潜力超出期望 5=关注人才8=自我提升人才7=稳定人才6=稳定人才9=提升绩效者4=核心人才3=核心人才2=:核心人才1=明星人才矛盾公开化与处理团队领导很大程度上影响团队氛围矛盾的根本在于张天师，必须尽力屏蔽天师对团队的负面影响。同时要收集数据改变天师对成员的看法。VF WF项目由孙和白直接对接，二师兄参与。从团队的利益出发，对人员进行安抚和调度。要依赖悟空，但要防止过度依赖我的感受：焦虑着急团队的感受：

18、信任受挫EPISODE IV 团建（1316周）关键项目交付与反馈价值观与领导风格向上管理人员招聘交付关键项目：通过来自业务方的反馈和历史数据的对比，提高团队的自信心、成就感和集体荣誉感。证明了重构的业务价值。VF WF项目交付后，WF相关ticket为0，VF node的onboarding时间从23周降低到3天左右。新的UI操作更方便。VF WF的后期调整时间在2天以内。JP第一个VF通过新WF上线（3天）。收集数据作为绩效证据。领导风格：责任感、执行力、服务意识。执行力需要：充分讨论（决策过程） 要有反馈（中间过程，总结性反馈） 要追踪 （落实的行动项）领导风格极大地影响团队行事氛围。西

19、雅图VF研发团队喜欢push back，为什么？要以身作则。向上管理：定期主动沟通：团队的情况和诉求，自己的情况和诉求。了解领导未来的诉求，积极配合。遇到决策，做好功课，让领导做选择题，而不是思考题。重点举措团队变化直属经理换团队，高级经理换团队西雅图新招了高级经理介绍团队的历史情况新成员从大团队转入新招若干人团队氛围趋向稳定，能够积极产出组织新老大和大团队一起去爬野长城、睡大通铺、谈心EPISODE V 逆袭（1736周）重构 vs. 重做使用DDD，重构中梳理领域（业务）知识设计文档化单元测试关注业务价值业务运营数据收集业务数据分析与报告推动业务自动化推动业务决策重构的前提：研发团队稳定、有责任感、有执行力研发理解业务 遗留系统问题（技术债务）明确、可控研发团队有确定的技术方向已有指标性数据，并有收集方式重构有明确的业务目标重构有明确的范围、期限重构的要求：核心负责全员参与积累知识关注质量分步进行数据验证定期复盘技术驱