4.5 需求与项目管理

大数据的规划、实施、运维本身就是一个项目，无论在企业的IT部门还是在大数据服务提供商中都需要超强的项目管理能力。这使作者想起了20世纪90年代末数据仓库（Data Warehouse）刚刚火起来的时候，美国政府部门、各大企业纷纷跳上了数据仓库的大篷车（Bandwagon），结果只有不到15%的成功率。其主要原因就是盲目跟风，缺乏对新型项目的管理能力。在大数据前行的路上，多一点反思，多一份冷静，或许能走得更远。

需求导致要求。面对需求，张三李四各有各的说法。作者在Intel公司工作期间，采用了一种做法：“漫天要价，就地还钱”。意思是说，来自前端市场的需求非常多、要求非常苛刻，通常会写在MRD（Marketing Requirement Document）中，也就是所谓的“漫天要价”。当拿到这个MRD后，我们所做的工作是根据现有的资源（Cost）、时间（Schedule）来进行排序（Scope），哪些是必需的（Must），哪些是有了挺好的（Nice To Have），哪些是不关痛痒的。对自己的了解，对市场的理解，对技术难度的判断，还有“2-8规则”，都在起作用。最后我们“就地还钱”，给出PRD（Product Requirement Document）。PRD就是后端和前端的合同，条款越细致越好。图4-31中的面积代表的是工作量，横轴是时间，可以看出，多数工作量花在了Exploration和Planning上。通常，应该由简到繁。

图4-31 大数据产品生命周期及创新的维度及要素

搞大数据就是要推出有意义的产品和服务。新产品和服务的推出一定要遵循其全生命周期的管理（图4-31中同时标出了创新的多个维度和三要素）。如果按照“园中有金”寓言中的做法去对待、管理大数据项目，可以保证，你的收获不会像寓言里所说的那样，因为作者在乡下种过果树。做好项目管理，要的是管理好需求，把握好时间点，合理调配资源，掌握好预算，有应对风险的策略，在两个铁三角（Scope-Schedule-Cost和Function-Performance-Cost）之间做好取舍。在大数据项目中组建团队、培养团队，拥有一支众中之众的团队，你的脑袋、你团队的脑袋就是最大的大数据。

大数据建设可能遇到的风险是多方面的。作者遇到最多的是“三不清”，即需求不清、目标不清、验收指标不清。这样的情况发生在银行、证券业，发生在制造业，也发生在所谓管理最好的企业。究其原因也可以理解，IT部门总是要跟风搞些新课题，大数据就在其中。我们能给出的建议是，以开放的心态学习或借鉴一下发达国家的经验，没有RFP（Request For Proposal，对应的接近的中文应该是项目指南），没有SOW，没有SLA的“项目”不要接。或者帮助客户一起明确RFP、SOW、SLA。否则，你会做的不开心，甚至赔钱。最重要的是，运用常识、从小做起、做慢点、一次做好（Use common sense, start small, go slow, do things the first time right）。这也是我们应对一个新生事物应有的态度，特别是大数据。图4-32是大数据资本性投入和研发迭代成本的剪刀差，反映了上述建议同时也需要开发/运维的交织，就是现下说的比较多的Dev/Ops，既是方法论又有一整套相应的Dev/Ops工具相配套。软件开发中的微服务架构，使得多个模块由传统的紧耦合变成了相对独立的模块，有助于快速定位问题模块，在不影响其他模块正常提供服务的情况下解决问题。对于大数据，微服务架构的引入有助于项目风险的把控。

图4-32 大数据资本性投入和研发迭代成本的剪刀差