项目经理与工程师间的“脑裂”

type

status

date

slug

summary

一、项目范围巨大，交付物众多：

这个交易集团旗下有16个平台系统，主要的有建设工程，产权交易，航运，医药等，给我们协定的交付物有现状分析、蓝图、一纲三策、16个全系统以及主数据的数据标准、技术架构（数据流向图，技术架构图，数仓分层图、采集/集成方案、安全方案、网络架构图）、技术平台以及和20多个制度规范和管理办法。

1️⃣ 现状分析、蓝图、一纲三策则是BA（业务架构）层面的事情，最终分别经过了客户公司信息化组长、经理、书记和CTO兼首席经济师的层层评审，政府单位的要求特别高，华为的经验并不能直接拿来引用，文件经理了无数次的修改，举一例子是他们对数据治理里提到了组织建议非常敏感，要求把所有相关的实体组织全部更换成虚拟组织，考虑到数据治理的全集团参与，因此16个平台的负责人及党委书记分别要在相关数据治理虚拟组织里担任什么身份，也进行了反复的battle和论证，最终共识无误才找CTO确认定稿。

2️⃣数据标准术语是IA/DA（信息架构或者数据架构）的事情，因为16个平台的数据标准需要逐个找客户进行确认，并针对客户的16个平台系统及子公司进行培训，每个系统的具体标准我们会拉相应接口及负责人反复进行确认，因为数据治理是个长期或者永续的事情，因此我不敢妄言帮他们全部制定了完善的数据标准，但是至少我们交付团队依赖对方的输入，仔细分析，完成了一大半的任务吧。考虑到这些问题的艰巨性，当时华为的现场交付团队总共有11个人，7个人都是做IA的。当然严格来说IA并不仅仅是数据标准，还包括数据模型、数据质量等，只是考虑到客户的规划以及项目有限时间，客户决定了这个面包要横着吃，而不是纵着吃，那我们只能适当缩减一定的工作量，不然这个项目是一定完不成的。

3️⃣ 技术架构属于是TA（技术架构）层面的事情，当时华为的现场交付团队总共有11个人，10个人都是主要做BA和IA，剩下的一个人就是我，当然我这时候已经是团队唯一最懂技术架构的人了，当然我也并非单打独斗，我具备华为云的云计算解决方案架构师认证，并且背后还有众多经验丰富的同事、以及华为云的产品部和一些架构师师长和朋友，因此技术相关的事情考虑到避免为代表处新增成本，我就在项目管理之外，主动认领了这个事情，成为了客户面展现的项目经理兼架构师。

4️⃣ 还有20多个数据治理的制度规范和管理办法，当然华为本身就有着成熟且强大的交付物套件，但是还是远远不够的，政务人员的挑剔程度远超想象，这些文档我们同样也是来来回回改了很多遍，本来我认为自己是项目经理，也可以完全安排手下的人一起干活，但是对于技术方面的规范和文档，不能对其他人要求太高，于是我也主动参与进来了，最后就把文档排版和基础优化的内容交给了手下人。这个就是我最后不愿意承认自己是项目经理的原因，因为整个项目是大家一起戮力同心，不放弃咬牙撑过去的，同事都非常的配合，没有给项目管理找太大的麻烦。当然20多个文件其实也有相近和重复，比如数据安全管理细则和数据安全管理办法，最终我们主动找客户合并了相关文件，仅保留16个文件。

5️⃣ 当然项目还有隐形的交付任务，就是平台系统，因为客户公司，B公司，C公司对华为的数据治理理论和工具都不清楚，就需要培训，哈哈，合同外的，我这里就参考另一篇文章称呼其为理念导入，一开始我是卷积产品部的ITA或者研发进行赋能的，但是对于一些比较复杂的产品，ITA讲的比较笼统，因为在技术交流中，客户看我比较在行，因此就委托我也针对华为云数据治理模块对他们进行赋能，于是乎，我在原本的基础就成了我们团队，甚至是华为整个大数据云计算交付中对DataArts 数据集成、数据开发、数据治理、数据目录、数据地图、数据服务、数据安全、数据模型功能最熟悉的人，在这个准备赋能以及赋能的过程中，我发现了华为云产品还是存在不小的改进空间了，因此就成了团队中提需求最多以及采纳需求最多的人，跟产品部混成了老熟人，或者成了产品部一生之敌。哈哈，不过还好，我现在离开啦，他们总归会松了一口气。

二、项目运作复杂，参与方较多：

该项目是联拓，主要参与方有三个，考虑到项目机密，先暂时用公司A、B、C描述吧，以我团队为代表的A公司负责咨询、蓝图顶设、数据治理规范、数据和技术架构设计、平台搭建和技术支持；B公司负责项目具体实施与开发；C公司负责项目的大屏，中屏可视化和部分应用以及运维项目。因此在这个项目中，我们团队并非全程参与，只参与整个项目周期3/5的时长，A、B、C三个公司的工作量存在衔接和依赖。最开始肯定是咨询先行，这时候我和B、C公司的核心人员也主要参与了咨询相关，但主要以我们A团队为主，一开始的时候项目和和气气，到了后期。我们A和B就存在了一定的工作量模糊地带，比如具体的数据模型，因为具体的建模是需要深入到业务的，考虑到内容众多，我们一开始入场时就谈好了项目边界，但是B公司还是反复来找我们掰扯，一次会议上，B公司拿他们做了三年的一个大项目跟这个总共就10个月的项目对标工作量，要求把模型甩锅给我们公司做，我们当然也是不认账，最后问题升级到双方高层，拿出来以前的会议纪要才算尘埃落定。反思这个问题出在B公司的PM中途变更过，所以他不清楚这个事情之前已经说明白了，但是他又没有直接去询问他们的领导，倒一遍遍的因为推进难度来和我们沟通。

另外产品的接受度，因为B、C公司作为项目的具体实施和运营方，即便我卷积产品一起对他们进行了深度辅导，对华为云产品是不熟悉的，到了交付的中后期，B公司员工之前明显学习的不到位了，他们就继续拉我们掰扯，对比他们的可视化工具与华为云的通用SQL脚本加成熟调度器哪个优劣，当时给他们沟通时候，我没有给他们好脸色，也没有撕破脸，给他和客户指出了，通用SQL脚本业界人才多，上手门槛低和调优空间大，而可视化界面没有调优空间，性能差，学习成本高，批量化操作空间太差。并请求他们给出核心诉求，是认为工作量大，还是说产品不会用，对方哑口无言，然后我们进入下一个议题，对方要求我给调优建议，点开编辑框一看，他们招的人连SQL语言 nvl和colease都不懂，写了一堆的if，可见是图成本优势招的性价比开发人员，脚本开发的质量很差，我针对这些问题分别给了解答和规范案例赋能，当然言尽于此了，我对这个项目的整体结果感到焦虑，但是又无法同客户明说，好在最终我们咨询和规范的这块内容是顺利交付的，只能祈祷B公司后续顺利吧。

（路上打字晕车，未完待续）

一、项目范围巨大，交付物众多：

二、项目运作复杂，参与方较多：

tacjin