[技术讨论]“软件工程”中的“工程”如何理解

下面是在水木软工上的对话。有兴趣的可以看看，全文涉及工程与科学之间的差异，软件工程的工程本身的分析，项目经理的行为和强弱势项目经理的一些问题。

btw：里面有著名的钱五哥的回复，呵呵。

发信人: timshaw (去SofeEng(软件工程)小侃吧), 信区: SoftEng
标 题: [合集] “软件工程”中的“工程”大家是如何理解的？
发信站: 水木社区 (Wed Jan 20 12:50:05 2010), 站内

☆─────────────────────────────────────☆
ihomd (ihomd) 于 (Thu Jan 14 18:05:31 2010) 提到:

别笑我弱大家讨论讨论，呵呵

我老听说“要以工程的方法来开发软件..."等等类似忠告。可以我怎么也不能领会工程的真
正意义。
我能想到的就是"more pratical"和理性。因为在我的理解中传统的工程(就是类似于建小区
)的产物都是实证的都必须是可行的都必须是经得起考验的。与之相对的就是夸夸其谈的艺
术的创意的只需要设计不重实现的，这些方向要的是纵横捭阖天马行空。
两项相较：一边是海水一边是火焰，一边是理性与冷静，一边则是感性与激情。一边是控制
一边是纵情。

而我们研发软件，同建房子一样，不仅要设计，更要能实现。最终的工件必须是经过客户用
户检验的，这个检验也是有标准的，不存在公说公有理婆说婆有理的情况。

软件工程的提法反映了当时软件开发屡遭失控打击的形势下，永不停止学习的软件人向传统
行业借鉴经验的决心。自此之后，估算技术测量技术地位急剧高升?

各位是怎么理解这个软件工程中的“工程”的？有没有人讲讲来龙去脉，freestyle。^_^

但是软件工程中有方法论过程论，这算不算传统工程理论的一部分？




☆─────────────────────────────────────☆
qingrun (青润) 于 (Thu Jan 14 21:10:42 2010) 提到:

不弱。能深入思考工程两个字的含义是很有必要的。
不思考工程两个字就来做软件开发的人，容易形而上学，更容易僵化的处理新的概念和新的方法论，借用老毛同志的话就是，容易本本主义。呵呵
不过，你这个话题太大，bbs上做这样的讨论，需要大量的文字输入，得不偿失，呵呵。
辩论或者讨论的时候，思辨过程和响应回路过长，价值不大，这样的问题应该考虑别的讨论形式会比较好一些。

【 在 ihomd (ihomd) 的大作中提到: 】
: 别笑我弱大家讨论讨论，呵呵
: 我老听说“要以工程的方法来开发软件..."等等类似忠告。可以我怎么也不能领会工程的真
: 正意义。
: ...................



☆─────────────────────────────────────☆
blueslc (Thomas) 于 (Thu Jan 14 23:04:41 2010) 提到:

Engineering is a cooperative game of invention and communication.
from <Agile software development - the cooperative game>
这本书有一章讲工程和软件工程，说的很好，我试着重复一下看看了。
过程中有创新的才是工程，没有的话就是生产而已，在传统领域，很多工程其实只是生产而已，没有什么难度。比如造房子，造第一座房子是工程，如果造同样的第二座，那就是生产。造第一座的难度，肯定比第二座要大很多
软件由于其独特性，每一个软件都不一样，所以软件工程，要和你造第一房子作对比，而不是第二座。
【 在 ihomd (ihomd) 的大作中提到: 】
: 别笑我弱大家讨论讨论，呵呵
: 我老听说“要以工程的方法来开发软件..."等等类似忠告。可以我怎么也不能领会工程的真
: 正意义。
: ...................



☆─────────────────────────────────────☆
qingrun (青润) 于 (Thu Jan 14 23:23:36 2010) 提到:

这个对比似乎应该是科学研究与工程对比，科学研究是造第一座房子，然后工程才是重复后面的房子过程，呵呵。
我个人认为，这本书里面讲的这个工程的解释应该是完全错误的。它混淆了科研与工程之间的差异。

