为啥不做两个版本AB测试呢？
专家和新手用法不同很正常。
如果你们的软件都是中台架构或者是类似的，前端的工作量可以忽略不计。
你们都是为了面子而争吵。

1.产品经理能给你发微信沟通，看上去对事不对人，都是为工作
2.你从客户角度出发，这个绝对是对的，但问题是你认为的客户角度在当下这个项目确实真的是你以为的那样吗
3.你做了19年自己也说了都是成熟的套路，不可否认的是会有更明显的惯性和思维固化，作为领导和老人倾听一下其他有能力成员想法意见没什么坏处
4.意见不一致可以开会讨论群策群力或者直接领导拍板，你们分歧无非是用成熟的套路还是创新，那这个其实是你们公司定位和策略的问题，理论上只有领导能定到底是稳妥还是要尝试更高风险的方案（前提是项目经理那个确实有尝试的价值和优点）
5.你是顾问，职责不应该是确保大面的东西没问题以及风控吗，细枝末节之类也要管吗？权责咋界定的，看你描述还以为你是项目经理他是技术开发呢

王专家你好，为啥不找几个客户问问他们的意见呢，你们自己闭门造车还造出高潮来了iOS fly ~

能把他开了吗 不能就算了 你两互相需要的话说啥都没用

先点选按钮，然后再勾选？
楼主的表达能力有问题，几个截图的问题，写这么一大段语体教的文字！
我建议参考最权威windows资源管理器的业务逻辑，不能先点选，因为这步是多余的

回复49#陆仁贾

打开了新思路。的确是不一样的角度看问题。

做为一个啥都要做点的码农，才多大点事，不值得吵啊。
要做的是整套软件都统一，要不就直接可以改，要不就查看再改。我是偏向点开就改，方便啊，担心误操作可以加一个确认动作就行。

设计产品的时候从客户的使用习惯出发，看怎么方便他们操作、怎么防止他们出现误操作，而不是从软件开发的角度看怎么使用方便，因为好不好、方便不方便、对不对不能脱离使用环境，我通常也是真么理解的 iOS fly ~

你的逻辑用户习惯程度高，出错几率小，效率低

他的逻辑效率高，出错几率大，新用户需要学习成本

说真的都不是完善的方案，但一个项目稳定的重要性要远超效率，所以他的出错几率没解决之前，是你的合适。

要是团队愿意增加工作量的话，前后端可以用高效率的操作方式，加大量提示，防误操作，增加体验操作，反馈操作的方式解决问题。

回复1#betaly
你是对的。从交互逻辑上看，产品经理对这套逻辑的修改，主要是考虑了操作简捷这个交互原则，可以鼓励。但是这些软件除了考虑操作简捷外，要注意客户操作习惯性问题，当业界的龙头软件都是像你这种成熟的交互流程的时候，产品经理的这种改变就要慎重。你们这种软件稳定性、延续性比便捷性更重要，不能纠结于体验性，不能追求互联网企业的那种操作便捷的极致体验。你可以看到，阿里，亚马逊很多交互流程以互联网的视觉看，不是很便捷，但是客户操作已经习惯，流程就会一直稳定不变。 iOS fly ~

2b的经验很丰富啊，赞

让客户看看原型呗。

我觉得你们争议的不是技术逻辑，而是用户体验。
首先尽可能防误点，关键信息要有二次确认或者换人审核，其次尽可能符合使用习惯，尽可能减少鼠标点击次数。

想说按照他的做，出了事他负责。
但是有看到你股份更多。。。唉。不好出主意了。

不过他如果直接接触客户的话，需求把握应该更好些。

骂你，你就骂回去啊。有啥的。 ios fly～

只有选择没有对错，所以，谁是老板听谁的。

我记得这个体验好像是哪个新框架带来的。 iOS fly ~

lz的思路是，先选择操作种类，再选择操作对象；对方的思路是，先选择操作对象，再选择操作种类。

回复26#事故龙

感觉楼主先自己出个简单原型更好描述问题

如果是替换，还是无缝上手比较好

太专业的不懂，但作为客户来说看情况吧，如果客户都是行业内的熟手当然喜欢快捷操作。但如果是我们这些老年化单位，你的逻辑正确，每条确认比较好。要是过于快捷，不到三天有人能把基层数据瞎改了。

