这是一个创建于 1960 天前的主题，其中的信息可能已经有所发展或是发生改变。
前几天有个 Java 程序员死活不愿意改程序，都吵起来了，说你又不是产品经理（我是技术总监）凭什么要我们改，产品经理的文档就是要求做成这样子的……
作为一个十几年前就已经是程序员老人来说，我们当年都是和项目经理一起去和用户碰需求，自己做设计画原型，都是在我们的脑海里从一个假想的画面，或者功能，然后通过自己的双手逐渐变成现实，那时候那种成就感是无与伦比的！
实话实说，我觉得我们这代人天然觉得自己作为程序员，作为软件工程师，天生就是应该是去思考如何用我掌握的技术，去思考、去设计系统该做成什么样子的人。系统在性能、稳定性、人性化、交互流程等等多方面都是应该是软件工程师能力的体现才对，特别是掌握如何将系统设计的更人性，更友好的能力，和想办法掌握某个编程语言的能力都应该是一个程序员工程师应该追求的能力啊。现在炒的火热的微信产品经理张小龙，还有大家熟悉的马化腾、雷军、周鸿祎等等，这些人那个当初不都是程序员吗？
这几年我带团队，我和新一代的程序员聊过很多次这个话题，他们的理由基本上都是说程序员都是不善于沟通的群体，就应该专注写代码，这些事情应该交给更善于沟通的产品经理去做，任何系统都是一大帮人团队配合的结果，你怎么可以让程序员去设计和了解需求，这样是非常不专业的……你以前干的都是小 case，我们是干大家伙的（实际上我以前干的系统比现在大得多和复杂的多了）！
实话说如果有特别靠谱的产品经理，我也的不介意让需求沟通、产品设计这事由产品经理分担去做，但是这几年和一些产品经理接触下来，我自己感觉真正靠谱的产品经理那是比程序员少太多太多了。程序员想法其实在再不济，好歹也是能把问题解决吧！但是很多产品经理因为不了解技术，往往很多时候把简单问题复杂化，甚至让沟通更复杂困难，问题反而解决的不好了。甚至有些产品经理觉得自己不懂技术才是优势，他们觉得懂了技术就局限了自己的空间，这样产品就会变得没有“创意”了，你和他讨论产品的设计，他反而会用你太懂技术了，所以你的想法不行用户不会接受的这种观点来拒绝你……无语……
我一直和我们的工程师说，github 里头的各种开源项目，Appstore 里头的大量 App，其实都不一定是产品经理带领下完成的吧，这些这么优秀的产品，不都是一帮、甚至只有一个程序员、软件工程师呕心沥血的成绩吗？现在语言的发展和技术的创新发展，不都是在让程序员变得更复合，更独当一面，似乎并不是变得分工更细，更专注只是编码啊！（ MD 我感觉现在写起代码来比我们那个时候简单太多了）
所以现在在我自己的团队里头，我一直在坚持要求程序员自己一定要去参与设计产品和系统。但是这么做下来，脚本语言的小伙伴还算配合和理解，但是后端 Java 的这帮人真心是不接受，很多时候和这帮人沟通我都有种绝望的感觉，所以有时候我也是真是挺迷茫的，也许是我真的已经 out 了，难道我真的 Out 了吗？
作为一个十几年前就已经是程序员老人来说，我们当年都是和项目经理一起去和用户碰需求，自己做设计画原型，都是在我们的脑海里从一个假想的画面，或者功能，然后通过自己的双手逐渐变成现实，那时候那种成就感是无与伦比的！
实话实说，我觉得我们这代人天然觉得自己作为程序员，作为软件工程师，天生就是应该是去思考如何用我掌握的技术，去思考、去设计系统该做成什么样子的人。系统在性能、稳定性、人性化、交互流程等等多方面都是应该是软件工程师能力的体现才对，特别是掌握如何将系统设计的更人性，更友好的能力，和想办法掌握某个编程语言的能力都应该是一个程序员工程师应该追求的能力啊。现在炒的火热的微信产品经理张小龙，还有大家熟悉的马化腾、雷军、周鸿祎等等，这些人那个当初不都是程序员吗？
这几年我带团队，我和新一代的程序员聊过很多次这个话题，他们的理由基本上都是说程序员都是不善于沟通的群体，就应该专注写代码，这些事情应该交给更善于沟通的产品经理去做，任何系统都是一大帮人团队配合的结果，你怎么可以让程序员去设计和了解需求，这样是非常不专业的……你以前干的都是小 case，我们是干大家伙的（实际上我以前干的系统比现在大得多和复杂的多了）！
实话说如果有特别靠谱的产品经理，我也的不介意让需求沟通、产品设计这事由产品经理分担去做，但是这几年和一些产品经理接触下来，我自己感觉真正靠谱的产品经理那是比程序员少太多太多了。程序员想法其实在再不济，好歹也是能把问题解决吧！但是很多产品经理因为不了解技术，往往很多时候把简单问题复杂化，甚至让沟通更复杂困难，问题反而解决的不好了。甚至有些产品经理觉得自己不懂技术才是优势，他们觉得懂了技术就局限了自己的空间，这样产品就会变得没有“创意”了，你和他讨论产品的设计，他反而会用你太懂技术了，所以你的想法不行用户不会接受的这种观点来拒绝你……无语……
我一直和我们的工程师说，github 里头的各种开源项目，Appstore 里头的大量 App，其实都不一定是产品经理带领下完成的吧，这些这么优秀的产品，不都是一帮、甚至只有一个程序员、软件工程师呕心沥血的成绩吗？现在语言的发展和技术的创新发展，不都是在让程序员变得更复合，更独当一面，似乎并不是变得分工更细，更专注只是编码啊！（ MD 我感觉现在写起代码来比我们那个时候简单太多了）
所以现在在我自己的团队里头，我一直在坚持要求程序员自己一定要去参与设计产品和系统。但是这么做下来，脚本语言的小伙伴还算配合和理解，但是后端 Java 的这帮人真心是不接受，很多时候和这帮人沟通我都有种绝望的感觉，所以有时候我也是真是挺迷茫的，也许是我真的已经 out 了，难道我真的 Out 了吗？
 |
101
www5070504 2019-07-22 09:32:22 +08:00
而且生产力发展的一个重要方式不就是专业化细分吗 不然大家都去搞全栈不就好了吗 全栈可就不是这个价了
|
|
102
www5070504 2019-07-22 09:34:30 +08:00
我相信做到总监级别的人 不会不明白基本的职场潜规则 除非是领导家亲戚
你想想如果底层员工直接跨级汇报 你乐意吗 如果你是团队负责人你乐意吗 |
 |
103
liuxu 2019-07-22 09:39:29 +08:00
总监要改需求，应该是去找产品经理改原型，改完文档定下来程序员和产品经理对接改代码
不然时间久了突然有人说程序员没按产品经理的原型开发，他找谁说理去？ |
 |
104
sheny 2019-07-22 09:49:01 +08:00
有 bug （ criminal ）要改（抓），你直接改（上）呗（啊），要产（ police ）品（ legal ）干什么，这年头有责任心的年轻人真是太少了，想当年我们都。。。。
|
 |
105
ganbuliao 2019-07-22 09:51:37 +08:00  1
最烦做事只管担不但责任麻不麻烦,不动脑子考虑的人，程序员是整个产品最后输出的人，要是程序员明明知道产品这么设计 还按照产品的去做 我觉得才有问题吧 我见过的产品没有一个设计的东西最后细节没问题的 难道非得全做完了让他们发现有问题 在改才是正确的 ，我觉得这种人最后肯定会被代替（机器人在不思考的情况下比你高效的多）。可能好多人看不懂我说的话，不在一个思考频道的肯定看不懂了。^_^
|
 |