【 在 blueslc (Thomas) 的大作中提到: 】
: Engineering is a cooperative game of invention and communication.
: from <Agile software development - the cooperative game>
: 这本书有一章讲工程和软件工程，说的很好，我试着重复一下看看了。
: 过程中有创新的才是工程，没有的话就是生产而已，在传统领域，很多工程其实只是生产而已，没有什么难度。比如造房子，造第一座房子是工程，如果造同样的第二座，那就是生产。造第一座的难度，肯定比第二座要大很多
: 软件由于其独特性，每一个软件都不一样，所以软件工程，要和你造第一房子作对比，而不是第二座。


☆─────────────────────────────────────☆
qingrun (青润) 于 (Thu Jan 14 23:27:44 2010) 提到:

评论一下这句话：但是软件工程中有方法论过程论，这算不算传统工程理论的一部分？
我记得我的blog上有一片关于软件工程重新定义的文字上（我对软件工程领域划分的认识之一，地址：http://blog.csdn.net/qingrun/archive/2006/12/21/1451598.aspx ），和一个在河南某大学的老师产生了争论，通过评论和评论回复的方式争论了几乎一整天，其实说的就是一两个小时就可以说完的东西。
对这个话题以及这个话题中各方面包含的内容做了比较深入的讨论。

【 在 ihomd (ihomd) 的大作中提到: 】
: 别笑我弱大家讨论讨论，呵呵
: 我老听说“要以工程的方法来开发软件..."等等类似忠告。可以我怎么也不能领会工程的真
: 正意义。
: ...................



☆─────────────────────────────────────☆
qlw (钱五哥) 于 (Thu Jan 14 23:43:55 2010) 提到:


工程和技巧相对应。工程的基础是可以测量，曾经复印过一张施工队的进度和报价
上面将投入、工时、成本算的清清楚楚。这和动辄可能延期的软件开发有天壤之别

但是软件工程也是很困难的，测量到现在似乎也没有什么人提出来与时俱进的方法
工程化最终导致了文档化和僵化。因此出现了敏捷过程 - 出发点是简化传统的工程
思路，从而回归到产品化的正确道路上。但是在解决规模扩大的问题方面还是有
些问题。早一些的CASE、组件化、软件工厂等概念，虽然盛极而衰，但是留下了
包括pattern、UML在内的遗产，对工程化有不小的帮助。

工程化首先要求可以重用，如果至今一直用主机+Cobol+DB2，则我坚信现在已经
工程化好久了，可惜目前是Linux+虚拟化+云计算的时代，原先搞的那套玩意早就
过时了，工程化还受到技术成熟性的制约！

可以看看Gartner的Hyper Cycle，现在M2M已经开始预热了。看到这类玩意，不禁
心说，“工程化又远了”

供讨论

【 在 timshaw (写啥呢？真矛盾) 的大作中提到: 】
: 多谢qingrun评价,我是哑巴,说不出子丑寅卯
: 呼唤canper,kabbesy,mike,SPQR,dicken等老版友
: 呼唤钱五哥
: ...................



☆─────────────────────────────────────☆
timshaw (写啥呢？真矛盾) 于 (Thu Jan 14 23:58:08 2010) 提到:


我再讲些感想。

软件工程是如此的复杂，风险是如此的高，搞到65%的软件项目延期，30%的项目直接取消。
跟传统工程的按时交付率差别如此之大。
原因有二：
第一是软字，软的就像女人的奶子客户都想捏成自己想要的形状。很多客户都不知道达到随便捏的程度需要吃多少木瓜，这种客户和软件提供商的沟通有点巴别塔。
其 二在原软件工程固有的复杂性。传统工程正如我开始所说，设计和实现相分离，劳斯莱斯的design和implementation是完全个裂开的。而软件 项目中design和implementtation是如此的不可分家，每一个实现者都在自己的范围内进行design。

和传统工程比 较，软件工程的轨迹必然是守破离。大乱时代，我们需要一个框架，是以学习传统工程，但由于上面两点，慢慢的，软件工程变异出自己的特性，我认为这里可以分 为三个层次：过程论/方法论/最佳实践和反模式，这些都是那些重视测量估算的传统工程所没有的。慢慢的最终发展出自己的一套理论，和传统软件工程完全不同 的理论。在这里，测量不是最重要的，最重要的是革新，是重构，是抽象，是沟通是融合而不是分而治之不是人为构筑壁垒。



