开发

遇到外包开发,产品经理就需要注意了

产品经理和开发难免因为一些观点不一而争(si)论(bi),万一遇上外包开发,又会如何……换了一份工作,进公司后发现完全和讲的不一样,这没有能力组建一个开发团队!咱不能遇到困难就退缩不是,于是乎开始了与外包团队的周璇,现在项目已成功上线,现将中间的坑与大家分享一下:一.选择靠谱的开发团队因为种种原因团队中唯一懂技术的CTO离职了,与挑选外包团队谈开发的事落在了产品经理头上。还

开发人员的客户思维

都说产品与开发之间的矛盾由来已久。在很多互联网企业,都发生过类似这样的一幕:工程师日以继夜,终于在约定的时间里交付产品——虽然这在产品经理看来可能还只能算个高保真的原型。产品经理体验了这个原型之后,发现一些与期待不符的地方,提出了改进意见。工程师带着泛起充满自信的笑容,再次进入了封闭的开发阶段。类似这样的过程持续往复下去,开发工程师和产品经理对对方的耐心都会受到挑战:产品

从产品的视角看待敏捷开发,减少和程序猿撕的几率

作为产品,如何有理有据地撕程序猿呢?如何把程序猿撕的无话可说,且直接认怂呢?答案就是——了解程序研发流程中的点点滴滴,多用程序猿的视角与程序猿沟通问题,提高产品研发效率,尽可能减少撕的环节。产品原型制作完成了,下一步的工作就是将原型及相关文档交付给开发团队进入到产品开发环节。这时,作为产品经理的你,终于可以稍微松一口气了。但是,并不是这以后的事情和自己没关系了!作为一个产品

产品汪,如何有理有据地手撕程序猿?

以产品的视角,理解程序猿的世界!作为产品,如何有理有据地撕程序猿呢?如何撕的程序猿无话可说直接认怂呢?答案就是了解程序研发流程中的点点滴滴,多用程序猿的视角与程序猿沟通问题,提高产品研发效率,尽可能减少撕的环节。产品原型制作完成了,下一步的工作就是将原型及相关文档交付给开发团队进入到产品开发环节,这时作为产品经理,可以稍微松一口气了。但是!并不是这以后的事情和自己没关系了!

如何与 PM 愉快的相爱相杀?

一些背景故事坊间流传着很多关于PM(Project Manager,项目经理)的笑话,在这些不无刻薄的笑话中,PM往往被描述成一个盲目应承客户,不了解实际情况而又喜欢指手画脚、专门坑开发的家伙。毋庸置疑,这些笑话当然出自那些“聪明的”开发(不过你得承认,这些笑话并非空穴来风)。在智力工作中,对于开发的实际进度、开发速率等问题,具体着手做的人永远比在背后指手画脚的人更有发言权

相亲相爱的产品经理与程序员——应遵循四个原则

如果你经常浏览互联网方面的段子,你就会经常看到诸如“产品经理改需求被打”之类的搞笑娱乐信息。有些互联网公司还会在办公室的墙壁上贴上相关的图纸,用来告诉产品经理,程序员们是有多痛恨你们频繁地更改需求。 我本人也接触了很多开发,有时候就会问他们这样一个问题:你觉得做产品经理需要懂技术吗?如果要的话需要懂到什么程度呢?开发大大们都是这么回答的:作为一个开发我想说:如果产品经理完全

产品开发结构化

关于产品开发,先看几组调查数据:在所有的交接任务中有39%引起了混淆和困惑,结果浪费了力气,误导了工作。22%的工作是在明知混淆和困惑的情况下放走的,原因很多,包括计划不周、执行仓促和纪律松驰等。至少有48%的开发工作是“救火”,即那些出其不意地冒出的必须立刻加以解决的、无计划的工作。人们有30%的时间实际花在了产品设计上,而另外70%的时间全浪费在澄清关于正在做什么和由谁

为什么选择快速开发?优势是什么?

大家都知道,现在和以前比起来,互联网行业、软件行业已经天差地别了。现在处处都在搞信息化建设,人人都知道互联网思维。这样的信息化时代,对于软件开发者、对于软件开发公司来说,是一个巨大的机遇。在门外汉看来,软件开发是机遇大、成本低,只要叫几个程序员,就能搞出个软件公司来。但是,事实情况是这个样子吗?本人在国内软件行业发展较好的二线城市发展,几年也亲眼看到了不少软件公司的衰落。有