在路上的图书主页-查字典图书网

2008-12-25

wow，My God，当当终于销售《走出软件作坊》了

如果还有人不了解这本书内容的，可以看我的blog上的部分草稿：

http://blog.csdn.net/david_lv/archive/2008/02/28/2127299.aspx

这是第一章的草稿，在我的blog的4月、5月、6月、7月、8月的blog中有更多的草稿可以预览。

但纸版书仍然比网上草稿多40%的内容，快多一半了，所以还是推荐阅读纸版书，而且网上的草稿是过去自己笔记的整理，没有经过专业编辑，所以思路有些混乱，结构不够清晰

我是书作者，叫阿朱，欢迎交流

2008-12-11

这本书不是一本方法论的书，而只是我的10年工作点滴思考经验总结而已。我喜欢记笔记写东西，10年来记了很多东西，现在整理出版。

如果你是学生想找工作，这本书合适
如果你想跳槽，这本书合适
如果你想创业，这本书合适
如果你不知道未来怎么发展，这本书也合适

我的其他观点在blog.csdn.net/david_lv

我擅长产品体系规划产品研发管理技术架构

关注SOA、云计算hadoop、SaaS、FLEX、JAVASCRIPT、mashups、atom app、REST

一个网友说的挺好，我给发过来了

2008-12-30

我从当当订了这本书,一天一夜看完了(当然是简单的看,没有思考).但看后觉得真的非常有价值!
我做了8年技术,其中四年程序员,四年技术经理.其中的味道只有自己知道,四年前我十分向往西方的管理,西方的文化,觉得国内怎么能这样呢?怎么老板和客户不按规则行事呢?可四年后我发现不是别人的文化好,而是我们自己不行.阿朱书里有一句话我十分赞同:人对了,世界就对了!书里有很多写出了我想过思考过但没有写出来的问题.
的确很有价值,我希望阿朱接下来能否办一个论坛(不是网上这种),邀请一些程序员项目经理技术总监CTO来坐而论道!那样或许能擦出更多的火花.

从QQ群转过来的，评价的很毒

2009-01-02

阿朱的这本书很奇怪，说是开发过程管理，却有技术人员职业发展规划，又有IT行业未来趋势观点，还有自我素养修炼，其中还穿插了不少关于实施技巧、售前演示技巧、报价技巧，里面讲到的技术也有一定深度。书中涵盖了许许多多方面的内容，却又浑然一体，似乎缺了哪一章都是一个缺憾，但合起来，又显得这本书被塞了太多想表达的东西，如果单独分解成一套丛书，又觉得太成篇累牍。要把这本书归集为软件工程类书籍也不合适，归集到企业管理类也不合适，这到底是一本什么样的奇书呢？反正我翻来覆去看了好几遍，每次看每次都有新的启发，很多细节看一遍没有注意到，看第二遍才发现非常值得深思，如果要把每个细节都说透彻，我看这本书得有1000页。不过我很喜欢阿朱现在讲到的这个层次，点到为止，给了我们许多启发创新的思考空间，如果真讲的很透，可能就显得呆板无味了

一位程序员读者写的《走出软件作坊》读书摘要

2009-01-30

http://blog.csdn.net/yaoxiao83/archive/2009/01/17/3819782.aspx