最终实现效果和操作方式，产品经理有决定权，开发只能给建议，做事情之前，先确定好自己的管辖范围。

1、工作职责是什么，需要明确，您负责您的部分，产品经理负责产品经理部分
2、产品界面原则上是产品经理有决定权的，您只能根据您的经验来建议
3、如果您强势或者是老板，可以选择和产品经理的上级沟通，或者由他的上级开除他

前产品经理现解决方案路过

从楼主描述的情况看，只是一个简单的入口形式的问题，其实用哪种方法都可以。
但是从这件事情上看，是楼主和项目经理的思路冲突问题。
看上去楼主是从客户学习的角度出发要保留国外软件的操作习惯，但是客户是否必须要保留这个习惯？或许客户对这个习惯早就深恶痛绝了，想要一个更加方便快捷的方式？这只是一个不涉及核心业务的小功能罢了。如果我是楼主，就要项目经理先和客户沟通好需求再下决定。
从另一个方面看，我不看好楼主这个项目的情况。
1、主要的项目负责人和楼主思路不一致，居然还入股了，这对公司来说是个非常大的问题。分道扬镳是大概率的情况。后面一堆烂摊子我就不细说了。
2、楼主在行业内是有很多经验的，但是这也意味着楼主的创新能力会受到严重的制约。销售和技术之所以是创造利润的源泉，就是创造力高。如果你的产品更快更便捷，那么就可以变成你的一个卖点，如果是跟传统软件一样，也可变成你的卖点，不管怎么样，销售一张嘴，黑的要能说成白的。纠结于能不能被客户接受，这本身就是一种极端的不自信，对于销售是非常大的缺陷。

最后，如果已经拿到项目了，那就要尽量先完成，把业务逻辑走通，然后把产品卖出去，收钱回来。至于这个项目经理，就看楼主你容不容得下人了。

先选择操作对象，再选择操作方式。

你看看哪个操作系统是先选择我要复制，然后让你选择复制哪些文件的。

哦，命令行是你说的方式，我得先敲命令，也就是操作方式，然后再敲操作的对象，比如被复制的文件。

为什么这样？因为命令行没有GUI方便啊。所以你想做个界面，按命令行的方式实现，就因为有个老爷车系统也是这样的方式？

作为一个saas软件里面的开发，来支持一下49楼，计较这些细枝末节的交互要看你的项目阶段来决定，要知道替换一个saas系统是一个年位单位的周期时间，先快速实现你们系统解决客户痛点的功能，其它的细节可以在后续交付过程中，不断的优化，保持需求的快速迭代，受理，才是良性发展

体验上，我觉得他是对的。
习惯层面，你是对的。
我的建议，这两种方式完全可以共存，稍微做下兼容就好了。比如，单列三个增删改查键可以做全局操作。也可以在单个字段上弹框来控制操作。
难度不大啊。

回复52#betaly


这点前端没多少工作量啊。

回复80#betaly


也不算完全的业内人士，做过几年甲方，手上管过一些项目，有成功有失败。
个人经验，如果是替代方案，客户关心的主要三点，第一是业务流程基本不要动，要动也是在和各部门详细沟通之后动；第二是操作界面不能比原系统复杂；第三是切换的周期要短，成本要小。
至于菜单怎么打开这种事情，并不是客户考虑的重点。

回复83#betaly


哈哈，小钱无所谓，加个微信交个朋友好了。这件事情上，我是觉得在项目初期反而和稀泥是最好的解决方式，帖子里不少兄弟都是非此即彼的态度，这样是搞技术，搞项目不能这样的。项目成败很多是在于你不一定是最好的，只不过是很多情况下看起来最合适的。那么有时候搁置争议，让市场去检验。我同意你的是你告诉我那是行业的习惯，赞同不要这种交互方式的如果项目招标中万一有个人说这样不方便，还不如之前软件，业务会被客户搞的哑口无言的。另外，项目经理产品经理如果这样和技术业务沟通，一定要被我开掉的。大家是一起做事并不是来吵架的。万事总有解决方式，哪怕是错的。项目经理是来推进项目进度的，保障资源的，而不是自己来阻碍项目进度的。产品经理是来解决产品需求和客户需求的，而不是认为i自己的想法一定对去贯彻的。至少我们还没到乔布斯的层面。

