这是一个创建于 1988 天前的主题，其中的信息可能已经有所发展或是发生改变。
前几天有个 Java 程序员死活不愿意改程序，都吵起来了，说你又不是产品经理（我是技术总监）凭什么要我们改，产品经理的文档就是要求做成这样子的……
作为一个十几年前就已经是程序员老人来说，我们当年都是和项目经理一起去和用户碰需求，自己做设计画原型，都是在我们的脑海里从一个假想的画面，或者功能，然后通过自己的双手逐渐变成现实，那时候那种成就感是无与伦比的！
实话实说，我觉得我们这代人天然觉得自己作为程序员，作为软件工程师，天生就是应该是去思考如何用我掌握的技术，去思考、去设计系统该做成什么样子的人。系统在性能、稳定性、人性化、交互流程等等多方面都是应该是软件工程师能力的体现才对，特别是掌握如何将系统设计的更人性，更友好的能力，和想办法掌握某个编程语言的能力都应该是一个程序员工程师应该追求的能力啊。现在炒的火热的微信产品经理张小龙，还有大家熟悉的马化腾、雷军、周鸿祎等等，这些人那个当初不都是程序员吗？
这几年我带团队，我和新一代的程序员聊过很多次这个话题，他们的理由基本上都是说程序员都是不善于沟通的群体，就应该专注写代码，这些事情应该交给更善于沟通的产品经理去做，任何系统都是一大帮人团队配合的结果，你怎么可以让程序员去设计和了解需求，这样是非常不专业的……你以前干的都是小 case，我们是干大家伙的（实际上我以前干的系统比现在大得多和复杂的多了）！
实话说如果有特别靠谱的产品经理，我也的不介意让需求沟通、产品设计这事由产品经理分担去做，但是这几年和一些产品经理接触下来，我自己感觉真正靠谱的产品经理那是比程序员少太多太多了。程序员想法其实在再不济，好歹也是能把问题解决吧！但是很多产品经理因为不了解技术，往往很多时候把简单问题复杂化，甚至让沟通更复杂困难，问题反而解决的不好了。甚至有些产品经理觉得自己不懂技术才是优势，他们觉得懂了技术就局限了自己的空间，这样产品就会变得没有“创意”了，你和他讨论产品的设计，他反而会用你太懂技术了，所以你的想法不行用户不会接受的这种观点来拒绝你……无语……
我一直和我们的工程师说，github 里头的各种开源项目，Appstore 里头的大量 App，其实都不一定是产品经理带领下完成的吧，这些这么优秀的产品，不都是一帮、甚至只有一个程序员、软件工程师呕心沥血的成绩吗？现在语言的发展和技术的创新发展，不都是在让程序员变得更复合，更独当一面，似乎并不是变得分工更细，更专注只是编码啊！（ MD 我感觉现在写起代码来比我们那个时候简单太多了）
所以现在在我自己的团队里头，我一直在坚持要求程序员自己一定要去参与设计产品和系统。但是这么做下来，脚本语言的小伙伴还算配合和理解，但是后端 Java 的这帮人真心是不接受，很多时候和这帮人沟通我都有种绝望的感觉，所以有时候我也是真是挺迷茫的，也许是我真的已经 out 了，难道我真的 Out 了吗？
作为一个十几年前就已经是程序员老人来说，我们当年都是和项目经理一起去和用户碰需求，自己做设计画原型，都是在我们的脑海里从一个假想的画面，或者功能，然后通过自己的双手逐渐变成现实，那时候那种成就感是无与伦比的！
实话实说，我觉得我们这代人天然觉得自己作为程序员，作为软件工程师，天生就是应该是去思考如何用我掌握的技术，去思考、去设计系统该做成什么样子的人。系统在性能、稳定性、人性化、交互流程等等多方面都是应该是软件工程师能力的体现才对，特别是掌握如何将系统设计的更人性，更友好的能力，和想办法掌握某个编程语言的能力都应该是一个程序员工程师应该追求的能力啊。现在炒的火热的微信产品经理张小龙，还有大家熟悉的马化腾、雷军、周鸿祎等等，这些人那个当初不都是程序员吗？
这几年我带团队，我和新一代的程序员聊过很多次这个话题，他们的理由基本上都是说程序员都是不善于沟通的群体，就应该专注写代码，这些事情应该交给更善于沟通的产品经理去做，任何系统都是一大帮人团队配合的结果，你怎么可以让程序员去设计和了解需求，这样是非常不专业的……你以前干的都是小 case，我们是干大家伙的（实际上我以前干的系统比现在大得多和复杂的多了）！
实话说如果有特别靠谱的产品经理，我也的不介意让需求沟通、产品设计这事由产品经理分担去做，但是这几年和一些产品经理接触下来，我自己感觉真正靠谱的产品经理那是比程序员少太多太多了。程序员想法其实在再不济，好歹也是能把问题解决吧！但是很多产品经理因为不了解技术，往往很多时候把简单问题复杂化，甚至让沟通更复杂困难，问题反而解决的不好了。甚至有些产品经理觉得自己不懂技术才是优势，他们觉得懂了技术就局限了自己的空间，这样产品就会变得没有“创意”了，你和他讨论产品的设计，他反而会用你太懂技术了，所以你的想法不行用户不会接受的这种观点来拒绝你……无语……
我一直和我们的工程师说，github 里头的各种开源项目，Appstore 里头的大量 App，其实都不一定是产品经理带领下完成的吧，这些这么优秀的产品，不都是一帮、甚至只有一个程序员、软件工程师呕心沥血的成绩吗？现在语言的发展和技术的创新发展，不都是在让程序员变得更复合，更独当一面，似乎并不是变得分工更细，更专注只是编码啊！（ MD 我感觉现在写起代码来比我们那个时候简单太多了）
所以现在在我自己的团队里头，我一直在坚持要求程序员自己一定要去参与设计产品和系统。但是这么做下来，脚本语言的小伙伴还算配合和理解，但是后端 Java 的这帮人真心是不接受，很多时候和这帮人沟通我都有种绝望的感觉，所以有时候我也是真是挺迷茫的，也许是我真的已经 out 了，难道我真的 Out 了吗？
 |
