热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

产品经理懂技术=流氓会武术

最近七年,我都在做互联网产品,其中前五年分别在创业公司和上市公司里,做别人的产品;近两年在创业,做自己的产品。

最近七年,我都在做互联网产品,其中前五年分别在创业公司和上市公司里,做别人的产品;近两年在创业,做自己的产品。

我的体会是:产品经理需要懂技术,创业者尤其需要。但前提是你总觉得有股憋不住的想要做点儿什么的冲动,如果打算混安稳日子,特别是在大公司,你什么都不需要懂,反而要小心别"知道的太多了",傻人一生平安。

做产品这几年,和开发工程师打交道最多,和他们交流通常有两大忌:

一. 忌不懂技术

更准确的说,是不能缺乏设计、开发一个互联网产品基本的技术常识,比如至少要清楚一个网站从不存在到能被用户访问,需要哪些必须的环节;也要明白一个App从你的脑海走到用户的手机里,需要经历怎样的过程。

有常识,当然不一定就能做出好产品,但没常识,就很象在村里呆了半辈子的人乍到城市,一举一动即使小心翼翼,也没法儿不透着突兀和不和谐。

我接触过的业内人士里,有几个七十年代初的颇为典型,大概是互联网出现的时候,他们已经过了充满好奇和渴望未知的年龄,不愿意放低身段去学习新东西,喜欢只凭着想象和自己的生活经验就开喷,间或以若干近期热门关键词作为点缀,以示自己尚蹲在潮流尖端。

这样的人也许能忽悠某些领导,但一定不招工程师待见,他们可能什么都不说,但心里已经开始等着看笑话,交给他们的开发需求,自然也是能拖则拖、能蒙则蒙。

二. 忌懂技术

我遇到不少工程师喜欢说:"只要产品需求明确,技术上一切都能实现。"

这句话听起来相当豪迈,也让产品经理大为放心,觉得技术真是产品的坚强后盾。但其实传递了一个特别糟糕的信号。

当工程师这么说的时候,潜台词是:"你弄好你自己的事儿就行了,别来管我!"而且这种说法隐含着一个乐观但显然并不现实的假设:技术是无所不能的,他(掌握技术的人)也象灯神一样,可以实现你的任何愿望,只要你能明确的描述它。

我不知道阿拉丁说完愿望之后,假如胆敢继续追问灯神将具体采用何种技术方案来实现的话,会不会被塞到灯里,但我知道很多工程师在发现你关注技术层面过深的时候,都会有种领地被侵犯的感觉。

这就是工程师维护自己专业槽的本能,与行业中其它角色相比,工程师地位不是最高,待遇也不是最好,还经常加班加的要死要活的,唯一得天独厚的优势,就是专业槽比任何角色都深。关于产品、关于UI、甚至关于商业模式每个从业人员都能喷上几句,要是说到用户体验,那更是连业外人士都敢大喷特喷而没有任何心理负担:反正我就是用户嘛,越傻越光荣。而一旦涉及到代码,大多数人就直接晕菜了。想想那些UI设计师的苦逼段子,工作时没有喷子们指手划脚的干扰,真是上帝赋予工程师独有的恩赐。

所以当他们认为有外人正试图跨越这条槽时,自然会有所警惕,甚至体现出抵制和敌意。当一个产品经理发现工程师开始比较密集的使用术语或拼命把简单问题往复杂了说,你应该知道,他们在槽边开始向你射箭了。

从整个产品乃至公司的角度来说,各个专业角色之间的专业槽都是应该被填平的,产品经理不该对工程师玩挟天子以令诸侯,不要总假装自己是用户的三个代表,动不动就拿想象中的"用户需求"当"奉天承运"来用;工程师也不必总装灯神,假装无所不能很累的,工程师之间必有能力高下之分,其实有时候功能做不了或做不好,纯粹只是因为工程师能力所限。如果彼此坦诚一些,大可以提前有效沟通,尽可能避开那些投入产出比过低的部分,有不少工程师不愿意拿出来讨论的技术实现上的细节,都是值得产品经理参与进来的,在这些细节上如何取舍与抉择,会对产品的开发进度、性能甚至功能带来极大的影响,如果沟通到位,往往可以让开发工程师少做大量无用功。在我开始自己动手写代码之后,对这一点有了越来越深的体会。

