艾伟也谈项目管理,产品不要被技术绑架的十大注意事项

  “不可能的;有难度的;你懂不懂技术的;这个功能要放在二期才能做;要做可以但需要时间;把那个项目停掉我就给你做……”,如果经常听到技术这样说,那你的产品很有可能已经被技术绑架了,接下来你想再多的功能,只要技术说不可以那就没戏。

  1、正确选人

  ——做网站的技术开发,必须是个技术牛人,要像科学怪人那样的人最好,为实现一个功能可以两天不睡觉的主。千万不要找一个所谓的高级架构师之类的高人,其实这种人连最简单的功能也不会开发了。

  2、严禁不可能

  ——如果一个程序员说“不可能的”,那他应该去屎。做技术的就是把不可能变成可能, 如果连技术都说不可能,那一定是登火星。技术团队内一定要树立把疑难杂症解决为荣的文化。

  3、打破帮派

  ——程序员的性格大多比较内向,有抱怨不太会表达,通常几个人比较容易形成帮派,最后通过手中的技术权利反过来控制网站,随便手抖一下就可以让网站挂几分钟。不要太不尊重程序员,也不要太尊重程序员。

  4、考核目标

  ——传统软件的程序员应该先考核稳定性再考核开发速度,互联网的程序员应该先考核开发速度再考核稳定性。道理很简单,互联网是抢时间的游戏,谁快谁就赢,而出现一些小故障可以在线修复,发布到网友感受只是五分钟之内的事。

  5、选择语言

  ——用PHP还是用JAVA还是用XXX,从技术上讲其实都各有所常,但是从战略层面,要从人力资源的角度去选,那种人好招就用那种。如果选了一门很新的语言,结果程序员很难招或者很贵,有意义吗?

  6、服务器

  ——这是网站的命根子,最好由独立的部门管理。和财务部门一样,很多部门可以用钱,但最终钱是财务部统一管理的。如果让程序员去管服务器,意味着程序员做不好无法换人,换人就有可能数据丢失。

  7、拖工期

  ——理清开发流程、做好计划是程序开发时间控制的最基本工作,但是也有可能被滥用。明明一个月可以完成的,程序员可以说出一百得理由,把项目拆成三期,时间拖到一年。等到了一年又可以说由于你修改了功能又要半年。

  8、高压高薪

  ——愿意做程序员的很少有富二代,他们是网站建设的工人,但不要想通过廉价的薪水控制成本,那怕他今天要的工资很低,技术一但成熟一定会有更高的薪水挖他。很多程序员晚上还接私活赚钱,他们知道这是吃青春饭。还不如给他们三个人的活两个人的薪水。

  9、QA测试

  ——传统软件是必须要用QA测试,因为软件打包后给用户,如果出现问题是很难升级回收的。互联网程序最大的好处就是网友人人都是QA测试,办公室绝对模拟不出上百万不同电脑的浏览效果。修一个BUG几秒钟就可以发布,修错了几秒种就能恢复。

  10、技术创新

  ——在中国现阶段几大语言都是老外发明的,技术上的创新无非是如果把程序写的更短,效果更高,更省服务器。如果一个程序员老是在想如何做出一个可以取代运营的人工智能程序,那一定是白日梦或者是大忽悠。如果有这种技术,美国人第一个挖你去FBI了。

时间: 2024-10-26 23:23:27

艾伟也谈项目管理,产品不要被技术绑架的十大注意事项的相关文章

产品不要被技术绑架的十大注意事项(转)

  "不可能的:有难度的:你懂不懂技术的:这个功能要放在二期才能做:要做可以但需要时间:把那个项目停掉我就给你做--",如果经常听到技术这样说,那你的产品很有可能已经被技术绑架了,接下来你想再多的功能,只要技术说不可以那就没戏. 1.正确选人 --做网站的技术开发,必须是个技术牛人,要像科学怪人那样的人最好,为实现一个功能可以两天不睡觉的主.千万不要找一个所谓的高级架构师之类的高人,其实这种人连最简单的功能也不会开发了. 2.严禁不可能 --如果一个程序员说"不可能的&quo

设计之处:产品不要被技术绑架

文章描述:产品不要被技术绑架的十大注意事项. 不可能的:有难度的:你懂不懂技术的:这个功能要放在二期才能做:要做可以但需要时间:把那个项目停掉我就给你做--如果经常听到技术这样说,那你的产品很有可能已经被技术绑架了,接下来你想再多的功能,只要技术说不可以那就没戏.   1.正确选人 --做网站的技术开发,必须是个技术牛人,要像科学怪人那样的人最好,为实现一个功能可以两天不睡觉的主.千万不要找一个所谓的高级架构师之类的高人,其实这种人连最简单的功能也不会开发了.   2.严禁不可能 --如果一个程

