我觉得这本书的作者经验十分丰富,粗略的看完了所有章节,觉得里面的经验值得学习借鉴,特别是处理问题的方法,有些很巧妙,所以想针对每篇文章写个读书笔记,细细品味学习。
第一篇是开篇,作者提出了开发部门的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次。以后再有需求,就必须另签合同另收费,否则不予修改。
这些方法对控制客户随意变更需求有很好的控制,但是我觉得要对这些方法灵活使用,否则会导致客户不愿意提需求,最终导致产品质量差,影响公司的形象与发展。
星星之火可以燎原,红军能二万五千里长征,最终胜利,那么我们的一定能找出解决问题的方式,这样的态度才是走向成功需要的态度!