106
zr8657 2019-07-22 09:59:09 +08:00 2
想让手底下人听话还不简单，加钱啊，钱到位人到位多么浅显易懂的道理，现在都 2019 年了。
|
 |
107
passerbytiny 2019-07-22 10:00:29 +08:00
@CF3B5
程序员（ Programmer ）是一种人物类型，制作程序的人基本上都可以被叫做程序员；软件工程师（ Software Engineer ）是一种职业工种，并且是“工程师”大类下的一个工种，有明确的能力要求、职责要求，和工作范围，有些较真的地方还会有认证要求：请不要将二者混为一谈。 只负责编码不负责需求制定或者产品设计的工程师，严格意义上叫做软件开发工程师（不排除有些守旧的公司还会再细分为软件设计工程师和软件编码工程师）。不负责编码只负责产品的人，传统工程中叫做系统工程师或者需求工程师，敏捷开发中叫做产品负责人（形同产品设计工程师）。上面的人都是程序员，并且都是工程师，区别只在于是不同方向的工程师。至于“产品经理”，这是一个呵呵呵的中国特色职位。但是，他特色的原因不是“产品”，而是“经理”，而且是那种拥有无限权力但不用负主要责任的经理。你不能因为产品经理而否定产品。 程序员，可以并且应当具备软件开发、产品设计两种能力，好的程序员可以在开发工程师和产品工程师之间相互切换。但是，一旦一个具体的项目或者迭代开始了，那么权力和职责就固定了，不能随意切换，这一点不管是传统工程学还是敏捷开发，都是如此要求的。即使是只有一个人开发的项目，这个人也应该在不同的场合切换不同的身份：调研的时候要变成产品，不能在这时候考虑“循环比递归好”；编码的时候要变成开发，不能在这时候出现“用户操作时，这个分支是走不到的，所以我就不做这个分支的单元测试了”。楼主你要求程序员自己一定要去参与设计产品和系统，我不知道你是要求他们在什么阶段去参与，如果是在编码阶段同时参与，一边编着码，一边去设计产品，这必然会严重降低代码的质量。反过来，如果产品负责人一边设计交互过程，一边想着该怎么编码，那这设计出来的产品的用户体验度必然是极差的。 张小龙、马化腾、雷军、周鸿祎虽然都是程序员出身，但是他们现在可不是程序员。在他们当初干程序员的时候，做得东西并没有在市场站稳。 |
 |
108
abcbuzhiming 2019-07-22 10:01:16 +08:00
楼主你说你是技术总监？你一个总监怎么这点职场基本规则都不懂？你要让程序员改需求，难道不应该先把产品经理叫过来，你都没说服产品经理，凭什么越级指挥程序员呢？你改了需求到时候产品经理不认，这算谁的？你的想法才有问题，我倒不觉得 Java 程序员有说错什么，产品经理出了文档，不按文档做到时候产品经理翻脸你给帮说话不？
程序员参与产品设计，这没错，优秀的技术人员大部分同事也是优秀的产品设计，问题是职责在谁那里？产品经理已经存在并且写了文档的情况下，楼主不先和产品经理商量，反而煽动程序员私自修改需求。你那产品经理真是好说话，不怕人家键盘砸你脸上并且拉老总来怼你？ |
 |
109
gw1992225 2019-07-22 10:03:14 +08:00
作为楼主口中新一辈的程序员 其实我们也是想尽心尽力 多学点东西 把产品做的尽善尽美 但是在公司真的是要分工明确的 公司既然有流程一定要遵守流程 楼主觉得有不妥可以把大家都叫上一起开会讨论定方案定工期 而不是单纯的觉得后端开发有问题
|
 |
110
chen2019 2019-07-22 10:04:41 +08:00
... 唉，LZ 人人有本难念的经 尤其是底下程序员 可能有些有好几个领导 比如 项目经理 产品经理 技术主管 老板 ，到底听谁的？这么多领导，自己能提什么意见？不会说话的直男说错话了，那岂不是代表着 这么多上级想得都没自己好？所以选择一个能负责的人听，才是生存之道。
这不是程序员对产品负责的问题，是程序员无权对产品设计负责，而经常还得对此背锅。 |
 |
111
CF3B5 OP 我觉得看到很多人的回复，让我想到一句话：后宫不得干政治……哈哈，看样子很多公司的技术部就是公司的后宫啊！实在想不到这么多人年纪轻轻就如此的迂腐！
当我们说起某个软件、某个系统的作者的时候，无一例外提到的都是这个软件、系统的技程序员，工程师！产品经理并非说不重要，但是很明显在计算机的世界里头，程序员、软件工程师才是真真正正这个计算机世界皇冠拥有者，过去是，未来也应该是！如果你还不承认，你可以翻翻自己的电脑，看看里面的软件，有多少找的到他的产品经理，有多少找得到他的开发工程师？ 说白了，权力越大，责任也越大，很多人无非就是不想承担责任而已，流程什么都是虚的，产品的好坏本身就是一个团队应该共同负责和承担的责任，很多程序员只不过是借着“后宫不得干政”这个理由来规避自己的责任而已！就好像产品好不好是产品经理的事，程序有没有 Bug 是测试的事，我就是个打字的，虽然可能拿着整个 team 里头最高的工资，但是想让我承担责任？ NoWay ！ @sampeng 所以其实你的分析的是对的，我目的吐槽的其实就是程序员，但是没想到这么多人关注的是流程，就是所谓的技术不能干政……真是是挺无语的……说真的我一点都不排斥产品经理！我的意思是就算有产品经理，程序员都应该主动积极的去参与思考产品设计，一样要对产品好坏负责！很多程序员觉得自己不应该背这个锅，其实我想表达的是，产品设计这个锅本来就是程序员、软件工程师背的，你才是这个世界的国王，是你把这个责任甩给了产品经理而已！放十年前，很多软件项目只有项目经理+程序员，实际上产品经理这个岗位并不流行。所以说白了，程序员不是受害者，产品经理才是受害者！ @LeeChP 其实你觉得你最痛恨我这种人，但是你没有发现你就是现在这种结构的受害者吗？如果本身项目给予工程师足够的尊重，让工程师参与沟通和了解需求，你作为工程师如果一开始了解用户真实需求想法，按照这个需求和想法去设计架构，这本不就是最合理和最高效的开发流程不是吗？现在所谓的流程，把责任都甩给了很多连实现原理都闹不清楚的黄毛小子，要和客户沟通，设计了解需求的时候，就给产品经理带高帽，说产品经理们才专业，产品经理沟通能力比我们好！等要写代码的时候，自己又在骂娘，什么产品经理设计的东西都是一坨屎，垃圾，动不动就要改等等……！你觉得你背了别人的锅，实际上产品经理何尝不在被背程序员的锅？ |
 |
112
yxcoder 2019-07-22 10:10:52 +08:00
感觉挺有道理的，对于软件工程师和程序员的划分标准之一就是在软件生命周期中的参与程度。软件工程师应该是需要参与到软件的整个流程中的，或许在有些过程中，软件工程师不是决定性的地位，但参与到其中对自己本职工作是有很大的帮助的。
|
 |
113
LeeChP 2019-07-22 10:11:05 +08:00 via iPhone
所以当你吐槽这个的时候，麻烦能先把贵司的产品先开了么？你以为这种流程这种结构别人愿意啊？还不如吃一堑涨一智？不按流程，最后出了问题程序员背锅？还是说，你绕开产品直接找程序员，就是为了规避风险，把锅扔给程序员？坏的很！
|
 |
