能看我这篇帖子的人,有几种角色,要么是企业老板,要么程序员,再有就是产品经理一类人了;
我干了5、6年的项目经理了, 而且是软件定制外包类的项目经理,我想我接下来说的话应该是行业内经理的一个普遍共识了:
一个项目真正的难度并不是程序和技术的复杂和难以实现;高水平的技术人员和优秀的技术栈应用,现在已经极少有项目是实现不了的了。
一个项目真正的难度和让人头疼的地方在于:研发人员做事风格,水平差异甚巨;一个中等规模的项目参与人员起码是5人起步的,这5个人想要默契配合,减少争执,高效的协同办公,实非易事!这其中存在大量的磨合成本,代码规范、技术栈、技术能力不均衡的分配问题等等,所以项目经理往往并不好做。
磨合+沟通,这往往才是一个项目经理真正在做的事情,至于画导图,开会分析需求之类的工作和团队磨合沟通配合相比,简直不值一提了;
每个项目经理的角色,实际都是一瓶润滑油…,有了好的润滑剂才能让生产机械的大齿轮、小齿轮无缝衔接,流畅运转。
所以如何才能合理的分配每个人的工作,减少争执推诿,高效的协调办公,
并根据每个人的业务能力和擅长的点去安排工作;这是重中之重;
对于经理、老板是这样,对于程序员也是这样,因为大家都不想做自己不擅长的事情。
任人唯才,才能有利可图;
我前面的文章讲到过,如果甲方客户想节约项目沟通成本,降低价格。那么就要变身成项目经理,直接去指导开发工作;
那么同理,如果要想减少团队磨合,把团队中水平各异的不同角色的技术人员全部整合完美,那么就要考虑让团队中的每一个人都适当转换成“项目经理”的角色,或者说让每一个人都具备“大局观”“整体观”,不再拘泥于自己那舒适的一隅;团队中所有的人都能清晰的意识到项目的开发目的和应用意义,可以站在客户的角度去思考问题;这样才能拿出更好的解决方案来;在减少团队磨合的同时,也直接给最后客户的项目验收提供了极大便利;
让开发团队中的人,从项目参与者、生产者的角色,转换成项目立项者和应用者的角色;甚至可以想象成项目的投资方;
我见过甚至我自己本身在刚毕业那几年也经常有这种情况,有时候参与到一个项目的开发中,直到项目验收上线,我也并不清楚整个项目最终是什么样子,要实现什么商业目的,我只直到自己负责的那一小部分单元模块的用途;只直到拿着需求方给的修改意见和项目经理给出的开发需求去1:1的开发实现;好比坐井观天;
干了几年之后,自己开发负责大部分技术模块的时候,有时候会现场去和客户聊需求,直到那个时候,我才发现,做项目切忌思维片面,闭门造车,弊端摆出;时刻保持大局观,站在客户和自己公司的角度全面去考虑项目意义和用途,才能做出真正耐得住市场考验的产品;
而这样的大局观,只有一流的开发团队才具备,那么小公司或者甲方企业自身如何实现这一目标和愿景呢?
那么,我们就要势必借助一些可以提供给我们大局视角的平台化工具了。
在一个成熟的业务开发平台框架中,项目参与者人人都可以实时的观察到项目的开发进度开发细节,及时的做出反馈,并且快速原型化的体现在在开发框架中。这样一来,我们就具备了从开发视角到应用视角的转换;
也将实现以结果为导向的处理开发策略;
相关内容
最新内容