1
wdlth 2019-07-21 00:27:20 +08:00
等你让他们去做需求，会更杯具，产品会更加烂，和闭门造车差不多。
|
 |
2
mnssbe 2019-07-21 00:28:10 +08:00
技术总监管不了程序员？？
|
 |
3
shaolin 2019-07-21 00:33:53 +08:00
死活不愿意改，又不是啥优秀的人，在沟通沟通实在不行就强势点，在不能商量出个双方都接受的结果，就让他换个工作呗
|
 |
4
Maboroshii 2019-07-21 00:39:23 +08:00  1
如果有充足的时间，研发也会想慢慢打磨产品的吧。
但是实际上，每天破事一堆，能简单实现就简单实现了 |
 |
5
kyuuseiryuu 2019-07-21 00:43:07 +08:00 via iPhone 1
把你们的产品经理岗位换成需求分析员，然后你们的程序员就愿意改了。
|
 |
6
thomaspaine 2019-07-21 01:22:09 +08:00 19
文不对题啊，这个是流程问题。程序员该不该参与产品设计？应该。怎么参与？自己觉得不合理的地方向产品提意见，据理力争，让他接受。
不然直接改产品需求和产品设计吗？ 具体到文中这件事，up 作为技术总监，觉得产品设计不合理，应该和产品实际负责人商量怎么改吧？怎么能直接让程序员改？ |
 |
7
seki 2019-07-21 01:35:15 +08:00
没懂，要改的话不是应该先推动产品经理去改设计吗，贵司开发自己设计了之后和产品的设计有冲突怎么解决？
|
 |
8
night98 2019-07-21 01:37:56 +08:00 1
想法粉好，前提是贵司的工期给的比较足，也就是说开发要有足够的时间去思考这些内容，否则手头上的开发工作都做不完的话，怎么可能还会去接受思考产品需求的合理性及改进空间？
|
 |
9
limuyan44 2019-07-21 03:54:34 +08:00 via Android
产品的工作是增加需求，技术领导的事是如何减少需求。
|
 |
10
version 2019-07-21 05:06:04 +08:00 via iPhone 7
现在好的专业懂逻辑和认真负责的产品经理都跑去了互联网大企业了，这几年小企业的很多 2 万+的产品经理都是 985 转行业过来的，业务逻辑和流程上互斥也是不知道的，技术和他们这些人解释就是浪费生命，需求就这样下来了
大部分开发都是工作依赖分配，自检接口依赖测试人员，出问题不是我的锅，测试不提的 bug 发现也装不知道， 我是不愿意和 java 打交道，等他接口一周，效率低到离谱，和我讲各种设计，985 研究生，没办法，不敢怂，上线服务老断，不稳定，后来跑去阿里当 p6 国内就这样环境，一个团队总有关系户，坑人户，无解，只能是 996 慢性死亡的技术部 大环境就这样，后来我是不愿意待了，一年只有下班自学到的东西，企业技术代码营养都是负能量 |
 |
11
Yvette 2019-07-21 07:22:13 +08:00
程序员和软件工程师是两个工种
|
 |
12
whileFalse 2019-07-21 07:44:45 +08:00 via iPhone
那需求评审会的时候你为啥不去呢。
|
 |
13
1024MB 2019-07-21 07:45:34 +08:00 via Android
double 工资吗？
|
 |
14
misaka19000 2019-07-21 08:06:41 +08:00 via Android
？？？需求分析的时候你干嘛去了
|
 |
15
stephen9357 2019-07-21 08:23:10 +08:00 2
看描述你直接找程序员要求修改？有跟产品经理沟通过么，万一改完了，产品经理不同意，非得让改回来怎么办？你这做事方法就很有问题啊。
|
 |
16
jinhan13789991 2019-07-21 08:27:48 +08:00 via Android
就问你，改出事故谁承担责任
|
 |
17
jucelin 2019-07-21 08:29:54 +08:00
楼上好多人，能不能看完全文再喷跳过产品经理沟通的“ BUG ”啊！！！
LZ 的讨论不是这个 BUG 啊！！！ |
 |
18
raynor2011 2019-07-21 08:34:42 +08:00 via Android
可以考虑，但程序员不能擅自改变
|
 |
19
cabing 2019-07-21 08:40:48 +08:00
不是楼主 OUT 了。
产品是人打磨的，人不仅包括产品经理，也包括程序员啊，程序员除了保证系统的健壮性，稳定性，可维护性，也需要考虑产品的合理性。我们现在也是产品出产品方案，然后和技术过一遍合理性。但是也会涉及到话语权的问题，有时觉得合理也不一定能有反馈，有时也没有话语权。 产品经理的设计文档问题，是否和产品经理，程序员一起简单沟通下~~ 有可能是这几方面的原因~~ 1 程序员担心被甩锅 2 程序员担心改来改去 3 程序员的设计有问题，这么改动工作量大 |
 |