下面就说说我为什么开始学写代码,算是回答问题的后半部分吧。

在我做互联网产品的前五年里,我对技术的了解仅维持在常识范畴,能够手写的代码只有html和css,连js都不会,更别提任何适用于Web开发的编程语言了。我一直认为自己无法完全亲手写一个哪怕是最简单的动态网站,是作为互联网产品人员,很大的缺陷和耻辱。

工程师们一般倒不这么觉得,和他们聊天的时候,有时顺嘴喷一些对技术架构或某些技术问题的看法,立刻遭到赞扬:"你很懂技术嘛!"这时马上打着哈哈说:"懂个p啊,我连hello world都不会写,完全是纸上谈兵。"于是嬉笑声中,一群人把手里的箭收起来了。

但我压根儿就TM不想只能纸上谈兵,2009年,我不顾当时三十二岁的高龄,悍然决定要学Ruby,买了书、装好环境开始看书,敲代码,坚持了几天,然后失败了,考虑到也许Ruby对我来说太难,又尝试了Python,结果还是失败了。消沉几天后不死心,又买了一本iPhone开发的书,还趁机决定买了台27寸的iMac,但悲剧是只翻了翻书,连Xcode都没敢下就直接放弃了,这书上什么都不讲的啊!上来就是大段大段的代码啊!而且obj-c的代码都巨长,完全看不懂。

后来我想,这件事有两个收获:一. 发现了自己智商的边界。二. 我有了一台iMac。

转眼又过了一年多,想要自己动手做一个iPhone上的App的感觉越来越强烈,快压抑不住了。于是在某一天,我好了伤疤忘了疼似的把那本几乎没有折痕的iPhone开发基础教程又翻出来,等待Xcode下载的过程中,暗下决心:看不懂我也把它背下来。

后来发现笨办法至少对我来说,还挺管用的:照着书敲代码,能正常运行的话,就合上书,再敲一遍。一般重复四五次就能记得很牢了。合着书,劈里啪啦熟练的敲着自己还不知道是什么意思的代码,加上Xcode的自动补全很给力,几分钟就可以折腾出一大屏花花绿绿的代码,而且还能在iPhone上运行,这时会产生一种已经会写iPhone App的错觉,很奇妙。

人的大脑也很奇妙,你如果已经背下来了,本来不理解的就会慢慢自动理解,就这样背了一段又一段代码之后,突然发现:我明白是怎么回事儿了。之后就开始给自己提出各种小的不能再小的功能需求,尝试用这些代码去实现,每实现一个,都欣喜若狂:我能显示按钮了!我能弹出对话框了!我能写滚动列表了!我能发一条推送信息了!??

这些事儿在熟练之后,也许就像喝口水一样平淡,但却能给初学者带来巨大的快乐,我一直觉得,能否始终保持如初学者般的热情、专注,决定了在做某件事时能走多远,能做多好。

由于书上所用的Xcode版本问题和我用的不同以及一些印刷错误,书上的代码不会总是百分之百能运行,有时会报错,只能上网用尽一切办法搜,搜索的过程中,就会慢慢看到一些专门的技术论坛、Blog,最终不可避免的会发现Stack Overflow这个神奇的网站,你遇到的大部分问题,都能在上面找到答案。

当实现书上的功能已经不能带来狂喜的时候,就会忍不住想把自己束缚了很久的各种idea放出来了,终于可以亲手去做它,而不是局限在画画原型图、写写需求说明最后还要虔诚的擦拭神灯,呼唤灯神们显灵这样隔靴搔痒的做产品。

