《走出软件作坊》书评

走出软件作坊,是书商的“标题党”

走出软件作坊,感觉这个提法估计是书商的“标题党”做法。其实这本书就是写给软件作坊的人看的。没有“走出”只是“走入”，理解国内行业现状，努力适应，有限改进——很实际。一直在软件作坊打工，买了一本，看了一下。书写的很实在，基本问题我们公司很相似。但是书的缺点是只是描述了问题，解决方案太原则性和概念化，对于类似企业工作的我有提示作用，没有解决方法，我是怀着走出的期望读的，但是没有看到走出的方向和目标——救赎还得靠自己——作者也会这么想的吧。作者是一个很注意思考和积累的人，难能可贵，这一点对可能进入这个行业的学生、入职2-3年的程序员、梦想着成为所谓项目经理技术总监CTO的提供了一个很好现实认知和发展路径。

反过来读《走出软件作坊》的体验

阿朱描述了在软件作坊里面“混”出头来的技术人应该具备什么素质、心态和做事方式。 的确是一本写实的好书。 这个“实”就是中国的现实，任何一位欲投身其中的青年都要认清这个现实，越早越好。正面去读这本书，就是要准备像阿朱这样思考打拼。也可以反过来读这本书，如果付出了像阿朱这样的努力，得到如书中的结果，还不能让你满意的话， 那你就别趟这趟浑水了，没毕业的选其他行业，已经入行的，趁早做点别的吧。现在我用另外一种方式来描述这个现实：我把软件相关行业按其价值链，分为两种类型：1、资源自上而下型，即资金和其他各类资源从上而下流动：（纳税人——》）政府、机关——》国企——》国企关联企业、外企——》国内IT外包商——》二手接包方——》雇员。 传统软件业（即各行业的企业级应用）就是这种类型。 注意，纳税人的首环在价值链中的作用是很有限的，所以我称之为自上而下。 这类行业的特点是：利益相关人最重要的考虑是满足上一级价值链的关键人物的需求，而不是产品本身的最大效用。IBM的一位销售经理就曾经描述过所谓“天龙八步”的销售流程，其中，决策者最优先考虑的是“安全”因素，即：不要弄砸，或者弄砸了也必须至少有垫背，有说辞。接下来就考虑的是自身利益最大化（不妨看看王强的圈子圈套），最后才是项目本身的效用。 不管是什么角色 ，都要服务于这个优先级顺序。 所以说到底这个行业是对人的服务业，如果抱着做艺术精品的预期来做这个行业，必然免不了要失望。 所以这个行业注重上层资源关系网培育；注重培训、认证、资质、跨国公司产品等提供的安全因素；注重能侍候好各类菩萨的人精（是高价值的人才）。 雇员的成长也是沿着这些因素的道路成长起来的。 由于上层资源是条块分割的，因此以此为生的软件企业也是条块分割的，这就是为什么我们这么大的国家，靠软件发财的老板很多， 但长大的高质量软件企业却很少。 既然长不大，作坊式生存的代价也可以忍受，所以传统软件业充斥着大量廉价劳力+command&control的低效管理风格。这实质上是行业的主流的生存方式。2、资源自下而上型，即广大的消费者是企业的衣食父母，要是他们不满意就会用脚投票，抛弃企业转投竞争对手。互联网行业就是最好的范例。 没效率就会死掉的压力迫使企业自始至终都强烈关注产品的效用。企业会培养、争抢能够提高团队效率的人才。高效的敏捷精益等方法论和轻量级的技术受到追捧，而CMMi、SOA等方法论则被弃用，员工的效能产出的能力增长较快，容易成长为某一领域的专家。说到这里可以得到结论：如果你要成为攫取上层资源的人精，可以到传统软件业来锻炼锻炼；如果你希望做出一个产品能让很多人受益，那么就去做互联网吧。 两者的共同点是：都不容易，都要付出持续的努力。

中国软件开发的战术经典之作

这本书聚集了阿朱软件开发的思想，字里行间充满了软件开发管理的战术，对于中小软件企业，非常受用，包括人员的配置，各个角色的作用等。正如阿朱所说，书中的经验，可以领悟其含义，不可不顾情况死搬硬套，需要灵活运用。尽信书，不如无书！对于更大的企业，如研发人员超过50人，就不仅需要考虑战术，更需要从战略，框架级来考虑，一个基本的就是软件开发框架，可以参考CMMI和Agile的方法，建立一套合适；另一个就是绩效考评体系，能够公平对待研发人员，实现正向末位淘汰。阿朱的书可以从战术层面进行有效的补充。所以，对于不同的软件开发企业，这本书都有很多可以借鉴的地方，值得大家不断探讨。

可学习模仿的成长过程

这本书的作者从他的经历出发，告诉大家他是如何考虑问题，解决问题的。没有华丽的专业名词，朴实的语句，生动的描绘了一个积极思考和解决问题的程序员一步步的成长。从他做程序员的经历仿佛看到了自己的过去，从他描述现在如何管理团队的，对自己有帮助也有信心了。学习阿朱寻找问题本质，积极解决问题而不是只是找到问题所以自己不能如何如何的心态。

夹缝里求生存

很早就读操作系统源码，被李维推荐到delphi工作都说明作者本可以做个技术高手，但家庭的背景和个人喜好使得作者成为一个技术管理方面的牛人。管理软件行业是个有中国特色的it细分行业，中国冗大的政府企事业单位和各色的中小企业一大批的信息需要电子化，而使用者自身素质和对信息技术的接受程度又使得这个行业注定成为低技术，劳动密集型的行业。使用的技术无非数据库的crud，和面对甲方反复无常需求变更，技术上与互联网和游戏行业的技术更迭不能同日而语。软件公司老板多为有背景但不懂技术靠关系的小老板，甲方有是些喜欢搞猫腻或者对管理软件不认可的企业主，这又使得这个行业正规化标准化难上加难，需求，开发，实施，维护每个环节都需要把关。所以在这个行业里能躬耕十年不得不说作者情商很高不浮躁，深谙管理软件行业的特色，管理和协调上下级与客户关系，仅有的资源能作为人尽其用，角色分工明确。书值得多看几遍，后半部分回答博客上的读者问题也非常有意思。

肿么说呢，仁者见仁，智者见智了。

哎呀呀，让我肿么说呢。。这本书作者很有悟性，能一点点的积累，做到更好。。但是，为虾米要自己一点点积累捏？。。一看就是没呆过大公司，大公司关于这种流程和工作模式的东东已经很成熟了，直接可以拿来借鉴，比从零开始自己摸索要方便多了。。

是一部经典之作，言辞很犀利，内容很充实！

之前在网上曾看过该书的片段，已经忘记曾经读的是什么内容。现在偶然遇到，立马入手。刚刚看完一点就已经彻底被作者实在质朴的语言打动，如果当初早一点把此书读完，也许自己的的职场之路会走的更顺畅。现在经历了该经历的一切之后再读此书，有一种非常强烈的相见恨晚的感觉。

《技术领导之路》译者余晟：别做光鲜行业的蠢苦力

全原文地址http://www.luanxiang.org/blog/archives/576.html我很小的时候，在外出差的父亲给我写信，说“玩也要动脑筋”，这真让我头疼：玩就是玩嘛，动脑筋，那肯定是跟学习有关的，这怎么能扯到一起呢？我百思不得其解，甚至去找外婆评理。父亲出差回来解释说：玩也要动脑筋，就是不要老停留在一个水平上，要想办法玩得更好，更有意思。于是我明白了，“动脑筋”不只是跟烦人的学习有关的，各种问题其实都可以“动脑筋”。这些年来，随着经历的增长，我越来越深刻地体会到当年父母的一片苦心，也体会到四处“开动脑筋”的重要性。去年，我有幸翻译了温伯格的《技术领导之路》，在书中，我遇见了同样的道理：尽管风格各有不同，解决问题的领导都有一个共同点：他们都相信，总有更好的办法（there’s always a better way）。这信念源自何处？伯特兰•罗素曾说，信念就是不需要证据的相信。尽管解决问题的领导可能是讲逻辑的，他们也不能用逻辑来证明信念。也许它源于他们之前的成功：聪明孩子能把坏事变成好事。这种成功强化了孩子对于思维的信念。以这种信念为依托，孩子就更可能想到更聪明的办法，解决下一个问题。熟能生巧，成功带来更大的成功，最终成就了解决问题的领导。看来，“努力把事情做得更好”的重要价值，是大家公认的。然而，努力践行这一点，也是非常有难度的，这一点，我深有体会。就拿我所从事的软件行业来说吧，工作中，我时常会有这样的想法：软件开发顶着朝阳产业的华盖，然而内部的规范性和秩序性实在不容乐观，甚至到了“粗陋”的地步，远远赶不上传统的工匠：设计随意、文档混乱、沟通缺乏、配合失当、效率低下、维护困难……（刘未鹏写过一篇有趣的文章《我们都是信息时代的远古人》，我看不妨借用这个标题：我们都是光鲜行业的蠢苦力）究其原因，一方面是软件开发本身的问题（须知，软件乃是纯粹依靠人类的智力，“凭空”构造出来的复杂系统）；另一方面，也与我们对自己工作的思考深度有关——即便软件开发本身是困难的，我们仍然能够开动脑筋，总结、反省、提高，一点点做得更好。可惜，长久以来，关于这些问题的论述，都被外国人所垄断。在中文世界里，“如何做好软件”，或许有许多人在思考，但经验的交流都还局限于口耳相传的方式，在知识的整体性、层次性和交流效率上，都很可惜。所以，当我看到《走出软件作坊》的时候，实在是大为惊喜。我手上这本书，是在面世签售的前一天晚上，博闻视点的周老师赠送的。赶回家已经是夜里两点来钟了，但捧起这本书就很难放下，书中不仅交代了许多困扰自己的问题，许多未曾接触过的问题，也能看得饶有兴致，并且为其中的某些观点、做法叫绝。看技术类的书籍，很久没有这种畅快的体验了，于是我想，这本书一定能吸引很多人的兴趣。果然，这本书面市之后，引发了大量的关注。无论评价如何，这些关注本身，就证明书已经挠到了软件开发的痒处（正如它的英文名：The Itch of Software Workshop），引发了大家的思考。我以为，针对中国软件行业的现状来说，这就已经是重要的价值了。《走出软件作坊》或许不是一本圣经，但它无愧于一个起点，为了走出作坊，我们需要这个起点。

不错的项目管理+自我管理

书摘：--------------有很多网友特奇怪我为什么能有时间来写博客，甚至还能接受网友的IM交流，问我是怎么做到的。他们都觉得自己每天忙死了，相信我作为部门的头公司的高层，估计更忙的不见人影，怎么回事呢？我总结了总结，在此给大家分享一下。首先，我每天的工作主要干什么？1每日接受开发组长报告给我的进度报告、功能需求设计报告，我来提出调整建议和指导。对于报告的问题，我会给出建议的处理方法。如果需要我出面动手解决，那我就出面。这是每日的例行事务，占了主要的时间。2处理手下员工间的流程配合问题，处理部门间的流程配合问题。一般都是根据现在出现的问题重申和强调过去的流程、职责。如果需要调整流程和职责，就把新的流程和职责重新定义清楚，并且观察几天的执行情况，直到每个人都按照新的流程走。3定期重新回顾这段时间公司业务的开展情况和面临的困难和未来的动态发展，以重新审视自己过去定义的产品战略，不断调整，以适合公司发展变化。根据产品发展战略的调整，然后调整内部每个人的职责和分工。4定期和每个员工在MSN中沟通或面对面沟通，了解他们现在的心理变化、薪水、公司发展看法、职业发展看法，以自己掌握的信息和自己的经验，对每个员工提出指导建议和方向建议。对于没有个人目标的员工，和他一起交流制定一个可见时间内他可以达到的目标。如程序员，我会提出，在6个月内，让你的代码变的比现在稳定，至少要达到你自己心中的满意的稳定程度。然后，我会针对这个目标，时常提醒他，不要让他忘记这个目标，鼓励他一定能达到这个目标。不提醒，人就会渐渐忘记了自己上个月才确定好的目标，甚至由于当前的诱惑和问题，对自己定的目标发生了怀疑或不感兴趣，就失去了目标。5对于每个员工所干的工作，我也会根据他最近出现的问题，及时进行能力方法、技巧的指导。如你应该这样做会更好。对于如何写稳定的代码、高性能的代码等等，对于如何测试找到更深层次的问题等等，都有技巧的指导，而且都是结合他现在所遇到的问题和手头的工作。我不会专门拿出一段时间来专门培训。我都是在日常工作中不断指导，把培训都化在了每日的工作中，尽量做到润物细无声。对于一些新手程序员，我拒绝回答他们的技术问题，我通常会说：把你们报错的那个信息原模原样输入到百度中，你就会找到答案。你也可以查询微软、SUN的联机手册，或者你到CSDN上问、搜索。6我还会平时看IT技术网站、行业网站，思考客户行业发展、IT技术发展。我来研究软件中的管理思想、管理模型、管理业务流程优化、考核评价模型。管理软件、数据分析咨询业务、市场推广，很需要这些模型和文章。每当我研究出一个管理模型，我就会写文章在内部发邮件，给公司老板、高层、员工推广。7偶尔我会跟着实施、咨询团队到客户现场，体会真实的客户应用，和客户面对面交流，交流现在的问题，交流目前的困境和焦虑，交流未来的发展看法，体会客户真实的想法、思考思路，体会客户的真实应用水平。这就是我大概的每日工作内容。我能把时间省出来，最重要是以下几点方法：1由于我经常性思考产品发展战略、盈利模式、管理模型、工作职责、流程制度，所以公司的发展一般都是按照计划和既定流程走的。很多公司也不知道自己做什么才能赚钱，就东一头西一头拉项目，所以也不会有产品发展战略，而一般老板也是销售出身，想不透软件产品如何发展，而技术总监呢，又不懂这些，可能就是个技术牛人而已，甚至连技术牛人都算不上，只能算个一帮人的头儿。我们过去也是没有产品发展战略，但我是职业经理人，我不能让公司东一头西一头的随波逐流，所以我常常思考公司现状，从公司的现在的资源和优势和困境来找一条产品发展路线。就这样不断思考不断尝试不断执行，渐渐的，在我空降公司3年后才找到了现在的清晰的切实可行的产品发展战略。有了切实可行的产品发展战略，随之就有稳定的工作流程与职责，每个人就有了稳定的计划和工作任务。变化少了，自然也就不会老救火了。很多人说忙，就是老出异常，老救火，公司没有稳定清晰的盈利模式，一直处于抓项目的状态，每个项目都没有连贯性，当然也就不需要流程，也不需要职责，有了项目大家一窝蜂加班，没有项目大家闲的要死，这样的状态，即使有流程和职责也是被废掉，根本没有用，执行不了，项目一来就废掉了。2我不会去处理事情。我总是授人以渔。我一直强调方法和流程。如果一发现新异常，没有流程和职责和明确的人负责，我就会立即把这些都补齐，让明确的人去处理，而且有明确的处理流程。如果明确的人没有方法和头绪，我会指导他。但我从不会亲自做。3就是因为有稳定的模式和流程和员工岗位，我就从细节中抽了出来。需求调研、功能设计，有项目经理。开发有开发组长和程序员，测试有测试员、文档有文案人员，实施有实施人员，支持有支持人员，每个事都有专门的处理人员，而且有明确的流程协作。由于我的平时不断的指导，还有他们每日都处理自己专门的事情，所以他们对自己负责的事情越来越经验多，处理起来很快，质量也高。我看到很多公司业务不固定不稳定，人经常被抽调来抽调去，当然经验积累就不深入不专业，工作就不胜任，干活质量和效率都不高。4我这个人很专。我清楚的知道自己的优点和缺点，自己想要走的路。所以我十年，一直在开发岗位，而不是去做项目经理，去做实施，去做售前，去做市场，去做销售等等。很多人尝试了不少工作，但我没有。我知道自己，所以我总是把自己很优秀的方面练的更加优秀，这样我的缺点就非常明显，因为我没有去想着补齐我的缺点，我根本就没有为我的缺点投入任何精力。所以我这个人看起来很简单，同事们都能很容易看出我的优点和缺点，而且我的优点和突出。所以对于老板、对于其它同级同事，某件事需要不需要我的参与，需要不需要我做，大家都很明白。所以，我不擅长的事情从来不找我。这样，我也省去了很多乱七八糟的事情，就有了很多的时间。不少人这个也能干那个也能干，但都干不精，这样的人最容易被别人抽调来抽调去，当然就没有时间了。我只能干很窄的一个领域，所以我在这个领域精进的很快很高很专业，所以我总是能当这个领域的管理者。5我是个公司赚钱导向的人。我研发产品，率领研发团队，我一直贯彻这样的思路，所以整个研发团队全是这个想法。所以，很多事，一拿这个准则来衡量，这个事到底值不值得做就很清楚了。所以，省掉了不少事。许多人不知道自己要做一个什么产品，只要别人说的有道理没有办法回绝就做，到头来这个软件就成了一个四不像，看着什么功能都有，但这个软件的竞争力在哪里，它的核心模型是什么，很多人回答不出来了。我对产品目标，每个阶段的目标，产品的核心竞争力，我因为有清晰的产品发展战略，所以我都能把这些要素控制的很好。到底做不做，看是否符合利益和当前阶段的目标。6我这个人不是一个追求完美的人。只要不影响我的任务目标，即使出点小问题小异常，我也不爱管不爱问，就这样过去了。世界上很多事情，其实要成功，只有那么关键的几个点，我深刻的理解是哪几个点。于是我就把控这几个点。只要不是这几个点出现的问题，我都大事化小，小事化了。所以在我手下做事，干的比较轻松，还能达到目标。虽然在有些追求完美的人的眼里看来，每件事情都做的不好。但钱也赚到了，事也按客户要求的进度和质量完成了，而且后续的客户单子也来了，又没有影响未来的客户合同延续。一切关键因素都不影响，我何必花成本和代价去追求完美，让我的人累的半死呢？7我有个我自己的每日任务列表。我每天要做什么事情，我都随时记录下来，然后一条条的做，一条条的消。我看着不断有任务变灰，就很开心。我清楚的知道我每天要做什么事。8我要求手下在每天下班前一个小时把今天的工作进展发过来。然后我一一审阅，给些建议。这样，他们明天该怎么做，该做什么，今天遇到的问题该怎么解决，在他们下班前就知道了。这样，他们明天一来了就立即动手，根本不耽误时间，所以工作效率很好。9有的员工跟我絮絮叨叨讲了很多，反映他所遇到的问题。我听完后往往第一个校验的就是，你到底要达到什么目的。很多员工被反问后，是啊，我到底要达到什么目的。最后一重新审视自己的问题，很快就把问题简化了，问题的症结就找到了，当然解决也就很快了。甚至，弄清楚了目的，发现问题根本不是问题，根本无须解决。省了不少功夫。10我不喜欢员工像讲故事一样来龙去脉的报告。我总是强调，要1、2、3，这样来。而且你一次报告，不要报告太多的问题，人不应该关注那么多问题。关注多了，就根本理不清，所以也就解决不了问题。先要把自己的头脑清醒了，就焦点关注在前三个问题。等前三个问题解决了，再思考以后的。有些员工向我报告问题，总是拔起萝卜带出泥，一个问题的描述往往会引入另外的问题，然后问题串问题，跟糖葫芦一样。我总是让他打住，就说那是另外一个问题，咱们现在先别管它，咱们先把你现在说的这个问题说清楚解决完，再处理另外一个问题。11咨询有个方法，就是四象限。在时间管理中也有这个方法，重要且紧急，重要不紧急，紧急不重要，紧急重要。很多人其实是分不清楚这个事情是重要不重要的。我就拿我的目标和赚钱为导向来校验，不赚钱，也不影响未来赚钱，也不影响我当前核心目标，这个事情就不重要。既然事情不重要，那它怎么会紧急呢。不重要，就认为它是紧急的。就让大事化小、小事化了。很多事情，随着时间的消磨，也就那样了。你不去处理它，也就过去了，根本对未来没啥影响。12有时我指导训练手下员工，但员工听不懂，当然也不会按照我的方法来做。不少管理者见到这种情况，非常生气，还不如自己亲自动手做，本来简单的事情被员工搞了两天搞不定，如果是自己，两个小时就能搞定。但作为管理者，千万不要自己这么做。越这样，越是欲速则不达。每次都是自己亲为亲力，员工闲死，自己累死。我不怕员工做事做不好，关键点出了异常我可能会亲自处理，其他我都能过则过，而一件事情的关键点往往就是两三个。所以，一次做不好，咱们其他的事情我继续指导、重复指导。一次听不懂，我继续在下一件事情方法上指导，直到员工自己也能做的很好。时间，真是一个很奇妙的东西。它能自然改变很多东西。有时候你讲了许多员工也听不懂，时间长了，他也就明白了。不是不到，是时候未到。就是这个道理。13我希望记笔记，不管看书，还是做事，想到一个很好的点就立即记下来。而且我还经常回顾自己的这些记录，把它们尽量整理成体系和方法，让彼此关联起来。所以我解决问题思考问题的时候，总是有很多参考。而不是从头想起，也不是一遇到什么事情还得重复寻找资料。我这个人由于太专，所以关注的东西也不多。就看自己关注的东西，所以范围窄。许多人没有重点，什么热就看什么，而且积累了一大堆资料，反而后来自己都不看。而我，由于关注的少，所以看的东西自然比别人范围小，看的少也就看的精，而且还定期整理自己的笔记和资料，发现过时了就删除掉，保留下自己持续关注的资料。我发现，不少人有移动硬盘，里面放了很多资料，但真要做事反而一点资料都找不到，跟没有资料一样。14我喜欢看书和思考问题。过去坐地铁上下班，我都拿本书拿支笔，随时读书和记笔记。一天不读书不总结就觉得空空的，即使上个厕所也要带本书。很多工作中的管理方法很问题解决思路都是这样想出来的，在工作时间就赶快去，节省了不少工作时间。有的人记忆力还不好，还没有做笔记的习惯，还想问我有什么阅读理解的好方法？我的父亲常说：好记忆不如有个烂笔头。其实做笔记不仅仅是个做笔记这么简单的过程，而是在你写字的时候你就会思考揣摩思考，本来你认为很不错的一段文字准备记录下来，在记的过程中你就会想到自己的问题是否能有所借鉴，在记的过程中你就会联想其他同类的信息对比，总结出共性和差异点，在记的过程中你就会发现这段话说的比较片面不像你刚看的那么激动。很多人做不好自己时间管理，就是想做，但只是一个想法，真正做，就觉得这样做太累了，就放弃了。15我常笑说我是个生活不能自理的人。许多平时工作中的例行事情，我都交给我的团队中的文案女孩处理了。她就相当于我的一个兼职文秘助理一样，帮我处理了许多行政事务。我要去给客户讲某个产品，我给她讲好思路和客户爱听的重点，她就能把方案处理的符合我明天的讲解。比如我要出差，订票订宾馆只要和她讲一下，她就处理了。而且她还会告诉我怎么去那家宾馆，地址、路线图、联系电话都有。我很多事情，都是能不用我处理就不要我处理，我都分配给下属了。16我从小爱看书，但是家里也没有多少钱买书。我的一个亲戚家里有许多书，但我不能经常去。但只要去了，我就赶快看书。为了看的多，就渐渐养成了能很快把握书中的重点和思路的方法，也养成了如何快速鉴别手中的这本书对自己到底有没有用的方法。所以，现在工作也是，能很快读书，也能很快总结理出思路。对于员工报告的问题，也能很快找到重点和关键。这个性格也是我能留出时间的原因之一。但这个性格很少人有，这个是从小的影响，无法复制，所以我也就放到了最后。

他们需要一个产品经理

这是一本很草根的书，虽然现在“草根”这个词被用烂了甚至都成贬义词了，但是这本书确实是作者的真实工作经历，很有实战的意味。因为这本书脱胎于作者的博客文章，所以体系上并没有很强的前后关联性，基本上所有的博客文章合辑出的书问题就是没有传统意义上书籍的前后逻辑性和联系性，但是这本书仍然获得如此高的分，可见内容还是很有价值。作者阿朱一直在一家“三五个人，十来条枪”的软件公司工作，从地秤一直做到了CTO的位置，书中内容基本都是作者日常工作中自己要面对的各种问题，以及平常和网友讨论的各种技术管理问题等。不得不说，这些草根经验真的很实在，创建或者运营一家小软件公司的方方面面的问题，作者都在书中一一写道，并且最后都给出了解决办法。可以说这是一本创业者/公司老板的必读书籍，书中的内容很有可能在每个企业的成长过程中都能会碰到，这本指南或者实战手册至少能给你指明努力的方向。这本书不像那种成功学著作之类的鸡血书籍，完全都是最最现实最最底层最最经典的问题，“为什么老板不给我加工资”“为什么别人能升职我却不行”“产品质量和公司销售额有啥关系”。作者甚至针对自己从事的行业，分别对测试，文案，项目经理，开发，实施人员，客服人员一一都写了“成长攻略”，很体贴很实在的文章，推荐所有相关人员都去读一下，尤其是程序员朋友们。跳转回来，因为我自己是产品经理，所以书看着看着我就有一种越来越强烈的感觉：“这个公司缺少一个产品经理！”。真的，这个公司缺少一个产品经理，一个几乎可以解决大部分问题的产品经理：开发人员不知道功能到底是什么，不知道产品长什么样子；界面按钮颜色不对，位置偏移；项目问题太多，是开发新功能还是处理原有产品的bug；开发人员与设计师沟通起来效率太低；测试人员和开发人员关于bug的争论不断；用户需求的收集管理，每个版本的规划立项和产品的长远规划以及每一代产品的更迭时机等等。如果是个产品经理的同行看见这些问题，肯定会宛然一笑。确实，这些工作在互联网公司，是产品经理的主要甚至是绝大部分的工作内容。设计产品功能，沟通不同岗位的同时，协调资源问题以及产品的版本规划问题，几乎构成了日常功能内容。这家公司缺少一个产品经理。我看了一下书籍的出版时间是2009年1月份，而作者草稿形成时间可能在2008年，而博客文章可能写的更早。我去作者的博客看了一圈，确实，这本书的主体形成于2008年。而且作者工作于一家比较传统的软件公司，当时几乎还没有或者说很少有产品经理这个职位，而却通过google的时间隧道可以发现，2008年的产品经理还是仅仅局限于制造业和传统产业，几乎都很少发现互联网企业的产品经理消息，更不用说软件行业。但是我上文讲到的问题，是一直存在的。不管是2008年还是2011年，而且也确实是作者阿朱的主要工作内容。除此之外，作者还要兼任技术经理，CTO一般还是会不由自如的对技术开发团队投入更多精力的。按照目前一般互联网公司架构，技术经理和产品经理是一个项目/产品不可或缺的部分，而项目经理则一般由前面两者之一兼任，这个主要看项目性质以及企业的文化等原因。这样才能保证产品设计规划以及项目的开发测试相对隔离，不会出现两者混杂在一起甚至需要开发人员收集需求的乱局。每个人负责自己的工作然后通过共同合作将工作分隔，尽量保证独立性，这样每个人都能发挥自己的长处而集中处理手里的工作，效率要比每个人都身兼数职要高得多。作为一个产品经理，读书过程中这种揪心感觉很明显，因为作者不断的在各种乱局中抽丝剥茧的找到问题本质然后针对解决，然而依然为作者的这样工作感到累心，我经常在看书的过程中叹息“招个产品经理多好！”。呵呵，当然我们这是后人的眼光看待“历史”。在2008年，作者阿朱其实就已经肩负起三个经理的职责，而且还是在一家三五条枪的小公司。这只能说作者确实能力比较强悍，能够通过自己的能力和不断的学习来完成如此众多而又复杂的工作，非一般人能够搞定的。作者如果能够看到这篇文章，希望他能了解一下互联网公司的产品经理，然后招聘一个有执行力的产品经理，从而将自己彻底抽身为CTO和项目经理。最后，还是要说的是，小公司确实资源比较稀缺，很多资源都要比大公司紧张的多。人不够，预算不够，时间不够，但是作者使用偏方也好，使用正道也好，总是能用各种方法解决一个个问题。所谓逢山开路，遇水搭桥，无论什么问题，出现了就想尽各种办法却解决，不要抱怨，不要逃避，只要一群人想办法总是能解决，而且结果也证明问题总有解决办法，关键在于是否有解决的动力和决心。看到这想起我自己经常给boss回复“这事干不来，资源明显不够呀”就觉得汗颜，个人工作缺少这种执着和坚毅，往往先入为主的主观上就不想解决困难问题，那么这问题就永远是问题，没有了解决的希望和可能。最后的小结是，所有与软件和互联网相关的人士都应该读一读这本书，对比作者的环境和解决方法来看看自己目前的问题，可能会很大的提升自己的成长。http://viecho.com/post/165.html

现身说法

看此书，就好像有种看到作者在现身说法的感觉！里面的案例真实，也有表格、数据作为补充，令人不得不服！是一本管理方面的好书！

实践+思考

诙谐的文字, 辩证的思维. 阿朱给我们描绘出一幅中国本土软件突重围,求生存的壮丽场面. 既是实践的结晶, 又闪烁着思考的光芒. 是一本不可多得的好书.

支付宝冯大辉妙评：认清现实，积极打造“老板赚钱、下属满意的团队文化”

http://www.dbanotes.net/review/the_itch_of_software_workshop.html如何走出软件作坊记得看过一个数据，中国软件企业 50人以下的公司数量达到 70% 以上，规模普遍偏小。我想这 70% 中至少有 80% 还是小作坊的研发模式，"三五个人，十来条枪"，有一部分企业偏居一隅，远离信息技术发达城市，摸索着发展团队，其中甘苦谁人能知? 阿朱这本《走出软件作坊》，以切肤之痛，现身说法，是一件很有价值的事情。当然，此书未必能解决很多公司的问题(也没有任何书能做到这样)，但至少能引起多数人共鸣，引发大家进一步思考与探讨，少走弯路，这正是当下缺少的。书店里管理学图书汗牛充栋，有的告诉你把信送给加西亚，有的告诉你不要有什么借口，还有的说是办法比问题多...... BULLSHIT! 凡此种种，多数是管理者写给管理者的洗脑心灵鸡汤，此类图书，多半中了成功学的流毒，读后三天如打了鸡血兴奋，三天之后打回原形。而阿朱毕竟是过过苦日子的，说白了，是做过咱技术民工的，久病成医，现身说法，疗效尤佳。打造软件团队，或许很多人以微软、IBM 等巨擘为师，但文化隔阂在哪里摆着，差之毫厘，谬以千里；也有人从实践中来，黑猫白猫，抓到耗子才是好猫，我想阿朱属于后者。有的时候，看了阿朱说的话，挺生气，比如说技术人员与老板的关系，"老板把你提上来就是为了让你给他赚更多的钱..." ，也挺让人绝望，但这也是实话，早点认清了这一点，摆正心态，积极面对，反而更有利于把自己全身心投入，从而打造一个老板赚钱、下属满意的团队文化。否则一味抱怨，也不会解决问题，也就失去了改造团队的机会。最近，自己也多有反思这样的事情，一声叹息。最后，从这本书里学到比较多的两个章节是关于"售前经理"和"演示方法"(记得在北京 SD 2.0 大会的时候雷军也特地提到了这个章节)。看过很多所谓大公司的售前做演示，出色的不多，糟糕的倒是看到不少。阿朱这两个章节的内容可以拿去给这些大公司做一下培训。希望阅读这本书的朋友都能从此书受益，让自己的团队不再山寨，顺利走出软件作坊。也期待阿朱同学能通过网络和大家分享更多的心得。

值得我们反省

不得不说我是一个比较慵懒的人，这本书我看了大概有1个月左右才看完。整本书的的介绍什么我就不说了，网上一搜一大把。我只想说一下我看完这本书的感觉。本书洋洋洒洒下去有几百页下去，看起来很厚实的一本书，翻起来却很快，让人有些欲罢不能的感觉。虽然作者已经很努力以案例的形式来介绍，但是正如作者所说，软件开发本来就是一个整体，所以很多章节还是有联系的（这点需要看到最后才能明白）。即便如此，每章的内容也足以让我们反省半天，不仅仅是所说的问题以及方法，更加应该反问自己一句“如果我遇到这种情况，我会怎么处理？”或者“当时我们公司遇到这种情况，如果按照这种方法处理的话结局会是怎么样？”这本书真的非常适合这样子去看，边看边想，思考中不断假设如何处理。设身处地的思考一下你就会发现，原来这些土方法在中国这个国度还真的实用~！看完整本书，你真的要我说一下到底有什么新鲜东西？嘿嘿，我还真不知道。因为所有的问题，我们或多或少都在开发或者工作中遇到过，所以在阿朱说这些问题的时候我们更加能感同身受，我们就更加渴望知道作者的处理方法。就像作者本人说的那样“有过相同经历的人才会互相信任”，其实我觉得更确切的应该是“遇到过相同问题的时候，两个人才能引起共鸣，才能更加渴望知道解决的办法。”原先对技术有一些偏执或者执着，现在看了书之后，感觉有些觉醒的意思——是啊，书中也说了“我们不是研究所，我们是公司。我们的东西只需要满足我们的需求就好了。”我再多说一句“在满足需求的时候也不要忘记了做一定的技术储备才不会很快被竞争对手赶超或者抄袭！”下面说几个我记忆比较深刻的话1. 你做事的出发点一定要是帮老板赚钱，否则永远不可能得到老板的支持！2. 公司里面总有自己的特殊情况、利益团队。老板或者职业经理人需要去平衡这种利益团队内部的争斗。这才是公司的发展。3. 需求分析的方法有很多，但是需要深入到公司内部各个部门的相互冲突和利益之下，才能很好的了解需求。4. 做事需要有资源的人支持你。在公司这个人一般都是老板！老板不首肯的事情，你永远做不成！！5. 项目或者产品不可能一次性完善，这一版需要收集用户的不满意的地方，在下一版中修正！所以不要一开始追求完美，否则会很累！6. 永远不要和老板争权！如果可以取得信任，会自动放权，否则都是扯淡！7. 抓住自己的核心竞争力8. 技术人员发展路线有很多，项目主管、CTO等，但是需要结合自身的能力来进行选择。9. 公司中，了解业务模型都是最重要的！10. 演示中不仅仅是PPT要注意，还需要注意自己的仪表、周围环境等因素对演讲或者演示的影响！11. 明白自己的价值，不要老是说自己的价值没有被老板发现！要明白自己到底创造了多少的价值！公司的业绩到底是你的产品核心竞争力来的还是老板的人际关系来的？这都要搞明白！

读《走出软件作坊》有感

