我是半年的需求,开发常说我的功能难做,擅自简化。但我的PM找他做相同功能,他就能?

我是工作半年的需求,原先是前端出身,但是很长时间不接触,技术已经忘的差不多了。而且我们公司的开发技术好像都可以,不是瞎做一通混日子的那种,所以日常基本开发说什么能做什么不能做,我基本都信了。但是时间长
阅读全文
请先 登录 后评论
  • 0 关注
  • 0 收藏 102 浏览
  • 略问用户 提出于 2020-10-22 17:37:03

12 个回答

xxxxxa

产品经理为啥需求扔给技术之前要做需求评审和技术评审。。。

就是为了让大家都把话事先说完,不要跑到后面再抱怨或者修改。

一般而言技术工作不应该产品经理直接分配,而是技术项目经理在技术评审后项目拆解后分配。


如果你司缺乏技术项目负责人,产品经理直接对接技术时,那就对上管理做好,把项目质量控制权验收权放自己手上。

也就是开发时你不要去bb,周会或者项目会议上拖出来骂,直接验收不过关甩回去让他自己改。




按照你的描述的话,对产品的理解阶段当前尚只限于原型和前端,应该还属于产品初级阶段。那么你的最大问题可能在于产品设计上并不具备有专业性和权威度。技术并不相信你的判断,你需要慢慢进行打磨,能够从项目角度出发设计和思考产品契合团队目标,从数据角度/竞品等方面证明自己的观点,从团队上下管理层关系上借用权威展现自己的职能性。

而以上这一切,其实就是你要为证明自己的能力和为结果负责。


有些时候,产品对技术的妥协是必要的(如果你就是赶着从0到1上线,那么越快越安全的方案就是越好的方案,抓大放小不用拘泥过小的对原型的复原)

有些时候,精益求精一个像素也不能放过是产品经理的职能。

请先 登录 后评论
xxxxxa

擅自改需求,要么是技术不敬业觉得你好说话估计坑你,要么是工作流程不规范需求没有传达到位。

你这种情况应该属于一工作流程的问题,因为项目经理说改又改好了。

需求确定好后和技术过评审,他们评估开发时间和技术难点,如有有难点应该提出一起想解决办法,技术的问题技术们想办法解决,技术解决不了的PM再想其他方案,当然如果开发时间太长可以一起商量能不能把功能简化。

开发们评估后的需求给出时间排期后一般是不能擅自更改需求的,开发过程中遇到技术难度的问题说明技术评估不准确(技术能力的提问),开发过程中真的遇到难点也应该要找PM或者项目经理。

所以,技术如果擅自更改需求你这关肯定是不能让他过的。

还有就是在需求评审中一定要把需求讲清楚,尽量避免他们不理解需求的情况。

请先 登录 后评论
xxxxxa

程序员分很多类,其中一类是我见的比较多的(本人之前做过3年客户端),就是进入技术舒适区的这类人,技术一般来说不会特优秀,但业务也相对熟练,常规需求完成的质量也很好。

但是,如果你让他做个新的东西,比如在原有模块衍生个稍复杂的功能,他就很抗拒,并且希望你按他熟悉的需求来提。如果你这时候恰是新人,他更不care你,即使在你的方案老大已经审过,功能会也开过的情况下。

(人嘛,基本偏惰性的,优秀的人往往能突破舒适区不断成长,但毕竟少数。)

这个时候,你妥协就是你的问题,你的目的是啥?是按时完成上级给你指派的工作任务,不是自我安慰侥幸这个问题也是可解的,然后一直拖下去。

所以,有自己拿不准的,程序坚持说不可行的,第一时间找老大。不是说要去刚对面,而是先把手头的事儿给解决了,哪怕真是方案不行,推翻重新设计也很正常。

还有就是要意识到交际的重要性,跟程序关系搞好一点(偶尔的示弱也可以),那开发效率比你想象中要快很多。

请先 登录 后评论
xxxxxa

以下是我觉得你可以在以下几个方面思考:

需求评审:我觉得开发可以有自己的想法,以及站在开发的角度提出对产品的优化建议。但这些都需要在需求评审(我不知道你们有没有这一环节,这一环肯定是不能缺少的)里面大家协商好。如果在需求评审中开发提出的方案比我们产品拿出来的更好,那就要反思自己在设计过程中是否存在过度设计以及考虑不到位的地方。

