02.创业团队怎么实现想法？

公司级的软件过程实践系列文章，请参见连接。

前提

本文为《大型网络应用全景图》的续编。也是为了帮助各种想转型，各种想进入互联网行业的人们提供一个简单的对比。让各位了解一下进入需要考虑哪些东西，怎么样选择团队的搭建等等内容。

举几个例子：

• 滴滴的第一版

  在百度上一搜就可以知道滴滴第一版的事情。简单总结一下在滴滴刚起步时需要一个软件团队来帮忙实现程维的想法。程维想的是又快又好又便宜的上线并验证想法，软件团队想的是付出多少就会有多少回报，软件团队的成本是比其他行业高的多的。所以虽然钱花出去了，东西有了。最终落了个最悲惨的结局。

• 创业团队技术负责人带走整个团队

  前一段时间听一个朋友说，他们的团队技术负责人在上线的前一周离职了把整个技术团队都带走了。具体原因就不说了，大概说一下情况，一个金融行业的人想出来做一个面向最终用户的商品推荐平台，运营的人说如果产品上线，一周内可以推广10万人使用。这个创始人说上线时可以引入2000个高端品牌。我相信这是一个非常好的项目，但是忽略了软件研发是需要投入的。简单分析：产品是有自己的运营渠道的，可以进行很快的推广。创始人是经过了很长时间的走访调查的才能积累这么多的品牌。软件研发人员就是被招进来立马就要做出来可以支撑10万人系统的。凡是都是需要一视同仁的，运营经过多长时间积累下的渠道，创始人是经过多长时间积累的想法与品牌。研发也需要经过很长时间的搭建，才能搭建出一套完整的系统的。

• 小公司为了省成本被骗

  大概说明一下前因后果。公司从外面请一个团队帮忙实现想法，想法实现了。因为小公司不懂整体的开发与交付过程。所以在项目交付时没有交付任何形式的文档，代码的内容。项目就直接上线，并开始运营。在前一段时间的运营过程中还是比较好的，公司请团队修改，添加功能都还是比较好。后来因为各团队运营不善，项目修改与添加功能迟迟不能支持。公司只能一直付费，然后进行功能的添加。然后，后来还听说团队在代码内加了限制，限制系统上的用户数。被威胁不付费的话就不要在想使用。（这个绝对不可能是研发人员赶出来的，肯定是一些城府很深的业务人员要加的）。

所以，团队肯定是自己组织好，但是自己组织没有把控力。可能被技术负责人直接整团队带走。总结一下可以说：就像其他行业(如：建筑设计，药品研发，芯片制造)一样，软件研发不是谁想做就能做的。但是，软件研发也有它自己的特点，它需要跟各个行业结合才有价值。所以，不管在什么样的情况下双方只需要做到诚而不欺即可达到最好的发展。

写这篇文章就是为了解决这些现象。就有可能会出现一些人会怀疑说，你写了这些，谁还会找你咨询，找你做实现？

1. 我遇到的事情也是比较多了。遇到各种各样的不靠谱的事情，所以，想在这里劝解一下各位想进入互联网行业的人。不要轻易的进入，如果要进入，还是要考量清楚之后在进入。
2. 我相信世间还是好人多的。不要被骗，也不要骗人。
3. 知识是需要输出的。没有输出，就没有意义。并且你的一点点输出说不定哪天就能为整个行业的提升做出巨大的贡献。

在本文中会对比使用外部力量来帮助实现和自己组织团队之间的区别、不同等内容。这里不会具体把两个的成本列出来，因为成本是显而易见的。在这里更多的讨论的是团队背后的事情，这些也是为了让产品(项目)能更长远更好的发展的一个前提。

下面会以项目制（外部力量帮助）和产品制（自己组织团队）这两种方式在各个事务上的对比描述各自的优缺点。其中涉及九个大方向，每个方向都会有具体的说明。并在最后会对这九个方向进行一个大致的总结。下面让我们One By One的看一下这几个方向的内容。

目标

每一个人在做任何事情之前肯定要知道目标是什么，用目标来知道我们的具体实施过程。所以，一个团队或者一个公司肯定也是有自己的目标的，用这个目标指导项目团队管理，实施过程管理等等的软件过程管理工作。下面分别说明不同团队在目标上的不同：

• 项目制的目标：