20
opengps 2019-07-21 08:41:56 +08:00 via Android
脱离开发的产品经理也不是什么靠谱的产品经理。
团队作战需要的就是沟通 |
|
21
opengps 2019-07-21 08:42:55 +08:00 via Android
另外就是，程序员自己本身也排斥被当做工具，被安排执行
|
 |
22
xuanbg 2019-07-21 08:44:52 +08:00 1
我去！上面的回复简直不忍直视。。。天天喊着程序员是青春饭的是你们，不愿意在业务上下点功夫积累的也是你们。就你们这个认知，也不要等 30 岁 35 岁了，凡事都是赶早不赶晚，你们明儿就赶紧地、麻利地转行了吧。
别不服气，就你们平常写的那些破代码，一个智商在线的人我能三天教会。不说能解决多大问题，写的 bug 多不多，效率高不高，至少能够面向搜索引擎编程，能把一些简单的逻辑实现了。这说明什么？这说明现在写代码这个事情的难度和拧螺丝一个级别了呀。。。码农不再是程序员的自嘲，而是真的有了呀。。。但是，现在能解决业务问题的高级程序员还是非常稀缺的。 言尽于此 |
 |
23
kerr92 2019-07-21 08:46:37 +08:00 via iPhone 1
我也想问需求评审的时候你们干嘛去了……产品不提需求不要随便改现有功能，不是很正常吗？？？
|
|
24
xuanbg 2019-07-21 08:50:33 +08:00
我觉得，大家可以考虑一下当产品学会写代码的时候，作为只会写代码的程序员，该何去何从
|
 |
25
hoyixi 2019-07-21 08:51:08 +08:00
扯，职责不分，没有流程，最后的结果就是：加班，加班，加班，低效，低效，低效
|
 |
27
jorneyr 2019-07-21 08:53:26 +08:00
程序员设计的产品，很容易带入极客思想，而用户需要的是傻瓜化的产品，术业有专攻，当好自己的码农即可，产品设计、用户体验设计师不是摆设，你什么都干是因为你们没人、穷而已。
|
 |
29
ChefIsAwesome 2019-07-21 08:59:01 +08:00 3
“这个地方有问题，应该重新做一下”，有权力发表这种意见的只有老板。等东西做完，老板说不行的时候再改才是最安全的。老板懒得看，或者觉得没问题，程序员费那劲掺和，搞不好还跟产品经理闹得不愉快，何必呢。
产品烂，反复改需求，推倒重做，都不是大事。跟重复劳动比起来，老板觉得产品很好，开发没活干才是更可怕的。 愿意参与产品设计的程序员都创业去了。职场上班，没人愿意趟浑水，老老实实拿工资，不得罪人。 |
 |
31
loginbygoogle 2019-07-21 09:24:06 +08:00
敢和产品抢饭碗？打一架打一架
|
|
33
loginbygoogle 2019-07-21 09:37:36 +08:00
其实我很赞同楼主的观点，但可能每个人所擅长的或感兴趣的东西不同吧，有的人就喜欢技术型的东西，对产品不感兴趣。而有的对产品或 UI 有色天赋级别的爱好，却成了个 Coder。但我认为一个好的产品经理应该同时具备 Codeing 和 UI 设计的能力，这样才能在某些功能的设计上做的更加符合实际，能够极大的提高团队的沟通效率和开发效率。
|
 |
34
mcfog 2019-07-21 10:22:10 +08:00 2
我赞同工程师应当有产品素养，但不应当是为了替代产品的职责，而是为了正确找到产品需求和具体实现复杂度的平衡，产品即使懂技术，他也不了解项目的具体实现和技术债，所以产品需求当中一定有“虽然是好的体验但并不值得大量的研发维护成本”的部分，和“其实不需要太大成本就能做到更好的体验”的部分，工程师应当负责填补这个空白
我觉得楼主作为技术负责人，对产品团队若有若无的敌意是非常不可取的，先抛开产品团队其实并不差的可能性（你是否真的理解产品工作的复杂性？），即使产品团队真的不行，作为技术负责人，应该做的也是和产品负责人沟通交流看能否改善，产品负责人也不好沟通就和老板沟通。同时一定要避免煽动团队对抗产品经理，下面的人对抗就算了你作为领导也对抗那整个公司的协作配合的氛围就完蛋了。就好比销售和风控，开发和测试的关系是一样的，指责上可能有冲突，但团队之间一定是要配合的，讲默契的，这个氛围是需要双方领导一起来建设的 |
 |
35
CF3B5 OP @thomaspaine 其实很简单，有些需求会存在架构设计问题，很多时候需求可以实现，但是完全实现的话，会影响整体的系统架构，给系统带来一些负面影响，这些产品经理大部分不会知道也不会懂！很多时候这些问题也不一定是在需求评审中发现的，那么本来就需要程序员要思考究竟什么是系统最总要的，用户要的究竟是什么，来判断一个双赢的设计，而不是完全依靠产品经理指引去做！
|
|
36
CF3B5 OP @mcfog 我其实对产品经理没意见，我有意见的是现在的很多的搞技术的这帮人，年纪轻轻，思维固化的厉害！我们那个年代，学了点技术就像应用起来，自己写网站，开博客，主动去想很多办法把自己所学的东西都用起来！但是感觉现在很多做技术的，完全就把自己当成了一个打字的！产品好不好那是产品的事情，有没有 bug 那是测试的事情，自己每天就是打字，只要需求完成了，不出 bug，绝不会改第二次，还觉得这才叫负责！系统出任何问题都是别人没有把问题告诉他，和这些人沟通太 TMD 难受了……
|
 |