【 在 qlw (钱五哥) 的大作中提到: 】
: 工程和技巧相对应。工程的基础是可以测量，曾经复印过一张施工队的进度和报价
: 上面将投入、工时、成本算的清清楚楚。这和动辄可能延期的软件开发有天壤之别
: 但是软件工程也是很困难的，测量到现在似乎也没有什么人提出来与时俱进的方法
: ...................



☆─────────────────────────────────────☆
timshaw (写啥呢？真矛盾) 于 (Fri Jan 15 00:21:24 2010) 提到:

那肯定啊，但是主要指导思想还是IOC和分而治之。
说起这个就想起而二战的通用，短时间内就是用IOC理念造就了如此多的飞机。。。。

【 在 canper (洗衣粉) 的大作中提到: 】
: 车盲，不了解，不过我想造车设计师也不是画完图纸就完事的吧，也要参与样品车的组装，调试。




☆─────────────────────────────────────☆
canper (洗衣粉) 于 (Fri Jan 15 00:26:47 2010) 提到:


我觉得软件中设计和编码分开也是完全可以的，但并不表示这样就可以降低编码人员的水平，以及设计者可以不参与到编码阶段中。

我想配合设计师一起组织样品车的技术的工资也不是和普通工人一个档次的。

【 在 timshaw (写啥呢？真矛盾) 的大作中提到: 】
: 那肯定啊，但是主要指导思想还是IOC和分而治之。
: 说起这个就想起而二战的通用，短时间内就是用IOC理念造就了如此多的飞机。。。。




☆─────────────────────────────────────☆
timshaw (写啥呢？真矛盾) 于 (Fri Jan 15 00:31:14 2010) 提到:

我觉得软件行业革新的动力就是融合互相学习无法剥夺的学习，而传统行业是分而治之，缺乏对流缺乏沟通。软件行业如果没融合没沟通，基本上就夕阳了。
我们之所以如此热爱这个行业，就在于我们喜欢沟通交流喜欢持续改进而不是得过且过。

【 在 canper (洗衣粉) 的大作中提到: 】
: 我觉得软件中设计和编码分开也是完全可以的，但并不表示这样就可以降低编码人员的水平，以及设计者可以不参与到编码阶段中。
: 我想配合设计师一起组织样品车的技术的工资也不是和普通工人一个档次的。




☆─────────────────────────────────────☆
canper (洗衣粉) 于 (Fri Jan 15 00:32:05 2010) 提到:


不过同样的事情如果放到建筑业就不是那么回事了，设计师画完图纸就完了，没有必要建一栋房子来验证自己的设计。

如果是服装业呢，好像也要做出样品来看看效果。


【 在 canper (洗衣粉) 的大作中提到: 】
: 我觉得软件中设计和编码分开也是完全可以的，但并不表示这样就可以降低编码人员的水平，以及设计者可以不参与到编码阶段中。
: 我想配合设计师一起组织样品车的技术的工资也不是和普通工人一个档次的。




☆─────────────────────────────────────☆
canper (洗衣粉) 于 (Fri Jan 15 00:33:10 2010) 提到:


这个，我还真说不上热爱
【 在 timshaw (写啥呢？真矛盾) 的大作中提到: 】
: 我觉得软件行业革新的动力就是融合互相学习无法剥夺的学习，而传统行业是分而治之，缺乏对流缺乏沟通。软件行业如果没融合没沟通，基本上就夕阳了。
: 我们之所以如此热爱这个行业，就在于我们喜欢沟通交流喜欢持续改进而不是得过且过。




☆─────────────────────────────────────☆
canper (洗衣粉) 于 (Fri Jan 15 00:35:22 2010) 提到:


在考虑一个问题，一个好的汽车工程师不需要拥有技师的技能。
一个好的服装设计师不一定是个好裁缝。


但是一个好的软件设计师不是一个好的编程人员就不靠谱了

【 在 canper (洗衣粉) 的大作中提到: 】
: 不过同样的事情如果放到建筑业就不是那么回事了，设计师画完图纸就完了，没有必要建一栋房子来验证自己的设计。
: 如果是服装业呢，好像也要做出样品来看看效果。




☆─────────────────────────────────────☆
timshaw (写啥呢？真矛盾) 于 (Fri Jan 15 00:36:00 2010) 提到:

这就是软件业的design和implementation不可分离的特点啊。

