我参与的一个项目的继续总结：牢骚篇

李迟按：
今年2月份我对自己参与的项目进行了个人总结，但这个项目陆续地进行，直到现在的8月份、9月份。出于习惯，继续写总结。
这是一篇牢骚文章，作为步入中年的人，似乎不应该如此。但我觉得自己还年经，有些事，凭已之意气，说上两句也无妨。另外监管项目的部门说不开专门的会议评价各项事，心有不爽，只好在这里发发牢骚了。以下是站在既是开发角色又是项目经理角色的角度行文的。

前文
今年4月23号，A、B阶段的项目经理发电子邮件，说要启动C阶段，开发人员3人，测试人员2人。4月26号还是27号还是28号，部门主管突然告诉我要做C阶段的项目经理。4月29号中午，上届项目经理发电子邮件，安排我为项目经理，同时追加1个开发人员，并要求4月30号召开项目预备会，但因为有人员未到位，不启动。6月人员正式到位，所以项目计划表从6月1号正式开始，8月14号完成软件开发提交测试。8月18号正式发电子邮件交付给其它部门（按公司制度，“其它部门”是项目的客户）使用。截至8月底9月初，即本文写草稿及发表为止，仍在做收尾工作。只计实质的工作，我投入的时间大约有4个多月。翻开我的工作日记，在去年的这个时期，我就开始了这个项目，历时一年。鉴于公司制度，没有离职情况下，只要沾过边的事，就要负责到底，我相信以后这个项目一直会follow着我。

正文
去年的这个时候，公司着手这个项目，当然，前期工作，是不算到项目里面，但往往会有先行者——比如我，去做公司所谓的“预研”。从做小弟到做项目经理，听上去似乎不错，前途无量。然而实际上却不如此，在这个公司，你懂得越多，你的活就越多。我所做之工作，相比以往的角色，只是多“管理”：开会，写报告，写申请。而写代码，去外场测试，找bug，一样倒没落下。
公司组织架构中，有“项目经理”这一岗位，而我，title是工程师。虽然公司开发气氛很浓重，但无可避免地有着制度条例。我想不明白，为什么公司现在已经有了项目经理，怎么还让我去做呢？实际上，我这个项目经理是兼职的，无实权的。所以凡有我无权或无力做决断之事，我都会第一时间请示上峰。
不过，可能由于人微言轻之故，即使是流程制度上规定的需要审核的事，有的领导也没有回应。我的观点是，人在其位，要谋其政，该你干的事，你应该要干。但有的领导偏偏很忙，我只好向上峰反应，叫领导去催领导了。而对于一些验收方案的事，应该是领导自己写的，但依然忙没给我，于是我就自己安排人写人，叫领导回复行还是不行。后来我听人说，因为公司以前专门招聘来的“项目经理”都不懂搞项目，所以从现成的开发人员中选项目经理出来，美其名曰人才培养。
有人说，为什么你不反抗呢？如何反抗？我本着做事的原则，不想扯皮太多。每个召开项目例会时，我都有或多或少的意见，但得到的回复都很冠冕堂皇，没什么实际用。我特别反感的话是：既然你对流程没有意见，就应该想办法把事情做好。而当我就某些事说出意见后，回复说，流程只是规定你如何做事，但没有把每个细节都考虑。另外，前文说的请示领导，也是必要的。像有些验收项和标准，我认为是可以的，但有的领导不认可，最终只能如领导所愿。有次开会，大领导罕见地参加了，问我们这帮兼职的PM是不是头上有天花板——即在工作时，是否有些事压着你。我们都很快速地承认有。其实，大领导知道，我们也知道，但并不是每个事情都可以反抗的。
有道是“匹夫无罪，怀璧其罪”，人没有罪，有罪的是璧玉。流程本身没错，但错的往往是人。有的人在执行时有疏忽，或不到位，以结果导向来看，就是有问题，而执行，又在于项目经理。作为菜鸟级别的新手PM，有些事的确没意识到，你不能要求一个搞了3年内核驱动的人，会很好地完成审核UIl界面细节的东西及管理。但我会努力去做，但有的事，实不是吾之力可及也。当然，在这里我是为我开脱，但面对领导的批判，我依然有责任把责任揽到自己身上。
但自己想想，老是做好人不行啊，后来我学会了和某些部门打官腔了，并决心如此下去。这也多亏了这些经历。

下面按时间顺序说说项目实施过程的事。

其实初期的需求是不明确的，参与那么多项目，没见过有几个是很明确的，也没见过几个后期不需要修改的。这或许是无法改变的现状。而我，只是想让一些很明显的需求项描述清楚。我们公司有专门写需求文档的人，由于本人对文字的理解异于其它人，所以对于一些细节的描述，我是很在意的。因为对于程序来说，是要确切的知道的。比如，需求上说要支持可播放的视频格式，是支持AVI，还是MP4还是MKV？只支持单一一种即可，还是所有的格式都支持？类似这样不明确的，加上有部分描述还有错误。我多次和该负责人就文字的准确性和多加备注方面展开争论，当然，结果我lose——即使我在会议上向领导明确提出。需求是有部分未考虑周到的，这也是无法避免的事，但有些需求项，是完全可以写得清楚明白的。比如，中期项目加入了IE 64位的支持，但偏偏在后面用括号写上几个IE版本号，由于领导口头告诉我的是支持64位，我就没留意IE的版本，到后面项目准备收工时，发现程序在有的IE版本上有问题。于是回查，于是发现了需求里要对很多个版本的IE都支持。找到原因，也好办，改。但时间，起码用掉了3天。后来我发电子邮件，把项目经理(即我)、模块实施人员、测试人员和管需求的，都批评了一次，当然，不出意料，管理需求人员进行回复，并说特别加入了IE的需求，你们要引起重视，对需求细节不明确的可在研发需求分析或概设时及时向人家提出，消除误解。我完全可以继续争吵下去。但于事无补，因为时间已经耗掉了。对此，我在项目例会上把意见说出来，就不知道管理项目的部门(公司有专门管理项目的部门，由他们制定流程、管理项目进度，项目经理要向他们汇报，我上面所说的领导，很多时候是指他们，但他们没有人是做过开发的)如何处理了。

概要设计一直是公司的心病。当年，公司召开员工吐槽大会，有人专门就概要设计存在必要性提出意见，引发大领导的不满意。后来不久，那位兄弟去别处高就了，在远方的他不知还要不要写概要设计。但概要设计是必须的流程文档，一定要写的。这个项目中，开发上位机的哥们一直没写。这也是我的疏忽，我在开始已经强调要先写概要设计或编码，但可能是选择性忽视的原因，没有写。我催促了几次，后来就放弃了——因为项目准备进行了中期，已经不是概要设计阶段了。于是我计划到项目准备完成时再叫他补充。在我的坚持每隔一天催一次的努力下，在交付前终于完成了。
在项目初期安排人员时，已经确定了哪些人负责哪些模块了，概要设计也相应完成。但后续有不同的需求加入来，已有概要设计已不能表述；新加需求又杂又乱，无法统一写一份。我就此事问项目管理的领导。他们要我给出具体的例子，我给了当前的，但他们没给明确的意见，叫我自己把握度。我一听就想不写了。但基于责任心，我还是安排人做了补充——我不希望我经手的项目，有的功能没有在文档中体现。至于其它人，不是我的事，我不操心。

我负责着一个模块，本来作为项目经理，应该做整合的人，不做具体的模块开发。但人手不够，我不搞就没人了。但我高估了自己的能力，一来部门还有事务要做(本来做项目不应该有部门事务干扰的)，分散了时间；二来我还要兼顾项目管理的各种杂事，同时分散了时间。到后面发现搞不定了，只好分派给别人了。我也专心做了打杂的角色了：整合。没有人负责的模块出问题，我来搞，测试的bug，首先我来分析；别人的bug一时解不完，我来，解不了的，我来。后面有人周末有事无法加班，我要去。项目搞不完，首先是项目经理的事。即使心里再不爽，也要做。

理论上，每个模块都自测没问题后整合就轻松很多，但事实上我不亲自自测，我不敢提交给测试人员测试。在自测时就发现很多很基本的问题。当然，搞开发肯定会有问题，但很基本的问题就不应该存在。最可能的原因是大家都没有进行自测。

以前还不是项目经理时，我要和测试人员一起到外场测试。因为之前有反映，测试人员不懂用。有开发人员去，也好解决一些异常情况。而我是项目经理，依然要去。一句话，人手不够的情况下，你不去就没人去了。风吹日晒的过程，不说也罢。

