本节内容可能不会很长，但是还是希望尽可能把这个环节重要的骨架勾勒出来。
有一个经典的问题是：“如果你是一个投资人，要投资一个项目，核心是看什么？项目还是团队？”。与之对应的一个问题是：“如果你是一位创业者，创业的基石是一个独特的项目还是一个优秀的团队？”
当然这种二选一的问题往往都只强调了某一个方面，并没有标准答案，有的人会选项目，有的人会选人（团队）。本节要讨论的是在一个企业里面“如何构建一个有效的能做产品的团队所需要的不同角色的人”，这个问题。
顺带的，以我当前所在的工作环境，这个问题天然地穿插了一个“远程工作”的上下文，它不是主要的问题，但是在里面是一个因素。
一个完整的能做产品的团队需要的不同类型的人包括哪些？这个问题是比较好回答的，从一个MVP的角度开始变化。
如果是一个单人项目，只需要一个人把事情都做了即可。
如果拆分前后端，大概2个人就够了：
如果需要UI设计，增加1个UX即可：
+UX(0.5)如果后端复杂起来，增加1个即可：
+UX(0.5)如果项目不只一个，前端也需要多点，增加前端。
+UX(0.5)随着项目的演化，后端数据从简单的OLTP演变成OLTP+OLAP，日常开发开始有OLAP数据处理的支持，需要增加OLAP支持（理论上后端也可以兼做）。OLAP系统本身是一个X个人维护的Team，投射到项目上的支持人员为1。
+UX(0.5)+ OLAP(1)随着项目的演化，后端数据处理需要搜索/推荐服务，产品开始变成流量漏斗模型。搜索/推荐本身是一个X个人维护的Team，投射到项目上的支持人员为0.2，因为它本身变成了一个产品，具体的业务产品是作为数据插件接入和接出它的服务。
+UX(0.5)+ OLAP(1)+ 搜索/推荐(0.2)随着项目的演化，开发范式的转移，特别是移动互联网时代兴起的信息流万金油模式，个性化推荐显得特别重要，OLAP部分的工作和这个可以结合。
+UX(0.5)+ OLAP(1)+ 搜索/推荐(0.2)+ 算法(1)随着项目的演化，开发范式的进一步转移，需要AI技术的支持。AI技术本身也会是一个x个人的Team。投射到项目上的支持人员可能是2+，此时合并掉算法人员。
+UX(0.5)+ OLAP(1)+ 搜索/推荐(0.2)+ AI(2+)一个相对完整的研发人员配齐模式就成型了，但是一个项目还是要有产品经理，有运营，假设各自根据情况配齐：
+UX(0.5)+ OLAP(1)+ 搜索/推荐(0.2)+ AI(2+)这个就相对可以跑起来飞轮了，保证每周能排好P1-P2任务，持续稳定地运行。这样的一个软件小组在企业产研体系里相对独立，但是在整个产研体系里处于一种「插件」模式。例如运维是整个产研共享的。运维本身也是一个x人组成的Team。投射到项目角色上：
+UX(0.5)+ OLAP(1)+ 搜索/推荐(0.2)+ AI(2+)运维虽然只配置了0.5 ，但是运维是不可或缺的，现代软件开发里一个工程师写的代码在各种环境里运行，这些环境是各种异构的「云」环境，每个项目也都需要有开发/测试/正式环境。因此一个项目的研发在一个企业的产研体系里，有大量的环境需要从运维那里支持：
此外，测试团队也是一个x个人的Team，投射到项目上也是平均一个人
+UX(0.5)+ OLAP(1)+ 搜索/推荐(0.2)+ AI(2+)上面的分解实际上是一个事后诸葛亮模式。在一个企业里，从零开始配齐一个产品线的最小研发团队有许多实际的困难。
一个实际的例子可能是这样的。
软件产品是会腐化的，这个是写在软件工程教科书里的定律。一个产品从发布开始，就需要持续不断地版本迭代和演化，否则随着时间的流逝，它就会逐渐腐化。腐化有很多具体的表现：
还可以举很多例子，每个产品从发布的第一天开始就要警惕「半衰期」，不断地演化，摆脱平庸，努力做到比同行好x倍的用户价值增加。
因此，产品开发中人要保证：保证一个稳定持续发力的研发团队持续地迭代产品的P1优先级功能。这听上去应该是很自然的事情？但是软件公司里经常这点也不能保证。
->留存(uv/pv)->付费转化，动作->效果->困难->方案->SOP等等），如果观察了几周后数据不怎么样就失去了信心，难以建立起一流的运营水准，研究清楚飞轮里缺失链条勾连的「技术」。
->发布->运营->产品->研发…，建立起这样的飞轮的心智模型，每个角色需要不断去理解角色之间的差异和关联。例如产品和运营的核心目标应该是不同的，但是需要相互衔接。例如研发如果不直接接触用户，不理解产品，就会做「定义清晰但是没有彻底解决用户需求」的功能…软件项目需要在市场上获得成功才能存活并迭代下去。有一个著名的观点是：
从这角度，企业软件开发都是天生「短视」的，一个能持续存活的项目在配齐人员后就忘事大吉了？No，风险从一开始就存在，万事万物都有定时器。Team在建立后，它的定时器就开始运转了，只不过不同体量的公司，对半衰期的耐受度不同。
一个项目无论出于情怀，理想主义，还是出于奇思妙想，又或者出于实用主义，功能主义，工具主义，数据驱动主义。在半衰期范围内，都要解决两个问题：
这两个风险点是核心风险点。这两个风险点，即是软件开发团队需要不断做P1优先级迭代的原因，也是软件开发团队稳定迭代的潜在杀手。深刻理解到这点，一个有目标感同时有危机感的软件开发团队如果成功化解了产品生命周期的初期的鸿沟，跨越过去，就可以为软件和软件开发团队赢得相对长期的时间。可能这也是为什么说一个软件开发公司的生命周期是18个月的原因之一。
上述过程和是否远程开发是正交的。有了前两节的基础，远程软件开发大体上面对上面的问题不会有非常大的困难。实际上，优秀的人组织在一起，是否远程都会体现出优秀。但是如果一般的人组织在一起，是否远程都会是一般的水平。
一个团队，如果每次加入的人都比平均水平高，那么这个团队就会整体水平越来越好，反之则是另外一个方向。这是其中一个维度，另外一个维度是要找到那些有热情的人，和对所做事物的技术和方向有判断力的人。
此外，互相的认可是重要的。远程软件开发，团队成员之间的互相结对解决问题是一个非常好的方式，结对解决问题需要双方都以释放善意，互相学习，共同解决问题为目标，基于协作建立的情感和共识，是比较牢靠的。而通过相对稳定的持续迭代，可以不断累计这种情感和共识，在这个基础上激发整体的潜能。
软件/软件开发/软件开发团队/远程软件开发团队，都是有生命周期的，本节简略从软件开发团队建立到可能遇到的困难/风险浅谈，作为远程软件开发过程的一个环节，以后也会随着实际经验的演化更新，下一次我们可以进一步谈下人的另外一些形态。
–end–