第一次看到这个书的副标题《三五个人十来条枪，如何成为开发正规军》，心里就觉的这是一本十足的IT小说书，但是读了几段之后，就放不下手了，很久没有看书看到欲罢不能的境地了，所以晚上一有空就读上几章，当然也不放过在等车和在轻轨上捧读的那一点时间，因为是部门公共书籍，所以看第一遍的时候也没有写下什么笔记，后面看第2、3遍的时候，顺便写了一些提纲。其实不同的时间不同的心情看这本书，你会发现每看一遍都会有新的体会和思考。那么接下来就有了下面一点读书心得，与大家一起分享一下：(一共十段)㈠. 团队配合【p27】我们也应该属于作者以前身处的那种三五个人，十来条枪，旧系统需要维护，新系统也要上线，上有不停的变更，下有客户的意见的情况。虽然我们的团队文化不很明晰，但是我们还是一个很好的团队，那么游击队如何变为兄弟连，如何再变为正规军，那么这个就是要讲究一个团队配合，做到心往一处想，劲往一处使。至于团队人员的配置上，作者分析下来 除了需要程序员外 还至少需要这么几类人1、Help文档编写人员2、搞内部培训的人3、测试人员4、设计文档编写人员5、核心代码和公共代码编写人员6、比客服更懂软件的支持人员如果再压缩一下，1和2可以是一个人 3和6可以是一个人 4和5可以是一个人？作者提出一个观点，“不允许开发团队出现多种技术。多种技术，会让团队成本升高，每个人都得会多种技术”【p36】的确对一个技术(简单举例：java / c# )只有经常用、吃透摸透，才可能提高开发速度和质量，俗话说"拳不离手、曲不离口"应该就是这个道理，技术运用的越多可能掌握的就深度不够，熟练度也不达不到，那么怎么提高开发速度和质量？说到开发速度，不仅对于技术，就是工具的选择也是这样，俗话说”磨刀不误砍柴工“，如果拿一个不熟悉或者不称手的工具，即使很熟悉这个技术，也无法提速。例如我们几年前用Jbuilder作为java开发平台，后来转到eclipse开发平台上，现在利用集成了CVS的eclipse，做开发的时候关注点不会再放在工具怎么用、快捷键是什么的问题上了，可以更专注的解决设计开发的核心问题上。不过如果再让我用回Jbuilder，我可能又要适应一段时间，那么可以想象对比一下，这个效率是如何的。使用工具尚且如此，何况在不同的技术上呢？作者在设计方面使用了“PPT+WORD+脑图+EXCEL”的描述方法【p38】我也谈一下我的感受，作者这里说的四个工具，当然也不光光只能用在设计方面，平日里都可以拿出来晒晒。三个是Office套件工具，的确很好很强大，作者说到用PPT做界面窗口，我觉的不太顺手，可能作者是做C/S架构软件的，我们这里全都做的是B/S架构的，界面都是WEB，如果话原型，用HTML表现更快更好用。其实后面作者也谈到了这一点，呵呵【p91】word就不说了。excel我觉得深入学习还是非常有必要的，如果仅仅把excel看做是表格工具，那word就可以搞定了。excel的计算和可编程功能可以大大提高我们的工作效率，我现在家里记账就使用的一个台湾人基于excel做的电子帐簿，用起来非常舒服第4个是脑图 ，是一个思考问题的方法，近来越来越觉的很实用，特别方便把脑子里的东西理顺，严重推荐。㈡. 老系统维护【p71】作者也说把这个主题放在过程管理篇的第一部分，因为现在很多程序员每天干的工作，不是在开发新系统，而是在维护老系统。维护老系统，不断继承包袱，不断细心剖析问题，剥茧抽丝理清思路，不断改进，才能渐渐从恶性循环走向良性循环，才能把一套人见人厌的系统变个样，当然不要忘记考虑一下成本和代价。作者提了8项建议，结合我们各类旧系统，我把它精简一下，对于老系统有以下几点：1、表单输入、存储、显示、打印必须一致。2、追加新需求功能代码，分离特殊业务和正常业务的功能代码。不要搅在一起，本来就迷糊的代码，更让人难懂。3、在维护时，觉得程序很烂，不能抱着破罐子破摔的思想，你心态平和一点，修改代码可能还顺利一点。4、避免编写大函数。5、如果某个系统一没文档二没注释，怎么维护？的确不要说设计文档、帮助说明，就是代码都可能没有注释或者还有垃圾在里面，还好能从页面上看到数据库字段的定义，并且老系统流程都不复杂。新增加的代码，本来看不懂现在看懂的代码，应该增加上必要的注释，否则下次再来搞一遍？㈢. 设计文档编写方法【p127】作者对于企业管理软件开发过程中的文档是这样的：需求调研-》需求分析说明书-》功能点文档-》按照功能进行优先级标识（3级即3个阶段）每个功能点文档由一个excel文档来详细描述，这个excel中包括了：Sheet1 版本信息Sheet2 页面布局Sheet3 字段说明 包括：默认值、不可为空、输入约束、主键唯一、输入长度、参照录入等Sheet4 如果有必要，放业务流程图Sheet5 非功能性需求等这个excel完工后，测试人员介入校验。ok了之后，才涉及到具体的实现说明。公共代码人员整理出数据结构【p132】，并在之上建立视图。然后编写每个功能的增删改查的操作文档，并补充到excel的 sheet6中下面就定义开发计划和公共开发人员的任务列表。综上所述，公共开发与业务开发在并行，设计编写和功能开发在并行，设计和设计测试在并行，代码和代码测试在并行。让我们用平和的心态看待编写文档，不是为了正规才编写文档，而是为了用而写。当然，我觉我们现在不是要砍掉什么多余文档，而是要增加必要环节的关键文档，例如：功能点描述文档，关键页面布局（或页面原型），开发设计文档。其实这也是我们要开发的主要内容，先讨论明确了，后面开发时候可以减少点返工或会不一致的地方。㈣. 开发团队练兵【p135】3新的情况是指“新技术、新团队、新产品 ”，首先避免这3种情况同时出现，三新同时出现风险太大，特别是避免采用新技术作为基础技术。其中对于学习新技术，作者提出了应该先“学习基于新技术的第三方的国外开源源代码”。这个观点的确很实在，干嘛要学习新技术？不就是为了用嘛，别人的实际应用不是最好的example了吗？比官方的DEMO还要贴近实际。但问题是找的到，然后是看得懂。㈤. 企业业务开发平台架构【p141】如果有个稳定的，易用的底层平台，那对开发会带来很大帮助，作者总结的关键特性总结好像不太适合我们B/S开发，我也想了一下，B/S下我们需要1、可以快速开发(文档化，可查可用)2、稳定（需要不断历练）3、日志记录4、通讯功能5、PDF打印框架6、页面通用控件7、页面CSS样式8、常用javascript库（UI特效、前台验证）9、安全性控制10、简单可用的RBAC等等吧㈥. 代码那些事【p149】这章中作者提到的新手常出的2个错误，令我印象深刻：一个是修改bug问题，修改bug，的确有时是非常令人头疼的事情，特别是缺少设计的文档，缺少必要注释或者程序逻辑复杂，或别人写的程序段中古怪的句法。bug好似拔萝卜，连根又带一把泥的，怎么办？我常用的方法是排除法，将各个吃不准的代码块隔离，优先找到出现bug的直接原因，然后看看这个问题如何修改，是否修改后会影响到其他地方。另外一个，我也能非常体会得到作者当时误操作后的感受，感同身受啊，曾经我也有一次数据库误操作，由于sql控制台中开发和正式都连接着，结果本意是想删除开发中的数据库，结果竟然删掉了正式数据库，当然我也是一身冷汗，万幸这个数据库不是当年度的正在使用和业务操作的数据库，我立即将它回复到最新备份，虽然是很久以前的事情，但是促使我养成了几个习惯，1、除非是真的要操作正式数据库，否则只用Select权限，宁愿让数据库提示我没有权限进行更新或删除操作；2、删除数据库前先脱机，等确定一段时间后删除3、开发数据库的库名不与正式库名相同；4、执行更新删除前检查确认无误，特别是where查询条件子句是否正确㈦. 软件测试【p157】关于测试，开发人员首先自己承担测试工作，冒烟测试？代码互查？这是否是浪费？违反开发人员的”二八法则“？降低了开发人员效率？可能不一定，测试人员找到case后，还是要交给开发人员，如果不是像界面文字那种简单易见的错误外，开发人员要沟通、查找、修改、自测、再回归测试，反而成本更高。因为其实最后还是需要开发人员找出问题，排除错误，为什么不能开发人员先进行测试呢。无法测试？开发人员首先拿测试人员的case进行自测是否全部pass，这样可以刷掉第一轮测试的大量bug，再者也顺便复查了一下case的是否完备如果开发人员要问我测试人员做什么？我说0、测试、把关、QA1、根据需求（如果没有需求，就需要参与开发人员功能开发讨论的结论）进行编写测试case2、编写FAQ3、发布正式系统4、当系统稳定后，分析是否有必要编写自动化测试脚本时编写和测试自动化测试脚本，如用QTP工具5、非功能性测试，系统调优6、系统技术支持或DEMO和培训7、bug分析和归类上面太理想化，可以不看。开发测试比例 1：3，现在主流B/S架构下开发测试人员配置比例1：1？我觉的更多的软件工程学上的东西，太理论化，没有考虑到不同系统和条件下的关系，要不可能更多的偏向于单机时代，因为大家都知道那时候都是卖盒子软件的，一旦刻好盘那么再出软件bug问题，特别是严重问题，那就变成废品，成本损失代价很高，所以测试产品质量要求非常严格。现在是B/S时代，比C/S更进一步了，不用全部OK才上线，现在可以先上一部分功能，再逐步扩展和完善功能另外bug管理系统可以有多个用途：除了bug管理外还可能提供需求管理和任务管理。㈧. PPT 和演示的方法 【p179】作者最如何做一个专业的PPT文档和如何做演示写的非常朴实。其他不说，我最认同的一点就是，PPT就是你思路的大纲，不要密密麻麻的一堆又一堆文字。如果怕自己忘记可以把演讲稿放大一点字体打印出来放在laptop边上看看。不过我记得我第一次的时候，也想这么干，不过秦老师就说，将的时候一定要脱稿，否则会老是惦记着这张纸，老是怕漏讲什么，呵呵，看来仁者见仁，智者见智了吧。㈨. 客服支持 【p241】这章让我想起去年服务人员病了的那段日子，我的开发同事去替代帮助他服务，去前端呆上一段日可以体会到一些在幕后设计开发测试人员所体会不到东西，了解到一些需求中不可能提及的业务实际？呵呵，其实也可以选在课题申报截止的那天，开发或测试人员轮流去隔壁网站编辑部帮半天工，也一定可以体会到不少东西吧？㈩. 自我时间管理【p385】这章是全书对我最有价值的地方，因为首先书中大多案例以企业管理软件信息化为背景，以公司盈利最大化为目标，再者作者已公司管理者的角度待人处事和提出解决企业问题的方法，所以不可能按照他的方法照搬硬套。但是这章却不同，这种是将个人管理，对每个人在每个阶段都有参考意义。如果用一句话浓缩一下，我觉得就是“二八法则”，把有限的时间做最有价值的事情上去。上面的一些东西只是我在阅读前后的几点感受和扩展思考，可能和现实状况不搭边，也可能会适得其反。书中大多讲的是一些“土"方法，都是作者长期以来工作中的一些经验和思考总结，没有大段的枯燥理论带你走出软件作坊，而是给你一种思路，思考问题的方法，一种出路，让你自然而然的走出软件作坊。看完这本书后，作者不会代替你思考，但你在思考了吗？

可以让人少走弯路的书

又看了一会儿，我觉得对于有心改善一下公司当前研发状况的人很有价值。问题与问题环环相扣，不用“公司的钱，客户的项目，自己的时间”来重复错误——这应该是这本书对我最重要作用。PS:阅读的时候不要太专注了，我本来是准备0点之前休息的，看到现在，而且还特地跑上来写书评....

走出自己心中的作坊

看了前十页就感觉此书符合自己的口味，讲到的一些实例或多或少的遇到过！ 深有感触，也解决了自己的疑惑，改善了自己的观点。就如此书序言所说的每个人都以为被人碗里的肉香 ，其实家家都有难念的经，沉下心下来，这个后面的---------------国内外的环境土壤不一致，整天30岁就over的论调，然后国内公司完全是施舍的态度，管理方面又是各有各的方法！老外的不能完全适应，反而会适得其反！此书讲的我们会慢慢的体会到，所以要读此书，知道自己的职业路程中，遇到什么事，要怎么处理，以后的路如何规划！------------------CTO

刚才给一个网友回邮件，挺好的，对大家都有效

主动、最大化的做事、解决问题，用最短的时间，做最好的质量。这是人的成功的第一步。第二步，就是在团队中要通过积极做事，帮助别人做事，达到好的人缘，这是人的成功的第二步。第三步，有敏锐的商业感觉，怎么做最赚钱，做什么最赚钱，怎么做能够使客户最赚钱，客户目前还有什么问题，如何最好的解决这个问题，这是成功的第三步。OK，就这三步，和技术无关，但是成功的关键。

公共代码开发员-软件作坊里的高人

完整内容在http://blog.csdn.net/qinzhihu/archive/2009/01/13/3766423.aspx在这里我们假设一个最典型的作坊模型，按照阿朱的《走出软件作坊》里所述，我们可以为一个项目配置如下人员。一个研发部，一名研发部经理，1-2名开发人员，一名项目经理，一名公共代码开发人员，一名测试，一名文案。在这个配置里，各个人员的角色和任务分配，大家大概可以推测。下面我重点强调一下公共代码开发人员的职责。有一个大家都了解的事实是，在一家小型公司里，项目做成一槽烂的情况非常普遍，大部头的书，大家读的未必少，可是凡是什么东西，在这一个小公司里，就觉得处处掣肘，什么都实施不起来。看人家书上写的是天花乱坠，跑到自己公司里真正一实践，才发现那不过是镜中花。一槽烂的情况是因为大家基本都不怎么写注释和文档，不管你强调多少遍，喊的声嘶力竭，到最后把文档和注释给你写好的人，也是屈指可数。为什么呢？难道程序员都是笨蛋？难道每个程序员都是混子，都不想写好？按概率论来说，如果你觉得大家都是笨蛋，那大家是笨蛋的概率就很小了，最有可能是的你自己是个笨蛋。当你做到程序员的位置，从程序员的角度想一想，实际做一做，会发现真的很难。小公司项目的一个典型特点就是着急，催，催。而且实际上小公司里的大部分程序员水平都不是那么高，最起码没有项目经理想象的那么高。实际情况是小公司里员工流动非常频繁，能把员工留住的好的小公司十分稀少。而在这频繁的流动中，小公司招聘的人大部分还是很初级的一些程序员，有不少是刚刚毕业的学生，这些学生一出门来，没有培训，没有培养，上来就是干项目，因为小公司也从来不花钱培训这些人。而这些程序员因为经验少，底子薄，写代码是不可能中规中炬，非常严谨的。最多的情况是，先紧着完成任务，其他的废话不要多说，先把功能做起来，让那按钮能按，让那表单能提交。说一句实在的话，这么短的时间里，能把功能搞出来是最重要的，其他的什么流程啊，编码规范，设计模式啊，这些东西都是扯犊子。人家大公司能这样搞，不一定代表你小公司也能这样搞。如果哪个经理非要较真，上这些东西，最终的结果就是大家耗死在这个里面，流程严重滞后。程序员能够从百度，google上搜索到相关的代码，能够复制粘贴进来，把这个界面动起来，程序跑起来，就着实不错了。说到底一句话，你公司给的待遇太低，大家的积极性是不大可能自发起来的。至于说什么理想，责任之类的废话，老板你说说可以，千万不要当真。还是按概率论，公司里十个人有两个能够甘于奉献，积极向上，则公司幸甚，老板幸甚。下面这些话，给予那些目前无力改变现状的经理们。这现状包括，公司招的程序员，你不能想赶走就赶走；公司的薪酬制度，你插不上嘴，也插不上手；你没什么东西能够强制这些程序干什么事情。说白了，公司就这些人，就这些破枪，你干不干？要真想干的话，咱们说到的这个公共代码开发员，可就要大大的重视了，关于这个人员的职责，我还是引用下阿朱的《走出软件作坊》所述。公共代码开发人员，一般就一个人。对于企业管理软件的开发，框架的开发和维护，公共代码的开发，高难度的问题跟踪，需要高性能的设计，需要高扩展性的设计，需要高稳定的代码，需要高安全的代码，需要高并发的操作，需要复杂代码重构。需要性能优化，不知道的技术API，都可以寻求这位公共代码开发人员的帮助。他还负责新技术跟踪、新技术介绍、新技术试验。但这个新技术必须是为了改进公司现有产品和现有客户。新技术的跟踪必须上报给技术总监，以防不符合公司目标乱跟踪或跟踪方法和思路不对。对于有利于现有开发的新技术，可以筹备好培训课，由研发部经理安排时间，让公共代码人员给研发部全体人员讲解。如果大家认可这种方法，就需要选择适当的时机在产品中引入。因为你现在不能把宝压在刚毕业的程序员身上，但是你又得保证项目的质量不至于太差劲。那怎么办呢？你必须有自己的中坚力量，这个中坚力量就是公共代码开发人员，这个人你可以死皮赖脸的要求老板招一个有2，3年工作经验的人，如果老板不肯，那你就从招收的毕业生里重点提拔一，两个。这个中坚力量，在大公司里就是架构师，在咱这小公司里，叫公共代码开发员。这个人唯一的责任就是保证代码质量和文档完善。别的活计，无论任务多紧，都不要分给他。一个公司，不管多小，横竖都会有公共代码，框架代码，一些通用的东西，前人写过了，后辈绝对不要重复。但是在这里，这个公共代码，不单单是说那些可以公用的类和方法，而是说所有共性的东西。比如说上传文件的代码，这次和那次的需求差不了多少，这个人就要维护好这些类似的东西。因为你不分配给他具体的项目上的任务，所以他是有很多时间的，他这么多的时间来干吗呢？整理代码。你手底下的程序员不是忙吗，不是没空吗，这个事你就交给公共代码员。不必担心这个公共代码员水平不足，即便是你提拔的初学者，他见的多了，翻的多了，就熟悉了，因为他要翻开人人的代码，而且他有充足的剩余时间去百度上搜索，研究，他的水平慢慢就会上去。除了这个任务之外，他剩下的时间，就是要写注释，写文档，仅仅从程序员的角度写，不管其他的项目文档什么的，注意，这个人是宝贝，你得使劲保护着。王牌部队，给养要充足，任务要明确。只要这两个活干好了，你就得大大的赏。用这个王牌军的好处有很多，一个是，让他从框架的角度把握程序质量，有他在，出不了大乱子。第二个是他要维护程序文档，从模式或者组件或则思想的角度来写这个文档，即便公司里铁打的营盘，流水的兵，因为在他这有良好的文档，所以新来的人，都有据可循。第三个，因为他常常检查代码，就能总结出好和不好来。货比三家，有些程序员也就跟着提高了，总写不好的代码，他不好意思。第四个，这人是后备军，以后公司假如有成长壮大的时候，这个人就是骨干人才。就跟古代的皇帝有御林军一样，这个人也是自己的嫡系部队，要保证其绝对的忠诚，绝对的积极主动。而且对一个人来说，想要讨好所有人那是不可能的，可是想要讨好一个人，确是很容易的，只要你下了功夫，给予优厚待遇，可以保证这个人不要象其他人那样频繁流动，频繁跳槽，那么这个项目，这个公司，就稳固的多。老板抠门也好，公司财务制度混乱也好，接项目青黄不接也好，诸多因素，会导致公司运营始终走不出作坊的境地，但是你却可以在自己的位置上，尽量做到最好，在软件方面，撑得住大局，一个小型的公司，能够持续运行，就是靠你，你保持的住，老板只要不是太愚蠢，会有重视你的一天。到那时，你在想办法整顿整顿其他的。

网购地址集锦！

互动网 http://www.china-pub.com/508874卓越网 http://www.amazon.cn/mn/detailApp?qid=1229476350&ref=SR&sr=13-1&uid=168-5594865-3877817&prodid=bkbk812538蔚蓝网 http://www.wl.cn/4018060新风雨 http://www.cnforyou.com/query/bookdetail1.asp?viBookCode=13651沪江网店 http://www.hjbook.net/product/3933/第一书城 http://www.bookmall.com.cn/bookmall/servlet/cn.com.kehwa.KHMTServlet?TASK_ALIAS=proddisp&prodno=1100285674第二书店 http://www.dearbook.com.cn/book/251170北发图书网 http://book.beifabook.com/product/BookDetail.aspx?Plucode=712106539王府井书店 http://www.wfjsd.com/list.asp?id=712106539北京图书大厦 http://www.bjbb.com/product/detail.php?catalog=1&id=1799747中关村图书大厦 http://www.zgcbb.com/product.asp?id=712106539天津图书大厦 http://www.tjbb.com/Book/InfoBook.aspx?ID=712106539&CategoryID=0406070000中国科技金书网 http://www.golden-book.com/booksinfo/99/992685.html

不抱怨，不逃跑

作者，阿朱，山西人，从程序员一步步走上了管理岗位。这也是这本书程序员们看来更真切的原因吧。书写的非常细致，有些章节几乎是管理细则了。对于在校的计算机相关专业的“准IT人” 这是一本不错的了解业界的书。对于很多工作了的程序员更像是一本“心灵鸡汤”类的东西。国内软件行业的不成熟的现状，中小公司自身的困难，是现实。在各种论坛，在程序员中，甚至在学校中，都充满着各种迷茫和抱怨。但是迷茫和抱怨解决不了问题， 作者不时强调：问对困难，问题，压力，不抱怨，不逃跑，而是去想尽一切方法解决。这种态度我认为是本书的一大亮点，不论作者的方法能不能解决我们自己面对的问题，甚至作者有许多对技术，业界的观点我们不能认同。但这种不抱怨，不逃跑的精神是解决任何问题都需要的。抛弃一切怨天尤人情绪，知难则退的想法，努力前行！

值得一读的书

以前同事推荐过这本书，我听着书名，感觉有些像三流小说，顿时也怀疑同事的品味（H同学不像这样的人啊）。在偶尔的机会，我从Robin那里拿过来，翻了几页，明白了自己又自以为是了。书的内容主要讲的是作者如何解决工作(项目管理，和老板沟通，做事等等)中存在的问题。连着几天在地铁上把看完之后发现自己很多时候自以为是了，以为自己已经达到一定的水平，汗颜。我在这本书中得到最大的收获：要用心，只要想干一件事，总有方法的。

书要慢慢读，路要慢慢走

我看书的习惯不是很好，很快，文字都是跳跃着进行，特别容易因第一印象来决定是否要继续读。只有第一遍快读的时候很有感觉的书才会细细的再读。读这本书的过程很有意思。第一遍的时候感觉很一般，没体会出干货。并且觉得作者有点太“自夸”了吧，先抛个问题，然后就是“我xxxx的解决了这个问题”。随便扔那了。偶尔翻翻。正好有段时间为公司的事情头痛上火呢，也是一作坊。这段时间再翻到这本书，感觉来了。其实想想，作坊就是作坊，解决作坊问题的方法并不是让作坊升级成高级场所，而是调整自己的工作方法来适应这个作坊不要总想着颠覆性的变革来试图体现自己的伟大，作坊存在那么久，是有他的理由的。一切的变化，是要有益于后面的工作，就是革命了，无所谓大调整还是小调整。小调整操作性强，更容易推动。所以，即使酝酿了大调整，不妨也考虑一下是否采用“渐进式改革”之路。看到这里不要晕。也许上面的话和书的内容都没有关系。我就是写写自己对“走出软件作坊”这件事的感觉。书的内容，等我读完了再评论。

读《走出软件作坊》有感

我读阿朱的书，感觉非常的亲切，技术人员的成长历程，就是这样的。最近在读酒徒的历史小说《家园》，就是讲一个叫李旭的家伙，如何从一个小兵，成长为一个将军的。

原则面前，人人平等，这样才能走出软件作坊——51.COM技术总监如是说

阿朱送给我一本书 -- 《走出软件作坊》，并希望我能给再版写序。我一开始也感到奇怪，认为这只是一本软件开发者的心得，不是什么大作。收到书后，我给几个同事作介绍，想不到，很多人已经读过这本书，而且对阿朱也很推崇。这使我有些受宠若惊起来，我离开一线开发多年，哪有资格给这样一本很有分量的技术管理书籍写序呢？ 好在我还在一家技术型公司工作，并且还兼着分管技术线的工作。作为一个拥有超过200个程序员的互联网公司，我们最大的忌讳就是，各项目组还采用作坊式的开发管理，作坊式的系统运维。《走出软件作坊》更是一种管理的思维，而不仅仅提供一些方法。很多时候，人的思想决定行动，当你知道做么做明显是错的时候，你就会去选择正确的方法。 51.com走过从3~5个技术人员到30~50个人，然后到300多人的历程。51.com连续2年被百度评为web2.0用户交互做的最好的网站，也许只有我们的程序员明白其中的涵义。每天上传1000万张照片，500万篇日记，200万个群组帖子。以及用户之间上亿的交互动作。全部需要保存在系统里，并且即时传达每个用户。这些海量的信息需要保存在线上的数据库里，随着新用户的增长，老用户的不断沉淀。保存在系统里的数据还在不断地膨胀。互联网系统还有一个特点，就是软件的更新比客户端要来得更快，每天都有更新上线。所有这些，造成了对技术的巨大压力。这么多人，怎么分工协作，这么多功能、模块、项目怎么减少关联影响。要做到这些，我们唯一的办法就是：走出软件作坊。我们首先在思想上，不断地让每一个技术人员明白，我们已经不是作坊了，一定不能用作坊式工作模式来做51的事情。其次，更重要的是，我们要在工作中，不断建立各种研发工作流程、上线流程、质量保障流程。并且作为最高工作原则、要求来在公司施行。任何人，不管你以前功劳多大，能力多强，在这些原则面前，都是人人平等的。大家都知道，人最难改变的就是习惯。就像保证生存和敷衍下一代是生命体出现以来就根深蒂固的思维一样，人类要去掉这种自私的思维是多么的困难。要想用几千年的文明去改造几十亿年形成的思想，确实是很困难的时候。同样，自由散漫，作坊式的软件开发其实也是在每一个程序员心里根深蒂固的思维，“我可以做得很好，根本不会影响到别人的东西”，“这些事情很简单，没必要走那么多流程”，“把我自己的事情做好就行了，和别人怎么配合，他们自己想办法”，“这个根本不可能，用不着浪费时间讨论了”......想一想，你还有你的技术同事们，是不是曾经，经常有过这些思想呢？ 所以，我很推崇阿朱的这本书，他系统地讲述了，一个企业，怎么走出软件作坊，不仅是在思想上重视，更是要在行动上，制度上保证。《走出软件作坊》网上订购：互动网：http://www.china-pub.com/508874卓越网：http://www.amazon.cn/mn/detailApp?prodid=bkbk812538&ref=GS_TS&uid=168-8093432-0389064当当网：http://product.dangdang.com/product.aspx?product_id=20435119

说实在的话，做实在的事

原文地址：http://planeboy.blogbus.com/logs/33508768.html第一次听到阿朱这个名字，是在去年的9月初，当时受博文视点周筠老师相约前往印客网参加一个创业沙龙，周老师告诉我这个沙龙的主角就是阿朱，以及他即将出版的书《走出软件作坊》。为了给这次沙龙做足功课，我从周老师处要来了该书的电子版先睹为快了。这一看不要紧，我就被这本书深深得吸引住了，里面的一些观点与经验都是来自第一线，虽然看上去有点杂乱，但的确都是非常受用的东西。土是土了点，但的确是很管用的。在书中“双龙会”这一节中，有提到CTO每天的工作安排，先摘录如下：1. 每日接受开发组长汇报的进度报告，对此给出建议或指导；2. 处理同一部门员工间、不同部门间的流程配合问题，根据需要调整工作流程和岗位职责；3. 定期重新回顾公司业务的开张情况、面临的困难、未来的动态发展，以调整本部门制定的产品战略，并调整内部员工的职责和分工；4. 定期复查bug库，看看哪些Bug会重复出现，如何去根除它；5. 定期与员工进行沟通，了解他们现在的心理、薪水、公司发展看法、职业发展看法，以及对员工进行指导和方向建议。对于没有个人目标的员工，和其交流制定一个可见时间内他可以达到的目标，并不断的去提醒他完成；6. 对于每个员工的工作，会根据他最近所出现的问题，及时进行能力方法、技巧的指导。在日常工作中不断进行指导的效果，要好于拿出专门时间进行培训的效果；7. 查看行业内网站，关注竞争对手发展，思考未来的行业发展趋势。研究管理思想、管理模型、管理业务流程优化、考核评价模型；8. 从用户的角度去体验网站所带来的服务感受，发现问题、解决问题。虽然自己不是CTO，但从阿朱的这段描述中获益良多。下面，根据阿朱书中的这段描述，对照自己的实际工作来讲一讲。1. 每天早上，我都会对前一天每个组员提交的日报进行浏览，及时了解组员的工作状态以及工作进度，如果发现问题就立即回复邮件进行询问与指导。由于需要管理的组员人数较多，所以能与他们单独沟通的时间就会变得很少，而每天检查日报就是一件最快捷了解组员工作的方式；2. 在一家技术、采购、编辑、运营、市场、客服、物流等部分都有的公司里面，每天会花很多时间去处理同部门员工、不同部门间配合的工作，扯皮拉筋的事情经常发生。如何处理好不同部门之间的协调问题，是需要非常讲究艺术性的；3. 公司在发展，人员太年轻，因此会不断犯各种各样的错误。错误本身不可怕，只要能从错误中吸取教训，下次不再犯就善莫大焉了。因此定期对所犯的错误进行搜集和整理就变得非常有必要了，让公司的老人和新人都对这些错误有深刻的认识，千万不要犯重复性的错误；4. 人，是人，真的是人。要让组员踏踏实实的工作，除了以较好的薪酬待遇和未来的发展远景去激励他之外，还需要深入组员的内心去设身处地的为他思考，去帮他解决实际问题，正所谓“带人要带心”，就是这样的道理。如果发现组员有问题，要及时的指出来让其改正，而不能闷在心里面不说，到最后实在忍不住的时候就把人家开掉；5. 了解竞争对手的动态，要知道他们正在想什么、正在做什么，我们能从里面获得哪些有益的启示。有时候，竞争对手可以作为我们的一面镜子，让我们看到自己的不足，并时刻提醒自己前路很坎坷，差距还很大，我们还需要更加的努力；6. 站在用户的角度去思考问题，所有工作都要以用户为中心。“用户是衣食父母”这句话估计每个人都可以喊得出来，但并不是每个人都能在工作中实际贯彻下去的。但用户问一些我们认为很傻的问题的时候，我们就已经背离了以用户为中心的道路了。每个用户在网站上反映的问题，都可能是由于我们在设计上有缺陷、在交互上有问题而导致的，需要积极对待用户的每一个问题，即使你认为这个问题是很弱智的。在阿朱书中，还有另外一个观点我很赞同，就是对新人要加倍去考察和锻炼，书中原话是“试用期需要重点观察员工的EQ、技术能力、理解学习能力。交流，还是交流。需要用高于新人能力一倍的项目去锻炼人，实战更加锻炼人，如果他顶不住压力，自觉放弃跳槽，那么他就不适合团队的要求”。由于公司是一家创业型公司，因此对于人员的要求是非常高的，工作时间长、工作压力大、强度高是最基础的。很多招聘过来的人，都在试用期扛不住压力而选择了离开。而能扛住压力并留下来的人，于是练就了超强的压力承受能力，而且也能接受公司文化，这样的人就会成为未来公司的骨干与核心。虽然，这样的方式造成了较高的人员流失率，但我还是觉得在目前创业的阶段这一方式还是非常有效的。对《走出软件作坊》这本书有共鸣的地方实在是太多了，以上仅只举我自己感受最深的两个部分的内容与大家分享，更多精彩的内容大家可以在书中去认真体会哦。看过这本书之后，我将自己的邮件签名档改为“我们犯了很多错误，交了很多学费才知道了这个世界没有神话，只有一些很朴素的道理：便宜的打败贵的，质量好的打败质量差的，认真的打败轻率的，耐心的打败浮躁的，勤奋的打败懒惰的，有信誉的打败没信誉的……”，这句话来形容阿朱这本书是再贴切不过了。友情提示：《走出软件作坊》在互动网的购买地址http://www.china-pub.com/508874

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

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

很好

很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好很好

既解决了实际问题，又开阔了思路

之前朋友推荐这本书，看名字以为是类似成功学之类的，就一直搁置着。前两天无聊拿出来翻翻，就一发不可收拾。这本书对软件开发全流程中遇到的一些棘手的问题给出了解决方法。同时对不同职位的人员的发展也给出了意见或说明了职责。对于产品研发没有任何经验的人来说，本书提到的一些注意事项、产品研发过程、产品生命周期等，都做了简单的介绍，非常实用。对于从业人员的一些观点，作者也提出了自己的见解，我觉得说得也很有道理，尤其指出了都要以为老板赚更多钱为目标。总之，我是憋尿推荐这本书。

实用主义的教科书

这本书写的很通俗，比较容易读进去；没有什么方法论，可以说全是实战，全是前线上磨练出来的。作者不仅经验丰富，总结和文字能力也很值得钦佩。而且作者是典型的实用主义，完全的结果导向，一切要以解决问题为核心，我喜欢这种风格。当然，那些技术至上方法之上的人看了八成会不屑一顾，嗤之以鼻的。

超五星

这本书很好。表面上讲的是软件公司的问题，实际上很多地方非常启发人。这么说吧，我觉得我认识的同龄人，都能从其中吸取到管理经验。里面还有应聘，职业发展，调查需求，销售，报价，个人发展，福利待遇，团队建设，职能设计。最重要的，这里面都是实打实作者自己的“土”办法，不会脱离实际。1.作者喜欢推演，将员工小的错误/企业错误决策做成线索，一步步带我们看到大问题为什么出现。出现以后，最小成本的解决方法是什么。解决以后，出现的新问题再如何解决。大事化小，小事化了，消弭问题于无形之中。以及而如何预防同类问题。2.另一种推演是根据客户，剖析客户心理，然后给出应对模板。非常有系统性和说服力。f，写不下去了。最无力的是，我没法有效归纳这本书到底讲什么，看完自己写的归纳，太过泛泛，和其他管理评论比还不如。这是一本值得推荐的好书，原因是只有你看了才知道好看。

伯乐、师傅、领导——这就是阿朱

同步至博客：http://idaoteng.blogbus.com/logs/78603679.html这本书看完有一周了，可一直没从“在读”改为“已读”，仅仅觉得该写点读书的感受，为书带给我的收获和快乐。每晚躺在床上看一点，起初按顺序来，后来重新好好看看目录，好些标题吸引着我，于是随心而读，很HAPPY（看的哈哈笑~），阿朱娓娓道来中还带着幽默，让人感叹这个CTO的魅力。感受1：在阿朱手下干，是这等幸福和幸运。即是伯乐也是师傅，有事领导——这就是从书中体会到的阿朱。不管最初是程序员，还是简单的文案，阿朱总发掘着他们的潜力，教他们做好当前工作的同时，给予更多发展的机会。程序员可以做项目经理，作为他们强大的后盾。文案可以兼任测试可以尝试各种方法帮她做好做到位，可以到服务部去锻炼，经历有了，知识面扩展了，对她的职业发展已经起了莫大作用。同为女孩，我不得不说自己羡慕这个蛋白质女孩。或许因为这份文案工作，她的提升可以让她以后的路走的更明确，更顺。感受2：作为一个快要研究生毕业的学生，我希望从本书中了解不同职位，实实在在的职能是什么。而从书中我获得了想要的。从开发到测试，从售前到售后，从软件实施再到客服支持，还有我敢兴趣的项目管理，羡慕的蛋白质女孩，这一切都让我这个未出校门的童鞋切实体会到，这些不同的工作有着各样的魅力。也正如阿朱所说，我看到了这样一个软件作坊式如何发展起来的，同时也看到这个软件公司以后的道路会越走越宽广。感受3：与感受2相通，除了了解各种职位的工作，也拓展了自己的思维。这样一个软件作坊，慢慢走来，一路摸索着有了自己的经验，此路不同走彼路，这就需要有双慧眼，来寻求可发展的路子。

书目结构

组织结构（各个职位的能力要求）--过程管理（文档管理、需求管理<强调过程管理>、开发、测试，人员培养<总有适合的工作给他做，然后成长，不怕笨就怕不用心>，产品定位，软件费用报价参考）---绩效考核（胡萝卜）

一点一滴都是经验啊

厉害，很不错的书，能早一天看到就能避免少走一天的弯路。什么高级软件工具，什么新式开发语言，统统的都是浮云。。。要简化流程，要规范文档，要统一目标……老板不是混饭吃的，要低调低调再低调

华为朋友评价《走出软件作坊》：第一眼美女

原文地址在　　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来担当这样的职责更加符合企业的实际情况。 　　 　　 管理只所以是一门艺术，原因之一在于永远没有放之四海而皆准的管理方法。管理应该因时、因地、因人的不同而采用不同的管理方式从而收获最好的管理效果。把另外一个公司的成功管理一成不变的搬到您的公司往往会是死路一条。我在管理的境界中提到，科学的管理仅仅是一种初级的管理方式，任何流程，制度能不能发挥作用关键在于管理者的灵活适当的应用，只有当您知道了如何合理的运用管理科学的时候，您才是一个合格的管理者。 　　 　　 虽然只是读了一篇，但就像作者所说，这是一本脚踏实地的书。绝对值得您深入的研究和思考！

中国的IT人很值得读的一本书

从这本书得到了如下几个东东：1.不要照搬书上或者网上的东西，只有真正能解决自己工作中遇到的问题的方法才是最好的方法；2.书写和语言表达很重要，尤其是PPT，文档的格式，而这一点是自己以前最瞧不起的！3.老板永远不可能给你足够的资源和时间，而员工的责任就是在极其有限的资源和时间下实现老板布置的任务和目标，因此抱怨永远无济于事！4.责任感相当重要，有了责任感，什么压力，困难都可以迎刃而解！5.遇到困难和压力，需要勇敢地面对，不找借口！这一点也是自己最欠缺的，自己总是在困难和压力面前，选择逃避，选择得过且过，选择浑水摸鱼！但是出来混迟早要还的！逃得了一时，逃不了一世！如果选择面对，会耗费自己大量的精力，但会感到充实和自信；如果选择逃避，虽然偷得一时清闲，但会感到虚妄与忐忑！

从程序员到管理者都应该读一读的好书

这本书是我去年就读过的，最近应好友之约，又读了一遍，收获很大。虽然这本书的很多章节都是互相独立，但是作者用基本同一种思路在写作。那就是遇到问题、为什么会有问题、做了哪些尝试、如何解决的、我们应该怎么对待这些问题。所以这本书，不仅仅是一本写具体实例的书，也是一本关于如何解决问题、思考问题的书，你可以从中学习到具体的知识，尤其是刚刚走上程序员职业道路和刚刚开始做管理的人以及那些从其他行业进入软件开发行业的人员，绝对属于必读之书。这本书，也在工作上给我很大帮助，感谢阿朱写出如此一本好的一本书。我的读书笔记：01http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1046.entry02http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1051.entry03 http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1057.entry04http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1060.entry05http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1063.entry06http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1066.entry07http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1074.entry08http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1080.entry09http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1084.entry10http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1088.entry11http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1091.entry12http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1094.entry13http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1098.entry14http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1102.entry15http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1107.entry16http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1110.entry17http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1115.entry18http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1118.entry19http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1121.entry20http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1126.entry21http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1131.entry22http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1134.entry23http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1137.entry24http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1143.entry25http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1146.entry26http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1149.entry27http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1152.entry28http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1155.entry29http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1158.entry30http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1164.entry31http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1167.entry32http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1170.entry33http://zhaoguoqing.spaces.live.com/blog/cns!179C0A825FB6EDED!1173.entry

搜狐研发的朋友也在看这本书

peter-matrix 说:走出软件作坊很好看。yeka 说:Peter 姜？peter-matrix 说:呵呵，是。老师好yeka 说:你买了？peter-matrix 说:恩。yeka 说:在哪里买的peter-matrix 说:我推荐组里的同事都买了。 在卓越订的yeka 说:你们是哪个公司的？peter-matrix 说:我现在在搜狐了， 无线研发中心yeka 说:哦！ 你们组多少同事？peter-matrix 说:30人左右peter-matrix 说:写的很实在yeka 说:呵呵，期待不断听到来自你们的反馈。我能把和你的聊天作为营销的内容放在博客上吗peter-matrix 说:我觉得比较解决问题。不过我们的开发离行业软件有点远，但很多道理是相通的呵呵。可以yeka 说:非常感谢， 期待书评。同时推荐昨天朋友告诉我的一本好书，也可以推荐给你们组的同事们peter-matrix 说:呵呵，好的。yeka 说:《自慢——从员工到总经理的成长笔记》，这本书是台湾2007年度最畅销的经管书，豆瓣上的介绍说：“这是一本少有的以工作为主题，却能让上班族广泛传阅的杰作，总会有小员工不辞劳苦地在网络上转发，也会有大老板交代下属大量复印，让员工仔细阅读。” 卓越有售：http://www.amazon.cn/mn/detailApp?qid=1230166267&ref=SR&sr=13-1&uid=168-8093432-0389064&prodid=bkbk859716起因是我们看到了一篇文章“一个公司主管的真情告白”peter-matrix 说:其实这么多年，看开发和管理的书很多，但最后能落实到实际工作中的很少，都比较理想化，最后还是自己琢磨出来的方法管用，所以看这本书很有共鸣

有很多共鸣

之前一直没有读过阿朱的博客，应该是个遗憾。一次偶然的机缘，在当当上找其他书的时候发现了这本书，看了目录和样张，就被这本书深深吸引，买回来一读，爱不释手，用最快的速度读完后，仍然意犹未尽，还想找机会再读一遍。如今中国的软件行业，是一个很奇怪的现象：像大的软件公司，一般是大型的协作团队，但是现在的软件行业大多数是小项目小团队，即使是几百号人的软件公司，也大多被分成了一个又一个的小团队。也许是发展阶段的不同？？这样的小团队，管理不够规范、测试或其他资源不足，维护工作量太大，版本怎么管理、客户怎么搞定、老板不够支持。。。管理者面临着大大小小，各种各样的问题，当然老板也在纳闷，这个管理者是否能帮助我把事业做大，带领开发团队前进。于是大家带着相当的困惑，和朋友交流、上网交流，希望能解惑。阿朱这本书的出现，无疑增加了一种交流的方式，也解答和相当多的困惑，当然他不能解决所有的困惑。我对这本书价值的看法，这本书不是圣经，也不一定是最佳实践，但是他已经走在了比较合理的方向上，也许这也是发展阶段中一个必经之路，相信如果所有的中小团队都能达到阿朱的这种水平，我们就可以进入下一个发展阶段，继续下一种模式的探讨。

去做传统软件业，还是去做互联网

软件相关行业按其价值链，分为两种类型：　　 1、资源自上而下型，即资金和其他各类资源从上而下流动：（纳税人——》）政府、机关——》国企——》国企关联企业、外企——》国内IT外包商——》二手接包方——》雇员。 传统软件业（即各行业的企业级应用）就是这种类型。 注意，纳税人的首环在价值链中的作用是很有限的，所以我称之为自上而下。 这类行业的特点是：利益相关人最重要的考虑是满足上一级价值链的关键人物的需求，而不是产品本身的最大效用。IBM的一位销售经理就曾经描述过所谓“天龙八步”的销售流程，其中，决策者最优先考虑的是“安全”因素，即：不要弄砸，或者弄砸了也必须至少有垫背，有说辞。接下来就考虑的是自身利益最大化（不妨看看王强的圈子圈套），最后才是项目本身的效用。 不管是什么角色 ，都要服务于这个优先级顺序。 所以说到底这个行业是对人的服务业，如果抱着做艺术精品的预期来做这个行业，必然免不了要失望。 所以这个行业注重上层资源关系网培育；注重培训、认证、资质、跨国公司产品等提供的安全因素；注重能侍候好各类菩萨的人精（是高价值的人才）。 雇员的成长也是沿着这些因素的道路成长起来的。 由于上层资源是条块分割的，因此以此为生的软件企业也是条块分割的，这就是为什么我们这么大的国家，靠软件发财的老板很多， 但长大的高质量软件企业却很少。 既然长不大，作坊式生存的代价也可以忍受，所以传统软件业充斥着大量廉价劳力+command&control的低效管理风格。这实质上是行业的主流的生存方式。　　　　2、资源自下而上型，即广大的消费者是企业的衣食父母，要是他们不满意就会用脚投票，抛弃企业转投竞争对手。互联网行业就是最好的范例。 没效率就会死掉的压力迫使企业自始至终都强烈关注产品的效用。企业会培养、争抢能够提高团队效率的人才。高效的敏捷精益等方法论和轻量级的技术受到追捧，而CMMi、SOA等方法论则被弃用，员工的效能产出的能力增长较快，容易成长为某一领域的专家。　　　　说到这里可以得到结论：如果你要成为攫取上层资源的人精，可以到传统软件业来锻炼锻炼；如果你希望做出一个产品能让很多人受益，那么就去做互联网吧。 两者的共同点是：都不容易，都要付出持续的努力。

理想与现实

我是做嵌入式软件开发了，所以对这本书里面讲的很多细节都没有切身体会，读起来可能没有这些同学的收获大。每个上进的技术人员都有自己的技术梦想，我们渴望做很酷的产品，渴望成为技术上的大牛，渴望有一天我们也可以在自己的农场里面，为google这样的公司开发V8引擎，渴望在一个成功的产品之后，可以去瑞士滑雪，而在工作中，总是由于这样或那样的原因，感觉离梦想越来越远，激情在被奢侈的挥霍。梦想和现实之间的矛盾让我总是感觉很纠结，我经常在考虑，在中国，会有技术的空间吗？这种纠结有时候会让我感觉沮丧、痛苦。“走出软件作坊”这本书让我的痛苦好过许多，因为我知道，还有行业信息化这个行业，他们的痛苦和纠结比我更甚，我是做嵌入式软件的，看书的时候，我突然觉得，其实，这几年的研发经历，真的很幸福了。这本书让我受益的不是方法论，说实话，很多方法，到实际工作中，你指望不上能够像阿朱那样，可以得到想要的结果，让我受益的是，在苍白的现实中，我们其实也可以通过做一些小事，看起来不那么眩，通过微小的量变，累积出质变。再眩的技术，也要服务于现实，它才有生命力。积极一点，反正怎么都是过，不是吗？

老紫竹的书评：我们得尽全力去思考

书里面什么内容都有，什么人都适合看，都能得到很多启发。其实这并不是阿朱先生的文章怪了，而是我们这个社会本身就是光怪陆离。中国人太多了，林子大了什么鸟都有了，而软件业又是一个变化多端的环境，在中国大环境下，出现的问题自然是非常有中国特色，软件业的老板不了解软件，粗放式的管理，虽然是高科技的东西，坐起来却还不如很多旧式公司。很多软件公司真的就像个作坊，甚至有些还不如作坊。但是这不可以。 因为中国市场毕竟有成熟的一天，市场总会因此达到自己的饱和。所以就要想方法来解决这些办法。阿朱先生总是很谦虚的说自己的方法很土，因为我们的很多公司就是土包子，还就得用原始的方法。老板不愿意放钱，不就是因为怕赔钱吗？其实矛盾就在这里，阿朱把很多开发中的矛盾都得非常准确。 但是阿朱先生的文章并不仅仅是这些。还有很多结合业界、经济环境的分析。 特别是关于经济状况的分析！有些时候，我们对周围的事情总是漠不关心，觉得和我们的行业，我们的生活太远，但现在的市场经济已经把我们紧密的联系在了一起，全球化更加加剧了这种联系。一个小小的波动就会影响全球的经济。 只有我们去参透这种联系才能让我们的工作变得更加自如。 这里让我想起了以前《蓝海战略》这本书里提到的太阳马戏团的成功，虽然同样是马戏团，但是他们的竞争对手并不仅仅是周围的马戏团，还有电视上的节目，每个家庭的PlayStation游戏机。而太阳马戏团的成功正得益于他们跳出自己狭窄的圈子，真正思考一下自己所处的行业面临的问题，自己行业面对的消费真正的需求。 什么是中国企业的问题呢？中国市场其实真的很大，还有各地区发展的不平衡，很多行业起初并不需要去关心如何发展，因为只要他们有业务就有盈利。阿朱先生在《管理软件到底有没有前途》那一章的内容，现在想想都还让我觉得触目惊心。问题并不是没有，只是一时没有发现而已。现则则是因为积累的时间长了，终于爆发了。 看这本书，其实就是阿朱先生帮我们去反思我们的现状，很多问题就出在我们身边，只是没有人告诉我们，没有人去系统的思考这些问题之间的联系。 而解决问题的方法其实也很简单，只是我们没有尽全力去思考，没有用尽我们周围可用的资源。跟着阿朱先生一路走来，真的感觉收益颇多。 我其实个人更加期待阿朱先生下一个系列，CRM管理，因为这个部分要涉及的问题是所有企业都必须面对的。 我也相信阿朱先生下一部著作也一定会更加精彩的。

如何看待软件开发过程

读了阿朱的《走出软件作坊》，结合王明夫对于国内战略咨询的理解，突然对软件开发过程中，软件设计与软件开发的管理过程有了一个新的认识。王明夫对中国企业发展的看法大体如下，基础不牢，无法上来就谈管理，直接从管理的层面切入，可能永远也有无法解决的问题。所以我的理解是，我们现在处于打基础和注重企业管理方法的混沌时期，需要混合注意，而不是单独的看基础或者是单独的看管理，这样容易出问题。同样的，读了阿朱的《走出软件作坊》，虽然还没看完，我就产生了疑问，为什么在他那里，OO、设计模式成了虚无缥缈的东西，为什么正统的管理方法在他的文章中不会被大张旗鼓的描述，而出现最多的则是“解决问题”，这个“解决问题”用的很好，从实际出发，我可能没有用漂亮的OO，没有用漂亮的设计模式，然而我解决了问题，如何？我从实际出发，我的问题解决了，你有再好的OO，再好的设计模式，你问题一大堆，还有什么可说的？这两者一对比，我似乎看到了什么，我是初出茅庐的小伙子，我没有在软件行业摸爬滚打那么多年，我没有那么多的经验，我看不到软件行业的发展问题，然而，我也不是没有经验，我也经历了一些初创企业的伤，也看到了一些问题，不是从全局，而是从自身经历，因此我有很多疑惑，但在《走出软件作坊》之后，我的疑问似乎有了答案，如果真的如同阿朱所说，国内的软件作坊的形态不够正规，数量和比例又如此之大，那么我有理由认为，这和王明夫老师所讲的内容是有关联的，而且问题如出一辙，有同样的根源所在，因为现在的软件行业环境中，你单独的看设计、看开发和单独的看管理和把控，都是容易出问题的，是很难解决问题的，因为方法不够完美，方法本身有问题。所以，我觉得，现在正好可以用上这个词：混乱之治。基础不够牢靠，我们从开发人员到客户都没有形成那么完美的认识，客户没有很好的消费意识和对软件的高水平认识，开发人员大多不是计算机的科班出身，学什么专业的都有，半路出家，就做了程序员。大环境如此，这时候如果大讲特讲设计模式，管理方法，我想真的会徒劳无功，然而，对于一个团队，一个组织或者一个技术性的创业公司来说，没有合理的方法，没有合理的过程和流程，你就会事倍功半，你就会效率低下，于是阿朱如此的受到欢迎，因为他把当下能够实实在在解决问题的路子给了大家，就是不可单独的看待设计和管理，需要混合对待，同时思考，不是盲目的利用成熟的管理方法和完美的设计模式，而是根据需要来使用方法。说说我的一个经历：我的上一个公司也是创业公司，几个创业者都有很好的背景，有国外顶级软件公司的管理经验和开发经验，CTO有带领百人开发团队的经验，项目总监也有10来年的项目管理经验，曾经管理过上亿的项目，这样的资历，拿到一个几十万的项目，对他们来说应该不算是难题了吧，然而，项目进度一拖再拖，项目的实现漏洞百出，连我这个写程序的人都不愿意再回去看原来的代码，感觉没有什么利用价值，没有什么再总结的价值，因为没有任何一个地方是顺眼的，现在总结起来，是没有把正确的方法用在正确的事情上，大项目的经验没有平滑的落实到我们这个小项目上，生硬的实施，最后文档、工具还有各个方面什么也不缺，但都是流于形式，看着好看，然而其中的失败和无用只有我们自己知道，我想这种情况正好应了《走出》中描述的情况，而我现在看来，这也正是没有认识到这是一个混乱的过程所致。我想，这是一个介于起步与平稳的中间阶段，是高速发展的阶段，这个阶段的特征就是无法照搬国外成熟的先进的各种设计模式，各种管理方法，而真的是要根据问题寻找方法，那么我想，这个阶段需要的是改造，需要将现有的、成熟的设计模式、管理方法结合自身流程的特征，进行改造，变成适合自己的才能够利用起来，就像敏捷在一开始实施的过程中，也就是用excel来做一些记录，而逐渐的产生并使用了一些工具一样，在发展的过程中，需要寻找的是中间态，而不是望着成熟的方法却不能“止渴”。

请不要叫我“程序员”

周星驰有一句经典的台词：请不要叫我“跑龙套的”，我是一名演员。看了这本书，我突然也有了感悟：请不要叫我“程序员”，我是一名软件工程师。程序员只关心自己代码的一亩三分地，完成预期功能，如果级别高点，能考虑一下代码的质量和相关文档。在这种情况下，程序员一般被动的接收来自上级的分配的任务：按照分配任务的邮件，开发完代码。输入数据了，看看输出数据，不对？那就修改一下；得到预期效果了？嗯，任务完成了。至于这个代码是做什么的，用在什么产品里了，能带来多少利润？不管不关我的事情，反正我是完成任务，对得起我的工资了。有什么方案，可以让这个产品做的更好，和其他部门协作的过程中，我是否需要人家提供更好的资源吗？嗯，还是不关我的事，人家给啥我就做啥呗。而软件工程师考虑的不是代码，因为真正给自己和公司创造价值的是产品。所以作为一名软件工程师，实际上承担了更多的责任，一个产品的成功，代码实现功能，只是其中一部分，还要考虑是否需求是否合理，UI是否友好，开发进度如何安排，开发过程中不同的人甚至不同的部门如何分工，才能保证保证产品开发高效进行。而完成这些工作，，往往纠结以往的惯性，部门和个人的利益关系。这些工作都不是一个程序员没有权力去安排这些工作按照自己的意愿进行，但却可能收到这些因素的掣肘，典型的程序员遇到这些问题大多要么“事不关己高高挂起”；要么“众人皆醉唯我独醒”，嗟叹自己怀才不遇。而一个真正为产品负责的软件工程师，最终的目标是为自己心中的那个产品而奋斗，想方设法解决一切这条路上的困难，无论是不是代码相关的。归根到底，程序员和软件工程师的区别在于责任的范围大小。一个真正有前途的软件工程师，遇到问题，不要把时间浪费在争论是谁的责任，是谁的分内工作，而是要尽快想出解决方案。一切给我带来不便的问题，本质上都是我的问题，因为如果不解决，受到拖累的人就是自己，如果自己都不帮自己，谁还来帮自己？所以一般程序员的形象就是胡子拉碴，不讲卫生，头发油油，穿着大裤衩大拖鞋，说话满口听不懂的词汇。而软件工程师的形象应该是有衬衣西裤，工作报告有统计，有分析，有总结，不加班，不弹性工作，会开发会写总结会演讲。写到这里，突然觉得，软件开发这个行业似乎和其他行业也没有什么本质区别，一个合格软件工程师，其所具备的子夜精神也会让其在陌生行业上也会很快进入正轨。各位伏案敲代码的同行们，就把当前的工作作为一项人生的修炼吧。

没写过书评，大家凑合看吧

直接捞干的说吧，这本书我的确很喜欢。为啥喜欢呢？因为，这书就好像老妈炖的酸菜一样，既让你吃的饱，还让你很容易消化；你弄些鲍鱼，龙虾俺也吃不出来啥味，弄不好还拉肚子。第一 语言很实在，弄句现在流行的话就是不忽悠人，不故弄玄虚，书看的多了，有些作家总是弄对华丽的辞藻，杜撰各种稀奇古怪的名词，常常让你惊为天人。其实，里面还不如放点玉米面或者大馇子来的实在。第二 来自于草根，草根是最贴近生活的，他真实的体验了身边发生的每一件事，而不是在家里天马行空的一顿胡想。俺也是算是个挨踢人吧，以前也做过几年程序员，现在转行做了产品经理，以前也曾经总抱怨，人手不够、资源不足。。。。。后来发现人手、资源、其他条件极少有同时满足的时候，那么产品还做不做？？阿朱的书里我想已经给出了答案，有条件要上，没有条件也要上，没办法大家等米下锅呢。我也常跟同事说，现在就是敌人冲到我们阵地前了，你却没有枪，你抵抗还是不抵抗？？第三 “杀猪刀”实在的解决办法，俺也算跟同学一起创业吧，不到30人，典型的作坊。公司虽小但五脏还算全和，随之问题也就来了。产品、研发、测试单单这三个部门就够乱的。以前，大家也觉得产品部门就是写文档，什么需求文档，设计文档。。。反正你就写吧。研发部门为了代码保密也没有版本管理，经常也是改一个BUG，再出三bug。。。头疼啊！！！产品、研发、测试 三者的关系混乱也直接导致了效率低下，相互推诿。 而我们要解决这些问题，找来找去更多的是买“屠龙刀”，其实我只想买个适合自己的“杀猪刀”，俺不是不知道“屠龙刀”好，可惜俺没有那么多钱，还有俺们功力太弱，别没耍好砸自己脚面就不好了。第四 思考，全世界最难的工作恐怕就是思考了！阿朱却把这项工作做的很细致。很多问题看起来很难解决，但阿朱却处理的不错。我想这应该是思考的结果。问题的症结在什么地方？关键人？如何处理？ 我也常常在思考产品部门的存在意义和其作用是什么！所以大家还是静下心来仔细的思考一下你所遇到的问题。第五 。。。。暂时没想到，以后想到了在补上吧 嘿嘿！扔砖者！非诚勿扰！（扔过来，我在给你撇回去，最近玩《使命召唤5》光扔手雷了）

要像熬粥一样慢读此书

我个人最欣赏地方是书中带来多种思想方法的激荡。假如你瞥一眼这本书，只是看出表面的东西。但你慢慢品味，就会体现一些不一样的味道来。就拿我个人读此书经历来说。之前听闻网上的好评，冲着这点去图书馆翻阅一下，只被书中通俗有趣的词语解读所吸引。结果匆匆一睹为快。到现在临近毕业，有一丁点的求职经验，重新阅读此书，觉得对个人思想方法有个说不清道不完的冲击。

爱不释手，欲罢不能的一本书

这是有史以来读的最快的一本书，只用了一周时间就读完了，过程中的感觉是爱不释手，欲罢不能，只要一有空闲就捡起来读一读，有时看到书中的文字甚至能笑出声，一本讲管理的书能带来如此效果，真的很是惊讶。读了这本书，最大的收获有两点，一是如何正确的树立职场价值观，避免一些浮躁的情绪出现。二是如何更好的工作，实现自己的目标。读后感：http://blog.sina.com.cn/s/blog_5b01dfc30100o8bh.html

学会自省

熬了几个夜晚，终于看完了《走出软件开发作坊》，尽管我非身处管理软件开发领域。但如同管理软件开发领域一样，我们在web应用开发领域同样会遇到客户需求反复修改、开发过程的管理复杂多变、开发团队难以管理等诸多头疼的问题。你所在的团队，在面对这些问题时表现出来的态度、采用的解决办法，正好反映了这个团队的成熟度，也反映你的职业素养。阿朱毫无吝啬地与大家分享了自己多年的从业心得和实际经验，给IT中小企业好好地把了一下脉。对于个人，这本书带给我的最大收获是：学会自省。“我是怎样一个人”，我们往往很难认清自己，甚至很难驾驭自己。我想认识自己的最好办法是，看看别人是怎样对待自己的。我们是怎样对待他人的，那么他人也一定是那样对待我们的。只有这样，我们个人才能在一个群体找到最适合自己的位置，才能被大家更加认可，才能为团队承担更多的责任。如果你是团队的管理者，冷静思考一下，团队中其他人是怎样对待自己的：会倾听你的观点吗？会乐意接受你的任务吗？能真诚接受你的批评吗？会跟你商量事情吗？会向你提意见吗？......如果是，说明他们认同你的管理，信任你，相信与你一起能做出成绩；如果不是，说明自己管理一定有问题，思考自己是不是在言行上表现得太强势，是不是自己不够信任他们，是不是不尊重他们的建议，是不是在平衡团队利益上欠妥，是不是还停留在以前程序员的思维，是不是把简单的事情搞得复杂了，是不是拿着诸如《人月神话》、RUP、CMMI、UML等照本宣科？......想想别人为什么会那样对你，如果你是他们，又会怎样对待现在的“你”。如果你不是个管理者，冷静思考一下，管理者是否愿意让你承担更多责任，其他团队成员是否乐意帮助你，他们是否愿意指正你的缺点，是否愿意和你推心置腹？......如果是，说明大家信任你，自己有能力也有责任为团队付出更多；如果不是，说明自己待人处事一定存在问题，想想自己在哪个环节做的不好，是不是不够信任大家，是不是付出太少而抱怨太多，是不是总记得嘀咕自己的功劳而忘记别人的苦劳，是不是自己说话前从不考虑后果，是不是自己从来不会推心置腹？......想想别人为什么会那样对你，如果你是他们，又会怎样对待现在的“你”。“人，是人，真的是人”，阿朱的取词意味深长。只有我们把别人当成一个有血有肉有情有爱的人来对待，只有主动站在对方的立场来思考，我们个人的职业素养才能有进步，在做人做事上像阿朱、大宝那样驾轻就熟，团队才有希望。 longlinfeng's Blog：www.longlinfeng.com

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

原文地址在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来担当这样的职责更加符合企业的实际情况。管理只所以是一门艺术，原因之一在于永远没有放之四海而皆准的管理方法。管理应该因时、因地、因人的不同而采用不同的管理方式从而收获最好的管理效果。把另外一个公司的成功管理一成不变的搬到您的公司往往会是死路一条。我在管理的境界中提到，科学的管理仅仅是一种初级的管理方式，任何流程，制度能不能发挥作用关键在于管理者的灵活适当的应用，只有当您知道了如何合理的运用管理科学的时候，您才是一个合格的管理者。虽然只是读了一篇，但就像作者所说，这是一本脚踏实地的书。绝对值得您深入的研究和思考！

写的内容有很强的共识

http://www.china-pub.com/member/bookpinglun/memberpl.asp?membername=china-pub_sos写的内容有很强的共识，时常共鸣，就如自己发生地一样！其中有不少内容在日常管理中值得借鉴，而且不同层次的人皆有，我觉得这本书称为“手册”比较妥当，需要的时候翻翻。

很棒

1. 阿朱能对自己参与的工作，不断思考，不断总结，这是他的价值所在 2. 阿朱最让我佩服的是，懂得换位思考，尤其是与老板的换位思考，职业经理人能想到老板所想，厉害！

经历过、经历中、将要经历

阿朱的切实感受，自然分外真切，也许我们正在经历，或许我们曾经经历过，或者我们将来要经历，但是我觉得读这本书最重要的一点就是两个字“态度”，任何事情只要态度端正、心态良好，我觉得任何事情都会有解决的方法，阿朱的方法自然是其中一种，但是只要你的态度端正、心态良好，你也可以找到自己的方法，所以我看阿朱的“走出软件作坊”，看得是阿朱的态度和心态。

刘未鹏：我就喜欢这样简略的总结，节省阅读的时间，具体的运用实践是属于自己思考的范

今天看到李笑来老师在博客上推荐这篇文章，跳转过去看了，觉得阿朱这篇文章写得太好了，一定要仔细体会，虽然每条都很简练，可能不大合喜欢看故事的人的口味，然而我就是喜欢这样简略的总结，节省阅读的时间，具体的运用实践是属于自己思考的范畴，仔细反复体会每条语句所对应的现实情景，结合自己平时的做法，比较，揣摩为什么阿朱文中提到的做法是更好的，对于平时做事情很有帮助。 以前也一直有注意《走出软件作坊》的连载，但由于项目管理的知识目前还没有用到的需要所以一直也就没有跟踪阅读，但看了这篇之后才知道这本书并非是纯粹的讲项目管理，顿时决定一定要买来看一看！

争鸣来了——老曹如是说

http://hi.baidu.com/caoz/blog/item/51ee8a13486770d7f7039e2e.html走不出软件作坊2009-01-12 12:51黄一孟 小朋友犯了一个小错误，把他自己订阅的书寄给了我，是两本书，一本是“基业长青”，一本是“走出软件作坊”，这也让我有机会嘲笑他的阅读品味的机会。“基业长青”是一本牵强附会的书，试图在成功企业中获得某些共性，但是又解释说没有什么共性是可以供后者参照的，如果我们在金融危机后考察他们的成功企业，发现这些具有“成功代表意义”的伟大企业很多都在金融危机后光了屁股。所以，一笑而已，切莫当真。今天要说的是“走出软件作坊”，这本书的作者是阿朱，博客地址是http://hi.csdn.net/david_lv/profile ，这个作者可以看出，是一个有心人，或者说，是一个具有较高职业素质和分析问题能力的人，但是，必须说，受到职业和工作环境的限制，其视野局限在有限的领域里，这也就是caoz要对黄一孟小朋友说的话，对互联网的理解和把握，这个阿朱比你低不止一个档次，你去看他的书？有没有搞错？有人会说，caoz太自傲，如此“贬低”阿朱？其实不是，因为caoz有特殊的工作背景和工作资历，在电信行业呆过，做过企业软件（也就是阿朱所提到的软件作坊），呼叫中心(阿朱提过的东西，呼叫中心与客户关系管理的整合，caoz也算是门清的)，也做过网络安全（高级一点的软件作坊），并且在互联网领域也混了若干年，所以，阿朱说的情况和故事，caoz 100%可以理解，甚至可以说，在那个领域，caoz的见解和作为远不如阿朱，caoz做过oa产品，说的不客气点，就是功能堆砌，竞争对手有什么，我就有什么，但是可用性很差，看上去什么都有，出去推荐的时候自说自话，对客户需求的理解和认知都很差劲。如果caoz还在那个行业，阿朱做caoz的老师是绰绰有余的，但是，必须说，那个行业和互联网行业完全不可类比，甚至过分一点说，如果你呆在那些行业久了，进入互联网，还不如一个纯粹的新人进来，因为你在那些行业积淀的视野，经验和看待问题的方式，用在互联网上，不但是没作用，反而是副作用（caoz为此蹉跎了很多岁月）。阿朱还提到经常通过donews了解行业最新动态，唉，可怜的人，殊不知donews上你所了解到的，也是负的，还不如一个字不读去扔硬币来的准确。这就是行业代沟，不是阿朱的能力问题，而是他所处的环境问题，而以他当前的心态看（多次说自己是职业经理人，并多次使用“空降”字眼），想换个领域从头开始，不是一般的难。caoz说了这么多废话，下面来点干货。1. 阿朱说任何脱离正常利润率的行为都是不能持久的，都是违背经济规律的。好吧，姑且认为google是新贵，还没有现原形，不知道阿朱怎么解释微软30年来的利润率情况？边际利润和边际效益，在传统通用软件行业其实已经可以看到（很可惜，中国几乎没有这样的公司），在互联网领域更加明显，而以签单为生的行业，如电信集成，企业软件，则基本上无法感悟到。此外，“IT不再重要”里提到的“众包”概念...... 嗯，不多说了，多说了某些老大又要批评caoz好为人师了。2. 企业级软件（包括但不限于管理软件，财务软件，乃至企业级信息安全产品等，特别提示，企业级安全产品和瑞星不是一码事），的确是靠关系吃饭，靠背景吃饭，但是互联网不是。互联网靠的是产品和服务吃饭，这一点caoz强调了无数次。在互联网上，没关系的，没背景的往往战胜了有关系的，有背景的。3.阿朱说整合产业链，个性化服务作为最大的卖点，但是google adwords在北美是没有客服的，连销售都没有，这个怎么解释？4.阿朱将公司分成几流这个无所谓，但是看他把苹果排在了第几流？苹果是做产品的？无语！我感觉阿朱压根没想明白苹果的收益模式是什么。5.阿朱对电子商务的盈利点的整理是基于一个前提，那就是，我提供了有价值的服务，就有理由获得收益！很抱歉，在互联网上，事实不是这样，淘宝有100个理由收费，但是拍拍是免费的，淘宝就不敢跨出这一步。看看易趣是怎么输给淘宝的。6.因为持久呆在一个靠背景，靠关系吃饭的行业，阿朱在整理电子商务产业链的时候，恰恰忽视了最重要的一个事情，用户是怎么看的。所以，理想主义的成分非常大，认为我提供了所有的服务，理所当然就拥有了所有的用户，真的“理所当然”吗。马化腾拥有几亿QQ注册用户，但是旗下的拍拍和搜搜并没有理所当然的拥有这些用户，百度也是，百度hi和百度im，百度有啊也没有理所当然的拥有他的贴吧用户，为什么？7.阿朱并不真的了解一个大公司，比如千人以上的公司，在管理，产品决策等方面的困境和问题。因为他的确没接触过。所以，阿朱的确很好的解释了如何在有效的资源前提下发展产品，发展业务的问题，但是却仍然仅仅适合“软件作坊”，而走不出去。8.一个很关键的事实是互联网上的成功产品，往往并不是靠代码量；而在传统企业软件，代码量几乎是无法省略的，为了证明这一点，caoz可以举几个例子，caoz恰恰做过一些不太成熟的产品（按照严格的软件工程概念，很不成熟），但是这个不太成熟的产品被几十万网站使用，每天处理请求以亿为单位，在三年长的时间里是互联网同行中覆盖率的第一名。那么这么一个产品开发了多久呢？两周！一个人！(当然后来又花了很多零碎的时间打补丁，但是总代码量不过两三千行而已，核心代码不过几百行)。 此外caoz有一个小朋友，叫做 吴洪声 ，他提供的产品为几十万站长服务，每天处理请求以亿为单位，也是一个人，很短的时间做好的。caoz恰恰以前做过oa系统， 仅源代码就有2M，做了半年多，还是垃圾产品，而现在做的网络应用，源代码20k就足够成为一个热门应用了！ 这就是为什么互联网越来越强调“敏捷开发”而在传统软件领域往往不可推广的原因。以互联网上最成熟的应用Discuz为例，嗯，目前经过几年的积累和发展代码量也不少了，但是如果我们回溯一下，discuz最初成功的时候有多少行源代码？和传统的企业管理软件真不在一个数量级上。互联网更强调需求的变化，应变性和负载支撑能力，功能点仅仅提供一两个热点即可。最流行的互联网应用你去看，用传统软件的观点看，功能点少的可怜。所以，互联网往往出现个人英雄，完全不懂软件管理，不懂软件工程，不懂流程控制的小孩子，写一个东西出来，也没有市场费用，也没有销售，也不做关系，因为人们喜欢用，很快的通过口碑扩散成为主流应用，并且通过其他模式的捆绑获得收益，这样的例子数不胜数。很抱歉，阿朱是看不到的。综述：《走出软件作坊》的作者，并没有走出软件作坊，他在帮助其他朋友规划职业的时候，应该也继续考虑一下如何规划自己的职业。最后，回答黄一孟小朋友一个问题，黄一孟 一直想的是，如何把他的小公司，一个山寨网络公司，做大，做强，做成一个伟大的企业，也因此不断寻找各种书籍来充电，那么caoz也琢磨了两周，最近突然豁然开朗，推荐一本书给所有有这样的想法和困惑的人，那就是《毛泽东选集》。要想在中国成为一名伟大的管理者，强烈建议通读《毛泽东选集》。

部分摘录以及自我总结

1 企业信息管理系统开发过程中，软件实施时，涉及数据的整理，录入，这个过程应该交由软件使用方来做，这是一个说服对方的过程。2 软件的维护是通过局域网软件来实现远程控制，而不是哪个客户端有问题就跑到哪里去维护。3 有关软件版本跟新的一个好方法是：开机自动检测，检测到新版本自动跟新同步，如果计算机跟新失败，则要求用户手动跟新，跟新之后才能正常使用。使用不同版本的软件可能导致录入数据不一致，出现问题不知道是哪个版本软件出了问题。4 客户支持：书中讲到开始使用电话，费钱劳人又讲不清楚又没有交流记录，后使用QQ一对一的支持，QQ聊天有聊天记录功能，由于一个人不能同时支持多个客户。后来使用QQ群进行支持，对有问题的客户来说是多对一（有些遇到过同样问题的客户也会热心回答）的进行支持，对公司的支持人员来说是一对多的支持，这样有什么问题大家可以相互讨论，但是QQ群里会灌水，重要的聊天记录不好找，不能有效利用已经讨论过的方法，所以挂了一个BBS，把讨论过的，系统的方法都总结出来挂到BBS上，共大家参考。最终的方案是：一个QQ群客户和软件公司客服人员交流问题，解决问题，BBS上为总结好的问题，大家遇到问题后可以看看是否已经解决了，同时在BBS上加一个webQQ链接，客户对已经解决过的问题如有疑问可以单独支持。QQ群+BBS+webQQ实现客户在线支持。5 企业信息管理软件相关流程：调研客户公司，涉及，开发，测试，文档，实施，维护。读书过程中自我总结：1 要踏实工作，不要总想着跳槽，如果跳槽绝不能仅仅是为了工资有所提高，更早注重职位的上升。如果职位没有上升，仅仅是工资涨了，在原来公司遇到的问题在新公司也会遇到。在原来公司坚持下来可能会有更好的发展。2 即使自己知道很多，不同场合，不同人面前，说话要特别注意，只说该说的，不说知道的。

作坊里出来的第一个大项目

人生中第一个大项目，是跟着导师做的是一个人力资源管理的系统，从这个系统的开始，到现在系统终于验收了，历经一年的时间。这一年的时间里，不断用错误和失败验证了软件工程的正确性，从多方面多深度验证了理论来自于实践这个基础的马克思主义观点。从对这些理论的不屑，到现在对这些理论一知半解的膜拜，迷茫依然存在。昨天在经典的十层理论里头（不记得来源了，挺经典的那片十层上面是上帝的好像有关程序员的牛文），看到了有关唯心主义宿命论在现代物理学里得到验证的观点，一下子结合到了与这本书进行暧昧的过程中。从这本书中，作者提供了如何走出作坊的一系列不成系统的理论，并用实例佐证，可是结合到上面提到的宿命论，我深深怀疑，作者的成功或者说相对成功，是宿命，还是主观能动性在现实中的幸运。如果说所有的分子运动都是在大爆炸的一霎那决定的，所有人的命运都是在自己的重重重奶奶或者爷爷出生的时候就决定了的，那是否看过这本书，或者是否认真学过软件工程，都不能成为是否能够成为一个成功程序员的条件，那我现在做的工作有何意义？再多的技术书籍也不能决定自己将来要做的工作吧，我有点儿确认。

笑来力荐：阿朱是个心智力量相当强大的人

http：//www.xiaolai.net/index.php/archives/1981.html一个人最大的力量来自于他的心智。阿朱是个心智力量相当强大的人，这是我对未曾谋面的阿朱之印象——谢谢周筠老师送我阿朱的新书《走出软件作坊：三五个人十来条枪 如何成为开发正规军》（点击这里开始阅读该书博客连载版本；点击这里购买……）。其实，并不见得一定是做软件的、带团队的人才可以读这本书。我觉得所有正在做事的、想要做事的的人都能开卷有益。我个人的观察是，计算机领域几乎是目前所有领域中“现代运筹方法论”运用、发展最为淋漓尽致的领域。在计算机领域里先行的各种行为模式、选择理论、协同机制、优势策略，正在慢慢向各个领域扩散。在昆汀拍《低俗小说》的时候，大家确实应该震惊于他的天才；可是，在《无间道》推出的时候，其实，更多的是计算机领域里的“面向对象编程”的思想被应用到剧本编写领域中了而已。理查德•道金斯在《自私的基因》里解释人类的基因如何“无意识”地发展到今天这个高度之时，也要借用程序员如何设计出最终能够打败国际象棋世界冠军的程序的例子才能够透彻地说明。就算是没时间甚至没兴趣去读完整本书，我也强烈建议读者起码读读这一篇：《一分钟先生》。（我过去读过一本老外写的管理时间的书籍，就叫这个名字《一分钟先生》，不知道阿朱这篇文章的题目是否来自于此？）不管是在任何领域里，能够驾驭时间的人习惯大致相同：列表、笔记、思考、不追求完美……阿朱的文字，随性、粗糙，但真实、有效。

要让主动性成为生命的一部分

最开始接触是在网络一读就停不下来，一口气看完所有的博文，然后决定买一本。简单写下自己的感受，希望更多的人因此而读这本书，并有所收获。1.主动性。书中时时刻刻都体现并强调了人的主动性。正如有句话“逢山开路，遇水架桥”。作者一路走来，不断的遇到问题，不断的解决，同时不断的进步。不管任何人，只要渴望进步，就必须具备主动性。不简单的是一种想法，要让主动性成为习惯，成为生命的一部分才行。2.选择。作者讲了很多。开发、实施、团队建设、CTO等等，我们需要什么？我们自己在做什么？不用每个细节都看，关注与自身相关的那一部分就好。看到有的读者对书中某个部分的内容进行了校正和扩充，其实任何一个部分的内容都可以单独拿出来讲，成为一个理论体系或科学体系。想一个章节讲完确不现实。我认为这个更像《计算机导论》，把每个环节的事情都展现一下，同时也提出了入门级的问题和解决的方法。如果读者在现实中遇到问题可以入手，可以研究新的方法解决问题。3.自我培养和训练。读一本书，抑或一句话，双方产生共鸣，说明一个问题：在双方心里都有共识,在听到或读到之前，双方心里都有底了。只有这样才会有共鸣！要解决问题终究还要靠自己。同一个方法换个人不一定有效果。平时应该加强自我培养和训练。

自省的力量-关于《走出软件作坊》

一桌坐着5个人，其中4个是正在管软件项目的，包括我。4个人志同道合的吐着苦水。另外一个制造业管理出身的家伙很感兴趣的听我们发泄，估计他觉得这4个人倒的苦水特别不可思议。不管其他行业的人觉得多古怪，软件行业就是这样的。我们的本质就是作坊，只不过是大作坊和小作坊的区别，一个作坊和多个作坊的区别。所有人都希望软件做的好一点，管理做的有序点，进度可靠一点，这个在其他任何行业都觉得"再正常不过了"的需求，在软件行业的确很难达到。为了证实我上面的想法，我也确实问过很多朋友，这些人分布在各种公司，大型外企，大型国企，上市公司...不吝成本的公司不是没有，能容忍失败的雇主也不是没有。但是当我问到项目情况的时候，所有人都大摇其头。好吧，在我长时间的工作中，不是没见过非常成功的项目，只是确实太少了。比起好高骛远，想google如何，微软如何，不如先看看眼前，承认我们生活在作坊里面吧。当然，最终还是得找到一个适合自己企业的办法，把项目管起来。事实上，软件作坊并不丢人，无数伟大公司都是这样起步的，这对于未来的事业只不过是个开始点，而绝非终点。想到未来，自省的力量就变得更为重要起来。阿朱的《走出软件作坊》，讲的就是这么一个过程。一个小公司，到底怎样才能找到适合自己的管理方法，怎样成长起来。从《人月神话》第一次出版，到现在已经将近30年，在这已经相当于整个计算机历史一半的时间里，我们碰到的问题没有变少，甚至完全没有改变。《人月神话》提到的所有问题，仍然是目前困扰我们的问题。所以，阿朱这本书的意义与其说帮你解决问题，不如说帮你思考问题。这也是我所谓的自省的力量。承认现状，认识不足，勤于思考，由小及大的解决问题，这才是正确的道路。阿朱为我们展示了一个工程师自省的历程，思考问题的方法，以及向管理人员转换过程。我想，原封照学，或许能解决一些问题，但并不够。其实我们的最终目标也并非走出一个作坊，而是提高可靠性和可用性。请你在阅读时，拍着桌子喊"就是这么回事！"的时候，别忘了想想自己面临的问题，试着像阿朱展示的那样，多思考一些，多自省一些，如能借此有所提高，则善莫大焉！

一本有干货，但被稀释的博客书

前天看了阿朱续写了那个《CRM下午茶》系列文章，与自己一直专注的客服务管理有所交叉，于是晚上花了两个小时把他那本《走出软件作坊》看完，几点心得与体会：* 这本书，应该是他的第一本书，还缺乏写作技巧，不太懂得怎么写书。这本书不是以书籍为目标写的，而是按照写blog的习惯整理的，blog只需一篇文章说明一个问题，写书却需要凝练* blog的写法是：面对的读者很广泛，写的可以很“科普”，不怕前面做大量的铺陈和介绍，只要在后面收尾的时候点睛，结尾处点化了主题，就是好文章、有用的文章。但是书则不然，书要求凝练、系统、有结构。* 阿朱这本书确实有干货，但是被blog写作的发散性稀释了，大家按照读书的习惯读到却是一本博客书，自然不能很快把握要点，直取精要。于是这本书，就显得泛泛了。* 小作坊式的成功经验往往是很难复制的，因为成功的本身往往有很多随机性，因此很难总结出规律理论。借用技术术语打比方——也许阿朱的经验很丰富，这些确实也有归纳的价值，但把这些总结出来虽挺好，可若再成为理论让别人复制应用的话，变量太多，“运行”结果自然会bug百出http://blog.csdn.net/lazylorna/archive/2009/03/10/3975102.aspx

看到这么多的5个星，不得不怀疑国内软件开发和项目管理的水平

我同时买了《项目管理之美》和《走出软件作坊》这两本书。本来，我只想买前一本。后一本，是我在JavaEyes讨论问题的时候，好几个人跑来推荐，似乎《走出》是灵丹妙药一般，只要我看了这本书，我所遇到的管理的，工程的问题都可以迎刃而解。我想，既然大家这么极力推荐，我就买本看看吧。实际上，我现在只看了前面的组织结构篇：双龙会——CTO与技术总监人，是人，真的是人——团队文化四套马车——团队配合大长今——项目经理走钢索的人——架构师对于项目的组织架构，这是不是太过于简单了。作者看起来是在实施多于研发的公司干活。这本书，看来只是作者自己的工作总结（所以，就容易以偏概全），或者说是软件开发的故事书，但这本书道出了国内软件开发的现状，值得那些心存幻想比较纯洁的刚走入这个行业的同学看看。反正，看看就好，不必当真。＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝本来给的3分，但是看到如此在网上推销书，并且在豆瓣上的热门评论全是5分这种刷分的行为，我决定只给1分。

“smart，get things done”

不错的书。读了半天，发现有一个句话用在这边书里面非常恰当。“smart，get things done”。作者就是一个解决问题的专家。完全一副兵来将挡，水来土掩的气势。

适合程序员们开阔下眼界

小品文的集合。非常适合程序员们开阔下眼界，编码之余理解老板们在想什么。文中的环境与问题与我现在相去甚远了，不知道将来还会不会回到这种软件开发项目的前线去。

什么是我们应该做的？

先看了《梦断代码》又看了《走出软件作坊》，两本书看完，感觉有点明白了一件事。其实我们应该是做产品的，而不是编程序的。编程序只要考虑程序本身怎么样，和感受编写代码的快感和乐趣。可是作为一个职场人，我们买的是产品。用户看的是我们的产品是不是能满足他的需要。老板看的是我们的工作能不能给他带来效益。就算你能写出全宇宙最高深的程序，可是你不能实现前两者，那你也是不可能在职场和商场取得成功的。在职场我们总会有各种不如意，但是这个地球又不是围着我们转的，我们有什么理由要求这个世界为我们改变呢？生活就像被XX，如果不能反抗，那就享受吧。其实我们总在抱怨，我们没有这个资源，没有那个条件。可是什么都有了，还要我们干什么。再想想，我们手里真的是什么都没有吗？还是我们没有用好？给用户提供好用的软件，给老板创造效益，这个才是我们应该做的。

实践总结

作者展示了要想作为一个成功职业人的心态，对软件行业各方面也有一些珠玑总结，可扩展知识面。——joneguohttp://comm.dangdang.com/member/7010722414649/reviewdetail/2508330/

当小说看，一些零零散散的记录

葵花点穴手 那节里提到的标杆法:和产品设计的用户研究中，常用的Personas（人物角色），在方法论上是一样的，相通的，很有意思，：）根本的目的就是在做产品的时候，提醒自己时刻不忘用户，做到UCD（以用户为中心的设计）文档知多少 最后一句：做项目要“物有所值”，做出“物超所值”的东西来，要么对不起公司，要么对不起客户（客户不满意，到头来还是对不起公司）。我可能不是这本书的主流受众，是当小说看的，也受益匪浅。

很好！

在浙江杭州图书大厦看到了这本书，很不错哦。作为单位的信息管理员，有时候也有做点小小的开发工作，这本书我很有启发。推荐

程序员怎么看这本书

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，是否符合正宗，就不在我们的商业开发管理范畴了。

美人赐我蒙汗药——和讯网CTO江涛赐赠的《走出软件作坊》书评

http://blog.csdn.net/david_lv/archive/2009/04/10/4061404.aspx按：小说中的阿朱是美人，但《走出软件作坊》的阿朱却是北方大佬爷们。但这两个阿朱老让人产生关联。蒙汗药，《走出软件作坊》给人的感觉就是这种感觉，让你翻来第一页不知不觉就陷入其中，跟随作者的叙述而九曲回转，直到最后 一页翻过仍然头脑一片厚重，给人留下太多需要思考和发醒的地方。认识阿朱，是很偶然的机会。阿朱非常热情，很快送来了一本他写的书--《走出软件作坊》。这本书没有任何高深的理论，完全从中国的国内实际情况出发，结合阿朱自己多年做企业IT应用的经验，介绍了作为技术管理人员如何应对国内客户的复杂多变的需求。这本书涉及面非常非常广，从软件开发，到项目管理，到和老板的沟通、团队协作，客户沟通、职业发展等，稍微夸张一点，我觉得完全可以作为国内企业IT应用的中小型软件公司的技术人员的一本圣经了。合上这本书，我的第一个感觉就是实在。对于任何一家国内做企业IT应用的软件公司来说，书中介绍的那些办法，可以马上应用，而且应该马上就可以见效的。不像很多国外的讲管理，或者软件工程的书，读起来头头是道，但真要在实践中应用，却发现寸步难行。国外的大型成熟的ERP软件，在国内的企业里面应用很少有成功的，一个很大的原因在于ERP软件不仅仅是一个软件，还包含了一整套企业管理和运行的思路和逻辑，而国内的企业的管理水平和国外还差得很远。所以阿朱的这些看似比较“土”的办法，却是非常可行和现实的。虽然阿朱给自己总结的第一个特点就是懒，但看了这本书，你就知道其实他只是身体懒，脑子一点都不懒。因为你从书中处处可以看到阿朱为了解决很多问题，动脑筋琢磨出来的好的办法，简单而有效。第二个感觉就是这本书对于技术人员的成长非常有帮助。技术人员通常都是属于智商比较高，但情商比较低的人群，每天只知道埋头做技术，不擅长和人沟通，最后很多项目做下来都是吃力不讨好。这本书里面纯技术的内容并不太多，更多的篇幅讲的是技术之外的事情，比如作为技术人员（特别是技术管理人员）要学会如何和老板，和售前经理，和客户沟通；比如如何管理项目，如何报价，绩效考核以及职业发展等，这些对于一个普通的技术人员成为技术管理人员是非常重要的。目前专门讲这方面的书很少，所以这本书就显得更加难能可贵。国内的企业IT应用的软件行业，是个竞争激烈，客户IT水平参差不齐的行业，所以很多软件企业做起来是很累的。阿朱能够面对这么复杂的情况（姑且不考虑客户要回扣、压尾款等恶劣情况），总结出一套行之有效的应对策略，并且出版发行，确实是这些软件企业的福音，也是这些软件企业的技术人员的福音。我其实一直在互联网行业，和企业IT应用的软件行业还是有一定差距，但N多年前，老板为了收入，也曾经接过一些项目，所以阿朱写的这些问题我几乎都遇到过，但肯定地说，我当时解决得并不好。当然现在我面临的更多是其他方面的问题，但依然还是有一些和阿朱共同的问题，比如程序文档的问题，比如团队管理的问题等等，阿朱的书同样给了我很好的参考——所以，最后我要对阿朱说一声，谢谢。

走出软件作坊

这本书引起了我强烈的共鸣，推荐打算在IT行业有所作为的朋友都抽空看看。作者通过自己在工作中的亲身经历和感悟，向我们描述了一个软件开发过程是如何从混乱进化到有序的；而且在描述的同时，也向我们充分披露了这个过程中会遇到的问题、可能的解决办法、有帮助的工具等实际而具体的内容。虽然在不同的细分行业或者不同的公司中，具体情况都不相同，然而这些实例背后的思想，解决问题的思路却是有普遍借鉴意义的。尤其对研究过项目管理和敏捷开发的朋友来说，你会发现很多地方都是暗合的。其实归根到底，软件开发还是关于人的问题，软件开发的过程就是人与人之间如何组织，如何分工，如何协作，如何互动的问题，专业化、规模化、自动化都是为了更加充分地利用人的能力，减少人的错误，提高人的效率。想必作者是深喑此道，否则也不会写出如此动人的文章。大家还是自己阅读，自己感悟吧！

我的不合潮流的看法

前天买了一本，看到这里褒奖生一片。如果说一些不合潮流的话，肯定会引起一片斥责。但是，我还是想说一点个人的感受。昨天晚上看了关于架构师的一章感觉作者对架构师的理解未免太狭隘了。作者认为，架构师就是公共代码程序员。负责写一些公共代码给业务开发组。难道整个系统的架构不需要考虑么？这不是架构师的职责么？系统的架构都没有，成员分工从何谈起，公共代码又从和谈起？还有，作者着力想表达的就是，架构师开发的代码就是让业务组更快更高效更安全的开发系统。因为都是小系统,这本身当然没错，但小系统就不需要扩展性么？应用范围广的可扩展框架可以整体提高公司的效率，而不是单个的魔个项目，不值得投入资源去做么？也许我的理解有偏颇，希望能有机会跟作者交流就更好了，哪位知道作者的QQ或者Mail？另外，想一起交流的可以加我的qq群：3421086

针对很强，实战经验丰富的书

第一次看阿朱的书，感觉有些章节写的非常精彩，对迷惑的小公司，软件团队，是一个非常有指导意义的书。作者是一个乐与分享、智慧、学习型的人，也相当自信！这本书，曾把链连转给一些同事，期望他们都能从中有益！摘录如下：开发向网游一样盈利模式的软件：开源。谁不愿意开发向网游一样盈利模式的软件：1客户多，市场容量大，未来预期增长还很好。不像做某些行业管理软件，行业就那么多大中小各 个层次的企业。软件这个东西又不磨损老化，买一套直到用的不符合需要。客户对软件费用认知不高，认为一套软件2万都贵。每年的维护服务费用就更别想。这类 行业就本身市场容量小。所以说，市场容量小的行业，所销售的产品一定是高价的，而且能持续收到服务费的，否则就无法支撑一个行业软件公司的持续发展。如果 这个行业还无法接受高价，也没有高价软件的需求，就说明这个行业不能做。做了也是多年坚持白收苦，到头只是一场空。2不给服务费，掐了。就跟网游一样，网游服务器不开，网游客户端就玩不了。你不续费，网游也玩不了。3大量的增值服务，可以带来增值收入。4而且是有时效期的增值产品。如果一个增值产品也是永不磨损，那就没什么戏唱了。就跟点卡一样，没了就需要充值。5 而且是需要大量购买的增值产品，如果只购买一个增值产品就可以了，那么你需要研发多种增值产品。但其实是，研发多种增值产品往往很难。因为惊喜式眼睛一亮 的创新不是天天都有的，大家都是玩来玩去就那么几种模式。所以，最需要的增值服务类似QQ挂机小太阳一样，一个增值产品，看你能有几个小太阳。6不需要人干涉。购买、消费，再购买，完全客户自己一个人自己完成。而且可以24小时x7天的，无论何时何地的支付然后消费。而且都是虚拟数字的消费。这样，即使你和你的员工下班回家睡大觉，你的公司还在赚钱。根据这样的思路，我们发现，现在盈利性极高的网络公司，如盛大，QQ，51.com，阿里巴巴B2B网站，百度无不都是这样的公司。像当当这样靠实物、库存、物流、收款来运作的企业，累哭了也不如前面提到的公司赚钱。在他们眼里可能觉得，一个团队，只要用上先进的工具就会成为一支装备了机关枪的军队。就跟我们的客户一个想法，只要上了这套ERP软件，我们的管理 就上了一个台阶，我们的盈利就会提升。这个想法，真是奇怪，就如同一个人拿了一把屠龙刀，人没砍到，倒是把自己砍伤了。一把好厨子的刀，到了不会做菜的人 的手里，仍然做不出好菜，就这么浅显的道理，但大家还在幻想。我一直在商业软件公司工作，也深深的明白自己的责任就是帮助公司最大限度的利润最大化。(功利、直接）需求如何描述清楚，成了必须提上日程的事情。许多没有经验的项目经理尤其会在这一步犯晕。UML工具、数据库设计工具，需求管理工具，能上的都上，最后也没解决问题，把自己和自己的团队累的半死。我使用了PPT+WORD+脑图+EXCEL的描述方法。因为很多需求都是这个支那个叉出来的。程序员往往想的了这头想不了那头。这就是人的思考的周密性差异。想让人能从千万丝绦中理出头绪，于是脑图软件上场。把各个分支来龙去脉表现清楚。到了描述某个节点的时候，PPT上手。一页PPT相当于一个界面窗口。每页PPT的图形模仿了菜单、输入框、按钮。按钮按下，还可以跳转到其他的PPT页上，和软件操作流程非常相似。PPT让程序员很直观的看到未来软件作出来是什么样子。关于PPT的详细描述，如字段，流程，特殊注意，特殊控制，都用WORD说明好。(这个部分，使用AXture免费原型软件比较好，一个软件解决以上几个软件同使说明的事情，布局和交互流程都能一目了解，还可加注释）我这个人就有个习惯，能改 进我就不在原地踏步。这个改进方法不行，我就继续想其他改进方法，不断尝试不断推进，哪怕一点改进我都要去实现它。量多了就会引起质变。许多人就等着大机 会大改变，对小改进懒的动，我不赞同。我在我的另一篇帖子中也写过流行技术我到底该学哪一样。我大致给大家在这里总结一下：现在社会，主要的开发应用是1互联网网站。主要是asp、asp.net、JSP、PHP、Python、Ruby、Perl。2网络游戏。主要是C++3嵌入开发、硬件开发、通信与网络开发，主要是C/C++。中国大量的家电、数码、手机、电信设备都属于这类。4外包。主要是JAVA和.NET。5企业管理类软件。WEB开发，主要是JAVA和.NET。C/S开发，主要是DELPHI、VB、VB.NET、C#、PB、VFP。所以，你选择了什么开发语言，那么你应聘的公司就有了区别。所幸，我上述所说的五类开发应用，现在都有许多公司。所以，选择其中的开发语言，学扎实，有实际案例经验，人品端正，做人踏实努力积极主动，应聘应该是没有问题的。不过，工资是有高有低。互联网网站公司，大公司薪资福利好，就看你的毕业学校和你的聪明劲了。如果你感觉自己一般，能选择的就是无数的互联网创业小 公司。这类公司倒闭风险大，薪资福利和工作条件可能艰苦，要的人也可能是熟练手，而不是新手。还有一些中不溜的互联网公司，比较偏向伪互联网。主要做广告 推广或网站制作或电子商务线下买卖，做了5-6年了，可能需要一些刚毕业的学生做维护开发工作。现在热门的网络游戏和嵌入开发，工资高、未来发展潜力大，但技术门槛也高。如果你学技术中不溜没有快速成长天分，也不愿意深钻，总想着机会主义，这个流行就学这个那个有兴起了赶快转移学习目光。这种思路，别说这些热门行业，就是那些传统行业也难找到工作。对于外包，外语是第一位置，而开发技术反而是其次。因为外包都是大规模作战，分工很细，每个程序员能做的都是熟练工种，人海战术。尤其一些对日外包的项目，人家日本人连伪代码，函数名，参数名，参数类型都给起好了。对于企业管理类软件，和外包很类似。技术普遍要求不高，常见都是增删改数据库的应用。也是人海战术。不过工资就比外包要低了，因为外包是老外掏钱， 而面向国内销售的企业管理软件售价就低了。而且国内很多公司都是从事企业管理类软件。因为只要有客户关系，就可以做，没有多少技术难度。找工作是好找，但 打一枪换一炮，反复需求修改，一个人捣鼓一个项目身揽数职，让人感觉没多少发展。你觉得依你的毕业学校和你的人品和你的技术学习能力，你觉得你能达到哪个你喜欢做哪个，你就选择定不断努力，不要还在晃来晃去，最后什么都不精什么都看了点，这类人什么工作也找不到。我说：我先给你说说软件开发费怎么报。下次再请我吃饭，我再跟你说如何给实施报价。产品开发由以下阶段构成：1客户调研、客户调研报告编写2功能设计、功能设计说明书编写3开发4测试5帮助文档、培训课程、培训演示版本编写其实，产品开发完毕后，还必须由开发部的文档组对实施部门的培训专员和项目经理进行内训，否则产品知识无法通过培训专员和项目经理传递给客户。这个内部培训也都是有成本的，而客户和你，往往都会遗漏的。由于功能说明书为内部产品开发使用，所以功能说明书不会销售给客户。如果客户非要连功能说明书都认为是他的产品的一部份，那么他也需要花钱买走。这也是文案人员和项目经理辛苦劳动的成果，又不是自动产生的。有付出就必然要求回报。产品开发团队由如下人员构成1客户调研团队2产品开发团队3产品测试团队4产品文档教育团队客户调研团队，由项目经理和培训专员构成，亲自到客户现场去调研。每个调研团一般由2名人员构成，1名项目经理，1名培训专员。由于不同经验的人当 然工资待遇不同，而工作的质量也就不同。所以我们的调研项目经理，也有高级调研项目经理，中级调研项目经理，调研项目经理三个等级。你如果作为客户，你敢 把企业的需求和流程梳理交给一个刚毕业出来的毛头小子么？他对企业的感觉连企业的一个看门人都不如。当然，不同等级的调研项目经理，调研一天的工作费用当 然也是不同的。与之匹配的调研助理（培训专员）也是有不同的经验等级的。调研费用，按调研团队人数和工作天数和他们的工作费用和调研家数计算。出差过程所花费的交通、住宿、餐费不包含在他们的工作费用中。调研是调研费， 这是调研的工作，但出差产生的费用是出差的费用。如果你把这些都整到一块，你的调研费用肯定看起来很高，客户又质问你怎么一天3000块了，还不如报的时 候就清楚的报。哪里都需要钱呀。一般，调研周期为两周。先是调研收集客户现有状况细节，然后进行现有状况梳理。梳理理解后，总结疑问，并与调研方开会，双方就疑问和目标和需求进行讨论。最后是根据多次讨论进行调整，得出最后的调研报告。我为啥说需要两周呢。因为一个企业有许多部门许多岗位。你要把客户的整个组织结构和岗位职责和流程，和他们的现状问题，和他们的需求目标，都需要调 查清楚，而且还要和他们协商统一认可好如何改进，否则你怎么设计适合他们的系统。没有两周的调研和讨论和反复修改磨合，你出来的软件更是痛苦，调研3天， 开发1月，实施和不断修改2月，维护修改和稳定和技术支持3月。最后客户还抱怨你的软件太不稳定，N多需求都没有做，当然不能付尾款了。你不答应他们的需 求，你就拿不到尾款。于是，需求修改更新，发现又引出了其他的BUG和需求，噩梦循环啊。咱们说说调研。例如，调研10家客户。客户分布在东北、华北、华东、华南、华中、西南、西北。调研需要2周的时间。如果遇到星期六日还需要出差进行工作，那么休息日加班费就按国家规定累计。这样来算一下费用。高级调研项目团队，中级调研项目团队，标准调研项目团队，（每个相应等级的调研项目经理每天的调研工作费用+他的每天对 应的餐费交通费通讯费住宿费+每个相应等级的调研助理每天的调研工作费用+他的每天对应的餐费交通费通讯费住宿费）x10天工作日x10个城市，你看看多 少调研费用吧。你用一个EXCEL做个自动计算就OK了。你把这个公式内置到EXCEL中，客户只需要选择自己想要等级的调研人员，填写要调研一家的天 数，再填写要调研的总家数，调研费用自然就出来了。如果客户觉得不能接受，就让客户自己玩这个计算公式，直到他自己都觉得确实没什么水分了作罢（他也不是 变态狂，以榨干软件公司逼死软件公司为乐。所以，他认可的是一个合理的报价，而不是离谱的报价。他认可的合理的利润还是手下留情的）。想想吧。没有跟客户要一点浑水摸鱼的费用。都是大家都能认可和理解的费用。假设，一个在本行业信息化工作了5年的调研经理，他的月薪水达到6000 块应该没有人质疑吧。那么他这个人每天最低的成本就是200元。再说了，这个员工消耗的其他办公费用与福利与税金也是有均摊成本的（企业总不能无原因生钱 吧。钱肯定还是要从客户这个源头来）。另外，我还没有计算调研团队在这2周的调研时间内，还有4天的休息日，如果工作的话，这个加班费用还没算呢。你可以算一下。调研完了，就要开发了。你以为雇佣几个编码人员就能搞定了。那样的搞定也是活稀泥的，最后不断修改的成本能让你把赚的钱都吐出来。所以为了以后不秋 后算账，我们就得从一开始好好做（如果你想赚更多的钱，可以把我给你讲的配置都缩减了。当然，质量和效果也就缩减了。一文价钱一文货，谁也不白给。国内软 件如此现状，就是为了多赚钱，最后把客户给的合适的费用都缩减了，但是给客户报的却是达到100%效果的人员数量和人员素质和人员天数。这个中间差就是个 小九九了）。产品开发团队，一般由以下角色构成1开发总监1名2架构师1名，公共代码开发人员2名3业务开发组长1名，主要代码开发1名，辅助开发1名。每个子系统由3名人员构成。假设有4个子系统，就需要有12名开发人员产品测试团队，一般由以下角色构成测试员1名。假设有4个子系统，就需要有（4+1）=5名开发人员，其中+1是公共代码测试。产品文档团队，一般由以下角色构成1每个子系统一个文档编写与内部培训人员。假设有4个子系统，就需要有4x1=4名文档人员。所以，一个产品开发过程，以4个子系统为例，共需要参与开发人员1客户调研团队 2名2产品开发团队 16名3产品测试团队 5名4产品文档团队 4名共计27名参与者（估计许多人会说我三五杆枪能有这么多人么？楼主真是搞笑痴心妄想白日做梦。我报这个人数，是为了计算一个能达到客户效果的一个合 理人员配置上。国内软件公司往往无法满足，所以效果就不断衰减。不过，我一般都建议三五条枪的企业最好能从实施部门抽调过来调研、文档、测试人员，这样人 数可以缩减，但要做的事情不能缩减，这样效果衰减的就不会很厉害。很多三五条枪的企业现状都是做一单骗一单砸一单，就是什么人也没有，两个开发人员从调研 到设计到开发到测试到实施到支持都这两位老哥。甚至干脆一个人全挑。这样的现状如果不去想办法改观，软件质量和软件竞争力仍然无从提高。）。客户调研周期14天。产品开发周期60天，产品测试周期10天，产品文档周期10天，产品内部培训周期10天。由于产品测试周期和开发同步测试，自己独立出来的10天是综合测试。产品文档周期10天也是如此。而产品内部培训周期10天，是必须在产品文档发布后才能培训。所以总的项目周期会是14+60+10+10=94天，27名参与者。才能保证一个产品（4个子系统+1个系统管理系统）开发的质量。平均每人6000元月工资算（因为有低工资的培训专员和辅助编程，也有中等工资的各职责经理组长，也有高工资的总监，所以拉平6000元，应该也算 比较合理。）。一个产品的开发大约是6000x3月（94天）x27人=486,000费用（这可都是成本，诸位客官都看到了，里面没有加任何企业的利润 点）。再加上30%的毛利，共486,000+145800=631,800。大约63万开发费用和3个月的时间才能保证4个业务管理系统的软件质量和进 度。这些人的成本，你都可以做一个计算公式，明明白白得算。在客户要求的质量、时间限制内，使用多少人，使用多高工资的人，一算，成本就出来了。成本出 来了，再加上你希望的合理毛利，就得出了你应该报出来的价格了。否则，你拍脑门报价，做到项目结束，你还真有可能亏损了。那些被项目拖死的公司还少吗？30%的毛利，剔除销售费用和税金和管理费用，纯利在15%以下。也就是说，年销售1000万，纯利才150万，其他都产生了费用支出。根本无法支撑下一年的生产再发展。这样来看，软件公司确实活的挺惨。这样来深入计算软件公司一个软件的成本和利润，我想那个说600元软件的客户该理解了吧（当然，那些总觉得老板是黄世仁的程序员，心里或许也能舒坦舒坦）。我想答曰：现在的客户都是荤素全收。吃饭KTV洗澡加回扣，这些都是正常流程。但桌下的归桌下，桌上的还要看你桌上的。现在需要的是面上好看面下也 好看，既要捞了实惠还要项目做的好。现在企业打单的竞争都已经不是一两层的竞争了。先开始比关系，发现竞争对手关系也不弱。比价格，发现还是差不多。再往 上加竞争层，比谁的功能强，比谁的售前方案和演示做的好，比谁的实施承诺和服务承诺好，比谁能够客户化修改，比谁能在现场驻扎时间长，比谁派的实力干将厉 害，比谁客户化修改次数无限改动幅度无限。等等等等，比到大家觉得这单子签了也是个擦屁股事，坚持到最后的就胜出。如果洗洗澡吃吃饭给点回扣就能搞定，那 销售就简单多了。过去可以，但现在不行了。未来更不行了，喝酒吃饭玩，那是工作之外的；谈到工作，还要怎么正规怎么来。想混水摸鱼报个价过关，以后出了时 间问题和质量问题，谁的位子都可能丢，这个险没人敢冒。如果你经常经历斗争，那么你会很快找到自己最合适的生存点我判别平衡和矛盾冲突，也一般从人性和利益这两个方面去思考。企业员工间的矛盾，不外乎就是一口气、一个位子、一个面子或者是一点小利。其实最大的控制者还是老板，所有人都是棋子而已。解决了气、位、面、利，就很好搞定团队和谐了。中国人性，阅读历史长河，变化甚少。很多人问我：你当职业经理人，你和老板意见不一致的时候多吗？不一致你怎么处理？我说：我一般会找合适的时机向老板说明我的思路。而且我的思路的出发点和目的点一定为老板利益最大化考虑的（如果你的思路从一开始不是为老板着想 的，那估计什么时候都得不到老板的认可）。所以，我有这个基点，所以我会找时机进言（时机很重要。老板正固执的时候你即使对的也不能接受。老板也是人，老 板也有面子。）。如果老板仍然不接受，我会职业化公事公办的执行，安排人，推动，检查进度，监督质量，消除异常，调度资源，指导方法。我的意见，一般老板 会听30%。而且，我当多年后回顾老板当年的想法的时候，我发现，老板是对的。我想的确实不够高。老板是比我掌握信息和资源多的人，老板也知道内外矛盾和 困境，他就像在下围棋统揽全局，他想的步数可能会影响大局或影响未来的第三步第四步第五步。而我只能看到前三步。如果我也能看到比老板更多的步数，可能我 就是他的老板的。所以老板自有当老板的资本。经过这么多年职业经理人生涯，我还自认自己有一点能力，但老板仍然是老板，我仍然服务这么多年。可见，老板不 是混饭吃的。所以，我总是告诫自己，低调低调再低调，再考虑远一些，不要乱讲。我尚且如此，我手下的员工更是如此。这段话描写的栩栩如生，和我们日常遇到的需求困境如出一辙。中国人的需求很特别，好像事情都特别赶人都特别忙似的，都寥寥数语就以为他的需求已经说清楚而且你也肯定明白了，到底能不能实现，实现后能不能可操作可执行，都是匆匆一个见面一个电话几句MSN几句MAIL然后就等着软件开发出来用。我看到日本人花费一年的时间反复和客户讨论需求，深入到生产一线天天蹲点，还派人拿专业的测量工具来记录，如拿秒表记录操作的时间，拿摄相机拍摄操作流程，有大量的过程检测指标需要15分钟确认一次，很是认真，然后才设计解决问题的软件功能。对于每个操作的软件界面也是反复和客户确认，如何更容易理解更方便操作。我见到许多国内项目经理调研没个方法，东一榔头西一棒槌，需求调研像是开座谈会，一屋子人，有干系的人都请来开会。有最终操作用户，有部门管理者，有大老板，有二老板，有计算机室，好几个部门。每个人站的角度，层次都不同，关注的问题重点也不同，眼光长远也不同，有人悲观有人乐观，有人不懂装懂，有人不懂瞎嚷嚷，有的部门影响力大气粗的不行，有的部门比较势力小唯唯诺诺，有的部门不愿意多干就推来推去反正不是他部门的事情，到底是哪个部门的事情需要大领导来定，但可惜大领导没来，有的部门怕自己那点内部发小财被破坏了就故意找各种各样的困难还说的头头是道，于是一帮人叽叽喳喳，没个结论。有时候开会开多了，实在说不过去了，必须要有一个结论，于是每个人的意见都上了需求本，回来一整理，没法弄。我曾经参与过一个项目就遇到了这样一个情形，最后拖的时间太长，项目主导方认为没什么利益可赚，而客户冲突利益太多，就放弃这个项目了。“表面上看起来好像没有任何一个单独的问题会导致困难，每个问题都能获得解决，但是当他们相互纠缠和积累在一起的时候，团队的行动就会变得越来越慢。”对于问题的我们很难看到本质，不过，如果我们想解决问题，就必须试图先去了解问题。这是《人月神话》中的一段话，我从网上找到的，估计那个项目经理很遗憾没有看到这句话。风水轮流转呀。真不小心，新一轮领导换届，新领导上台。这个项目又被作为领导新政提了出来。（注意，不是政府换届，而是企业领导换届。我从来没有做过政府的单子）这回，项目主导方变成了我们。我成了项目经理。但是，除了这位新领导，过去的那帮人还是那帮人，我仍然要解决这帮人。（我的一位助手笑称这帮人是成事不足败事有余。上一次我是挂名，他是真正参加了上一次的项目每一次开会。这次，我找他做助手，希望他的上一次经验能给我提供帮助）我这次没有像我的助手上次项目一样，让计算机室帮忙到业务部门要这信息那表格。我首先向计算机室要了一份全企业的部门组织结构图。我先看看这个盘子到底多大。我曾经刚出道的时候就遇到一次滑铁卢，半路地杀出来一个部门领导竟然严重影响了项目走向。这次，我把全体部门都纳入思考范围内，了解我这个项目和各个部门的关系。最后我按项目关系紧密程度把客户各个部门排了一张表，每个部门的负责人的名字，联系电话我都要到，每个负责人的年龄，每个负责人的性格，我通过晚上请计算机室没有结婚的小伙吃羊肉串了解了个一清二楚，谁说话算话，谁比较和事佬，谁比较见风倒，谁和谁不对付。想问问他们大老板是怎么看这个项目的，想达到什么目标，他说他也不清楚。我先去亲自找最容易配合我的那个部门（我并没有采用聚众开座谈会的形式，而是单个击破法）。但他不是和我这个项目关联最紧密的部门。但他最容易突破。他和我发了一下午的闷气，有对企业现状的灰心与不满，有对理想做法的想象，希望我能在这次项目中把他的想法全部实现了。不过这次聊天我也受益匪浅，对这个企业的各种来龙去脉了解了许多，使我在以后的小心翼翼项目推进中避免了很多人为的障碍。但这不是我这次找他谈的真正目的。他絮叨了一下午，我临走时才说出了我的目的：我需要把他这个部门的报表和单据收集回去。他很配合，把他的得力干将叫了过来准备安排，我说别了，我跟着他去自己收集，这样我对您的需求也理解的更深更直观一些。于是，我跟着他的得力干将，一位36-37岁的中年女士一一到每个重要的人的桌边，我和每个人都讲明了我的来意，他们将他们手头的报表和单据全都拿给了我。有EXCEL的，有WORD的，有每月PPT述职报告，有纸张的，有电脑软件上的报表都打印出来，有电脑软件上的数据输入，我就帮他们COPY屏幕打印放到我的U盘上。我一个人一个人的边收集边问，通过他们给我的表格，我就大致知道了他们的工作岗位内容。然后，我问：哪些表格是你最常用的。于是，那个人就帮我挑出了好几张。然后，我依次把最常用的，次常用的，偶尔用的报表都分了类。我又提出了问题：哪些报表影响你的考核和奖金工资福利之类？他又帮我挑出来一些。我又对着他挑出来的影响他的考核的报表，拿起每一张问他：在这张报表中，你最关注哪几个指标？他一一指出来。我顺着他的指，边和他交流这些指标的关联关系。然后我拿着这些指标问他，这些指标是怎么的数据是怎么得来的。他就帮我从这一堆的电子的、纸张的单据中找了出来，并且解释怎么输入的。然后我对着每一个单据都问他这个单据的使用频率，是每天、每周、每月、每季还是每半年、每年。是每天（周、月、季、半年、年）的期初做、期末做、还是平时做？哪个频率高？高到什么程度？这样，我就明白了每个人主要真正做哪些事，怎么做，最后怎么考核，哪些事最重要，哪些事每天做，哪些事频率最高。常用的功能，重要的功能，性能压力大的功能，稳定性要求高的功能、数据精确要求高功能，易操作性要求高的的功能，就是从这些提问回答中自然浮现出来的。我的那个助手用笔在笔记本上不断记录，手累的最后回来都说手写的都抽筋，告诉我下次不要这么快，让他好记录全一些。还给我看，为了记得快，字都写的有些现在不认识了，还得靠回忆，整理起来特费劲。我说，行，行，我一定注意。我们回到宾馆后，先制作了一份草稿，粗略的列出来这个部门的组织结构、人员岗位角色说明、业务流程图、考核报表。第二天，然后针对这次项目，把这次项目相关的详细描述出来，并且把核心业务流程和非核心业务流程分开。第三天上午，我们又去了那个部门，针对每个报表间的钩稽关系，每张单据录入的每一项录入要求、默认值、必填项、唯一约束、录入校验、单据状态、可选值都做了详细调研。在交谈中，我们又发现了一些流程，这些流程都是些特殊处理流程。我们也发现了一些异常的操作，是发生特殊业务时候的土处理，我们都如实记录了下来。有时候，你专门问他异常流程的时候，他反而回答不出来。大部分人没有系统性思维，都是以事论事，讲到哪里想到哪里。所以发现异常流程，发现新流程，全靠调研人自己细心发现和甄别。可能，他无意的一句话，你直追着下去就会发现他日常处理的空白和漏洞和矛盾的地方。第三天下午，我们继续工作，单个人访谈，把每个人工作中认为最想解决的问题都提出来，但只能说5个，能想到哪些就说哪些，我们一一记录。第四天，我们把我们过去画好的组织结构、人员岗位角色说明、业务流程图，经过昨天的调研，又修改补充了一些，在整理的时候，我们用红圈标好了业务处理漏洞和矛盾的地方，并且对这些地方都提出了改进建议。把他们每个人认为最想解决的问题都考虑进流程和业务单据报表中，建议增加什么流程、建议增加什么单据、建议增加什么报表，谁来做，怎么做，谁来监督，怎么考核。一份优化好的流程展现出来了。第五天，我们又去了客户那里。这次，我们组织了部门座谈会。我们给他们整个部门都讲解了我们梳理过的流程现状，给他们说明漏洞和矛盾，给他们说明我们提出的方案。座谈会非常顺利，全在我们的意料掌控之中。他们非常惊讶我们能在短期内画出这么专业的流程图，其理解透彻度比他们自己还要清楚。而且对他们问题的把握准确，对他们问题的解决思路之巧妙，都不禁赞叹我们。每个人的疑问和建议都融入了我们的流程改进思考之中。客户部门给与了我们很高的评价。接下来，我并没有把这种方法扩展到其他客户业务部门的调研。而是我把这份调查报告又给了他们大老板演示了一次。他们的大老板从来没见过这样专业的调研，赶快召集各部门头头都来开会，乐的喜笑颜开，大赞这钱花的值，他们只想到上套软件，没想到上软件讲究这么大，他们自己都没有如此明晰专业的流程图。他们的大老板赶快让我给他也COPY一份，如获珍宝。有了大老板的肯定，我做一个部门的调研，就给他们的大老板发一个报告邮件。邮件抄送给调研的业务部门负责人。我所有的调研一帆风顺，各个部门配合极好。上一次项目的扯皮推搡都不见了。我的助手说：你这个人有点邪门。我一笑。

很有启发，很不错

太牛了!也不知道人家作者脑子怎么那么好,这平时干的嘛、管理理念、软件公司的概念一一说的很清楚，很通俗，很让人赞同。看了它就好象你一直身临其境一样遇到的是你的问题，其发展理念和管理过程确实适合中大部分中小型软件企业。呵呵，很有启发…….如果作者能再再职业发展规划上讲讲,在行业里比较好发展的领域,说说自己的见解就更好了,起码对我周边的很多人都会有帮助. ——lijinghui书真的很不错！我也管理着一个20人左右的团队，非常认同阿朱的“润物细无声”的管理理念。昨天书到手，读了两章，我就确信这书对我会有很大的帮助！谢谢阿朱！！！ ——yialong 摘自http://www.china-pub.com/508874

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

wow，My God，当当终于销售《走出软件作坊》了如果还有人不了解这本书内容的，可以看我的blog上的部分草稿：http://blog.csdn.net/david_lv/archive/2008/02/28/2127299.aspx这是第一章的草稿，在我的blog的4月、5月、6月、7月、8月的blog中有更多的草稿可以预览。但纸版书仍然比网上草稿多40%的内容，快多一半了，所以还是推荐阅读纸版书，而且网上的草稿是过去自己笔记的整理，没有经过专业编辑，所以思路有些混乱，结构不够清晰

为什么?!

看完了这本书,我想的更多的是为什么?一. 为什么项目做不好?既然是软件作坊,一般来说,都还是谈不上什么软件产品的.能说的,也就只有项目而已.但是,为什么项目做不好?在我的第一个项目中,带领10余程序员工作大半年. 得到的,不仅仅是客户的白条和责难.更多的是,让一支生机勃勃的开发团队几乎信心全毁.为什么?在看到<<走出软件作坊>>之前, 我一直在苦苦思索这个问题.我们的团队工作非常勤奋,每天都是毫无怨言地工作到11点.完全没有休息日.甚至完全是按照标准的开发方法和流程来进行控制.但是,客户仍然认为队伍在偷懒,人员投入不够.一度矛盾极端激化,为什么?当我看到"四驾马车"的概念的时候,恍然大悟了.开发团队 不等于 一群程序员.核心开发人员必须保护起来.必须由一个专门的人以文档,ppt或者其他的方式来保证和客户的沟通.按照这个思路下去,就发现不是人不好,而是没有把人用好.对于一个小的开发团队来说,尽管麻雀虽小,但是五脏必须俱全.所谓公共代码开发员,简直就是一台汽车的引擎.他不应该被客户的责难和需求改变而影响,更多的,他要做的就是保证系统的稳定. 相应的职责理清楚之后,起码你能保证由一个人员是心态平和,积极稳定.而不是后院到处起火,所有人都心浮气燥,乱作一团.为什么项目会做不好?抓住最关键的问题了吗?二. 为什么没有人?软件作坊里,往往会出现,做什么事情好像就只有那一两个人能干,其他的人好像都干不了,也不知道什么时候能够成长起来.稍微能干一点的人弄不好还会跑掉.为什么? 小公司到底应不应该有企业文化?怎么才有企业文化?企业文化能够留住人吗?阿朱说,其实,人对了,世界就对了.深以为然.我有一个员工,生性纯良,工作非常努力.但就只有一点,似乎没有怎么长脑子.没有见过的东西,完全不知道怎么做.大家都很郁闷.他每天提心吊胆.带他的小师傅天天发飙.觉得说,这个世界上怎么能够有这样不会动脑子的人.越是骂他,越是质疑他,他越是兢兢业业,连路都快不怎么会走了.但是,在降低了对他的期望值,让他先做重复性的工作.没有见过的东西先帮他做个样例,然后让他照着做.多鼓励他做的好的地方.三个星期之后,我竟然没有听到这个小师傅的抱怨了.反到开始说,这个家伙做重复性的东西还很像回事.现在省心多了.本来就是嘛.虽然这只是我按照阿朱的方法做的一个实验而已,但是,时间加上努力,事情发生了改变.为什么没有人?你觉得呢?三.为什么没有事业?有了项目,有了能作项目的人.为什么没有事业?为什么还是简单重复,客户不断改变定制,突围总是遥遥无期?为什么?你真的理解了你的行业么?你真的理解了你的客户么?阿朱说:1自己的企业是否经常深度参与行业会议，和行业专家在一起，和客户在一起？2自己的企业有没有行业模型可以成书？3自己的企业中有多少员工来自客户行业？4自己的企业的成功案例集多厚？成功案例中有多少知名企业？所以,为什么没有事业,你觉得呢?四. 你还想要什么?在阿朱的会上,我问了他一个问题.为什么明明知道企业应用软件行业的利润率不高,还是会选择做这个行业?他说,的确如此.金山的雷军也这么说.这个行业会有发展的瓶颈.但是,他仍然相信,传统的产业机会巨大,信息技术的创新只要应用进去,哪怕只有一点点,带来的改变和机遇都是巨大的.所以,他愿意做这样的努力来看到这件事情的发生.我佩服这样有理想的人.

很不错的书，不过不能教会你成为正规军

里面介绍的方法是土八路级的，打打鬼子皇协军没问题 ；）作者在书中总结了一些处理特定问题的最佳实践，也可以供读者直接参考套用。有心的读者可以摘录整理出来，定期回顾一下也应该能受益不少。对于不在民营国有企业里工作的软件开发从业者，虽然对书中某些实践无法尝试，但至少通过读这本书还可以了解部分同行们所处的状况。除了经验总结和最佳实践之外，值得学习的作者的思路。贯穿全书的是主线是作者认识问题、分析问题、解决问题的思路。这正是本书的可贵之处——作者不仅把对于多年职业生涯中所遇到的问题困难原原本本呈现出来，更进一步把他分析解决问题的“是什么-为什么-怎么办”的过程告诉了读者。每个人都在自己的工作过程中遇到过问题，如果你能很好得解决每个问题，那么你很有可能（只）是个好员工。像作者一样善于分析解决问题，不断思考总结，坚持写作推销自己才会有更大的进步。

专业化是唯一出路 ------<<走出软件作坊>>读后感

专业化是唯一出路 ------<<走出软件作坊>>读后感专业化是唯一出路 ------------<<走出软件作坊>>读后感 以前曾经在网上看过<<走出软件作坊>>的连载,昨天终于买了一本书,一口气通读了一遍,确实是一本难得一见的好书. 这本书最重要的价值,在于真实两字,无论引用事例,还是分析过程,讲的都是作者自己的真实感受,这是最难得的.因为人们在写东西的时候,往往喜欢掩饰自己的真实想法,有意无意拔高自己的境界,简单来说就是虚伪成风,最后你得费半天劲去猜它想讲啥. 作为作者的同龄人,对于作者提出的很多观点和想法,我颇有同感,对于工作中遇到的现象,也是认同的,但对于他提出的解决方案和思路,我却不太认可. 软件作坊的产生,是有它的历史背景的,在当时的时代背景下,电脑是高科技的代表,根本不具备象今天这样的人力资源情况,我们当时也不具备今天的互联网,交流环境,大环境也都不一样了,回头来看,当时产生软件作坊,并且发展很大很快,是一个时代的必然.在当时的情况下,无论做怎样的决定,最后恐怕都会走到软件作坊,一个师傅带几个徒弟的状态. 今天我们谈论走出软件作坊,那么首先要看看,整个世界的状态发生了怎样的变化,IT业又发生了怎样的变化,软件行业本身又有那些变化,具体到行业管理软件又有那些变化,在这个前提下,才能谈到该如何走出软件作坊,如何组建正规军,如何扩大规模,走向世界. 我的看法是,在经历了早期的混沌状态,混战状态以后,未来的软件行业,将会向其他任何行业一样,迅速走向专业分工,纵向整合的时代. 具体来说，就是软件本身,会按照它的生产阶段来进行专业划分,譬如有人专门做咨询,和客户进行规划,花多少钱,以多大代价来做一个软件,采用何种架构,如何整合.这就是目前IBM力图进入的领域和市场.有了咨询成果,有了一个确切的目标和行动路线.下一步才是基础架构的采购搭建,基础平台的采购搭建,通用软件的采购搭建,然后才是客户化开发. 系统开发完成以后,会交到专门的维护公司来进行维护,升级. 简单来说,软件行业目前出现的问题,根本上来说是分工不足,一个公司如果啥也想干,啥也必须干,最后必然是啥也干不好,啥也白干.而这就是目前中国软件业的现状. 要解决这个问题,只有走专业化分工的道路,一个公司专注于一某一方面,把自己在这一方面的优势发挥到极致,各个不同方面的公司相互配合,才能有钱大家赚,有肉大家吃. 非常遗憾的是,对于专业化分工这个问题,作者在这本书里面没有提到. 一个项目实施型的软件公司,既要做咨询,又要做基础架构,又要做开发,又要做维护,又要做测试,这么多工种凑到一个公司里面,每个工种要求不一,各有特点,相互之间来回扯皮,相互斗争不止,加上人员不断流动,那里能够有任何的积累和沉淀? 这是典型的狗熊掰棒子,一边掰一边扔,最后手里永远只有一个. 如果比到个人身上,就好比今天学一个语言,明天学一个语言,后台再学一个语言,贪多嚼不烂,最后会几个语言,最多一个. 专业化分工,找到自己在市场中明确的定位,这是走出软件作坊的唯一选择. 欢迎和我联系,交换意见. email: webdw2009@hotmail.com

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

这是一位网友在QQ上给我的留言，我个人感觉他的困惑许多人也有，所以发了上来我已是第三次在博客上翻阅这部著作了。每次看的时候总是很心动。但看完后，发现感觉我没有多少变化。如今我已失业了。项目开发了一年，始终开发不完。老板下压，客户不满意，下属也闹。我成了众叛亲离的人。如今我只能走出公司。回过头来又看了一次你的博客之后。有几个问题想请教一下你。我想起你说的四架马车。我想你的成功与你当时的环境与背景有关吧。如果我照搬你的四架马车，能成功吗？我怀疑这点。我是做网站建设，从业工作有3年了。2008年公司给我机会让我带团队开发。做一个房产项目，前后开发了10个月，客户还是不满意。后来团队散了，我出局了。以这样的结束。项目失败，我得到很多经验与教训。但现在却不知道怎么办。很多道理你都讲了，我也听了。但实施却很难。难点：第一。我想带好一个团队。但一个好的团队是什么样的。我不知道摸索中前进在找，很慢有时候还走弯路。感觉我就像在模像。第二。给老板带来利润。我自己却很没信心。不知道做什么样的项目能赚钱，怎么赚钱。我总以为技术员就是把软件技术做好，质量做好就好。但赚钱的问题，我骨子里想那是运营部或是市场部的事。但如果说让技术部产生利益却实不知道怎么产生。团队的利益在哪呢？ --------------------------以下是我（我是阿朱，上面的是网友的留言）的一些个人观点什么是好的团队，我并没有去刻意追求。我从跟随老板创业一路走过来，很多大家现在看到的结果都是我们在行进过程中被逼无奈而做出的，我们要活着，这是我们最唯一而清晰的目标。我们也不追求什么正规与不正规好看与不好看，凡是影响我们挣钱的我们就要解决。解决来解决去就形成了如今这样。对于研发管理来说，我所有举措围绕的目标就是：进度、质量。就这两个。我们没有资源，即使现在公司长这么大了，但是我们想做的事更多更大，永远都是资源不够用，员工的素质永远低于我们要做的事情的期望。但是我们仍然要做事。做的比竞争对手快，质量比竞争对手好，项目管理让客户感觉井井有条，改变比竞争对手快，态度比竞争对手好。就是这么简单。我不需要比中国任何一个公司都好，这没有意义，我只需要在我的这个行当比其他竞争对手跑的快就行了。我得到客户的单子，他没得到，我的公司活着，现实就是这样。我们没有太多的目的。我们做项目管理做测试做文案做UI，都有专业的岗位，不是为了分工明确，而是为了让我们的产品议价能力高，客户不能大幅度砍价。我们当初招文案人员，就是由于软件就一个软件，这样的一个裸奔的东西怎么能让客户心甘情愿付出几万元呢？所以必须做好包装，最好文档能打印上千页，做成书，然后一个大箱子给客户，沉甸甸的，让客户觉得安心。软件是一种难以触摸的东西，所以客户的购买心理就会比较靠后，所以必须要给客户手里塞一个实实在在的东西，让客户的购买心理增强。我们只是想让我们多卖钱而已，没别的想法。老板挣钱我们下头人才能挣钱，给人打工就是这样。大河都干了，我们这些小沟沟怎么会有水呢？我们公司一向提倡全员营销，而不是只有销售部门才承担销售任务。包括我们的服务支持部门都有销售任务，必须在做客户服务的时候对客户做老客户营销。这就是活着。客户对你的质量很不满意，那么你就需要找一个测试人员。如果客户对你的项目管理很不满意，那么你就需要找一个项目经理。如果你的客户觉得你的软件不值那么多钱，那么你需要做好包装，从软件UI到文档，到培训，到人的穿着打扮。客户觉得你像IBM，才会付给你类似IBM的钱。就是如此。

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

我读书有两个习惯：一是习惯于跳着读，书买回来后先看目录，找到自己感兴趣章节先看。二是习惯结合自己的情况来做对照，想想自己是怎么做的？看看书里是怎么写得？哪些可以借鉴，哪些不一定对。阿朱同志的大作《走出软件作坊》买回来后我还是按着这两个习惯开始阅读，首先看引子《这本书适合谁》，然后看未来发展趋势篇的内容，然后挑着几个自己关心的重点篇章进行了阅读。书读完了，忍不住向公司内的朋友推荐，我是这样介绍的“一个从事管理软件领域多年的家伙写的书，书里提到的很多问题咱们公司都碰到过，很值得一读。”，朋友问我，“有没有一套切实可行适合咱们公司借鉴方法呢？”，这一下子把我问楞了。思考了一会儿，反问到“这个世界上有这样的方法么？”管理软件信息化这碗饭不好吃，相信这是业内朋友的共识。把企业管理理念、操作流程、利益平衡这些装到一套系统中，本身听上去就是一件玄乎的事儿，更何况负责实现这项任务的人，在知识积累、社会阅历乃至生活经验方面的又是一帮毛头小子。听上去简直是不可能完成的任务。解决这一问题的出路在哪里？就象在武侠小说里，看到一本书，背上几个秘诀，吃个果子或者大蛇什么的？瞬间就成为绝世高手了。很遗憾，答案是“无解”，或者套用一位软件界前辈的话“没有银弹”。通读阿朱的书，发现他对软件企业运作的方方面面都有涉猎，但很多都是开了个头，提出了几个小技巧，好像没有写完，但又不知道如何写下去。这不应该怨作者，我想阿朱要做的就是提起一个话头，引发我们的思考，具体如何操作还是要靠我们自己。因为这就是世界的本来。

不可多得的一本好书

在我看来，这是一本不可多得的好书，囊括了一个软件公司的方方面面，很多内容都是实打实的干货。最为可贵的是，针对软件公司的各种常见问题，书中都给出了指导性的建议，这是非常务实的态度。阿朱的博客我也一直在关注，他从宏观角度分析问题的视角，以及独立思考的精神，都给我留下了深刻的印象。阅读此书不但可以帮助有志于从事这个行业的新人获得大量宝贵经验，有助于选择自己今后的发展方向；而且对于阅历丰富的行业老手，相信也具有一定的参考价值。书中列举了大量实际案例与常见行业问题，以及对应的深入分析与解决建议，真是物超所值的。如果您正在找寻一本中小软件公司管理方面的书，既要有深度又要有广度，还要完全符合当前环境，我相信此书是理想的选择。

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

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 版本管理工具这已经不是个新鲜的话题，但这里再强调一次。源代码、设计资料、手册、其他文档等这些软件构造过程中的产物，它们有一定的特殊性，所有资料将不会是一次性就完全正确，所以它们是在整个软件周期中逐步成熟起来的，其中每个阶段都是重要的成果记录，所以版本管理是团队开发不可少的利器。

走不出软件作坊

管理学相对于科学更像是艺术，但总的来说事实有一些共同的原则的，作者身处特定的行业，虽然局限了视野，但是世界上除了圣经，没有任何一本书是写给所有人的，从实用主义的角度，作者的现身说法不能照搬，但值得借鉴

品走出软件作有感

独座火车窗旁，手捧《走出软件作坊》一书，伴随火车的前行，把我带进了该书的第一篇章：双龙会--CTO与技术总监。 没有华丽的词藻，更没有任何理论条文，完全是一位前辈向后辈讲述自己的工作历程和心得体会，看完这篇，我不禁沉思，沉思自己这些年的工作经历，有多少可以去历练？有多少可以去总结？自无语回答！或许一本好书就如同一道良方，每当您夜深人静的时候，细细品味，洗涤您的心灵，从而认识自己，感知自我！ 实际工作中，我们更多地看到得是个人对公司的抱怨，部门与部门之间的抱怨，而很少对自我有一个清晰的认识，书中提到：作为一个领导层，如何得够得到老板的赏识？个人的人格魅力，个人的管理能力，个人与老板的眼光及整个公司的战略是否匹配都至关重要。然而作为我们这些职员，能否领悟上司的意图，是否可以快速响应上司的决策？您做到了吗？请记住：意图明确，就必须快速执行，而不要有太多的抱怨！因为抱怨只能让自己丧失信心，丧失斗志！ 牢记：“因为老板给您的资源，永远小于您干事需要的资源”

终于完成对阿朱的承诺，我要出《走出软件作坊》的售前实施版

《走出软件作坊》我是认真看完了，写了一组书评，整整16篇。阿朱搞研发管理，但对售前实施都介入很深，总结也很经典，我呢是搞售前实施，和公司开发团队博弈多多，阿朱写《走出软件作坊》，针对公司。我提出一个命题，仅仅是公司理念上升，没有职业化素质的兵，怕也难走出来。所以我要写一本给兵的书，本来想叫《项目经理九阴真经》，结果编辑说不好，和谐之后就成了《超越对手-大项目售前售后的30种实战技巧》。当初和阿朱打赌，说他的书大卖的话，我的书应该也能，现在出来，到底谁的书更受市场认可，这个要读者说话。推荐大家也去我这本《超越对手-大项目售前售后的30种实战技巧》豆瓣评论去看看，http://www.douban.com/subject/4195531/两厢对比，也许更有趣。对了我做一些资料分享，都是和大项目有关的，大家看了就知道了。

个人感觉的3点不足

1. 有些东西感觉还是没说清楚,比如激励考核那地方说的就太少2. 还有就是多是行业软件方面的经验,有些东西不具有一般性3. 未来趋势里讲的东西对我来说完全没有吸引力,还不如多讲团队,讲绩效考核等等

强调不可能万事俱备，重视老板之于公司的影响

组织结构篇：主要围绕两个观点展开：1、不可能万事具备。2、一切以老板为中心。忽视制度与规则，比如“好的人，才会有好的制度，并且保持好这个制度，毕竟制度是人定的。”适合于小公司，符合“软件作坊”的特点。从管理学的角度说，这仅仅是处于制度发展的初级阶段。《心灵、自我与社会》：管理型的政府是一个例证，表明一种明确的进步，即从极端依赖对政治领袖的个人关系、依赖各党派对负责人的忠诚的组织，进步到以政府应当在共同体中做些什么为基础的合理组织。一个团队的好与坏，就在于团队的创建者和第一任运营者。企业文化就是老板的性格。

一本写实的好书

　　阿朱描述了在软件作坊里面“混”出头来的技术人应该具备什么素质、心态和做事方式。 的确是一本写实的好书。 这个“实”就是中国的现实，任何一位欲投身其中的青年都要认清这个现实，越早越好。　　　　正面去读这本书，就是要准备像阿朱这样思考打拼。也可以反过来读这本书，如果付出了像阿朱这样的努力，得到如书中的结果，还不能让你满意的话， 那你就别趟这趟浑水了，没毕业的选其他行业，已经入行的，趁早做点别的吧。

管理软件作坊

感觉书中的经验可能对于软件作坊的管理有借鉴作用，但是如何走出作坊没有看出来。个人感觉书名改为"如何管理软件作坊"更为合适。作者说十年后再出一本书，我想那时候倒是可以用现在这个书名，目前看起来还为时过早。也许我本就不是书的受众之一，书中的理念和我以前所接受的和看到的管理理念格格不入。例如：我觉得批评应该采用引导式的，而不是书中这种严厉不留余地吐沫飞溅的训斥。应该就事论事，而不是通过一些事情归纳到本质，刻意将人进行分类。也许这本书对于众多的作坊式小公司管理者和被管理者有益，但是对于大公司中想学习管理经验的读者不推荐。

很不错的书，4篇系列书评

读《走出软件作坊》-1自以为看书不用做笔记，匆匆翻过一遍便能吸取其中的精华。其实我不能。自以为可以把事业和感情平衡的很好，做到鱼与熊掌可以兼得。其实我也不能。那就一个一个来改吧。先来读读《走出软件作坊》这本书，每天把自己的心得写上来，看看自己究竟能学到什么。今天读了“双龙会”和“人，是人，真的是人”两篇。“双龙会”讲主要CTO和技术总监之间的工作分工不同，也有阿朱（书作者）对CTO和老板之间关系的一些理解。技术总监负责产品，但是往往目光不够广阔，不能以市场的角度来看这个产品，他也无暇甚至是不屑与其它部门相互协调。技术总监做出个东西，但是要销售出去能变成公司的营业额才能称之为产品，这就需要CTO从高处审视这个问题。但是我个人更感兴趣的是阿朱对CTO和老板之间关系的理解。老板自有老板的想法，职业经理人必须要在老板给的舞台上尽情施展，双方面才能取得最大的收益。这个道理，我想不光是在职业经理人和公司老板之间适用，也适用于普通的上下级之间。经常有人会认为自己是怀才不遇，我想这种人应该首先考虑一下在目前的情况下，上级领导到底是需要什么样的“才”？实际工作中到底需要什么样的能力？要明白上级领导的需求和想法，再有针对性的发挥自己的能力才能赢得台下的喝彩。如果不考虑这个问题，就算是顶级黑客，扔到酒店后厨也还是无出头之日。“人，是人，真的是人”讲的是团队文化。只要进了公司，进入到某个团队，就要接受团队文化的洗礼。刚开始只是普通员工，对于团队文化恐怕也只有接受的份，碰到比较开放的领导，也许还可以提提自己的意见。在这样的情况，只能尽量接受与自己的个人品质和职业操守不相矛盾的地方。但是一旦升任，便面临着建设自己团队文化的责任。对此，阿朱总结了五条心得：抓大放小，让员工自己表演；师傅带徒弟；朝九晚五，禁止加班；搞好环境，整好形象；立即奖励，马上兑现。个人感觉除了禁止加班在目前的小企业无法适用外，其它的都还算不错。此外，很多管理人员在谈到自己的队伍时，总是一副恨铁不成钢的样子，当然对于中低级干部是没有办法决定自己队伍的人选的，毕竟从招聘开始的那一关就不属于自己掌控。但是，必须要清楚不可能存在某个团队全是精兵强将就等着你来领导的情况。毕竟，作为一个领导，员工成长的如何，还是和领导有极大关系。究竟怎么样的员工是好员工呢？阿朱给出了自己的意见：责任心；情商；专业发展，流程协作；相互交流，制定下一阶段目标。这点且记下，等到合适的时候再来评论。阿朱还提到了几种团队文化创建错误的范例，看了看，十分汗颜，我想如果我走上领导岗位，十有八九要犯这种错误。比如“新官上任三把火”，搞很多噱头，比如送生日礼物啊，搞节日聚餐啊。阿朱一言指出其大错：“这与提高工作能力，创造效益究竟有多大关系，让你当领导不是为了搞共产主义的”。深以为是。读《走出软件作坊》-2“四套马车”讲团队配合。书中所讲是常见的小规模的软件开发公司的情况，如何合理的分配各项任务使得开发工作顺利的完成对这些小公司来说确实是问题。但对于目前我所在的公司，暂时不存在这样的问题。毕竟部门的规模还是有的，70人，任务也单一，只是软件测试，除了有时任务较多显得有点忙以外，基本上还是能应付的过来。但是其中提到一些问题和建议还是可以用到的。比如书中提到使用专业和高级的工具未必就能提高工作效率和质量，这一点对我有很大的惊醒作用。我往常还是很迷信这些一些好的工具和好的制度，以为有了这些，整个流程，所有工作都可以正规起来。现在想想，实在是没有必要。如果要提高工作质量和效率，正确的方法是逐步解决工作中存在的问题。往往一些小的管理技巧要比复杂的软件和制度来的有效，简单的Word+Excel+PPT用的好了不比高级的管理软件差。另外，有些工作是需要有一个专门的人来负责的的。这样并不是说这个人有多强能够做多项工作，而是要明确某项工作的责任。“大长今“讲项目经理。先讲了项目经理所需要的素质，然后分析了几类不适于向项目经理发展的人的优缺点。读完这篇我脑海中有几个问题：1：我们自身和职业规划的关系应该是怎样的？是在工作中设定一个目标，比如成长为“项目经理”，然后再以之为目标让自己朝这方面发展？还是根据我们自身的条件来规划和确定自己的目标？2：怎样才能认清自身条件，搞清楚自己的长处和短处？靠领导和同事反馈吗？如何获得这些反馈？这些反馈完全吗？和自己的看法相同吗？不同点在哪里？为什么？目前我对于这些问题的答案是：1：刚走上工作岗位，暂时还谈不上职业规划。3个乃至6个月后，人的各方面素质才逐渐显露出来。适合不适合这个行业，这个工作，到时候都自己也会有一定的想法。1年之内，基本上就“原形毕露”了。这时，领导，同事的看法，自己对这个行业和公司的了解和评估基本上都已经出来了。究竟走什么样的规划道路，领导会给一个建议，这是领导的意见，你自己肯定也有想法，都评估一下。然后再做调整。基本上，如果确有适合公司当时发展的能力，一般都会得到一定的提拔。在新的岗位以后，肯定会出现很多的新问题，这时又是一个循环的开始了。2：人要看清自己很难。没有第三方的参与恐怕都是不完整的。一则可以看看书，从中对照自己，不管是心理类的，还是励志类的，找准自己的类型。二来领导的评价确实一个方面。一般人总觉得领导很可怕，不容易亲近。其实这个也是不太正确的认识。平时和领导多沟通熟了以后就可以询问一下自己最近的表现如何之类的话题，在平时的报告和评价中，也会有所体现。所以说报告有时候并不是多余的，干技术的人总是觉得报告是浪费时间，实际上这是沟通一个很重要的方面。从各个方面要对自己定位，定位准了，职业规划也就好做了。我想这些问题解决好了，职业规划的问题也就解决了大半。以前在学校里谈职业规划，现在看来真正是纸上谈兵。比较实际一点的做法就是在职业生涯中一边航行，一边不时的调整方向。读《走出软件作坊》-3这本书内容很丰富，很多章节我几乎是看不懂的，但是并不妨碍我学习其中具有普遍性的道理。但是有些篇章我似乎立即就能用上，先读了吧。昨天和今天读了2篇，激励考核篇和职业发展篇。这两篇我想一起谈，其中也混杂着一些我对职业生涯的认识。或许我们都还没有走上管理职位，但是如果能以管理者的角度来看普通员工，很多平日工作中的事便能想的通了。像我一样的年轻人，刚进入公司时踌躇满志，半年乃至一年后不得升迁，工资不涨，便牢骚满腹，心里算着小九九了。这是人之常情。从管理者甚至老板的角度来看，如果他看不到在你身上体现的效益，试问怎么会有好处给你。沉下去，一个人能完成两个人的任务，或者你做出来的东西就是比别人做出来的好，那样你才是和别人不同的，你的劳动能转化为实实在在的成果和效益。如果你是老板，你能不注意这样的人吗？但是为什么大多数人做不到这点？阿朱在书中举了个数字，从到一个新公司开始的兢兢业业到后期的放松自己，上网、打游戏，时刻准备着跳槽，恰好是10个月。我自己虽没有这种经验，但回顾四周，也大致如此。坚持、专心，我想这是大多数人没有的品质，这就是答案。Outliers（一译 《出类拔萃》、一译《卓尔不群》）的作者总结了一个“1万小时定律”。 “It seems that it takes the brain this long to assimilate all that it needs to know to achieve true mastery”。 作者认为，在专业上专注地花上1万个小时（ 10年，每天3小时），就能在该领域出类拔萃。十年粗略一想确实很长，但是对我们来说在KTV陈奕迅上身的时候也不过是一首歌。如果十年做不到，坚持一年，一天工作8个小时，专心其中的6个小时。一年以后，我不认为不会有人在高处注意到你。两年以后，你可能也站在高处了，虽然可能不是那么高。激励当然只是一个策略，如果没有激励你也能长时间如一的表现良好，相信自然而然的回报要比所谓的激励结果更好。当然对大多数人来说，适当的激励要比没有激励好。由于我还没有真正的站在稍高一点的地位，所以对激励只有模糊的想法。我只能认识到，如果你想升迁，想涨工资，那么就不要想怎么样会得到这些，而是要想如何更好的完成工作。似乎听起来有点令人困惑，但是道理就是这样。就好比你要要某个人伴你一生，这并不表明你要去想着如何“得到”她，而是给她（他）一定自由，同时在没有可预见的回报的情况下付出，才能最终“得到”。可惜的是，晚了好几年才明白这个道理，所幸，还不算太晚。3月14日 　　读《走出软件作坊》-4 　　最近几天又把这本书看了一遍，抛开具体的技术不谈，我只看到了一个字-“人”。 　　 　　不管是作为管理阶层还是执行层，所接触的只是人而已。虽然大家的目的是为了做事，但是事情只是联系人与人之间的纽带。管理阶层选对了人，事情想必不会被做的太差。执行层做对了人，自然会有事情让你去做，事情做好了，也就会有得到赏识的机会。 　　 　　唐骏不厌其烦在各个访谈上说“先做人，后做事，偶尔做做秀”。本书的第二节章就是“人，人，真的是人”。仔细想一想人生最难的是什么？做事还是做人？有多少经理在焦头烂额的时候不是大骂事情难做而是埋怨能人难找？有多少基层员工离职后并非觉得工作困难而是痛斥领导非人的？ 　　 　　从上往下看，你要主动，你要机灵，你要随叫随到，你要胜利完成任务，你还不能抱怨，让你办事是那是组织上信任你。往大了说，这事情给你，办得了就办，办不了就走，就你这能力，我把职位在招聘市场一贴，随便召回来一打个个都能顶替你，还试用期3个月不用给钱的。往小了说，让你办个事你都吞吞吐吐，推三阻四，你还想不想提拔了，你要不行，重新找个下级来培养，说不定出息还比你大，办了事还任劳任怨决不恬着脸要涨工资的，再往后你这就算是被打入冷宫了。 　　 　　从下往上看，你要和蔼，你要可亲，你要批评人的时候春风化雨，表扬人的时候广而告之，你要过年过节发东西发钱，你要加班的时候和下属同甘共苦还要买来吃的喝的慰问一下，加班还不能频繁，也不能太累，要不我可吃不消，要想我工作更上一层楼，那行啊，涨工资吧。工作中你不能任人唯亲，不能受人蒙蔽，我干的是最多的，最累的，最苦的，你咋就看不见，别人啥事不干，净拍马匹咋就升的这么快，得，此处不留爷，自有留爷处，风紧，扯呼。 　　 　　大家都是出来混，都要最后还，都不容易，都是在公司里下面拱上面骂，在家里媳妇嫌儿女怕，那咋就能有这么多矛盾呢？这是人民内部矛盾还是阶级矛盾？能调和不？问题在哪？问题都在别人那吧？对不起，您想错了，我看您这死循环是跳不出来了，告诉您，问题都在自己身上，自己做人如何？做事如何？先掂量掂量再重出江湖吧。 　　 　　作为员工，要有主动性，要考虑事情周全，比别人想的多一点，做的多一点，有时还需要一点耐心，这很难吗？确实很难，要不说好员工就这几点，无它尔。是，上班时间打网页游戏很容易，聊QQ很容易，无所事事坐着发呆最容易，人的大脑也是贱，你不控制它，它就往着简单的事情上面去了，非要用大力气把它拉回来不可，就像方向盘似的，一刻不把稳它，它就要跑偏了。做工作就是做人，人做好了，事情自然就好做了。为什么都会把错误归结在别人身上？因为这很容易，大脑都是捡容易的事情做，找到一个方便的法子就不想其它的了。要能发现自己的问题，还要能改正它，最好还能找出问题根源所在避免再犯。其实各个公司，各个企业招员工的时候看重的就这几点，要不以为面试是干嘛呢？看学历？看背景？看看你有没有面试官长得帅？ 　　 　　作为领导，就要有领导的度量，有时候不用压制脾气，可以小小爆发一下，那也是时机恰当的时候。也许作为大领导，该有的特质基本上都是有的，要不怎么坐的稳呢，必有其过人之处。作为一个小领导，小任务组长，小项目经理，一方面要有领导能力，团队才有战斗力；另一方面还是个下属，要有工作能力；所谓中层，就是风箱里的老鼠，两头受气，但是事情来了还得做，还得做的好。人生就是一个个困难接踵而来的旅程，要不逃避沉沦，要不迎难而上，绝无第三条路，对这个有了心理准备，才能不措手不及，或者叫苦连天。 　　 　　阿朱怎么做的，他是不是有问题了逃避，或者只是坐在那里抱怨？是不是员工能力不足就看他不顺眼就一脚踢开自己来干？是不是有了好处和下属抢？是不是不思进取，僵化落后？是不是有点功劳沾沾自喜，以已为重？是不是犯点错误就惶惶不可终日？是不是遇事急躁，毫无耐心？ 　　 　　我想应该都不是吧。既然如此，学着做不就好了。多简单。别说这是别人干了十几年才有的经验，所以你没有这积累，没有这经历，所以无法体会，无法成长。别傻了，人为什么和动物不同，因为我们会学习，而且主要是从别人那里。谁说非要吃一堑才能长一智了。（最后一句话是一个链接：http://mindhacks.cn/2009/01/18/escape-from-your-shawshank-part1/）

大宝感言：阿朱的文章，教会了我们什么？

阿朱的文章, 我读过很多次, 其中的某些章节甚至反复读过. 不仅是共鸣, 也有更多的启迪. 阿朱的文章里, 有太多值得好好思考和学习的东西,发在CSDN的这篇博文, 只是这个系列读后感的开篇, 还会陆续有我的心得写出来. 向阿朱学习. 以下是转自我自己博客的文章内容, 与大家共同交流: 阿朱的系列博文“三五个人十来条枪 如何成为开发正规军”，我几乎是追着看完的。 一开始，我很诧异，一个人竟然可以这样连续数周接连不断的不受工作影响而发表博文，且篇篇深刻。读到后来，我才了解到，这些博文的内容，并不是阿朱这几周一时半会的即时感悟，而是他长久以来在IM上，邮件中与人沟通，与团队交流后自然而然形成的工作成果。此系列博文的可贵之处，正是在于它是阿朱这么多年工作以来的宝贵经验之谈，具有极强的现实指导意义。 很多的职场新人，正式进入职场的前两三年，绝大多数都处于困惑期。他们或者觉得城市太小，感觉IT没有发展空间；或者觉得单位太小，感觉没有发展前途；或者觉得压力太大，感觉暗无天日。凡此种种，不一而足。众多的困惑，带来的必然结果就是：不知道自己将来要作什么，不知道如何看待自己目前的老板，目前的项目，以及目前的工作环境。 虽然，在很多过来人看来，这些，都是新人成长所必须经历的过程。但是，作为一个曾经的新人，我非常希望能通过自己的一些观点和体会来不断引导新人渐渐进入角色，从此让自己的事业慢慢起步。可惜的是，也许是我经历的还不够多，也许是我考虑的还不够深刻，所写出来的东西，总是零零散散，不成系统。 以前，我总认为，中国的IT圈子里，有太多阳春白雪想法的人，他们以为玩熟了C++，看透了设计模式，就是天下第一了，而事实上，技能仅仅是技能，技能能不能转化成生产力，还要看团队，还要看公司环境，还要看自己对技能的态度，要看自己对产品方向的感觉和把握。 初读阿朱文章时，第一个感觉是：惊喜！这时，我才发现，原来IT圈子里还有这么多务实的人。 再读阿朱文章时，给我的感觉是：畅快，震撼！把我太多想说而又没法系统说出的观点，想法统统说了出来，总结了出来。 这，绝不仅仅因为阿朱的表达力比我要好，更重要的是，这些观点和想法，都是他自己的实战经验总结，而绝不是市面上通常见到的那些无味的条条框框的软工理论。我们都想成为开发正规军，也都在努力成为开发正规军，那到底，按照什么样的一套方法才可以去打造一个开发正规军呢？ 很多创业型的小公司，其技术人员规模多数不超过10个人，在创业初期，大家面临的一个共同的问题是： 什么样的开发方式，才是有效率的，质量可控的？ 什么样的组织结构，才是保持创新和活力的？ 团结，有凝聚力，能战斗的开发团队，该如何打造？ 很多小公司的夭折，常常是因为开发进度不可控，开发团队不可控。 倒下去的公司，会后悔自己当初不该这样不该那样；而成功了的公司，又都意气风发，斗志昂扬的迎接新的冲锋，似乎受磨难的，并不是自己。成功或者失败，很 难得有人总结一下小公司的成长经历。而作为中国未来企业的众多小公司们，又特别需要在自己漫无头绪时能获得一些前辈的指点和提携。 阿朱的文章，恰到好处的满足了这种需求，这一点，从众多网友在阿朱博客上的留言就可以看出来：大家都很迫切的在想办法解决自己个人，所在的团队或公司在 目前所遇到的困难。说小了，这能解决自己个人的吃饭问题；说大了，这也能解决团队乃至公司的生存问题。所以，这里探讨的话题，深刻中带着沉重。 而时间，是最无情的。谁能更快的组织好自己的开发流程，组织好自己的开发团队，谁就能更快更好的出产品，而谁能更快更好的出产品，谁就能更好的生存下 去，世界很残酷，不是吗？ 阿朱的文章，教会了我们以下几点： 1.无论你是个程序员，还是个项目经理，或者是个老板，“积极面对”的心态都是最重要的； 2.不在其位，不谋其政，尽全力作好自己份内的事，其它的东西，都会随之而来； 3.不唯书本论，万事以实务为第一； 4.不要想着直接用阿朱文章里的方法去套你自己的实践，要从这些文章中学到最本质的东西：思考问题的方式，解决问题的角度； 5.技能，只是技能，真正用起来，才是有价值的。不要总觉得作技术的没得到应得的报酬，要想想，这个产品之所以卖得出去，是因为技术作得好，还是因为老 板有关系，学会换位思考，会让你的心态更平和； 6.在这个公司，就不要总是抱怨，否则干脆离开，因为抱怨不仅无法解决自己的问题，也同时在伤害团队。 等等等等。 更多的东西，还需要读者自己去认认真真读读这个系列，而且，要反复的读。

非常适合程序员读，该书内容很全面，任何阶段的程序员都能汲取到营养

　　首先，就编辑质量来讲，这是一本质量很高的书。错别字不多，我发现的只有2处，语句也很通顺，没有词不达意的情况。　　其次，就内容来讲，作者很全面的讲解了一个成功的职业经理人应该具有的素质，以及如何成为一个成功并且优秀的职业经理人。该书最大的特点就是在传授知识的同时结合作者自身的实际经历，这非常具有实际操作价值。此外，该书把打工者与老板的关系讲的非常透彻，为众多打工者及求职者实现自己职业生涯价值的最大化提供了参考。其实， 于2009年已经接触到该书，如果当时果断出手，也许我的职业生涯会走的更顺畅，没有过多的起起沉沉。现在经历了那么多之后再看此书，只能有一种相见恨晚的感觉。不过，作者推荐的很多书，我非常喜欢，例如《微软的秘密》、《联想风云》等等。作者的一些学习习惯也让我受益匪浅，相较于该书，作者其人倒是让我很长见识。

对作者的一个理解

作者是一个遇到问题就想办法去解决的软件人。遇到问题，解决问题，不断创新，这种能力我需要。过了一段时间写书评，记忆中书中最主要的就是遇到问题，解决问题，当然问题有一定代表性，除了明白作者怎么做事，还能了解一些一些实际问题可行的解决办法。

软件行业和传统行业的比较

最近断断续续在读阿朱的《走出软件作坊》，感觉不错，在认识上面有了一定的提高。感觉和现实还是比较的贴近的，很多点还是经得起实践的考验的，可以在实战中“拿来主义”，或者稍加修饰即可“拿来主义”。今天读到了如何给可以报价的问题？下面的一些话是摘自阿朱的书中。例如我们给客户报价3万，客户就会说“好像有一个华军软件园，可以下载免费的软件。再说了，谁不知道你们软件开发，就一台电脑一个人，啥费用也没有，就买我们3万？你看我们，进原料买地建厂房招人买流水线搞运输招商打广告，我们才卖那么点钱》你们什么都不要，不要原料，不要厂房，不要流水线，就要卖3万，利润也太高了吧。”很多时候，我们会这么回答“我们要给您定制化开发，要维护、培训，这已经是插标卖人了。”又或者说“一点也不贵啊，我才给您报3万，您的企业一年流水就1个多亿呢，您的宝马保养一次要3千。这软件全体员工都能用，而且能提高效率，才3万，多值啊！”客户还是觉得贵，不是他买不起，他请别人吃饭，也许一顿就要3万了。主要是他觉得你的软件没有那么多价值。其实是一方面客户对软件开发的流程不熟悉，不知道软件也有原料和流水线等等，和传统行业的生产过程是一样的；另一方面，是我们自己没有细分流程，至少在给客户讲解的时候没有细分流程，没有将软件开发的流程和客户熟悉的工厂运作流程进行对比。我们软件开发其实也是存在进原料，买地，买流水线等等的。软件产品开发的流程为：1、客户调研、客户调研报告编写。这个就相当于客户的买原料阶段，客户生产的基础需要原料，我们开发也需要需求啊，收集需求就是客户的购买原料。2、功能设计、功能设计说明书编写这个就相当于客户的买地、建厂房，客户生产要有一个牢靠的基础没有厂房，就算买了原料又如何生产呢？软件没有一个良好的功能结构设计，后面写出的代码肯定也是劣质品，就好象生产的不合格产品一样。3、开发这个就相当于客户的流水线了，原料（需求）买了，厂房（功能结构）也建好了，可以生产（开发代码）了。4、测试这个相当于客户的质检，经过严格质检的产品才可以上市，才经得住客户的使用。5、帮助文档、培训课程、培训演示版本编写这个相当于客户的售后服务之类的吧，这方面我还没有接触到，如果有不当的地方，请大家指出。你看，这么一比较，是不是客户就会更加认同你的价格呢。因为你是从他的角度出发，用他熟悉的流程解释了软件开发不是一个人一台电脑就可以解决的事情，也是需要一个完整的流程，和传统行业的流程差别不大，只是换了一些名词，换了一个工作方式。但是，过程是不可避免的，都是为了保证产品最终的完成。以上观点仅供参考，如果有偏差还请指正，本人工作时间不长，难免会有比喻不当的地方。感谢您抽出时间看到了文章的最后，也感谢阿朱无私的编写！

修炼内功的活教材，适合团队的每个人看——用友华表CTO谈《走出软件作坊》

几个月前，就看了这本书，当时还没出版，也算是看的内参了。语言虽然波澜不惊，但内容让人着实欲罢不能，速战速决一天看完最后一页，颇有些淋漓痛快的感觉。 这些天要写写其中的感受，其实书中的内容细节经过数月脑细胞的不断新陈代谢已经忘的差不多了，手上也没有书，想重新温故一些也不大可能了，又觉得，到这个时候能留在脑子里的当算是其中的精华了，一本书对一个人的影响随着时间流逝也不过这些，至于其余的，不好意思暂且先还给作者了。 《走出软件作坊》我的第一感受就是写的很实在，书中写的故事看起来是那么的亲切就好像是发生在自己身上，似乎写的就是自己公司。国内软件行业绝大部分是中小企业，里面的研发团队少有超过10人的。成千上万家这样的公司几乎每天都在经历着书中的问题，每年都在重复着书中的故事。当然，阿朱并不只是提出问题，他把自己10年来从一个程序员到CTO所积累的经验历共享在大家面前，每个章节针对具体的一个方面，看后总能产生一些回味，引出些思考，想去改变些什么。 《走出软件作坊》出现的又很必要，听说已经重印了，这是意料之中的，因为这并不是仅给研发管理人员准备的书。产品编码、架构设计、需求分析、质量测试、文档等等这些成员，人人有份，甚至于其他销售、市场、运维、培训部门也都囊括其中。 但这并不是说这是本大杂烩，而是因为软件作为产品要取得成功，不是哪一个人的事情，也不只是研发部门的责任，而是全公司共同参与努力的结果。软件作为新型行业在国内还处于初级阶段，虽说是高科技，但还应该再加上民工二字 ，很多方面还不如一个建筑工地有制度、有流程、有规范。因此在各个方面出现各种各样的矛盾也不足为怪。 　　 每个员工都需要成长的环境，但凡在事业上有追求有理想的员工，无论现在处在公司的什么位置，都会无时不刻在考虑如何提升自己，把盘子做大。 编码人员要做更规模更复杂技术难度更高的产品，设计人员要积攒大型产品的设计经验，需求想要在行业里做得更深入专业，项目经理需要积累多人月的开发经验与管理经验。 每个人都是从作坊中出来的，所有人都希望加入到正规军当中，山寨里充其量是个山大王，将军从来都只在正规军中。 　　 看到目前这个经济形势，我还发觉这本书出来的挺及时，大家都说外面环境不好了，要多在家里修炼内功，怎么修炼,炼什么。这不，眼前就是活教材，与其找那些老外们的最佳实践往我们中国特色上生搬硬套，不如多看看走出作坊，这个更靠谱些。当然，连Fred Brooks都说没有银弹，是不是合适自己还要自己亲自去揣摩。

最近正在拜读这部书

昨天书刚到，晚上看了里面的前两片文章！本人从一个普通软件工程师，转向创业。公司已发展成10人左右规模，也是像书中所言靠关系维持公司，但是左思右想总觉得靠关系不能可持续发展，产品卖出去也是靠关系！于是天天在CSDN上捞信息，能捞出点可持续发展的信息。无意间看到这本书的片段，虽然和自己当初的想要捞的信息有出入，但里面谈到的团队开发，双龙会等文章让我受益匪浅。回头看看自个公司在产品开发中所碰到的问题，还真是有那么回事。算是找到良策，正在学习中！呵呵。。。

xtools创始人CTO李亚平的《走出软件作坊》书评

xtools是国内著名的saas提供商，李亚平先生也是国内的软件前辈，驰骋软件行业20年，xtools的网址是www.xtools.cn.非常适合国内中小型企业。从《走出软件作坊》看阿朱 今天出差回来，收到阿朱寄来的《走出软件作坊》，仔细拜读之后，细细体验这个写书的家伙；首先声明一点，知道有阿朱这个人实在sd2008上，然后通过csdn的CTO俱乐部交流的，之前对阿朱完全不认识。 最大的感觉，阿朱是一个优秀的程序员，是一个干大事的人，原因有下： 1、一个优秀的程序员最基础的基本功：信息、资料、收集、消化...... 《走出软件作坊》绝不是一天写出来的，里面众多的内容绝对是作者长期收集、整理、体验、记录而来；一个优秀的程序员没有自己收集整理的“资料包”，简直不敢想象。 2、一个干大事的人必然是一个可以策划一个长期大事的人，《走出软件作坊》策划和写作就是一个例子（该书绝不是短期赶出来的，不少公司赶程序，我认为赶出来的都是垃圾）。 3、优秀的人才必须是全面的，阿朱在本书的营销策划上大有手笔，绝不是一个死写程序的人，很多地方很注重”从市场营销出发“而定程序（文章）写作方向。 4、该细的地方细，该面的地方面(全面的面，不是面瓜的面)，针对现在犹如爆炸的信息（例如众多的编程语言，新概念），阿朱知道抓核心，还有什么时候抓，已达到用最小的代价获取最大的收获。 5、程序员很懒，我甚至有些认为一个非常勤快的人当不了程序员，因为你这一生的思维方法就是“怎样减少重复劳动(这是程序相比人的强项)”，也就是说怎样在完成任务的前提下偷懒。 6、乱就是治，治就是乱，凡是跳出常规的框框，一个程序管理的书内容线索也很多，阿朱利用他的乱治却将内容治理的很条例，与我的习惯相同。有点像joyo的仓库，全部商品全都不按同类型分类，但是却能在最快的时间内找出。 7、事情看本质，一个与研发有关的事件，哪怕是别的公司的，甚至报纸上的，都能看出问题出在哪里，这是一种长期的思维方法导致。 8、阿朱很会调剂，现在的程序员压力很大，优秀的程序员自然会有泄压的方式，比如阿朱，其他的爱好暂且不说，爱好看科幻大片就是一个不错的选择，因为看大片的时候是外界信息直接输入大脑，大脑没有主动思考，是一个脑力休息的好方法。 9、跳出程序员看程序员，好比站在上帝的位置上看人，有利于提高自己 10、...... 今天很累，就写到这，希望大家各有各的视角看问题。

《走出软件作坊》读后感

《走出软件作坊》读后感第一次知道这本书，是曹政写的一篇叫《走不出软件作坊》的博文[1]。我记得那篇博文的最后caoz说阿朱对互联网领域的理解不如黄一孟。想想黄一孟的团队才十来个人、七八杆枪，想必这个阿朱水平也不会高到哪里去。我找来一份PDF版粗粗看了一下，不但找不出来caoz的槽点的落脚处，而且连作者立论的依据和场景也想不出。那时候，只懂得什么是“代码”不懂得什么是“软件”的我，遑论“软件作坊”和“走出软件作坊”。就这样，这本书一直躺在我的硬盘里，从来没有认真的读过。后来公司临时决定交一个项目让我带的时候，终于体会到了麻烦扑面而来的感觉：丝丝相扣的问题让你无法下手，一个一个貌似死结的东西需要解开，甚至没有时间去想里面的前因后果。赤手空拳的我这时候想找一些项目管理的书来作为“武功秘籍”来修炼一下：先是到豆瓣上看看哪本评价最高，然后到书店去找书来试读一下，但是到最后也没能找到一本“葵花宝典”。一部部的经典著作好像都在告诉我一个事实，项目管理是“道不可言”。在放假回家的火车上百无聊赖找出来这“钦定”读本，细细读了一些章节之后发现共鸣不少，实在是一本很接地气的书。点子大王书里面的场景在现在看来都有些似曾相识，好像是犯过这样的错，吃过这样的亏，但是为什么却没有阿朱这样的一个个的“点子”。比如项目经理的棘手问题怎么处理？维护人员的棘手问题怎么处理？怎样让测试人员不敷衍了事？嗯，好像看起来阿朱比别人要聪明一些。软件质量是所有公司的首要问题，所有的实施困难、使用效果差、支持费用高，都与此相干。 阿朱所述： 先找一个“懒”程序员做客户支持，为了减少客户支持工作量，就要做好好做测试。为了好好做测试，就需要有恰当的测试策略。自然而然的引入BUG管理工具与问题处理流程。如此看来，阿朱的策略是代价最小的，既没有空降规范，又没有人员的流血冲突。:P 用“土方”治大病的范例。象这样的例子书中很多，看起来作者象个“点子大王”，不过仔细研究一下里面的来龙去脉，发现阿朱这些东西并不是“灵机一动”而是具有相当的智慧，实际上是敏锐观察和不断思考的结果。分析高手知道有坑，却始终不知道坑在哪里，这是我的真实感受。针对行业软件项目实施时间长的问题：问题(实施周期长) -> 主要问题（客户需求、数据准备、报表定制） -> 具体分析（关键矛盾的解决）。这样就把整体的问题拆解了，如此下来好像都有了具体的策略。书中的“四套马车”就是CMMI的简化简化再简化，如果CMMI是“超跑”，“四套马车”就是“昌河”，从到达目的地这个目的来说，选择一个合适的交通工具更重要。对于正规化，作者认为：只有专业分工合作，才能走上正规化。组织结构可以保证专业分工，过程管理可以保证合作，我们看到的是大树，阿朱看到的是森林。实践出真知与第一版的书相比，思考组织结构方面更多了一些，认识也更深刻了，这是作者自己的提升。在知乎，有人问了一个问题：“您觉得明源相比较其他本土ERP公司（用友、金蝶、神码等等），优势在哪里？”阿朱的回答：“这里缺研发线带头人,需要把整个研发团队带向前进.一个300人的研发大军要走向何方，如何带领这么大的一支研发团队，应该给业界产生怎样的影响力和贡献？这就需要大格局大未来的研发带头人。一个纯软件公司，最核心的资产和竞争力就是它的研发线了，这是一个纯软件公司的命根，它的大部分收入和发展都取决于研发线，这个部门的重要性在公司不言而喻。能带领这么核心的、可以决定公司命运的部门，而且是靠我的力量去领导它前进，这是个人价值实现需求满足的一方面。另外也和我个人的研发优势合拍。我一直在行业软件公司工作，而且一直在研发口工作，而且一直在架构、研发、管理三方面精进，十多年来从未离开半步。”

想不通，那么好么？

我是慕名买的这本书，可是买回来，发现其实这本书并没有传说中的那么好，也许是希望越大，失望就越大吧。这本书的确，针对很多问题都做了作者自己的理解，可是很多问题上，我并不赞同，比如对于项目经理的一些看法，我只能说作者的办法适用于他的公司，但不能说他的办法就能让人获得成功，只不过他的办法可以让我引发一些思考，就是这样。另外，我刚开始很喜欢这本书，读着读着就不是很喜欢了，因为越到后，我越能感觉到作者言语之间的那种小骄傲，也许成功人士都是这样，但是我不喜欢。

逻辑的严密性有待商榷

又重新看了一下阿朱的博客连载的走出软件作坊系列，还是保留最初的评价，走出软件作坊提供了三五个人十来条枪打造正规军的可能性，但是在必要性的分析上基本没有。我们往往认为所谓正规军是必要的，但必要性分析往往不够全面和缺乏力度。我觉得四人帮的设计模式给我们提供了一个逻辑分析的范本——名称，应用范围，实现方法，实例。我总觉得阿朱的论述会在上述四个方面有一定得欠缺。当然一家之言，仅供参考。

呃落伍了。。书已经出了快一年了。。

这两天在看阿朱的书..《走出软件作坊》。。推荐一下。。写的很好。。呃落伍了。。书已经出了快一年了。。我现在才看。。5555不过不算迟。。至少让我看到了，我现在应该要干嘛。。计划计划。。时间很快就会过去。。又一年啦。。应该学学阿朱。。应该总结一下。。- -！什么都是半桶水。。是不行滴。。想在挨踢里搞点名堂。。还要不断努力。。计划计划。。做个人，好人，懂得总结经验的人。。写下每天的工作。。该干嘛。。干嘛去。。要仔细！认真！耐心！。。。戒骄戒躁。。努力！进步。。。

全书精华都在一分钟先生——自我时间管理

7我有个我自己的每日任务列表。我每天要做什么事情，我都随时记录下来，然后一条条的做，一条条的消。我看着不断有任务变灰，就很开心。我清楚的知道我每天要做什么事。 让行动代表你　　 　　8我要求手下在每天下班前一个小时把今天的工作进展发过来。然后我一一审阅，给些建议。这样，他们明天该怎么做，该做什么，今天遇到的问题该怎么解决，在他们下班前就知道了。这样，他们明天一来了就立即动手，根本不耽误时间，所以工作效率很好。 　　 　　9有的员工跟我絮絮叨叨讲了很多，反映他所遇到的问题。我听完后往往第一个校验的就是，你到底要达到什么目的。很多员工被反问后，是啊，我到底要达到什么目的。最后一重新审视自己的问题，很快就把问题简化了，问题的症结就找到了，当然解决也就很快了。甚至，弄清楚了目的，发现问题根本不是问题，根本无须解决。省了不少功夫。 10我不喜欢员工像讲故事一样来龙去脉的报告。我总是强调，要1、2、3，这样来。而且你一次报告，不要报告太多的问题，人不应该关注那么多问题。关注多了，就根本理不清，所以也就解决不了问题。先要把自己的头脑清醒了，就焦点关注在前三个问题。等前三个问题解决了，再思考以后的。有些员工向我报告问题，总是拔起萝卜带出泥，一个问题的描述往往会引入另外的问题，然后问题串问题，跟糖葫芦一样。我总是让他打住，就说那是另外一个问题，咱们现在先别管它，咱们先把你现在说的这个问题说清楚解决完，再处理另外一个问题。 13我希望记笔记，不管看书，还是做事，想到一个很好的点就立即记下来。而且我还经常回顾自己的这些记录，把它们尽量整理成体系和方法，让彼此关联起来。所以我解决问题思考问题的时候，总是有很多参考。而不是从头想起，也不是一遇到什么事情还得重复寻找资料。我这个人由于太专，所以关注的东西也不多。就看自己关注的东西，所以范围窄。许多人没有重点，什么热就看什么，而且积累了一大堆资料，反而后来自己都不看。而我，由于关注的少，所以看的东西自然比别人范围小，看的少也就看的精，而且还定期整理自己的笔记和资料，发现过时了就删除掉，保留下自己持续关注的资料。我发现，不少人有移动硬盘，里面放了很多资料，但真要做事反而一点资料都找不到，跟没有资料一样。 　　 　　14我喜欢看书和思考问题。过去坐地铁上下班，我都拿本书拿支笔，随时读书和记笔记。一天不读书不总结就觉得空空的，即使上个厕所也要带本书。很多工作中的管理方法很问题解决思路都是这样想出来的，在工作时间就赶快去，节省了不少工作时间。有的人记忆力还不好，还没有做笔记的习惯，还想问我有什么阅读理解的好方法？我的父亲常说：好记忆不如有个烂笔头。其实做笔记不仅仅是个做笔记这么简单的过程，而是在你写字的时候你就会思考揣摩思考，本来你认为很不错的一段文字准备记录下来，在记的过程中你就会想到自己的问题是否能有所借鉴，在记的过程中你就会联想其他同类的信息对比，总结出共性和差异点，在记的过程中你就会发现这段话说的比较片面不像你刚看的那么激动。很多人做不好自己时间管理，就是想做，但只是一个想法，真正做，就觉得这样做太累了，就放弃了。 其实，不管是谁的问题，只要是阻碍我的问题，我都要解决，千方百计去解决它。因为我知道，我受了影响，我如果连自己都不去救自己，就没有人救我自己了。其他地方的补充1大的公司中，你一定能够找出职位比你高，但你认为能力却不如你的人。但是你不应该钻这个牛角尖，因为这只会让你气馁。你应该做的是找到和你级别差不多的，但是你很佩服的人。你能从他们身上学到什么？你有什么他们不具备的优点？2有些新员工会问我获得职业成功的秘诀。当我告诉他们答案是“努力工作”时，他们通常会很失望。这听起来像陈腐的说教，还像是自夸。如果我的答案是“我之所以能够爬到中层管理岗位是因为我很善于给上级拍马屁”，他们也许会更满意。我来微软的第一年就带了个睡袋到办公室，而且经常加班，周末的时候，我也是在写代码，学习新技术。我会看团队管理和如何与人沟通的书籍。才智相当的人在职业生涯上会有不同的发展，主要是因为他们的付出有多有少。如果有人另有说法，那他可能是想向你“兜售”点什么。

《走出软件作坊》启示 -- 坚持思考和总结 + 务实的态度

这书本读了两遍，第一遍读的时候拖得时间比较长，想起来的时候就翻翻，读完后没有特别大的感触，在读完了《微软的秘密》后，我迫切的想要再读一遍，因为阿朱在书中讲到这本书是对他影响很深的一本书，我很想知道，阿朱对于《微软的秘密》是如何理解的。读完第二遍，给我留下深刻印象的是作者的务实，书中没有很空洞的理论，讲得都是在现实项目开发中遇到的问题，以及他的应对策略，很有借鉴意义。另外作者这种经常思考总结的习惯值得每个人学习，对我个人影响很深的是关于个人发展的部分，让我能够更多的反思自己。1、 关于如何成为项目经理要有项目敏锐性，关注焦点不应在技术细节上如谁主导项目？每个人重点关注什么？谁影响项目的验收？….眼光敏锐，思考清晰我们在哪里？我们将要做什么？我们要怎么做？面对的阻碍是什么？思想上有根弦，如果我是项目经理我要怎么做？要想成为项目经理就应该在思想上早做准备，经常的模拟演练，想象如果自己是项目经理，遇到这类问题应该怎么处理要积极主动思考，并解决问题，而不是一切等上面定，要有自己的主见表达能力，要正式专业，不要太口语化，显得轻浮2、 关于过程管理走访客户很重要，有助和改善老板、实施、开发三者的关系BD可以扮演这样的角色，了解客户的需求，反馈到硬件、软件设计中新产品规划-- 剖析行业标杆老大的产品，学习他们的架构，产品气质，实施模式，咨询模式，服务，销售，整合出一份吸收优点的列表反思：在我们定义产品时，从未做过类似的分析，如果能对主流产品也做类似的分析并总结出列表，应该是很有帮助的。分析他们产品演变的过程，可以分析其这样设计的原因，并在新产品中借鉴-- 思考新老产品的关系，最好形成整合互补关系，不能互不相干产品定位-- 定位要清晰，细分客户和市场，而不是泛泛而谈-- 分析客户特征，总结出一个完善的最佳客户，去做销售支持时，只需与最佳客户比对，以确定重点方案人员的培养-- 上来就写方档很难，可以先去做客户支持、服务，了解用户的问题，使用习惯，便于文档中抓住重点-- 有能力的可以兼任内部培训，如每次发布新版，负责给销售等进行培训做报告有很多要注意的细节-- 确定听众，根据不同听众关注点不同，调整重点-- 录音，反复锻炼自己的演讲能力-- 眼睛不要死盯一角，面向全体，都照顾到3、关于个人提高要关注盈利模式，新产品，新应用，管理流程，模型，看能否引入到现在公司项目中？了解标杆企业，列出可以吸收优点的列表要经常总结和反思自己，清楚自己的优缺点，明确定位反思：-- 书中作者对自己清晰的认知给我留下了深刻的印象，他很清楚自己适合做什么，不适合做什么，也清楚自己想要什么，人的时间都是有限的，他把时间都花在自己关注的事情上，而不会广撒网，到头来，对什么都了解得不深。-- 要对自己有清楚的认知，就需要经常总结自己，总结自己的优点和缺点，扬长避短-- 作者说他不是完善主义者，他很务实，只会把精力放在最重要的几件事情下意识的培养自己的关联性思维随时随地看到的一些东西与自己的工作或手头的问题联系在一起养成做笔记的习惯，随时随地记录好的想法，总结等反思：不单单只是做笔记，更应该常翻翻，把一些好的想法，要真正的落实，好的习惯要下意识的培养，要不断提醒自己，有哪里需要改进，否则就只是记录下来而已，没有任何价值经常关注招聘网站，了解市场上都需要什么人才，我这样的人值多少钱？常看书，培养自己能很快把握重点和思路的能力反思：每读完一本书，要做笔记，记录哪些是值得反思和学习的，对于认为很有价值的书要多读几遍，在不同的期会有不同的看法下载源码，并优化修改，是学习的一种好方法反思：现在想要了解和学习FPGA在网络系统中的应用，可以去opencore上看有没有源码，进行学习和修改另外作者提到他的经历是，讲到会下载管理方面的讲座，有时间，走在路上时听反思：我是否也能像他一样，抓住一切可以利用的时间，不断的提高自己？经典语录：心有多大，舞台就有多大想做事，胸怀要大，要踏实，要低调领导气质，最重要的就是责任与态度另外在豆瓣上看到一则书评觉得写得很好：阿朱的文章，教会了我们以下几点： 无论你是个程序员，还是个项目经理，或者是个老板，“积极面对”的心态都是最重要的； 不在其位，不谋其政，尽全力作好自己份内的事，其它的东西，都会随之而来； 不唯书本论，万事以实务为第一； 不要想着直接用阿朱文章里的方法去套你自己的实践，要从这些文章中学到最本质的东西：思考问题的方式，解决问题的角度； 技能，只是技能，真正用起来，才是有价值的。不要总觉得作技术的没得到应得的报酬，要想想，这个产品之所以卖得出去，是因为技术作得好，还是因为老 板有关系，学会换位思考，会让你的心态更平和； 在这个公司，就不要总是抱怨，否则干脆离开，因为抱怨不仅无法解决自己的问题，也同时在伤害团队。 更多读书笔记请参见：http://458854394.qzone.qq.com

读阿朱的《走出软件作坊》

读阿朱的《走出软件作坊》与阿朱是通过BLOG偶遇在CSDN，收到《走出软件作坊》一书其实已经很久了。却一直带回家放到书架上，今天拿出来的时候发现封面上都有土了。一直未读的原因有两点：第一点当然是忙，最合理的理由；第二确是现在出书的太多了，压根就没看起不起眼的草根作者。：）习惯于在广告中寻找大师的时代，名声也许是最有价值的了。从序言看起，随着一页一页翻过，越来越感觉作者对软件开发和管理的不同的视角，尤其是对多读了基本管理书籍和教材的我来说。记得自己在读《当代管理学》的时候，发现原来管理还有这么多深奥的理论和模型。当时觉得虽然看起来很累确实收获很多。而且对照现实中企业的管理中，也确是感慨前人的总结和知识。但是从阿朱的娓娓道来的言语中，看到的是另一种真实而有价值的经验与思考的分享。读理论收获的是“原来管理可以这样做”，读阿朱的书收获的是“原来就是这样做的”。因此刚读了不到30页，就觉得应当写点感受谢谢作者。而且决定读完全书。blog.csdn.net/david_lv

最近看的一本书

开学来从图书馆借出来的第三本书，是在 信息管理教程课 及中国近代史课 上看完的（没办法，一会宿舍就Web,罪过罪过）, 感觉这本书还行，呵呵 稍微离我远呢还。

作者很清楚自己在说什么。

看过不少书，很多人甚至都不知自己在说什么，我感觉他们是在借鉴别人的思路。但这不是我想要的，因为你自己都是借鉴来的，又何谈来说服我并让我信服呢？本书看过来后很有内容，真的很清楚作者要表达什么，甚至在很多地方看到了自己曾经的影子。观点和想法很有针对性，整理感觉不错，我甚至推荐给我的领导看看，呵呵。那个思考角度和方式不错，特别的解决了与老板沟通上的障碍，希望能给我们的境况带来不同。

推荐中小软件公司的领导和员工都读一下这本书

看完后会对中小项目型软件公司的流程有个大致的映像，书里的案例非常接近实际情况，无论是从管理细节，公司战略，业界动态都有点到为止的一个描述，所以作为中小企业的软件开发参考手册还是很合适的。个人发展方面的描述也是可圈可点的，让公司走出软件作坊的同时，也让自己走出一个打工者的心态，用老板的心态去打工，自然你也成为老板了。

读了，也不一定能走太远

感谢作者分析了自己亲历的很多项目经验。读了，感觉什么都写了一些。但有些章节不是我想了解的，或者说我想了解更多细节的时候，却一笔带过了。有的章节能看出圈子圈套的痕迹。读了有几个月了，依稀留下的印象就是：作者会一再强调要体会老板的心思。但作者谈到的很多问题，正是很多小公司里正在发生的，有很多可以借鉴的。

人的思想决定行动——51.COM技术总监力荐《走出软件作坊》

阿朱送给我一本书 -- 《走出软件作坊》，并希望我能给再版写序。我一开始也感到奇怪，认为这只是一本软件开发者的心得，不是什么大作。收到书后，我给几个同事作介绍，想不到，很多人已经读过这本书，而且对阿朱也很推崇。这使我有些受宠若惊起来，我离开一线开发多年，哪有资格给这样一本很有分量的技术管理书籍写序呢？ 　　 　　 好在我还在一家技术型公司工作，并且还兼着分管技术线的工作。作为一个拥有超过200个程序员的互联网公司，我们最大的忌讳就是，各项目组还采用作坊式的开发管理，作坊式的系统运维。《走出软件作坊》更是一种管理的思维，而不仅仅提供一些方法。很多时候，人的思想决定行动，当你知道做么做明显是错的时候，你就会去选择正确的方法。 　　 　　 　　 　　 51.com走过从3~5个技术人员到30~50个人，然后到300多人的历程。51.com连续2年被百度评为web2.0用户交互做的最好的网站，也许只有我们的程序员明白其中的涵义。每天上传1000万张照片，500万篇日记，200万个群组帖子。以及用户之间上亿的交互动作。全部需要保存在系统里，并且即时传达每个用户。这些海量的信息需要保存在线上的数据库里，随着新用户的增长，老用户的不断沉淀。保存在系统里的数据还在不断地膨胀。互联网系统还有一个特点，就是软件的更新比客户端要来得更快，每天都有更新上线。 　　 所有这些，造成了对技术的巨大压力。这么多人，怎么分工协作，这么多功能、模块、项目怎么减少关联影响。要做到这些，我们唯一的办法就是：走出软件作坊。我们首先在思想上，不断地让每一个技术人员明白，我们已经不是作坊了，一定不能用作坊式工作模式来做51的事情。其次，更重要的是，我们要在工作中，不断建立各种研发工作流程、上线流程、质量保障流程。并且作为最高工作原则、要求来在公司施行。任何人，不管你以前功劳多大，能力多强，在这些原则面前，都是人人平等的。 　　 　　 大家都知道，人最难改变的就是习惯。就像保证生存和敷衍下一代是生命体出现以来就根深蒂固的思维一样，人类要去掉这种自私的思维是多么的困难。要想用几千年的文明去改造几十亿年形成的思想，确实是很困难的时候。同样，自由散漫，作坊式的软件开发其实也是在每一个程序员心里根深蒂固的思维，“我可以做得很好，根本不会影响到别人的东西”，“这些事情很简单，没必要走那么多流程”，“把我自己的事情做好就行了，和别人怎么配合，他们自己想办法”，“这个根本不可能，用不着浪费时间讨论了”......想一想，你还有你的技术同事们，是不是曾经，经常有过这些思想呢？ 　　 　　 　　 　　 所以，我很推崇阿朱的这本书，他系统地讲述了，一个企业，怎么走出软件作坊，不仅是在思想上重视，更是要在行动上，制度上保证。 　　《走出软件作坊》网上订购： 　　 　　互动网：http://www.china-pub.com/508874 　　 　　卓越网：http://www.amazon.cn/mn/detailApp?prodid=bkbk812538&ref=GS_TS&uid=168-8093432-0389064 　　 　　当当网：http://product.dangdang.com/product.aspx?product_id=20435119 　　 　　 　　

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

从98年毕业到现在，我一直在软件企业中打拼。自己从程序员到项目经理，到产品经理，经历过非常多的事情。参与过多个项目、产品的开发，也曾经参与过很多种管理方式的尝试。但是有个很深的困惑一直萦绕在我的心中，如何能够从纯手工作坊的方式上逐步走到正规的开发模式上？应该如何一步一步地迈进？应该从何入手？相信在中国，绝大多数软件开发人员、项目经理都曾经象我一样考虑过这样的问题：怎样能够让一个产品或项目的开发顺利完成？为什么老板和客户一边不断地追加变更需求，一边还要压缩开发计划？为什么在开发最要命的时候，所有部门（包括老板）都对开发的东西指手画脚，希望自己的意见能够在产品中实现？为什么对于开发出来的东西，总是怨声载道？销售抱怨，市场抱怨，老板和客户都不满意？正在我努力学习管理知识，希望找出问题的根源和解决方法，寻找一条适合自己企业现状的发展之路时，碰巧搜索到了吕先生的Blog文章。从第一篇的第一段，我就被他的文字粘在了他的Blog上，一口气读完不知不觉已经到了凌晨。看完整个Blog上的内容，整个人犹如醍醐灌顶一般，多年萦绕在心头上的困惑迎刃而解，茅塞顿开。现在，Blog上的文字变成了我现在手中沉甸甸的《走出软件作坊》。文字中描述的问题和事情，基本上都是我曾经在工作中遇到的棘手问题。对于这些问题，吕先生的解决思路和对问题的看法独到而深刻，文笔朴实而精辟。一切从实际出发，步步为营，深入浅出地描述了一个企业应该怎样从三五个人十来条枪的软件作坊，一步步发展成开发正规军的方法和手段。从书中可以看出，这本书里凝聚了吕先生从业十年来宝贵的经验和心得。相信读过此书后，无论是开发人会员、项目经理、产品经理，还是公司老总，上面说到的问题将不会再会是困惑。管理的精髓就是把合适的人放在合适的位置上，让所有人明确你的目标，带领这些人为你的目标而努力，直到达到目标。对于管理，仁者见仁，智者见智，每个人看事情的角度都不一样。很幸运的是，在这本书中，你能够看到老板眼中的程序员，也能够看到程序员眼中的老板。尹松北京瑞星国际软件有限公司 产品经理

亲切到没用的一本书

这书描写为软件公司问题的时候就像在写你身边的那些公司，但看完却发现怎么没帮助啊，来看看前面6节的内容总结和我的看法1.技术总监和CTO的区别技术总监光技术了得，光设计产品而没有将产品和公司战略发展结合。CTO是在技术总监的基础上，并统管企业咨询实施支持，协调市场与销售，能理解老板的发展战略，并组织资源来实现产品。（传递失真的问题CTO能解决吗，本节没提这回事。。）2.三五个人十来条枪 如何成为开发正规军面对的问题是：实施人员要求很全面，每个实施项目都是独立的，没有统计的积累和管理。解决办法：不被客户牵着鼻子走，而是引导客户走。1）首先调研项目的人员构成、能力、分别的职责、上线时间、上一套系统存在的问题、上一套系统的功能结构和操作流程、上一套系统是如何实施的2）重新建议项目人员构成、职责、流程、项目阶段时间、各方面负责人、本项目最突出要解决的前5个目标问题 （客户会听你的吗？ 特别是人员这个资源、项目日程也不是随意能改的，确定责任人倒很重要）3）按目标、责任、标准来分解执行。由此旧系统的数据校验交给客户IT来处理，实施项目经理负责制定流程、目标、计划、协调控制执行到位，培训交给专人负责，客户化代码交给公司研发人员。 （靠，好轻松的实施PM啊，两块大任务分别丢给客户和公司研发，这样就解决问题了。。 关于需求问题如何解决这一节没说，只轻描淡写的说“要一个目标"，问题是如何达成一致的目标并产生一致统一的一份需求，由谁来负责）这一节的标题也就一个标题党，“正规军”在文中就没见到过。。3.项目经理的工具箱excel + ppt +脑图(mind manager?) + word 四架马车出手，天下太平excel画报表式样，ppt画界面，mind map做需求分析，word？？本节前面扯一堆国内只有PM没有研发经理、技术总监、CTO的问题现状，后面扯一堆软件包装的问题，跟你这个标题有何干系。。4.人，是人，真的是人这标题，难道还会有鬼。。本节讲的是如何培养人才、留住人才，为什么不能搞个简洁明了的标题，想生动有趣点也不能偏离主题啊，文字功夫啊。。作者的解决方案：1）师傅制2）禁止加班 （谈何容易）3）良好的办公环境和良好的个人形象 （其实不完全说形象，要不然非美女帅哥进不了他们公司，准确说是着装举止不乱来）4）员工激励 （没具体说怎么激励的，跟没说一样）5）形成层次感有阶梯有接力的员工组织，避免不同高低职位上全是80-84年的人。下属还在窝里斗互相不服6）沟通交流，做政治思想教育工作7）让员工专业发展，还有一点是招聘注意点： （也被作者混在一块，这思维混乱的。。。 正好这节他讲到思维混乱这个问题）先看EQ再看技术能力5.实施经理的工具箱1）用管理模型KPI，管理模型计算公式、管理模型流程 唬住 要买管理信息系统的客户，让他们想用这套系统 （客户也蛮好忽悠的）2）数据录入 （之前数据录入竟然没有数据校验功能，匪夷所思的产品。。）3）封锁数据库 （客户的数据库可以被直接修改，这IT安全性。。）4）记录错误日志及抓屏为了培训做的屏幕录制，公司内部的vnc软件，软件加上自动更新功能 这样几个小技巧 也堂而皇之写在书上，骗字数啊。。6.客户顾问的工具箱1）QQ，QQ群，BBS2）客户工单系统真是很囧的一节，那么多文字来介绍QQ.. 软件公司没有客户服务系统，问题管理系统总要有吧。还有必要看下去吗........另外发现IT书籍的书托现象真是愈发严重了

作为一个准备在软件业试水的人来看，它很有参考价值

　　《走出软件作坊》从一个职业软件企业经理人的职业成长经历为背景，从自己的角度分析和解决问题，积极从问题出发，以解决问题为根本原则，我想无论在什么行业都可以借鉴。　　更可贵的是，《走出软件作坊》涉及了作者从新人成长到技术主管的各个岗位的问题，对于如何有效的发挥作坊的战斗力，提出了不少自己实用的技巧，也许很多初级的管理教材也会涉及类似的管理方法，但是针对小企业的思考就未必充分，《走出软件作坊》正式弥补了这样的不足。　　《走出软件作坊》足以为游走在小作坊的人们提供新的思考方式。

从一个程序员到领导者转型

读阿朱的这本书感触蛮多，有些思想和内容在很早的时候就在一些资料就见到过，但是这些观点虽然都是很明显的，但是只有在自己真正经历之后才会明白其中的含义。软件开发一个市场人员看上去很简单的工作，实际的复杂性可能是无法预测和想象的，在前期项目准备中可能公司的业务会盲目的给客户打包票，说我们技术多NX 多NX ，什么都能做，这个现象应该在很多公司都有遇到吧，其实很多东西都是无法完成的，但是业务部门的人用很感性的眼光认为zhe这些都是很简单的东东，开发人员和业务部门都会互生怨气。业务开始激情万丈，但是一听到程序员说这样不能做，那也不能做，顿时心里面就开始打小算盘了，比如以前一个业务，说 我辛辛苦苦、跟客户谈了好久好久。。。。结果。。。我个人认为应该把业务和开发编排在一个队伍中。开发经理应该先个业务部门一个大概的实力估计，业务部门应该及时的反馈和明确公司的研发能力。 大家先跟外面谈判和交流的时候，一条心去做，解决掉内部的问题，一条心去项目，应该大家合作起来会更加愉快。打包票。。。这个东西业务人员特别喜欢，不管怎样先把项目接下来再说。。。软件作坊 需要项目，但是我觉得项目多了。反而或许会拖累整个公司的开发进度和质量， 比如说以前公司做了一个电子商务系统，然后又有单子做 社区系统，然后公司还在做核心软件的研发，但是公司的美工配置是有限的，美工组是作为所有项目的协调使用，但是在做社区系统的时候客户不满意的多在于UI前端，今天不满意，明天也不满意，刚把这改了，又要改那，UI毕竟是个人喜好的东西。或许UI工程师觉得满意了，用户都觉得满意了，但是客户说这个不好看，，没办法。你不能定量的去衡量的东西，真够麻烦的。研发项目这边技术难度是最大的 大部分是核心代码的编写，几百行代码都要计算很多草稿纸的那种类型，但是UI 也很重要，因为UI 能反映出我们最后需要的什么效果，但是客户不满意 UI 就要继续花很多精力在上面，研发项目的UI 设计只是你要求他才设计，这是UI设计的一个比较忌讳的事情。毕竟是偏向艺术的技术活。这也不能怪UI，因为UI的精力有限，在反复修改的情况下，心里面就会变得烦躁不安，灵感或许就丢失了。。最后没办法 只有先忍痛割爱了，砍掉一个项目，最后是草草收尾，做软件作坊 应该先考虑做精 一个东西，就已经能够算得上很有成就了。你做电子商务，就专心攻克，你做游戏 就专心做游戏。做系统内核就老老实实的研究操作系统，这或许更有成功和壮大的可能性，因为把所有的力量都集中在解决一个问题上面了。今天想做这个，明天想做那个 天天研究，天天讨论，最后撒东西都做不出来。感觉在开发中 团队开发中问题很多很多，有很多程序员都有自己的个性，自己写的代码根本不能让人看懂，而且很多代码都是硬代码和基本不能移植和重用的代码。反而他们认为自己很NX，这种心理应该很多程序员都有的吧。不过感觉代码写多了就好了，程序员都不喜欢运动，这个会影响到开发效率，程序员老是坐在那儿敲代码，不参加一些运动，我在观察中发现这样会影响开发的进度和开发的质量。 最好是每个星期 几个人组织打一次球之类的活动，像我们公司公司夏天的时候每个星期组织一次游泳。。虽然很多CODER 都是旱鸭子，不过也可以活动筋骨和促进血液循环，大脑的供血充足，思考的就会更加敏捷。而且在运动的时候有可能找到新的灵感和问题的解决方法。

适合闲看的书

这本书适合软件公司人数比较少，需要使用综合技能的人员。里面对大萝卜和大棒的一段故事，比较感兴趣。说是要走出软件作坊，其实无非是说在作坊里如何想点办法好好的把作坊运作好，讲白了无非是遇到问题多找方法和出路。

软件开发那点事情

书还是应该看看的。昨天在看书，公司的项目主管也说看过几个章节的。他还说根本不可能在我们这些公司实现，因为公司内部肯定有人嫌人工少，不卖命的。我只是看了一小半而已，没有看完。但是，还是觉得里边有很多东西是可以学习借鉴的，即使不是在一个已经成型的软件公司。三个人就是一个小团队了。我会把书推荐给我身边的那两个做开发的朋友，因为大家都有交流的话题。

11

本书提供了解决国内中小型IT 企业和创业团队发展过程中会遇到的管理问题的若干方法。本书形式活泼，内容独特，以作者自身多年工作的宝贵经验，来谈IT 企业的项目管理和团队建设，主要包括组织结构、团队文化、软件过程管理、团队激励、绩效考核、职业发展规划、未来业界发展趋势、个人素质提升等，具有极强的现实指导意义。本书主要读者对象是IT 企业的研发主管、项目经理和软件开发人员，以及即将到IT 企业工作的高校毕业生。

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

这本书不是一本方法论的书，而只是我的10年工作点滴思考经验总结而已。我喜欢记笔记写东西，10年来记了很多东西，现在整理出版。如果你是学生想找工作，这本书合适如果你想跳槽，这本书合适如果你想创业，这本书合适如果你不知道未来怎么发展，这本书也合适我的其他观点在blog.csdn.net/david_lv我擅长产品体系规划\产品研发管理\技术架构关注SOA、云计算hadoop、SaaS、FLEX、JAVASCRIPT、mashups、atom app、REST

《走出软件作坊》启示 -- 坚持思考和总结 + 务实的态度

这书读了两遍，第一遍读的时候拖得时间比较长，想起来的时候就翻翻，读完后没有特别大的感触，在读完了《微软的秘密》后，我迫切的想要再读一遍，因为阿朱在书中讲到这本书是对他影响很深的一本书，我很想知道，阿朱对于《微软的秘密》是如何理解的。读完第二遍，给我留下深刻印象的是作者的务实，书中没有很空洞的理论，讲得都是在现实项目开发中遇到的问题，以及他的应对策略，很有借鉴意义。另外作者这种经常思考总结的习惯值得每个人学习，对我个人影响很深的是关于个人发展的部分，让我能够更多的反思自己。1、 关于如何成为项目经理要有项目敏锐性，关注焦点不应在技术细节上-- 如谁主导项目？每个人重点关注什么？谁影响项目的验收？….眼光敏锐，思考清晰-- 我们在哪里？我们将要做什么？我们要怎么做？面对的阻碍是什么？思想上有根弦，如果我是项目经理我要怎么做？要想成为项目经理就应该在思想上早做准备，经常的模拟演练，想象如果自己是项目经理，遇到这类问题应该怎么处理要积极主动思考，并解决问题，而不是一切等上面定，要有自己的主见表达能力，要正式专业，不要太口语化，显得轻浮2、 关于过程管理走访客户很重要，有助和改善老板、实施、开发三者的关系-- BD可以扮演这样的角色，了解客户的需求，反馈到硬件、软件设计中新产品规划-- 剖析行业标杆老大的产品，学习他们的架构，产品气质，实施模式，咨询模式，服务，销售，整合出一份吸收优点的列表反思：在我们定义产品时，从未做过类似的分析，如果能对主流产品也做类似的分析并总结出列表，应该是很有帮助的。分析他们产品演变的过程，可以分析其这样设计的原因，并在新产品中借鉴-- 思考新老产品的关系，最好形成整合互补关系，不能互不相干产品定位-- 定位要清晰，细分客户和市场，而不是泛泛而谈-- 分析客户特征，总结出一个完善的最佳客户，去做销售支持时，只需与最佳客户比对，以确定重点方案人员的培养-- 上来就写方档很难，可以先去做客户支持、服务，了解用户的问题，使用习惯，便于文档中抓住重点-- 有能力的可以兼任内部培训，如每次发布新版，负责给销售等进行培训做报告有很多要注意的细节-- 确定听众，根据不同听众关注点不同，调整重点-- 录音，反复锻炼自己的演讲能力-- 眼睛不要死盯一角，面向全体，都照顾到3、关于个人提高要关注盈利模式，新产品，新应用，管理流程，模型，看能否引入到现在公司项目中？了解标杆企业，列出可以吸收优点的列表要经常总结和反思自己，清楚自己的优缺点，明确定位反思：-- 书中作者对自己清晰的认知给我留下了深刻的印象，他很清楚自己适合做什么，不适合做什么，也清楚自己想要什么，人的时间都是有限的，他把时间都花在自己关注的事情上，而不会广撒网，到头来，对什么都了解得不深。-- 要对自己有清楚的认知，就需要经常总结自己，总结自己的优点和缺点，扬长避短-- 作者说他不是完善主义者，他很务实，只会把精力放在最重要的几件事情下意识的培养自己的关联性思维随时随地看到的一些东西与自己的工作或手头的问题联系在一起养成做笔记的习惯，随时随地记录好的想法，总结等反思：不单单只是做笔记，更应该常翻翻，把一些好的想法，要真正的落实，好的习惯要下意识的培养，要不断提醒自己，有哪里需要改进，否则就只是记录下来而已，没有任何价值经常关注招聘网站，了解市场上都需要什么人才，我这样的人值多少钱？常看书，培养自己能很快把握重点和思路的能力反思：每读完一本书，要做笔记，记录哪些是值得反思和学习的，对于认为很有价值的书要多读几遍，在不同的期会有不同的看法下载源码，并优化修改，是学习的一种好方法反思：现在想要了解和学习FPGA在网络系统中的应用，可以去opencore上看有没有源码，进行学习和修改另外作者提到他的经历是，讲到会下载管理方面的讲座，有时间，走在路上时听反思：我是否也能像他一样，抓住一切可以利用的时间，不断的提高自己？经典语录：心有多大，舞台就有多大想做事，胸怀要大，要踏实，要低调领导气质，最重要的就是责任与态度另外在豆瓣上看到一则书评觉得写得很好：阿朱的文章，教会了我们以下几点： 无论你是个程序员，还是个项目经理，或者是个老板，“积极面对”的心态都是最重要的； 不在其位，不谋其政，尽全力作好自己份内的事，其它的东西，都会随之而来； 不唯书本论，万事以实务为第一； 不要想着直接用阿朱文章里的方法去套你自己的实践，要从这些文章中学到最本质的东西：思考问题的方式，解决问题的角度； 技能，只是技能，真正用起来，才是有价值的。不要总觉得作技术的没得到应得的报酬，要想想，这个产品之所以卖得出去，是因为技术作得好，还是因为老 板有关系，学会换位思考，会让你的心态更平和； 在这个公司，就不要总是抱怨，否则干脆离开，因为抱怨不仅无法解决自己的问题，也同时在伤害团队。 更多读书笔记请参见：http://458854394.qzone.qq.com

书名叫做“如何做一个好的软件学徒”更贴切。

架不住博客、论坛上轮番的轰炸，去当当买了本看。书中对软件团队的看法多比较浅显，可能是因为作者是技术出身的，所以管理方面缺乏见地。不过对于新入行的小弟弟妹妹们还是有用的，可以让他们少走些弯路。所以说叫《如何做一个好的软件学徒》更贴切。至于管理者们，恐怕很难从这本速食面般的小册子里面学到什么。当然也不是说这本书就没有什么参考价值，毕竟目前国内的软件小企业甚至连“好的软件作坊”都做不到，更别说走出软件作坊了。书里面的一些做法对于软件作坊来说，还是挺有用的，起码让小作坊的人知道好一点的小作坊是怎么个做法。阿朱倒是老强调自己是职业经理人，可他怎么看也是个高级程序员，最多也就是半个业务顾问+高级程序员。不过挺佩服博文视点的，楞把一本快餐书炒成了教科书，我要是风投的老板，绝对去投博文视点。至于阿朱那个伟大的软件企业，还是熬过冬天再说吧。

不管怎么样，半本好书也是好书

看完这本书已经一个多月了，其实很早就想写评论，可是拖着拖着就没写。忽然发现有些感想开始淡忘了，还是写一下比较好。1.软件作坊不好吗？在流水线思想已经泛滥的今天，作坊这种小规模的代言词让人看着就觉得要鄙视之，是非正规的代表（看副标题）。那么我来举两个伟大的作坊的例子。其一，DEK—《计算机程序设计艺术》的作者，也许是世界上最伟大的作坊的拥有者（个人作坊），他的TEX的效果怎么样，不用我介绍了；其二，XP方法的首次实现，实际上就来自于一个大项目被一个自组织的小作坊来完成了。上面两个例子都含有伟大的程序员，这是他们作坊成功的重要因素，这些程序员本身也是从菜鸟走过来的。大的项目可能会带来大的团队，但是更优秀的程序员同样可以减少人员的使用。并且，优秀的程序员组成的作坊并不一定就不正规，相反他们的自组织行为远比规定的软件能力成熟度5级要高得多。为什么软件作坊不好？因为项目变大了，但是人员素质的提高速度大大的没跟上。其实这是因为我们在作坊的时候忽视了人员和团队建设而造成的恶果。2.临阵磨枪“临阵磨枪，不快也光”，其实这本来是带有贬义色彩的，但是那仅仅只是在只光不快的时候，如果能做到快了，那说明应变能力很强了。“临阵磨枪”，正是阿朱的办法。没有能力弄来完整的的正规化的流程（人员，成本，时间等的压力），那么就遇见问题解决问题吧。正如本书中前半部分那样，其中大量充斥着详实的例子，真实的场景，细致的描述，具体的解决办法。而软件开发方法的每一次巨变，都是积累了无数次的这种小变以后产生的。无疑，正规化的流程教会了你如何来做，但是阿朱在告诉你如何做的同时，顺便还告诉了你为什么要这么做，以后出现了新问题要按照什么思路来解决。这是本书高明的地方。3.交流的重要性在读本书的时候，我感觉到大量的问题的根源来自于信息壁垒，因为职业化和专业化同时造就了中心化和孤岛化。往往这种情境造就了相互之间的难以理解，交流之间的障碍，相互之间的信任等等。传统的软件开发方法曾试图利用结构化，标准接口化，文档化等方法来解决这个问题，但是直到今天，效果依然的不理想。而当前解决这个问题的唯一办法还是只能更进一步的加强交流，相互理解，力图减小这个信息壁垒。根据实际效果来看，当双方的相互能理解程度达到一定的级别以后，其相互之间的交流的效率将呈爆发性的增长。当然，这也是自组织系统一直追求的，而传统的结构化系统一直在回避这个问题。4.没有磨枪，就不要说自己磨了最后想说一下这一点。本书可以明显的被分为两部分，前面一部分让我看起来感觉非常的舒服，因为我确实的明白阿朱说得非常对。但是到了后面，感觉阿朱写得就不那么好了，特别是在最后，对问题的分析越来越让我觉得走错了方向。阿朱是一个从传统软件行业走上来的程序员，其至今的经历是一笔宝贵的财富，这也正是本书前半段的价值体现。但是毕竟，阿朱是走的实践派的道路，彻底的实用主义，对于其价值背后的抽象拔高并没有花费太多的精力，这使得阿朱在靠感觉论述一个自身的熟悉的领域的时候，总会产生一些偏差。所以本书最后的部分，可以看，但是慎重学习。5.关于成功成功没有任何的捷径，不要指望可以通过学习一套打遍天下无敌手的技能。只有不断的正视自己的不足，不断的在学习中改进提高自身各个方面的能力（无论是在深度上还是广度上），在任何情况下，你都是一个比正规军还正规的“正规军”。无论什么问题，归根到底都是人的问题。不断提高人的素质，将来有一天可以解决一切的问题。

实在、实用、实可进步

读过该书了，喜欢。作者语言平实、诙谐、小技巧、小经验很多、很实用，反映了作者的聪慧、好学和认真的积累。可喜可贺，但有些知识和经验如果和管理学基本原理相扣（明扣、暗扣均好，我个人以为后者更佳）可能会使作品增色不少！！

醍醐灌顶---阿朱是个用头脑思考的人

刚看到《走出软件作坊》这个书名的时候，有点怀疑到底是不是值得读的一本书。毕竟自己写过一点小程序，也关注过IT业。但是在某个blog看到了推荐，所以决定还是要去看一看。开始读，便觉得爱不释手。果然是本好书，我很赞同阿朱那种务实的笔锋，提出问题，并指出问题，并给出解决方法。面对问题，就是要分析问题，不要抱怨牢骚，这个并不是解决问题的方法，阿朱的方法很简单，不是有问题么，一条条写下来，看看到底是什么问题，但往往写下来之后才发觉，问题就那么点。很赞同阿朱的总结法，对工作过几年的人来说是不是要回顾一下呢，不能老做和尚撞钟啊。

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

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

很实在

我翻了下豆瓣上关于这本书的评论，有好多是同样的几个人发的，貌似有书托之嫌。好在这本书确实很不错。里边没有什么大道理，讲得很实在，而且是结合作者多年的开发经验在谈。内容比较杂，好像各个方面都讲到了，也点出了问题和解决问题的方法，更多的是引导我们去思考，有些地方点到为止就可以了。虽然本人还未毕业，但如书中所说的一些问题，同学们在实习中也觉察到，我想阿朱所讲的那些问题，肯定有很多业内人士都认识到了。但真正能够想出不错的解决办法的人还是在少数，甚至一些人会在得知某种解决办法时，也不去试试。我想到唐骏的自传《我的成功可以复制》中所讲到的他初到微软后的一个故事，在他意识到Windows多语言开发模式上的问题时，他提出了这个问题并提交了自己的解决方案，更重要的是他对一个小模块进行了试验并给出可行性报告，而很多同事也发现了这一问题，也有些提交了解决方案，但也到此为止，唐骏是唯一对解决方案找到论证办法的人。所以，发现问题后必须分析问题然后想办法去解决，不管这一问题是否应该由你来解决。只要他阻碍了你的工作进程，你就应该想办法去解决，不管你是直接去解决，还是找其他人去解决。

成长的轨迹——作者写的特别深刻特别实在

http://www.cnblogs.com/Jianchidaodi/archive/2008/12/25/1362293.html最近断断续续的在读《走出软件作坊》这本书，感觉特别深刻，特别实在。它里面没有高深的理论，空洞的说教，都是作者一路上的真实经历，曲曲折折的，但又是实实在在的，能解决问题，特别是针对中小型软件公司问题。字里行间，刻着作者的平凡而又不简单的经历，一家软件公司的成长过程，软件过程管理的提升途径，各种软件行业人员的成才轨迹……，在后面的拜读中，我想我也会整理出书中所说的各种成长轨迹。当然这本书也许你读的并不是很轻松，里面有你想要的各种答案，简单可行的答案，简单的到你自己感觉到惭愧，但是为什么你自己平时却没有想到呢？在SD2.0 大会上，流传着这样一句话，我爱问阿朱，问跳槽、问求职、问创业、问成长……，名不虚传

我读这本书

抛却技术争论，去除浮躁喧嚣，这是《走出软件作坊》给我的感觉。也会有人会说这书名起的不符合软件开发的思维，说阿朱根本不懂软件开发，但内容这么好，谁又会对书名抓住不放呢？博客连载成书，磨十年之功，阿朱端的是所有国内程序员的成长和梦想。大多数还在这个行业里打拼的，都是普普通通的年轻程序员，或者有兴趣爱好，但却没有天才脑筋，但又还想留在这个圈子里面，但又不知道今后会发展成啥样，到了所谓的30岁又会怎样？所处的是再普通不过的国内行业软件小公司，没有无需自己操心的正规的软件流程，却又有一人承担起多重角色，别人整天在研究讨论一些新新技术，而自己却还耗费自己的青春在不知经历了多少代人多少手的代码上。好了，来看看阿朱的这本书吧，他是CTO没错，但他写的是给所有还在职场水深火热的程序员看的。 面面俱到，有的时候甚至会让你觉得他罗哩罗嗦，但说的都是事实，说的都是解决办法，不对么？都是我们一直在面临的现实，面临的客户，以及我们的心态。还是放下埋怨吧，打消此处爷不爽自有留爷处的念头吧，回到地球，再适时的跳出烦恼自己的圈子，在圈外去思考，情况为什么会这样发生？该找些怎样的对策去处理？这跟技术实力无关，这跟一个人的EQ有关，跟一个人的成长有关。还是那句话，技术天才永远是少数人。阿朱在告诫我们很多事实：做人要正派，既然在企业做事，要以企业收益为己任，要以企业和老板的想法为己任，当然不是让你去逢迎拍马，做人要有原则。但要把事情做好做利索。这些其实都是再现实不过的事情了，阿朱一代还有养家糊口的意识，现在进入这个行业的人们对这样的意识则是越发缺少了。一个程序员乃至IT从业者的成长，不是仅靠技术上的钻研成为大牛就可以了，需要的是全方位，更重要的是心智上的成熟，才所谓成人了。而阿朱的这本书就是带着我（们）开始慢慢的反思自己，让自己落地，考虑眼下的问题并思考解决方案。人就是怕认真，一认真了也就没什么难事了，写程序是这样，做事更是这样。

没想到书没看多久，就遇到了一个软件作坊

http://www.imisv.com/2009/01/%E5%85%B3%E4%BA%8E%E8%BD%AF%E4%BB%B6%E4%BD%9C%E5%9D%8A/前段时间看了《走出软件作坊》这本书，觉得不错(也有不同意见)，是作者多年工作的积淀和总结，有很多经验可以借鉴，也可以从一个侧面了解了特定行业软件企业和从业人员的状态。没想到书没看多久，最近就遇到了一个软件作坊。事情是这样：公司需要开发一个SAP到金税税控机的接口软件，用于自动打印发票。找了几个供应商来做演示，有SAP、IBM和国内某作坊。因为与会者有不少是来自国外的同事，所以主要用英文来做讲解，多少有点小难度，影响了沟通。演示机器的设置也有问题，临开始了才发现不能接入我们公司的网络，手忙脚乱了半天。演示中展示了一些系统截图，为了保护敏感数据，对截图上某些数据做了涂改。这当然可以理解，可是偏偏幻灯片上的截图用mspaint上涂抹得东一块西一坨，如同涂鸦。熟悉自己系统的演示者操作起界面来速度超级快，APM达到60+。感叹一下，作坊不易开啊。

传道者阿朱

这本书，买了有一段时间了，一直忙，没来得及看，但是悬在心上，总是一桩心事——或者说，一项没有完成的作业，所以，抽时间阅读完，仿佛放下一块石头。说放下，其实是获得。和阿朱认识，在网上，没有见过面，不过在我的概念里，见没见过面不重要，是朋友就够了。我起初了解阿朱，是因为阿朱的专业，后来谈起来，才赫然发现阿朱的博学，尤其是对文学和电影，在《走出软件作坊》这本书里，标题很多都是电影名称，看着有趣味，又生动形象。这本书我是从最后开始读的，因为我不是做研发项目管理的，所以直率地讲，这本书对我作用不太大，我买这本书，是支持阿朱，而且，在买的时候，我已经想好，要传递给需要的人。一切都是项目管理，不过项目管理又会因领域、行业、企业等而不同。《走出软件作坊》的好，在于平实、简易、实用，看惯了大部头、严谨、枯燥的专家口吻的书，听听阿朱以亲身经历，娓娓道来，而且，多是身边的例子，普遍性很强，给出的解释、解决方案也是贴实可行的，这个阅读的感觉非常好。我因为不是程序员出身，所以对那些部分都略过了，我关注的，是团队管理、员工成长，是阿朱总结出来的管理实践。这是邻家大哥式的写法，这个人，他不是高高在上的专家，不是教训人，而是无私地把自己的经验包括教训都分享出来，他走的是一条前行的路，一步一个脚印，而沿着这些脚印，可引人走出沙漠，找到绿洲。很多人缺少经验因而在费力地走着弯路，很多人拥有经验但是不善于总结和分享，又有经验又善于分享的人，难得而且可贵。我看这本书，对于阿朱的敬佩，又增几分。这本书适用于在软件企业工作的职场新人，适用于希望从技术岗位转型为项目管理岗位的人，适用于职业生涯规划为CTO的人，如果从企业角度，应当说，这本书适用于小企业，大企业有其理相通不过一般来说相对成熟完善的项目管理模式，而小企业往往因为缺少这方面的积累而需要摸索，现在，有这样的一本书，可以成为良好的指导。按照我的知识管理思维惯性，如果多一些象阿朱这样的传道者，也会就少很多的迷惑者。因为我们也在和博文合作《项目经理九阴真经》，所以后面的《策划人手记》我也特别关注了一下。事实上我注意到博文也是缘于《走出软件作坊》，看着周筠老师妙趣横生的话，我不禁好奇地想，在我们的书里，周筠老师会怎么写呢？这篇日志，我是先发在公司内部博客上，发起了一个传递活动：我请有兴趣阅读的同事，在我内部博客的日志上回复，可以找我取书。我的建议是最好是能够在20天内看完，以便传递给下一位。这本书有一个我很欣赏的设计，即在推荐序后有几页空白页，所以我建议参与传递的同事可以在书上签上自己的名字，也可以写上一句自己的读后感，我想，这也是很有趣味的一件事。

一本项目管理实务方面的好书

这不是一本教科书，没有讲过一个理论，全书都是作者创业及管理实战经验的总结。内容没有半点务虚，而且包含很多管理技巧，是技术管理、项目管理者不可多得的指导书。同时，对于创业者来说，本书是一个难得的纪实性小说。而且，如果你细心的话，会发现本书的写作方法栩栩如生，让我感觉到作者犹如在我身边，和我娓娓道来一般亲切、真实。

我认为这本书最大的不足是——没有失败的教训

在群里和作者聊过一下下，是个蛮不错的人，这本书也的确是揭露了很多项目或软件企业做的不成功的原因。但是书里全部说的是作者成功的经验，我就不相信，作者没有过失败的教训。可书中基本不提失败，所以他的对策不见得是所有的对策，因为你不知道背景和原因。知其然而不知其所以然，生搬硬套是要死人的。做项目经理或部门经理或CTO，认为失败的经验才是最重要的，成功的道路只有一条，踏踏实实，认认真真、巧干加实干的把事情做好，可是失败的教训却有N多。没有过失败教训的项目经理不可能成为一个好的项目经理，这是我的观点。我们更多的是学习失败的教训。失败对我们而言才是最重要的。不要刻意去追求失败，但是失败才是成熟和成长的源泉。

《走出软件作坊》

中国很多企业的缩写。程序员很多的郁闷在这个书中有了说明，也有了解决的某种办法。我知道这是一条不容易的路，可是我在这条路上找到了自己的乐趣和追求，依旧感恩和前行。

人，是人，真的是人——《走出软件作坊》摘录

http://blog.csdn.net/david_lv/archive/2008/05/27/2487553.aspx写了《三五个人十来条枪 如何走出软件作坊成为开发正规军》（一）、（二）、（三）后，每篇都点击上万跟贴评论无数。有网友评论我之前的几篇博文：分析的不错，方案似乎也很能解决问题！不过必须满足一个潜条件：一定要找到非常合适人。现实中，就连最基本的程序员，找个合格的也不容易（聪明伶俐的养不住、经验丰富的养不起、迟钝呆傻的没法要、碰上心术不正的还够你喝一水壶的）还有网友评论：楼主所说的很多方法，都是假设了客户还不错、对项目的重视程度、习惯于正规化的程度都还过得去，而楼上有些朋友的质疑则是指出这些资源不一定满足的情况；但是跟贴最多的评论就是：现实问题描述的很精确，但解决方案不现实，太理想化，老板根本不可能给你人。如果真的发慈悲心，也是给你一个新人让你哭死。你想主导项目，省省吧，死了你的心吧，一切都是老板说了算。而且，你敢和客户说个不字，看来你是不想要你的饭碗了。还是乖乖敲好你的代码，多干活，多跟客户搞好关系。高手做啥都是高手，低能再培养再有方法管理他也是低能。你这样研究，只能吃饱饭瞎想瞎扯蛋，有你这工夫，早就把项目做好了。种种评论来看，一切的根源都是人，是人。大家都觉得我的方法要想实施，必须老板支持，员工也是高素质的，客户也是高素质的。而三者要想凑到一起具备，根本不可能。所以我的方法算是理想的痴人说梦。能支持的老板从哪里来？高素质的员工从哪里来？高素质的客户从哪里来？好像一切都是运气而来。好像我们就有高薪能聘得起高素质的员工。好像我们的产品面对的就是高素质的客户。但我回顾了自己10多年的从业经验和管理经验，我并没有发现这个规律。我并非供职国际巨头公司，也不是国内知名企业，只是信息化行业内略有名气而已。手下很少出现名牌大学的员工，也很少能达到所谓的高薪（我自认自己还没有在马云、史玉柱、牛根生、柳传志这样大胸怀大眼光的企业家手下任过职，我们所从事的行业信息化也不是暴利的行业，大家也都知道管理软件没啥暴利，定制化修改、实施、咨询、培训、支持占去了很多成本。），我们的客户也是各种各样的人都有，从挖煤暴发户的私营老板到死气沉沉勾心斗角的国企，我们的客户千奇百怪。在这样的环境下，我能把方法用起来，我和许多网友也交流过，最重要的是我认可了以下观点，这就是一个职业经理人和老板的关系：1.老板都是疑人也用用人也疑。用人不疑，疑人不用，我不奢望。2.再劳苦功高，我也只是职业经理人，我不拥有这个企业的哪怕1%所有权，所以我做好职业经理人本分，老板的归老板，职业经理人的归职业经理人。职业经理人的职责范围的，老板权力范围的，不要超越，也不要动歪脑筋。即使公司大部分的收入都是你研发的产品带来的。3.计划不计划一件事情，执行不执行一件事情。一定要以老板利益为目的。老板不赚钱，一切好事一切好想法都会被老板推翻，老板就是老板。老板赚钱赚的眉开眼笑，其他的事情就好办的多。这是很多职业经理人居然都认识不到的，他们总抱怨老板限制太死，什么资源也不给，干活还贼累。根源就出在这里了。想实现你的想法，必须在实现了老板想法和目的的前提下才能做。所以我的方法能实现，多靠此。4.而且我的方法不是为了我自己有什么好处，我的每一个方法也都不是为了正规化装修门面图好看。我的方法都是为了解决实际问题，为了老板赚钱更快更省成本更容易，员工更省力，客户更满意，而且每个方法都是在本企业能力和成本范围内能执行落地的解决方案。这样的解决方案，哪个老板会不支持呢。但很奇怪的是，很多研发部主管都忽略这个重点，老板在想利益，他在想技术。两人说不到一个目的去，互相不理解互相不支持互相埋怨，久而久之互相猜疑互相提防互相留一手。其实技术就是个手段，赚钱是目的，双方一起绑定去赚钱，怎么合法的赚更多钱怎么来。如果研发主管能脚踏实地的从本企业的能力和困境和现状去思考改进方法执行落地，而不是抱怨这样的环境没法实现想法消极怠工或心想跳槽，我想很多心结就都打开了。只有和老板具备了这样的距离和关系，我的方法才好实施下去。所以，很多人觉得太理想化，就是和老板没有找到自己的位置。但是，即使有这样的基础，要实现我所述的方法，也需要其他的环境支持。我个人是这么看的：1.好的氛围，才会引入、留住好的人（乱世强盗多就是这个理）。2.好的人，才会有好的制度，并且保持好这个制度（制度是人定的）。3.好的人和好的制度，才会遇到好的客户（有句老话，夜路走多了总会遇见鬼。有些人老想着邪门事，最后也被邪人玩。近朱者赤近墨者黑，什么人总遇到什么人，就这个道理）。好客户就会产生好的结果。所以，好的人才，好的客户都不是运气来的，而是来自你自己。你就是控制源头的人。如何制造好的氛围，我讲讲我的职业经理人管理人的一些心得：1.师傅制。这里没有总监，没有经理，只有师傅，老师。总监，经理，会让员工产生隔阂，距离，权力争斗。每一个人总有一个师傅。每一个新人进来，都要指定一位合适的师傅。尤其是新人，更要短期内注意看时候合适，不合适就要更换合适的师傅。什么问题都可以问师傅，从技术到公司制度到公司新闻公司历史到职业发展规划到个人生活问题。团队的凝聚力，配合性，归属感，责任感，很多问题都被人的感情消化了。2.朝九晚五，禁止加班。其实大部分程序员也是不喜欢加班的（不过有些程序员是光棍，也是漂在北京，反正也是一个人，于是就喜欢呆在公司上网玩游戏看小说看电影吹空调，美其名曰加班。还有一类老板喜欢看表面功夫，谁加班就喜欢谁，于是大家都装做很忙都要加班）。因为加班不给钱。不给钱，还加班，天长日久就觉得自己很亏，心里不平衡，各种心思就都有了。其实也没有多大的事。我的老板一开始对我的不加班也是心存戒心，但是每次交给他的结果比加班的部门做的都好都快，他也就默许了。3.良好的办公环境和良好的个人形象。我们看到美女就兴奋的口吐莲花，我们看到阳光溪水草地我们就心情舒畅。当然，我们看自己，别人看我们，都是一个道理。心情好，工作才能好。一个满桌狼藉充满烟味饭味脚丫子味有人在冥思苦想解决问题有人在打游戏有人在放朋克音乐有人在骂有人在打闹嬉笑有人把脚放到桌子上的办公环境，我看谁都会逃离。4.以更快更省成本更容易完成任务为目标，以赚更多钱为目标，以提高产品质量产品价值产品售价为目标，鼓励员工进行自我岗位上的改进创新，我经常给与交流和指导，一旦有效，进行精神或物质的奖励或职位提拔或工资晋级。好的氛围有了，就需要有好的人才。以下是我引入好的人才的几个心得：1.人的年龄和工作经验拉开距离。年年招，时时招。不断看人，试人，滤人，培养人，形成层次感有阶梯有接力的员工组织，绵绵不断前赴后继，不会出现人才地震、集体疲劳、小团伙争斗。避免不同高低职位上全是80-84年的人。下属还在窝里斗互相不服（很多员工不看对方能力，就看对方的工资和年龄。凭啥你就是我师傅？），那么客户逼你，老板压你，其他部门利益冲突你，下属还闹你，你这个孤独人算是失道者寡助也。2.人的技术能力高低先放一边。首先要过EQ关。有些中小型企业没有HR经理，一般考察EQ，都是老板把关。如果你现在招人没有老板把关，那么必须先考察人的EQ，再考察他的技术能力。我最怕有些羡慕科学管理的管理者照搬什么EQ测试问卷或什么团队游戏来评测。我的评测方法仍然是不讲道理，要讲经历。没有工作经历，至少有学习经历和生活经历吧。一个人的情感、压力、正义感、真诚感、领悟力、心细观察力、思路整理总结能力、关注全面平衡能力、执着力，都能看的出来。招聘程序员也得看这些。我曾遇到一个程序员，思维混乱所以代码也混乱，思考也不全面，程序到处都是漏洞，思路也不自我整理总结，无法举一反三，给他讲了多遍的需求他都无法自己重述，一有了问题很急躁说搞不定了，一看还是很简单的问题，把错误提示原模原样输入到百度中查百度就能搜到好多，你说这样的程序员算技术合格吗？其实，试用期的三个月就是主要看他的EQ和他的技术能力、理解学习成长能力，而不是片面只看他的现状技术能力。一个不愿意学习钻研，没有方法钻研快速学习理解，推一下动一下，或者怎么说都理解不了的，都需要统统辞掉。另外，对于心术不正有仇必报不服管教之类，早就扫出门外。一个讲究吃穿用享受或者满口脏话习惯毛病一堆或者不孝顺父母或者满口介词的人坚决不能要。3.专业发展，流程协作。如果不专业化，老板有什么活就分配什么活，时间短了还认为自己是在学习更多知识在锻炼。时间长了就会觉得自己就像个混子，干什么都干过，但什么都拿不起来。出去应聘啥职位，是应聘开发呢，项目经理呢，实施呢，支持呢，销售呢。啥都做过，但啥都没做专，都了解个皮毛，真要让上手还真给人家拿不下来。心就慌了，觉得自己是个被老板困在手心的小鸟，无法飞出本企业的樊笼，一旦飞出就要饿死没有能力存活。好可怕。难道只能在这家公司耗死了？赶快能逃逃吧，逃到一个正规的专业的公司去。4.下一阶段目标交流制定。交流，我想每个CTO或技术总监或研发经理都会做。交流可以了解员工的困难和心中的疑惑、个人期望、个人专业兴趣的变化、人生观世界观技术观管理观生活观（以调整自己以后和该员工如何交流、如何讲解工作、如何鼓励、如何布置任务、如何考察等等）。交流也可以让员工多了解自己是怎么想的。双方在日常很多事情的分歧和误解就会消除，心会往一处想，劲会往一处使。但是，交流也不仅仅实现这些目标。更重要的是，交流，主要为了能给该员工制定一个切实可行的、某段时间段内可达到的、他也喜欢也愿意努力的、也会他未来职业发展很有好处的职业目标。没有目标的工作，虽然他很努力，但是他容易迷失方向。如果他又是一个不能很有悟性很有规划的人，他的工作就会形成做一天和尚撞一天钟。撞钟撞的不错，但没什么更高层次的提高。天长日久，就会木然，倦怠，不思进取，思想守旧，遇到新问题无法突破。所以，我会根据双方的交流，和员工一些协商一个下一阶段的职业发展目标，并且时常指导调整他的做事方法和思考方法，给他讲解一些我过去的工作经验和我的感受，鼓励指导他们有计划有目标的走的更高更专业。这是很多研发部门主管没有做的一点。最后有几句话和大家分享一下：1.毛主席说：社会主义就是打土豪分田地（不是资本论这样的天人天书），要天天讲，时时讲，到处讲，要团部建设到连队。所以，借用毛主席的方针，咱们的团队精神建设也得这样。天长日久，就形成了文化精神，就形成了习惯。2.习惯决定性格，性格决定命运，细节决定成败

初步的感想

1.对拿单型的公司各种面临的问题讲述较多，对专门拿单的软件公司可能有价值。2. 对于软件公司内各种实用性的经验讲述较多，很多想法对于软件管理人员来说也不是什么新东西，但没有象作者这样用心去积累。3. 能给我带来直接价值的东西不多，但是有空时翻翻他的文章可以引发一些思考

18评-《走出软件作坊》，从开发到实施

评论很具体，有点长，把原来发的博客链接提供到这里，也许对感兴趣的朋友有帮助。《走出软件作坊》读后感系列之一--我和阿朱（http://blog.vsharing.com/hopeful/A797378.html）《走出软件作坊》读后感系列之二 --CTO悖论http://blog.vsharing.com/hopeful/A798106.html《走出软件作坊》读后感系列之三 --人人都做多面手http://blog.vsharing.com/hopeful/A798529.html《走出软件作坊》读后感系列之四 --职业规划之悖论：要成为项目经理？http://blog.vsharing.com/hopeful/A799074.html《走出软件作坊》读后感系列之五 --规划人员，产品的灵魂http://blog.vsharing.com/hopeful/A800135.html《走出软件作坊》读后感系列之六 --房子越做越大，只长胖不长高http://blog.vsharing.com/hopeful/A801049.html《走出软件作坊》读后感系列之七 --程序员最牛武器PPThttp://blog.vsharing.com/hopeful/A803935.html《走出软件作坊》读后感系列之八 --把各个客户的优点集中就可以做出最佳客户吗？http://blog.vsharing.com/hopeful/A805366.html《走出软件作坊》读后感系列之九 --你的软件平台是怎样的？http://blog.vsharing.com/hopeful/A806973.html《走出软件作坊》读后感系列之十 --培养个蛋白质女孩写文案？http://blog.vsharing.com/hopeful/A809693.html《走出软件作坊》读后感系列之十一 --演示的技巧http://blog.vsharing.com/hopeful/A811755.html《走出软件作坊》读后感系列之十二 --关于软件的报价http://blog.vsharing.com/hopeful/A812543.html《走出软件作坊》读后感系列之十三 -实施顾问该如何养成？http://blog.vsharing.com/hopeful/A816127.html《走出软件作坊》读后感系列之十四 -实施经理该有什么素质？http://blog.vsharing.com/hopeful/A817240.html《走出软件作坊》读后感系列之十五 -选择典型客户的技巧http://blog.vsharing.com/hopeful/A819994.html《走出软件作坊》读后感系列之十六 -客户服务工具之变迁http://blog.vsharing.com/hopeful/A819998.html《走出软件作坊》读后感系列之十七 -职业经理人定位http://blog.vsharing.com/hopeful/A820063.html《走出软件作坊》读后感系列之十八 -管理软件人的出路http://blog.vsharing.com/hopeful/A820065.html

如果我来做软件（1）- 评《走出软件作坊》

http://sunxiunan.com/?p=1302走马观花看完了《走出软件作坊》，如果打分的话，只能给个三星加，从话题比较少见出发，可以勉强给到四星。原因很简单，作者本身眼界以及所在行业的局限性（管理信息系统开发），加上为了更大范围适应读者，导致对问题的探讨浮于表面，除了某些章节有些新意，大部分文字都是看看即可。比如最后的几个章节，有价值的地方不多，完全可以去掉。书中两个地方我觉得很有意思，第一是介绍他如何对某个企业进行调研的过程《焦油坑》，另外是他如何快速的融入第二个公司的过程（page275）。由于文字过于口语化，很多精华的地方都被淹没在长篇大论的叙述文字中，这是这本书的另外一个弱点：有亮点，但是亮点不明显。第三个问题是可操作性稍差。尽管书名开宗明义是要让小型软件企业或者小型软件开发组织能够提升他们的项目管理开发能力，可是书中介绍的办法过于流散，没有一个可以比较容易遵循的办法，方法散落各处，不同开发周期的侧重点也不同，比较倾向于前期调研以及与客户的交流，如果能够加重介绍一些开发中后期的管理以及开发流程各个过程的文档工具使用，就比较完美了。总而言之，作者的视角偏向于一个经理人或者一个高层，不像从一个工程人员角度看问题，很多值得展开的细节内容感觉是隔靴搔痒，另外缺少在大型软件企业的经历导致流程上的不规范（所谓中小企业，并不代表管理上的不规范），这都是遗憾之处。尽管没有做过开发管理，可是也吃过猪肉。在后续的文字中会介绍如果我来负责从头开发一个软件，会如何操作，将从不同的角度谈谈如何开发一个软件，希望能够给这本书做一些补遗。

很不错的一本书！

很不错一本书，软件公司、产品经理、项目经理推荐阅读！确实很不错的一本书，电子版看后甚为喜欢，准备入手纸质版！本书教你站在老板、客户、实操人员，项目经理、技术人员不同的角度审视问题，找出问题，解决问题。书中阐述的很多问题都是原公司存在的问题，也就是小企业的弊端，很希望原Boss能看到，其实软件公司不是仅仅有双软认证就是，其中很多门道很多规则都是我们所不了解的。很实用，很有价值的一本书。

很值得看的书

我是先看了电子版后又去买了本纸书，里面的很多办法让我很惊喜，在日常工作中经常遇到文中讲述的现象，能踩着过来人的脚印走路，可以少摔很多跟头，在这里说声谢谢你，阿朱。

每次阅读此书，都是久久不能平静。

每次看后都感慨很多，绝对的共鸣，并且思考很多。但是最终有一个很浮躁的感觉，读后一两天总是左思右想（总觉得自己太渺小了，很多事情有点无能为力），无法全心投入工作和学习。本想向全公司推荐，最后还是没有推荐。（当然这只是我个人的一些感触，我自己还是从这本书中学到了很多）

打造五星级的软件作坊

http://david-xiao.spaces.live.com/blog/cns!5797CC4C4D67F9E1!362.entry最近读了阿朱编著的《走出软件作坊》，在书店看到这本书时立刻被书名吸引住了，在封面右侧醒目的用白底黄字粗写的标题：三五个人，十来条枪，如何成为开发正规军？书的名字取得好，这个问题也问得好。书很厚，洋洋洒洒45万字，是一本拿在手上沉甸甸的足有400多页的厚书，看完后你明白了这个问题的答案了吗？我不知道你的答案，每个人都有自己的答案。Oh, sorry, 在这里俺并不想讨论这个问题，反倒是对于软件作坊这个话题，忽然间很想讨论一下。我记得不久前也曾经参与过一个小组的讨论，在那个讨论中曾提到了作坊与正规军的比喻，本来主持人是想通过作坊和正规军的比喻引导大家改变作坊式不规范低效的作法，转向更为高效的开发方法，但是开放式的讨论却发展出了一个有意思的问题：作坊就一定差吗？正规军就一定好吗？在很多的人印象中作坊似乎就是街上的小摊：脏、乱、差，作坊出来的产品也似乎是质量低劣的代名词。这让我想起来了山寨手机，也想到了在网上流传甚广的华为对山寨手机的分析胶片。山寨机是作坊生产的，那山寨机的质量就低吗？什么是质量？质量是满足用户需要的程度。举个例子：如果用户本身对手机使用寿命要求不高，例如一个手机能用个两年就不错了，两年后再换个新的，那满足这个要求山寨机的质量就是好的。我们给软件作坊扣上了一个大大的帽子，先入为主的认为作坊就是不好的，低质量的。问题的根源在哪里呢？到底是软件作坊本身不好，还是我们自己没有做好软件作坊！ 不妨先让我们比较一下软件作坊和正规军的差别到底在哪里：1) 人员规模 正规军是大部队，黑压压的一大片。再看作坊这边就这么三/五个人，十来条枪。但是我们再认真看看，著名大公司的Feature Team大小也就6，7个人。很多著名的互联网公司(例如：YouTube, Facebook)启动人员规模都在20人以下。2) 流程规范 正规军一进去就练正步，站姿，敬礼，各种流程规范完备齐全。再看作坊这边很多时候就是走过去说一下，几个人简单碰一下。但是别忘了：面对面交流是最为高效的交流方式。敏捷开发的核心思想之一就是消除在软件开发中各种浪费，特别是在流程限制上的浪费。3) 资金投入 正规军一动就是粮草先行，各种资源充分保障。再看作坊这边什么都得抠，什么都得省。但是由于开源软件，免费服务和硬件的飞速发展，在软件开发的投入已经越来越集中在人身上。如果上面这些差别都不是，那最大的差别在哪里？ 一个字，人！有再多的人，不协作在一起，也是一盘散沙；有再好的流程，不明白流程的目的，不认真地执行，也是花架子；有再好的工具，不好好地利用，也是白费；有再多的钱，也经不起烧；我们一定要发展为正规军吗？印度最大的软件公司TCS拥有CMM最高级别的认证，在大家的眼中当然是正规军了，国内近年也涌现了多个优秀的外包软件公司，这些公司似乎光芒四射，那让我们认真地思考一下，软件外包的核心目的是什么：降低软件开发成本，外包的东西不可能是企业核心竞争力的东西。那外包公司自己的核心竞争力在哪里？用低廉的成本制造客户要求的软件。这让我们想起中国的制造业。我们一定要发展为正规军吗？如果作坊可以在很特定的领域做的很深入，活得很开心，为什么一定要发展为正规军？例如：美国Pamone公司是世界颜色标准的制定者，它是个家族式小公司，它专门做颜色的编码和标准化。现在和未来中国的软件大环境为各种软件作坊提供无限的可能，为什么一定要变为正规军？也许成为正规军后反而无法生存和发展。为什么在国外有大量的工作室和小型软件开发服务公司可以很好的生存和发展？除了版权保护的大环境外，还在于人员的专业性。作坊也是可以做成5星级的，要做一个5星级的作坊，首先要找到合适的人，可能您会觉得我就这么一个作坊，怎么和正规军去抢人才。确实很难，但不是做不到。要卡好选人这一关，因为它非常的关键，宁缺勿滥。优秀团队的生产率可以是平庸团队生产率的10倍，由于软件作坊规模不大，不需要去找很多人，所以不断积累，总是能找到几个合适的人。找到合适的人后培养他，留住他。在一个领域做深入做强，如果这个软件作坊在某一块领域内就是领先的，那人员为什么要跳去其他地方，至少他在选择之前会慎重考虑。做5星级的作坊需要5星级的团队，怎样打造一个5星级的团队，这是一个巨大的话题，需要另外一本400页的厚书。打造五星级的软件作坊 是一本不错的书名。如果哪一天哪位仁兄想出这本书时，请注明原话出自这里哈。(^-^)是时候给作坊正名了，作坊本身没有好坏，只是做的人把它做好或者做差而已。让我们一起努力，打造5星级的软件作坊。

从本书中学什么?

最近赋闲在家,于是有了啃"闲书"的时间,其实这本书于我而言并不是完全的"闲书",因为目前我还从事软件开发这个行业,也有过不少失败的经历了,趁着这段时间,我回想,我反思,为什么有人做事就能成,为什么有人努力却不得正果...很多很多的"为什么"浮现在我的脑海中.几天的时间,大体读完了本书,我想说的是,有空了还会读第二次,第三次...因为里面有太多切实的经历以及作者面对这些他人觉得困扰的情形解决的思路.我想说,面对同一件事情,处理的方式不同,面对的态度不同,往往就有不同的结果,甚至于可能是天堂和地狱的区别,这也许就是所谓的"心智模式",它影响着我们对外界的认知和处理方式.在我们初学软件开发时,什么设计模式,OO,软件工程等等学院派的理论学了不少,其实,当真正面对具体的问题时,你需要有足够的"心智"来认清你周遭的事物和人,这样你才能在现有的资源之间折中权衡调度,本书中作者列举了不少他曾经面对的也是我们很多人都面对过的困境,给出了自己面对这些时具体的处理方法,我想学习作者如何处理事情,不仅仅是做软件开发写代码的人才需要去学习的,也值得其他人学习.除了上面说了学习作者做事情的方法,在本书中,还有其他的一些内容,比如如何处理员工和老板的关系,作者从试图剖析老板的心理给出了自己的一些建议;如如何规划自己的职业生涯,如何面对跳槽这个问题;如何进行时间管理,等等等等,这些都是很现实的问题,身在职场时常会考虑.总之,阅读过本书之后我最大的收获是:1) 以积极的心态去面对你所处的环境和工作,在具体的环境中进行权衡,另外要多想想多思考别人做事情的方式.2) 时间管理,我已经开始使用google docs记录我每天的时间和金钱上面的花费了.3) 务实,作者很务实,从他说他不是一个完美主义者,只会把精力放在最重要的几件事情上就可以看出.其实人生关键的也就是那么几步,把这几部走好了,大体上差不了.4) 有待补充...暂时写到这里吧,我还得消化思考一下本书的内容.