我没用过你的软件，但是我在医院经常用到另外一种软件，你干啥他都要提示，都要审核的，非常难用，大家都深恶痛绝。我们逻辑是这样的，如果出错了我们可以退，可以改，但是不要求设置太多前提条件。 iOS fly ~

我觉得他的逻辑很好。你写一个国产软件不一定非得按照国外那套生搬硬套。有更好的逻辑为什么不用上？至于是否符合用户习惯？那得用户说了算。

先回一帖晚点来看。 最近我也经常和UX 和 TPM 吵，但总的来说还是要在现在这个大环境下，把软件先搞出来。

回复53#betaly

习惯是很重要的，但是一边使用一边骂人的习惯就不太好，我想问是不是先看内容再决定是否删除，这样的话你先点删除再找文件就不方便了吧，不方便筛选

突然发现我保存了这个帖子，本不想回复，但作为当事人还是站出来说几句。

LZ一直对标的是一款十多年前的系统，和他说了现在系统的操作方式，他表示接受不了。
我说你可以参考下新版的系统，人家的软件也不是说一直停留在十多年前，我还给他找了对标系统的官网，他说没有试用账号，也找不到有人在用新版，我当时也挺无奈。
前段时间，我上U管，查了下，找到了这个系统在U管的不少视频，应该是官方出的类似于教程或者介绍，从视频中可以看到，无论UI界面还是操作方式，变化都很大，而且操作逻辑根本不是他说的那样。即便是这样，他还是想坚持他的观点。

对于这样的合作伙伴，我确实很无奈。

有些场景是可以使用instant edit的，两种方式都兼容也不是多复杂，非得吵？

~ fly ~

积累到一定时候，才吵的。单纯一件事，吵不起来。

这个得留言先说我自己，原先是乙方给客户做业务ERP系统，后来客户觉得外包太慢，直接把我整过去成立部门带个小团队开发。
其中有点转变，以前自己就是项目经理，目的就是完成客户功能，所以思考问题的角度偏开发，长期积累的经验，也会自以为是；但是现在到客户公司后，可不一定这么思考问题，会从业务实操去要求开发人员提高业务的用户体验。

1、楼主跟产品经理争执是好事，对事不对人，最终大家能统一思路就好，但是骂人肯定不对；
2、关于操作按钮，也就是页面布局
从产品经理角度，原来点击一次鼠标，就可以弹出页面，变成先选择、再点按钮，再点修改，点三次，从他角度，真的会觉得shabi；
从楼主角度，跟随原来系统的操作习惯，也就是上手快，但是真不一定提高工作效率，这就是你经验导致你以为你绝对正确，其实总归有改进的空间；

我觉得楼主应该重新评估，毕竟你是行业专家，考虑风险同时也要考虑效率，产品经理是提供你另一个角度重新审视你的产品，这是好事，你们完全可以心平气和的就事论事，为了完美的产品。

以上我只是讨论这个问题，至于管理上分工不同，这个应该也不是障碍。

楼主的方案更合适。减少出错，这也是客户希望的结果。

在页面上直接修改看起来方便但是出错利率更大。


另外，这个项目到底谁说的算，不管什么位置讨论中骂人算个什么素质。

iOS fly ~

到底是查看后修改，还是查看和修改同时出现，这个是整个产品的基本逻辑，取决于数据重要性和修改的频繁性，不该一开始就定好吗？
我反正在大面积开工前确定好这些内容，多开几个定案收口会，过程中少来和我扯需求

客户当然希望更方便，但出了问题还是要你们背。是安全重要还是省个步骤重要？

坦白讲…这个不重要

sf把。

他的几个模块是挺贵， 订单、财务等。

我记得有个公司想切这块，以第三方插件的方式，提供服务，当然还在sf的数据基础上。

如果是我说的情况，我建议你们先想想如果被sf封了接口怎么办，按道理是按道理，商业公司做点操作都是很正常的。

除非你们是完全抛弃sf。