只显示主题贴

站在投资人的角度,项目进度也许是越快越好(这点我是假设的),但是各位做项目管理的同学,对于控制进度是如何考虑的? 先说说我自己的.在项目时间允许的情况下,一般我不考虑让项目提前完成,或者提前的太多.如果每个人员在全力工作的时候能够输出100%的功率,那么我更新希望能够让他们保持在60%-80%左右的每日输出功率. 以近可能的延长每个人的工作寿命. 当然这样的情况下,项目进度就会变得不快也不漫.能够一定完成,但是就是需要些时间. 不过可惜这样的项目一般不多,更多的都是比较紧张的.
论坛上常说的管理不够规范,管理混乱。就实际原因都是管理无经验,或者公司处于强烈的变动期。这些老板,管理人员都是摸索着在过日子,他们自己都不知道该怎么办,怎么求管理规范,做事流程规范? 当然学习和参考其他有经验的公司是有必要的。不过只能是参考。 且不说各家有各家的不同情况,关键是,引入一种制度,势必要打破一种制度。 而在看似混乱的管理下,公司的全体成员实际上已经摸索出一套团队合作的方式了,虽然没有用明文定下来,虽然不时的再小范围变动,但是每个人该做什么,该怎么做,都是有一定的规律可循的。 那么,引进新制度,打破旧有制度的代价,一般的老板和管理人员都是不敢轻易尝试 ...
大约从06年9月正式接触rails。买ror书,按书上画瓢。开始进行实验项目开发,再到正式项目开发,已经过去了大半年了。这个大半年的应用中,最大的感触还是,rails虽然很不错,但是依然有很多地方让你痛苦不堪。 不过这个也是大部分技术开始应用的时候经常遇到的,有些小细节上处理不好,整个项目就会被卡死。 我所遇到的rails的最大难题,第一是。中文处理,第二:数据库,第三:部署。 这些问题在前期开发中和试验项目中实在是难以遇到,但是正式项目中却能让项目失败的几个点。对于准备热心应用rails项目的各位同学,千万要当心这点。 做rails项目,要么就是严格按照rails最 ...
  • 进入论坛 Ruby
过去一年来,公司招聘了不少应届毕业生。经过一年的共事,除了失望还是失望,以后不再招聘应届毕业生。 为什么不在招聘?不是因为他们技术不行,不是因为他们沟通能力不行,也不是因为他们的品性和心性问题。 工作责任心的问题。就是这个说不清楚,道不明白,摸不着,看不到的但是又却是影响工作成败,完成度质量的关键性因素的缺乏,使得我 不在想招聘应届毕业生。 应届毕业生缺乏一种应有的工作责任心。这个是毕业生们的致命伤。 工作责任心是一种工作态度,一种思维方式,是一种和工作年龄成正比的个人因素。这个也是职业道德的一部分。公司里面很明显的,工作时间越久的同事越值得信任。对,有没有工作责任心会影响到同事对你的 ...
最早看到yield时,就用c/C++中的概念对比了一番,发现最接近就是“宏代码的展开”。粗看起来,这样的理解是可以的。不过马上就有个问题出来了,就是定义域。宏代码的展开,要求展开后的代码处于被展开的位置同一个定义域,否则,相关变量和函数就会出现没有定义的错误。 不过从下面的ruby代码来看,yield没有这样的问题存在 class A def self.test yield end end class B def test0 puts "call from class B" end def test1 A.test {test0} end end b = B.new ...
  • 进入论坛 Ruby
Ruby的Thread是伪线程,不管代码中写了多少个Thread.new,Ruby都只启动了一个线程去运行这些Thread的代码。 这样做的确使得Ruby的Thread很容易控制,程序也不容易产生类似死锁这类严重的线程问题。但是效率始终无法提高,因为在ruby进程中,实际上只有一个真实的线程在运行,同样的代码在那么多核或者多cpu的电脑上运行效率和单核cpu的电脑上的效率并不会相差多少。 于是有两个衍生问题: 第一,不太可能用ruby编写桌面程序。桌面程序大都是单进程,多线程模型。因为ruby用的是伪线程,Thread.new用的越多,运行效率只会越来越低。CPU ...
  • 进入论坛 Ruby
从2001年.net平台开始发布到现在,C++/CLI已经存在了好几年。以前叫mc++,现在改名为C++/CLI,有些人认为C++/CLI是一种新语言,有的只是认为是C++的一个扩展。C++/CLI是完全基于.NET平台之上。C++/CLI的出现给C++项目开发带来了不少的变化。可惜由于.NET平台目前还没有完全覆盖windows的全部操作系统,C++/CLI也只能用于服务器程序的开发。用来编写客户端程序,分发成本实在不低。 光从用途来看C++/CLI是.NET平台和iso c++之间的一个过渡桥梁,一个 ISO c++项目走向.net项目的一个单向桥梁。抛开各种政治上的,信仰上的 ...
用脚本语言编写的项目在代码修改,项目部署,运行配置的方便性,是编写应用程序的人眼红的地方。使用脚本语言,专业用户可以很方便的自己修改或者做些二次开发。 在想要利用编译语言的各种优点,又想方便配置甚至可以让专业用户自己修改逻辑或是二次开发的项目中。嵌入式脚本语言就派上了很大用处。在项目中加入嵌入式脚本语言,以牺牲部分运行性能来换得部分维护和分发便利性。从长期成本来说还是可以接受的。嵌入式脚本的存在也使得编译语言和脚本世界之间搭了桥梁,不至于大家老死不相往来。 嵌入式脚本语言最容易发挥力量的场所是允许(需要)专业用户自己更改部分业务逻辑的yy应用系统。比如嵌入式语言在游戏中就有很多应用 ...
下面的结论是对比我和arath的两个项目组得出的一个初步结论 开发语言的逻辑边界越明显,新手在用这种语言做项目时,越不容易失去控制。 最近我和arath都有个类似的项目,就是需要写一个比较高性能的服务器程序。为此我们讨论了很多次。arath的项目用C,我的项目用C++. 其中有一次,arath提到了项目中的基础设计有些被改乱了。排除了各种人为因素之外,C代码明显比C++代码更加容易随意编写,而不易检查。C并不存在某种物理或者逻辑上的设计边界,C++多了个class的概念。且抛开是否因为OO,明显的C++可以用class来做出最简单设计边界。 新手,模仿性强且极易把代码 ...
这里有不少帖子是讨论 某种项目方法怎么推行的? 比如 单元测试,TDD。 发起这样帖子的人,一定有个很大的疑惑,这么好的办法,为啥自己的头就是不采纳,还是用那种很不好的方法在做项目研发呢? 这的确是个迷啊! 不过,就我猜测,你们在游说的时候没有把关键字说出来。当然这个也是技术人员比较不容易注意地地方。技术人员关注这些方法是因为这些方法将能够改进自己的工作方法,提升自己技术水平。那么管理人员关注的是啥呢? 这个就是上面说的关键。“成本”,“收益”,“风险”这三个关键指标。 成本,收益,风险这三个经济指标是管理人员第一考虑的内容。就算是技术 ...
jack
搜索本博客
我的相册
最近加入圈子
存档
最新评论