37
chmaple 2019-07-21 10:48:38 +08:00 7
@CF3B5
我的观点就是你有毒。 你觉得有问题第一步要找产品经理，都进入开发阶段了，还直接让程序员改，有没有一点规则概念？？？？ 这不是你一个人过家家的事情，前端、后端、交互、UI、测试、产品，多方共同参与的。都进入开发阶段了你有问题就应该找产品、找项目的开发负责人，而不是扯一个程序员来批判，有病吧？ 我做项目，别说你技术负责人，顶头 boss 让我不按照需求去开发要我改东西我都不搭理，都进入开发阶段了，你要改可以，找齐产品、开发负责人、测试负责人，需求变更的会议记录通知到所有人，不然改出事情了归谁？早不说干啥去了？还一大堆大道理，一堆的“我们当年”，还一堆的“感觉”，看把你能的。 |
|
38
chmaple 2019-07-21 10:52:24 +08:00 3
@xuanbg 他不能每个都参加，那么至少项目应该有开发负责人吧，开发负责人吃什么饭去了？有问题来怼一个程序员而不知道和产品沟通、不知道问责负责人，我不明白这人什么思维。
而且话说的很明白了，“产品经理的文档就是要求做成这样子的……”，这句话明显就能看出来需求早就确认了，而且已经开发完了，谁允许这个所谓的“技术负责人”越过产品经理或者项目负责人直接改需求的？ |
|
39
chmaple 2019-07-21 11:08:22 +08:00
@CF3B5
而且需求是需求，技术是技术，别把两者混为一谈。 项目的需求，从下发需求文档、批注、评审、签字，这么长的时间你想改什么觉得有什么问题随便提。都签完字进入开发阶段了，除非涉及到流程不正确会卡死或者存在非常非常大的问题的情况下，会采取通知项目负责人和开发负责人以及相关人员一起修改，否则谁来说都应该是不做不改，你是产品经理还是咋滴，这个项目你是负责人吗？你要改大家知道吗？产品知道了吗同意了吗？ 技术是另一回事。我这边项目开发完，每个人都有自己的学习计划和技术分享安排，爱搞权限的搞搞 shiro/security/jwt/sso 之类的，爱搞数据库的搞搞 es/elk/mongo/pg，爱玩网络的搞搞 nio/netty/dubbo。程序员这方面做的不好，不愿意学习，不愿意按照你的要求做技术调研，这个你可以随意喷，开了都是你的权利。 “只要需求完成了，不出 bug，绝不会改第二次，还觉得这才叫负责”，这就是负责，需求都完成了还没 BUG，只要代码 review 没有明明白白的错误（我们这边是违反阿里 java 规约、或者存在明显不合适的实现方式的时候），你凭什么要去改别人的代码？ |
 |
40
ww2000e 2019-07-21 11:16:52 +08:00
现在有产品的公司，产品是主导，不要越界，你为何不去说服产品。。
|
|
41
CF3B5 OP @chmaple 其实这就是我很困惑的地方，是不是这个世界上所有的系统和软件项目都是前端、后端、交互、UI、测试、产品这个流程组合走下来开发出来的？我翻了很多项目，查了很多公司的成功产品的开发过程，实际上大部分项目的成功，其实都归结到项目程序员工程师的设计和思考功劳居多，特别是一些核心技术人员支撑起了整个系统架构，从 Linux 这个全世界最大的开源项目，小到 Github 里头成千上万的各种模块应用，基本上都是工程师的心血结晶！你在世界上，能叫得出名字的软件系统，几乎背后的名字都是技术，而不是产品，UI 或者交互这些人！现在所有的软件技术发展，无非都是 2 条路，要么性能更好，要么就更简单，更融合，更跨界！整个大方向似乎都是让工程师变的更全面，而不是分工更明确！
|
 |
42
janxin 2019-07-21 11:30:38 +08:00
看情况决定处理：
如果之前与产品讨论过，并且确定方案要按文档这种方案执行的这样做没有问题，你去强制推动修改并不合适。 如果产品沟通已经确定需要修改，这种害群之马的开发开了就开了，无所谓的。 |
 |
