老程序员一蓑烟雨任平生

学习丰田生产方式

一蓑烟雨任平生 — Sat, 31 May 2008 10:55:17 +0800

作者: 一蓑烟雨任平生链接：http://leebo.javaeye.com/blog/198930 发表时间: 2008年05月31日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

按照个人理解整理了一个丰田生产方式的大纲，以便在开发过程中进行比对学习。

1、总则：杜绝浪费
丰田的7种浪费
消除浪费的步骤
零库存

2、准时化
均衡化生产
生产流程化
生产节拍与看板
5S

3、自动化
标准作业书
省人化
缩短更换作业时间
维修保养

4、改善
目视管理
现场改善
IE手法

5、IE手法
工序分析
动作分析
时间分析

已有 0 人发表留言，猛击->>这里<<-参与讨论

JavaEye推荐

无坚不摧唯快不破

一蓑烟雨任平生 — Sat, 19 Apr 2008 14:21:57 +0800

作者: 一蓑烟雨任平生链接：http://leebo.javaeye.com/blog/184417 发表时间: 2008年04月19日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

什么人做功能测试比较好？这是我写这篇《功能测试谁来做》的想法。

经常有人会跟我说他们公司开发过程很好，配备了独立的功能测试组，有的成立了独立的测试部门。也有顾问告诉我，要有独立的测试人员。也有相当的人想着用测试来和开发制衡。

首先我承认要有功能测试组，而且我也会在项目中采用功能测试这个环节，但是对于什么样的人能做功能测试，我有自己的看法。

对项目组来说，谁设计谁测试，既然是功能顾问、功能分析设计人员做的业务分析和设计，那么就应该由他们做功能测试，而不是新手或者对业务不熟悉的测试人员，独立的功能测试部门，因为要参与多个项目，不可能精于某一领域的业务，所以他们的测试往往只是流于表面，稍微深一些的业务就无能为力。至于开发人员能不能做测试？一看规模，二看角色合并程度，我认为如果一个人业务和技术能力都很强，就更应该将功能测试交给他，而不必增加新的人手。

最理想的功能测试人员是业务用户，但是很难抓到他们，而且他们也没有时间去做用例，再完善的场景设计和用例，也无法完全覆盖，同时基于成本，也不能无休止的进行用例编写测试应该把上线前后的两个阶段，用户验收测试和上线试运行，视作功能测试，也就是说开发期的结束不是在上线前，而是在验收后，这样做就需要定义自己的项目开发过程和开发方法。

越快将可运行的系统提交给客户越好，Agile的各个流派提供了很多成功实践，我再提提我的看法，正好也把这篇BLOG和我以前的几个联系起来：
1、业务驱动，项目组必须要有强有力的业务顾问和分析人员，做好项目策划，这个可以参考我前面说的“四种模式”。对于熟悉的业务领域，做好积累。对于不熟悉的业务领域，做好上线后反复的准备。
2、缩短原型开发时间，把上线的系统视作原型，把用户视作功能测试人员，让用户真正使用系统，提出业务细节的变更，找到错误。
3、开发人员要能业务、技术能力同样突出，省掉多余的环节，他们是士官，能指挥小组，并且也能打仗，没有业务理解和分析能力、纯粹的编码人员将被淘汰。
4、做深一个业务领域，产品化。
5、不迷信流行的开发方法论，什么样的世界观决定什么样的方法论。

已有 6 人发表留言，猛击->>这里<<-参与讨论

JavaEye推荐

功能测试谁来做

一蓑烟雨任平生 — Thu, 03 Apr 2008 22:19:02 +0800

作者: 一蓑烟雨任平生链接：http://leebo.javaeye.com/blog/179425 发表时间: 2008年04月03日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

受微软的影响，项目组单独配备功能测试人员，在很多公司里成为一种标配，而且经常是找一些小丫头来做，实际上效果如何，基本上没有用途。

功能测试应该由对业务非常清楚的人来做，而对业务非常清楚的只有二类人，一类是业务功能顾问，他们负责与客户进行沟通，能站在业务流程的整体上去测试，也就是谁做业务设计谁做业务测试。另一类就是业务模块的使用人员，他们是用户。所以真正的功能测试，应该是这两类人员去做。我比较倾向于业务功能顾问进行功能测试，通过测试后，尽快交给业务用户使用，一起进行业务测试，而不是将功能测试交给一些由外行人士构成的独立测试组。