做项目肯定有延期，虽然公司领导不愿看到，也想办法不使之发生。但实际上不发生是不可能的。流程上说有延期要写申请，要提前三天。我好像一共申请了三次。前两次按足官方话来说，看电子邮件，不会看出再有问题引起延期，但还是有了第三次。主要还是技术方面的原因。至于因为需求或欠考虑的原因，各位领导依然要我给出真实理由，还问我有没有预判。最后一次要我给真实原因，我就列出了后期发现的所有bug，根据事实描述各个bug的情况。

关于验收，其实要做的事情很多。首先，项目交付是要通过测试的，实验室测试和外场测试通过后才能算通过，另外各类文档也是多个部门审核，走流程恐怕也要一两天才完成。但这终归是项目组的事。其次，临时组成的项目组的客户是公司其它部门，我们做完东西是给他们卖的，他们也要验收。包括需求点，文档，bug，易用性，扩展性，等等。比如，这个文档这个地方描述有歧义；这个UI界面的颜色不太明显；这两个框的距离大了，不对齐；这两个框的距离小了，信息太长显示不下，等等。
本来在我这个项目完成之前，另一个项目先完成，进行了验收，期间就扯皮了很久很久。我以为经此一役，各方都会理解，达成共识。但没想到，这个项目依然如此，似乎这个永恒之事。也正因为之前的争吵，后面到我和客户部门争吵时，首战告捷，这还得多谢该项目。
为了更好地卖出产品，他们站在客户的使用角度提的各种意见，是无可厚非的。只是，我不太习惯这个验收一次又验收一次的制度，也受不了其它部门作为客户的态度。我觉得，大家都是同事，我们做完东西，你们又不会给钱。更何况，做项目最多可报销加班餐和加班交通费，吃项目饭也有人均的限额。就连周末加班调休也要审核几天，你加班了5个周末，又不一定会批5天休息，而且又没有奖金。何必如此受气。

下面说说我作为项目经理的其它事。

对于开发人员，这次我没有过多考虑。但现在后悔了。我太相信领导安排的人了。前文提到了，所有人员是领导安排好的。我想，这些人员应该都是有能力做项目的。但事与愿违，有人连基本的SVN都不会用。而且，该人连项目基本流程也不懂，做事条理性也不够，我几乎差点手把手教了。对于加班很晚而第二天10点才开上班的事，我也无法干预。后来我向有关项目管理部门反应问题。得到答复是，你做为项目经理，你应该自己管好自己的队员。就是我，关于项目成员的所有事，都是我本职要做的。后来我为自己想到一个理由，就是我作为项目经理的威信还不够，因为我只是一个coder；因为我只是一个与其它基层员工平等的员工；因为我和有的成员不在同一部门。我说的话，人家不一定听。想到这，除了得到教训外，我也心安理得了。

对于流程制度，我有很多想说的。但多次和别人交锋发现，无论怎样，我还是too young。

对于项目来说，交付之后即表示研发的结束，但项目还不能结项。而关于结项，我也有些不爽，可能是跟制度有关吧。以前是说验收，在验收过程出现问题要解决。解决之后才能申请结项。我就此事向有关领导咨询过，他们说没有原则性问题，可以在交付后就申请，但不一定会审核通过。当然，经过考虑，我肯定是听从他们的意见。我不知道公司的项目制度为何如此设计。本着快速开发之原则，理应不存在项目验收了，客户部门也再次验收，项目交付后，还要受客户部门的牵制。我觉得，公司组织架构决定了存在这样的问题，产品涉及不同部门，在项目开发时客户部门并没有大量参与，都是基础部门做开发，但他们在后期做支持却是以项目交付的结果为基础。客户部门不一定会百分百理解和掌握项目涉及的方方面面。按项目制度来说，要在他们使用得没任何问题后才能结项。但即使如此，后期有不同需求而原项目成果不满足时，又会涉及到基础部门。而公司制度又规定，基础部门必须为客户部门做支撑。这样对于我们来说，前期做项目，后期做维护，始终没有脱离过。

其实这种制度是不利于个别人员的发展的。就这个项目的我来说，项目未立项时，我已经在摸板子了，对于外设，系统构建及程序烧写，已经在研究了。完成这些后，我就开发做业务程序的整合(主要是哪个模块没安排到人的，都指派给我)，兼职陪测试人员去外场测试。而完成了A、B阶段后，我变成项目经理，但又兼职着开发人员。这种哪里需要人就到哪里去的做法，在公司领导来看似乎是好的，因为锻炼员工的能力。但试想一下，在一个有专职项目经理的公司里，让一个没有经验的人负责项目，风险谁担？最后还不是归于项目经理头上？

