现在的位置: 首页 > 综合 > 正文

开发角度谈:项目延期以及与产品部门的过招

2013年07月15日 ⁄ 综合 ⁄ 共 2469字 ⁄ 字号 评论关闭

做为一个还没有转到产品的技术人员来说,没事谈谈技术开发部门与产品的问题,而且还是这两个部门永远扯不清的项目延期问题,或许能够有助于将来自己的转型与学习。

从开发的角度先谈谈开发这边是因为什么而导致的延期:

1. 开发预估不是简单说两句或者很认真的制定就一定能达到准时的,即使再有经验的项目经理也不可能完全保证,三年的开发到现在,几乎所有开发的头头都会认同的是项目不延期几乎不可能”只是延期长短的问题!!如果能提前完成,那一般都是头头的口才好.....

2. 需求变更,需求变更几乎是最恐怖的,因为需求一变从头到脚就都得变。

3. 技术难点,技术难点可能在看需求或者效果图的时候感觉不难,定了个三天,结果一周还没做完,发现其实这玩意根本是个变态功能(经常踫到)。

4. 测试,测试过程中用例不全,导致小范围内部测时暴露过多问题,使debug时间延长。

5. 其他不确定因素。如人员流失,硬件设施故障等。

上面几点应该是比较常见的,比较客观的因素,其实也会多少存在一些主观的因素。比如老员工的消极情绪,技术人员的内向不沟通,编码过程中的粗心大意等等。我们不算后期的维护,就拿一个能够上线交给真正客户使用的产品来说,时间可能被延长一倍甚至更长。

通过这些因素来看,似乎问题就全部集中在了技术人员身上。我们这些码农们只能悲催的加着班,红着眼的敲着代码。然后慢慢的从客观因素变成了消极怠工之类的主观因素,并且总是在背后发泄着XX是SB之类的。最后,要么自己辞,要么被扫地出门,似乎也是个相当悲情的职业。

其实问题还不是出在产品与技术的沟通之上,就像大家都强调的那样,沟通好,才能合作的更好。但是说的容易,做到却又是何等的困难!我们且不说整个公司的大环境,仅以产品和技术团队的合作来看,似乎永远是产品催不停,技术做不停,最后效果对不上,实现不靠谱,一上线就报怨一片,最后只得不了了之。80%的产品不都是这样流产的吗?为了减少流产率,是不是首先考虑一下这两个部门的配合?

我们与产品的过招,无非就是希望需求定下就别变,在写第一行代码前把该说的都好好讲清楚。就这两点,再无其他。但是从工作这几年以及接触产品方面的知识后发现,不太强势的产品经理往往只是老板的传话桶。这里相信不我多说大家也深有体会,老板给你发工资,还比你有阅历,有时候即使争论也并不会有太大的改变,最后只能依照老板的想法去改,而在改的过程中,其实产品经理自己也是深感痛苦,最后交给技术同学的时候自己心里都发虚,这样能不被抱怨才怪。老板才不会管你什么技术架构的问题,一个小功能的变化可能带来整个架构的推翻也并不是没有的事情,项目的延期也就成了不可避免的。(另外一个现象是一个大的功能变化却有可能只改一点点的代码)这些在整个项目的开发过程中几乎是天天见到的现象,特别是我上家公司,每个产品都是如此,即使我们深知做的很烂,但每次的重做却又是如此的不舍,但高层却把原来的东西清理的非常彻底,于是我们永远在对同一个东西的无限循环中。

另外产品经理本身的想法也比较多,自身带来的需求变化也会时不时的出现,但一般还是会比较靠谱一点,如果真的踫到非常不靠谱的产品经理,那只能说是技术部门的悲哀。

再借一步来说,我自己现在的目标也是向产品和项目管理方面学习。也就从产品角度说下,咱产品人是不是也利用下自己的优势,主动去找技术人员聊聊。了解他们的问题,在预估开发时间的时候就能发挥更大的作用。咱是不是也去多找老板聊聊,有些问题或许就直接扼杀在摇篮中了。既然老板要招个产品经理,那么他就一定知道产品经理是干嘛的,如果一味的强势干预,这样还不如让老板自己当产品经理更好些。所以,产品在该硬的时候还是得硬,对于好的建议当然直接采纳,而对于会让已经开始开发的项目有较大变动的意见决不能姑息放纵,在认真研究后直接给出或采纳或延缓或拒绝的态度,否则可能导致项目延期或流产的罪魁祸首就是这个所谓的产品经理。而对于自身的想法,还是要多听取他人的意见,并且能够对技术方面的相关知识有一定的把握,都说产品经理要博学,技术这方面当然不能落下,多少学习一点点皮毛也是用不了多少时间的。这样在与技术经理谈的时候,也有自己的分寸,不会因为想法简单而实现困难去强加他人,也不会因为技术经理的消极诱导而放弃本来可以完成的需求。

稳住老板,在开始开发之前找到真正的目标、商业价值与需求点,然后一次开发,将来扩展。这样的产品相信即使不成功,也不会死的太难看。说真的,有时候很多问题也并不是我们开发人员想要出现的,或许只是大家都没有搞清楚我们要做的到底是啥而已。

同理,技术经理也是如此,我们直接面对老板和产品经理时,如果不衡量项目开发过程中的变动所带来的影响,最后的罪人可能就是你。在技术实现这最后一道关卡,技术经理同样有着不可替代的作用和绝对的影响力。不管是老板的需求,还是产品的需求,一样必须在评估后给出态度,而不是随口的一句“OK”了事,除非这功能的改变还真是一句代码的事。项目的进度把控,就是技术经理的最大职责之一。要说产品经理是产品的亲妈,那估计除了咱玩技术的,也没人敢做亲爹吧!(谁当爹谁当妈都不要紧,反正都是一个成功产品最亲的人嘛,怕有人误会….)

因此,产品与技术,从来没有上下级的关系,也不会出现谁主导谁的问题。一个是灵魂,一个是身体,两方面的协调才能成为一个完整的人。如果少了灵魂,无非一具行尸走肉而已;如果少了躯体,灵魂无处安息,终将蒸发殆尽。包括上面用的爹妈比喻,说的无非就是少点互相的报怨(但再好的夫妻多少还是会有吵架的时候),唯有多多互相的了解才是一个产品成形的正道,至于它将来的成长发育,我们还有运营的兄弟姐妹们在,将来再说!

产品和技术兄弟们没事的时候多互相表白表白吧,没坏处,嘿嘿!

------------------------------------------------

我的独立博客:壊小子 -

http://www.zyblog.net/

本文链接:http://www.zyblog.net/post-87.html

欢迎转载,转载请注明本文来源。

抱歉!评论已关闭.