43
xx19941215 2019-07-21 11:38:10 +08:00
我赞成楼主的想法 工程师需要考虑产品的可使用性、用户体验，技术最终是要面向用户的，工程师需要为整个工程负责，不然就不能称为「工程师」。
|
|
44
CF3B5 OP 1
@chmaple 不知道你有没有看过《代码大全》这本书！要知道，代码中的是有坏味道的，而且很多代码也是会随着项目的发展慢慢腐化的，很多时候刚开始做出来的菜，也许确实能吃，吃了也死不了！但是不好吃是普遍存在的，刚开始的好吃的代码，慢慢也会变得难吃！这些不是我瞎掰的，很多专业方面的书籍也是这么说的，程序员追究自身水平的提高，很重要的一点就是降低自己代码中坏味道，让自己的代码更简洁，更优雅，更解耦，更灵活，这些貌似都不是产品经理和文档能够给到程序员的把？如果程序员在这方面没有追求，认为只要能跑不出问题，遵循代码规范就是好的程序员吗？至少我看过很这方面的书似乎都不太认可这个观点……
|
|
45
chmaple 2019-07-21 11:53:18 +08:00 3
@CF3B5
我俩站的角度不一样。 你想表达是程序员作为主导的项目中，程序员应该有的素养。 而我所站的立场，是在项目开发过程中的程序员应该做到的，需求既定的情况下不应该贸贸然改动。 如果把你今天这一堆观点和起始事件剥离开来，单纯看你的观点，我举双手赞同，程序员应该做到进步无止境，无论是技术还是风格。 而回归到你“现在做程序员（工程师），难道不应该考虑自己负责的产品设计工作吗？”的标题，应该考虑，事实上就必须要考虑。但是这个考虑是在需求文档确定之前的，确认开始开发之前凡是不符合规则、不符合实际、存在问题的需求，都应该被改正过来。 需求既定的情况，就要做好程序员的本分。本分是什么，拿着别人的钱，按照别人的要求开发出合格的软件，这个合格是主导项目的人来制定规则的，而不是由程序员。 之前我的言辞过于激烈了，很抱歉。 |
|
46
misaka19000 2019-07-21 11:55:01 +08:00 via Android
楼主真有毒，还好你不在我们团队，不如就完了
|
 |
47
linZ 2019-07-21 11:55:13 +08:00
其实根本问题是后端不愿意理解业务，说是啥就是啥。。产品多数不靠谱，对话都困难。。讲道理，需要有个人来领导一下（是不是就是卖苦力的意思。。。），他来帮忙推动各个事情，要不就满满磨合。。个人意见。。
|
 |
48
inwar 2019-07-21 12:05:21 +08:00
程序员当然要关注产品,开发也要有流程和记录,楼主如果作为技术负责人应该着力去推流程的机制,比如开发问题反馈机制,推动搭建产品沟通窗口。
针于单人单事做规则以外的事情,谁都怕麻烦,程序该完到时候和产品对不上版,到时候两边都有理,就很难处理。 |
 |
49
IanPeverell 2019-07-21 12:12:06 +08:00
你如果比产品经理还专业，那要产品经理干什么呢？你这边把这块改了，产品那边看了会怎么想？你一嘴他一嘴最后改得乱七八糟的最后还不是你来收拾烂摊子。既然有产品来设计，你就把你的看法跟产品说就完了，改不改改哪里最后由产品来决定就完事儿了。要不然谁都是产品经理了，谁都来说一嘴最后到底听谁的？
|
 |
50
MeteorCat 2019-07-21 12:13:23 +08:00 via Android
最开始需求文档写了吗？
|
 |
51
Takamine 2019-07-21 12:17:08 +08:00 via Android 1
请把岗位工作范围和权力放到一起谈，不要只给工作不给权力。到时候说没按照需求来的时候，背锅的是谁。哪怕参与进来了，但是话语权最终是又给了谁。
你也许想建立一个大家齐心协力打造一个好的产品的氛围，但是这不是一朝一夕之功，更不是就单方面要求程序员参与进来的问题。 如果说你司的程序员招聘要求就是产品开发设计并岗，那我觉得在招人的时候也说清楚比较好，免得彼此误解岗位职责定位。 |
 |
52
Vegetable 2019-07-21 12:32:41 +08:00
现在非常需要在软件开发行业开展职称评级，初级的不叫工程师，叫技工。
很多人觉得楼主司流程存在问题，但是他说的问题的确是真真确确存在的。技术技工完全不关注产品。很多人连产品本身的功能都不知道。产品经理和程序员能力的交集应该是对产品的理解和设计能力，产品经理多了沟通需求的能力，工程师多了编写代码的能力。 |
 |
53
hefish 2019-07-21 12:44:39 +08:00
真舒服，居然还有技术总监帮忙考虑产品这一块。 我们都是程序员自己想，搞的累的一塌糊涂。
|
 |
54
gamexg 2019-07-21 13:01:07 +08:00 via Android
两个可能：
一是，开发想尽量事少。 二是，开发如果提了建议，或者自己做了认为正确的修改，却被产品顶回去，多来几次就变成了要么走认为，要么忍了。 |
 |
55
mumbler 2019-07-21 13:01:32 +08:00 via Android
@CF3B5 我明白你想表达的东西，程序员这个群体现在很多人看工资高培训一下就进来混饭吃的，他们不热爱编程，也不爱自己做的项目，能少做绝不多做，不主动学习。真正的程序员都会像你一样思考问题，不用说服哪些混子，他们未来注定会被淘汰的
|
 |
56
chrisstyle 2019-07-21 13:49:28 +08:00 1
赞同楼主！
程序员首先要技术方面是专业的，大部分公司都是业务为主，这时候技术专业就是能根据业务快速设计合理的架构并产出，而如何写出好的架构？不理解业务设计个啥架构？产品设计的好不好，作为程序员心理没点逼数能行？ 而且程序员了解业务，具备业务分析能力，这才是竞争力吧！甚至于能技术驱动业务--->这种太少了，也是阿里 p7 以上的基本要求。 |
 |
57
leafShimple 2019-07-21 14:13:07 +08:00
- - 我也不知道该怎么样好,一开始项目的产品不给力，我们开发自己去调研需求，产品有意见就想叫我们加班，后来换了个需求。
我梳理了业务,他连需求文档都不写了,我给他讲明白了，我发给他的一段话，他复制过去直接叫我做需求.需求评审叫上一堆测试就评审了. 看了楼上各位前辈的回答,我也在想知道怎么做的更好.目前的新项目,开发嫌麻烦,需求产品觉得你给他找事儿. 我也觉得我做的项目能有很多人稳定高效的使用是一件有满足感的事儿 |
 |