1. 在需求方规划的基础上，需求放将规划的一部分交个项目方进行实现。由项目方为软件客户解决某方面的问题；
2. 软件开发公司与软件使用公司项目合作，达到双赢的目标；
3. 项目方可以在实现过程中积累行业经验，为深入行业内部做前期工作；
4. 在实施过程中可以对项目方自己的业务体系、技术体系、咨询体系、管理体系进行不断的升级与优化。

• 产品制的目标：

1. 解决行业中的问题，并通过这个途径完成项目；
2. 将系统服务运营起来，并实现盈利；
3. 为客户提供更好的服务，提升客户满意度；
4. 形成完整的产业闭环，从产业闭环内赚取利润。

• 总结：

1. 从目标上就可以看到项目外包和自研项目的主要区别在于项目制时的软件实施公司更注重自身的成长与发展啊。产品制公司更注重产品是否能上线，能吸引客户，能够盈利。
2. 在软件研发过程成需要有很强的业务规划能力和软件过程把控能力。不是不经过长期训练就可以实现对软件的研发、运营、运维的整体认识；
3. 这里隐藏一句话。如果有兴趣可以加我微信，我可以单独发给你。

产品规划

目标明确之后，接下来就要对产品进行规划。本阶段中所有的内容，在二流及以下的项目制团队中都不会有涉及。除非像一流的项目制团队或者咨询公司中才会有。例如：ThoughtWorks，埃森哲，IBM，HP等等。

• 产品规划

产品规划是指产品规划人员通过调查研究，在了解市场、了解客户需求、了解竞争对手、了解外在机会与风险以及市场和技术发展态势的基础上，根据公司自身的情况和发展方向，制定出可以把握市场机会，满足消费者需要的产品的远景目标（Vision）以及实施该远景目标的战略、战术的过程。

• 阶段规划

在信息系统架构设计阶段，确定主要的信息类型和处理这些信息的应用系统。在本阶段有两个主要的步骤，数据架构设计和应用架构设计，二者既可以依次开发，也可以并行开发。核心内容为：IT系统如何满足企业的业务目标；信息以及信息之间的关系；应用以及应用之间的关系。

• 运营模式

一般来说，运营的目标不同，基于目标的手段也就不一样。对一个产品来说，基本的运营手段至少包括三种：内容运营，活动运营和用户运营。

运营模式

内容运营是最古老的运营手段之一。通过内容去打动用户，以内容为主的产品会更具黏性，媒体产品就是一个非常典型的内容产品。包括微博也是，微博现在已经成为了一个通过内容去打动用户的产品，所以对新浪微博来说，内容运营是非常重的一块。

一般来说活动运营有两个目标，一个是结合市场部门需求，起到吸引新用户的作用；另一个则是结合用户运营需求，起到活跃用户的作用。做一个活动运营（或者称之为策划），我们更关注的应该是执行过程的细节，并通过活动的投入产出来衡量活动效果。

• 用户验证

用户体验需求

用户体验（User Experience，简称UE/UX）是用户在使用产品过程中建立起来的一种纯主观感受。但是对于一个界定明确的用户群体来讲，其用户体验的共性是能够经由良好设计实验来认识到。计算机技术和互联网的发展，使技术创新形态正在发生转变，以用户为中心、以人为本越来越得到重视，用户体验也因此被称做创新2.0模式的精髓。在中国面向知识社会的创新2.0——应用创新园区模式探索中，更将用户体验作为“三验”创新机制之首。

• 企业运营

需要进行企业内部的运营管理。使用各种各样的方式进行运营过程管理，产品过程管理，实施计划管理等等企业运营管理过程。

• 总结

产品制公司需要有很强的业务支撑能力，项目才能真正的进入实施阶段。需要有业务分析能力，才能形成完整的业务闭环。需要有完整的企业内部流程管理，才能真正的驱动开发过程。所以，这些内容不可能交给一个项目制公司去代管。需要有产品制公司整体的想法与过程才可以真正的支撑起来项目团队与运营团队。

需求调研

不管是项目制还是产品制，跟研发团队沟通时都需要SMART原则下的项目需求。因为这一步已经进入视线阶段了，如果需求仍然不够明确那研发团队做出来的东西肯定和你想的不一致。这个时候不要怪研发团队怎么能这样，这是因为你自己没有说清楚。所以，需要进行业务调研、业务分析、业务设计工作。

• 业务调研

