借4.1这个大好机会,大家一起来聊聊“真心话”吧!你有什么最想对“他”“她”“它”说的?
云栖大会订制T恤 x 2
淘公仔 x 2
优酷VIP月卡 x 4
妙正灰
已获得淘公仔
复制链接去分享
本来是运营🐱,然后最近为了对付省比赛,开始试水产品🐶+运营🐱混合。
用 Axure 做了一份原型,然后开始异想天开模式,动不动就灵感爆发在手机的备忘录写下来,继续丰富产品。
然后有三个开发实现生产,我基本天天跑到它们的房间,狂提需求,现在它们看到我都是躲着我的,特别是做网页的仁兄。。。
产品不可怕,就怕产品有文化,因为我网页也比较会,所以做网页的那个说做不了,我基本上都能提出实现的方法(应该会被打吧,逃~~)
timjintan1
已获得优酷VIP月卡
复制链接去分享
我是程序员,现在和运维合在一起了,共同对付产品团队,挺好的吧?哈哈。
客观地说,通常产品团队更强势些,以前吃过他们的苦头。
要减少团队间的摩擦,最重要的是公司领导在制订绩效考核的政策时,要把三个团队当作一个大的团队制订统一的指标,这样团队之间的利益就一致了,不会互相指责和推泄责任了。
RD.Enoch
已获得优酷VIP月卡
复制链接去分享
我们公司产品需求基本就是项目初期的时候有用,后期市场或者集团老总们时不时的说改一下这里,动一下哪里,最后总结就是:《临时性一句话需求》,因此今年2-3月份程序猿走了一半。
开化府尹
已获得云栖大会订制T恤
复制链接去分享
我是一名程序猿,给我留下第一次伤痕的开发要算是公司的OA协同办公软件的开发:
产品狗开始列出各种需求,然后把列表需求给我们说:“前期就想到这些需求功能你们先弄,有问题我们在沟通!一定要加快进度老板等着看效果。”于是我们开启了程序猿加班模式,先整理好需求思路画好构架图,着手开发。3天后 产品狗带来了一打材料,说:“经过这几天他们部门对整个公司的调研对之前的需求进行了完善和修改,你们看看有没有问题。”我们一看内心是无语的。(哪里是完善和修改,明明是推翻之前的想法,弄了一个新的思路出来嘛。)于是我们重新开始,一个礼拜后弄出了第一版。产品狗一看说:“这咋这么丑呢,不好看啊。”我说:“这只是功能测试版,你看下功能有没有问题,没有问题我们再弄页面美化。”产品狗说:“应该问题不大,先把页面弄好看,我好给老板看。”一听就知道“问题不大”就知道又有新想法了,又要改了。找设计部出效果图,切片把页面弄好看了,给产品狗带去,产品狗一番讨论又出新想法,好吧、再修改吧!如此往复怕有上百次的修改,大到整个功能模块重做,小到一个表单的修改。好吧产品狗基本满意了,拿去给经理审报,过了几个小时后,产品狗一脸贱笑的过来对我们说:“经理对整体比较满意应该没有问题,但产品使用方式太单一,现在是移动时代要注重移动端使用。”一听就明白了,这是要加移动端的开发了,还好对功能架构没大意见,只是加移动端开发。弄完后审报,产品狗再次走了又来,这次带来的是:“微信端开发。”好吧。又注册微信企业号。对接开发微信企业号开发。如此反复的修改开发我记不清最后修改过多少次。尤其是我们总经理是个美女,对样式的美观很是“苛刻”,最后小到一个图标位置不满意都要修改……
这只是众多项目中的一个,还有很多………………
最后我只想对产品狗说:“是你天马行空的想法让我们程序猿的技术猛涨,让我本只会php语言的程序猿去学习了JAVA,谢谢美女经理让我审美观得到了提升。但有时候请你们为我们着想一下,那些不合理的要求,'臣妾做不到啊……'。”
张维ACE
已获得优酷VIP月卡
复制链接去分享
产品上线前的提测
相信不少产品朋友的公司或团队里面有负责不同产品的。就拿KEVIN来说,目前负责的是1个APP(包括IOS端和安卓端),3个后台;并且3个后台逻辑是相关关联。一个全局后台、一个内容管理后台、一个业务后台。
在大多数团队产品中,一个后台匹配一个产品足够,但往往很多产品不仅是对产品负责,更是起到了企业整个流程的作用。将企业现有的传统流程改为信息化处理。如CRM/ERP等,都是这些产品的体现。
那么作为PM,应该如何与测试有效的沟通?
首先KEVIN目前所在的团队是以端进行分化并非功能模块,如移动端A产品经理负责、1个后台B产品经理负责、1个后台C产品经理负责。
首先KEVIN这里抛出一个问题:作为PM是否应该了解测试情况?
在这里,一个产品的交互设计是否合理?业务逻辑合理?大家有没有思考过,这是可以从测试体现的?
从KEVIN的经验来说,目前程序的错误的测试BUG占比测试结果报告中是很少的。
并且作为PM需要清除的是及时了解未处理的BUG,而已经解决的,不需要CARE。
在测试中一般会有以下情况:
【BUG状态】
以上是经常PM会看到的一些测试反馈,那么对于相应的状态就要有相应的产品认识。
如果是重新开启的BUG,就要考虑是不是产品的逻辑关系,导致产品不断出现BUG。相应的对于PM也要及时更新产品需求文档,对于一些新加的需求,需求文档需要详细标注。这样测试的结果才是准确的,当然产品需求文档怎么写?之前KEVIN有简单聊过PRD与竞品分析,可以去看看。
【某产品测试报告】
之前KEVIN有说过目前负责的是以端来进行区分。或许部分PM的划分是以模块划分的,不管如何划分,PM应当时刻保持对自己的产品测试报告进行回查。
首先开发排期后,主动的将开发排期表与相关开发人员的情况拿到手里,随时跟着开发进度进行跟随。其次,开发完成之后,提测进行测试排期,主动的拿到测试排期。
测试中,KEVIN认为对于产品应该进行区分,尤其是对于团队中有2个以上的PM来说,那么区分产品的测试报告,方便PM进行查看和调试。
简单来说过程可以分为:
【测试分化】
这样就不需要将所有的测试结果集中在一起,PM也不方便查看。当然对于认为不需要查看测试结果的PM,这条建议当然没用啦。
并且PM需要制定相关测试用例或测试报告。
【测试用例】
测试用例是准备用来测试的数据,假设我们需要测试一个计算绝对值的程序是否正确,我们至少要准备一些正数、负数、0来作为测试用例,例如-3、0、9这就是一组例子。测试报告详细描述测试报告以及选择这些作为例子的理由,还要包括在测试例子数据的工作情况,最后有测试结论。例如我们输入-3、0、9这个程序的结果是3、0、9,说明程序是正确的,评估开发人员的能力和项目整体的质量。
项目管理软件如何让PM提升效率?
这里KEVIN在自己的产品群中简单调研过,其中不少朋友这样说。
【项目管理软件】
简单罗列为:TEAMBITION/禅道/PROJECT/WORKTILE/JJRA
看来不少的朋友还是以项目软件来管理相应的产品进度。这一点KEVIN分享的是在开发中,PM需要时刻了解目前开发的进度占整体项目或产品的百分比情况,当然EXCEL或脑图进行统计是没有错的。但以更好的项目软件管理能够时刻了解其进度与排期是否保持一致。并且能够了解相关负责人,这样可以保持不拖欠,保证后续需求可以有进有条的进行。
最后分享一下关于需求的时间把握,这也是KEVIN最近学习的深刻的地方。
时刻与需求方保持沟通,一旦产品排期推迟,与需求方同步。
优先级排定后,次优先级的功能点与需求方进行确定,准备相应产品评审
沟通不了的问题,保持上升,并且时刻注意同步,千万不要以打小报告的形式解决。
1877291205310372
已获得淘公仔
复制链接去分享
本来是运营🐱,然后最近为了对付省比赛,开始试水产品🐶+运营🐱混合。
用 Axure 做了一份原型,然后开始异想天开模式,动不动就灵感爆发在手机的备忘录写下来,继续丰富产品。
然后有三个开发实现生产,我基本天天跑到它们的房间,狂提需求,现在它们看到我都是躲着我的,特别是做网页的仁兄。。。
产品不可怕,就怕产品有文化,因为我网页也比较会,所以做网页的那个说做不了,我基本上都能提出实现的方法(应该会被打吧,逃~~)
keller.zhou
已获得优酷VIP月卡
复制链接去分享
程序员总是想尽量精简并按照自己的想法来完成一些功能设计,有时候为了完成功能,并不会完全按照最初的产品设计来执行,那么未来就有可能进行返工,产品会指责程序员没有按照设计执行,程序则会以各种功能无法实现为借口进行反驳,“无法做,无法实现”是最佳的刁难理由。
做产品的时候,总是想一开始就做一个大而全的东西,别人有的我要有,别人没有的我也要有,总是先模仿同类的其他网站,这样很难有自己的特色。程序员做的不是自己想做的,所以他们总是消极怠工,或者是代码考虑不周全,留下了未来的一大堆隐患,或者是本来可以很快完成的任务,他说是很复杂,这个需要做很久,以此来表达自己的不满和抱怨。
双方交恶的更本质的原因一般不在改需求本身,专业程序员不会反对改需求,一般的原因在于不相信程序员的专业性,举个例子,你要改动一个登录页面的流程,程序员告诉你,这个功能要两周才能做完,你说不行,一周必须做完。这样就没办法沟通了,不写程序的人决定一个程序多少时间写完(注意我说的是决定),这是很荒唐的一件事。一般的结果是闹到老大那里去,最后加班(加班从来也不是一种专业的表现)。
专业的产品经理不应该用功能的产生原因来说服程序员,这不是程序员应该关心的事,如果程序员关心这事,很好。但这不能起决定作用。同理,程序员认为产品经理需要懂写程序也是算流氓。
1个人同时扮演三个角色,会不会感觉很分裂~~
这有啥分裂的嘛,自己的产品自己做啊,然后自己运营,哈哈,爆棚感很强烈的!
两个啦。产品+运营
此乃神人也
厉害
111
支持国货
O2O
自己都干吧
程序员说:你懒的做的事情全丢给了我们
对头 自己做吧 这么厉害