58
leafre 2019-07-21 14:15:29 +08:00
程序员学会吹牛就可以去应聘产品经理了
|
|
59
CF3B5 OP @leafShimple 实际上在我的经历来看，不靠谱的产品比不靠谱的程序员多的多去了！国外产品经理都是要技术背景的，甚至是技术做的足够好了，所以才转做产品。国内现在恰好是反过来的，产品经理以不懂技术为荣，技术干不下去了，才去做产品经理！实际上我最近还较真的去找了一下，真正标榜是产品经理做起来做的好的产品在网上屈指可数！反倒是实际上由程序员或者所谓的码农创立的产品做的比较好的比比皆是！举个最简单例子，v2ex 这个论坛的创始人刘昕不就是程序员吗？难道你们觉得他的想法就没有产品经理设计的好，v2ex 里头充满了不合适的功能和技术？大家不用的挺欢的吗？
所以我一直不明白新一代的这些程序员你们菲薄些什么，现实的情况究竟是真的产品经理做的比程序员做的普遍都专业，还是说实际上大家们在营造一种气氛去降低对自己的要求以求安逸？天天盯着电脑，重复敲着类似的代码和用现成技术框架，CVCP，这就算程序员该有的一生了？ 老说程序员是青春饭，老说自己年纪大干不动，写不了代码，生产线当然谁也干不了一辈子，但是工程师绝对是可以干一辈子的工作啊！ |
 |
60
snoopy1024 2019-07-21 14:59:39 +08:00 via iPhone
@opengps 本来就是工具，排斥什么？都是打工的
|
 |
62
wyz123723 2019-07-21 15:11:33 +08:00
貌似楼主不明白一个道理，现在这社会，又懂技术，又懂产品的人是不会当程序员的
|
 |
63
sigone 2019-07-21 15:12:29 +08:00 via Android
该干什么就干什么，不要越权也不要越级。
|
 |
64
swulling 2019-07-21 15:17:55 +08:00 via iPhone 1
责任和权力是对等的
你希望开发自己可以自行修改产品设计，那你先得授予他们修改产品设计不被 PM 怼的权力 不下放权力，只提要求和责任，是 Manager 最失败的地方 |
|
65
sigone 2019-07-21 15:24:56 +08:00 via Android
对产品不满意就直接找产品经理商量，你直接对程序员指手画脚，被怼了是不是很没面子？
这个程序员敢怼领导，说明这个领导平时经常干一些指手画脚的事， 下属已经厌烦或者开始不尊重他了。 |
 |
66
iPhoneXI 2019-07-21 15:32:29 +08:00 via Android
流程问题，
公司产品不是程序员自己的项目，需求不合理的地方拉产品开会啊，不然出问题了锅是谁的， 大的需求改动讨论清楚了，也不至于以后扯皮。 |
 |
67
jugelizi 2019-07-21 15:36:05 +08:00
怎么说呢 有次客户反馈了问题 我提了方案 给到了前端去优化
结果不符合要求 再次沟通被前端怼了 |
 |
68
Sparetire 2019-07-21 15:37:23 +08:00 via Android
能者多劳？多给钱就行了
|
 |
69
moloach 2019-07-21 15:50:21 +08:00
我倒是很想去参与设计啊，每次有什么需求了，他们就直接怼过来，完全不跟我们商量。完成了之后，就开始说这里要改，那里不合适。。。自己都不知道自己想要什么东西。我真的很想揍他们，明明可以把程序员叫过去一起开会研讨哪些可以做，哪些有难度，还能帮他们梳理需求，可他们就是要自己关起门来怕脑袋
|
 |
70
chanchan 2019-07-21 16:05:21 +08:00
一把年纪的人了吧,还不懂规矩.你觉得应该怎样改和产品什么谈不就好了.
程序员也告诉你了你凭什么要求,这种情况还不知道该怎么做吗? 还有必要在这发帖抱怨吗? |
 |
71
jason19659 2019-07-21 16:33:03 +08:00
在何位某何职。全管的现在叫技术合伙人 /CTO
|
 |
72
sxlzll 2019-07-21 16:48:41 +08:00
能有产品思维、全盘考虑业务能力的码农算很罕见的了，如果楼主在的公司不是业内顶尖（给的起钱的），没必要人人如此要求，分而治之，有几个骨干能做到，其余负责搬砖即可
|
 |
73
cszchen 2019-07-21 17:15:30 +08:00 via Android
给这个程序员点赞，就应该拒绝，楼主作为技术总监，都不遵守流程和规范，太可怕了
|
 |
74
luozic 2019-07-21 17:30:11 +08:00 via iPhone
业务流程应该是产品经理负责的，不靠谱就帮别人把活干了？
|
 |
75
ruimz 2019-07-21 17:35:49 +08:00 via Android
对于程序员这个职业来说，楼主说的是对的，一个工程师，无论是什么岗位，应该懂得整个流程，考虑得更多
但这并不是跳过产品直接找开发的理由 |
 |
