最新发布《数智时代的AI人才粮仓模型解读白皮书(2024版)》,立即领取! 了解详情
写点什么

杂谈:创业公司的产品开发与团队管理

  • 2015-07-01
  • 本文字数:4627 字

    阅读完需:约 15 分钟

一般来说,创业公司规模小,人员少,没有大公司的官僚作风。而官僚作风是很害人的东西,记得在大公司时,本来一言而决的一点小事,常常因为害怕承担失败的责任,或参与者(如管项目或管人的经理们)有意的要突出自己的影响力或存在感,在各色人等中往来穿梭,仿佛煞有介事,经过无数次的会议讨论却议而不决。而软件工程师们为配合这样的戏码常常被搞得焦头烂额,无可适从。创业公司由于管理层次简单,很少受到官僚作风的困扰,但也不能想当然地认为万事大吉,高枕无忧了。其实创业公司也有创业公司的局限性,这些局限性常常被忽略,从而影响到产品的开发,兹总结如下。

创业不一定志高。人们往往认为创业公司旨在 IPO,对自己的产品计划往往雄心勃勃。其实并不尽然,有人就认为,创业公司的资源配备不能和大公司相提并论,因此,做出的产品比大公司差些也是理所当然的。而创业公司产品的优势主要在于低廉的价格。听起来似乎有道理,其实是在为自身的懒惰或能力上的缺陷寻找借口。就如同国家足球队那样没有出息,踢输了,或怪草皮太硬,或怪裁判不公,或怪状态不佳,或怪对手太强。在竞争如此激烈的市场,一个创业公司如果做不出最好的产品,为用户提供实实在在的价值,既没有生存的可能,也没有生存的必要。因此,三军可夺其帅,匹夫不可夺其志也,唯有如此,创业公司才有成功的可能性。

简单不一定高效。有些创业公司不太注重项目制定计划,或者不太善于制定项目计划。没有完善可行的项目计划,就更谈不到项目状态和进度的检查和管控,常常是做到哪里算哪里。当然看起来很简单,高效却是未必。大家不清楚什么时间做什么事,也不知道事情的轻重缓急。每个人似乎都在忙忙叨叨,而究竟忙些什么,却是糊里糊涂。临近项目结束时,发现还差很多,于是加班加点赶进度,哪里还顾得上产品质量。

人少不一定沟通流畅。软件开发当然需要团队合作,无论团队大小,项目经理、产品经理、UX 设计师、开发工程师、测试工程师需要准确有效地沟通协调。对于新的功能:产品经理一定要讲明白它的作用和价值,开发工程师才有信心做好;开发工程师要和测试工程师一起检查主要的功能测试点,制定测试计划;项目经理要确保开发计划让所有人都清楚地知道,并协调任务之间的相互依赖。创业公司人少事多,有时候身兼数职,若没有有意识的沟通,大家都埋头于自己的工作,个人自扫门前雪,莫管他人瓦上霜,就可能出现这样的情况,事情做完了,才突然很惊讶地发现完全搞错了。

年轻不一定朝气蓬勃。曾国藩认为:“军事是喜朝气,最忌暮气,惰则皆暮气也。”创业阶段的公司本应该是披荆斩棘,锐意进取,表现出勃勃的生机。但创业的艰辛往往超出创业者的想象,不断的挫败侵蚀着创业者的意志,从而直接影响民心士气。如果面对困难既没有愿景,也没有解决之道,由失败引起的沮丧就可能变成不可逆转的暮气,最终压垮整个公司。

正如有什么样的人民就有什么样的政府,产品的品质归根结底取决于做产品的人,有什么样的工程师(开发和测试)、设计师、架构师、产品经理,就有什么样的产品。因此,保证产品品质最有效的办法莫过于打造一支高水平的团队,而团队建设很大程度上取决于领导的艺术。

