Question

所以公司要给项目一个生存的环境，项目要给自己一个生存的逻辑。

如何构建项目的生存环境呢？

项目的生存环境与公司的项目管理体系有关，例如公司决定如何进行项目立项、审核、推动、考评等流程。这样的生存环境是一系列管理行为的总和，它与具体项目内部的运作方法没有直接的关系，但却实实在在地影响了这个项目的生存与状态。事实上，它也反映了公司对于产品、项目、团队三者的整体态度。

首先，公司是否基于产品建立了一系列的外围组织（或更为细致地说，“产品”作为一个市场化的基础条件是如何被定义、被评价以及是以何种形式作为公司运作的基础构件的），这是后续问题的基本前设。表 1-1 列出了三种需求类型 1 。

表 1-1　对三种软件产品定义及其需求类型的简单考察

下面，我们来分析这三种需求类型。

1. 若需求方是生产型企业（以下称为 A 型），需要的是业务生产系统，那么产品通常是一个软件产品包，开发方需要现场安装、部署、调试以及技术培训；从长期来看，开发方还需要提供版本计划、维护手册、作业限制以及应急方案等。这事实上也包括开发方与需求方是同一公司或公司的不同层次的情况。
2. 若需求方是一般的互联网用户（以下称为 B 型），需要的是一个在线功能，那么产品可能是一个线上网站，所有的产品构件都在开发方所能支配的服务器、机房等环境中运作，而使用功能的客户端可能是网络用户的 Web 浏览器，或者其他第三方网站通过 API 进行的访问。
3. 若需求方是离线的桌面软件用户（以下称为 C 型），需要的是一个能解决具体问题的功能性软件——这包括桌面操作系统、移动设备、手持终端等环境下的软件产品，那么产品的形式可能就是一个离线或在线分发的安装包，以及一些附属的构件（例如在线手册、在线升级或配套的工具软件）。

上述三种类型的产品定义、实现过程和交付方式都是根本不同的。例如对于 A 型，公司对产品的要求就是客户需用、能用以及符合客户的生产运行环境。如果客户现有的应用环境是 Java+Oracle DB，那么公司就必然是基于 Java+Oracle DB 来开发，项目所需的人力及与技术储备就都受到这一前提的限定，项目的评价自然就是产品订单，项目的立项依据就必然是业务人员接触到的市场信息与客户反馈——这些基本设定都依赖客户需求，而与开发方的技术能力与产品设计几乎完全无关。从公司整体上来看，应当是业务驱动型的组织结构最为合理，技术研发上的创新会少，技术实现上也会保守很多。

假定与 B 型来做一个比较，那么 B 型就并不一定适宜业务驱动。因为 B 型的业务部门可能会碰触不到确切的用户需求，以用户需求为核心依据的业务模式就会发生变化。反之，应从更大范围内来考虑以互联网用户行为为背景的产品推演，并关注基于业务链上下游需求的、功能性（或制约性的）产品设计。于是，在这样的背景下，面对需求问题，业务部门的形态将变成“观察－规划”型，而非（与 A 型类似的、传统含义上的）“收集－反馈”型。所以通常在 B 型产品的公司中，业务部门是以构建产品线为其核心工作方法的。进一步地，整个模式就会变成产品与产品线驱动，例如“产品”的定义就可能是子网站、多级域名或功能模块，项目的评价依据就会是上线下线、运行流量以及用户数量等因素。

所以，项目的生存环境首先依赖于产品定义与产品管理方法。进而，只有在公司内形成与 产品过程模型 相匹配的 项目过程模型 ，项目的生存问题才会有解。但不幸的是，大多数公司在对待这两个模型的做法上是有冲突的，尤其是在企业转型阶段——请尝试着考虑一下微软与谷歌在产品形态上的不同，以及微软公司在向后者转型中一些可能的障碍。所以，项目组并不一定总在“舒适”的环境中生存。也因此，当公司转型时既可能“砍掉”一些项目，也可能有一些项目自然地就消亡掉了。

产品与业务的规划，是公司为项目准备的生存环境。当我们人性化地来看待项目的生存问题时，这一环境正好决定了项目的价值观、归属感以及项目的基本道德伦理。例如，一个项目是否更好、更值得立项、更有效益，可以看成是项目价值观的问题；而一个项目是否觉得自己重要、受重视以及有前途，则就是一个归属感的问题。至于两个项目间的资源之争，是“掠夺”还是“奉献”，抑或是“有条件地相互合作”，那么就是一个基本道德伦理问题了。