这里面又包含了我的一个观点，真正的测试阶段是系统上线后的几个月，正式使用前的测试，做的再多再细，因为只是关键用户参与，往往只完成基本流程的测试，业务场景的设计也不会全面，上线后会碰到更多的业务特例，怎么应对非常考量项目组的能力。

已有 3 人发表留言，猛击->>这里<<-参与讨论

JavaEye推荐

企业应用干嘛要用做网站的技术

一蓑烟雨任平生 — Mon, 31 Mar 2008 12:16:46 +0800

作者: 一蓑烟雨任平生链接：http://leebo.javaeye.com/blog/177995 发表时间: 2008年03月31日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

现在的B/S开发，做企业应用系统，表现层还是基于网站的开发技术，基本靠程序员在代码里面画页面，10几年来一直没有什么进步，是不是从根上就是错的，企业应用用Web页面来进行展现是否合算？

B/S只是一种系统部署应用的架构，基于Web，但不一定非要用Web网页的开发技术，目前一些ERP厂商采用的远程接入方式，换了个角度来解决C/S系统的部署应用问题。

按照厂商的说法，基于服务器计算模式的远程接入平台，能够将C/S架构的产品WEB化，“是一种在服务器上100%地安装、管理、支持和执行应用程序的计算模式;所有的计算都是在服务器端完成，在网络上只传输键盘、鼠标点击和屏幕更新信息，应用性能与网络的带宽无关;客户端不安装任何程序，不需要任何计算能力，也不需要进行任何维护;在应用上，能够将企业基于局域网的应用直接延伸到互联网，而不需要进行任何变动。”

ERP厂商考虑的是经过长期考验的C/S产品，如何不重起炉灶，但能应对Web化的需求。值得我们考虑的是，能否基于C/S开发，采用远程接入方式，用户通过浏览器访问业务系统，这样是否是一个很理想的架构方案？

已有 34 人发表留言，猛击->>这里<<-参与讨论

JavaEye推荐

世界观决定方法论

一蓑烟雨任平生 — Sat, 08 Mar 2008 16:06:23 +0800

作者: 一蓑烟雨任平生链接：http://leebo.javaeye.com/blog/169368 发表时间: 2008年03月08日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

世界观决定方法论

Lean，丰田的精益生产方式，把开发当作是生产制造。
Scrum，橄榄球，把开发当作是一场比赛。研究研究NBA、足球、围棋的比赛训练，是能找到不少好的成功实践。
RUP，把开发当作拼图，你不会拼，我就卖给你工具，为了更好的掌握工具，最好买我的咨询。
MSF、FDD、XP，高人补充，我没想好。

可以站的角度太多了，比如：战争，没有比这种项目风险更高的了，怎么没人从这个角度来创建一个流派。

已有 0 人发表留言，猛击->>这里<<-参与讨论

JavaEye推荐

从二战德军之父冯·西克特看团队培养

一蓑烟雨任平生 — Thu, 06 Mar 2008 17:00:57 +0800

作者: 一蓑烟雨任平生链接：http://leebo.javaeye.com/blog/168827 发表时间: 2008年03月06日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

从二战德军之父冯·西克特看团队培养

冯·西克特“缔造了一支成为国家中流砥柱、被证明为同时代训练最佳、领导能力最强的军队。他制定了重新武装和重振士气的计划，使德军最大的优势——军官团得以保留，使新的战术战法得以酝酿而成。凡尔赛和约规定德军人数不得超过十万，所以西克特制定的标准是：士兵身体良好，有12年以上的服役经验；军官要有25年以上的从伍经验。一旦成为国防军的一分子，要接受某一方面的专门培训，重点是领导才能。他极为重视士兵的个人技能和主观能动性。合约禁止德国拥有军事院校，他就联合团一级的单位建立了一个建在部队上的军事教育体系，每一位列兵都受到成为军士的培训，每一位军士都受到成为军官的培训，每一位军官都受到成为将军的培训。每半年进行一次演习，使专业技能得到精进，职业素养得到提高。没有坦克、高炮，就用纸板、木料仿制，德军也许是唯一用玩具飞机模拟真飞机演练对空射击的军队！单兵在演习中要自称我是某某排，或者代表一个8人机枪组。这一切的一切构成了冯·西克特的“十万陆军”！”（原文见《二战德军之父——冯·西克特》http://www.sspanzer.net/army_officer/seeckt/seeckt.htm）