114
Fortnight 2019-07-22 10:11:54 +08:00
让开发者参与设计这个想法本身没有错，但是改程序的例子举得不行，真的有需要改的地方应该先跟产品沟通，而不是直接就改了，不然产品又说研发不按文档来，这个锅还是得研发背
|
 |
115
JerryCha 2019-07-22 10:21:34 +08:00
楼主认为大家不懂产品，大家认为楼主不懂企业。
|
 |
116
maxiaofeng 2019-07-22 10:28:54 +08:00
所以你说服不了产品经理，也没能力改变公司流程！ 只有来喷一波 java 后端？ java 后端脸上写的好欺负写嘛？
|
 |
117
Aresxue 2019-07-22 10:35:25 +08:00
1.改了可能要背锅，不改就不会，这种明哲保身没人可以指摘；
2.职业不断细化，最早的程序员是全能的，后来分化为产品、测试、运维，甚至本身又分化为前端和后端，这是有一定道理的，随着业务复杂度的上升，分工确实能带来效率上的提高； 3.有追求且有精力的程序员是乐于参与产品设计的，像提到的成就感和参与感是一个方面，了解市场和用户并融入产品的能力也是程序员独当一面的一个必经历程，但不能苛求。 |
|
118
CF3B5 OP 1
|
 |
119
aaronhua 2019-07-22 11:09:13 +08:00 1
论一个不恰当的例子，如何引战。lz 很强
|
 |
120
xaplux 2019-07-22 11:15:44 +08:00
这种事情不应该技术总监先去和产品碰一下么，产品同意你再去和具体搬砖的说么？我一般如果觉得产品设计不合理我会直接向产品提出来，说出我的想法。我也经常和具体任务成员强调，如果觉得产品不合理，那么试着去说服产品经理。
|
|
121
LeeChP 2019-07-22 11:16:02 +08:00 via iPhone
所以你家程序员哪里做错了？
产品设计，需求分析的时候，你家程序员没参与还是怎么滴？别人没提意见还是提了你们当耳旁风？还是你压根就没让人参与？ 既然都走流程开发了，麻烦你也走个流程去联系产品前端 ui 设计好不好？ 开发末期改需求，有一个算一个全特么的垃圾玩意，建议把你家程序员开了。 美其名曰希望程序员要有产品思维，实质还是粗暴管理，你一个总监都不管流程，还丢锅给别人？ 20 人公司的总监吗？ |
 |
122
dai123456 2019-07-22 11:18:21 +08:00
必须为自己的产品负责，没有市场的产品，就不是好产品
|
 |
123
ThiagoJC 2019-07-22 11:20:33 +08:00 via iPhone
产品让我做个苹果我绝对不敢做个香蕉，改需求一定要找产品确认的
|
 |
124
blacklee 2019-07-22 11:22:20 +08:00
|
 |
126
imnpc 2019-07-22 11:24:35 +08:00
一个成熟的开发团队 这些走下流程 各部门负责人审核同意下不就行了 为什么非得跳出流程？
|
 |
127
tfdetang 2019-07-22 11:26:25 +08:00 1
作为一个懂技术的前产品经理，我理解楼主想要表达什么。 产品经理也是人，在设计产品的时候一样会犯错（特别现在阿猫阿狗都成产品经理了），而开发如果不以主人翁的心态参与到其中，仅仅是根据文档 CURD，最后产品很难不经历返工。文档所能传达的信息十分有限
|
 |
128
hellwen 2019-07-22 11:26:38 +08:00
@CF3B5 你也只是站在自己的立场上大谈特谈罢了，有点追求的程序员不知道打磨产品？需求分析程序员参加了么？工期给足了么？流程规章制度是什么样的？别老是你当年了，想当年毛主席还用小米加步枪打江山了。你怎么知道人家程序员下班没有好好打磨自己的独立产品？楼上说的对，“美其名曰希望程序员要有产品思维，实质还是粗暴管理，你一个总监都不管流程，还丢锅给别人”。我就问一句，出了事故你出来担责任么？产品找程序员麻烦你能跳出来顶上么？我承认你说的有那么一点道理，但是那是应该有一堆前提的情况下才成立的。
|
 |
129
busymilk 2019-07-22 11:40:06 +08:00
找错人了
|
 |
130
googoehl 2019-07-22 11:51:43 +08:00
全干的路上!!!!
|
|
131
CF3B5 OP 1
@LeeChP 我就问问，Linus 大神管不管流程？ Linux 内核现在是不是都是他找了一堆产品经理帮他设计有那些功能那些特性，然后出一堆 PRD 文档，然后分布在全球各地的程序员都是完全按照他发的这些文档开发的？还有大家用的 spring、git、tomcat、apache 等等一堆一堆的各种软件，各种技术，这些东西的作者都是一个一个的不懂技术的产品经理，还是懂产品的程序员？产品经理才是计算机世界的国王？
再说技术总监凭什么不能改程序，首先改程序就不一定会改需求！实现同样的需求，程序可以很多种实现的方法，我之所以特别的火大，就是因为程序员自始至终不从产品角度考虑问题，只对所谓的需求文档负责，代码好不好，结构是否合理，是否有足够的灵活性健壮性等等，这些都被抛诸脑后，只要看着和需求是一样的，测试不出 bug，就觉得是没问题的…… 年轻人，在公司混日子，这种态度没所谓……但是我想讨论的是作为程序员，特别是希望自己能成为比较优秀的程序员的人，真的就应该这样子态度对待自己的前途和行业吗？很多人，膜拜各种技术大神，努力学习这些人开发的各种架构和技术，把这些大神视为自己的奋斗目标！但是这些技术大神如果每天在公司，和你们觉得的程序员就应该只对实现产品经理的需求而负责态度去工作和思考问题的话，你觉得他们能设计出这些优秀的技术和产品吗？既然要认为别人的代码写的好，产品也做的有用，那为什么不想想人家的为什么能做的这么好？是因为他有个特别好的产品经理在帮他吗？ 我说的这个话题，和你们在公司如何混日子根本就是两码事，要混日子那是混日子的事情，这个我也干过！但是作为一个行业的从业者，真把这种混日子变成是行业规范？是不是太误人子弟了一点？ |
 |
132
qinyusen 2019-07-22 12:19:36 +08:00 2
因为信息不对等，所以，技术提出的“改进”很可能是产品和项目里已经毙掉的 idea。
仅此而已， 我更倾向于，能把需求 1：1 完美呈现的人，但是很抱歉，没几个能 1：1 完美的。 |
 |
133
hahaayaoyaoyao 2019-07-22 12:28:31 +08:00 via Android
@CF3B5 #131 你开出了那个工资了吗？
|
 |
134
jiwei3187553 2019-07-22 12:37:39 +08:00
这么喜欢好为人师吗，说了半天都是我们以前如何如何，大神如何如何，在看看你这个垃圾程序员不思进取的德行。我服了，不按流程来锅是程序员背，按流程规范来还要被说是垃圾，不思进取，混日子,是牛皮.
|
 |
