仟家信黄金分析软件【视频】那些年,被自己的技术者思维虐过的项目经理们-琦点思维

作品分类:全部文章 2020-11-04

【视频】那些年,被自己的技术者思维虐过的项目经理们-琦点思维


不论在哪个国家,IT 公司中的项目经理,很大一部分都是技术出身。的确,工程师背景的项目经理,在开发人员选择,开发进度控制,客户需求把握等诸多方面,有得天独厚的优势,从程序员到 leader 再到项目经理也是常见职场发展方向之一。
最近这几年在世界各地突然吹起了一股全民写程序的风潮,连美国总统欧巴马都在写 JavaScript 了,但是身为一介靠写程序(以及在上班时间胡乱上网)来谋生的 developer(所谓的 developer 就是「软件工程师」的比较潮的说法),想要提醒那些想学习写程序的人一件重要的事:慎选你的第一个程序语言。
在软件工程师(中国叫做「程序员」或「码农」)的圈子里,文人相轻的现象可是非常严重的,在程序设计的各个领域里都有着错综复杂的「鄙视链」。从程序语言、编辑器、平台到 { 是写在 if 的同一行还是下一行,不同阵营的人都习惯鄙视来鄙视去。而其中「你用什么程序语言?」更是大家最热衷的一条鄙视链,所以对于刚踏入程序设计领域的初学者来说,万一程序语言选得不好,可是会一开始就落入鄙视链的底层啊。
软件工程师的鄙视链到底有多惨烈、多残酷呢仟家信黄金分析软件?程序语言篇
懂 Functional Programming 的工程师鄙视老是把设计模式挂在嘴边的工程师,老是把设计模式挂在嘴边的工程师鄙视会说「你这样写就不 OO 了啊」的工程师,会说「你这样写就不 OO 了啊」的工程师鄙视会说「哈?什么物件导向大红团?不是把重复的 code 写成一个 function 就好了吗?」的工程师,会说「哈?什么物件导向?不是把重复的 code 写成一个 function 就好了吗?」的工程师鄙视把同一段 code 到处复制贴上的工程师全素敏,把同一段 code 到处复制贴上的工程师鄙视 PM。
写静态语言的工程师鄙视写动态语言的工程师。
写组合语言的工程师鄙视写 C 语言的工程师,C 语言工程师鄙视 C++ 工程师,C++ 工程师鄙视 Java 和 C# 工程师,Java 工程师和 C# 工程师则互相鄙视,而 C# 工程师又鄙视 Visual Basic 工程师和会把 C# 念成「C 井」的工程师,会把 C# 念成「C 井」的工程师则鄙视认为 HTML 是一种程序语言的设计师。
用 Python 3 的工程师鄙视还在用 Python 2 的工程师,用 Python 2 的工程师鄙视遇到 UnicodeEncodeError 的工程师。
写 iOS 的工程师鄙视写 Android 的工程师,写 Android 的工程师鄙视写 Windows Phone 的工程师。
有 Swift 一年经验的工程师鄙视有 Objective-C 五年经验的工程师,写 Objective-C 的工程师鄙视用 PhoneGap 包装成 native app 的工程师。
用 React.js 的工程师鄙视用 AngularJS 的工程师,用 AngularJS 的工程师鄙视用 jQuery 的工程师,用 jQuery 的工程师鄙视用Vanilla JavaScript的工程师,用 Vanilla JavaScript 的工程师鄙视 IE 的使用者。
会用 debugger 的工程师鄙视用 assert 的工程师,用 assert 的工程师鄙视只会 print () 的工程师;用 console.log () 来 debug 的工程师鄙视用 alert () 来 debug 的工程师。
写 Ruby on Rails 的工程师鄙视所有使用其他语言的工程师。
什么?你说 Ruby?Ruby 只是 Ruby on Rails 的一套框架,才不是什么程序语言呢!
所有的工程师都鄙视 PHP 工程师。工具篇
用 text editor 的工程师鄙视用 IDE 的工程师。
用 Vim 的工程师鄙视用 Emacs 的工程师,用 Emacs 的工程师鄙视用 Vim 的工程师,无论是用 Vim 或 Emacs 的工程师都鄙视所有用其他编辑器的工程师;用 Atom、Notepadd++、Sublime Text 的工程师鄙视用 Windows 记事本的工程师。
用 Android Studio 或 IntelliJ IDEA 的工程师鄙视用 Eclipse 的工程师,用 Eclipse 的工程师鄙视用 NetBeans 的工程师。
用 Git 或 Mercurial 的工程师鄙视用 Subversion 的工程师,用 Subversion 的工程师鄙视用 Dropbox 来做版本控制的工程师,用 Dropbox 来做版本控制的工程师鄙视根本不知道什么叫做版本控制的工程师。
用 Zsh 的工程师鄙视用 Bash 的工程师,用 Bash 的工程师鄙视用 Cygwin 的工程师,用 Cygwin 的工程师鄙视用「命令提示字元」的工程师,用命令提示字元的工程师鄙视用 GUI 介面的工程师。
用 IRC 的工程师鄙视用 HipChat 的工程师,用 HipChat 的工程师鄙视用 Slack 的设计师。
用 reStructuredText 写文件的工程师鄙视用 Markdown 写文件的工程师,用 Markdown 写文件的工程师鄙视用 HTML 写文件的工程师,用 HTML 写文件的工程师鄙视不写文件的工程师,然后用 LaTeX 写文件的工程师鄙视所有工程师。
用 Docker 来部署 server 的工程师鄙视用 Ansible 或 Puppet 来部署 server 的工程师,用 Ansible 或 Puppet 来部署 server 的工程师鄙视用 Fabric 来部署 server 的工程师,用 Fabric 来部署 server 的工程师鄙视手动 SSH 的工程师。OS 篇
用 Mac OS X 的工程师鄙视用 Linux 的工程师,用 Linux 的工程师鄙视用 Windows 的工程师。
用 Debian 的工程师瞧不起用 Ubuntu 的工程师,用 Ubuntu 的工程师瞧不起用非 LTS 版本的 Ubuntu 的工程师。硬件篇
用 MacBook Pro Retina 的工程师鄙视用 MacBook Air 的工程师,用 MacBook Air 的工程师鄙视用 ThinkPad 的工程师,然后用 Raspberry Pi 的工程师鄙视用 MacBook Pro Retina 的工程师。
用 Dvorak 键盘的工程师鄙视用 Mac 键盘的工程师,用 Mac 键盘的工程师鄙视用 QWERTY 键盘的工程师,用 QWERTY 键盘的工程师鄙视用手写板的设计师。
坐 Aeron 椅子的工程师鄙视坐普通办公椅的工程师,坐普通办公椅的工程师鄙视跟他一样做普通办公椅的 PM,然后站着写程序的工程师鄙视坐 Aeron 椅子的工程师。职场篇
搞硬件的工程师鄙视搞软件的工程师。
写 OS 的工程师鄙视写 Web 的工程师,写 Web 的工程师鄙视写 desktop application 的工程师。
后端工程师鄙视前端工程师。
工程师跟设计师互相鄙视。
信奉 Test-Driven Development 的工程师鄙视先写 code 再补 tests 的工程师,先写 code 再补 tests 的工程师鄙视不写 tests 的工程师,不写 tests 的工程师鄙视又他妈乱改需求的 PM。
没有证照的工程师鄙视考了一堆证照的工程师。
上班穿休闲服的工程师鄙视上班穿西装的工程师,上班穿西装的工程师鄙视上班穿系服的工程师。
雷子个人认为,从普遍意义上讲,在日本,只要勤奋努力,向上走是很容易的事。但到了管理岗位,即使勤奋努力,有时候思维没有及时转变,也可能遭遇惨败。我就亲见过智商一流,经验丰富技术人员,初任项目经理时,分外努力却搞得焦头烂额,甚至在项目中途被换下,经过很久很久才熬到第二次被提拔……
场上升之路,有时需要些时运,可能各有不同,但失败的原因,有时却很相似。那么,技术者在初任项目经理时,经常会遇到哪些问题,给自己挖哪些坑呢?
故事一
有时候,谎话连篇的项目经理才是好经理
A 君,认识他时,他是个年轻的 leader,技术很不错,还有开荒牛般的勤勉,性格也非常开朗坦诚,能力人品双佳耿直男儿,当 leader 时成绩斐然,自然的,他很快升到了项目经理,一时间意气风发。
做 leader 时很受爱戴,成为了项目经理,依旧沿用了一贯的坦率作风,事无巨细,和大家分享所有和项目有关的事。甚至包括:客户方面的负责人突然换人啊,咱们的契约很危险啊这些情报,也全都毫无保留地告诉给组员们。那么关贵敏,像A预期地一样,全组拧成一股绳,项目圆满顺利地进行下去了吗?
实际上,并没有。在充分了解项目的同时,组员们也知道了大量的关于这个项目的不利因素,倍感不安。私底下,咱领导心里也没底啊,项目要扑街啊,这样的议论越来越多,A明明比做技术时更加努力,但项目状况却每况越下,回天乏力。
后,连部长都觉得“怎么搞成这样,哎,A还是太年轻火锅鸡的做法。”无奈在项目中期换下了A,让经验丰富的B顶上。
B 是个待人和善,初次见面就会让人印象很好的人。上任后,B和整个项目组的人挨个私聊,发现了问题所在——很多人对本来不用他们操心的事感到不安。这种不安,有时甚至影响到了他们的本职工作。
于是,B把大家召集到一起开会,“通过沟通,我了解了大家现在的想法,和对这个项目前景的担心。不过这些担心,很多都是针对潜在的风险的,还有一些问题,是我可以通过斡旋调节解决掉的,balabala……”总之,就是天空飘过几个字儿,那都不是事儿。
这个会,开得效果很好,B自信满满,言之凿凿的一番话,很好的安抚了组员们的情绪,大家专心开发,项目进度竟慢慢地赶上了。
那么B真的像他表现出来的一样有自信吗?
事情的真相是,他非常了解——这个破项目,问题一大把。和组员说的话,很多都是他信口胡诌的……
为项目组的普通成员或者 leader,不管说什么都要有根有据,信口胡诌是绝对不行的。但这不适用于项目经理。有时候就算是睁着眼说瞎话松田英子,也得把组员往正确的方向上带。
“不管怎么努力也来不及了”,一旦让组员有了这种想法,那项目就必定要完。互相扯皮,产生信任危机,生产性下降,品质恶化,是一连串的连锁反应。无论如何也要避免这种情况的发生。
 教训一
项目经理必须要让组员相信:“这些情况早就在我的预料和控制之内,大家放心。”只有这样,组员才能心无旁骛的做好自己的事情。给组员们吃定心丸——是项目管理的手段之一。
这时有的同学可能会说,很多项目从一开始就明摆着是坑,瞎子都能看出来。但即使是这样,把真实情况全部如实传达给组员,也是一点好处都没有。就算项目真的无论如何也挽救不了,那也是项目经理一个人的责任。把真实情况隐瞒下来,何权谋 让组员们安心工作,多少还有一点希望。就算扑街,也不会姿势太惨烈。反过来,把真实情况和盘托出,导致军心涣散,那就真的一点儿机会也没有了。
 故事二
有时候,不会较真的项目经理才是好经理
C 君做工程师的时候,非常优秀。思维敏捷,逻辑清晰,精通各种开发语言。最重要的是,发生问题时,他一定要刨根问底的追查,不仅要找到解决方法还要找到问题的根本原因,从流程上改进,防止再发。这样的思考方式和做法,很多工程师都有。
时的上司和同事们对C君都是绝对地信赖,即使有时他在刨根问底上花费了太多时间,导致进度延迟,上司也都是积极地同客户调整进度或者加人回忆三部曲,从不给他脸色看。
当得知C申请做项目管理,而不是走技术路线的时候张雅卓,大家都挺吃惊的。不过他作为项目经理,负责的前两个小型案件都完成得满好。这时他的上司有些放心了,觉得聪明又努力的人,做什么都会做得不错吧。
之后,他被指定去负责一个具有一定规模的项目。这个项目所开发的系统,有十几个子模块,每个模块有3~4 个成员负责。
一天,C收到了客户发来的邮件“项目进度全体看起来很顺利,但是几个子模块开发进度为什么有些延迟?什么地方出了问题吗?”
C 作为整个案件的项目经理,通常是掌握项目的大体情况,对于每个子模块开发的具体细节并没有过问。第一次被客户质问开发进度延迟的理由,C有点坐不住了,而且他也产生了同样的疑问。
于是,C君询问了这个模块的每个开发人员,得到的回答是:该模块所使用的部分第三方产品,有兼容性问题,加上调用方法不对天湖女侠,不断试错导致了这部分的开发延迟。可是C还是有疑问:“产品兼容性和调用方法不对,真的会导致生产性这么大的降低吗?”
是C又开始了他对于问题刨根问底式的追查。把每个项目组成员负责的工作细细地捋了一遍,得出的结论是——恩,和他们说的一样。于是,他向客户如实地汇报了原因,客户也接受了他的解释。
但是他这么一折腾,本就有点儿延迟的项目,又浪费掉了更多的工数,给组员和他自己又加重了负担。
本来对客户作出最初的解释就完全够了,可是C并没有那么做。像做工程师时一样,在这个问题上刨根问底,但整个过程却只是他的自我满足。本来项目经理和成员之间是互相信任的,由于这件事菲鹰航空,信赖关系也出现了裂痕。
分析问题原因这件事上,项目经理追求的目标应该是客户的满足感。如果弄错了这个目标,花费了大量的精力,那就得不偿失了。
比如说客户问,为什么这个系统能够运行?这个时候只要从产品框架的程度上给客户作出解释就完全够了。如果真要从编程语言和计算机原理的开始讲给客户听,只会让客户一头雾水吧。
确实,如果花费大量的时间精力,去把一个问题彻底弄清,非黑即白,对今后的工作是有帮助的。但这是工程师该做的事情,而不是项目经理。
 教训二
项目经理应该把更多的精力放在客户和成员的组织协调方面。有时候,不得不对问题的正确性和精准性做出妥协。从工程师出身的经理,往往在这一点上很难转变。
 故事三
有时候,不会和部下同甘共苦的项目经理才是好经理
第三个故事,是我的故事。
大多数工程师都是很单纯很热心的人。如果组里的其他成员遇到了什么问题卡住了,很多工程师会留下来加班帮他一起把问题解决掉。但这种做法并不适用于项目经理梦见大肚婆。
我以前当工程师的时候,一次遇到客户要求调查一个问题,要的很急。我和项目经理两个人一直调查到很晚,都没有做完。眼看要赶不上终电了,项目经理一脸抱歉地对我说:“不好意思啊雷子君,今天就辛苦一下,加个通宵的班吧。”
客户要求的,也没有办法,所以我就很爽快地答应了走向中枢。本来以为项目经理也会留下来和我一起加班,没想到这个大哥说了一句“后面的就拜托了!”然后拎包就回家了,只剩下我坐在那里独自凌乱。
然明知项目经理留下陪我加班没有意义,但当时不免心里是颇有微词的。直到后来我自己也当上了项目经理,才体会到他的做法完全正确。
我作为一个个体的工程师,只要对项目经理一个人负责就可以了。但是项目经理需要对整个项目负责,对客户负责。如果他留下来陪我一起加班,第二天早晨一起回家的话,那么第二天的项目推进谁来管?如果客户对于调查结果有追加的疑问,让谁来对应?就算他第二天不回家,一直留下来完成自身的工作,那恐怕也是精疲力尽,效率会大打折扣吧。
面这张图是网上流传很久的,leader 和项目经理的区别。作为 leader,和成员们同甘共苦,是很有必要的,但项目经理绝对不可以。反过来,leader 和成员们只要低头努力工作就够了,但项目经理坐的位置,决定了只有他才能看到前方有没有深渊,后面有没有猛兽。这一点谁都代替不了。
教训三
技术者升级为项目经理墨子怒耕柱子 ,切不可再像做工程师的时候那样事事亲力亲为。懂得自己该做什么,懂得找擅长的人去做他擅长的事情,才是经营之道。
故事四
有时候,想着「等前提条件都确定了再开工」的项目经理不是好经理
这个故事是个段子。
某日,老师在课堂问一个学生: “树上有十只鸟,开枪打死一只,还剩几只?”
学生反问“是无声手枪或别的无声的枪吗?”
“不是。”
“枪声有多大?”
“80-100 分贝五禽戏图解。”
“那就是说会震的耳朵疼?”
“是探虚陵现代篇。”
“在这个城市里打鸟犯不犯法?”
“不犯。”
“您确定那只鸟真的被打死啦?”
“确定。”老师已经不耐烦了“拜托,你告诉我还剩几只就行了,OK?”
“OK,树上的鸟里有没有聋子?”
“没有打手虫。”
“有没有关在笼子里的?”
“没有。”
“边上还有没有其他的树,树上还有没有其他鸟?”
“没有曾挚。”
“有没有残疾的或饿的飞不动的鸟?”
“没有。”
“算不算怀孕肚子里的小鸟?”
“不算。”
“打鸟的人眼有没有花?保证是十只?”
“没有花,就十只。” 老师已经满脑门是汗,且下课铃响,但学生继续问,
“有没有傻的不怕死的?”
“都怕死。”
“会不会一枪打死两只?”
“不会。”
“所有的鸟都可以自由活动吗?”
“完全可以。”
“如果没有其他前提条件,”学生满怀信心的说,“打死的鸟要是挂在树上没掉下来,那么就剩一只,如果掉下来,就一只不剩。”
老师擦了擦汗说:“你一定是个程序员……”
编程做久了,往往思维方式会发生固化致命预感 。工程师都对事物的逻辑性和因果关系有着执拗的追求,“把前提条件全都告诉我”,是工程师的常用语。当然,从工程师的角度来看,前提条件不明确就开工,最后能做出什么样的东西来,只有上帝才知道。
但是,这个世界上从来就没有过从最开始就明确了所有前提和需求的项目。这个时候,就需要对案件的情况做出各种假设,分析可能性,然后在保证最大正确性的前提下开工。如果在项目途中,前提条件或者需求发生了改变,那就再根据具体情况进行调整——这考验的是项目经理的能力。不这么做的话,项目永远也开始不了。
在设计第一台月球车的时候,如果 NASA 宇航局的工程师说:“请把月球表面的详细情报告诉我,否则我没法设计”,这样的话人类可能永远只能在地球上晃悠。当时,月球表面的状态只能从望远镜里观测到的景象进行推测。虽然前提条件很不充分,但也只有基于最大可能性开始设计,别无他法。
做项目也是一样。设计系统的时候,要假设各种各样的前提:系统使用年限,最大并发访问数,相关的法律会不会更改(特别是政府项目或者和金融相关的系统)……
 教训四
先从最确定,可能性最大的部分开始做起,当需求和前提渐渐明确,再逐步调整进度和人员安排。对于项目全局的把握和大局观,往往是工程师初任项目经理时,最为欠缺的部分。
今天,和大家分享了几个小故事,愿大家在职场上升道路上避免这些有可能走的弯路,少付出一些成长的代价。
看法浅薄,期待与大家更多的交流讨论。更加欢迎老司机们向大家分享自己看到过难忘的启蒙 ,经历过的职场经验。结束语
如果你看了以上这些惨绝人寰的鄙视链之后,仍然没有击倒你想要学习 coding 的心,那我必须提醒你一件最重要的事:先去交一个女朋友库贝尔饭店,再来学写程序;因为一旦你成为软件工程师之后,就交不到女朋友了。

(本文所有权归作者所有,如需转载请联系本平台。)
知道你会来
所以我一直在这里等
走过的叫足迹,走不到叫憧憬。
当你扛不住的时候就读一遍(精辟)
不要拿着别人的地图,找自己的路
每个人的心中都有过一个人,也都曾有过英雄梦
没有凭空而降的幸运,只有不断努力后获得的收获!
长按二维码或搜索“ds593481865”即可关注


意见反馈