开发的过程对我来说充满了乐趣,因为写代码的时候,世界变的简单而美好,某个做法对还是错,你不需要自己反复猜测,也不需要和任何人没完没了争辩,编译器就是神圣的裁判。你的每个操作都能得到及时、明确的反馈,而且拥有近乎奢侈的试错机会,从这个角度来看,编程的乐趣倒是有点儿象玩游戏。

当然也会遇到无数的问题,Stack Overflow、Github、Bitbucket、mailing list会慢慢成为你的朋友。

在能够独自写出一个iPhone App并把它放到App Store上之后,我又发现还需要再学一门语言,用来开发网站以及需要在App中调用的RESTful Web Service,于是不顾三十五岁的高龄,再一次悍然打起了Python的主意,有了学obj-c的经验,知道关键是要能狠得下心和静得下心来,看什么书,其实区别不是特别大,所以我就用了免费的Learn Python The Hard Way,用前面提到的方法,跟着做了一遍(前半部分比较简单,可以每天做上十几个exercise,后面速度可能会慢一点儿),了解了Python怎么写之后,马上开始看Django Book 2.0,只看到第九章,就等不及用同样的方法把Django Tutorial做了两遍,接着惊喜的发现已经可以写一个简单但完整的网站了。然后很快试着用Django写了一个特别小的针对某垂直领域的工具类网站,上线跑了一段时间,昨天晚上结束免费试用,开始收费,现在看到已有几个付费用户,我很欣慰。

至于技术需要懂到什么程度,我觉得要是花几个月学的东西就够用一辈子,这买卖也太划算了,尤其是在技术领域,一定会需要持续学习,但对于我来说,已经没有资格象十几二十岁的年轻人那样仅凭兴趣广泛的学,我目前对这件事的原则非常功利:马上要用到的,能显著提高效率或者公认是最佳实践的就学,否则就先不学,尽量不折腾、严格控制投入的时间和精力。

比如写好的代码放到Server上,虽然只要能跑就算是部署成功了,但公认的最佳实践是使用virtualenv隔离Python环境,这样可以减少以后很多的麻烦,那就值得多花时间去了解,去应用;使用Fabric配合Git进行自动化部署可以大大提高效率,那就也值得花时间去学怎么用。

我也知道可以用Memcached或Redis来做缓存,提高应用性能;或是用Rabbit Mq和Celery来做异步队列,可以改善同步执行耗时较久的任务给用户带来的不爽感;还有Node.js似乎比传统的Web开发语言更适合做RESTful API ?? 不过这些都不是目前最紧迫的问题,所以虽然我还不会而且确定会有用,但先不去学。

一没留神,喷了几千字,还是打住吧,看来中年男人的??滤闶敲痪攘恕 /p>

最后还是总结一下,就一句啊:

产品经理懂技术 = 流氓会武术。你要是觉得帮派够大,自己脑子又好用到可以当师爷,那不会武术也凑合;要不巧是个和我一样没什么团队精神,又老喜欢独来独往的流氓,还想只凭着脑子就能连点儿防身术都不练,恐怕很容易被人打成爬行动物。

比较严肃的总结是:产品经理懂技术,在没资源的时候可以用最低成本把事儿办了,有资源的时候可以把资源用的更有效率。