135
niubee1 2019-07-22 12:41:11 +08:00
提升自己的事情居然很多人会反对， 所以张小龙成为了张小龙， 路人甲始终是路人甲
|
|
136
CF3B5 OP @hahaayaoyaoyao 说真的我不知道，我这边的 Java，初级 3 年以内经验的 10k 多点把，有个 3、5 年经验的能拿到 15 ～ 20 左右，说真的我觉得比上不足比下有余把……因为我最早是干 asp 入行的，后来干过 c、net、java、php 各种语言各种技术，自己就是喜欢码代码而已，对于我来说面对新技术其实就是乐趣！但是说真的觉得我觉得现在很多程序员真的一点责任都不肯背，客户骂产品难用，那是产品经理的设计问题，上线了有 bug，就说是为啥测试没找出来，服务当机了就说运维为啥这都不第一时间发现，哪怕做 code review 的时候给他找出问题，他都能说代码规范没这么规定，你有规定了我肯定照着规范写啊！
就好像医生给病人开刀，和病人说，你想往那切我就往那切，是生是死你自己决定啊，我就是个拿刀的……无语…… |
|
137
www5070504 2019-07-22 12:58:37 +08:00
看楼主的回复 有种实名挑战软件工程的感觉 按照开发流程到他这就变成了混日子
那还要规范和标准操作流程干嘛 一线人员全都临场发挥呗 |
|
138
abcbuzhiming 2019-07-22 12:59:13 +08:00 2
@CF3B5 你这话说的，你到现在还没搞清楚你错在哪里啊，我就问你公司的产品经理是透明人吗，由着你这么胡来？你为啥就是不愿意先说服产品经理再去找程序员呢？你这么牛逼你可以把产品经理全开了自己来干产品的活嘛，那样你下来的程序员绝对服你。你又不愿意去招惹产品，又越级煽动程序员，还来这里找认同，你是真的不懂职场规则还是装不懂啊？
|
 |
139
good1uck 2019-07-22 13:00:08 +08:00 via Android
那你先解雇你们所有的产品经理
|
 |
140
kveln 2019-07-22 13:18:17 +08:00
我感觉大部分人都没有 get 到楼主要表达的意思！
|
 |
141
clayyj1210 2019-07-22 13:25:42 +08:00
131 楼后面说混日子的部分不说。
131 楼举的例子 spring、git、tomcat、apache、linux 内核，这几个例子不算好例子。这几个例子，程序员既是产品的开发者，也是产品的用户。但实际上在开发产品的过程中，程序员是开发者，但不一定是用户。这里对用户的定义并不是那种打开一次应用就算了。 |
 |
142
Torpedo 2019-07-22 13:57:20 +08:00
都说国外程序员开发的技术项目多，国内程序员都是写业务。
结果国内程序员业务都不愿意去了解，推动。。。 |
|
143
LeeChP 2019-07-22 14:04:11 +08:00 via iPhone
粗暴管理就是粗暴管理，少扯那么多。你问问林那厮一个人能开发出现在规模的 linux 么？你问问比尔盖茨能开发出现在规模的 win 么？
这个制度是你们公司定的，有本事骂你们 ceo 去，关程序员屁事？ 你就是改了没问题你拿功劳，出了问题程序员背锅的那种人，在你手下干活的那帮人可算是倒了血霉。 |
 |
144
sxlzll 2019-07-22 14:06:52 +08:00
@weiqk 考虑问题不要总是极端化，对产品业务有一定的认识不是让你取代产品经理，打个比方，如果每个角色都只懂自己的专业能力，哪怕个个都很强，也会像复杂机械却没有润滑油一样，所以需要一部分人能力图谱比较宽，并且和其他上下游角色有一定交集，事情做起来才更“润”，也有人互相为对方纠错
|
|
145
hellwen 2019-07-22 14:12:07 +08:00
@Torpedo 至少在我们公司开发了解业务是 p 用没有的，也不是我们不想了解，需求分析根本不带开发能怎么办，再说你了解了能按照你的意思改么？产品说的话你能不听么？产品说领导要求的，跟你了解的流程不对，你改还是不改？自己改了出问题了，谁的责任？形式所迫而已，我们也知道业务有问题，我们就能按自己意愿改了？挣钱已经不容易了，为啥还要自己找锅背？
|
|
146
Aresxue 2019-07-22 14:14:46 +08:00
@CF3B5 怕背锅是重要因素，但不是主要因素。。。软件发展到现在，稍微有点用户的系统业务复杂度都太高了，别说程序员，就是所有的产品经理加一起都未必能搞懂业务和用户需求，分工是必要的，各自关注自身职责也是必要的，设计模式都有个单一职责原则，对于工程师来说把产品经理的想法能接近理想的实现就已经很不容易了。人的精力都是有限的，有人追求深度有人追求广度，没必要强行要求。
|
 |
147
QQQQQQQ 2019-07-22 14:16:19 +08:00
开发对需求的参与及讨论应该在需求落地前，而不是已经出了需求文档。当然我理解的文档应该是需求详述了。这个时候再改，我认为确实应该通知需求去评估，而不是只要求开发去改动，这样后期出现问题的时候，锅就扣自己头上了，还可能牵扯到绩效等一系列问题。我认为一个开发在需求落地时期去明确需求和了解整体业务是没有问题的，但是真正到了开发阶段再要求去修改就不能只针对开发一个人说了，既然是团队，还是得按照流程来的，之所以有规则，不还是大家多年摸索出来的吗。
|
 |
148
Gea 2019-07-22 14:32:55 +08:00
1.楼主是技术总监，让手下改点东西，不管是什么理由（合理或者不合理），手下能吵起来都不改，楼主在团队里真的是一点权威都没有，一点管理能力都没有，我觉得先想想自己的问题吧。至少我的总监让我改代码，不管怎么样，我还是会改的，楼上说责任的问题，真到最后，我肯定会说是总监让我改的，这点大家都看着。
2.闻道有先后，术业有专攻。你说张小龙，马化腾等人又做技术又做产品，这种人拿出来举例子没什么用，有多少做技术出身的创业失败的，他们不也是懂技术又亲自做产品，依然创业失败？这种东西不拿数据出来说话，没有什么说服力的。 3.现在是一个合作的时代，不是单打独斗的时代，把背后交给队友，全力做自己的事情。你看不起你们公司的产品经理，但是有些方面人家肯定比你强。如果你们产品经理真的什么都不行，想想为什么会在这样的公司而不是一个好公司吧。 4.人都有身不由己的时候，可能要忍受傻逼的同事，傻逼的领导，但自己也要恰饭，无法避免的要一起工作。这个时候更应该楼主（技术总监）出马去预先解决掉这些问题，在研发一开始就提出可能的问题，不管是告诉产品方面还是自己手下这些，而不是产出了，才去跨过所有需求流程来告诉程序员去改。不然，这个技术总监，当的也太简单了。 至于程序员打磨产品的精神，我司的情况走的敏捷开发，每次迭代的需求宣讲会和评估故事点，都是研发、产品、测试三方一起来开会的，说起来，产品精神测试同学比我们研发更认真，究竟是你太 out，还是我司太 in，我也不知道，只不过当代程序员的情况应该比你那时候要好，你的时代结束了。 |
 |
149
1cming 2019-07-22 14:55:55 +08:00
其实楼主的意思我大概理解，但是就像楼上一个 V 友说的一样，不能刚划范围不给权力。
我本身是很乐于去跟产品讨论的，大家相互可以转变身份打磨思维——这是建立在有跟我有同样看法的产品的人身上。 如果对方本身就是比较固执一些的产品呢？甚至好多所谓的产品已经沦为运营的工具了。 这个时候技术想要去反向推产品、运营、业务是何其难。因此权力的意义就在于此。 回到事件本身应该是楼主推动努力跟产品团队达成共识，大家相互打磨。 有的人喜欢去跟产品打磨那就让这样的人去打磨，这样的人后期往 PM 方向培养，当公司有项目时，这类人去带是有价值并且可以拿到结果的；有的人不喜欢去那就让他专注于技术范畴内，挖掘深度，不定期团队内部分享一些知识也是不错的。 无论何时，一刀切都是不适合的。作为 team leader，楼主要学会当伯乐。 |
 |