无论怎样，一个项目如果有问题发生，那么首当其冲的就是项目经理，无论是怎样的问题，项目经理都难辞其咎。在这个以结果为导向的公司里尤为明显。面对领导，即使把实情说出来，领导也未必会理解。所以就选择在这里发发牢骚。牢骚发完，该干活干活去了。

后有人记录了此事，单表项目经理之心酸和无奈：

嵌入式软件工程师

以前呢
我的岗位是嵌入式软件工程师
负责内核驱动移植根文件系统构建
解决“底层问题”

后来啊
我还是嵌入式软件工程师
同时兼任“方案负责人”
负责内核驱动根文件系统 “底层问题”
还有方案整合 “设备问题”跟外场测试

而现在
同时兼任“项目经理”
我依然是嵌入式软件工程师
负责内核驱动根文件系统 “底层问题”
还有方案整合 “设备问题”跟外场测试
以及开会报告和扯皮
整天进度控制风险管理

将来吗？
我仍旧是嵌入式软件工程师
已知要光荣掉天坑一
其它的
就是重复昨天的轨迹

(注：天坑一并不是一个坑，而是代表着研发新CPU的众多坑)

(全文完)

李迟 2015.9.3晚

我参与的一个项目的继续总结：牢骚篇相关推荐

我参与的一个项目总结
最近参与的一个项目阶段性结束了,从去年9月到今年2月,进行了整整5个月.下面是我的总结. 一. 1.比较完整地参与到项目中来,进行了需求分析.概要设计.编码实现.测试等环节,对软件工程的科学性有了更进 ...
我参与的一个项目的继续总结：技术篇
看了年初写的总结,主要还是在于环境的搭建,底层的支撑.所做的事,大部分是从无到有的过程.这次继续参与项目,基本上是在搞业务层的东西.当然,除了研发外,还在做项目管理方面的工作. 由于精力分散了,不能花 ...
我参与的一个项目的继续总结：经验篇
李迟按: 我看了很多关于项目管理的文章,但发现文章说的和我实际上做的,出入很大.后来和同样做项目经理的同事讨论,发现一个秘密:我们只是临时工,临时兼职项目经理.对于项目经理的权力,权利,均是官方套话. ...
java dagger2_从零开始搭建一个项目(rxJava+Retrofit+Dagger2) --完结篇
鸡汤:感到迷茫是因为你没有给自己做好人生规划接上一章的内容,如果还没看过的朋友, 请点本章内容 Dagger2的引入 Dagger2的引入 Dagger2是一个依赖注入框架,那么dagger2能起 ...
我参与的一个x86平台项目的经历
今年是第一次完整参与一个项目的方方面面--当然,是站在开发人员的角度的,至于市场需求收集,采购元件生产,新品发布,销售拿钱,就不可能有我的份了.以前参与项目,都是只负责一点点东西,而且中后期完全处于边 ...
一个项目在启动前都应该明确哪些事
前言广告系统在之前很长一段时间都是依赖用户主动行为进行查询透出以达到效果. 但随着用户和模式的成熟,主动模式几乎达到了业务瓶颈,这就需要采用更智能的方式,比如推荐,去引导和促进用户发生转化,提升效果 ...
好的开始是成功的一半 -- 怎么做好一个项目的启动...
俗话说号的开始是成功的一半,管理一个项目也同样是这样,很多的时候,项目运行中的遇到的问题往往就是在填项目启动时所埋的坑.一个好的项目启动能极大的提高项目成功的概率,避免项目过程中很多的风险.这里我简单 ...
一个项目中能提出哪些数据库优化_如何有效进行项目集管理?
随着企业的扩张,业务往来日益增多,企业同时开展多个项目是不可避免的,如何有效进行多项目管理,是许多企业急需解决的问题. 这一趋势导致多项目管理角色的兴起.它与项目高效和谐地配合,为企业的快速发展提供了 ...
如何在github上fork一个项目来贡献代码以及同步原作者的修改
如何在github上fork一个项目来贡献代码以及同步原作者的修改作为一个IT人,通过github进行学习是最快的成长手段.我们可以浏览别人的优秀代码.但只看不动手还是成长得很慢,因此为别人贡献代码 ...

我参与的一个项目的继续总结：牢骚篇

我参与的一个项目的继续总结：牢骚篇相关推荐

最新文章

热门文章