明确定位和培养员工，提高领导才能、个人技能、主观能动性，掌握新的思想，让他们能有全面的提升，项目如同战争，成功靠的是团队的信心、勇气和能力，不是规范和条例。

我们往往会说，公司大了，原来几十个人的时候，管理很松散，现在不一样了，要抓管理。现在看来，我们是要想想，要应对公司今后规模扩张，我们要做的不仅仅是管理制度完善这么简单的事情，最关键的是员工能力的提升，在没有扩张的时候，就把他们当作更高一级人员来进行培养。“每一位列兵都受到成为军士的培训，每一位军士都受到成为军官的培训，每一位军官都受到成为将军的培训。”

已有 4 人发表留言，猛击->>这里<<-参与讨论

JavaEye推荐

我对产品化的理解

一蓑烟雨任平生 — Thu, 06 Mar 2008 16:19:44 +0800

作者: 一蓑烟雨任平生链接：http://leebo.javaeye.com/blog/168816 发表时间: 2008年03月06日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

我对产品化的理解

产品化的时机是看业务的需要，不管是对前景的落实，还是项目转化成产品，这些都不是技术人员能考虑的，业务的发展和策划，如何进行市场细化等如果都由技术人员考虑，产品化的风险很大。
风险最大的是对于产品化的理解。

提到“产品化”，大部分技术人员，包括很多公司老板，首先想到的是可销售性，也就是免实施，“软件产品的制造成本为零，微软就是这样发财的”，这是很多人跟我这么说，为什么要做产品。
基于这种考虑，技术人员往往把主要精力放在体系结构设计，把焦点放在可配置性、零实施等环节，小型软件可能可以做到，而对于绝大部分中小软件公司，主要做的都是企业管理软件，采用这种思路会是一种灾难，企业管理软件是靠业务驱动的，即使是国外的成熟软件实施周期也不会比定制开发少多少，基于技术架构而不是业务来做产品开发，还没做出第一套就想着零成本复制，还没有业务应用，就想着软件提供的组织机构要支持复杂的矩阵式，甚至虚拟组织，基于产品的二次开发被看作是一种罪恶，从精益的角度上看也是一种过度设计，是一种浪费。如果基于这种想法来做产品，可以说产品失败的风险是非常大的，技术上对于一般的中小公司而言，是无法保证的。
通用类产品、中间件及系统软件的产品化，我没有这方面的经验，无法评论。

企业管理软件，切入一个行业和领域，是可以产品化的，不过产品化在很大程度上讲，我认为是一种商业名词，是一种结合管理思想、实施方法等个性化元素的东西，无法轻易复制和实施，不具备大规模的销售可能。公司想做好，靠的是咨询顾问，他们所要的是Best Practise，技术在这个领域对顾客的影响是微乎其微的，项目成功靠的是实施，我看国外的产品实施跟二次开发也没什么区别。

如果不是通用产品或者系统软件，做企业管理软件想零成本实施不太可能，产品所提供的功能永远无法满足客户的业务要求。而且靠销售软件产品挣钱，远远不及靠实施顾问挣实施费挣钱挣得多，后者才会给企业客户带来管理上的提升。

软件公司怎么做产品化？我的意见是：
1、找到合适的项目和合适的客户，多做项目；
2、在某一个领域积累行业经验，建立样板工程和成功案例，并将项目产品化（指商务概念上的产品）；
3、提炼管理理念，并将理念和成功案例结合，整理实施方法论；
4、找到下一个项目，在项目开发过程中将原系统重构。

在刚开始的时候，别想着挣大钱，先老老实实做项目，只是要从业务的上多下功夫，对公司而言更重要的是抽象和提炼管理思想和业务规则，整理好实施方法和项目管理的经验，多做几个成功案例，产品化才有良好的基础。

