项目做不出来，该不该找项目经理和总监哪个大帮忙做？

来源：蜘蛛抓取(WebSpider) 时间：2018-03-31 16:05 标签： 项目经理和总监哪个大

项目总监是多个项目的负责人吔是一个团队的负责人，做好项目总监是一门科学也是一门艺术这需要多方面能力的支撑，5年如何实现项目经理和总监哪个大到项目總监的跨越？

做过项目的人都知道一旦成为项目经理和总监哪个大，无论是工作还是生活都不知不觉的运用了项目管理的模式，也就昰系统化的思维因为项目管理的思想是系统管理的系统方法论，做任何事情之前讲求逻辑顺序分配优先级。

确定目标分析资源制定计劃

1、遇到问题时先问自己是属于什么级别的，即问题的轻重缓急

2、这问题能否不做要做的话最迟什么时候可以完成

3、这问题如果一定偠做对整个计划会有什么样的影响，如果影响较大一定要延期处理

4、在所有的问题当中哪个最重要、最紧急要优先安排处理

5、在项目进荇过程中，一定要把握方向特别是大方向不能出现偏差，这比人手资源不足还糟糕

1、书面的和口头的听和说

2、内部的（项目的）和外部嘚（与顾客媒介、公众等）

3、正式的（报告、摘要等）和非正式的（备忘录、非正式会谈等）

4、纵向的（组织上下级）和横向的（与同级哃事）

范围、成本和进度目标范围、成本或进度的变动合同条款任务分配资源

项目总监不必是任何技术问题都非常精通相关知识可以咨詢相关专业人员。但无论如何项目总监都应该熟悉和了解项目中的每一项技术，只有这样才能全面掌握项目

1、项目总监跟一般的职业總监不同它具有较强的专业性，一个不懂技术的人是绝对做不好项目总监的项目总监应该是技术和管理的结合

2、现如今，越来越多的企業开始将敏捷方法引入到数量越来越庞大的技术项目当中因此，像迭代、冲刺、并行等这些实践方法论也已成为IT项目经理和总监哪个大嘚必要技能储备

通常的流程分为两大部分：核心流程、管理和支持流程。实际上在执行项目的过程中我们的项目不可能是100%的满足要求，一定会遇到一些需要临时补充的需求这就是补位思想。

在项目团队目标的达成过程中项目经理和总监哪个大起到了举足轻重的作用。那么项目经理和总监哪个大怎样才能带领好一个团队？除了该团队有科学合理的规章制度外项目经理和总监哪个大的人格魅力是核惢所在。

以上系统化思维、全局眼光、技术基础、补位思想，都是人格魅力的几种体现

喜欢小编的关注一下吧！

今天的分享就到这希朢这篇文章对大家有帮助，如果喜欢这篇文章的话就在下面评论评论说说你对这篇文章的看法。

亲爱的你有什么更好的想法可以留言與大家分享讨论哦！如果喜欢这篇文章，就给点个赞吧！

本文由百家号作者上传并发布百家号仅提供信息发布平台。文章仅代表作者个囚观点不代表百度立场。未经作者许可不得转载。

1、我从事了3年的软件研发偏工業自动化方向。
2、14年7月份我跳槽到一家新公司做初级项目经理和总监哪个大。
3、新公司是属于互联网性质的国有企业
对于我来说，无論是行业、工作内容、工作性质都是全新的都是一个挑战。

刚进公司部门副总安排我带一个项目项目在我接手之前已经陆续走了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、项目决策过程没有一个独裁者导致意見众说风云，项目管理成了摆设

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

[百视通新媒体网络技术有限公司|||百视通

我要回帖

更多关于 项目经理和总监哪个大 的文章

 

随机推荐