走出软件作坊之精简版
Ø 走出软件作坊有了偏方
至今为止，在软件行业已经滚爬多年，见本部门现状（软件作坊），提出建议走出软件作坊，参加软件开发正规军。需求、开发、质量和演示已经成为我们的头号难题，但现实中，已经有太多的成功例子，或许完全成熟和正规的管理方式我们并不实用，先进的辅助工具反而适得其反，那么是不是没有解决办法了呢？值得庆幸的是我们还有解决问题的偏方。
Ø 解决温饱 - 团队建设
l 给客户最有效的药丸 - 演示
说难不难，说易也不易，演示是我们对外开放的窗口。就算我们的项目或产品做得再好，如果演示做不好，客户不满意，对我们的声誉也有很大影响，严重则可能前功尽弃。其实很早之前我们就意识到这个问题，想从内部找到解决方案，事实告诉我们，这没有成功。我们总不能永远信赖别人，所以我们需要专业的演示人员，此角色的人员需要具备以下技能：
1 有较强的演讲能力
2 能快速熟悉软件项目或产品
3 有一定的演示制作和讲演经验
l 软件产品的基石 – 基础框架与公共部份
我们没有雄厚的资本，没有庞大的开发团队，但我们可以改善我们的管理方式，利用现有的人员与物质资源，最大化我们产生的效益，当然这个观点需要得到大家的认可。任何项目或产品都有底层的公共部份，我们不能每一个产品都重头开发，那么我们将需要一个成熟稳定的基础框架，基础框架将解决以下问题：
1 项目或产品的质量无法保证
2 项目或产品的开发周期长，成本高
3 项目或产品的后期维护多，耗去了大量的时间、人员和资金
所以我们需要专门的人员来进行基本框架的建立，这个专门人员叫做主程（主要程序员），他将掌握公司软件的基石，当然这个人员需要一定技能：
1 对软件的基础理论知识掌握较好
2 对软件的设计和各方面技术比较全面
3 对软件的速度、安全性、扩展性、稳定性有高度认知
4 对发布软件二次开发有一定研究
5 对新技术、新理论有快速反映能力
l 质量的保证 – 测试
有了软件项目的基石，我们还需要保证软件产品的质量，如果产品质量无法保证，那么我们所做的也得不到客户的满意。所以测试人员将是软件产品质量的保证人员，测试人员应具备以下能力：
1 对软件产品有一定测试经验
2 比其他服务部门更懂软件
3 具备产品的版本管理、打包与部署方面能力
4 源代码和数据库的备份管理（没有专门的配置管理人员的情况下）
l 是产品就必不可少的 – 文档
既然叫做软件产品，那产品需要的相关文档也需要有人专门负责，那就是用户手册、SDK开发手册和相关设计文档，而这些文档恰好是程序员不太擅长的方面，如果分离出来，他们将更有精力干好本质工作。这就是所说的文案人员，应该有较好的软件文档编写功底。
Ø 迈向现代化建设之路 - 过程管理
有了这样的梦幻团队，可以说是基本的温饱问题能够得到很好的解决，但我们肯定是不满足于温饱，而是要奔小康，那我们将在过程管理上下功夫。
我们不需要完全规范化的过程管理，但我们不能少了过程管理，过程管理将给我们带来量和质的飞跃。在过程管理中，当然少不了管理工具，但我们不需要先进的管理工具，说不定先进的工具会适得其反。越是功能强大的工具，使用也会越复杂，为了使团队能有效地推动管理过程，满足需要将是首选。
l 设计软件之Office
界面设计软件：PowerPoint可以像我们的操作界面一样进行流程跳转，也可以添加菜单、工具条之类的东西，它能快速地将需要进行展现。最重要的是客户、领导、老板、经理和开发人员都能明白，所以我认为它是界面展现最有效的工具。
报表设计软件：信息管理软件中不可缺少的报表输出功能，但我们用什么东西可以快速地反映报表的内容和样式呢？Excel将展现出它的魅力，我们可以利用它快速地建立报表样本。
l 需要管理系统
一个软件项目从最初的设想到实施，都会产生很多需要，当然主要的需要应该是在项目建设前期，但后期的需要变化也是无穷尽的，所以需要的管理是个非常重要的任务，只有记录了不同环境、不同人员提出的需求问题，我们才能有效地进行跟踪。
l 任务管理系统
人员的逐步增加给任务管理工作带来了难题，常常是任务分配不当，导致了人力资源的浪费和项目进度的难以控制。引入任务管理系统将是有力的解决办法。
l Bug管理系统
软件是个奇怪的东西，制作软件时将不可避免地产生Bug，而且Bug的数量不会因为你修改后就不再产生，经调查每修改100个Bug将产生20个新的Bug，这给我们的软件产品质量带来了威胁，但我们并不是拿它没有办法。Bug管理系统将有效地记录Bug的修改和产生情况，它将在整个开发周期中为修改Bug提供帮助。
l 版本管理工具
这已经不是个新鲜的话题，但这里再强调一次。源代码、设计资料、手册、其他文档等这些软件构造过程中的产物，它们有一定的特殊性，所有资料将不会是一次性就完全正确，所以它们是在整个软件周期中逐步成熟起来的，其中每个阶段都是重要的成果记录，所以版本管理是团队开发不可少的利器。