让我们来看看从历史中可以学到什么。秦失其鹿,天下人共逐之。最后的竞争在最有实力的两个对手刘邦和项羽之间展开,当然最终的结果是屡败屡战的刘邦完胜屡战屡胜的项羽。历史学家们从个人性格、政治智慧、军事才能、战略战术等各个角度对胜负之数做了全方位的分析,我认为决定最终胜负的最重要的原因当属创业团队的建设。刘邦的团队网罗了当时顶尖的一流人才,项羽当初的创业团队也毫不逊色。项羽拥有战国贵族的血统,接受过良好的教育,“见人恭敬慈爱,言语呕呕,人有疾病,涕泣分食饮”,更尊范增为亚父。而平民出身流氓习性难改的刘邦却慢而侮人,甚至于向儒生的帽子里面撒尿。但是在项羽实力鼎盛的时候,一些了不起的大牛如陈平、韩信之辈却选择去项王而从沛公游,何也?原因其实很简单,刘邦长期在黑社会中混迹的经历以及在革命斗争的实践中锻炼出了高度的智慧和不凡的见识。使他有能力明白团队中大牛们的高明见解,闻弦歌而知雅意,并且不断激发团队的想象力和创造力。这其实就是所谓的领导力,也是刘邦“不能将兵,而善将将”的秘诀。而项羽虽然个人素质过硬,具有很高的军事天分,巨鹿一战,大破秦军,“召见诸侯将,入辕门,无不膝行而前,莫敢仰视”。但他毕竟“too young, too simple, sometimes naïve”,不是不尊重别人的建议,而是缺乏君临天下而应有的领导力,稍微高深一点的意见便不能理解。让我们来看一个具体的例子,当有人劝霸王定都关中的时候,他却说:“富贵不归故乡,如衣锦夜行,谁知之者?”如此幼稚可笑的话,真叫人瞠目结舌,怪不得人家骂他沐猴衣冠,竖子不足与谋。而面对同样的建议,尽管“左右大臣皆山东人,多劝上都雒阳”,但是刘邦却知道这个意见的重要价值,排除众议,定都关中,为后世弭平七国之乱起到了至关重要的作用。所以,一流的人才都离开项羽,跳槽到刘邦那里,把好的主意讲给听得懂的人了。

关于这一点,Steve Jobs 讲得更明白:

“For most things in life, the range between best and average is 30% or so. The best airplane flight, the best meal, they may be 30% better than your average one. What I saw with Woz was somebody who was fifty times better than the average engineer. He could have meetings in his head. The Mac team was an attempt to build a whole team like that, A players. People said they wouldn’t get along, they’d hate working with each other. But I realized that A players like to work with A players, they just didn’t like working with C players.”

一流的人才愿意和一流的人才一起工作,因为他们之间有共同语言,相互理解;而一流的人才却不愿意和三流的人才一起工作,因为三流的人才根本不能明白一流的人才的想法和意图,讨论问题时总是缠夹不清,糊糊涂涂,无可无不可。另外,刘邦比之项羽还有另一个重要的优点,那就是毫不吝啬的激励措施,刘邦“使人攻城略地,因以与之,与天下同其利”,而项羽“至使人有功当封爵者,印刓敝,忍不能予。”所以,百战百胜的项羽不能保证最后决战的胜利。垓下一战,只落得霸王别姬,英雄气短,天数耶?人事耶?历史事件常常会惊人的相似,相似的剧本在三国时期再次上演。这次的主角换成了雄才大略的曹操和刚愎自用的袁绍。袁绍榆木疙瘩一样简单的大脑也同样不能理解高明的见解,一而再,再而三地失去良机。在官渡之战中被实力远不如自己的曹操击败,从此一蹶不振。