我们要靠什么走出软件作坊

来源《中华读书报》（http://www.gmw.cn/CONTENT/2009-03/11/content_899594.htm）。摘要：“软件本无法，有法也空，一法不立，万法不容”。从这个意义上，我们就不难给阿朱所说的话做出一个注解：透过一个个实用的点子，《走出软件作坊》实际上是一些思路。真正走出软件作坊的方法，正在于把这些思路再化为适应应用者实际情况的点子。 即使在维基的发源地美国，优秀的维基式图书也不乏败绩，那么，《走出软件作坊》因何而畅销？也许我们可以这样认为，一本真正有影响力的书，它的价值不只体现在销售数字之上；它本身必须成为一个平台，承载着与其所描述内容相对应的领域的责任。拿这个标准来衡量，《走出软件作坊》显然可以称得上是一本有影响力的 图书。在北京图书大厦，我们可以看到，这样一本纯IT应用的书，在上架建议上却被标上了“经管案例”。显然，它的阅读范围已经超越了IT从业人员。接下来的采访结果印证了我们的猜想——有一位读者曾遇到了这样一件事：某软件公司在实施客户的项目时遇到了重重困难，实施效果也颇为不理想，客户一怒之下，送给了该软件公司项目经理一本书，居然就是这本《走出软件作坊》。这种影响力吸引着我们走近《走出软件作坊》的作者阿朱（吕建伟）。既然研究的是影响力，关注点当然不只是《走出软件作坊》本身，我们关注的最关键问题一如我们在标题中所表述的——我们要靠什么走出软件作坊？维基式的写作过程在阿朱看来，《走出软件作坊》的影响力来自于一个契合点，而找到这个契合点，则是冥冥之中一种莫名的力量，或者也可以说：一切自有定数。事情是这样的：转眼之间，阿朱从事软件开发行业已有十个年头了，这个时候，阿朱有了一种冲动——人们常说“十年磨一剑”，阿朱反问自己“十年了我磨了一把什么剑”呢？为此，他选择了一种别样的方法——开博。他把十年来的心得体会经过系统整理以后，发表在自己的博客之中。当时的阿朱无论如何也不会想到，自己的这一举动构成了契合点的一方面。让阿朱没有想到的，是网友的反应。发表第五篇博文之后，他的博客引起了大量网友的关注，不少网友试着把自己在软件开发和实施过程中的困惑写在了阿朱博客的留言栏中。热情的阿朱开始试着用自己的经验帮助这些网友解决这些问题。正是在答复、评论等一系列简单的互动中，一场维基式的写作展开了。这种维基式的写作绝不是悄无声息的，阿朱的博文在引起更多网友关注的同时，也引起了出版界的注意。当出版协议摆在阿朱面前时，他选择了接受这个挑战。作为一名职业写手，笔者总爱把写作分为两类：一类是在策划编辑无情的催促下，进行痛苦的、挤压式的写作，笔者把它称为是拉动型。另一种则是有感而发，非要一吐为快的推动型。阿朱的写作过程显然颠覆了笔者的分类。阿朱进行的确实是拉动型写作，但他却在这个过程中充分享受到了写作的快乐。原因很简单，阿朱一语道破了其中的玄机：“十年的工作积累，让我有了近两千个工作文档。即使不写这本书，我也要重新整理它们。我写作的过程不过带着目的，去重新整理它们。”而更重要的，是阿朱“绝不是一个人在写作”。他介绍说：“网友的提问，让我更加深入地思考某些问题。如果我从一开始就接受了出版社的约稿，有些问题我可能会一笔带过，而认识不到它对读者的价值。”我们可以这样认为，网友帮助阿朱在成书的过程中，选择了“什么才是他们真正需要的”。这种维基式的写作也有不利的一面，这就是写作的成果完全展示在它的载体——互联网上，而互联网的一大特性就是开放。完全开放的东西，在印刷成纸介质的图书时，还有价值吗？出乎我们的意料，当我们就此询问《走出软件作坊》一书的策划编辑周筠时，得到的答复却是这本书的第一版已经售完。即使在维基的发源地——美国，优秀的维基式图书也不乏败绩，谈起《走出软件作坊》的畅销，阿朱道出了契合点的另一方面：“一方面是出版编辑和网友帮助我放弃了自说自话式的写作方式，而换成了更易于读者接受的叙事型写作方式，另一方面是因为中国软件经过了多年的发展，中国软件人已开始了思考，他们需要一个诉求点，而《走出软件作坊》正好充当了这个诉求点。”点子还是体系应该说，《走出软件作坊》一书填补了一个空白点。在此之前，作坊型的软件公司项目经理，如果想提高自己，只能选择微软、谷歌、华为这样一些颇具规模的公司的管理方法。读过之后，不少项目经理在感叹这些公司的管理方法先进之余，却碍于条件所限，无法在自己的公司当中实施。而纯IT技术类图书，则多数是纯技术开发类作品。这样，中小软件企业在IT与管理的交合点上，存在一个巨大的空白点。阿朱在《走出软件作坊》一书之中，针对的正是这个空白点。他提出了一系列针对作坊型软件公司量身定制的点子。我们知道，小成需要的是点子，而真正的大成需要的是一个体系，那么，应用《走出软件作坊》，作坊型软件企业真能踏上成长之路吗？对此，阿朱谈了自己的看法。“《走出软件作坊》的内容，90%的内容是我亲身经历过的，另外10%的内容是我帮助网友在网上回答问题时创作出来的，因此，它是完全真实的，这保证了它的实用性。但不能因此就说它是一个点子合集，从这本书的内容体系中不难看出，从最初的组织结构、团队文化，到后边的软件过程管理、团队激励、绩效考核、职业发展规划、未来业界发展趋势、个人素质提升等内容，这些内容已构成了一个体系，这个体系涉及了一个作坊型软件公司成长所需的方方面面。”而之所以没有强调这个体系，阿朱强调：“处于不同层面的人有不同的需求。”关于走出软件作坊的方法，51.com网站的CTO王兴华写了一句耐人寻味的话：“原则面前，人人平等，才能走出软件作坊。”这里的原则，我们不能简单地认为是一些方法，而只能理解为某种思路。篡改某位武学大师的话，就是“软件本无法，有法也空，一法不立，万法不容”。从这个意义上，我们就不难给阿朱所说的话做出一个注解：透过一个个实用的点子，《走出软件作坊》实际上是一些思路。真正走出软件作坊的方法，正在于把这些思路再化为适应应用者实际情况的点子。谈起收获，阿朱认为：“最大的收获是认识了非常多的业界朋友，大家可以一起交流探讨，更加开阔了眼界和创新思路。”但与很多作者不同，阿朱介绍说：“我热爱职业经理人的工作，因而不会因为这本书的成功就转去做咨询。但‘走出软件作坊’事实上已成了一个项目，我并没有因为已经成书，就停止回答网友关于软件项目方面的问题。今后，我还会投入业余时间在这上面，我喜欢看到各类公司从软件中得到价值，也希望能因此而帮助中小型软件企业得到质的提升。”退回到图书业本身，这也许意味着《走出软件作坊》还有续集，让我们开始期待吧。