推荐阅读
  • 在尝试加载支持推送通知的iOS应用程序的Ad Hoc构建时,遇到了‘no valid aps-environment entitlement found for application’的错误提示。本文将探讨此错误的原因及多种可能的解决方案。 ... [详细]
  • 在iOS开发过程中,当开发团队使用多台Mac设备时,可能会遇到无法继续申请新证书的问题。本文介绍了如何通过导出.p12文件来解决这一问题,并确保团队成员能够在不同设备上共享同一个证书。 ... [详细]
  • 本文为初学者提供了一条清晰的学习路线,帮助他们逐步成长为优秀的Web开发人员。通过十个关键步骤,涵盖从基础到高级的各个方面,确保每位学习者都能找到适合自己的学习方向。 ... [详细]
  • SvpplyTable: 实现可扩展和可折叠的菜单动画
    SvpplyTable 是一个示例项目,旨在实现类似 Svpply 应用程序中的可扩展和可折叠的菜单动画效果。该项目托管在 GitHub 上,地址为 https://github.com/liuminqian/SvpplyTable。 ... [详细]
  • 本文详细介绍了 Java 网站开发的相关资源和步骤,包括常用网站、开发环境和框架选择。 ... [详细]
  • 本文介绍了如何处理在Xcode构建过程中出现的多个命令生成相同文件的问题,特别是当这些文件与Info.plist无关时。 ... [详细]
  • 探讨Redis的最佳应用场景
    本文将深入探讨Redis在不同场景下的最佳应用,包括其优势和适用范围。 ... [详细]
  • 利用REM实现移动端布局的高效适配技巧
    在移动设备上实现高效布局适配时,使用rem单位已成为一种流行且有效的技术。本文将分享过去一年中使用rem进行布局适配的经验和心得。rem作为一种相对单位,能够根据根元素的字体大小动态调整,从而确保不同屏幕尺寸下的布局一致性。通过合理设置根元素的字体大小,开发者可以轻松实现响应式设计,提高用户体验。此外,文章还将探讨一些常见的问题和解决方案,帮助开发者更好地掌握这一技术。 ... [详细]
  • 浏览器作为我们日常不可或缺的软件工具,其背后的运作机制却鲜为人知。本文将深入探讨浏览器内核及其版本的演变历程,帮助读者更好地理解这一关键技术组件,揭示其内部运作的奥秘。 ... [详细]
  • 技术日志:使用 Ruby 爬虫抓取拉勾网职位数据并生成词云分析报告
    技术日志:使用 Ruby 爬虫抓取拉勾网职位数据并生成词云分析报告 ... [详细]
  • iOS 设备唯一标识获取的高效解决方案与实践
    在iOS 7中,苹果公司再次禁止了对MAC地址的访问,使得开发者无法直接获取设备的物理地址。为了在开发过程中实现设备的唯一标识,苹果推荐使用Keychain服务来存储和管理唯一的标识符。此外,还可以结合其他技术手段,如UUID和广告标识符(IDFA),以确保设备的唯一性和安全性。这些方法不仅能够满足应用的需求,还能保护用户的隐私。 ... [详细]
  • 掌握PHP编程必备知识与技巧——全面教程在当今的PHP开发中,了解并运用最新的技术和最佳实践至关重要。本教程将详细介绍PHP编程的核心知识与实用技巧。首先,确保你正在使用PHP 5.3或更高版本,最好是最新版本,以充分利用其性能优化和新特性。此外,我们还将探讨代码结构、安全性和性能优化等方面的内容,帮助你成为一名更高效的PHP开发者。 ... [详细]
  • 本文提供了针对iOS设备在Xcode 8.0及以上版本中的调试指南,详细介绍了从环境配置到常见问题解决的全流程。内容涵盖设备连接、证书配置、日志查看及性能监控等多个方面,适用于2015年后的开发环境。通过本指南,开发者可以高效地进行应用调试,提升开发效率。 ... [详细]
  • 本文推荐了六款高效的Java Web应用开发工具,并详细介绍了它们的实用功能。其中,分布式敏捷开发系统架构“zheng”项目,基于Spring、Spring MVC和MyBatis技术栈,提供了完整的分布式敏捷开发解决方案,支持快速构建高性能的企业级应用。此外,该工具还集成了多种中间件和服务,进一步提升了开发效率和系统的可维护性。 ... [详细]
  • 当前,众多初创企业对全栈工程师的需求日益增长,但市场中却存在大量所谓的“伪全栈工程师”,尤其是那些仅掌握了Node.js技能的前端开发人员。本文旨在深入探讨全栈工程师在现代技术生态中的真实角色与价值,澄清对这一角色的误解,并强调真正的全栈工程师应具备全面的技术栈和综合解决问题的能力。 ... [详细]
author-avatar
苏格拉没有底YI_670
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有