历史的经验更加验证了那句俗话,兵熊熊一个,将熊熊一窝。做领导的不一定十八般兵器,样样精通,但一定要加强修养,提高领导力,这是打造一支优秀的开发团队的必要条件。产品的开发是百分之百的智力游戏和创造性活动,每个工程师的最重要的贡献是 TA 的创造力和想象力。而领导要有足够的智慧和见识用来领悟他们高明的建议,并想方设法利用各种激励措施把他们的想象力和创造力最大限度地激发出来。相反,一个比较“熊”的领导形式上搞再多的头脑风暴,对所谓的创新也一样的于事无补。我曾经历过这样一个产品开发团队,几乎所有的人对产品的目标和价值都不甚了了,甚至说不明白产品是什么,也不知道如何与同类型的产品做区分。很多人建议要把这些问题好好讨论清楚,但是团队的领导认为先做起来看,在开发中逐步加深认识,也许一下子所有的问题都清楚了,最不济大家也可以在开发中练练手。最终的结果可想而知,产品不可避免地失败了,刚刚招聘成立的部门也全部解散了。这不仅是公司的损失,而且影响到每一位员工的职业生涯,同时也浪费了宝贵的生产力。这说明如果领导把握不住产品的正确方向,即使开发团队努力再多也不过是徒劳无益,与成功南辕北辙,渐行渐远。

大公司设计的那些官僚而笨拙的开发管理流程不是创业公司可以承受之重。其实,最好的管理就是没有管理。无为而治,所有人都在生产第一线,写代码,做测试。仿佛是一条由机器人操控的自动生产线,所有的开发任务都按部就班进行,顺利得像流水一样。没有任何人力、物力浪费在管理工作上,当然生产效率是最高的。我想,这是一种可望而不可即的理想状况。因为,产品开发本身不是流水线式的作业,存在许多不确定因素,比如对于每一项开发任务,几乎不可能正确地估计出需要的时间,产品的需求随时可能发生变化,任务之间存在各种依赖关系。所以,我们需要把开发工作划分为具体的可操作的开发任务,估计每项任务所需的时间,根据需求的变化确定任务的优先级,协调任务之间的进度等,所有这些都属于管理工作的范畴。因此,我们只能尽量减少管理,而做不到完全没有管理的理想状态。为了下文叙述的方便,我们把管理产品开发的人统称为开发经理,可能的角色包括产品经理,项目经理,技术主管等。开发经理应努力克制自己,尽量减少因为管理对工程师的工作带来的干扰以及时间与精力的开销,让工程师专注于创造性的工作。开发经理要多做功课,精简管理的流程,没有必要开的会就不要去开,能够开短会的就不要开长会,小会能够解决问题的就不要开大会。记得在某大公司时,开发经理们为了同步项目的进度和状态,早上工程师开始工作之前,每个开发小组都要花一刻钟到半个小时的时间开一个例会,报告自己昨天的工作和今天的计划。另外,还有数不清的各种各样的项目状况汇报会。这当然方便了开发经理了解项目的状况,但却浪费了工程师的时间和精力,去一遍又一遍地应付开发经理们重复且无聊问题。

对于创业公司而言,管理要做到尽量简单,只要每个人都有事做,清楚地知道什么时间做什么事,并保证每件事的质量,就基本达到管理的目的了。开发经理要像一个在场边指挥的足球教练,能够及时发现团队或个人的问题和缺陷,并采取有效措施加以补救,不能等到形势严重了还浑然不觉,而当团队运行顺利时,开发经理就应该像空气一样自动消失;开发经理要像一个高明的调酒师,调酒师知道各种调料的风格味道,并能按照恰当比例制成美酒佳酿,开发经理也要清楚团队中每个工程师的性情,优点和缺点,取长补短,合理搭配组合,高效率、高质量地完成任务;开发经理要像一个拉拉队长,激发工程师的创造力和想象力,鼓舞士气,传播正能量;开发经理要像一个后勤部长,凡是和产品开发不直接相关的杂事,都能搞定。