【 在 canper (洗衣粉) 的大作中提到: 】
: 在考虑一个问题，一个好的汽车工程师不需要拥有技师的技能。
: 一个好的服装设计师不一定是个好裁缝。
: 但是一个好的软件设计师不是一个好的编程人员就不靠谱了
: ...................



☆─────────────────────────────────────☆
canper (洗衣粉) 于 (Fri Jan 15 00:38:02 2010) 提到:


但是一个好的软件工程师不需要是一个好美工，哈哈
【 在 timshaw (写啥呢？真矛盾) 的大作中提到: 】
: 这就是软件业的design和implementation不可分离的特点啊。




☆─────────────────────────────────────☆
timshaw (写啥呢？真矛盾) 于 (Fri Jan 15 00:39:49 2010) 提到:

这里的design不是指UI design,而是指 architecture啊。
【 在 canper (洗衣粉) 的大作中提到: 】
: 但是一个好的软件工程师不需要是一个好美工，哈哈




☆─────────────────────────────────────☆
qingrun (青润) 于 (Fri Jan 15 14:25:48 2010) 提到:

这 样的实验我做过，02年8月，南京地税金力四期项目上，我从上海带了5个人过去参加tp当年的团队，后面给了我两个星期做一个模块实用性原型，成都那边给 了我一个美工，我这边自己做模型开发，设计完成后，分给了一个做页面，一个做数据库，我做业务控制层，一个人做银行接口的扣款，一共8天不到全部搞定，一 次性通过测试。
做界面和数据库开发的人完全是在我给定的模型导出的代码上进行的，我们做了一次设计变更，形成了一个独立的直接对象数据的写入类。
所以，我一直定义的编码人员就是印度的那种编码层次就足够了。
不是说设计人员完全脱离编码，而是对于一些创造性和创新性或者说有一定难度的编码是需要设计人员写好的，类似于过去传统软件工程中提出的微代码的开发阶段所完成的内容。
这样，就可以完整地实现代码设计的分离。实现我们的对印外包。

【 在 canper (洗衣粉) 的大作中提到: 】
: 我觉得软件中设计和编码分开也是完全可以的，但并不表示这样就可以降低编码人员的水平，以及设计者可以不参与到编码阶段中。
: 我想配合设计师一起组织样品车的技术的工资也不是和普通工人一个档次的。



☆─────────────────────────────────────☆
qingrun (青润) 于 (Fri Jan 15 14:28:53 2010) 提到:

一个好的汽车工程师也需要好的技师的配合，在做一些设计的时候，需要他们才实现设计，然后进行验证，获得验证结果后，对设计进行调整和优化——我的本专业材料学就是干这个的，现在大多数同学都在汽车行业，嘿嘿。

【 在 canper (洗衣粉) 的大作中提到: 】
: 在考虑一个问题，一个好的汽车工程师不需要拥有技师的技能。
: 一个好的服装设计师不一定是个好裁缝。
: 但是一个好的软件设计师不是一个好的编程人员就不靠谱了



☆─────────────────────────────────────☆
blueslc (Thomas) 于 (Fri Jan 15 17:44:54 2010) 提到:

但对于软件开发，对开发者来说，我们经常都是在造第一座房子，有时候还是在原来房子的基础上加层，更加困难
【 在 qingrun (青润) 的大作中提到: 】
: 这个对比似乎应该是科学研究与工程对比，科学研究是造第一座房子，然后工程才是重复后面的房子过程，呵呵。
: 我个人认为，这本书里面讲的这个工程的解释应该是完全错误的。它混淆了科研与工程之间的差异。



☆─────────────────────────────────────☆
qingrun (青润) 于 (Fri Jan 15 18:10:17 2010) 提到:

不管我们做什么软件，这个软件大部分都是此前已经有人做过的，或者有过类似的，或者至少是在原理上已经被证明过的，如果非要强调，应该说，科学是对原理的验证，而工程是对原理的实现。
难度有可能实现比推理过程更难，所以，在科学领域的很多学科上都有大量至今还无法验证的假设，这是客观存在的，假设往往需要很多条件满足后才可能被验证，所以，那本书上说的工程的所谓概念是完全错误的！！！

【 在 blueslc (Thomas) 的大作中提到: 】
: 但对于软件开发，对开发者来说，我们经常都是在造第一座房子，有时候还是在原来房子的基础上加层，更加困难



