-项目背景：
刚进公司部门副总安排我带一个项目。项目在我接手之前已经陆续走了4个产品经理，5个项目经理（当然这个情况大概是在我接手后的1个月左右才了解到的），该项目属于13年底和14年初的部门烂尾项目。但是，迫于年底部门指标，部门重新捡起该项目进行一系列的运营和推广，而我接手主要负责运营推广中的技术支撑。

-项目技术
项目分为前后端以及行为统计，前端技术使用的是外包公司(WD)私有的中间件技术，后端使用该公司已有的平台产品。前端技术比较偏门，我之前从来没有接触过，网上资源几乎没有。前端还分IOS版和Android版。
后端使用的是外包公司的平台产品，技术不开源，部门只有已经部署好的系统，没有源码，所有后台改动必须依赖于外包公司。
行为统计有两个工具，一个是经分平台，用于渠道结算；一个是统计脚本，用于计算和分析用户行为。统计脚本的出处已经无从查询了，反正是一套不怎么稳定的平台。

-项目涉及到的人员和资源
部门副总：主要分管部门的技术，同时也会管理一部分的运营。也是我的直属领导。
产品总监：名义上负责该产品推广运营。名下有1名产品经理。名义上直属于部门副总，实际上直属于部门老大。
产品经理：负责提供每天的数据报表、产品设计、UED设计等。（最后赶进度的时候根本就没有什么设计，直接开始码字）
内容生产总编：负责内容生产，在该项目中，协助产品总监完成指标任务。名下有内容生产团队，用于本项目的编辑主要有2名。直属于部门老大。
部门技术总监：名义上负责部门的技术，包括前后端的技术架构和系统的部署运维。但在该项目实际进行中，没有提出任何建设性的意见，没有做过任何决定，在部门副总和部门老大之间打太极。直属于部门副总。
外包公司(WD)：WD曾经是部门副总的资源，但不知出于什么原因，从14年年后外包公司和我们部门的合作变得不愉快了，沟通和响应也不及时了。（后来才了解，之前与部门副总交好的原外包公司领导走人了）。WD拥有前端的中间件技术以及后端的平台产品。
部门前端开发技术1名：实际干活的人，主要开发和修改前端，部门中唯一一个熟悉外包公司中间件技术的人。
部门后台运维1名：负责后台的部署和运维，只有他才有权限进入后台服务，查看日志、部署系统等。
QA 1名：基本没啥用，只做功能性的测试，无法真正做到质量保证，对测试过的产品不负责。
人力外包(X)1名：项目的中后期，部门唯一一个能做该项目前端的人被部门副总调去做其他项目，找了另外一家外包公司，外包人力接手前端开发工作。

-我的职责
技术支撑；及时完成运营推广中功能改版。

-悲惨经历（以下按照项目片段来叙述）

片段一：需求问题
我接手项目大概是9月初的样子。刚开始接手项目我真是眼前一抹黑，啥都不懂，甚至不知道项目的大致情况。此时，部门副总根据自己的理解，提出了项目的几个改版需求。我赶紧召集了技术总监、前端开发人员，产品总监、产品经理等人开会商议，需求的可行性以及时间计划。结果开会没多久，矛盾出现了。产品总监认为改版需求完全不能满足他运营的要求，于是他提出了自己的需求，以及时间节点。最后，会议不了了之，没有得到明确的反馈。大概过了一周后，部门副总出差回来，我赶紧把部门副总、产品总监等相关人员召集起来开会明确改版需求，最后争了半天，谁也没有争过谁，结果两个人的需求都要满足，时间节点不变（那个时候我真想骂人）。随后我又召集了技术和产品经理开会讨论设计和开发，结果得出的结论是，设计肯定来不及了，干脆边设计边开发吧（其实就是去掉设计这一步骤）。至于人员安排，前端只有一个人能做，后端没人顶上去，结果我把自己搭上去，从现网上拉了几个类反编译后修改了一下。最后，版本还是比原计划迟了一个星期才发布，但总算把这个版本给糊弄过去。

片段二：资源不足的问题
上一个版本刚刚弄好还没有完全上线，下一个版本的需求又过来了。这次是内容编辑和运营总监提的。吃了上一次的亏，我学乖了，把部门副总拉上一起明确需求。结果当然也是很混乱的，副总有自己的想法，运营有自己的想法，两边的想法都得实现。当然，这不是该片段的重点。重点是：在此期间我跟部门副总提出技术资源不够，要申请资源。副总给我的答案是，找外包公司。我手上没有外包公司资源，想让他帮忙留意一下这方面的资源，知道最后他都没有明确下来。另一方面，产品总监跟我说，部门老大说，部门要有自己的研发团队、要节约成本，不能找外包公司，要自己干。结果，我又拉着他们俩开了个会，也没有明确的结论。但是，改版的时间节点迫在眼前，部门前端技术人员又开始加班加点。关于是否用外包的问题直到现在都没有一个明确的结论。

