远程小组软件开发过程:人

Posted 2022-12-16 幻灰龙

本节内容可能不会很长，但是还是希望尽可能把这个环节重要的骨架勾勒出来。

有一个经典的问题是：“如果你是一个投资人，要投资一个项目，核心是看什么？项目还是团队？”。与之对应的一个问题是：“如果你是一位创业者，创业的基石是一个独特的项目还是一个优秀的团队？”

当然这种二选一的问题往往都只强调了某一个方面，并没有标准答案，有的人会选项目，有的人会选人（团队）。本节要讨论的是在一个企业里面“如何构建一个有效的能做产品的团队所需要的不同角色的人”，这个问题。

顺带的，以我当前所在的工作环境，这个问题天然地穿插了一个“远程工作”的上下文，它不是主要的问题，但是在里面是一个因素。

一个有效的能做产品的团队需要哪些人？

一个完整的能做产品的团队需要的不同类型的人包括哪些？这个问题是比较好回答的，从一个MVP的角度开始变化。

如果是一个单人项目，只需要一个人把事情都做了即可。

• Linus（1）

如果拆分前后端，大概2个人就够了：

• 前端(1)
• 后端(1)

如果需要UI设计，增加1个UX即可：

• 前端(1)
  • +UX(0.5)
• 后端(1)

如果后端复杂起来，增加1个即可：

• 前端(1)
  • +UX(0.5)
• 后端(2)

如果项目不只一个，前端也需要多点，增加前端。

• 前端(2)
  • +UX(0.5)
• 后端(2)

随着项目的演化，后端数据从简单的OLTP演变成OLTP+OLAP，日常开发开始有OLAP数据处理的支持，需要增加OLAP支持（理论上后端也可以兼做）。OLAP系统本身是一个X个人维护的Team，投射到项目上的支持人员为1。

• 前端(2)
  • +UX(0.5)
• 后端(2)
  • + OLAP(1)

随着项目的演化，后端数据处理需要搜索/推荐服务，产品开始变成流量漏斗模型。搜索/推荐本身是一个X个人维护的Team，投射到项目上的支持人员为0.2，因为它本身变成了一个产品，具体的业务产品是作为数据插件接入和接出它的服务。

• 前端(2)
  • +UX(0.5)
• 后端(2)
  • + OLAP(1)
• 数据
  • + 搜索/推荐(0.2)

随着项目的演化，开发范式的转移，特别是移动互联网时代兴起的信息流万金油模式，个性化推荐显得特别重要，OLAP部分的工作和这个可以结合。

• 前端(2)
  • +UX(0.5)
• 后端(2)
  • + OLAP(1)
• 数据
  • + 搜索/推荐(0.2)
  • + 算法(1)

随着项目的演化，开发范式的进一步转移，需要AI技术的支持。AI技术本身也会是一个x个人的Team。投射到项目上的支持人员可能是2+，此时合并掉算法人员。

• 前端(2)
  • +UX(0.5)
• 后端(2)
  • + OLAP(1)
• 数据
  • + 搜索/推荐(0.2)
  • + AI(2+)

一个相对完整的研发人员配齐模式就成型了，但是一个项目还是要有产品经理，有运营，假设各自根据情况配齐：

• 产品(1)
• 运营(1-2)
• 前端(2)
  • +UX(0.5)
• 后端(2)
  • + OLAP(1)
• 数据
  • + 搜索/推荐(0.2)
  • + AI(2+)

这个就相对可以跑起来飞轮了，保证每周能排好P1-P2任务，持续稳定地运行。这样的一个软件小组在企业产研体系里相对独立，但是在整个产研体系里处于一种「插件」模式。例如运维是整个产研共享的。运维本身也是一个x人组成的Team。投射到项目角色上：

• 产品(1)
• 运营(1-2)
• 前端(2)
  • +UX(0.5)
• 后端(2)
  • + OLAP(1)
• 数据
  • + 搜索/推荐(0.2)
  • + AI(2+)
• 运维(0.5)

运维虽然只配置了0.5 ，但是运维是不可或缺的，现代软件开发里一个工程师写的代码在各种环境里运行，这些环境是各种异构的「云」环境，每个项目也都需要有开发/测试/正式环境。因此一个项目的研发在一个企业的产研体系里，有大量的环境需要从运维那里支持：

• 权限申请
• 基本功能熟悉和使用
• 开发/测试/部署
• 问题诊断
• 性能分析

此外，测试团队也是一个x个人的Team，投射到项目上也是平均一个人

• 产品(1)
• 运营(1-2)
• 前端(2)
  • +UX(0.5)
• 后端(2)
  • + OLAP(1)
• 数据
  • + 搜索/推荐(0.2)
  • + AI(2+)
• 运维(0.5)
• 测试(1)

配齐一个产品线的最小研发团队有哪些困难？

上面的分解实际上是一个事后诸葛亮模式。在一个企业里，从零开始配齐一个产品线的最小研发团队有许多实际的困难。

一个实际的例子可能是这样的。

• 从数据层开始，构建一个最小的数据模型
• 围绕这个最小的数据模型，构建一组最小的API
• 围绕这组最小的API，开发一个最小的UI原型
• 围绕这组最小的UI原型，游说业务产品来做这个产品
• 产品设计了正式产品的MVP后，业务层前/后端开始开发，驱动数据层迭代。
• 最小产品发布后，业务产品可能跑去做别的事情了（经常发生），数据层在没有业务层支持的情况下反复演化/迭代数据层的模型和服务，或者直接在数据层可以和用户做很多扩展。