☆─────────────────────────────────────☆
ilovecpp (cpp) 于 (Fri Jan 15 23:48:23 2010) 提到:

【 在 timshaw (写啥呢？真矛盾) 的大作中提到: 】
: 我再讲些感想。
: 软件工程是如此的复杂，风险是如此的高，搞到65%的软件项目延期，30%的项目
: 直接取消。
: 跟传统工程的按时交付率差别如此之大。

传统工程真有这么牛？

787的延期，Larabee的延期，业界巨头数十亿美元轻易打水漂。

一部美国军机发展史，就看见三个词：延期，超出预算，项目取消。

软件工程喜欢拿盖房子作比。盖房子真是这个时代最接近软件工程的传统工程？

我父母是电子工程师。我的直观印象是，电子产品的开发决不像盖房子，倒是和
软件开发的过程颇多相似之处。

和传统工程比，我们做得真的更差吗？

诸多疑问，难以厘清。



☆─────────────────────────────────────☆
qingrun (青润) 于 (Sat Jan 16 11:23:17 2010) 提到:

对 于国内来说，我们和国外的差距主要在管理意识上，而不是技术层面；由于管理意识的差异，引起的投资方对软件系统的渴望和要求有了非常大的变化，国内的传媒 方面对国外软件项目的报道，也包括国外对自己的软件工程实施的报道也都大多集中于成功的例子，加上随着大家对科技进步的奢望，总认为软件应该能做到什么什 么样子，应该能解决什么什么问题，却忽视了软件本身最需要解决的根本问题：数据积累。
国外的软件行业走过了超过我们三倍以上的时间，他们积累的数据基础远远不是我们目前能够比拟的。
对 美国来说，因为几次世界大战都没有到他的本土，他的企业和经济的延续性在全世界范围内都可以算是最好的，其数据的保持也是最好的，而我国，大部分企业都是 80年以后重建的，更多的数据在二战，中全面毁灭，没有剩下什么，我们所能研究到的数据积累能超过10年的都不多，而且大部分是未信息化处理的原始数 据，但是同时，国内的宣传为了获得眼球的注意力，更多的关注在国外已成功地项目和目前的技术积累和产品状态下，所以，附带而来，传统行业在信息化的时候对 我们的期望就处于一个相对过高的水平线上，于是就带来了意识与技术现实的直接冲突，加上可投入研发资金和积累的时间问题，于是这个矛盾就更为剧烈了。
所以，不是我们做得不够努力，而是环境太过于苛刻了。
虽说解决这些问题不是不可能但是，需要多方面的配合和引导，涉足点太多，就超出了这个话题了。呵呵
【 在 ilovecpp (cpp) 的大作中提到: 】
: 传统工程真有这么牛？
: 787的延期，Larabee的延期，业界巨头数十亿美元轻易打水漂。
: 一部美国军机发展史，就看见三个词：延期，超出预算，项目取消。
: 软件工程喜欢拿盖房子作比。盖房子真是这个时代最接近软件工程的传统工程？

: 我父母是电子工程师。我的直观印象是，电子产品的开发决不像盖房子，倒是和
软件开发的过程颇多相似之处。

: 和传统工程比，我们做得真的更差吗？

: 诸多疑问，难以厘清。


☆─────────────────────────────────────☆
blueslc (Thomas) 于 (Sat Jan 16 11:40:07 2010) 提到:

那软件的开发算是科学？还是算是社会学？很多事情都没有这么绝对的。
【 在 qingrun (青润) 的大作中提到: 】
: 不管我们做什么软件，这个软件大部分都是此前已经有人做过的，或者有过类似的，或者至少是在原理上已经被证明过的，如果非要强调，应该说，科学是对原理的验证，而工程是对原理的实现。
: 难度有可能实现比推理过程更难，所以，在科学领域的很多学科上都有大量至今还无法验证的假设，这是客观存在的，假设往往需要很多条件满足后才可能被验证，所以，那本书上说的工程的所谓概念是完全错误的！！！



☆─────────────────────────────────────☆
canper (洗衣粉) 于 (Sat Jan 16 11:47:17 2010) 提到:


这篇说的好，呼唤版主m之
【 在 qingrun (青润) 的大作中提到: 】
: 对于国内来说，我们和国外的差距主要在管理意识上，而不是技术层面；由于管理意识的差异，引起的投资方对软件系统的渴望和要求有了非常大的变化，国内的传媒方面对国外软件项目的报道，也包括国外对自己的软件工程实施的报道也都大多集中于成功的例子，加上随着大家对科
: 国外的软件行业走过了超过我们三倍以上的时间，他们积累的数据基础远远不是我们目前能够比拟的。
: 对美国来说，因为几次世界大战都没有到他的本土，他的企业和经济的延续性在全世界范围内都可以算是最好的，其数据的保持也是最好的，而我国，大部分企业都 是80年以后重建的，更多的数据在二战，中全面毁灭，没有剩下什么，我们所能研究到的数据积累能超过10年的都不
: ...................



☆─────────────────────────────────────☆
qingrun (青润) 于 (Sat Jan 16 11:56:03 2010) 提到:

软件开发是工程学的内容，绝对不是科学领域直接关联的内容，当然，一切都是在科学理论的指导或者指引下完成的，这个事情，可以说是绝对的。
科学的概念和范畴是可以明确地东西。这个问题也是可以明确地，呵呵。

【 在 blueslc (Thomas) 的大作中提到: 】
: 那软件的开发算是科学？还是算是社会学？很多事情都没有这么绝对的。



☆─────────────────────────────────────☆
canper (洗衣粉) 于 (Sat Jan 16 12:02:23 2010) 提到:


后面两项我都不喜欢，每次同事去的时候我就躺一边睡觉，让他们很郁闷
【 在 timshaw (写啥呢？真矛盾) 的大作中提到: 】
: 在深圳啊，来的话请吃肠粉...^_^，晚上可以去吃糕点。no洗脚no按摩




☆─────────────────────────────────────☆
canper (洗衣粉) 于 (Sat Jan 16 12:09:13 2010) 提到:


我就一个写代码兼做工程的，整天和客户打交道
【 在 timshaw (写啥呢？真矛盾) 的大作中提到: 】
: 莫非你是技术顾问/总监，老被销售经理拉着压阵�




☆─────────────────────────────────────☆
timshaw (写啥呢？真矛盾) 于 (Sat Jan 16 12:20:57 2010) 提到:

说起这个来，确实在管理意识上有些不匹配，举个很弱的例子
我以前有个非it的老大，买了个2w的asp源代码，后来几个项目非要我用这个asp源代码，一个项目下来用“不要改”阻击了我起码快20次提议。
他很难理解有现成的东西为啥不用，仿佛另起炉灶或者升级给就算是把他那小2w给浪费了会给他造成很多成本费用似的。虽然我解释过很多次。
搞软件有时候对成本对质量的贡献，管理人员在管理层面上过程成层面上的运作不见得比技术人员关键。
此时，我想起一本书（应该是《软件工程的事实与谬误》）前言中提到作者说过的一句话，大意是说他喜欢搞技术，很享受这种技术人的意见压倒管理者命令的状况。当时我觉得很好笑，我心想在中国你有立锥之地吗？


【 在 qingrun (青润) 的大作中提到: 】
: 对于国内来说，我们和国外的差距主要在管理意识上，而不是技术层面；由于管理意识的差异，引起的投资方对软件系统的渴望和要求有了非常大的变化，国内的传媒方面对国外软件项目的报道，也包括国外对自己的软件工程实施的报道也都大多集中于成功的例子，加上随着大家对科
: 国外的软件行业走过了超过我们三倍以上的时间，他们积累的数据基础远远不是我们目前能够比拟的。
: 对美国来说，因为几次世界大战都没有到他的本土，他的企业和经济的延续性在全世界范围内都可以算是最好的，其数据的保持也是最好的，而我国，大部分企业都 是80年以后重建的，更多的数据在二战，中全面毁灭，没有剩下什么，我们所能研究到的数据积累能超过10年的都不
: ...................



☆─────────────────────────────────────☆
timshaw (写啥呢？真矛盾) 于 (Sat Jan 16 12:22:05 2010) 提到:

昨晚上看到一本用友人写的书，说很多技术顾问不愿意跟着销售出去吃喝玩乐，而销售经理又不好意思不叫，怕得罪啊。..
【 在 canper (洗衣粉) 的大作中提到: 】
: 我就一个写代码兼做工程的，整天和客户打交道




☆─────────────────────────────────────☆
qingrun (青润) 于 (Sat Jan 16 12:25:42 2010) 提到:

