《走出软件作坊》是一本由阿朱著作，电子工业出版社出版的平装图书，本书定价：39.80，页数：403，文章吧小编精心整理的一些读者的读后感，希望对大家能有帮助。
《走出软件作坊》读后感(一)：围绕问题，灵活地寻找解决方案
http://kaverjody.com/《走出软件作坊》读后感/
此书（走出软件作坊(IT人升职必备) – 图书 – 当当网）在网上的名气实在有点响，本没有想法要去看，发现长逛的几个社区里大家的评价都还挺高的，就决定要瞟一眼，也了解了解别人是如何走上CTO之路的，以及他描述的究竟是一条怎样走出软件作坊的道路。
不搜不知道，居然还有个专门的论坛。。“欢迎访问《走出软件作坊》官方论坛”
读完整本书后的感受就是，虽然作者一直在强调自己是三五条枪的软件作坊，搞不起什么CMMI、RUP之类的重型方法，也难以模拟国外流行的敏捷模式，所以要走自己的道路。但其实呢，作者无非是更好的平衡了企业当下的需求，和对CMMI、RUP、敏捷的追求而已，因为他所遵循的道路始终是抓住当下企业面临的最大问题，以规范化、可度量化、责任到人等方式来处理。但此书的局限在于，它并非适合所有行业或是所有的IT从业人，和作者一样处于管理软件行业的从业者可以更直接或是更简单地从书中吸收知识，而其他人则不得不多加思考，领略作者解决问题过程中的思路，才能灵活应对自己所面对的难题，而不是生搬硬套。
@自序
“毕竟我只在企业管理软件开发公司工作过，而且只工作了十年，只服务了两家公司，所以我的见识恐怕难免狭隘，欠缺普遍性。”
@1. 组织结构篇
“要成为CTO，就必须具备以下四种素质和能力：1. 商业眼光；2. 管理才能；3. 技术眼光；4. 产品结构。”
“我的方法都是为了解决实际问题，为了老板赚钱更快、更省成本、更容易，员工更省力，客户更满意，而且每个方法都是在本企业能力和成本范围内能执行落地的解决方案。” # 脚踏实地地解决当下的具体问题，才是可选良策，再大的理想也要从身边小事做起。
“如何创造好的氛围，我讲讲我作为职业经理人管理人的一些心得：1. 抓大放小，搭台让人唱戏；2. 师傅带徒弟；3. 朝九晚五，禁止加班；4. 搞好环境、整好形象；5. 立即奖励，马上兑现。”
“以下是我引入好的人才的几个心得：1. 第一当数责任心；2. 人的年龄和工作经验要拉开距离；3. 技术第二，EQ第一；4. 专业发展，流程协作；5. 互相交流，制定下一阶段的目标。”
“公司的文化是你在日常细节工作中潜移默化感受到的。” # 大张旗鼓地宣扬某种企业文化，非常有挂羊头卖狗肉的嫌疑。
“依我看，作为中国软件群体最大组成部分的小软件公司，需要的不是UML/RUP/CMM这些重型方法，不是前几年大家关注的小组开发方法，也不是敏捷编程这样的结对方法，我们都无法有这样的资源实现这样的方法。” # 个人觉得这个观点值得商榷。
“研发经理驾驭的四套马车”
“每个人都身兼数职，而且都对自身的提高非常有好处，而不是给他身上堆砌毫不关联的工作内容。每一项职责都能互相互补，整体提高他的岗位专业性。”
“我在设计方面使用了PPT+WORD+脑图+Excel的描述方法。 …… 此外，我们还使用了需求管理工具来管理来自各个方面的需求；使用了Bug管理工具管理需求；使用了任务管理工具管理任务。 …… 在版本控制方面，我们使用了版本控制工具来控制设计文档和源代码的版本。我们还使用了自动每日构建工具，每天晚上整体编译。 …… 不过，我们倒是使用了一些压力测试工具，模拟同时并发访问，同时插入数据，同时取数，模拟网速限制。 …… 还使用了Setup打包安装工具 …… 我们还自己写了一个版本自动更新工具 …… 没有驱动力的事情我们从来不干。” # 其实作者已经做了很多的事情去规范企业软件开发过程的各个方面。
“我抓住了项目经理的两大重点：1. 业务需求；2. 项目计划、项目报告、项目异常解决、项目推进、人员调度。”
“很多人缺乏创新能力，所以无法成为总监。”
“技术是为商品服务的，能不用就尽量不用，技术是藏在商品里的。” # 不能给客户带来价值的技术，客户没有理由购买，至少对企业生存是没有什么帮助的。
@2. 过程管理篇
“写代码的8项建议：1. 重点把控输入数据的校验；2. 以后的需求再往上加，都写成函数；3. 以后再加功能，尽量不要做成联动触发的；4. 以后写代码，分离特殊处理业务和正常处理业务的功能代码；5. 对不常用的功能做一些隐藏处理，将其放到一个不起眼的位置；6. 写代码时，避免全局变量和大流水代码；7. 修改需求或Bug的时候，要按照模块来集中修改，而不要挑好改的先改了，不好改的就最后改；8. 多写视图，多写存储过程。”
“不是客户需求在变，而是你对客户的需求理解在不断加深。”
“第一回合，以开发部门老老实实修改需求为结束。 …… 第二回合，开发V.S.实施，平手。 …… 第三回合，开发胜出。”
“我走访客户，主要目的有三：1. 改善一下老板和实施人员对开发部的认知；2. 改善一下开发人员和实施人员的冲突；3. 了解客户现状，想方法如何去引导与影响客户。”
“新产品必须与公司的实力和战略相结合。” # 不能一口吃成个胖子，需要量力而行。
“保守中的创新：先剖析行业标杆老大的产品；只比客户前进半步；整合出一份吸收优点的特性列表。”
“获得公司内部最多人的支持是一件非常重要的事情。 …… 首先要获得自己下属的认同；然后是获得老板的赞同；最后是获得客户的支持。 …… 得道者多助，失道者寡助。上下左右逢源，你才能成功。” # 万不可孤军奋战，众叛亲离。
“所以我们做产品规划的时候，必须要思考新产品与老产品的关系，最好形成整合互补关系，而不是代替的关系，更不能形成互不相干的关系。”
“对于销售来说，演示的时候稳定、易用、好看、速度快就是关键。 …… 对于实施来说，最重要的就是软件稳定。 …… 对于培训来说，软件易用最关键。 …… 对于技术支持来说，软件稳定是第一位的。 …… 对于支持来说，软件自动升级也非常重要。 …… 对于后续版本开发维护人员来说，代码容易看懂，代码好修改才是最关键的。 …… 对于测试人员来讲，软件必须具有可测试性。 …… 对于文案人员来说，软件必须能让文案人员编写文档。” # 小小的PPT演示就可以看到不同利益方的不同需求和期待，一切都需要通盘考虑，整体协调安排。
“客户其实只想解决问题而已，什么技术都无所谓，只要能解决了，解决方法越简单越好。”
“解决问题，这是你自己面临的问题，你不去自己想办法，没有人会给你解决这个问题。能救你自己的只能是你自己。”
“大规模的开发，必然需要的是一般素质的人员。” # 这是一个极其重要的现实问题，寻找解决方案的根本出发点。人员要培养，但能力不会在一夜之间产生飞跃，所以必须考虑在这样的环境条件下如何开展工作。
“没有了实质的进度，也就没有了实质的项目预算管理。那到底能不能赚钱，真成了一个鬼才知道的问题。”
“我们并不是为了正规才编写文档的，我们写的每一个文档都有作用。”
“我们从来不为没有利益回报的东西多付出。” # 非常实在。
“尽量限制使用新技术，不会让新产品、新团队、新技术这三个‘新’都同时出现，风险太大了，而且坚决不使用新技术作为基础技术。”
“代码的几个关键点：1. 代码风格统一，从命名含义，到大小写，到缩进，都一致。每个源代码文件都一致，确实出于一人之手；2. 我的代码居然能看出业务流程；3. 我的程序都是小函数组成的，都有明确报错。”
“售前、项目管理、实施适用的演示方法：1. 首先要字号够大；2. PPT就是个你演讲的思路大纲；3. 字体要统一；4. 一些名词要统一；5. 不要用色太多；6. 图表太复杂；7. 讲得太多了；8. 你再把你的步骤调整一下；9. 眼睛不要死盯一个角；10. 我建议你手中拿一支激光笔，这样你就有个可握着的东西，会让你心里踏实下来；11. 讲话要大声，响亮；12. 不清楚的事情千万不要乱说，不要说谎。” # 这是我最喜欢的一部分，讲得非常详细，而且言之有理。
“PPT之外的许许多多细节：1. 你一定要清楚你住的宾馆到客户会场的交通路线、车行时间；2. 这次的听众是谁？3. 准备好你的录音笔、激光笔，以便在演讲的时候录音，反复锻炼自己的演讲；4. 如果听众要求你现场演示，也最好不要做；5. 检查好你的U盘；6. 还要把你的笔记本电脑清理干净；7. 提前到了会议现场，先看好电源插座，看看你的电脑够不够得着？8. 有多少人参会，就需要提前复印多少份听众材料，而且一旦复印，你就不要再改动你的PPT了；9. 观察会场光线怎么样，暗了就需要开灯，强了就需要拉窗帘；10. 有些领导特注意这些细节，往往都是99%都给了，就1%没有给，但恰恰就是那1%起决定作用；11. 不要评价竞争对手，不要打击竞争对手。” # 我最喜欢的第二部分，作者的经验之谈。
“如果要增加互动问答，一定要是选择题，而不要是思考题。”
“如果确实想尝试交互游戏，一定要设计一个规矩很简单的游戏”
“现场培训演讲：培训前必须和到会者交换名片，并且签到。 …… 开会前，把自己的手机调整为静音，振动都不行，以防分心。每个人都要戴手表，以控制时间。开会的时候，把手表放到桌面边，这样不用看手腕就能瞄一眼时间。 …… 一定要了解听众需求。”
“演讲过程中要注意以下几点：1. 不要把全部的功能都向客户展示；2. 不了解行业，不要打比喻；3. 不要和管理层谈行业；4. 不要和IT层谈IT；5. 我们最了解的就是我们的软件。”
“试点实施：走出第一步，一定要把型塑好，千万不要特殊事情特殊处理，否则开发部很容易变成一个小社会，开发、实施、支持全都管，再也回不到正常的流程上来了。” # 规矩不能乱。
“客服支持：于是，电话下场，QQ出场。 …… 客服人员在压力下自己创新，成立了QQ群。 …… 于是，BBS搭建起来了。 …… 这个案例库现在真是非常宝贵。 …… 这个重量级的工具就是客服工单系统。 …… 工单系统还和呼叫中心绑定在一起。 …… 工单系统和呼叫中心绑定在一起后，还能实现工单的智能分配。 …… 有了量化的工作考核指标，客服人员就有了高级客服顾问、中级客服顾问和客服顾问三个等级，工资不同。” # 典型的不断反省，持续改进的过程。
@4. 职业发展篇
“新人入职手册：每个企业和组织都有其内部的制度和规则。 …… 但由于部门内部长期协作、经理的个人管理风格和部门间的利益力量博弈，所以形成了部门内说不清道不明的规则。 …… 我的管理风格一向都是以问题找答案。”
“员工职业发展思考：一个平时不主动努力，不勤于思考钻研的人，工作中也会如此。一个说话思路都不清晰、没有重点的人，写出程序也会是一片混乱。他看什么样层次的书籍和报刊杂志，就能知道他的眼界有多宽，发展有多少后劲。如果他做的毕业设计很独特，很有思考力，我就会比较赞许。因为他是在用心思考和努力，而不是混毕业设计。” # 窥一斑而知全豹，还是kaopulity的人靠得住。
@5. 心路成长篇
“是什么造就了他们的成长呢？ …… 我把这种根源归结为责任。 …… 我能做的就是尽量展现自己的工作效果，让老板看到我的全面价值。 …… 什么是价值？我个人是这么看的：‘为客户带来好处和收入，为公司带来好处和收入。’ …… 米卢有句话：‘态度决定一切’。” # 我非常喜欢米卢的这句话，《自慢》里面其实也强调非常多次，要有正确的态度。
“想做事，胸怀要大，要踏实，要低调。” # 三点：1. 视野、理想、目标要宏大；2. 要有切实的执行力；3. 要谦逊，不可得意忘形。有远大的理想，又能脚踏实地地前进，还有谦逊学习的态度，成功岂不是指日可待？
“责任感，就能产生领导力，就不畏挑战。态度、胸怀就能决定是否有团队能让你领导，是否有人追随你自然形成团队。”
“机会，不是掉下来落到你的头上砸到你的头的。 …… 从手头做起。 …… 皆在一个‘心’字。”
“我的读书技巧：第一，我经常梳理自己的知识体系，技术的，管理的，业务的；第二，我读书就和猕猴吃食一样，先看书的目录，然后发现自己感兴趣的章节，直接找自己关注的问题答案；第三，从小到大，我都保持着读书的爱好，一本好书在手，经常饭不吃觉不睡。” # 活到老学到老，学习真的是没有尽头，人得不断地提高自己，优秀的人永不满足。
“这样不行就那样做，反正总是不放弃努力，哪怕一丁点的改进我都愿意每天去提升一点 …… 我的这些土办法都是这样点点滴滴在解决日常问题时积累下来的。” # 挺有点Scrum里面Inspect and Adapt的味道，尝试、回顾、调整的循环。
“分享给大家几句话：1. 能救你的只有你自己；2. 没有不可能；3. 这个世界没有机会，机会永远是别人的。”
==========
徐毅：独立敏捷顾问，经验丰富的国内知名敏捷及精益教练，专注于敏捷软件开发、Scrum、敏捷转型、敏捷测试、测试自动化、robotframework等。
《走出软件作坊》读后感(二)：产品经理也要懂管理
虽然自己定位在产品经理，但书中很多知识也很有借鉴意义。软件产品是脱离不了代码开发的，如果产品经理一点不钻研技术，那是于产品脱节的，也无法实现自己的想法。
本书索引：
第一篇 组织结构篇
第一章 CTO与技术总监
1、相当好CTO或技术总监，首先老板得喜欢你
2、想出与老板想法匹配的产品
3、老板给你的资源，永远小于你干事的资源
CTO四种素质：商业眼光、管理才能、技术眼光、产品架构。
4、我的日常工作（可以借鉴）
第二章 团队文化
1、职业经理人和老板的关系（职责划分）
2、老板不是混饭吃的
管理心得：
- 抓大放小，搭台让人唱戏
- 师傅带徒弟
- 朝九晚五，禁止加班
- 搞好环境、整好形象
- 立即奖励，马上兑现
好的人才
- 第一当数责任心
- 人的年龄和工作经验要拉开距离
- 技术第二，EQ第一
- 专业发展，流程协作
- 互相交流，制定下一阶段的目标
3、润物细无声（锻炼下属）
4、学习管理80后、90后
第三章 团队配合
1、混乱中的软件作坊（现状）
2、从游击队到兄弟连
软件开发团队角色：
- 帮助文档编写
- 内部培训
- 测试
- 公共代码编写
- 设计文档编写
- 支持人员
3、研发经理驾驭的四套马车
- 项目经理，1~2人
- 公共代码开发人员，1人
- 测试人员，1~2人
- 文案人员，1~2人
（P29 表1.1 四套马车在研发过程中的配合方法）
4、保证项目进度的四个“不允许”
现场开发、脱离业务、多种技术、最新技术
5、业务组长每日的进度沟通：向下、向上（可以借鉴）
第四章 项目经理
1、让人抓狂的项目经理
项目经理两大重点：
- 业务需求
- 项目计划、项目报告、项目异常解决、项目推进、
人员调度
第五章 架构师
1、李维：架构师应该具备的特性（参考）
2、需要越复杂我的成长越快（技术成长）
3、架构师必须了解业务
4、理解客户行业可以这样提问（5条访谈技巧可以借鉴）
5、MySpace怎么样做架构（案例）
第二篇 过程管理篇
第六章 老系统维护
1、写代码的8项建议
- 重点把控输入数据的校验
- 以后的需求再往上加，都写成函数
- 以后再加功能，尽量不要做成联动触发的
- 分离特殊处理业务的功能代码
- 隐藏处理不常用功能
- 避免全局变量和大流水代码
- 改BUG按照模块集中修改
- 多些视图和存储过程
2、客户需求！客户需求！
规范客户需求的管理。（可以借鉴）
3、几个过渡性的实用建议
- 修改代码前先备份,跟上日期
- 大修改前，先定一个稳定的版本发布出去
- 每天备份一份源代码
- 利用文本对比工具：WinMerge
- 发布新版本时，把关闭需求的列表附在新版本后
第七章 项目开发
三类客户：
- 根本没有IT维护人员
- 自己有专门的IT部门
- 自己有IT部门，但只做需求、招标、协调、管理等
1、共赢：说服没章法的客户
达成共识、收集需求、项目开发流程、原型。
2、文档以及文档的版本维护（可以借鉴）
第八章 新产品战略
1、做企业不能只守不攻
2、保守中的创新
- 剖析行业老大产品
- 只比客户前进半步
- 获得公司内部支持
第九章 产品生命周期
1、客户不同，产品不同
低端、中端、高端（简化版、标准版、高级版）
产品规划（新老产品关系）
公司各种角色对新产品的要求
2、什么是好软件
- 第一版：实用性。
- 第二版：包装漂亮。
- 第三版：增强现有功能和稳定性，尽量易用、易维护。
- 第四版：如何兼容，如何容错，代码易读。
- 第五版：性能。数据大。
- 第六版：重构易用性。
- 第七版：打补丁，准备下一代产品。
第十章 产品定位
1、微软的产品定位方法（案例）
2、“完美”的最佳客户
解决用户最核心的问题，不可能面面俱到。
第十一章 项目需求调研
1、日本人怎样讨论需求（案例）
2、需求调研实战
- 企业部门组织结构图
- 了解项目和各个部门的关系
- 不要采用聚众座谈，而是单个击破
- 发现流程、日常处理的空白、漏洞和矛盾
第十二章 设计文档编写方法
- 首先给出功能点文档
- 然后对功能点进行优先级标识
- 再根据功能点清单编写功能设计说明书
1、用户不必是计算机高手
我们并不是为了正规才编写文档，我们写的每一个文档都有作用。我们从来不为没有利益回报的东西多付出。
第十三章 开发团队练兵
1、技术总监做对的两件事
如何阅读代码、如何学习新技术
2、技术团队犯得致命错误
新产品、新团队、新技术同时出现
第十四章 代码编写规范
1、走极端的新手
- 代码风格统一
- 代码能看出业务流程
- 小函数组成，都有明确报错
2、新手容易出现的两个错误
- 调试没有章法
- 对数据没有警觉性
第十五章 软件测试
1、有方法和没方法的区别
测试方法：
- 分工测
- 不全部测
- 每天下班前汇总问题统一上报
- 每天的测试报告要连在一起
- 每个问题要标好功能模块
- 把需求和问题分开
2、测试人员兼任技术支持
- 经常遇到的问题，就做成FAQ
- 定期培训，解答疑问，并且考试
第十六章 产品文案（案例）
第十七章 售前经理
1、不难找的售前经理
- 必须懂得客户业务
- 最好干过开发
- 有项目经理的气质
- 有那么点机灵劲儿
- 会制作PPT和写文档
第十八章 售前、项目管理、实施适用的演示方法
- 字号够大
- 要有重点
- 字体要统一
- 名词要统一
- 不要用色太多
- 图表不要太复杂
- 把握好节奏
- 调整好页的顺序
- 眼睛不要死盯一个角
- 手放自然
- 讲话要大声、响亮
- 不清楚不要乱说
1、PPT之外的许许多多细节
- 清楚宾馆到会场的交通路线、车行时间
- 这次听众是谁？
- 准备好录音笔、激光笔
- 如果听众要求现场演示，最好不要做
- 检查好U盘内容
- 笔记本电脑清理干净
- 提前到会场，看好电源环境
- 准备复印听众材料
- 会场光线
- 会前检查自己的衣冠、面貌
- 不要评价竞争对手
第十九章 软件费用报价方法
1、调研费用
2、开发费用
第二十章 实施费用报价方法
项目实施阶段：
- 调研期
- 数据准备期
- 培训期
- 上线运行期
- 验收期
1、实施费用
实施费用=（A+N*B）*实施天数
A：所选级别的项目经理每天费用；
：所选级别培训专员每天费用；
：子系统数量。
第二十一章 服务费用报价方法
免费：论坛和QQ群
缴费：有一次性交清一年（或半年）和临时缴费。
服务能力：普通级、中间级、高级。
第二十二章 打造实施顾问
1、作坊VS大公司
2、一头一尾很关键
- 不要演示全部功能
- 不了解行业，不要打比喻
- 不要和管理层谈行业
- 不要和IT层谈IT
- 我们最了解的只是我们的软件
第二十三章 实施过程管理
1、实施：做好数据准备
- 严格地测试数据字典准备功能
- 封锁数据库，严格控制数据库访问权限
- 错误日志
176 表2.4 实施工作分配表（可借鉴）
第二十四章 试点实施（如何找试点）
第二十五章 客服支持
QQ群、BBS、客服工单系统
189、P190 表2.5 客户日报、周报 （可借鉴）
第三篇 激励考核篇
第二十六章 团队激励（奖金不一定能解决问题）
第二十七章 员工绩效考核
206 表3.1 员工绩效综合评定表（可借鉴）
第四篇 职业发展篇
第二十八章 新人入职手册（潜规则）
1、职场老鸟入新巢
- 收集公司所有人联系方式
- 认识每个部门的头
- 了解现有产品
- 了解现有客户和跟单项目
- 结交与老板最亲近的人，观察他们的做事，分析老板为人
- 结交每个部门最有影响力的人，了解公司真实消息
- 了解每个主管的想法
- 寻求短期出彩的活
第二十九章 员工职业发展思考（职位、技术）
第三十章 创业小作坊职业发展思考
第三十一章 CTO职业发展思考
1、职业经理人的命名（大副）
第五篇 心路成长篇
第三十二章 关联性思维（可借鉴）
第三十三章 皆在一个“心”字（责任）
1、团队，团队，你有团队吗？（领导气质）
第三十四章 帮助过我的那些书那些人
大学时期：
- 严援朝 《CCDOS源代码剖析》
- Marco Cantu的《Delphi高级开发指南》
- Charles Petzold《Windows程序设计》
- 《微软的秘密》（可阅读）
- 迈克·波特《竞争战略》（可阅读）
- 《计算机世界》
工作时期：
- RonSoukup 《Microsoft SQL Server 7.0技术内幕》
- Don Box《COM本质论》
- 李维《Delphi高级开发》
- 王玉荣 《流程管理》
- 《谁动了我的奶酪》
- 《CORBA企业解决方案》
- 《软件开发的科学与艺术》
心智：
- 二月河 《雍正皇帝》
- 陈东升《华为真相》
- 《毛泽东》
- 《程序员》杂志
- 《财富》杂志
第三十五章 自我时间管理（参考）
第三十六章 从游击队到正规军
- 把引擎和业务功能分离
- 每日构建、每日测试、全程测试
- 代码复查
- 不要没完没了
- 结对开发
266 附录：敏捷开发的宣言与原则 （可借鉴）
第三十七章 方法反思（找到自己的方法，自救）
《走出软件作坊》读后感(三)：中国的IT人很值得读的一本书
从这本书得到了如下几个东东：
1.不要照搬书上或者网上的东西，只有真正能解决自己工作中遇到的问题的方法才是最好的方法；
2.书写和语言表达很重要，尤其是PPT，文档的格式，而这一点是自己以前最瞧不起的！
3.老板永远不可能给你足够的资源和时间，而员工的责任就是在极其有限的资源和时间下实现老板布置的任务和目标，因此抱怨永远无济于事！
4.责任感相当重要，有了责任感，什么压力，困难都可以迎刃而解！
5.遇到困难和压力，需要勇敢地面对，不找借口！这一点也是自己最欠缺的，自己总是在困难和压力面前，选择逃避，选择得过且过，选择浑水摸鱼！但是出来混迟早要还的！逃得了一时，逃不了一世！如果选择面对，会耗费自己大量的精力，但会感到充实和自信；如果选择逃避，虽然偷得一时清闲，但会感到虚妄与忐忑！
《走出软件作坊》读后感(四)：《走出软件作坊》读后感
《走出软件作坊》读后感
第一次知道这本书，是曹政写的一篇叫《走不出软件作坊》的博文[1]。我记得那篇博文的最后caoz说阿朱对互联网领域的理解不如黄一孟。想想黄一孟的团队才十来个人、七八杆枪，想必这个阿朱水平也不会高到哪里去。我找来一份PDF版粗粗看了一下，不但找不出来caoz的槽点的落脚处，而且连作者立论的依据和场景也想不出。那时候，只懂得什么是“代码”不懂得什么是“软件”的我，遑论“软件作坊”和“走出软件作坊”。就这样，这本书一直躺在我的硬盘里，从来没有认真的读过。
后来公司临时决定交一个项目让我带的时候，终于体会到了麻烦扑面而来的感觉：丝丝相扣的问题让你无法下手，一个一个貌似死结的东西需要解开，甚至没有时间去想里面的前因后果。赤手空拳的我这时候想找一些项目管理的书来作为“武功秘籍”来修炼一下：先是到豆瓣上看看哪本评价最高，然后到书店去找书来试读一下，但是到最后也没能找到一本“葵花宝典”。一部部的经典著作好像都在告诉我一个事实，项目管理是“道不可言”。在放假回家的火车上百无聊赖找出来这“钦定”读本，细细读了一些章节之后发现共鸣不少，实在是一本很接地气的书。
点子大王
书里面的场景在现在看来都有些似曾相识，好像是犯过这样的错，吃过这样的亏，但是为什么却没有阿朱这样的一个个的“点子”。比如项目经理的棘手问题怎么处理？维护人员的棘手问题怎么处理？怎样让测试人员不敷衍了事？嗯，好像看起来阿朱比别人要聪明一些。
软件质量是所有公司的首要问题，所有的实施困难、使用效果差、支持费用高，都与此相干。 阿朱所述： 先找一个“懒”程序员做客户支持，为了减少客户支持工作量，就要做好好做测试。为了好好做测试，就需要有恰当的测试策略。自然而然的引入BUG管理工具与问题处理流程。如此看来，阿朱的策略是代价最小的，既没有空降规范，又没有人员的流血冲突。:P 用“土方”治大病的范例。
象这样的例子书中很多，看起来作者象个“点子大王”，不过仔细研究一下里面的来龙去脉，发现阿朱这些东西并不是“灵机一动”而是具有相当的智慧，实际上是敏锐观察和不断思考的结果。
分析高手
知道有坑，却始终不知道坑在哪里，这是我的真实感受。针对行业软件项目实施时间长的问题：问题(实施周期长) -> 主要问题（客户需求、数据准备、报表定制） -> 具体分析（关键矛盾的解决）。这样就把整体的问题拆解了，如此下来好像都有了具体的策略。书中的“四套马车”就是CMMI的简化简化再简化，如果CMMI是“超跑”，“四套马车”就是“昌河”，从到达目的地这个目的来说，选择一个合适的交通工具更重要。
对于正规化，作者认为：只有专业分工合作，才能走上正规化。组织结构可以保证专业分工，过程管理可以保证合作，我们看到的是大树，阿朱看到的是森林。
实践出真知
与第一版的书相比，思考组织结构方面更多了一些，认识也更深刻了，这是作者自己的提升。在知乎，有人问了一个问题：“您觉得明源相比较其他本土ERP公司（用友、金蝶、神码等等），优势在哪里？”阿朱的回答：
“这里缺研发线带头人,需要把整个研发团队带向前进.一个300人的研发大军要走向何方，如何带领这么大的一支研发团队，应该给业界产生怎样的影响力和贡献？这就需要大格局大未来的研发带头人。一个纯软件公司，最核心的资产和竞争力就是它的研发线了，这是一个纯软件公司的命根，它的大部分收入和发展都取决于研发线，这个部门的重要性在公司不言而喻。能带领这么核心的、可以决定公司命运的部门，而且是靠我的力量去领导它前进，这是个人价值实现需求满足的一方面。另外也和我个人的研发优势合拍。我一直在行业软件公司工作，而且一直在研发口工作，而且一直在架构、研发、管理三方面精进，十多年来从未离开半步。”
《走出软件作坊》读后感(五)：全书精华都在一分钟先生——自我时间管理
7我有个我自己的每日任务列表。我每天要做什么事情，我都随时记录下来，然后一条条的做，一条条的消。我看着不断有任务变灰，就很开心。我清楚的知道我每天要做什么事。 让行动代表你
8我要求手下在每天下班前一个小时把今天的工作进展发过来。然后我一一审阅，给些建议。这样，他们明天该怎么做，该做什么，今天遇到的问题该怎么解决，在他们下班前就知道了。这样，他们明天一来了就立即动手，根本不耽误时间，所以工作效率很好。
9有的员工跟我絮絮叨叨讲了很多，反映他所遇到的问题。我听完后往往第一个校验的就是，你到底要达到什么目的。很多员工被反问后，是啊，我到底要达到什么目的。最后一重新审视自己的问题，很快就把问题简化了，问题的症结就找到了，当然解决也就很快了。甚至，弄清楚了目的，发现问题根本不是问题，根本无须解决。省了不少功夫。
10我不喜欢员工像讲故事一样来龙去脉的报告。我总是强调，要1、2、3，这样来。而且你一次报告，不要报告太多的问题，人不应该关注那么多问题。关注多了，就根本理不清，所以也就解决不了问题。先要把自己的头脑清醒了，就焦点关注在前三个问题。等前三个问题解决了，再思考以后的。有些员工向我报告问题，总是拔起萝卜带出泥，一个问题的描述往往会引入另外的问题，然后问题串问题，跟糖葫芦一样。我总是让他打住，就说那是另外一个问题，咱们现在先别管它，咱们先把你现在说的这个问题说清楚解决完，再处理另外一个问题。
13我希望记笔记，不管看书，还是做事，想到一个很好的点就立即记下来。而且我还经常回顾自己的这些记录，把它们尽量整理成体系和方法，让彼此关联起来。所以我解决问题思考问题的时候，总是有很多参考。而不是从头想起，也不是一遇到什么事情还得重复寻找资料。我这个人由于太专，所以关注的东西也不多。就看自己关注的东西，所以范围窄。许多人没有重点，什么热就看什么，而且积累了一大堆资料，反而后来自己都不看。而我，由于关注的少，所以看的东西自然比别人范围小，看的少也就看的精，而且还定期整理自己的笔记和资料，发现过时了就删除掉，保留下自己持续关注的资料。我发现，不少人有移动硬盘，里面放了很多资料，但真要做事反而一点资料都找不到，跟没有资料一样。
14我喜欢看书和思考问题。过去坐地铁上下班，我都拿本书拿支笔，随时读书和记笔记。一天不读书不总结就觉得空空的，即使上个厕所也要带本书。很多工作中的管理方法很问题解决思路都是这样想出来的，在工作时间就赶快去，节省了不少工作时间。有的人记忆力还不好，还没有做笔记的习惯，还想问我有什么阅读理解的好方法？我的父亲常说：好记忆不如有个烂笔头。其实做笔记不仅仅是个做笔记这么简单的过程，而是在你写字的时候你就会思考揣摩思考，本来你认为很不错的一段文字准备记录下来，在记的过程中你就会想到自己的问题是否能有所借鉴，在记的过程中你就会联想其他同类的信息对比，总结出共性和差异点，在记的过程中你就会发现这段话说的比较片面不像你刚看的那么激动。很多人做不好自己时间管理，就是想做，但只是一个想法，真正做，就觉得这样做太累了，就放弃了。
其实，不管是谁的问题，只要是阻碍我的问题，我都要解决，千方百计去解决它。因为我知道，我受了影响，我如果连自己都不去救自己，就没有人救我自己了。
其他地方的补充
1大的公司中，你一定能够找出职位比你高，但你认为能力却不如你的人。但是你不应该钻这个牛角尖，因为这只会让你气馁。你应该做的是找到和你级别差不多的，但是你很佩服的人。你能从他们身上学到什么？你有什么他们不具备的优点？
2有些新员工会问我获得职业成功的秘诀。当我告诉他们答案是“努力工作”时，他们通常会很失望。这听起来像陈腐的说教，还像是自夸。如果我的答案是“我之所以能够爬到中层管理岗位是因为我很善于给上级拍马屁”，他们也许会更满意。我来微软的第一年就带了个睡袋到办公室，而且经常加班，周末的时候，我也是在写代码，学习新技术。我会看团队管理和如何与人沟通的书籍。才智相当的人在职业生涯上会有不同的发展，主要是因为他们的付出有多有少。如果有人另有说法，那他可能是想向你“兜售”点什么。
《走出软件作坊》读后感(六)：去做传统软件业，还是去做互联网
软件相关行业按其价值链，分为两种类型：
1、资源自上而下型，即资金和其他各类资源从上而下流动：（纳税人——》）政府、机关——》国企——》国企关联企业、外企——》国内IT外包商——》二手接包方——》雇员。 传统软件业（即各行业的企业级应用）就是这种类型。 注意，纳税人的首环在价值链中的作用是很有限的，所以我称之为自上而下。 这类行业的特点是：利益相关人最重要的考虑是满足上一级价值链的关键人物的需求，而不是产品本身的最大效用。IBM的一位销售经理就曾经描述过所谓“天龙八步”的销售流程，其中，决策者最优先考虑的是“安全”因素，即：不要弄砸，或者弄砸了也必须至少有垫背，有说辞。接下来就考虑的是自身利益最大化（不妨看看王强的圈子圈套），最后才是项目本身的效用。 不管是什么角色 ，都要服务于这个优先级顺序。 所以说到底这个行业是对人的服务业，如果抱着做艺术精品的预期来做这个行业，必然免不了要失望。 所以这个行业注重上层资源关系网培育；注重培训、认证、资质、跨国公司产品等提供的安全因素；注重能侍候好各类菩萨的人精（是高价值的人才）。 雇员的成长也是沿着这些因素的道路成长起来的。 由于上层资源是条块分割的，因此以此为生的软件企业也是条块分割的，这就是为什么我们这么大的国家，靠软件发财的老板很多， 但长大的高质量软件企业却很少。 既然长不大，作坊式生存的代价也可以忍受，所以传统软件业充斥着大量廉价劳力+command&control的低效管理风格。这实质上是行业的主流的生存方式。
2、资源自下而上型，即广大的消费者是企业的衣食父母，要是他们不满意就会用脚投票，抛弃企业转投竞争对手。互联网行业就是最好的范例。 没效率就会死掉的压力迫使企业自始至终都强烈关注产品的效用。企业会培养、争抢能够提高团队效率的人才。高效的敏捷精益等方法论和轻量级的技术受到追捧，而CMMi、SOA等方法论则被弃用，员工的效能产出的能力增长较快，容易成长为某一领域的专家。
说到这里可以得到结论：如果你要成为攫取上层资源的人精，可以到传统软件业来锻炼锻炼；如果你希望做出一个产品能让很多人受益，那么就去做互联网吧。 两者的共同点是：都不容易，都要付出持续的努力。
《走出软件作坊》读后感(七)：走出自己心中的作坊
看了前十页就感觉此书符合自己的口味，讲到的一些实例或多或少的遇到过！ 深有感触，也解决了自己的疑惑，改善了自己的观点。
就如此书序言所说的每个人都以为被人碗里的肉香 ，其实家家都有难念的经，沉下心下来，这个后面的
---------------
国内外的环境土壤不一致，整天30岁就over的论调，然后国内公司完全是施舍的态度，管理方面又是各有各的方法！老外的不能完全适应，反而会适得其反！
此书讲的我们会慢慢的体会到，所以要读此书，知道自己的职业路程中，遇到什么事，要怎么处理，以后的路如何规划！
------------------
CTO
《走出软件作坊》读后感(八)：书要慢慢读，路要慢慢走
我看书的习惯不是很好，很快，文字都是跳跃着进行，特别容易因第一印象来决定是否要继续读。
只有第一遍快读的时候很有感觉的书才会细细的再读。
读这本书的过程很有意思。
第一遍的时候感觉很一般，没体会出干货。并且觉得作者有点太“自夸”了吧，先抛个问题，然后就是“我xxxx的解决了这个问题”。
随便扔那了。
偶尔翻翻。
正好有段时间为公司的事情头痛上火呢，也是一作坊。这段时间再翻到这本书，感觉来了。
其实想想，作坊就是作坊，解决作坊问题的方法并不是让作坊升级成高级场所，而是调整自己的工作方法来适应这个作坊
不要总想着颠覆性的变革来试图体现自己的伟大，作坊存在那么久，是有他的理由的。
一切的变化，是要有益于后面的工作，就是革命了，无所谓大调整还是小调整。小调整操作性强，更容易推动。所以，即使酝酿了大调整，不妨也考虑一下是否采用“渐进式改革”之路。
看到这里不要晕。也许上面的话和书的内容都没有关系。
我就是写写自己对“走出软件作坊”这件事的感觉。
书的内容，等我读完了再评论。
《走出软件作坊》读后感(九)：请不要叫我“程序员”
周星驰有一句经典的台词：请不要叫我“跑龙套的”，我是一名演员。
看了这本书，我突然也有了感悟：请不要叫我“程序员”，我是一名软件工程师。
程序员只关心自己代码的一亩三分地，完成预期功能，如果级别高点，能考虑一下代码的质量和相关文档。在这种情况下，程序员一般被动的接收来自上级的分配的任务：按照分配任务的邮件，开发完代码。输入数据了，看看输出数据，不对？那就修改一下；得到预期效果了？嗯，任务完成了。至于这个代码是做什么的，用在什么产品里了，能带来多少利润？不管不关我的事情，反正我是完成任务，对得起我的工资了。有什么方案，可以让这个产品做的更好，和其他部门协作的过程中，我是否需要人家提供更好的资源吗？嗯，还是不关我的事，人家给啥我就做啥呗。
而软件工程师考虑的不是代码，因为真正给自己和公司创造价值的是产品。所以作为一名软件工程师，实际上承担了更多的责任，一个产品的成功，代码实现功能，只是其中一部分，还要考虑是否需求是否合理，UI是否友好，开发进度如何安排，开发过程中不同的人甚至不同的部门如何分工，才能保证保证产品开发高效进行。而完成这些工作，，往往纠结以往的惯性，部门和个人的利益关系。这些工作都不是一个程序员没有权力去安排这些工作按照自己的意愿进行，但却可能收到这些因素的掣肘，典型的程序员遇到这些问题大多要么“事不关己高高挂起”；要么“众人皆醉唯我独醒”，嗟叹自己怀才不遇。而一个真正为产品负责的软件工程师，最终的目标是为自己心中的那个产品而奋斗，想方设法解决一切这条路上的困难，无论是不是代码相关的。
归根到底，程序员和软件工程师的区别在于责任的范围大小。一个真正有前途的软件工程师，遇到问题，不要把时间浪费在争论是谁的责任，是谁的分内工作，而是要尽快想出解决方案。一切给我带来不便的问题，本质上都是我的问题，因为如果不解决，受到拖累的人就是自己，如果自己都不帮自己，谁还来帮自己？
所以一般程序员的形象就是胡子拉碴，不讲卫生，头发油油，穿着大裤衩大拖鞋，说话满口听不懂的词汇。
而软件工程师的形象应该是有衬衣西裤，工作报告有统计，有分析，有总结，不加班，不弹性工作，会开发会写总结会演讲。
写到这里，突然觉得，软件开发这个行业似乎和其他行业也没有什么本质区别，一个合格软件工程师，其所具备的子夜精神也会让其在陌生行业上也会很快进入正轨。各位伏案敲代码的同行们，就把当前的工作作为一项人生的修炼吧。
《走出软件作坊》读后感(十)：既解决了实际问题，又开阔了思路
之前朋友推荐这本书，看名字以为是类似成功学之类的，就一直搁置着。前两天无聊拿出来翻翻，就一发不可收拾。
这本书对软件开发全流程中遇到的一些棘手的问题给出了解决方法。同时对不同职位的人员的发展也给出了意见或说明了职责。
对于产品研发没有任何经验的人来说，本书提到的一些注意事项、产品研发过程、产品生命周期等，都做了简单的介绍，非常实用。
对于从业人员的一些观点，作者也提出了自己的见解，我觉得说得也很有道理，尤其指出了都要以为老板赚更多钱为目标。
总之，我是憋尿推荐这本书。