|
|
# 26 | 平台产品研发：三个月完成千人规模的产品要怎么做？
|
|
|
|
|
|
你好，我是石雪峰。
|
|
|
|
|
|
虽然我们之前聊了这么多的平台建设思路，但是，可能很多人都没有机会经历一个平台从构思到开发、再到推广落地的完整过程。
|
|
|
|
|
|
如果要开发一个千人使用的DevOps产品，需要多长时间呢？你可能会说需要半年甚至是更长的时间，我之前也是这么觉得的。
|
|
|
|
|
|
但是，2018年，在启动流水线平台建设的时候，老板“大手一挥”，要求在三个月内见到成效，我都快惊呆了。
|
|
|
|
|
|
因为，我们要真正地从零开始：原型图都没有一张，代码都没有一行，临时组建的一个草台班子还分散在北京、上海两地，团队成员之前都没怎么打过招呼，这能行吗？
|
|
|
|
|
|
今天，我想给你分享的就是这个真实的故事。我来跟你一起复盘下这次“急行军”的历程，看看我们做对了什么，又做错了什么，有哪些干货是可以拿来就用的，又有哪些“坑”是你一定要努力回避的。
|
|
|
|
|
|
其实，作为一个非专业的DevOps产品经理，你终将面对这样的挑战，但你要相信，**只要开始去做了，就没有什么是不可能的**。
|
|
|
|
|
|
## 项目启动
|
|
|
|
|
|
时间回到一年前，当时我所在的这个“草台班子”是个啥情况呢？团队组成是这样的：两个后台开发在北京，一个半前端开发在上海，还有一个基础设施工程师和一个流水线开发工程师，再加上半个全能打杂的产品经理，也就是我，满打满算一共6个人。
|
|
|
|
|
|
项目从11月中旬开始构思，12月初开启动会，当时，除了我之外，没有任何人清楚我们要做的到底是个什么玩意儿。这该怎么办呢？
|
|
|
|
|
|
玩过游戏的同学应该都知道打好开局有多重要，所以，为了这个Kickoff会议，我事先做了大量的准备工作，其中就包括0.2版本的产品原型图。与其说是一个原型图，不如说就是一个草稿，简陋得不能再简陋了。
|
|
|
|
|
|
|
|
|
|
|
|
项目的Kickoff会议是项目组成员和未来产品的第一次见面，留下一个积极的印象非常重要。所以，从第一刻开始，我就铆足了精神。
|
|
|
|
|
|
首先，我发出了一封热情洋溢的会议邀请。在会议邀请中，我仔细地陈述了我们为什么要做这件事，为什么是现在，为什么不做不行。
|
|
|
|
|
|
在正式开会的时候，我再一次明确了项目的重要性和紧急性，并给大家演示了第一版的系统原型图（没错，就是简陋到极致的刚刚的这张原型图）。
|
|
|
|
|
|
即便这样，三个月的工期也让大家非常焦虑。为了缓解紧张情绪，证明这个项目的可行性，我还做了两件事：
|
|
|
|
|
|
1. 搭建了一个系统demo，几个简单的页面；
|
|
|
2. 由于用到了另外一个开源产品的核心技术，于是，我就对这个技术进行了简单演示。
|
|
|
|
|
|
虽然我自己心里对这个计划也相当“打鼓”，但我还是希望告诉大家，这并不是不可能的任务，努力帮助大家树立信心。
|
|
|
|
|
|
在项目启动会上，团队达成了两个非常关键的结论：**一个是系统方案选型；另一个是建立协作机制**。
|
|
|
|
|
|
首先，由于时间紧任务重，我们决定使用更易于协作的前后端分离的开发模式。后来，事实证明，这是一个非常明智的选择。这不仅大幅提升了开发效率，也大大降低了之后向移动端迁移的成本。在开发移动端产品的时候，后端接口大部分都可以直接拿来使用。
|
|
|
|
|
|
在技术框架方面，由于大家对前后端分离的模式达成了共识，我们就采用**Python+Django+VUE**的方式来做。你可能会问，为啥不用基于Java的Spring系列呢？因为我觉得，对于内部系统来说，这些典型的框架应付起来基本都绰绰有余，关键还是要选你熟悉的、易上手的那个。从这个角度来看，Python显然有着得天独厚的优势。即便之前只是写写脚本，想要上手Python也不是一件困难的事情。
|
|
|
|
|
|
在项目协作方面，我等会儿会专门提到，由于团队成员分散在北京、上海两地，彼此之间不够熟悉和信任，所以，**建立固定的沟通机制就非常重要**。
|
|
|
|
|
|
至少，在项目初期，我们每周都要开两次电话会议：
|
|
|
|
|
|
* 一次是面向全员的。一方面同步项目的最新进展，另一方面，也给大家一些紧迫感，让大家觉得“其他人都在按照计划执行，自己也不能落后”。
|
|
|
* 另外一次是面向跨地域骨干的。这主要还是为了增进联系，并且对一些核心问题进行二次的进展确认。不拉上全员，也是为了避免过多地浪费项目成员的时间。
|
|
|
|
|
|
最后，项目毕竟还是有一些技术风险的，所以还需要启动预研。我们这个项目的主要风险是在**前端交互**上。
|
|
|
|
|
|
这是一个从来没人实现过的场景，有大量的用户界面编排操作在里面。所以，我们专门指定了一位同学，让他啥也别想，一门心思地进行技术攻关。
|
|
|
|
|
|
事实证明，但凡能打硬仗的同事，在后来都是非常靠谱且独当一面的，这与年龄无关，哪怕是应届生，也同样如此。
|
|
|
|
|
|
讲到这里，我要先给你总结一下在项目启动阶段要重点关注的几件事情：
|
|
|
|
|
|
* 明确项目目标，树立团队的信心；
|
|
|
* 沟通开发模式和技术架构选型，以快速开发和简单上手为导向；
|
|
|
* 建立沟通渠道，保持高频联系；
|
|
|
* 识别项目的技术风险，提前开启专项预研。
|
|
|
|
|
|
## 开发策略
|
|
|
|
|
|
人类社会活动的每一个环节，都需要越来越多的人为了同一个目标推进工作，软件开发也不例外。那么，我们是怎么做的呢？
|
|
|
|
|
|
首先，就是**研发环境容器化**。
|
|
|
|
|
|
**对于接触一个全新技术栈的开发来说，本地搭建一套完整可运行的环境总是绕不过去的坎**。即便是对照着文档一步步操作，也总会有遗漏的地方。除此之外，项目依赖的各种中间件，哪怕稍微有一个版本不一致，最后一旦出现问题，就要查很久。
|
|
|
|
|
|
既然如此，为什么不一上来就采用标准化的环境呢？这就可以发挥容器技术的优势了。主力后台开发同学自己认领了这个任务，先在本地完成环境搭建并调试通过，接着把环境配置容器化。这样一来，新人加入项目后，几分钟就能完成一套可以工作的本地开发环境。即便后续要升级环境组件，比如Django框架版本，也非常简单，只要推送一个镜像上去，再重启本地环境就可以了。
|
|
|
|
|
|
其次，就是选择分支策略。虽然DevOps倡导的是主干开发，但是我们还是选择了“三分支”的策略，因为**我们搭建了三套环境**。
|
|
|
|
|
|
测试环境对应dev分支作为开发主线，所有新功能在特性分支开发，自测通过后，再通过MR到dev分支并部署到测试环境进行验收测试，一般验收测试由需求提出方负责。
|
|
|
|
|
|
接下来，定期每周两次从dev上master分支，master分支对应了预发布环境，保证跟生产环境的一致性，数据也会定期进行同步。只有在预发布环境最终验收通过后，才具备上线生产环境的条件。通过将master分支合并到release分支，最后完成生产环境部署。这种分支策略的示意图如下：
|
|
|
|
|
|
|
|
|
|
|
|
为什么要采用三套环境的“三分支”策略呢？
|
|
|
|
|
|
这里的主要原因就是，团队处于组建初期，磨合不到位，经常会出现前后端配置不一致的情况。更何况，我们这个项目不只有前后端开发，还有核心原子业务开发，以及基础设施维护。任何一方的步调不一致，都会导致出现问题。
|
|
|
|
|
|
另外，内部平台开发往往有个通病，就是**没有专职测试**。这也能理解，总共才几个人的“草台班子”，哪来的测试资源啊？所以，基本上只能靠研发和产品把关。
|
|
|
|
|
|
但是，毕竟测试也是个专业的工种，这么一来，总会有各种各样的问题。再加上，产品需求本身就没有那么清晰、灵活多变，所以，**多一套环境，多一套安全**。
|
|
|
|
|
|
但不可否认的是，这种策略并非是最优解，只不过是适应当时场景下的可行方案。当团队磨合到位，而且也比较成熟之后，就可以简化一条分支和一套环境了。不过，前提是，**只有快速迭代，快速上线，才能发挥两套环境的优势**。
|
|
|
|
|
|
> Use what you build to build what you use.（使用你开发的工具来开发你的工具）
|
|
|
|
|
|
这是我们一以贯之的理念。既然是DevOps平台，那么团队也要有DevOps的样子，所以，作为一个全功能团队，研发自上线和研发自运维就发挥到了极致。
|
|
|
|
|
|
同时，我们并没有使用公司统一的上线流程，而是自己建立了一个标准化的上线流程并固化在工具里面，团队的每一个人都能完成上线动作。
|
|
|
|
|
|
这样一来，就不会再依赖于某个具体的人员了，这就保持了最大的灵活性。即便赶上大促封网，也不会阻塞正常的开发活动。
|
|
|
|
|
|
## 开发协作流程
|
|
|
|
|
|
仅仅是做到上面这几点，还不足以让整个团队高效运转起来，因为**缺少了最重要的研发协作流程**。
|
|
|
|
|
|
作为项目负责人，我花了很大的精力优化研发协作流程，制定研发协作规范。当这一切正常运转起来后，我发现，这些前期的投入都是非常值得的。
|
|
|
|
|
|
在工具层面，我们使用了Jira。对于小团队来说，Jira的功能就足够优秀了，可以满足大多数场景的需求。但是Jira的缺点在于，使用和配置门槛稍微有点高。因此，团队里面需要有一个熟悉Jira的成员，才能把这套方法“玩”下去。
|
|
|
|
|
|
在Jira里面，我们采用了**精益看板加上迭代**的方式，基本上两周一个迭代，保持开发交付的节奏。这种开发工作流刚好适配我们的分支策略和多环境部署。
|
|
|
|
|
|
需求统一纳入Backlog管理，当迭代开始时，就拖入待开发状态，研发挑选任务启动开发，并进入开发中。当开发完成后，也就意味着功能已经在测试环境部署。这个时候，就可以等待功能验收。只有在验收通过之后，才会发布到预发布环境。并经过二次验收后，最终上线发布给用户。
|
|
|
|
|
|
开发流程并不复杂，你可以看一下下面这两版流程图。
|
|
|
|
|
|
图片版：
|
|
|
|
|
|
|
|
|
|
|
|
文字版：
|
|
|
|
|
|
|
|
|
|
|
|
定义好开发工作流之后，接下来，就需要明确原则和规范了。对于一个新组建的团队来说，**规则是消除分歧和误解的最好手段，所以一定要让这些规则足够得清晰易懂**。比如，在我们内部就有一个“3-2-1”原则：
|
|
|
|
|
|
3：**创建**任务三要素
|
|
|
|
|
|
* 有详细的问题说明和描述
|
|
|
* 有清晰的验收标准
|
|
|
* 有具体的经办人和迭代排期
|
|
|
|
|
|
2：**处理**任务两要素
|
|
|
|
|
|
* 在开发中，代码变更要关联Jira任务号
|
|
|
* 在开发完成后，要添加Jira注释，说明改动内容和影响范围
|
|
|
|
|
|
1：**解决**任务一要素
|
|
|
|
|
|
* 问题报告人负责任务验收关闭
|
|
|
|
|
|
当然，团队规则远不止这几条。你要打造自己团队内部的规则，并且反复地强调规则，帮助大家养成习惯。这样一来，你会发现，**研发效率提升和自组织团队都会慢慢成为现实**。
|
|
|
|
|
|
除此之外，**你也不要高估人的主动性，期望每个人都能自觉地按照规则执行**。所以，定期和及时的提醒就非常必要。比如，每天增加定时邮件通知，告诉大家有哪些需求需要验收，有哪些可以上线发布，尽量让每个人都明白应该去哪里获取最新的信息。
|
|
|
|
|
|
另外，每次开周会时，都要强调规则的执行情况，甚至每天的站会也要按需沟通。只有保持短促、高频的沟通，才能产生理想的效果。
|
|
|
|
|
|
## 产品运营策略
|
|
|
|
|
|
关于产品运营策略，“酒香不怕巷子深”的理念已经有些过时了。想要一个产品获得成功，**团队不仅要做得好，还要善于运营和宣传，而这又是技术团队的一大软肋**。
|
|
|
|
|
|
开发团队大多只知道如何实现功能，却不知道应该怎么做产品运营。往往也正因为如此，团队很难获取用户的真实反馈，甚至开发了很多天才的功能，用户都不知道。产品开发变成了“自嗨”，这肯定不符合产品设计的初衷。
|
|
|
|
|
|
考虑到这些，我们在平台运营的时候，也采取了一些手段。我想提醒你的是，**很多事情其实没有没有多难，关键就看有没有想，有没有坚持做**。
|
|
|
|
|
|
比如，你可以建立内部用户沟通群，在产品初期尽量选择一些活跃的种子用户来试用。那些特别感兴趣、愿意尝试新事物、不断给你提建议的都是超级用户。这些用户未来都是各个团队中的“星星之火”，**在项目初期，你一定要识别出这些用户**。
|
|
|
|
|
|
另外，每一次上线都发布一个release notes，并通过邮件和内部沟通群的方式通知全员，一方面可以宣传新功能，另一方面，也是很重要的一方面，**就是保持存在感的刷新**。你要让用户知道这个产品是在高速迭代的过程中的，而且每次都有不一样的新东西，总有一样会吸引到他们，或者让他们主动提出自己的问题。
|
|
|
|
|
|
在用户群里面，注意要及时响应用户的问题。你可以在团队内部建立OnCall机制，每周团队成员轮值解决一线用户的问题，既可以保证问题的及时收敛，也能让远离用户的开发真真切切地听到用户的声音。这样的话，在需求规划会和迭代回顾会的时候，开发就会更多地主动参与讨论。
|
|
|
|
|
|
以上这些都是比较常规的手段，在我们的产品运营中，还有两个方法特别有效，我也推荐给你。
|
|
|
|
|
|
平台运营就跟打广告是一样的，越是在人流最大、关注度最高的地方打广告，效果也就越好。每个公司一般都有类似的首页，比如公司内部的技术首页、技术论坛、日常办公的OA系统等等，这些地方其实都会有宣传的渠道和入口。**你要做的就是找到这个入口，并联系上负责这个渠道的人员**。我们的产品就一度实现了热门站点的霸屏，宣传效果非常明显，用户量直线上升。
|
|
|
|
|
|
|
|
|
|
|
|
另一个方法有些取巧，但对于技术团队来说，也非常适用，那就是**通过技术分享的渠道来宣传产品**。
|
|
|
|
|
|
相信每个团队都会有定期的技术分享渠道，或者是技术公众号等，**你可以把平台的核心技术点和设计思想提炼出来，拟定一个分享话题，并在内部最大范围的技术分享渠道中进行分享**。
|
|
|
|
|
|
很多时候，单纯地宣传一个产品，很多人是“不感冒”的。但是，如果你在讲一些新技术，并结合产品化落地的事情，对技术人员的吸引力就会大很多。所以，**换个思路做运营，也是提升产品知名度的好方法**。我把我之前总结的产品运营渠道和手段汇总成了一幅脑图，也分享给你。
|
|
|
|
|
|
|
|
|
|
|
|
## 团队文化建设
|
|
|
|
|
|
最后，我想再跟你简单聊聊团队文化建设的事情。毕竟，无论什么样的工具、流程、目标，最终都是依靠人来完成的。**如果忽略对人的关注，就等同于本末倒置，不是一个成熟的团队管理者应该做的事情**。我给你分享我的两点感受。
|
|
|
|
|
|
**1.让专业的人做专业的事情**
|
|
|
|
|
|
很多时候，千万不要小看专业度这个事情。任何一个组织内部的职能都需要专业能力的支撑，这些专业能力都是量变引发的质变。
|
|
|
|
|
|
我举个最简单的例子，你还记得我在前面提到的0.2版本的原型草稿吗？实际上，到了0.3版本，引用前端工程师话来说，“原型做得比系统还漂亮”。这是为什么呢？难道是我这个“半吊子”产品经理突然开窍了吗？
|
|
|
|
|
|
显然不是。其实答案很简单，就是我去找了专业产品经理做外援，让他帮我改了两天的原型图。对于专业的人来说，这些事情再简单不过了。
|
|
|
|
|
|
找专业的人来做这些事情，不仅可以帮助你快速地跨越鸿沟，也能留下很多现成的经验，供你以后使用，这绝对不是一个人埋头苦干可以做得到的。
|
|
|
|
|
|
不仅是产品方面，技术领域也是一样的。**我们要勇于承认自己的无知，善于向别人求助，否则到头来，损失的时间和机会都是自己买单，得不偿失**。
|
|
|
|
|
|
**2.抓大放小，适当地忽略细节**
|
|
|
|
|
|
在协作的过程中，团队总会在一些细节上产生冲突。如果任由团队成员在细节上争论不休，久而久之，就会影响团队之间的信任感。这个时候，就需要引导团队将注意力集中在大的方向上，适当地暂缓细节讨论，以保证团队的协作效率。
|
|
|
|
|
|
比如，一个业务逻辑是放在前端处理，还是放在后端处理，结果并没有太大区别，说白了，就是放在哪儿都行。但是，前端同学会坚持认为，逻辑处理都应该由后端来解决，以降低前端和业务的耦合性，这样说也没有错。可是，后端同学也会有自己的想法，比如针对前端拦截器的处理机制，后端到底要不要配合着返回前端要求的返回码，而不是直接抛出http原始的返回码呢？
|
|
|
|
|
|
类似的这些问题，没有谁对谁错之分，但是真要是纠结起来，也不是一两句话就能说清楚的。
|
|
|
|
|
|
这个时候，就需要有人拍板，选择一条更加符合常规的方式推进，并预留出后续的讨论空间。甚至，为了促进多地合作，自己人这边要适当地牺牲一些，以此来换取合作的顺利推进。这样一来，你会发现，有些不可调和的事情，在项目不断成功、人员不断磨合的过程中，也就不是个事情了。
|
|
|
|
|
|
## 总结
|
|
|
|
|
|
在这一讲中，关于如何开发产品，可以说，我是把自己在过去几个项目经历中的总结倾囊相授了。
|
|
|
|
|
|
其实，就像我在讲“[DevOps工程师需要的技能](https://time.geekbang.org/column/article/151398)”中提到的那样，软实力（比如沟通协作、同理心、持续改进等）对促进产品快速迭代开发演进有着重大的作用。作为非专业产品经理，我也在慢慢地积累自己的产品心经，有机会再给你好好聊聊。
|
|
|
|
|
|
你可能还在想，最终千人的目标是否实现了呢？我想说的是，有些时候，真实生活比故事还要精彩。
|
|
|
|
|
|
就在预订目标的倒数第二天，平台用户只有997个。当时，我跟同事吐槽这个数字，他们说要不要拉几个用户进来，我说：“算了吧，随它去吧。“结果你猜怎样？在当天周五下班的时候，我又去平台上看了一眼，不多不少刚好1000个注册用户。当时我的第一感觉就是，**要相信，当我们把自己的全身心和热情都灌注在一个产品的开发过程中时，美好的事情会自然而然地发生**。
|
|
|
|
|
|
## 思考题
|
|
|
|
|
|
你对这一讲的哪部分内容印象最深刻呢？你有什么其他有助于产品快速研发落地的观点吗？
|
|
|
|
|
|
欢迎在留言区写下你的思考和答案，我们一起讨论，共同学习进步。如果你觉得这篇文章对你有所帮助，也欢迎你把文章分享给你的朋友。
|
|
|
|