让产品经理、研发团队充分的理解业务的目标，业务过程的一个过程。然后产品经理会根据了解的内容进行业务分析并进行业务建模工作。

• 项目制

  1. 在业务调研过程中需要给项目制团队一个明确的需求边界。正如产品规划中所说明的，项目团队不会为产品做整体规划。所以，产品团队需要有计划性的划分出来一块并进行交给项目制团队进行实施工作。
  2. 在实施过程中项目制团队会需要与业务专家进行沟通、学习。以方便了解业务的内容。
  3. 项目制团队在进行项目调研时会有非常明确的方向，并有针对性的跟客户沟通业务边界内的内容。
  4. 项目制团队面向的客户为产品团队，不是产品团队的最终用户。
  5. 项目制团队中的业务边界是不可以逾越。因为在这方面的投入产品团队是不会做响应的费用的。

• 产品制

  1. 在进行业务分析之前，产品制团队只能拿到一个业务方向。业务方向可以确定产品大致需求。需求部分不是很明确。
  2. 在产品制团队中，最主要的客户是最终使用系统的用户。所以产品制团队需要根据市场反馈再进行项目业务方向的调整。
  3. 在产品制公司内部人人都是业务专家。降低业务专家与软件人员的沟通成本。
  4. 产品制的团队会为了收集客户需求而组织各种各样的形式的最终用户调研：
     1> 在线问卷调查
     2> 线下有偿问卷
     3> 调查优惠券
     4> 客户投诉、反馈
     5> 等等

• 业务分析

• 项目制

  1. 针对项目级进行业务的分析与设计工作。项目的业务目标就是整个实施过程中的目标。
  2. 针对项目进行业务设计工作，进行项目集成的分析与设计工作。
  3. 分析结果为形成业务系统中的闭环，并稍作考虑形成业务体系内的闭环。
  4. 产品团队需要对项目团队设计出来的业务系统进行评审，看是否满足业务的需求。通过评审后才能进入实施阶段。

• 产品制

  1. 针对公司的业务方向，配合行业内的情况进行分析与设计。
  2. 使用完整的企业架构方法论进行企业的业务的架构设计，如：ToGAF
  3. 形成业务的标准化的企业流程与规范，更好的满足企业的潜在需求

• 总结

1. 项目制在软件实施过程中的目标性更强一些，可以推动项目真正的向前进。从某个侧面推动整个产品的不断前行。
2. 产品制的计划更强一些，可以保证在为公司的业务发展有正确的方向。可以持续的去优化，改善系统。

投入评估方法

在企业管理过程中比较重要的是对人财物时的管理工作。针对于软件研发过程也是适用的，但人不是一般意义上的人。这里的人是指由专业技能的人，可以真正在软件研发层面上解决问题的人。下面具体说明投入评估的区别。

• 特点

• 项目制

  1. 项目有明确范围，并且已经进行了前期的调研和分析工作。分析出的业务模型就可以是工作量，并且可以评估出实施需要的资源、时间等等内容。
  2. 在项目制团队中不会针对运营过程中的投入进行评估，基本上也不会涉及运营过程中的工作。并且不会对其进行评估
  3. 评估投入时会考虑与业务专家进行沟通与确认的成本，即需求调研的投入成本。

• 产品制

  1. 因为产品制支撑时需要的基础设施都是由公司统一管理的，所以很多基础设施都不会进行相关的评估工作。只需要用时随时申请即可。
  2. 在产品制的项目中，因项目是一个长期投入的过程。所以不会针对事务进行阶段性投入评估。
  3. 在产品制公司内部，不会评估出具体需要投入的费用。因为费用就涉及到人力费用、设施费用等等，这些其实很多时候多直接归入到公司运营成本里了。
  4. 基本上只会在项目启动阶段会进行项目启动时需要的投入的评估，以方便启动项目。
  5. 在项目运营过程中会有人、物、时的各种调整。不是显式的调整，更多的是隐式的调整。

• 评估方法

• 项目制

  1. 根据经验进行工作量的评估。
  2. 根据工作量的多少评估费用。
  3. 按照客户的要求，进行倒排的方式安排计划以及投入人员。

• 产品制

  1. 形成团队战斗力，并根据战斗力进行评估。
  2. 对其他投入使用各种评估方法进行相关的评估，例如：设备要求，性能要求。
  3. 比较依赖于对团队的长期输出的期望以及能力的考量。

• 评估内容