76
horizon 2019-07-21 18:15:28 +08:00
如果你觉得产品设计有问题，你应该带上这个程序员去找产品经理一起探讨 argue。
说出你更好的方案来说服产品，而不是直接让写代码的程序员按照你的想法来改。。 毕竟产品层面还是 PD 来负责的，而不是你。到时候 PD 不认可你的方案，程序员又 得改回去？？？ |
 |
77
cedoo22 2019-07-21 18:25:49 +08:00 2
在一个需求不确定的时候
需求人员想的是： 先让那群码代码的做一版出来，然后再改，反正不是我做，后面可以让领导提意见怎么改。 程序员 想的是： 这特么都不确定怎么做， 怎么设计？先让需求做个 demo 出来。 技术总监： 你特么程序员，要深入理解业务才做的出好程序！至于什么样才叫理解业务，你和需求去扯皮，你扯赢了 就说明你理解到了！ 产品经理 想的是： 就这么简单一个需求，工期都定不下来，加班！！ |
 |
78
neocanable 2019-07-21 18:31:04 +08:00
我十分十分排斥产品经理这个角色设定，我在阿里巴巴见过好的产品经理，屈指可数。
|
 |
81
ironMan1995 2019-07-21 20:30:53 +08:00 via Android
现在的年轻人只看钱，调研肯定不能在上班期间干，下班了沙比才给你加班调研产品。
|
 |
82
paicha 2019-07-21 21:45:55 +08:00
「产品的 50% - 60% 的体验应该由工程师输出」
|
 |
83
appmanagecluster 2019-07-21 22:08:34 +08:00 1
大部分程序员上班都是为啥？混口饭吃啊。产品做的不够好关他们啥事，你去帮说需求啊。上班做的东西是他们感兴趣的东西吗是他们就算不工作也有动力做的东西吗，这个概率很低吧，不感兴趣还自己设计啥，程序员愿意像你心目中的那样，也挺好，为了项目能更好嘛。不是那样的，也没问题，把功能实现把需求实现做了份内的事了，道不同罢。有啥子用？能加上产品工资份不，能发奖金不。不差面包，去做自己想做的，何尝不会把项目当儿子一样捧着，何尝怕不自行参与产品设计和优化。你的想法可以有，但凭啥强求别人要认同你的想法，你给面包吃啊
|
 |
84
Shiyq 2019-07-21 22:15:32 +08:00
我觉得应该按着流程走，有问题找产品商量，大家都觉得没问题了再改
|
|
85
appmanagecluster 2019-07-21 22:20:51 +08:00 via iPhone
话说你是老大不是，强行搞不就好了。整啥子程序员追求，花里胡哨，不行劝退
|
 |
86
hanlyjiang 2019-07-21 23:43:32 +08:00
在不同的位置，关注点是不一样的。建议换位思考一下，另外多一些宽容，共同协作一起磨合成长。
举个例子： 目前在组内的角色是个开发小组长，作为这个角色有一段时间了，虽然本质上我这还是一个程序员，但是会涉及很多需求对接，需求转化为任务后分派，以上是背景。 但是我觉得非常有意思的是，分配下去的任务，总会有那么一些地方不尽如人意如人意，比方说一个功能相关的流程没有考虑周全，又或者一个 UI 元素和效果有偏差，又或者实现上不注重后期扩展等等，总之就是我觉得应该是他们应该能做到的，没有做好。（当然，等我检查之后，再提出来，他们也会很配合的去做。） 这确实是个很有意思的问题，因为回想一下我之前做某些功能开发，也是这个样子。关于这些，我考虑了下之前自己为什么这么做，我现在为什么会考虑得更多，要求的更严？他们在什么情况下会做成这个样子，什么情况下又做的比较好一些？ 考虑总结了之后，我觉得很重要的一个原因就是，对于开发角色来说，他们的任务是我分派的，他们其实对任务中可松可紧的或者模糊不清的地方无法决策，另外，还有时间的限制，在这种情况下， 1. 一般来说，会默认认为任务合理（默认认为任务布置者已经想清楚了），即只需要负责开发实现就完了，其他的不会想太多； 2. 都会采取先实现功能的策略，至于那些无法抉择的，不会去理会。 当然还有一些其他的原因。 针对我以上的这些结论，后续工作安排的时候我做了一些调整： 1. 考虑到他们会默认假设我布置任务时，任务的流程方向等等已经没有问题了，所以我会尽量在任务下发前，将任务在自己这边过一下，看没有什么可能是在这个任务描述之外额外的工作，或者可以优化改进的地方，这些内容我会在下发任务的时候，尽量说清楚，另外如果实在没有时间详细考虑，也会特别交代清楚； 2. 对于一些存在疑惑，在他们那个层面可能无法抉择的，我会尽量确定拍板下来，比方说对于一些 UI 界面，我会自己提前给他们设计好，自己画出设计图（组里无 UI ），什么颜色，什么字体，什么间距，都确定下来，因为这些东西只凭口述或者文字描述，他们就无法决策；（我也深深的知道对于一个没有决策权的开发来说，做一个只凭口述的界面是如何的纠结） 经过一段时间的实践，我发现他们交上来的成果确实会更好了，更加符合要求， 但是在一些关乎他们主动性的对程序的主动改进方面，他们并没有什么提升，但是这个我并不怪他们，如果他们能有这种意识并且做到了，固然好，如果没有，那这就是我应该考虑的问题，我应该考虑如何才能让他们注重这些，如何调整工作安排或者要求调动他们去达到这些要求。 |
 |