程序员怎么看这本书

2009-01-07

http://blog.csdn.net/Solstice/archive/2009/01/04/3707303.aspx

这是原地址，我是转载来的

《走出软件作坊》by 阿朱
这是一本靠谱的书。
p. 60，走钢索的人——架构师
有一部分所谓的架构师，技术超深厚，框架堪比Spring之类，但自己一个人闷头写框架不断优化，力竭使用最先进的技术思想，希望把最豪华的设计模式融进去，希望把OSGi融进去，希望把AOP融进去，全无视那些想利用框架减轻自己工作量提高自己工作效率的应用功能开发同事。这是在用公司工资玩技术呢，还是在满足个人技术幻想呢，还是在实验呢？到底在干吗？价值在哪里？

…………

我手底下有个框架开发员。他的技术渴望很强烈，为了技术难题攻克，可以不吃不睡。并且技术敏感度很强，学习也快。所以当时我感觉他是个程序员的料，就把他拉到我的手下。

但是有个问题，他写出的框架代码，在平时开发业务功能的时候挺麻烦。大家可能需要的是一把铁锹，但是他却给大家N根不同长度不同粗细不同材质的木棍，N个不同形状不同用途的铁锹头。大家会有N种组合。不仅导致他写代码老超任务期，而且也让使用人感觉没多大帮助。使用起来复杂，而且还得配置这个配置哪个，需要注意的地方太多。业务开发组的同事就不愿意用，还不如把代码自己直接写死了得了。【陈硕：先写死往往比预留扩展接口更加实用】

超期还会影响业务功能开发组的使用。本来人家是为了想加快自己的工作效率。你答应好这个星期给业务开发组提供一个功能，但你没有拿出来。就耽误人家进度。你多次拿不出来，人家业务开发组还不如自己开发一个呢，求人不如求己。

我最后警告他：OO、设计模式、接口？！和客户一点都没关系！那客户为什么要给我们钱？老板为什么要给开发部钱？开发部存在的意义在哪里？难道是翻译成代码？就这点意义，还要月薪上万？凭什么？你的价值在哪里？如果你认为自己技术够牛，那么你必须证明你能很快做出来。如果你认为自己技术够牛，最好能牛到，只提供一个函数就解决了他们的问题。别这个代理类，那个聚合类，这个唯一实例类。最好连参数也没有，大家调用一下写一句代码就OK。【陈硕：函数才是最佳的复用单元】

p. 149~150，代码那些事儿——代码编写规范
……大多数刚出道一两年，还有不少在校学生，希望认识并聊聊，要和我聊设计模式、OO、SOA，还有人建议我去看看OO和UML的书籍。

我确实没有阅读过OO的书籍，我不是一个死钻牛角尖的人。我只是有什么问题，就去找解决问题的方法，能解决我的问题就OK，而不在乎我用的正不正宗，也不在乎我用的是不是OO。可能它是OO的外壳，但是它实质上可能是伪OO，我也不想去深究和区分什么是正宗OO，什么是伪OO。反正能解决我的问题就行。

…………

这样，一个样子像OO的类产生了。它可能只遵守了OO所提了封装，它却没有实现OO所提的继承和多态。所以它可能是个伪OO，但它确实解决了我们的问题。【陈硕：Object-Based多好啊】

…………