软件产品是会腐化的，这个是写在软件工程教科书里的定律。一个产品从发布开始，就需要持续不断地版本迭代和演化，否则随着时间的流逝，它就会逐渐腐化。腐化有很多具体的表现：

• 第一个版本的功能很惊艳，但是随着时间的流逝，人们对第一时间的经验过后，一开始忽视的功能缺陷会随着时间的演化而开始不满意，当不满意大于惊艳时，同样功能的用户价值就下降。
• 用户会发生迁移，第一波用户走了后，随着时间的流逝，第x波用户来了后，对于常规功能已经习以为常，产品需要不断支持新的特性才能增加用户的价值，从而增加产品的价值。
• …

还可以举很多例子，每个产品从发布的第一天开始就要警惕「半衰期」，不断地演化，摆脱平庸，努力做到比同行好x倍的用户价值增加。

因此，产品开发中人要保证：保证一个稳定持续发力的研发团队持续地迭代产品的P1优先级功能。这听上去应该是很自然的事情？但是软件公司里经常这点也不能保证。

• 研发可能随时被调去干别的更「优先」的事情。
  • 核心研发可能随时被调去干别的更「重要」的事情，就像失联一样，几个月不能为项目提供贡献。
  • 研发可能也因此会对项目没有 owner 感，每个项目都像是做外包一样的做，做了后好不好，用户反馈如何和他可能没有什么直接的关系。
    • 我们知道优秀的事物，需要投入情感，有了情感（关注），才会主动为它解决很多潜在的问题，从而事物（产品）也就逐渐有了生命。
• 运营可能随时被调去干别的更「优先」的事情。
  • 运营可能也会难以形成一种真正把飞轮跑成功的耐心，跑一跑流量漏斗（流量(uc/pv)->留存(uv/pv)->付费转化，动作->效果->困难->方案->SOP等等），如果观察了几周后数据不怎么样就失去了信心，难以建立起一流的运营水准，研究清楚飞轮里缺失链条勾连的「技术」。
    • 研发->发布->运营->产品->研发…，建立起这样的飞轮的心智模型，每个角色需要不断去理解角色之间的差异和关联。例如产品和运营的核心目标应该是不同的，但是需要相互衔接。例如研发如果不直接接触用户，不理解产品，就会做「定义清晰但是没有彻底解决用户需求」的功能…

配齐人员后的产品迭代面临哪些风险？

软件项目需要在市场上获得成功才能存活并迭代下去。有一个著名的观点是：

• 科研是将金钱转化为知识
• 软件开发是将知识转化为金钱

从这角度，企业软件开发都是天生「短视」的，一个能持续存活的项目在配齐人员后就忘事大吉了？No，风险从一开始就存在，万事万物都有定时器。Team在建立后，它的定时器就开始运转了，只不过不同体量的公司，对半衰期的耐受度不同。

一个项目无论出于情怀，理想主义，还是出于奇思妙想，又或者出于实用主义，功能主义，工具主义，数据驱动主义。在半衰期范围内，都要解决两个问题：

• 是否能解决用户增长问题？
  • 是线性增长的？还是指数增长的？还是组合增长的？
    • 互联网/移动互联网的指数级增长成功的都是少数的，大多数停滞在线性增长或者死亡。
• 是否能解决收益模型？
  • 是广告模式？付费会员模式？还是交易平台模式？增长曲线是怎样的？
    • 刚毕业的工程师可能要很久之后才会需要面对这个问题，或者很多工程师一直面对的是技术问题，不需要面对这样的问题，或者在一个小企业里工作不到半年都直接和这个问题的结果挂钩了，这都是有可能的，取决于所在的企业环境。
    • 在技术范围内的fullstack，从软件项目的大生命周期看来，都属于研发这个范围，不算完整的fullstack。

这两个风险点是核心风险点。这两个风险点，即是软件开发团队需要不断做P1优先级迭代的原因，也是软件开发团队稳定迭代的潜在杀手。深刻理解到这点，一个有目标感同时有危机感的软件开发团队如果成功化解了产品生命周期的初期的鸿沟，跨越过去，就可以为软件和软件开发团队赢得相对长期的时间。可能这也是为什么说一个软件开发公司的生命周期是18个月的原因之一。

远程团队的因素

上述过程和是否远程开发是正交的。有了前两节的基础，远程软件开发大体上面对上面的问题不会有非常大的困难。实际上，优秀的人组织在一起，是否远程都会体现出优秀。但是如果一般的人组织在一起，是否远程都会是一般的水平。

一个团队，如果每次加入的人都比平均水平高，那么这个团队就会整体水平越来越好，反之则是另外一个方向。这是其中一个维度，另外一个维度是要找到那些有热情的人，和对所做事物的技术和方向有判断力的人。

此外，互相的认可是重要的。远程软件开发，团队成员之间的互相结对解决问题是一个非常好的方式，结对解决问题需要双方都以释放善意，互相学习，共同解决问题为目标，基于协作建立的情感和共识，是比较牢靠的。而通过相对稳定的持续迭代，可以不断累计这种情感和共识，在这个基础上激发整体的潜能。

小结

软件/软件开发/软件开发团队/远程软件开发团队，都是有生命周期的，本节简略从软件开发团队建立到可能遇到的困难/风险浅谈，作为远程软件开发过程的一个环节，以后也会随着实际经验的演化更新，下一次我们可以进一步谈下人的另外一些形态。

–end–