87
zhiguang 2019-07-21 23:50:39 +08:00
总监管不了一线开发干活的？ 这只是表象吧，说是不改需求，实际上是不是管理不到位，激励？加薪？
|
|
88
zhiguang 2019-07-21 23:53:30 +08:00
我对领导的看法,能担责,能挡需求,能要好处,能分配好任务
|
|
89
leafShimple 2019-07-21 23:59:26 +08:00
@CF3B5 是的 我也应该多锻炼这方面的能力,受教了.今年也做了个项目,还在原型阶段,我应该在上面多花点功夫.很不错的主题
|
 |
90
hmmm 2019-07-22 00:07:42 +08:00
大部分人只是码农，很少人是工程师
|
 |
91
UFc8704I4Bv63gy2 2019-07-22 00:59:13 +08:00
@sxlzll 全盘考虑，从 idea 到利润都考虑到的程序员在现实中绝对找不到工作，因为任何一个环节看起来都不专业
|
 |
92
LeeChP 2019-07-22 02:00:53 +08:00 via iPhone
楼主应该就是我最讨厌的那种人了。
产品设计，需求分析的时候不提出来，开发要结束了，这不行那不行。还要给人扣上没有产品素养的锅。 想起来当年，和上头争一个方案，总之据理力争，一句话打回，按他说的做。行吧，我负责 coding。项目到中期的时候，这个改回去，那个改回去。最后整个全改成了我当初提的方案，我那种愤怒的心情，到现在想起来依旧咬牙切齿。 知道我他妈后期工作量有多大吗？牵一发动全身，整个架构全推翻，每天双倍工作量，还优化个几把，最后我也不管了，只堆功能。我一个方法写三四百行，我直接不玩了，开了我更好。 一次我忍了，第二次又他妈来，我直接吵，最后我直接收拾东西打辞职报告，要跟我重新谈待遇我都不搭理。这次让我对企业开发有了极大的恶心，直接回家打了半年游戏，还是自己写代码舒服。 所有的模型，需求，前期尽量做好，后期改动，请找产品沟通，最后重排工期，少他妈的逼逼。 |
 |
93
wo642436249 2019-07-22 07:33:58 +08:00 via Android
工作最好还是分工明确
|
 |
94
sampeng 2019-07-22 08:10:46 +08:00 via iPhone
像 lz 这种情况我会评估产品会不会发现。如果不会，则直接顺手改了。如过会发现就先讨论一下。 所以因此气哭了很多产品和测试…
|
|
95
sampeng 2019-07-22 08:28:07 +08:00 via iPhone 1
楼上在都揪着流程问题在声讨 lz。但实际楼主要讨论的是这一代新生研发要不要做 code 以外的事。
诚然面向工资编程是对的。但，工程师不是能是只 code 啊…这样的人抱怨青春饭我觉得就是自己作。眼铮铮看着产品被带沟里然后跳槽去下一家。最后时间长了手上一点核心竞争力都没有。君不见每个公司的靠谱程序员都是要和产品怼天怼地怼空气的。整个大环境和谐的团队真没见几个能成功的。lz 并没指明需求定了就研发私自改这一件事是正确的 我想 lz 想表达的是，需求定了，这事做的时候发现不对劲是要提出来去怼产品的。怼不过就升级怼。要坚持总是在做正确的事。这个思想一旦在团队内建成。大部分情况就会提升到需求确认的时候，就完美的符合前面各位说的所谓流程问题。但是 如果研发只是 coding …不做思考。这事就得 leader 一个人来干。真的会累死的。 所以我觉得 lz 不应该要求所有研发都如此。但最少小组长是这个特性的。人员分层是社会分工的必然进程。 |
 |
96
murmur 2019-07-22 08:31:22 +08:00
不应该，如果某些信仰极端的程序员去做设计，整个产品的 ui 全会给你做成 console
|
|
97
sampeng 2019-07-22 08:32:52 +08:00 via iPhone
另外有另一个思路供参考。研发思考产品体现出来的不仅仅是去和产品争需求。天天在代码设计领域说的扩展性好怎么到这没人说了？
窃以为扩展性好不是需求变的时候扩展性好。而是在开发阶段根据产品特性和自己的理解。预留了很多口子，一旦发现不合适或者需求变化可以快速修改。 我也神 tm 反感有研发说这不好改那不好改。大哥，我们是研发。你说不好改，请问你自己的代码设计跑哪去了？ 没有不好改的，只有不想改的 |
|
98
sampeng 2019-07-22 08:37:14 +08:00 via iPhone
楼上都说听产品的不背锅。你们一定没经历过产品提出奇怪需求。研发实现了。但是性能跟不上，产品反过来怪研发你们行不行啊…但实际这个需求压根就没人用也没必要做这么复杂。就因为产品说什么研发做什么，全被带沟里去了。要花费十倍的精力和资源去纠过来。这类事情在我从业生涯里比比皆是…千万要记住…产品说的事，除非大老板很懂技术。就算他说错了，你只要做了。锅就在你头上。背锅侠常在
|
 |
99
jk1030 2019-07-22 08:52:42 +08:00
技术总监说要改就改？ 不把产品总监放在眼里了 别把底层小弟当作你们做政治斗争的工具
|
 |
100
www5070504 2019-07-22 09:29:44 +08:00 1
你这样跨级指导玩微操 那个团队负责人看到什么想法 这程序员干的没毛病 要是随便听你的 回头在团队里咋混？
一个单位最怕俩领导都想表达意见 而且这明显不符合企业沟通的流程 |
Select Language