这里说明评估过程中项目制团队关心的内容和产品制团队关心的内容的不同点。

• 项目制

  1. 业务咨询：即是否需要出动咨询师，咨询师的投入时怎样的。
  2. 软件实施：软件实施的功能范围，非功能需求的工作量。
  3. 运营咨询与实施：项目运营的咨询师的投入，以及咨询师策划的内容的实施投入。

• 产品制

  1. 人员投入：进入项目的各项人员，产品经理，项目经理，研发人员，测试人员，运维人员，运营人员等。
  2. 时间投入：是否可以按照计划进行软件实施、运营活动过程。
  3. 资源投入：硬件成本，活动成本等。

• 总结

1. 项目制的各项都比较明确，可以根据明确的目标进行明确的评估工作。总体来说会按照人员投入情况进行评估。
2. 产品制整体内容不是很明确，只能保证某段时间内需要这样的功能或业务。也不会进行相应的评估工作。所以需要长期支撑整体团队的要求。

实施过程

上面规划也做了，设计也完成了，也对投入没有什么问题的时候。就开始进入实施过程中。实施过程如果是不理解软件工程的人就会认为招人去做就OK了。其实没有那么简单，举个简单的例子很多地方都会用到齿轮，齿轮是不是要考虑材料的强度，韧性才可以知道材料是否合适，坯料来了之后加工时，是否需要严格控制误差尺寸。要不放不进去，不能和其他齿轮咬合。基本上这两项可以定义一个齿轮的质量了，但是软件中的很多质量都是隐形的，看不到的。这个东西就没有办法去实施了。这里就对这些内容加以说明。

• 实施计划

• 项目制

  1. 制作实施计划的目标是为了确保项目按时按点上线。
  2. 在实施过程中会针对项目的实施业务与进度考虑。
  3. 实施计划需要有明确的截止时间，以及实施范围。交付内容，结款方式都需要明确。
  4. 在制作实施计划时需要明确项目运营支持系统的计划、需求、评估、费用等等。

• 产品制

  1. 产品就是为了抢占市场先机的MVP先上，所有的东西都是为了这么目标而服务。
  2. 产品上线后，针对市场反馈完成的中后期，进行MVP项目的持续优化与完善工作。
  3. 产品制的计划时漫长的，所以，需要不断的增加新的业务方向，并循环上面两步。
  4. 需要对运营支持系统一起进行考虑并体现在实施计划中。

• 质量管理

• 项目制

  1. 为了能够把项目快速交付，省去了很多事情。（好像这句话是个悖论，具体怎么悖论我就不说了。）
  2. 不考虑长期质量的问题。为长期的数据存储，容灾，备份等考虑较少。
  3. 不考虑长期投入的问题。为了降低长期投入可以制作回归测试，自动化测试等方式。

• 产品制

  1. 注重系统可靠性，以防止上线后产生故障问题。
  2. 注重系统可用性，以防止上线后产生不可用问题。
  3. 注重系统的安全，以防止线上数据被窃取，商业秘密泄露等问题。
  4. 上线的系统需要有良好的质量属性，并有很好的用户体验。
  5. 考虑长期运行过程中的问题，并进行持续的跟进与解决。

• 验收

项目在到达上线水平时，需要考虑是否允许上线。上线后的部署情况等内容，所以需要进行详细的考量工作。以下说明两种不同的方式的考量内容：

• 项目制

  1. 需要确定的验收方法以及交付过程。以及需要交付的各种资料。
  2. 需要确定参与验收的业务人员，以及确定验收工作中的核心流程。
  3. 需要确定验收用例通过多少后才可以整体通过验收，并规定验收测试问题中的修复时间。

• 产品制

  1. 产品制是一个不断改进，不断根据使用者的情况做变化的产物。所以验收需要有最终客户验证。可以构建运营支持系统方便进行AB测试。
  2. 产品制公司内部一般都会形成质量标准，所以，产品制团队的产品需要遵循企业的质量标准。

• 总结

实施过程主要的内容是将计划和设计实施落地为一个真正的可运行的项目。在这个过程中不管是那个阶段，那个团队欠的债最终都是要还的。

团队

正如本文开始时候的例子，需要对技术团队有把控的能力。在软件研发与运营过程中最主要的就是团队需要控制。这里说明团队控制的内容。

• 团队目标

