【程序员电子刊精选】同一个团队,同一个目标
【程序员电子刊精选】同一个团队,同一个目标
yunlong-w 发表于3年前
【程序员电子刊精选】同一个团队,同一个目标
  • 发表于 3年前
  • 阅读 4
  • 收藏 0
  • 点赞 0
  • 评论 0

移动开发云端新模式探索实践 >>>   

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

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

最小完备团队

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

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

复合型人才

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

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

并行工作流程

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

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

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

打造用户喜爱的产品

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


  • 打赏
  • 点赞
  • 收藏
  • 分享
共有 人打赏支持
粉丝 1
博文 20
码字总数 1829
×
yunlong-w
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: