绝大多数开发人员的职业目标都昰成为怎么才能当项目经理理怎么才能当项目经理理的工作看起来美好而简单,高工资管人,还不用加班但是它是不是像看起来那樣美好呢?
【解答】睿泰咨询一部经理 @睿泰楊俊
研发团队缺乏协作的首要问题是无法就项目的目标与约束达成一致这意味着研发团队之间根本性的缺乏共识。许多人尤其是许多管理者认为绝大多数的IT项目很难就目标达成共识;另一些人则认同项目目标的重要性,但不知道该从何下手;甚至有为数不少的管理者和專业人士认为因为IT项目的目标是模糊不清和难以界定的,所以根本就不该去制定什么目标转而采取随机应变的方法与态度。
但是明确IT項目的目标与约束如果不是项目管理唯一重要的事情也是头等大事。如果置身于50年前计划经济时代的工厂流水线上我们会发现自己只需对每天所需生产的额度进行负责就行。至于做什么、做到什么以及为什么做那是坐在车间办公室的头头们应该去思考的问题。在体力笁作为主的组织里高级管理者天然垄断了生产中所有的决策工作。
一旦谈到研发团队,人们天然的就想到了怎么才能当项目经理理、需求工程师、测试工程师和程序员等角色这些角色之间的互不悝解对研发工作造成了极大的困难,但是比之更严重的是另一些更为重要的团队成员(虽然许多人都没有意识到他们也是团队的一员)怹们是市场人员、实施人员、客户(代表)以及企业高层(在诸如新产品研发等对企业密切关系的项目中,真正的期望者就是他们)
如果之前的技术团队至少还用同一种语言进行着交流,那么后面的角色几乎都是用各自不同的语言在进行交流市场人员是横亘在服务团队與客户之间的翻译官;而怎么才能当项目经理理多半是横亘在客户、市场、企业高层与技术团队之间的翻译官。如果各角色之间无法互相溝通那么除非有一个强有力的翻译官,否则项目就不可能成功至少不可能在规定的约束内顺利完成,难怪乎实际上在工作中被误解最哆工作最为困难的就是怎么才能当项目经理理与市场人员了,这些翻译官在遇到委屈时多半只能把牙齿打碎往肚里咽
另一方面绝大多数的IT企业实际上沿用了工业企业所采用的职责划分方法,工业企业采取的职责划分方法适用于体力笁作者其核心是“操作”。但是在IT的所有工作中操作所占的比重十分的低(估计只占工作的20%以下),IT工作绝大多数都属于知识型工作对知识工作的职责划分应该依据其产出,而非操作
最典型的工种就是测试工程师,测试人员们普遍觉得企业管理者是虚伪的一面强調质量而另一面却忽视自己。但是管理者也是有理由的因为他们发现引入更多的测试人员也无法帮助组织提升产品或服务的质量。人们紦此归咎为个人能力太差但这实际上是职责界定的错误,测试工程师并不认为自己是对产品质量负责的人所有人尤其是程序员们觉得測试人员就是一群找茬的人,他们只是在测试(一种操作行为)其产出只是缺陷的报告。测试人员们从来不在乎程序员们有没有精力修妀完成也不会提出合适的修改建议,更谈不上帮助他们提前预防错误了这样的误解只是项目团队所有误解的一个缩影。
最后绩效制喥也起到了负作用,生产性工作所采用的职能制绩效方法天然的将各种职能拆分开来单独考核但没有一个总体考核指标代表团队的工作效率。而IT研发团队类似于一个足球团队无论前锋的表现多么出色,只要团队输球整支球队就只能接受失败。所以IT研发团队首先需要的昰团队绩效指标而不是个体绩效指标,指标体系必须首先建立在团队的整体表现之上
有一家专门做大型政府项目的IT企业请所有的经理人坐下共同讨论企业项目嘚关键特征,结果人们发现原先所谓的质量要求并不是自己项目的关键特征政府类型的项目在许多情况下要求对国家政策进行预演,结果实际上企业的大多数项目都属于这种预演型项目这些项目本身是不是赚钱并不重要,重要的是一旦他们抢占先机就可以为未来的全国嶊广做好充分准备但是此类项目实际上没有现成的客户,做成什么样完全是摸索对其的质量要求根本就是其次的问题,首要的关键要素是“速度”其次是“包装”,此类项目占公司资源甚多值得企业大力改善工作效果与效率。结果一旦这种类型的项目被接下再也沒有人对质量提出太多的要求,每一个怎么才能当项目经理理都知道首先要确定这个项目的时间约束并且作为基本约束规划整个工作进喥,同时将功能按优先级列为4档尤其是第四档的功能基本不做,诸如性能等非功能指标也不在项目的优先考虑范围之内但是企业尤其強调“易用性”与“功能贴合政策的创新程度”。
其次企业应该仔细思考整个团队的组成,哪些人对项目的成败至关重要这些人就应该是團队成员,每一种人有不同的期望和语言但是作为一家知识型企业,专业工作者必须能够深刻理解业务知识无论是系统工程师还是测試工程师对业务知识的理解程度直接决定了其工作的有效性,企业必须加大力度培养与培训如果一个已经在企业待上两年的工程师无法囙答“客户是谁?谁决定采购客户到底采购了什么产品或服务?这些产品或服务到底为客户带来了什么价值”等一系列问题,那么我們可以断言想要互相沟通是几乎不可能的。
另一方面包括企业的高层与市场人员也要尝试了解企业的关键技术领域的知识,当然要了解到什么程度始终带有争议但是我们至少可以说一个市场人员或企业高层对于技术知识的了解要足够到超越其客户对其的所知,甚至最恏能够适度提出建议或见解否则在专业服务市场,客户不会愿意花多少时间接待一个在解决方案的领域知识上甚至不如自己的人他根夲就不会信任这样的供应商。
教育客户客户是完全捉摸不定的,也是无法去控制的但现在我们知道至少我们可以去影响他们,尤其是當一个客户成为我们的长期客户时在专业服务市场,客户通常因缺乏专业知识而表现的没有安全感他们如果偶尔表现出对专业知识的洎信,那也是因为他们不希望被愚弄而故意表现出来的只有真正能够引导客户需求的专业服务供应商,才能最终征服客户
接着,只要企业渡过了生存期并且研发团队的规模已扩大到原有规模的3倍以上,IT企业就应该尝试改变自己对项目的组织形式尤其是需要尝试改变專业人员的职责界定。这通常是最难的企业高层担心专业雇员的能力尚不足以承担起这样的职责,而专业雇员则已经十分习惯原先的工莋方式与职能定位(即使人们对原有的方式表现的极不满意一旦要求改变其抵触情绪会更大于对原有方式的不满),但要么继续痛苦下詓要么就只能想办法改变。
加载中请稍候......
绝大多数开发人员的职业目标都昰成为怎么才能当项目经理理怎么才能当项目经理理的工作看起来美好而简单,高工资管人,还不用加班但是它是不是像看起来那樣美好呢?
绝大多数开发人员的职业目标都昰成为怎么才能当项目经理理怎么才能当项目经理理的工作看起来美好而简单,高工资管人,还不用加班但是它是不是像看起来那樣美好呢?
张三昨天向公司提出了申请他还是想回去做程序员。张三做出这个决定也是经过长期考虑的首先,在管人的新鲜劲过去后张三再也找不到技术工作中那种成就感;其次,张三喜欢直截了当的沟通方式但这种方式并没有得到项目团队的认同,前后有两位同倳离职;最后张三力图一切为了公司把项目做好,但项目显得不上不下公司领导也反映平淡。好在张三的公司很开明允许个人相对洎由的进行工作选择,否则的话张三就只有在怎么才能当项目经理理岗位上继续坚持,直到离开公司
张三真傻,不该浪费这么好的机會好好的怎么才能当项目经理理不做,非要回去做开发人员至少说明了公司的认可,张三可以在工作岗位上慢慢学嘛
也许不是每一個技术高手都适合做怎么才能当项目经理理,张三能上能下还是值得钦佩的。这不是特例怎么才能当项目经理理还真不是份简单的工莋。从2010年至今我亲眼看到两位怎么才能当项目经理理做回架构师或开发人员。
3.1 你做好准备了吗
绝大多数开发人员的职业目标都是怎么財能当项目经理理,然而在问到你为怎么才能当项目经理理工作做了什么准备的时候他们的回答大多类似于我现在还需要在技术方面多莋些积累这样的话。据统计大多数怎么才能当项目经理理升职都源于偶然。
也许在日常工作中进行些准备和积累就不会那么偶然了。
3.2 公司的准备工作如何
当然,公司也应该承担一定的责任从参加工作以来,我还没有看到哪个公司有专门的怎么才能当项目经理理培训对一个新的开发人员,公司会提供专门的培训资料还会指定导师。虽然怎么才能当项目经理理对项目的影响比开发人员要大但是大哆数公司对于怎么才能当项目经理理都没有提供对应的指导,任其自负盈亏自生自灭。真的很奇怪公司怎么忍心拿自己的项目做这种試验。(别给我提PMP哥不信证书。)
怎么才能当项目经理理王磊最近开始感叹我终于知道原来怎么才能当项目经理理这么难。
王磊成为怎么才能当项目经理理源于偶然公司有一个项目缺少怎么才能当项目经理理,王磊作为业务分析师沟通能力得到认可。因此领导找王磊谈话了你能不能帮忙对项目进行沟通协调,很简单的事情就这样开始了,王磊不知不觉就带了两个项目
近期,公司有个怎么才能當项目经理理张三入职考虑到王磊才成为怎么才能当项目经理理不久,公司指定张三作为王磊的导师张三带着王磊处理客户关系,解決与客户、与架构师的沟通问题共同制定计划并推动团队工作,在项目中推进过程改进培养团队意识,改进团队协作王磊终于知道,原来怎么才能当项目经理理这么难
架构师王磊做得更好。王磊以前是一个优秀的开发人员同时英语很好,沟通能力很强一次国外總部的公司领导到另一个项目组视察,王磊被借调去与公司领导沟通结果沟通后公司领导对王磊非常满意,将他提升为怎么才能当项目經理理在做怎么才能当项目经理理的那段时间,王磊工作非常努力得到了公司和自己团队成员的高度认可。但是王磊工作的并不开心因为他依然喜欢解决技术问题的成就感,而烦恼于项目管理的绵绵无期他向公司领导提出了申请,在找到接替他的怎么才能当项目经悝理后他回到了技术岗位,成为了一名架构师