我过去领导过架构组。架构组的人在2002年的时候，疯狂迷上了UML和设计模式，人手一本《COM本质论》和《设计模式》。我手下有一个新手，就处处是类，处处是抽象，处处是封装，处处是分离，尽量使代码高内聚低耦合。但是这样的的代码太麻烦，他花费了大量的时间，他看自己的代码赏心悦目，别人看他的代码云里雾里，不阅读懂《设计模式》就按照常规理解业务的思路去阅读他的代码根本阅读不懂，不知道他为什么这样写代码，怪异的很。本来，这位想达到可维护性，可阅读性，却真正的失去了可维护性、可阅读性。这和我前几天看我的朋友周爱民写的《大道至简》中写到：有人希望拿UML去统一用户和软件设计者。殊不知UML有多难理解，而UML设计者却认为UML可以描述一切。就这个道理，要理解你的代码还要去读懂《设计模式》，这要求太高了吧。

所幸这位新手自己都每次写的累，慢慢的也就懒了，觉得确实需要分离的时候就分离，觉得没什么必要的就懒得做了。用他自嘲的话说就是：被磨平了。其实，依我看，他现在这个代码状态才是刚刚好，即照顾了设计扩展，又照顾了实用。真正的纯OO，纯设计模式，可能只存在于教学和科学，而不在于我们的商业软件开发。我们作为商业开发，强调的是叫座的基础上叫好，所以折中方案是必须的，客户和我们自己两相宜就OK，是否符合正宗，就不在我们的商业开发管理范畴了。

一个华为的朋友写的《走出软件作坊》书评，今天刚收到书就看了

2009-02-06

原文地址在
http://www.abuer.com/manage/the-best-soft-devolopment-handbook-from-david.html

非常感谢博文视点周筠老师推荐并快递了阿朱的《走出软件作坊》这本书。看完目录并读完第一章就让我有迫不及待的要写下这篇文章的冲动。这种冲动来自于一种共鸣或者说共振。

    双龙会——CTO与技术总监是阿朱的开篇之作，我相信这篇文章阿朱没有要写出CTO和技术总监区别的意思，这也不是这本书或者这篇文章的重点。阿朱的目的是告诉我们如何才能够很好的做一个CTO甚至大而化之的做一个管理者或者职业经理人。

    1：得到您的Boss的认可。这里的Boss不仅仅指您公司的老板也包括您的顶头上司。这是一个管理者的首要职责。我一直认为，公司的管理流程中应该强调市场化的管理流程，以服务客户的心态来服务于您的上下工作序列，把他们当做您的客户来服务。对你的老板，这条原则同样适用。老板做为您的客户，您需要象了解客户需求一样了解你的老板的需求，并尽自己最大的努力来实现这些需求。通过提供优质的产品服务来得到您的客户的认可！这是一种意识并应该成为指导您工作的原则和标准。

    2：找到适合工作的管理方式。在这篇文章中阿朱并没有提到这一点。但是从阿朱对CTO的四种能力的描述中可以总结出这一点。CTO需要四种能力：商业眼光；管理才能；技术眼光；产品架构。我相信这不是教科书式的对CTO的职责定义。我看到网上有网友的评论认为这应该是CMO的职责。“公司必须有CTO，凌驾于技术总监之上，统管咨询、实施、支持，协调市场与销售”。是的，如果我们照搬西方的管理理论，阿朱的CTO职责有一部分是CMO的职责。然而大家不要忘记了，《走出软件作坊》将的是中小软件企业的管理。一个中小规模的软件企业往往是偏技术的甚至有可能是技术导向的企业。为这样一个企业单独设立一个CMO的职务合适吗？而让CTO来担当这样的职责更加符合企业的实际情况。

    管理只所以是一门艺术，原因之一在于永远没有放之四海而皆准的管理方法。管理应该因时、因地、因人的不同而采用不同的管理方式从而收获最好的管理效果。把另外一个公司的成功管理一成不变的搬到您的公司往往会是死路一条。我在管理的境界中提到，科学的管理仅仅是一种初级的管理方式，任何流程，制度能不能发挥作用关键在于管理者的灵活适当的应用，只有当您知道了如何合理的运用管理科学的时候，您才是一个合格的管理者。

    虽然只是读了一篇，但就像作者所说，这是一本脚踏实地的书。绝对值得您深入的研究和思考！

畅享网上的网友书评：没有银弹

2009-01-18