已有 7 人发表留言，猛击->>这里<<-参与讨论

JavaEye推荐

基于客户业务能力的软件项目开发的四种模式

一蓑烟雨任平生 — Wed, 05 Mar 2008 22:17:53 +0800

作者: 一蓑烟雨任平生链接：http://leebo.javaeye.com/blog/168479 发表时间: 2008年03月05日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

基于客户业务能力的软件项目开发的四种模式

很多业务系统只能定制，定制软件一直有个“金科玉律”：根据客户的业务模式来实现。日产的过程首先强调的是业务改善先行，只有业务功能定义清楚才能进行IT实现。

定制开发也罢，产品实施也罢，很重要的一点就是对客户所要开发的业务的理解和掌控，简而言之就是业务能力。

我将客户自身的业务能力和开发方的业务能力（不是技术开发能力）按能力强弱进行了组合，实际上也是业务的沟通能力，整理了四种模式：

1、客户业务能力强，开发方业务能力弱
2、客户业务能力弱，开发方业务能力弱
3、客户业务能力强，开发方业务能力强
4、客户业务能力弱，开发方业务能力强

第一种模式：客户业务能力强，开发方业务能力弱

这种模式下，开发方基本上只能按照客户的业务要求来做，一般发包的项目都是这种情况，开发方通过努力学习客户的业务逐步来细化，表面上看这种模式的开发还是比较轻松的，风险也不小，客户对软件开发如果不清楚，盲目扩大项目边界，或提出无法实现的功能，特别是客户对业务很清楚的时候，往往会忽略掉一些他们认为很常见的地方或者一些异常情况，最后项目往往会反复修改，客户总觉得有些地方实现的功能和预想有差距。

控制这种风险的策略是引入业务专家或者顾问，对项目进行评估，并在项目的设计阶段与项目组和客户充分沟通。

第二种模式：客户业务能力弱，开发方业务能力弱

这种模式是非常让人恐怖的，严格的讲，这样的项目根本就不应该上，开发方也尽量不用碰，除非是样子工程，摆摆架子而已，如果对进度和项目结果有一个很好的期望值，不管是客户方定功能供开发方开发，还是开发方提功能供客户评判，这种模式下的项目基本上可以断定会失败，

我见到很多的项目都是这种情况，有的是老总头脑一热，听到某种理念；有的是咨询顾问把客户说动；有的是上级命令，这些情况下，客户所面对的是个陌生的业务，具体的办事人员就更糊涂了。

碰到这种模式，如果想把项目做好，双方都需要提升业务能力，根据提升能力的差异，会转换到另外三种模式。

第三种模式：客户业务能力强，开发方业务能力强

这种模式下，如果双方沟通的好，是比较理想的一种模式。

客户和开发方都清楚业务的范围和边界，也清楚业务的细节，对于业务分支、异常情况都明白，特殊的业务只要简单的解释就可以理解，双方使用的是同一种语言，项目成功的可能性较大。

这也是行业应用门槛高的原因，对行业业务职能比较清楚，和客户的沟通就非常顺畅。

对软件公司而言，认准一个行业，对业务深入理解，做得专业，有很强的业务能力就总会有自己的市场。

第四种模式：客户业务能力弱，开发方业务能力强

这种模式对于开发方的商务人员而言是最好的，有时碰到一个非洲商务人员，可以报个天价。

很多业务咨询和产品实施都走的是这个套路，给客户一个美好的前景，有一套完美的理念，以及一个很花哨的产品，拿着PPT把客户搞定，剩下的就是实施拿钱，客户用不好则是能力问题，呵呵。

坏话说了一堆，是对看到很多咨询公司和软件公司的做法非常不满，不过这种模式下的定制软件开发，对开发方而言也是很有利的，因为你能告诉客户需要改进的地方，如果你很实际，真心帮助客户解决问题，客户是非常喜欢和这样的开发方打交道的。

根据项目所处的模式类型，我们决定我们的开发方式，根据项目类型，进行必要的模式转变。

已有 2 人发表留言，猛击->>这里<<-参与讨论

JavaEye推荐

老程序员 一蓑烟雨任平生