150
cdh1075 2019-07-22 15:01:31 +08:00
没有规矩不成方圆，程序员的规矩是按照上级的指示做工作，你想改动你就应该按规矩走，去找他的上级，你这么做表面看是提高了效率，如果人人都这样就乱套了，你这么做是你觉得自己的想法对，产品经理那么做是他觉得他的想法对，先不说谁是真的对，但人人都会觉得自己的想法对，如果第二天一个 xx 总监也觉得自己对，来找程序员改成另一样，你会是什么想法？
|
 |
151
starerlloll 2019-07-22 15:03:21 +08:00
老板说了算， 你程序员能直接跟老板刚正面？
有的项目从技术的角度上来说就是辣鸡， 但是能赚钱啊，3 个月出了辣鸡产品捞一笔然后暴毙不多的是？还不是拿钱写代码做产品，然后产品失败了换项目？我觉得老板这个 idea 垃圾的要死我能怎么办？ 整个项目毙掉算了？ 你去争这个不如离职来的有效率。你钱就给这么多，我 996 还不够，还要我 24 小时为了公司产品掉头发？ 楼主最大的问题是把工作 和 兴趣混在一起谈，我自己的项目我反复打磨一个星期都没问题， 但公司的项目，团队里每个人都这么搞，需求还定不定了？工期前做得完么？ 公司倒闭了楼主给大家发钱么？ |
 |
152
userdhf 2019-07-22 15:10:04 +08:00
楼主我跟你想的一样。别的不多说，了解需求，能避开许多产品留的暗坑。而且长期来看，这是一种学习和经验积累。现在的人都太浮躁，也没有那么团结一致，各种西方传进来的分治思想和公司制度搞得企业内部各个部门和职能有巨大的鸿沟。
我们一直是强调，集体力量大，但是呢。。。 |
 |
153
TingHaiJamiE 2019-07-22 15:15:57 +08:00
楼主说的特别好，也特别对。但是现实情况就是有一些开发人员只对文档负责，一点也不多想，一点也不多做。很难改变。
|
 |
154
NickBlablabla 2019-07-22 15:16:03 +08:00 via Android
我 jiao 着 LZ 发到这里的帖子也是在做调研、验证。
|
|
155
CF3B5 OP @Gea 其实我们也是每次必带程序员，而且还千叮万嘱说你们要好好想清楚啊，但是问题还是架不住这帮人不肯动脑子啊！说白了就像这楼里头的一些人，潜意识里头就觉得公司做的这个产品和自己没关系的，按照流程他就只是个敲代码的，产品设计成什么样子都是产品经理的锅，他们唯一考虑的就是技术上能不能实现而已，至于产品是否合理根本不再考虑范围内啊……！
作为技术总监，你和他分析说这个需求，其实可能用这样的框架这样的技术比较好把，这样子实现起来会更合理，以后需求变更也更方便等等！这些人要不给你来句这个技术我不会啊，之前没做过啊，公司在招一个会的把！要不说我的办法能实现啊，能做出来就行了，考虑那么多干什么，可是一到改需求时候这些人就哇哇叫了……最后经常的结果就是我自己懒得和他废话，把门一关一晚上搞完了，收工……无语！但是真心 TMD 累啊……唉！ 软件开发真的是团队活，但是说真的现在年轻一代的程序员，你们真的清楚什么是软件工程师吗？你们究竟有多少人认真看过《代码大全》《设计模式》《重构》《程序员修炼之道》这些书了？你们真的明白这些书里面写的各种坏味道，各种代码、设计的目的是什么了？尽管很多人现在的水平不足，但是你们真的觉得按照自己现在这种等着产品经理给自己安排开发需求的状态，就慢慢能变成书中描述的那种软件工程师和程序员了吗？ 作为一个老程序员，我也很为现在这种程序员就是青春饭的模式打抱不平，但是真的看到你们有些人的回复，真的也是挺心寒的…… |
 |
156
lonelygo 2019-07-22 15:29:47 +08:00 4
这么多楼，不想一一看了，这是属于老生常谈的问题了，直接放我的结论。
说难听点：任何人，做任何工作，不愿意去突破“自己给自己的边界”，无法成长，难成大器； 说鸡汤点：我们需要更多的去理解别人的工作，这样我们才有可能站在对方的角度理解别人工作的难处与不易，我们才能更好的在自己的工作职责范围内，尽可能的去帮助别人一起进步； 说正常点： 写代码的目的是为了实现某个特定的功能，一些特定的功能组合起来，我们称之为“产品”；只有站在产品的角度去理解需求，审视代码逻辑与设计，才有可能“避坑”和“改来改去”； 当你是更高的段位的程序员，能理解产品方向之后，面对 PM 的需求，你可能就会主动和对方沟通，“未来这里会不会有这样的变化，哪里会不会增加新的功能……”，你会“理智”的在设计阶段就留出应对未来变化的结构和抽象方法； 当你段位更高之后，你关心的是架构与产品层面之上的问题，而不是写几行代码或者改什么功能； 所以，对于楼主而言，这样的程序员，吵大可不必。 安排一次不听，我给你讲一次道理，听进去，配合则好； 安排一次不听，我给你讲道理，还不配合，这次就这样，我相信这也不是不改地球就要爆炸的功能； 再安排一次，还不听不配合，那就最多再给一次机会； 三次之后，恭喜你裁员的时候有了第一个候选人；如果没有裁员机会，那么总有增删改查的维护，这些不需要那么复杂，给他干呗，干两年干废了再说。 |
 |
157
AyanamiRei 2019-07-22 15:30:31 +08:00
行业细分是趋势, 专精一个方面才能做得更好
|
|
158
CF3B5 OP @userdhf 国外对产品经理的定义和国内的完全不一样！实际上现在国内很多公司的产品经理的职责就是模仿腾讯和阿里这些大厂的模式来的，并不是借鉴国外的模式，实话说大厂有大厂的原因，对错不好评价……但是实际上国外的产品经理基本上要么是读 MBA 商科毕业的市场大拿，要不就是从技术做起来的技术大神！像国内这种直接社招的既不懂技术又不甚了解市场的产品经理来设计产品，还给他们扣个高帽子说他们很专业本来就是强人所难！实际上在大部分公司就是沦落成给技术甩锅的可怜虫……
|
 |
159
cnrting 2019-07-22 15:40:16 +08:00
我敢说楼主的公司一定很乱
|
 |
160
Leigg 2019-07-22 15:47:08 +08:00 via Android
楼主你说的没毛病。
问题在于，现在很多人觉得只是干技术，工资就已经使得他们心里满足了，他们不想多花一点心思了，这批人也就叫做马龙。 而你说的雷军，张小龙那批人，他们可不是马龙。 |
 |
161
version 2019-07-22 15:57:19 +08:00 via iPhone
@lonelygo 现实中是这样的，如果代码好，能预知扩展性，认真负责，肯钻研的，在技术总监里面铁定是有排名的，哪天裁员了或者要分配任务的时候，往往打卡上下班不积极的同事就会被安排无营养的功能 crud 或者无聊的 bug，公司的新架构钻研就分配给认真的同事，等过上 1 年，他们的技术水平就拉得非常开了，公司不行了，技术总监会带上靠谱的跑路或者内推给朋友公司，哪有找工作麻烦的事情，你有项目带上总监，总监也会留肉给自己，生活就是这样现实和赚钱
|
 |