我读书有两个习惯：一是习惯于跳着读，书买回来后先看目录，找到自己感兴趣章节先看。二是习惯结合自己的情况来做对照，想想自己是怎么做的？看看书里是怎么写得？哪些可以借鉴，哪些不一定对。

阿朱同志的大作《走出软件作坊》买回来后我还是按着这两个习惯开始阅读，首先看引子《这本书适合谁》，然后看未来发展趋势篇的内容，然后挑着几个自己关心的重点篇章进行了阅读。书读完了，忍不住向公司内的朋友推荐，我是这样介绍的“一个从事管理软件领域多年的家伙写的书，书里提到的很多问题咱们公司都碰到过，很值得一读。”，朋友问我，“有没有一套切实可行适合咱们公司借鉴方法呢？”，这一下子把我问楞了。思考了一会儿，反问到“这个世界上有这样的方法么？”

管理软件信息化这碗饭不好吃，相信这是业内朋友的共识。把企业管理理念、操作流程、利益平衡这些装到一套系统中，本身听上去就是一件玄乎的事儿，更何况负责实现这项任务的人，在知识积累、社会阅历乃至生活经验方面的又是一帮毛头小子。听上去简直是不可能完成的任务。

解决这一问题的出路在哪里？就象在武侠小说里，看到一本书，背上几个秘诀，吃个果子或者大蛇什么的？瞬间就成为绝世高手了。

很遗憾，答案是“无解”，或者套用一位软件界前辈的话“没有银弹”。

通读阿朱的书，发现他对软件企业运作的方方面面都有涉猎，但很多都是开了个头，提出了几个小技巧，好像没有写完，但又不知道如何写下去。这不应该怨作者，我想阿朱要做的就是提起一个话头，引发我们的思考，具体如何操作还是要靠我们自己。

因为这就是世界的本来。

回答一位网友的《走出软件作坊》读后困惑

2009-02-23

这是一位网友在QQ上给我的留言，我个人感觉他的困惑许多人也有，所以发了上来

我已是第三次在博客上翻阅这部著作了。每次看的时候总是很心动。但看完后，发现感觉我没有多少变化。如今我已失业了。项目开发了一年，始终开发不完。老板下压，客户不满意，下属也闹。我成了众叛亲离的人。如今我只能走出公司。回过头来又看了一次你的博客之后。有几个问题想请教一下你。
我想起你说的四架马车。我想你的成功与你当时的环境与背景有关吧。如果我照搬你的四架马车，能成功吗？我怀疑这点。
我是做网站建设，从业工作有3年了。2008年公司给我机会让我带团队开发。做一个房产项目，前后开发了10个月，客户还是不满意。后来团队散了，我出局了。以这样的结束。

项目失败，我得到很多经验与教训。但现在却不知道怎么办。很多道理你都讲了，我也听了。但实施却很难。

难点：
第一。我想带好一个团队。但一个好的团队是什么样的。我不知道摸索中前进在找，很慢有时候还走弯路。感觉我就像在模像。
第二。给老板带来利润。我自己却很没信心。不知道做什么样的项目能赚钱，怎么赚钱。我总以为技术员就是把软件技术做好，质量做好就好。但赚钱的问题，我骨子里想那是运营部或是市场部的事。但如果说让技术部产生利益却实不知道怎么产生。团队的利益在哪呢？

--------------------------
以下是我（我是阿朱，上面的是网友的留言）的一些个人观点

什么是好的团队，我并没有去刻意追求。我从跟随老板创业一路走过来，很多大家现在看到的结果都是我们在行进过程中被逼无奈而做出的，我们要活着，这是我们最唯一而清晰的目标。我们也不追求什么正规与不正规好看与不好看，凡是影响我们挣钱的我们就要解决。解决来解决去就形成了如今这样。

