读《走出软件作坊》第一篇

     我觉得这本书的作者经验十分丰富，粗略的看完了所有章节，觉得里面的经验值得学习借鉴，特别是处理问题的方法，有些很巧妙，所以想针对每篇文章写个读书笔记，细细品味学习。

    第一篇是开篇，作者提出了开发部门的4架马车：业务架构，技术架构，测试兼技术支持，文案兼培训。有了这样的团队，再加上各种管理软件：项目管理软件，版本管理软件， BUG管理软件，自动测试软件。这些东西相互配合，会形成良性循环，做出更好的软件产品。4架马车的分工至关重要。

    一个软件最重要的3个方面在于：操作说明，培训机制，稳定性。三者中稳定性最为重要。为了保证稳定性，首先从开发抓起，从队伍中抽象出来公共代码开发员，负责开发抽象公共代码，需求的修改必须 经过他的思考，要求公共代码开发员具备以下素质：

  

   1.参与过几个主要项目的开发，实施，支持。这样他对客户的需求有综合的把握，如果没有这样的人选，由项目经理负责

   2.公共代码开发员的态度认真，代码严谨周详，公共代码性能，稳定性都比较高；

   3.技术能力高，封装函数方面有灵活性和可扩展性。

 

  软件稳定性提高之后，做好文案，培训，实施便很容易。软件开发形成良性循环。

 

  文中提到项目经理的职责

 

1 客户行业这个群体有多大？大中小规模各有多少家，各分布在什么省？我们面对的最佳客户是什么规模什么信息化程度的？我们的次佳客户是什么规模什么信息化程度的？
2 我们的上层竞争对手、本层的竞争对手、下层竞争对手目前的产品怎么样？他们各自的优点是什么？他们各自的缺点是什么？我们应该突出的优点是什么？我们的缺点是什么？
3 客户行业的过去5年，现在2年，未来3年的发展历史和趋势是什么？他们面临哪些挑战和机遇？
4 我们现在所做的典型客户，他们的组织结构，人员规模，每个岗位每日业务流程、每个岗位每日每周每月每季每年的异常处理业务流程，每个岗位每日每周每月季每年的输入表格，每个岗位每日每周每月季每年的常用数据查询，每个岗位每日每周每月季每年的统计报表
5 针对以上的了解，客户面对未来挑战和机遇，未来应该如何变更他们的岗位和职责和流程，尽量流程少，效率高，运转快？

    其实，开发经理就相当于业务架构师（因为我们还是游击队，不可能有专职的业务架构师），公共代码开发员就相当于技术架构师。

 

  仔细品读这5种职责，收获颇大，从职责中可以看出，作为项目经理的工作方法，应该具有的视野，应该在业务层面提出解决方案，并使自己的解决方案具有竞争力。如果想成为项目经理，这些能力都是需要锻炼的。

 

   柳传志的话:"搭班子，定战略，带队伍"，首先最重要的是“搭班子”，班子不行，什么都不行。十分有道理，细细体会。

 

   文章中说目前流行的重型方式，如UML，RUP,CMM，这些重型方法不是中小企业。这一点可以看出不一定流行的都是好的，而是适合自己的才是最好的，要探索适合自己的企业的管理方式，一上来就用这些方法，可能达不到预期的效果。

   另外文章还提到了一些企业的现状，员工与老板之间明争暗斗。在中国，无论是政府部门，大型国有企业，还是外企，私企，政治斗争无处不在，如何在政治斗争中保护好自己，这是需要我仔细研究品读的东西。不要再政治斗争中成为炮灰。

   文章中还提到对需求变更的控制方法：

1 客户业务部门不能随便提需求。必须集中汇总到客户IT部门，由客户IT部门汇总过滤完，再集中报给软件公司
2 客户IT部门的需求，必须客户方负责IT项目的老板签字才能生效，才能报给软件公司
3 不能随时报，每3个月集中报一次
4 不能口头报（即使在现场实施支持也不行），不能电话报，只能MAIL或传真来报
5 必须按我们规定的格式报，要严格写清楚需要实现的功能的界面，输入数据或输出数据，输入输出数据的格式要求，谁操作，多长时间操作一次。
6 软件上线后只能免费修改3次。以后再有需求，就必须另签合同另收费，否则不予修改。

 

这些方法对控制客户随意变更需求有很好的控制，但是我觉得要对这些方法灵活使用，否则会导致客户不愿意提需求，最终导致产品质量差，影响公司的形象与发展。

 

星星之火可以燎原，红军能二万五千里长征，最终胜利，那么我们的一定能找出解决问题的方式，这样的态度才是走向成功需要的态度！