162
scotmouton 2019-07-22 15:57:58 +08:00
我认为，如果程序员写的代码与实际敲定的需求有偏差，没有达到楼主所说的人性化设计，那是产品经理和程序员拍需求没拍到位或者程序员理解设计的问题；但是如果程序员写的代码质量有问题，运行效率低，健壮性差，那是技术 Leader 有没有规范技术方案的问题，应该考虑的是有没有及时做到 Code Review,有没有代码规范；小弟虽说工作才几年，就自己经验来看，这两点做到了出来的产品基本不会太差，也不存在你说的这些问题。程序员如果想混日子至少也应该保证自己水平能力在平均水准之上也才能混日子，否则那叫拖后腿吧...
|
|
163
userdhf 2019-07-22 15:58:15 +08:00
@CF3B5 #158 学习了。。。还是觉得，做事要各个方面的人都要参与进来，一起商量着做，这样既能互相监督，又能互相学习，太分离的职能，估计人事考核会比较简单，大公司估计也有大公司的考虑吧
|
 |
164
muller 2019-07-22 16:11:07 +08:00
大哥 ，我理解你，不过 我还是想吐槽 [这么简单的需求来这里嘚瑟 ，你咋不自己替 java 程序猿改了呢？] 牵一发而动全身 ，反正就是懒，大家都懒，改了一点 ，还得 测试别的模块有没有受影响，出了问题都要自己担责任，你看哪一个程序猿不受怂逼，谁愿意担责个责任，改好了 是分内的，该糟糕 出错了，就是自己责任，那么多星辰大海，那只是你的而已
|
 |
165
ragku 2019-07-22 16:20:04 +08:00
1. 不懂得思考产品的开发正在变成编码工具，有一天会被 AI 替代掉的。
2. 说拿多少钱干多少活的，按编码字节收费，看一个月能拿多少？ curd 找个初中生培训一下都能做。 3. 技术总监都找你改了，没问题该改就改，有问题抛出来确认好改不会？ 4. 背锅怎样了？都做程序员了连个背锅的胆量都没有，还想升级加薪，当上 CTO，走向人生巅峰？ |
 |
166
LeeSeoung 2019-07-22 16:22:11 +08:00
楼上太多人台着重于程序员不愿意改变了，你怎么知道人家内心里没有设计，没有想法？拿 1w 的工资去操拿 2w 工资的人的心？按规章办事没错，开发就怕这种上面两个领导的，一个说改成 A，一个说改成 B，有争论，把产品经理一起拉进来讨论，何必隔一层以技术总监头衔来压制后台开发呢，那你又是出于啥目的不愿意把所有相关人都拉进来理清楚，这么简单的事情你为什么又要复杂化？
|
 |
167
noobcoder1 2019-07-22 16:22:14 +08:00
u can u up, no can no bb.....
|
|
168
Gea 2019-07-22 16:25:59 +08:00
@CF3B5 反过来看，现在倒是一个很好的机会，好的团队坏的团队就像好的代码坏的代码，都可以给人很好的经验，往往是一般的代码，让人既不能从中学习好的点，也没有太多可以改正的机会，提升代码水平的机会不多。目前的团队存在比较大的问题，慢慢的改变整个团队，是一个很有挑战也很有提升的经历。156 楼有解决方案，具体的实施方式有很多。楼主计算机理论基础很扎实，应该看一些管理的书了，我个人觉得楼主还是缺乏一定的管理经验和理论支撑。技术的深度，产品的思维，都很重要，但是接下来带队的能力才是能走的更远的必要条件吧。
|
 |
169
win7pro 2019-07-22 16:34:01 +08:00
1、是我理解错了吗？技术总监不能要求下面的 java 开发改代码？是不是你的管理出了问题？
2、我认为应该是这样的：如果你要改的代码涉及到产品特性，那应该反馈给产品经理，确认后安排你的人改；如果你要改的代码只涉及到性能调优，技术方案，那可以把这位 java 开发开了，当然无论结果好坏都是你承担。 3、在成熟的公司环境，每个员工首要做好的事情是自己的本职工作，即便不过问产品策划或设计，只要能优秀完成自己的任务，都是好员工；感兴趣拓展自己边界的员工值得鼓励，但不意味着就应该项目流程上要求大家都模糊自己的边界参与进来，而是每个职位都需要有一个负责人，你可以鼓励开发员工去多思考产品和设计，最终落地应该是去影响产品经理和设计师的决策，而不是代替他们决策；不然项目将乱成一锅粥。 4、鼓励大家模糊职责边界都参与项目更合适小团队，初创企业，因为人力不足，分工太明确流程太严谨反而会影响项目产出。 5、最后，作为技术总监，感觉你在下属面前缺少威严，可能是管理手段需要优化一下。良好的管理氛围是，你的下属要支持你，撑你，你决定的事情下属需要执行，说的不客气一点，如果下属敢这样反抗你的指令，你完全可以把他开掉，不然其他下属也会知道：原来拒绝执行技术总监的方案，是可以滴！ |
 |
170
Conte 2019-07-22 16:50:41 +08:00
只想知道楼主作为一个技术总监，有没有想过自己在这个事件里有什么问题？
|
 |
171
Mmiracle110 2019-07-22 16:53:26 +08:00
我觉得过需求的时候，程序员就应该和产品这边沟通是否合理，我们之前也是这么干的，不合理的地方直接提出来。然后讨论，感觉这个没啥问题。但是作为技术总监，你也应该有不合理的地方和产品沟通，而不是直接和开发说把这里改掉。如果改了，产品那边说不认，必须改回来，怎么办？
总的来说，开发是需要理解业务，而不是只盯着眼前的一亩三分地。但是你的做法感觉也是有一定问题的。 |
 |
172
unco020511 2019-07-22 17:01:56 +08:00
你要增加需求或者改需求本来就要推动产品经理先出文档或者邮件,技术可以提供一些技术指导或者方案,但必须由产品经理发文档或者邮件,技术这边才按需修改,否则不就乱套了吗?
你技术修改了,产品和测试都不知道,流程不就乱了吗? 再说改出问题了谁负责?是你还是改的那个程序员? 测试的测试用例需不需要对应修改? 这些都是问题 |
|
173
unco020511 2019-07-22 17:09:19 +08:00
按楼主的意思,按流程就是怕背锅?混日子?你不经过产品经理就私自修改需求,那是你们产品经理脾气好,我们产品经理早在会议上拍桌子了;
你作为技术总监发现了问题,理应先去跟产品经理沟通,确认修改后让他发邮件,这样又快又避免了很多问题; |
|
174
Mmiracle110 2019-07-22 17:14:04 +08:00
@Mmiracle110 补充下之前的回答，如果是程序性能上或者设计上的问题，你要求开发改，我觉得没问题，也不需要和产品沟通，如果开发一次两次不改，可以考虑裁人；但是如果是产品流程上的问题要改，我觉得是需要拉上产品，开发这些人一起讨论
|
 |
175
doing1 2019-07-22 17:19:18 +08:00
嗯，思考，重要的是思考，不仅仅是执行。
|
 |
176
shikimoon 2019-07-22 18:06:49 +08:00
我们之前也是这样，每次质疑产品设计就是被怼回来，理由不外乎用户需要的，竞品就有这个功能。导致产品一昧做加法，越来越臃肿越来越难用。结果导致用的人越来越少以至于裁员，反思之后，目前流程都需要有人讨论可行性和合理性，吵架是必要的，千万不要认为吵架伤了和气。也千万不要总是站在自己的立场去思考问题，只关注自己的那一亩三分地，认为程序猿就是写代码的，产品让做成什么样就是什么样，不然一个产品永远也做不好，自己也不会有提升
|
|
177
lonelygo 2019-07-22 18:39:37 +08:00
@version 所以楼主根本没必要和这种 CRUD 工程师计较什么，既然人家要废自己，那就目送好了，而且为了业务安全 D 这种活都不给他。
|
 |