• 项目制

  1. 快速开发，快速交付为项目做出贡献。
  2. 注重个人输出，快速的输出才可能把软件团队运营起来。
  3. 需要对项目进行快速交付。

• 产品制

  1. 需要考虑长期实施计划，需要有针对性的实施。进行快速决策的支持等。
  2. 进行项目中人员项目备份。产品是需要持续运营的，所以项目成员需要稳定。
  3. 进行全功能团队组织。保证项目运营过程中可以持续的进行输出。

• 团队基础情况

• 项目制

  1. 每个项目都需要构建一套团队基础设施。
  2. 每个项目的团队基础体系都不相同。

• 产品制

  1. 公司制度规定的基础设施的操作过程。
  2. 公司的团队管理规范。例如：活跃网络公司内部使用故事点评估工作量，评估Bug率的做法。

• 总结

团队的组织方式不一致。产品制团队更注重稳定、可靠，注重持续的进展以及输出。项目制的团队更加注重快速输出，快速解决问题。

运营支持

运营是项目上线后非常重要的一件事情，在这个阶段项目制团队几乎不参与。这个阶段的内容需要有运营团队+产品经理来完成。

• 运营系统

• 项目制
  1. 项目制的团队会把运营系统的需求也作为一个独立项目进行实施。
  2. 运营的项目会根据客户主导方式进行实施。
• 产品制
  1. 根据产品线的实施过程申请公司运营资源进行支持。
  2. 根据业务的特点定制化运营支持系统。

• 运营需求

• 项目制

1. 针对每一个阶段，每一个支持进行立项。并收取费用。

• 产品制

1. 产品经理收集运营数据，并针对运营数据进行分析得出需求。对这些需求进行分析与设计。
2. 针对内部管理需求进行开发。对这些需求进行分析与设计。

• 总结

项目制需要独立立项，独立的完成。产品制在项目开始阶段就规划好，并持续执行。

技术

软件过程中一个比较重要的点是技术，技术是整个项目的支撑。这里对比一下项目制和产品制技术的特点。

• 对比

• 项目制
  1. 一般是业界流行什么样的技术，项目制团队会招什么样的技术人员进入。
  2. 在项目中使用到的技术，从不同的团队过来。
• 产品制
  1. 根据产品的需求对技术进行选型，并形成体系化使用技术的方式。
  2. 在产品中不同的人负责不同的技术，并在业务层面上进行合作。

• 总结

项目制公司的技术，更加针对通用型的业务。产品制的技术需要有全方位，全方位的储备以及使用。因为在不同的场景下需要不同的技术来实现。

公司对比

最主要的是公司会根据以上的对比进行各项事宜的指导工作。所以，这些就是不同的类型的公司行事风格的基础。有些是有项目制上遇到一些事情，将就一下就过去了。因为不涉及到运营部分，所以，之后发生的问题也找不到这批人。但是，在产品过程中，现在可以将就一下。但之后发生了问题肯定还是需要解决的。

从某些角度讲，从传统行业进入软件行业是比较困难的一件事情。因为所有的东西都跟数学，逻辑有关。很多人都无法理解这个里面的内容，并且在实施和团队管理过程中的投入也比传统行业要巨大的多。如果在公司内部可以按照这种方式进行行事会事半功倍。在外部和公司合作，就需要考虑这些情况会不会影响自己的计划。

这是我第一次写没有任何插图的文章，不过我还是针对这个文章整理了思维导图。如有兴趣可以加我微信，我把思维导读发给你。

他人意见

• 高人的看法：

说我的几个看法吧:
1、首先产品的开发是要在公司战略的支撑下的，产品的生命周期内会有几个项目的生命周期组成
2、产品需要更快的完成业务闭环，去市场验证，反复修改，获得回报，Product Owner是一个产品重要的角色，通常他是项目中的内部客户
3、产品的开发周期较长，涉及版本较多，所以对产品的版本的维护、hotfix、SP等后期的维护的考虑在开发中要有所体现。同时产品生命周期长，为了持续保持产品的质量，UT，AT的比重要根据产品的周期和规模，不断加强。
4、产品开发中要考虑营销模式、运维、知识库等多种因素

我感觉产品制其实就是高度标准化的项目制。产品制目标就是实现项目聚焦，增加可复制性。

参考

运营有三种模式，你懂几种？
产品规划
聊聊用户体验的五个要素
良好的用户体验3个特点和实现4个层次
系统架构设计方法论——TOGAF