艾伟也谈项目管理,和谐共进的项目组——产品经理提高技术理解力123

最近被同事问到产品经理怎样提高技术理解力,有哪些途径,这里结合之前做过的两个项目以及和这个项目组所有开发兄弟一起并肩战斗的半年感触来说说. 1. 产品经理与项目经理的互动 项目过程中,产品经理和项目经理之间多沟通,产品经理准确传达产品设计的思路,项目经理结合产品实现,给出技术实现的方案,然后一起共同评估选出最优的解决方案,这个过程中产品经理可以学习到自己所做的产品的技术实现方法.在beta1项目中我们在手机QQ.QQ浏览器结合中采用了不同于其他平台的纵向整合方案,从而大大提高了项目的实现周期.

艾伟也谈项目管理,打造高效的技术团队,我会关注的7个点

1:使用分布式的版本管理系统 如果你觉得不需要使用版本管理系统,那我们沟通会有代沟,如果你是cvs.svn的粉丝,或者由于某种原因没有使用过分布式版本管理系统,比如git,那强烈建议你去看一下"why git is better than x". 2:一键式发布 这里发布的目标位置,既可以是开发机,做本地测试:也可以是测试机,为QA准备好捉虫游戏的森林:还可以是生产环境(或者beta环境),供用户直接访问. 如深度xp一键恢复系统一样,一键式发布需要自动完成很多工作:代码自动化测试(开

艾伟也谈项目管理,学习腾讯的产品管理之道

马化腾带着一大批产品高管自上而下,持之以恒地推动产品本位的管理体制规范化,并不断地创新和优化这套体制,使得整个公司上上下下融入了"产品的基因",最终成就了"产品的腾讯". 1.设置一个质量监控小组,由经验非常丰富的高Level的产品人员构成,赋予他们很大的权力,去监控和规范所有的产品项目.并且用KPI来制约产品项目服从这些规范.为了不搞教条主义,很多规范都是在立项之初,由项目经理和这个小组共同确认的,未必是硬性指派,一经确认就受到严格监控.确保好的规范不流于空喊口号

艾伟也谈项目管理,敏捷实施中的常见错误

一些评论员写下了敏捷实施中一些常见错误和反模式.他们贴出了"Top X"列表,列出了需要避免的事项和他们曾在各种组织实现敏捷时见过的错误. Target Process的Michael Dubakov写了两篇博文:"10个敏捷实施中最常见的错误"(Part 1; Part 2 ).他认为"许多公司在敏捷实施中再三犯同样的错误." 他的常见错误列表如下: 1. 从一个工具开始敏捷开发是不同的.一个工具不会立刻产生影响,不会由于这一工具的存在而解决多

艾伟也谈项目管理,DevOps,不是一个传说!

DevOps最近成了热词,望文生义,你也能猜个八九不离十,它就是在说"研发团队"与"运维团队"之间的那点事儿.那么,到底什么是"DevOps"呢? WikiPedia上说:"DevOps是软件开发.运维和质量保证三个部门之间的沟通.协作和集成所采用的流程.方法和体系的一个集合.它是人们为了及时生产软件产品或服务,以满足某个业务目标,对开发与运维之间相互依存关系的一种新的理解."这恰好体现了精益管理中的客户价值原则,即:以客户的

艾伟也谈项目管理,软件架构引言之项目管理的问题

软件架构引言之项目管理的问题   很多朋友都有过或者正在管理一个或者多个软件项目,那么我的文章就从这个问题开始:如果单纯从表象来说,软件项目管理过程中暴露的最大问题是什么?   不同的人的会有不同的答案,但是大致这样的答案我想大部分人都是会认可的,那就是"进度拖延".进度拖延当然是表象之一了,其他诸如质量不过关.功能不完整等等,我觉得都是和进度拖延密切相关的.很多项目经理都想去做那些认为是十分必要的事情,比如计划.测试等,但是"没有时间".为什么会没有时间?等到项目

艾伟也谈项目管理,项目经理的思维批判

想做好项目经理,就一定要改变你的思维方式.这对于技术出身的朋友尤其重要. 清末人们自以为天朝,他国皆为蛮夷.结果如何呢?丧师辱国,自己沦为病夫.其根本莫非自己脑筋不对头?后来又搞洋务运动,以为洋人只是工具好,其他都不如我们,师夷长技以制夷就可了.而事实却告诉我们,感情我们又错了. 做技术出身的项目经理,就仿佛清末的国人.技术第一的概念已经深入骨髓,说是做管理,其实还是把自己的技术看做天朝上国,管理当做蛮夷丑类,或者只是把管理当做一种工具来学习学习.这么做,果真能做好项目管理吗? 从技术走向管理是