178
WispZhan 2019-07-22 18:46:47 +08:00
这些都是没有灵魂的。 真正一个有灵魂的人，不论做什么都是想着如何做的更好。真有好的办法和点子，会主动找产品和负责人沟通。
--- 巧了，前几天我也和同事聊起这类问题。我认为互联网企业里的“工程师”应该对得起“工程师”这个头衔。而不是真正的一个程序员！ |
|
179
version 2019-07-22 19:57:47 +08:00 via iPhone
@lonelygo 其实楼主的情况看得出是小团队的创业企业，之前的技术总监带不动跑路了，后来楼主入职了，要求改，小的都能顶嘴，然后我是看不惯那么多人说楼主，流程什么的，也要区分情况，那么多人回复其实不是现在互联网的通病么，支付宝为什么那么卡，那么多年了，说白了就是没人敢提需求，没人敢动，很多应用都是第一版完美，越更新越卡，企业到了一定人数其实就是权斗，一周一半时间开会某行需求都能扣字眼那些，大评审下来到开工可能历经 1 年，喝喝下午茶过过日子，写写 ppt, 最怕就是大企业出来的人当技术总监，框架完全就是在大企业没机会练手然后拍板定下来，遇到问题也是忽悠手下加班解决，大企业也知道这些问题的，招那么多技术也是底面和储备，免得真遇到互联网 ai 抢人也不会血亏，平时复杂的都是外包，国内各行各业也是这样
|
|
181
lonelygo 2019-07-22 20:22:18 +08:00 1
@version 说实话，我就看了楼主的帖子，回复就扫了一眼，基本算是没看，但是能猜到有喷流程主义的，有喷谁背锅的。
楼主的有关产品经理的认识我是绝对赞成的，真正好的产品经理凤毛麟角，大多数产品经理其实就是“原型工具使用者”，干的活根本算不上“产品”。 产品迭代下来，后期都是在代码屎山里爬，这个是无法避免的问题，无非就是前人干活设计靠谱、代码工整、文档能和代码对上绝大多数，爬屎山轻松点而已。最后就是写代码的不敢接需求，提需求的给严严实实怼回去，让大家形成了“重视开会套路、需求评审”这些扯皮的事情，而且，把扯皮当成了正事和正义。 小企业理智的 Boss 是怕大企业出来的人做 CTO，一方面有可能无脑直接照搬大而全的 state of the art，HC 和工资包袱就能把小企业玩死；另一方面也有可能如你说的终于有话语权了，拿没经过时间验证的新东西来练手、跳坑；也有可能大企业是制度完备和管理完备的，技术可能就没参与过管理，然后要做管理了，定制度，带团队了，无招了，最后团队散事情搞不定，没有一个人开心。 但是呢，小企业又蜜汁相信大厂经验，认为只有大厂背景才是“最佳人选”。 所以我以为 @CF3B5 可以忽视这个帖子了，既然到了这个位置，架在火上烤了，还是看看管理类的书籍，快速入门管理。 |
 |
182
jabin88 2019-07-22 20:22:28 +08:00
技术总监说要改就改？ 不把产品总监放在眼里了 别把底层小弟当作你们做政治斗争的工具。
|
|
183
version 2019-07-22 21:05:47 +08:00 via iPhone
@lonelygo 是的，不懂技术的老板确认偏爱大厂的架构，如果是投资人的钱老板可能无所谓，如果是老板自己的，他更愿意听反对意见，本来技术部就是无底洞，普通的一个月 40 万工资也没多少员工，算上其它开支一个月就差不多 60 万了，一年下来没变化，那就悬了，
其实无状态的微服务适合大部分企业，技术总监分模块和定义，每个人去实现自己的服务，开发前定义假接口也对接假接口，压测和工期大家也不会相互影响，写得不合格的可以滚蛋， 串联出版本和压力测试一眼就看到哪些是技术菜的，面试吹牛的，直接劝退，留下的发项目奖金， 技术总监和老板搞好关系多沟通就好，不听话的赶走一两个就是了，剩下的都明白 很多人都是网上嘴炮的，等收到离职信或找工作，哭的都有可能 真以为那么多岗位，其实那些都是长期挂着根本没打算招人，一天都能收到几千份简历 |
 |
184
kevinzhwl 2019-07-22 21:10:37 +08:00 via iPhone
一句话，在我们公司 ceo 都不行。去找产品经理
|
 |
185
essicaj 2019-07-22 21:27:42 +08:00
流程问题我就不说了，我就说一点：现在产品经理对产品的改动、调整十分依赖数据，但因为职责分离的缘故，大部分情况下研发岗是接触不到真实环境下的数据的，即便有提取数据的需求，也是要请产品经理来帮忙。所以敢问一句，我连基本的数据都没有，我怎么能更好地优化这个产品？我甚至连想法都不会有，因为你根本不知道你的优化是不是在做负优化。
|
|
186
CF3B5 OP @version
其实关于大厂的产品经理问题，我觉得他们这么做是有道理的，最简单的一个原因，就是他们的产品基本上都是市场规则的制定者，所以他们在产品设计调整方面，确实需要有个产品经理在里面去思考整个市场的利益分配问题！是的，就是利益分配的问题，而不是产品体验！说白了这些公司的资源配置，随便你只要做个不低于市场平均水平的产品出来都不会太差！你反过来说小公司的产品，如果技术这边不给力，都像上面一些人认为技术就应该等需求混日子的话，就算让张小龙也没用！其实我听说张小龙也并不是多牛逼，好像他之前在腾讯也都是靠 foxmail 在公司吊命而已，而且腾讯的邮箱本身做的就是半死不活，而且邮箱本来就是昨日黄花了，所以他一直甚少建树，被人非议，马化腾其实几次都想裁掉他这个团队了，但是马性格上也比较优柔寡断，一直拖拉才没下狠手！哈…… @lonelygo 知音，必须握手……哈哈！我管理这块确实比较薄弱，所以现在也在努力各种爬书中，你说的都非常有道理，有机会一定要向你多多学习请教！ 虽然这贴有很多人反对我，不过我也看到有不少人确实认同我的观点，其实这就够了，这世间的问题，同道者不求多寡，只求有无，如果某个问题是人人都有统一的答案，其实就不能称之为问题了！ 有时候我真觉得人的起起伏伏，3 分能力，7 分天命！就好比我最近爬管理上的书，发现有人雷厉风行，说做就做才能成事，但是有人优柔寡断，做起事非常谨慎，瞻前顾后的，结果也成事了！ 技术上一个需求，来来去去也就几种写法，但是依靠团队要办成一件事，管理上的办法成千上万，真的不容易！ 但是我总觉得，无论何事，人心不齐，目标不一致就一定是坏事，这个人心不是说要洗脑成思想一样的人心，而是说团队所有人是否认可自己从事的工作最后能达到的目标是否一致。没有这个一致，就算生产线上的工人也无法把产品做到最好，更别说软件开发这种更复杂的智力劳动！ |
 |
187
mindjetzheng 2019-07-22 21:56:41 +08:00
其实就是边界的问题，理想与现实冲突的问题。
理想化扁平化的组织架构当然是每个人都把团队的产品视为己出，但现实情况是，人员能力参差不齐且高度专业化，这样各司其职反而出错率低一些。产品就只管产品和用户体验设计，开发就只管需求实现落地。至少说，能让流程跑起来。而扁平化架构在这种情况下很容易出现“朝令夕改”。 具体采用哪种方式，还是得看团队规模和人员能力建设情况。 |
 |
