文档章节

【程序员电子刊精选】同一个团队,同一个目标

yunlong-w
 yunlong-w
发布于 2015/03/31 11:53
字数 1953
阅读 4
收藏 0

程序员和产品人员之间的“矛盾”已经快达到了Emacs爱好者和VI粉丝之间的“矛盾”程度。所以也有不少关于“产品人员如何说服程序员”、“程序员如何参与产品设计”的讨论和分享,本文就是其中之一。同时,这也提醒了那些精于拍摄“婆媳大战”题材影视剧的导演们,如果哪天想拍摄IT题材的作品,“产程大战”是个极好的创意点,会火花四射的。

毫无疑问,我并非想夸大“产程大战”,而是试图解决问题,因为事实上没什么真正的“矛盾”,有的只是两个单纯、可爱的群体之间的打打闹闹。不过客观上,这样的打打闹闹确实是普遍存在的,从初创公司、高速增长公司到上市公司都存在。有时候,双方针对同一问题观点不一致;有时候,双方用各自的专业语言在强调同一问题的两个侧面;甚至有时候,双方在激烈地讨论着两个完全不同的问题,简直是关公战秦琼。这个过程中,各自的沟通技巧、水平、情商固然重要,但除了这些个人素养之外,公司用什么样的原则、方式、标准组建团队、招聘员工、制定工作流程等则起到了基础性的作用。

最小完备团队

在组建团队方面,尤其是大一些的公司,习惯按照专业线来划分,比如包括:产品团队、设计团队、开发团队、测试团队、运营团队、项目管理团队等,然后从不同的专业团队抽调人员组成一个项目组,来负责某个产品的某一次发布或升级。在这样的模式下,大家都是对各自的“专业”负责,而不是对“业务的结果”负责,不同专业背景的同事,缺乏统一的长远目标,相对来说只是比较被动地接受上游的需求,讨价还价。这时,技术人员通常没有机会参与到产品设计环节的讨论,充其量在产品人员(上游)完成需求规格说明书或UE设计后参与评审,给出一些技术可行性的意见,说白了就是“能否实现以及需要多长时间做完”而已。对于技术人员来说,这种形式、这种深度的参与基本无法调动其工作积极性,就更别提创造性了。相反,我们应该以业务或产品为核心,组建一个“角色齐备”的团队,让这个团队长久地对这个业务或产品的结果负责,这里面包括产品经理、产品设计、设计师、工程师、测试、运维等角色。

另外,任何大于等于两个人的团队,成员间都需要互相沟通,人越多沟通成本越高,工作效率越低,所以任何情况下,都要通过招募尽可能优秀的人才,保持团队尽可能小的人员规模。Facebook宣布以10亿美元收购Instagram时,Instagram团队一共只有13个人,可称得上是最小完备团队的典范了。当然,更具传奇色彩的是唐僧的西天取经团队,以及“碟中谍”电影中EthanHunt的IMF团队。

复合型人才

如果团队成员过于强调各自的专业性,同样也会出现问题。我碰到很多技术人员曾经表示过:“我对业务不感兴趣”、“我不想浪费时间和产品人员沟通,他们什么都不懂”、“我只想成为后端工程师,前端开发很肤浅和无聊”等。产品人员通常也会有类似的表达:“我又不懂技术”。相反,如果技术人员能绘制产品原型,产品人员能熟练写写HTML、CSS、JS等前端的代码,那么他们的共同语言和沟通默契将提高一个数量级,工作效率随之大幅提升,甚至大家的心情、幸福指数也会很高。

因此,在招募员工时,要找那些既有良好专业背景又对其他相关领域充满好奇的人才。这样的人通常都比较跨界、思路开阔,甚至性格上也比较积极、阳光。这样的团队自我学习能力非常强,同时,能够主动发现所负责的业务或产品的各种问题,并主动制定解决方案,推进执行。

并行工作流程

对于一个由复合型人才组成的最小完备团队来说,他们的工作将是积极主动的,大家会整天凑在一起研究自己的产品有哪些问题、需要做出什么改进等。他们追随自己的内心和市场反馈,得到了很多灵感和想法,他们需要全速推动产品的进化。于是,他们决定开始开发一个新的版本,当然也要随时准备修复线上版本的各种问题。

幸运的是他们没有像上面提到的由不同专业背景的人士组成的项目组那样进行串行工作,而是采用了并行的工作流程。首先产品、设计、技术、测试等团队成员坐在一起,开始讨论要实现哪些“特性”,关于特性的描述没有任何高深的非人类语言,相反,都是用最朴实的语言来描述产品会发生哪些变化,任何正常人都能读懂这些“特性”,否则就是有人在故弄玄虚。在这个过程中,技术人员与产品人员之间的沟通是用户体验相关的,而不是各自专业相关的,这种沟通是非常自然的。