为了追求简单高效,照搬大公司的产品开发流程固然不可取。但对于行之有效的方法也断不能一概拒之门外。比如,每个人都要清楚地知道产品开发计划,规范测试的方法和流程等。当然有些方法要经过改造才能适用于创业公司。比如代码审核,很多程序员认为是在给自己的工作挑刺,仿佛被批斗一样,感觉很不舒服,甚至有些抗拒。若从另外一个角度来看,代码审核就是另外不同的情景。当程序员对应用的需求不太明确时,代码审核可以用来帮助理清需求;当程序员对自己的代码没有信心时,代码审核可以用来帮助发现问题,修正错误;当程序员写出优雅的算法时,代码审核可以用来展示 TA 的奇思妙想。所以,代码审核绝不应该是挑战程序员,而是帮助程序员。这一点同程序员解释清楚了,那么,程序员就会主动要求审核自己的代码了。


感谢丁晓昀对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入 InfoQ 读者交流群)。

2015-07-01 00:123608

评论

发布
暂无评论
发现更多内容

Redis - 跳表以及其内部结构

insight

redis 4月日更

警惕数据泄露!快给你的数据加上安全密钥!

亚马逊云科技 (Amazon Web Services)

专访前美篇首席架构师张超|从工程师到CTO的蜕变

Aldeo

程序员 采访 调查采访能力考核

百度南渡,护航泉州水务的产业智能化征程

脑极体

微服务架构核心基础讲解

麦洛

微服务

Linux nslookup 命令

一个大红包

Linux linux命令 4月日更

Guide to UUID in Java

OutOfMemory1024

Java

低开销获取时间戳

捉虫大师

Java

基于mysqldump聊一聊MySQL的备份和恢复

麦洛

MySQL MySQL 运维 数据备份

如何打造更为精准的个性化推荐?Amazon Personalize 有独门技术秘籍!

亚马逊云科技 (Amazon Web Services)

采访彩食鲜 CTO乔新亮:程序员如何持续的登上新台阶

风翱

4月日更 采访提纲

低代码真能做到“让人人都能做开发者”吗?

优秀

低代码

架构师实战营 模块一总结

代廉洁

架构实战营

如何批评下属?

石云升

团队建设 28天写作 职场经验 管理经验 4月日更

运动的这两个价值,你知道吗?|靠谱点评

无量靠谱

Go Channel

escray

学习 极客时间 Go 语言 4月日更

话题讨论|To B & To G,互联网公司的下一主战场

程序员架构进阶

话题讨论 28天写作 4月日更 To B业务 领域思考

轻松搞定XML和对象之间的互转,就它了!

麦洛

xml XStream

Zip和7-zip谁更强,如何选择?

麦洛

ZIP格式 ZIP zip4j

Linux OOM Killer

OutOfMemory1024

Linux

如何从零开始学Python:(5)如何处理列表中嵌套多个列表?

广之巅

Python 4月日更

JVM 读书笔记(一) 内存划分

U2647

JVM 4月日更

如何缓解低代码开发的安全风险

YonBuilder低代码开发平台

小程序云开发 开发者 低代码 APP开发 APICloud

TO B产品从0到1:从项目中走出来

菜根老谭

产品孵化

计算机原理学习笔记 Day12

穿过生命散发芬芳

计算机原理 4月日更

独家对话阿里云函数计算负责人不瞋:你所不知道的 Serverless

阿里巴巴云原生

Serverless 容器 微服务 开发者 云原生

专访阿里巴巴研究员吴翰清 | 安全的持续运营之道

架构精进之路

4月日更 调查采访能力考核 人物访谈

Open Source Load Testing Tool Review 2020

OutOfMemory1024

Load Testing Open Source

Ubuntu 20.04 启用休眠(Hibernate)配置过程

OutOfMemory1024

Ubuntu20.04

乘“云”加速疾病诊断研发,亚马逊云科技新阶段“诊断开发计划”已开启!

亚马逊云科技 (Amazon Web Services)

不惧业务规模与复杂性,实现敏捷的云转型“三步走”就对了 | 云途专栏

亚马逊云科技 (Amazon Web Services)

杂谈:创业公司的产品开发与团队管理_语言 & 开发_贾彦民_InfoQ精选文章