片段三：前后端的bug和问题。
产品运营和内容生产都频繁抱怨产品有这样那样的问题，或是推送接收不到、或是客户端崩溃或是使用不方便等等，这些问题终于在国庆假期中集中爆发了。后台彻底挂掉，而我竟然都不知道问题出在哪里（这个属于我自身的技术水平不到家吧），甚至连进入后台权限也没有。结果在假日期间打了各种电话，求爷爷告奶奶的让部门的运维人员把后台重启了一下。假日过后，副总召集我们开会，让我们分析故障的原因。我陈述了两点：1、我没有权限进入后台，没法看出错日志；2、我没有后台的源码，都不知道整个后台的技术架构。副总让运维人员开一个账号给我，结果运维说，账号给了我，有问题就不要找他了，这件事最后就不了了之了（至今我还没有拿到权限，是不是特别失败？）。第二个问题让我直接找外包公司WD解决，而这个段子又是该项目中一个无比大的坑，片段四会详细描述的。总之，无论是客户端的问题还是后台的问题都没有找到一个很好的解决方案。事情就这样不了了之了。我只能每天祈祷后台千万不要崩掉。

片段四：坑爹的外包公司（WD）
该项目又一个巨大的坑：外包公司（WD）。WD的一些背景前面有了一部分概述，但是，我事先是真没有预计到WD竟然这么难搞，我都搞不清楚自己还是不是甲方了。
首先，我们客户端累计起来的问题最后都集中到中间件引擎上了。结果，WD始终没有安排专门人员及时配合我们解决前端问题。直到快年底的时候，WD商务急着要催款的时候，才把这个问题给落实了。在这其间，我终于搞清楚了为啥WD这么NB，为啥我一遍一遍的催都没有任何效果，原因前面已经说明了。
其次，WD更大的一个坑在后台。我们至始至终都没有后台的源码，所有的问题和功能修改都要经过他们。由于历史原因，WD的后台人员与我们的技术人员势成水火。沟通和交流非常非常的困难。每次修改功能以及响应特别特别的慢，而我们运营又催的特别着急。我就成了肉夹馍，有的时候把自己也搭进去做开发工作。
对于WD事件，领导的想法是不置可否，到我这边就变得非常困难。

片段五：需求矛盾的集中爆发
部门副总需求的多变以及与产品总监、内容总编辑之间的矛盾由来已久，终于在IOS客户端上集中爆发。部门副总认为IOS客户端只有800个活跃用户，我们没有必要去维护和改版，让我们停止维护。但是，产品总监把部门老大搬出来，说IOS客户端要继续做下去。结果因为这件事我被部门副总骂了一顿，他让我搞清楚谁是我的直属领导。因为这个事情，我变得毫无主见，两边都不敢得罪，工作量直线上升，到最后还吃力不讨好。

片段六：人员变动风波
前面的几个版本之所以能够勉强上线，是因为我们有一个特别NB的前端开发人员，所有的需求他都能按时做好，也是对项目最熟的一个人。结果，他被部门副总中途给拉到另外一个项目中。我被迫去找了一个人力外包来支撑前端开发。外包的人力对中间件这块技术一点都不了解，从头开始学，边学边做，结果也就显而易见了。版本发布再次推迟。而且随着版本迭代的次数越来越多，功能越做越复杂，问题也越来越多，bug是一个接着一个，加班加点的次数也越来越多，被领导批评的也越来越多，到最后自己越做越没有成就感，越做越没有信心。

片段七：数据统计问题
在项目实施过程中，数据统计、用户行为数据、用户行为分析一直是领导和运营团队所关心的核心问题。而恰恰在这方面，我做的特别不到位。问题如下：没有实际对口的技术人员来处理这部分数据。后经过沟通，部门副总终于安排了一个资源来处理这一摊事情，但是由于人员技术有限，数据常常不能及时更新，或者数据常常有错误。这个问题直到现在都没有很好的解决。甚至，如果哪天运营同事需要花钱买量时，分析平台必挂无疑，最关键的一手数据丢失。

片段八：项目被叫停
基于上述描述的情况，也许好多情况我还没有叙述清楚。部门副总终于忍无可忍了，某天召集大家开会，项目叫停，项目中用到的所有东西包括前端和后端全部砍掉，大家全部力量转移到另外一个项目中去，一切重新开始。（说实话，当时我的心情是既轻松又难过。轻松的是，这个烂摊子终于结束了，难过得是我的第一个项目管理以失败而告终。而且，我还被重新发配到开发的岗位上。）但是叫停的过程也遇到了一点风波：部门老大不同意项目停掉（我们前后端一共花了100多W的软件成本，还不算硬件成本和人力成本，带进来的收入连10W都没有，前后端一共用了1年左右），让我们继续维护，所以直到现在我还要时不时的处理这个项目中的各种各样的问题和小需求，只是没有前期那么着急了，但无疑多了一部分不必要的工作。

片段九：失败项目的一点感悟
这个项目失败的直接后果就是，我不再做项目经理，重新被安排去做开发。
说实话，对于这个结果我倒是没有什么想法，反而对之前的这段时间的折腾倒是感慨良多。自己给自己先总结一下。
一、自身原因
1、对项目中使用的技术不过硬，导致决定的时候过多的依赖于他人。
2、项目沟通不到位，各条线，各种关系没有理顺，导致项目失败。
3、对于项目管理中得行政关系没有理顺，做老好人结果变得好难做人！
二、客观原因
1、项目接手前，本身就先天不足。项目逻辑混乱，管理混乱，人员也混乱。
2、项目决策过程没有一个独裁者，导致意见众说风云，项目管理成了摆设。

其他的问题还请广大网友帮忙指点！