在确定“特性”之后,各自将并行展开自己专业领域的设计,比如:产品人员要进行UE的设计、技术人员要进行系统架构设计等;然后团队负责人(比如产品经理)将组织大家对这些专业相关的工作成果进行评审确认,以便进入后续的执行阶段。由于是大家共同制定了此次产品升级的目标,即之前讨论的特性范围,那么大家在评审时,将最大限度地降低非技术层面的讨价还价,更多地聚焦在这些设计是否是最优的。这样的讨论同样很激烈,但通常是让人愉悦的。

打造用户喜爱的产品

当整个团队长期对一个产品负责时,他们将产生归属感和荣誉感。在产品的进化过程中,每个版本的迭代也都是采用了上面的工作流程,那么大家的短期目标也是高度一致的。最终,不管是长期的产品目标、还是短期的项目目标,整个团队紧紧地聚焦在了“为用户打造他们喜爱的产品”上。专业、技能只是手段而不是目标,狭隘地专注或排斥都是可笑的,相反,技术人员、产品人员等紧紧地拥抱在了一起,自信又互信地为用户解决问题。这时我们可以期待团队迸发出创造力和执行力,美好的事情将会发生。再不改变世界就老了,赶快行动起来吧!


本文转载自:

共有 人打赏支持
yunlong-w
粉丝 1
博文 20
码字总数 1829
作品 0
成都
程序员
私信 提问
非程序员如何使用 Git——版本控制你的生活

在协同工作和版本控制方面,Git 绝对是一个优秀的工具,但其优点并不被大众所熟知。在过去的几年中,由于大众对于文字处理,电子表格(译者注:这里暗指Word和Excel,下同。)以及其他常用的...

oschina
2014/05/19
6.2K
36
12月6日云栖精选夜读 | 三张图读懂机器学习 :基本概念、五大流派与九种常见算法

机器学习正在进步,我们似乎正在不断接近我们心中的人工智能目标。语音识别、图像检测、机器翻译、风格迁移等技术已经在我们的实际生活中开始得到了应用,但机器学习的发展仍还在继续,甚至被...

yq传送门
2018/12/06
0
0
荐书|Python编程之美:最佳实践指南

被众多实践验证过的技巧、经验大全 Python安装、配置和使用的最佳实践手册 Python 是一个大世界,大到让你难以置信! 本书不是教你如何学习Python 语言的(我们引用了大量优秀资源供你学习)...

CSDN程序人生
2018/09/23
0
0
11月24日云栖精选夜读:如何打造千万级Feed流系统?阿里数据库技术解读

yq传送门 2017-11-24 15:53:05 浏览247 评论0 大数据 安全 云栖大会 数据库 人工智能 数据流 微服务 测试 scala 运营 流计算 摘要: 2017年的双十一又一次刷新了记录,交易创建峰值32.5万笔/...

姬子玉
2017/11/27
0
0
7月10日云栖精选夜读丨ApsaraCache开源之路,阿里云Redis团队LC3全球顶级开源峰会获CRUG"开源社区最具影响力奖"

近日由The Linux Foundation主办的全球开源盛会LinuxCon + ContainerCon + CloudOpen(LC3)中国在北京国家会议中心举行,阿里云Redis团队也受邀参与了本次盛会并分享了ApsaraCache开源之路,...

yq传送门
2018/07/10
0
0

没有更多内容

加载失败,请刷新页面

加载更多

告别2018

今天中午从喵喵家回来之后,倒头就睡到下午4点了。可能是之前透支的身体,在我放松下来后,开始觉得疲惫了,所以最近估计会进入嗜睡期。醒来之后,拿了包花生,开了瓶低糖菊花茶,听着网易云...

七木网络科技
13分钟前
0
0
MySql数据库分表分区实践

1. 背景 —— 公司物联网项目 海量设备通过物联网服务接入云端,设备每30s上报一次自身数据(以下称为动态数据)。 物联网服务将设备上报的数据转发给数据处理网关,由数据入库网关执行批量入...

吴伟祥
26分钟前
0
0
大表关联走hash优化

大表关联走hash? 案例: ---- 反正我执行过1个多小时,没有跑完 SELECT a.id AS order_id ,b.s_id AS bill_id, d.id AS sub_order_id, d.deal_oper_id FROM EM_ORDER PARTITION(EM_ORDER_20......

hnairdb
39分钟前
0
0
MySQL查询执行

当我们希望MySQL能够以更高的性能运行查询时,最好的办法就是弄清楚MySQL是如何优化和执行查询的。一旦理解了这一点,很多查询优化工作实际上就是遵循一些原则让优化器能够按照预想的合理方式...

问题终结者
今天
1
0
CDH5动静态资源池配置与回滚

关于动态 静态资源池的配置以前都有提过,可以从以下几篇了解: YARN动态资源池配置案例 https://yq.aliyun.com/ziliao/346856# Hadoop YARN配置参数剖析(4)—Fair Scheduler相关参数 Hadoop...

hblt-j
今天
3
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部