韩磊推荐：这本书更有价值的地方，是字里行间无处不在的实践知行观

http://hanlei.name/archive/2008/11/19/744791.aspx今年早些时候，有一系列文章在CSDN Blog上陡然火爆起来。博主阿朱，以《三五个人，十来条枪，如何走出软件作坊》为题，总结了自己从业十年以来在技术项目和技术团队管理方面的经验和思考，截至8月28日，总共发表43篇文章。博文视点也以其敏锐的嗅觉，迅速发现并决定出版这系列文章。 阿朱本名吕建伟，多年以前我们是混同一个技术论坛的网友，但直至今年CSDN上海英雄会方才有缘见面。在从上海回来的飞机上，聊着软件和非软件的话题，连飞机餐都没觉得有那么难吃了。也是那次谈话，给我留下了阿朱“稳重、实在”的深刻印象。 《走出软件作坊》一书，可以印证我的感觉。项目管理与团队管理，向有土、洋二派，尤以洋派最有市场。阿朱此书，不虚谈理论，全部来源于其十年实践所得。这不是普通的十年，而是一位普通程序员成长为CTO的十年。在后五年中，阿朱参与并见证了一家公司从软件作坊壮大成为行业领先软件服务提供商的过程，这正是其他许多中国软件公司正在或想走的路。阿朱及其所在机构的经验与教训，对于本土小型或创业型软件企业，具有极其宝贵的参考和借鉴价值。 然而，这本书更有价值的地方，是字里行间无处不在的实践知行观。软件企业和软件从业者，最该从里面学到的，也是一种不盲从的反思精神。每家公司都有自己独特的外部环境、文化氛围；“像成功公司一样好的团队架构与管理模式”听上去很美，多数时候却并不符合某家特定机构在某一特定时期的现实情况。为员工提供免费餐食，就算给的是神户牛肉，也并不足以让你的公司成为第二个Google。所谓管理，规范、制度、方法、人情缺一不可。人情，或谓关系，在中国公司中是决不可无视或轻视的因素，也是最可能存在变数的因素。除此之外还有其他变数，是在制定符合本机构实际情况的架构、制度时必须注意的。所谓学我者生，像我者死，学的和像的，实在不是同一个“我”，读者不可不察。 这本书另外一个有价值的地方，是作者与读者展开的网上讨论。在阿朱的Blog上，这系列每篇文章都有大量的读者评论，而阿朱也往往会在下一篇文章中，或直接或间接地答复和参加讨论。这些讨论有一部分写进了成书，更多的部分仍然留在网上。我建议阿朱为本书开通一个讨论区，使其不但有印刷的版本，也有更为鲜活和即时的网络版本。我深信，互联网改变了并仍在改变着传统出版。这本书和其他书在网上如何做出延伸价值，值得探索。 阿朱说，他希望在所在机构做大上市后，再写一本书，总结《走出软件作坊》之后的经验与思考。我期待那本书的面世，但并不认为书中的内容要等到出版后才能一睹为快——诸位不信？不妨到阿朱Blog上看看，《CRM下午茶》等系列文章，已然是颇值一读的了。

不说好坏，但看适用

网上看了前几篇大公司流程多，关系杂，内耗大，人浮于事现象比较严重，流程制度，很多时候其实也是双刃剑。 小公司（或者说小作坊），身处其中的我们又是否能熬到正规军的那一天？或者说这十来条枪是否真能打出条正规军？带着这些个困惑看这本书，开头之后不怎么翻的下去， 不是说这本书本身不好，作者平实的字句中确也在说着最真实的案例方法等等，只是对于没有什么国内小企业经历的人来说，对于书中所讲的软件公司的各个部门各个职位的各个角色的定义定位，我恐怕不是放之四海而皆准。书不错，不过可能不是很适合现在阶段的我。继续自我纠结中，其实更想看看书中提到的《微软的秘密》

这本书反应了做it不容易

做it真的不容易啊。做软件工作量，真是非常惊人的。书中反应了很多问题，这些问题有80%是所有人都知道，可是就是做不到。做it最需要的还是战胜自我。