我去年年初就拍死了一个合作公司的市场，对技术人员太不尊重了，后来他们还过来找了我一次，希望我继续提供咨询和培训，我没理他，就没有再找我了。

【 在 timshaw (写啥呢？真矛盾) 的大作中提到: 】
: 昨晚上看到一本用友人写的书，说很多技术顾问不愿意跟着销售出去吃喝玩乐，而销售经理又不好意思不叫，怕得罪啊。..



☆─────────────────────────────────────☆
qingrun (青润) 于 (Sat Jan 16 12:26:50 2010) 提到:

所以，在中国，有技术基础，又能谦虚做事的项目管理人员才可能把项目做的很好，单纯的强势或者弱势项目经理都是不好当的。呵呵。

【 在 timshaw (写啥呢？真矛盾) 的大作中提到: 】
: 说起这个来，确实在管理意识上有些不匹配，举个很弱的例子
: 我以前有个非it的老大，买了个2w的asp源代码，后来几个项目非要我用这个asp源代码，一个项目下来用“不要改”阻击了我起码快20次提议。
: 他很难理解有现成的东西为啥不用，仿佛另起炉灶或者升级给就算是把他那小2w给浪费了会给他造成很多成本费用似的。虽然我解释过很多次。
: ...................



☆─────────────────────────────────────☆
keygen (贫贱夫妻百事哀) 于 (Sat Jan 16 12:29:09 2010) 提到:

技术牛的项目管理人员强势点，大家倒是很愿意接受的。哈哈
【 在 qingrun (青润) 的大作中提到: 】
: 所以，在中国，有技术基础，又能谦虚做事的项目管理人员才可能把项目做的很好，单纯的强势或者弱势项目经理都是不好当的。呵呵。




☆─────────────────────────────────────☆
qingrun (青润) 于 (Sat Jan 16 12:34:02 2010) 提到:

那样会有一个问题出现，而且这个问题根本无法解决，那就是：
如果团队内有一个差不多一样牛的技术人员存在的话。

我曾经在自动化所跟随过一个技术很牛的研究员，离开后，写了一系列好像是五篇相关文字在我的blog上，就是谈如何和一个纯技术的老板合作的话题。
和他的合作就存在一个很严重的问题，那就是：他情商太低，低到了公认的负值——有人说这还不够。
一个例子08年底到09年中期，他发生了两次学生集体叛逃的事件，第一次18个学生9个集体提出换导师，其中有两个博士，是我在的时候的弟兄，人很老实，都已经博士第三或者第四年了，你想想，能把人家压迫成什么样子才能逼人家做出这样的选择。呵呵。
技术上大家都服气，都认为他很牛，我出来后，提到他也都说，他技术上的确很牛，别的，大都一带而过，偶尔用类似上面的事件作证明来说明一些，呵呵。
【 在 keygen (贫贱夫妻百事哀) 的大作中提到: 】
: 技术牛的项目管理人员强势点，大家倒是很愿意接受的。哈哈



☆─────────────────────────────────────☆
timshaw (写啥呢？真矛盾) 于 (Sat Jan 16 12:50:26 2010) 提到:

你这么一说我还真是眼界太窄了。。光盯着那些盖房子的了
下次再打听打听别的行业
【 在 ilovecpp (cpp) 的大作中提到: 】
: 传统工程真有这么牛？
: 787的延期，Larabee的延期，业界巨头数十亿美元轻易打水漂。
: 一部美国军机发展史，就看见三个词：延期，超出预算，项目取消。
: ...................



☆─────────────────────────────────────☆
canper (洗衣粉) 于 (Sat Jan 16 13:35:40 2010) 提到:


其实每时每刻这种事情都在发生，基本上大家都把拍马屁当做一种礼仪，可是并不是每个人都喜欢别人拍的，人家又觉得不拍不礼貌，拍了对方没反应有觉得对方不礼貌。
【 在 timshaw (写啥呢？真矛盾) 的大作中提到: 】
: 昨晚上看到一本用友人写的书，说很多技术顾问不愿意跟着销售出去吃喝玩乐，而销售经理又不好意思不叫，怕得罪啊。..




☆─────────────────────────────────────☆
timshaw (写啥呢？真矛盾) 于 (Sat Jan 16 13:38:57 2010) 提到:

所以你在洗脚房里睡觉，他们估计在嘀咕:难道是要把妞送到他房里去? @_@
开个玩笑。

【 在 canper (洗衣粉) 的大作中提到: 】
: 其实每时每刻这种事情都在发生，基本上大家都把拍马屁当做一种礼仪，可是并不是每个人都喜欢别人拍的，人家又觉得不拍不礼貌，拍了对方没反应有觉得对方不礼貌。




☆─────────────────────────────────────☆
canper (洗衣粉) 于 (Sat Jan 16 13:41:40 2010) 提到:


没有，每次出来他们都使劲的和我说这是很健康的事情，不要想歪了等等。


天地良心，我从来都认为这是很健康很健康的事情，但是健康的事情多了去了，又不见得一定要做。话说每星期打羽毛球我都没去，怎么就没人来和我解释：打羽毛球是很健康的事情。

【 在 timshaw (写啥呢？真矛盾) 的大作中提到: 】
: 所以你在洗脚房里睡觉，他们估计在嘀咕:难道是要把妞送到他房里去? @_@
: 开个玩笑。




☆─────────────────────────────────────☆
SPQR (苍狼) 于 (Sat Jan 16 17:52:51 2010) 提到:

这是因为不会说话啊...
做销售的, 何至于这么不会沟通

【 在 timshaw (写啥呢？真矛盾) 的大作中提到: 】
: 昨晚上看到一本用友人写的书，说很多技术顾问不愿意跟着销售出去吃喝玩乐，而销售经理又不好意思不叫，怕得罪啊。..




☆─────────────────────────────────────☆
SPQR (苍狼) 于 (Sat Jan 16 17:54:29 2010) 提到:

打羽毛球是很健康的事情

【 在 canper (洗衣粉) 的大作中提到: 】
: 没有，每次出来他们都使劲的和我说这是很健康的事情，不要想歪了等等。
: 天地良心，我从来都认为这是很健康很健康的事情，但是健康的事情多了去了，又不见得一定要做。话说每星期打羽毛球我都没去，怎么就没人来和我解释：打羽毛球是很健康的事情。




☆─────────────────────────────────────☆
timshaw (写啥呢？真矛盾) 于 (Sat Jan 16 18:17:17 2010) 提到:


销售来了，赞o(∩_∩)o...哈哈
【 在 SPQR (苍狼) 的大作中提到: 】
: 这是因为不会说话啊...
: 做销售的, 何至于这么不会沟通




☆─────────────────────────────────────☆
finely (finely) 于 (Sat Jan 16 20:55:03 2010) 提到:

你们都喜欢发长文 啊

我说个简短的，主要就是“工程”和“研究”之区别

工程就是干活，理论和工具都是现成的，用就是了

研究是高难度的创新，是制造理论和新工具的

软件从本质上讲，是个工程，但是一个复杂度极高的工程，以至于很难控制，所以需要一些理论和方法来控制这个工程。

【 在 ihomd (ihomd) 的大作中提到: 】
: 别笑我弱大家讨论讨论，呵呵
: 我老听说“要以工程的方法来开发软件..."等等类似忠告。可以我怎么也不能领会工程的真
: 正意义。
: ...................



☆─────────────────────────────────────☆
SPQR (苍狼) 于 (Sat Jan 16 22:43:39 2010) 提到:

有意思

所以工程大致是(关键字)
1) 应用/制造 (输出是可以直接使用的实物)
2) 系统化的/方法论的

不是;
1) 研究 (输出是研究报告)

但是其实工程这个概念是不需要严格界定的

【 在 finely (finely) 的大作中提到: 】
: 你们都喜欢发长文 啊
: 我说个简短的，主要就是“工程”和“研究”之区别
: 工程就是干活，理论和工具都是现成的，用就是了
: ...................



☆─────────────────────────────────────☆
zhangmike (秦月) 于 (Sun Jan 17 08:21:43 2010) 提到:

正确的短文的产生 是先有长文，再提炼,提炼完了后，短文就不完全对，一般95%的情况下是对的。还有5%的特殊情况下就不对。
然后就又有讨论和争论，焦点在5%的部分。
所以有时间也可以看看长文。


【 在 SPQR (苍狼) 的大作中提到: 】
: 有意思
: 所以工程大致是(关键字)
: 1) 应用/制造 (输出是可以直接使用的实物)
: ...................