188
fvckDaybyte2 2019-07-22 23:27:37 +08:00 via iPhone
有问题为什么不在看文档的时候提，写代码之前纠正……不建议写完程序之后才开始检查功能。文档看不出来的问题不算。
|
|
189
lonelygo 2019-07-23 00:03:17 +08:00
@version 公司实际支出，如果在把工位、设备、水电这些乱七八糟的成本核算进来，公司支出是账面发出去工资的 1.5 倍都不止，而且稍微想做点事情，准备融资的，合规都要考虑也不敢避税了，五险一金也不能乱来了。
JD 放出去么，简历上的快的前三岗位：设计、前端、产品，一天不看吓死人的节奏。 微服务说说也没啥难得，但是我见过一个苏宁干过的 30 岁的 Java，这是吓人的技术储备： 别人 boot 建的项目，他接手维护迭代后，升级要打 jar 包去生产环境替换。我以为还是传统的 SSH，就说你要看看 boot 啊，你们这种业务最适合微服务场景啊，要往 boot 上迁，然后 cloud，docker 用起来多省心啊。 人家说，就是 boot 建的工程啊，我说那你干嘛还 jar 包部署啊，不知道 docker 啊。 答：不知道 docker，没看过 cloud。 他的垂直拆表的办法，我估计你能猜出来。 @CF3B5 你可能掉入技术理想化的陷阱了，慈不带兵，该出手就要出手，否则无法立威。 你可以看看我之前的一波骚操作： https://zhuanlan.zhihu.com/p/30551539 实际上 V2 里面也有，懒得去翻了。 |
|
190
CF3B5 OP |
 |
191
sampeng 2019-07-23 08:27:59 +08:00 via iPhone
lz 不必纠结…这类人，下次裁员，各种 curl 的事，费力不讨好的事，不用动脑子的事。一个公司总有这些没什么搞头的事，总要有人来干。你这现成的人力储备。干这些事滑水最好了的，不用背锅，所有事也是在走流程。你也不用纠结… 2-3 年干毁了又不是你的意愿，要尊重每个人的选择…技术领域拿一年事干 5-6 年的多的是，自己都毁了还不自知
|
 |
192
l00t 2019-07-23 09:05:28 +08:00
得有决定权啊。现在又不是单打独斗的年代了，一个项目，不说别的角色，就单纯开发，也有一堆人在做，互相之间有不同意见很正常，听谁的？很多东西甚至没个对错之分，争个几次都没争到话语权你让人还怎么愿意去思考产品设计？你举例说 Linus，但人家对 Linux 怎么做有话语权啊。
另外，不同于你的“说起某个软件、某个系统的作者的时候，无一例外提到的都是这个软件、系统的程序员，工程师”的观点，实际上我们日常遇到的大多数软件都不知道谁是它的开发者，或者说它也不能简单归功到某一个人身上。VSCode 谁开发的？ Visual Studio 谁开发的？ IntelliJ 谁开发的？我们只知道哪个公司开发的，进而哪个团队开发的，但是并没有多少人关心具体的程序员是谁。 |
 |
193
misaka20 2019-07-23 09:10:46 +08:00
你的想法都没啥问题，但是你也必须去说服产品经理，然后再让他们改。
|
 |
194
turi 2019-07-23 09:13:02 +08:00
做棋牌的。
游戏界面，抄袭竞品，完全一样。你给我说提需求，市场那帮人完全不听你的，抄袭竞品就对了。 玩法，几天改，明天改，天天改。你给我说这个规则天天，能不能一次性对接好，产品来说：市场这么要求的，我也没办法。 主界面绿色清新，俱乐部界面暗黑主题。这 tmd 搭配不丑？我 tmd 都觉得丑，都 tmd 两三年了，就是没人换。 200 多人的研发人员，你说咋没人去管呢？ 我 tmd 给运维提过不少于十次，gcc 要升级到 c++11 版本，不奢求 c++14 17 啥的。 tmd 运维不给你升级啊。 |
 |
195
guolaopi 2019-07-23 09:45:49 +08:00
1.想法是好的，是不应该仅仅局限于只写代码，要思考别的东西。
2.注意仅仅思考就够了，在其位谋其职，况且隔行如隔山，自己琢磨出来的大概率不如人家专业做产品做出来的（别玻璃心我说的是专业做产品的。 3.公司里做事不要越级，不要越级，不要越级。 4.换位思考一下，如果你是员工，产品定下来的东西技术总监让你改你又会怎么样？ 最后再强调一下，想法是好的，所有人都应该在业余时间去提升自己，包括但不限于：感受下别的工种（产品、UI 等），发展别的技术栈，增加兴趣爱好，增加技术深度，甚至看书旅游等等。 |
 |
196
Keyes 2019-07-23 09:53:21 +08:00
@CF3B5 看 LZ 帖子真是深有感触
当年背着笔记本到处给客户演示功能（尤其那会儿电池普遍不给力，用了两三年的笔记本经常 10 分钟没电了，还到处找客户问插头在哪），演示完回来加班加点按照客户说的再改到满意，再拿过去试用。 说起来苦，但现在想想，那会儿真是很棒，真的是做软件的 现在呢？产品经理、项目经理、开发 leader、前端、后端、架构师、DBA、测试、交付，不得不说，商界大佬真是神奇，能把软工搞成这么流水线化 但是我觉得这种分工就是纯纯扯 J8 蛋的，是商业流水线带来的结果，这就 TM 是商业最大化利益而已。而现在所谓的全栈，才是软工本貌，一个功能，一个产品，就是要从市场调研、需求沟通、设计、实现、测试、交付全都做完，才是真的在做“工程师” 看楼上大部分回复，真是觉得好笑，你既然喜欢做你公司的螺丝钉，那请继续做吧，守护你公司的流程去吧，十年后见分晓。 |
|
197
guolaopi 2019-07-23 09:56:10 +08:00
@guolaopi 再补一个，别老拿开源项目说事儿，贵司不是做开源项目的吧？基本上公司产出的东西都是“商品”性质的。我认为根本无法相提并论。
开源什么的我不懂，但是 linux 的毛病没人负责也没人有义务帮你解决。 公司产品就不一样了，支付宝出个 BUG 你试试？ 产品那块说的是对的。但是把开源拉出来就不好了。 |
 |
198
xiaonengshou 2019-07-23 10:00:35 +08:00
额。baidu 和 ali 都是技术领导产品啊。产品委员会的老大一定是技术，并且一定是归属于技术委员会。比如在阿里，产品最高只能是 p9 但是技术可以 p12 都没问题
|
 |
199
knightgao2 2019-07-23 10:07:25 +08:00
按流程走，一线的程序员，要是谁都说上一句就改了功能，那么出问题了，背锅的一定也是一线的程序员。
换我，我最多口头答应，但绝不改，除非出了问题，有人会站出来背锅 |
 |
200
SunFarrell 2019-07-23 11:36:15 +08:00
要我，我会这么说
你的建议我不太懂，建议你和产品经理商量下，我从他文档里看他全局上都有考量，如果可以，我也想加，但现在这么突然是有风险的，我目前的工作对于整个产品来说是一个点，目前还看不到整体，你还是先和产品商量下吧 PS： 1. 我们的目标是完成产品，不是把同事放到自己的对立面上，为了高效的完成产品，沟通和尊重很重要 2. 年迈的 90 后 |
Select Language