评审后:一旦需求评审完成后,开发必须依照需求原型以及PRD文档要求完成功能开发。此时开发如果有想法和建议可以跟产品提,是否变更需求以及如何变更,这个也是由产品决定的。如果产品无法决定可以召开需求变更讨论会议。

是否该拒绝开发:什么时候拒绝开发,什么时候接受开发建议我觉得最重要的衡量标准就是:当前提出的问题是否有利于产品目标的实现,以及当前资源环境能否支持这个需求的变更。这是一个产品应该坚守的原则,但拒绝也是有技巧的,可以委婉一点并说出拒绝的理由。毕竟跟开发闹矛盾的确不利于后面的合作。

从你的描述来看:你们公司的开发应该也是个老油条了,对产品设计的功能不经过讨论就擅自修改。且存在欺软怕硬的嫌疑。对付类似这种的开发,最好就交给项目经理解决。让他把大家叫齐并在会上确定好相关规范,例如:需求变更规范、产品功能验收规范等!未来严格按照规范标准走。

请先 登录 后评论
xxxxxa

考虑问题不是只能从结果倒逼的,只从结果着手容易片面、遗漏……

我用最大包含(各种可能性)的形式都说一下:

首先从结果出发,说两个已经发现的问题

1 为什么项目经理说改就能改?

回复:

考虑下各岗位之间的关系?

判断岗位职权的权重高低?

是否绩效的决定权与项目经理有关?

多发散思考一下,抽象一下,你的问题是一个主流程,其他发散思考的都有可能是分支流程。

之前的环节中有没有工作留痕?邮件、讨论群等,

像我之前有一家公司,评审会必须签字留痕,为验收标准的一部分。

2 为什么你说改,就有难度,不可以?

回复:

设计是否有问题?

是否为最佳方案?

是否可以为难?

是否与开发驱动/产品驱动公司 有关?

开发未启动时,如何定义产出结果标准(验收指标)?

那么下面,放下结果,反之从起始说起:

需求定义是否精准?

从需求转化为产品时,最终拍板(评审会)通过,是否所有相关人员均参与其中?

需求、功能讲解时,是否阐述过各功能之间的关联性?

能够确定不是走过场,而是都参与进来,判断各功能的可用性?易用性?

评审会被批斗是常有的,

要么大家讨论开发过程中出现的不合理、不理解、调整功能输出形式,

要么就是个人能力输出有问题,可以检讨。

要么平平淡淡走过场,除了各部门领导,执行人员都没人走心听


最后说一句:

做事情多分析、工作多留痕、思维方式多样化。

请先 登录 后评论
xxxxxa

1. 在需求评审的时候,就跟开发讲清楚需求,不能实现的或者耗时间的需求,评估一下,看看是不是必须上,若必须上,就看看这个功能有没有其他呈现方式

2. 在交付开前,就和开发沟通好,在研发的过程中如果有问题、或事先考虑不充分的,及时告诉pm、并进行沟通,但开发不能擅自更改开发需求

请先 登录 后评论
xxxxxa

首先,开发如果不能按照原型来做,要让他们提前说,如果提前说了,可以换一种方式实现功能或者简化功能,你要懂一点开发,否则你没法跟技术撕逼。只能他们说什么是什么,就会被坑。

其次,在做的过程中,你是要关注的。做成什么样了。什么时候能做完。不能等他们都做完了再跟你说。

还有,你在做需求的时候,尽量要详细。而且要跟开发打好关系。关系好了,开发有什么问题自然主动反馈给你。

请先 登录 后评论
xxxxxa

产品的整体把握是否心里有数

一个功能实现方案可A可B可C

但你要学习沉淀知道每个方案  对整个产品、目标用户角色、当前和相关业务流程的影响

你就会慢慢知道

你去开发那里的时候,是带上刀、还是糖

请先 登录 后评论
xxxxxa

你的需求,影响他摸鱼了。他以前没做过这个,要百度查查才能开始做,有点麻烦。有些事情直接@他在最大的群,让所有人都看到,让他当面和所有人说:这个功能可以实现,需要100年。

研发研发,老是守着以前学的那些东西还叫研发吗,去做外包得了

请先 登录 后评论
xxxxxa

我现在的状态就是做功能就先问下开发他能不能实现,可以就先规划着,不能我就自己去百度看有没有做过的,没有就跟项目经理讨论这个功能会带什么需不要硬做,如果需要就让开发做,如果不需要就不做,如果有实现的就直接把功能做出来让他实现,走开发的路让他按我指的路走

请先 登录 后评论