对于研发管理来说，我所有举措围绕的目标就是：进度、质量。就这两个。我们没有资源，即使现在公司长这么大了，但是我们想做的事更多更大，永远都是资源不够用，员工的素质永远低于我们要做的事情的期望。但是我们仍然要做事。做的比竞争对手快，质量比竞争对手好，项目管理让客户感觉井井有条，改变比竞争对手快，态度比竞争对手好。就是这么简单。我不需要比中国任何一个公司都好，这没有意义，我只需要在我的这个行当比其他竞争对手跑的快就行了。我得到客户的单子，他没得到，我的公司活着，现实就是这样。我们没有太多的目的。我们做项目管理做测试做文案做UI，都有专业的岗位，不是为了分工明确，而是为了让我们的产品议价能力高，客户不能大幅度砍价。我们当初招文案人员，就是由于软件就一个软件，这样的一个裸奔的东西怎么能让客户心甘情愿付出几万元呢？所以必须做好包装，最好文档能打印上千页，做成书，然后一个大箱子给客户，沉甸甸的，让客户觉得安心。软件是一种难以触摸的东西，所以客户的购买心理就会比较靠后，所以必须要给客户手里塞一个实实在在的东西，让客户的购买心理增强。我们只是想让我们多卖钱而已，没别的想法。老板挣钱我们下头人才能挣钱，给人打工就是这样。大河都干了，我们这些小沟沟怎么会有水呢？

我们公司一向提倡全员营销，而不是只有销售部门才承担销售任务。包括我们的服务支持部门都有销售任务，必须在做客户服务的时候对客户做老客户营销。

这就是活着。

客户对你的质量很不满意，那么你就需要找一个测试人员。如果客户对你的项目管理很不满意，那么你就需要找一个项目经理。如果你的客户觉得你的软件不值那么多钱，那么你需要做好包装，从软件UI到文档，到培训，到人的穿着打扮。客户觉得你像IBM，才会付给你类似IBM的钱。就是如此。

瑞星产品经理的书评：在这本书中，你能够看到老板眼中的程序员，也能够看到程序员眼中的老板

2009-01-16

从98年毕业到现在，我一直在软件企业中打拼。自己从程序员到项目经理，到产品经理，经历过非常多的事情。参与过多个项目、产品的开发，也曾经参与过很多种管理方式的尝试。但是有个很深的困惑一直萦绕在我的心中，如何能够从纯手工作坊的方式上逐步走到正规的开发模式上？应该如何一步一步地迈进？应该从何入手？

相信在中国，绝大多数软件开发人员、项目经理都曾经象我一样考虑过这样的问题：怎样能够让一个产品或项目的开发顺利完成？为什么老板和客户一边不断地追加变更需求，一边还要压缩开发计划？为什么在开发最要命的时候，所有部门（包括老板）都对开发的东西指手画脚，希望自己的意见能够在产品中实现？为什么对于开发出来的东西，总是怨声载道？销售抱怨，市场抱怨，老板和客户都不满意？

正在我努力学习管理知识，希望找出问题的根源和解决方法，寻找一条适合自己企业现状的发展之路时，碰巧搜索到了吕先生的Blog文章。从第一篇的第一段，我就被他的文字粘在了他的Blog上，一口气读完不知不觉已经到了凌晨。看完整个Blog上的内容，整个人犹如醍醐灌顶一般，多年萦绕在心头上的困惑迎刃而解，茅塞顿开。

现在，Blog上的文字变成了我现在手中沉甸甸的《走出软件作坊》。文字中描述的问题和事情，基本上都是我曾经在工作中遇到的棘手问题。对于这些问题，吕先生的解决思路和对问题的看法独到而深刻，文笔朴实而精辟。一切从实际出发，步步为营，深入浅出地描述了一个企业应该怎样从三五个人十来条枪的软件作坊，一步步发展成开发正规军的方法和手段。从书中可以看出，这本书里凝聚了吕先生从业十年来宝贵的经验和心得。

相信读过此书后，无论是开发人会员、项目经理、产品经理，还是公司老总，上面说到的问题将不会再会是困惑。管理的精髓就是把合适的人放在合适的位置上，让所有人明确你的目标，带领这些人为你的目标而努力，直到达到目标。对于管理，仁者见仁，智者见智，每个人看事情的角度都不一样。很幸运的是，在这本书中，你能够看到老板眼中的程序员，也能够看到程序员眼中的老板。

尹松
北京瑞星国际软件有限公司产品经理