艾伟也谈项目管理,切勿过早优化

  Donald Knuth说“过早优化是万恶之源”(premature optimization is the root of all evil)。这话也许有些夸张,但“过早优化”的危害我觉得不能忽视。同时,我觉得“过早优化”的概念不专属编写程序,生活中的示例也比比皆是。不信,你看看下面这些情形你是否遇到过:

  1、当你开始学一门程序语言的时候(比如c#),你想如果可以精通开发工具(比如Visual Studio)一定如虎添翼,于是一开始你就花很多时间去研究开发工具,而忘记自己学习的重点是语言本身,而非工具。或者,一开始,你花不少的时间去选择哪门程序语言,比较各种语言的优劣,在五花八门的语言前面犹豫不决,这个想学,那个也不想放弃,结果都是学个半路子。

  2、当你学习一门外语比如英语的时候,一开始,你花了很多的时间去下载有关英语资料,花了很多的时间去找英语书籍,以为有了这些资料和书籍就可以学好英文,而不是一开始就踏踏实实的从单词、语法开始,结果后来资料下载了一大堆,书籍买了不少,却没有坚持下去。

  3、你想搞体育锻炼,比如打羽毛球,于是一开始你花大量时间去买球衣、球鞋、球拍等装备,可没连几天,你发现自己开始三天打鱼了,最后,那些装备都起了灰,也没锻炼几次。

  4、你想做时间管理(Getting Things Done),于是你研究各种时间管理的资料,上各种时间管理技巧的网站,比如lifehack、 digg 、gtdlife,下载对最流行的GTD的管理软件,以节省时间的名义浪费时间,很浮躁,不能做到实实在在把每天的计划都落实,拖拖拉拉。

  5、你有没有这样的体验,一本书你总是对开头的部分看的最仔细,后面的章节没坚持看下去,下次又重复这种循环。当你计划做一件事的时候,总是规划的非常完美,几乎考虑每个细节,但却没有认认真真、一步一步执行,或者过早完美计划,反而让你缩手缩脚,犹豫不前,瞻前顾后,顾此失彼,最后虎头蛇尾。

  6、比如,如果我有了钱,我就如何如何享受快乐,比如,如果我将来有了很多的时间,我就会花更多的时间陪家人或锻炼…

  这样类似的例子还可以举很多。

  过早优化对大的问题在于:过早关注不重要的部分,而忽略行动和目标本身。以静态的思维来优化,殊不知,事务发展总是动态的,“优化”是需要长期的实践积累才可以获得。出发点是好的,但往往好心办坏事,折腾大量的时间,做了很多不该做的,而该做的、重要的反而没做。强化外部条件、工具等外在,而忽略内在因素和行动本身,或者,过多期望将来,而忽略当下眼前。

  活在当下,实实在在做好手头的事,是避免“过早优化”最好的方法之一

时间: 2024-09-20 06:19:18

艾伟也谈项目管理,切勿过早优化的相关文章

艾伟也谈项目管理,我的项目管理观点

    公司要我给项目经理做一个培训,关于项目经理的做事情的方法和观点方面.我就采用了Workshop的方式,Workshop不是会议模式,而是侧重于交流会谈的一种模式,毕竟大家都是项目经理,并非说我的做法就是对的,所有的一切都是自己的经验之谈,所以我只是说大家彼此分享经验,交流心得.我把我所要分析的内容大概做了一个讲义,也希望更多人能够参与到这个Workshop中.项目经理好做吗?      项目经理好做吗?好做!项目经理好做吗?不好做.不同的人.不同的态度.不同的方法,其结果也就存在有极大的

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

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

艾伟也谈项目管理,项目管理的十大挑战

公司项目中的项目管理挑战 1. 不明确的目标:当目标不明确时,开发团队是不可能达到客户要求的.而且,由于上级管理层不会同意也不会支持不明确的目标,该项目成功的几率微乎其微.因而,项目经理应当通过询问恰当的问题,从一开始就建立并传达清晰的目标. 2. 范围变更:也称作"范围蔓延",当项目管理层允许项目的范围延伸到原始目标以外时,就会发生这种现象.当然,客户和项目监管员会要求修改项目,但一个优秀的项目经理会评估每一个请求.决定是否及如何实施,并且与每个利益相关人交流决策对预算与期限的影响.

艾伟也谈项目管理,代码背后的点滴

有段时间没有更新技术blog了,现在有空每天都写写围脖,记录生活和工作的点滴,但是有时候发现有些技术的想法和工作总结没有像过去那么完整的写很大一篇,但是也有零零散散的不少点滴,因此想着随意的写这么一个连续的片段分享. 为什么叫做代码背后的点滴呢,其实在现在互联网应用来说,其实用什么语言,用什么平台有些场景有影响,但已经不是绝对重要的因素的,其实代码被后的设计思想才是最重要的.而用最熟悉的方式去表现最自然的想法,那才能做到游刃有余,就好比我向华黎同学申请这次内部奖励的奖品希望是手写笔,因为不论什么

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

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

艾伟也谈项目管理,给敏捷软件开发的26条建议

我经常收集各种各样的至理名言,最近我重温敏捷软件开发:真正的问题是什么?下面是一份26条关键原则的清单,以指引敏捷软件开发团队. 1.完整地干完一件事后在开始另一件事:用厨房比喻来说就是:"先上这道菜,再开始做下一道".软件开发的最大问题就是同时开始几件事情,这将不可避免的造成某些工作被废弃,从而造成浪费.专注于一件事:完整地实现其功能:运行测试:编写文档:签入所有,把这当做一项工作完成,然后再开始下一件事. 2.不要破坏构建:非常明显,但必须被包含在任何软件开发建议清单中.程序员在签

艾伟也谈项目管理,我是如何带领团队开发项目的

最近有不少朋友写信问我一些关于团队开发的问题,由于这段时间有些忙,没有回复.今天写一篇这方面的文章向大家介绍一下我是如何带领团队开发工作流项目的 关于团队建设,项目管理的文章网上已经有很多了,在这里我就不谈这些理论了,直接给大家展示一个我在 项目开发方,后台服务开发方式,前台UI开发方式,后台服务与前台UI对接方式,代码文档,页面的开发文档,源码管理,单元测试,以及单元测试文档,实现思路设计文档,数据库文档,数据库设计规范,编码规范,操做数据的方法命名规则 方面的一些片断,这是一个为期6个月的工

艾伟也谈项目管理,编程习惯

文/Alexey Radul 译/程显峰 原文地址:http://web.mit.edu/~axch/www/programming_habits.html 近年来,我对编程艺术有很多体会.过后,我发现有些体会是错的:有些体会我遗忘了但又重新感受到:而另外有些则是必然会发现的.我还完善了一套项目管理的好习惯,这些习惯包括我自己的,或者小组的,抑或是更大的,公司内部的.一方面,这些习惯对软件的成功开发是至关重要的(太小或者纯粹巧合的不算),另一方面,这些习惯也不是什么高深莫测的东西,较小的篇幅就可

艾伟也谈项目管理,产品版本改造中的项目管理

近段时间,一直在负责一个产品版本改造(C/S系统进行B/S改造)的研发项目管理,在任务紧.时间短.团队成员又没有相关技术(Silverlight)背景的恶劣情况下,我带领包含我在内只有6个人员(5个研发人员,1个产品经理,产品经理在系统版本改造中主要精力投入到辅助市场部进行产品推广去了)的超小型项目团队,终于在公司给定的时间范围内完成了整个产品的版本改造.这其中经历了需求变更.技术风险.人员变动等诸多问题,项目任然取得了成功,这种使用新技术的试验项目能够取得成功不得不说有几分侥幸,更多的还是团队