系列书引言 关于开发团队培训体系的讨论 在北京CBD商务中心某上岛咖啡厅,靠窗户最里面的拐角处,一位年轻人坐在那里好像在等待着什么重要客人的到来,他就是当地小有名气的昂特拉软件公司的总经理徐杰,徐杰虽然年龄不大,但管理能力超强,他经营的软件公司在短短的几年内就在业界具有了较高的地位。但是,就是这样一个知名软件公司,目前在软件开发团队的管理方面遇到了难题,他不得不寻求外援来帮助提高他们开发团队的开发能力。他提前预约了软件工程专家晨落就如何提升软件开发团队方面进行咨询。 晨落将车停在车位后,快步走向上岛咖啡厅,隔着玻璃窗就看到了徐杰在靠窗户的沙发上坐着。然后挥挥手并且打招呼道: “下午好!”说着就走进了上岛咖啡厅。 “您好!”徐杰站起来招呼着晨落坐了下来。 “喝点什么?”徐杰问道。“上岛咖啡”,晨落随口说道,然后就坐了下来,打开了笔记本电脑。 “直接进入主题,你遇到什么问题了?”晨落直入主题地问道。 “在过去的几年里,我一直在关注着我们公司的市场,随着公司规模的扩大,我发现开发团队的开发能力已经无法适应市场变化了。”徐杰说道。 晨落认真地做着记录然后说道: “这是必然的。”并且问道: “具体体现在哪方面?” “工期延误,成本增加,质量无保障,员工斗志下降,不断地加班却没有效率,员工怨声载道,客户叫苦连天。”徐杰慢慢地说道。 “哈哈,这太正常啦,这是大部分软件企业老板和我讨论关于软件开发过程时的通用描述语。”晨落笑着说道,并且继续在笔记本电脑上记录着他们的谈话内容。然后问道: “你是学什么专业的?计算机专业吗?” 徐杰说道: “不是,我是学人力资源管理的,在企业管理经营方面自认为有一套,在前几年我的精力主要投入到市场拓展和财务管理方面,随着经营的公司规模的扩大,我发现软件开发部门已经成为公司发展的障碍了,想提高软件部门的综合水平,但是不知道如何提高软件团队的开发能力。” “你对软件开发有了解吗?”晨落问道。 “有些了解,就为了这个,我自修了软件工程专业的本科课程,但是,我目前知道的只有软件开发的一些知识,在如何提高软件开发能力方面没有任何思路,所以才请您这位专家帮我点化点化。”徐杰说道。 “那就好,如果有这方面的知识,我们之间沟通起来就没有什么大的障碍了。现在我绘制一幅软件开发过程框架图,再围绕这幅图逐步讨论如何培训软件开发团队,并且制定一套可行方案,好不好?我现在帮你理清公司目前的状况,找出目前存在的问题,然后根据计划来执行我们的培训计划,这样就能够做到有的放矢了。”晨落说道。 “好的!”徐杰说完后,也打开了笔记本电脑。 “我先为你绘制一个图,这是我总结出来的软件开发过程框架图,如图01所示。我个人认为开发团队至少由4个部分组成,生命周期是软件开发的核心部分,所有的一切都是围绕着软件生命周期展开的。”晨落说道。 图01软件开发过程框架图 “是的,但是我所知道的生命周期中里程碑应该是具体的,比如说需求开发、软件架构、数据架构等,我看到您的这个框架图中并没有具体说明里程碑的名称。”徐杰说道。 “你说得很好,因为它是一个通用模型,所以我无法在这个模型图中将所有的里程碑写出来,并且因为不同的生命周期中里程碑是不一样的,所以我只能用数字标识了。”晨落解释道。“首先你觉得对于这个模型图能否理解?” “不能,请你详细解释。”徐杰说道。 “一个软件开发过程应该至少由三个架构和一个生命周期组成(图01的中间部分),技术框架是软件开发过程的重要组成部分(图01右边),它所关注的是生命周期中生命周期实现的方法,我们经常所说的方法包括分析方法等。”晨落喝了口咖啡继续说道: “图01的左边是从软件工程管理的视角对生命周期中的每个里程碑进行评价的框架,它按照项目管理和评价体系对项目中的里程碑进行评价,以保证软件高质量地完成,技术框架和管理框架是相辅相成的,两者缺一不可。支撑平台是项目能够正常运作的基础,包括公司的人事管理制度、绩效考核制度等。因为项目经理或其他项目管理人员具有项目的考核权,但没有执行权,这样需要公司管理层面给予支持,所以支撑平台非常重要,支撑平台的关键人物就是公司的管理层,比如总经理徐杰。”晨落说完后看着徐杰笑了笑。 徐杰说道: “你这样解释我就懂了,我们公司目前的状况是每一个框架都做得很差,你这样一说我知道应该关注哪些框架了,但是对于如何关注、如何能够提高团队的开发能力就不知道了。” 晨落说道: “这个没关系,只要你积极配合,我会告诉你如何培训的。其实,将我们公司的所有项目进行培训是不现实的,我们可以考虑选择其中一个项目,针对这个项目进行培训和指导,采取案例式培训方法,这样才能够保证培训质量。” “我赞成,我打算先对投核保系统开发团队进行培训,计划从其他项目组抽调一些技术人员组成新的开发团队,然后由您对这些项目组成员进行现场培训,采取项目的里程碑方式进行培训,针对具体问题进行具体培训。我邀请您全程参与到我们的项目中来。”徐杰说道。 “这个没有问题,但是在培训之前我必须对公司软件团队的现状进行调研。你打算指定谁来担任投核保系统的项目经理?”晨落问道。 徐杰说道: “马莉,她是有多年项目经验的项目经理,组织能力很强,技术也很过硬。” “我们围绕着图01所示的模型针对不同框架逐一分析,了解一下目前的状况。”晨落说道。 徐杰说道: “现在就可以吗?但是马莉没有到现场呀。” 晨落说道: “通过QQ即可。” 说着,晨落通过QQ按照三个框架从马莉那里了解到项目的状况。 对于管理框架方面,马莉的反馈是目前只用到项目管理过程,对其他过程没有考虑过,主要是因为没有人力资源来负责这项工作,同时也不知道如何管理。 对于技术框架方面,马莉认为分析和设计方法应采取面向对象的分析和设计方法,软件架构建模语言使用UML语言,数据库设计使用PowerDesigner,开发语言使用Java语言,框架方面目前计划采取SSH(Struts+Spring+Hibernate)框架,对其他方面目前没有考虑到。 对于生命周期方面,采取传统的瀑布模型。 对于人力资源方面,目前有系统分析员一名,毕业四年; 架构师两名,毕业三年; 数据库架构师一名,毕业两年; 程序员多名。 晨落看了看马莉反馈的信息,想了想说道: “管理框架按道理来说非常重要,但是现在我们竟然没有在项目中应用,这个你觉得重要吗?” “是的,非常重要,说实话,这样会使我们的项目进度变得很慢,客户项目经常非常紧急,我知道写文档、搞评审会占用大部分时间。我尝试着做过,但是放弃了。”徐杰说道。 “你刚才不是说过吗,项目进度总是延期,说明项目延期不是因为应用管理框架导致的,其实管理框架的应用并不会影响我们的进度,只能让我们的工作效率更高。当然,在开始阶段可能从表面上看进度变慢了,但是,如果质量能够提高,后期的返工自然就少了,延期也就不会发生了。”晨落喝了口咖啡说道: “如果我们不对管理框架进行培训,对其他方面的培训只能是治标不治本。无论团队技术水平如何高,如果没有很好的管理配合,项目依然无法成功。你说呢?” 徐杰说道: “我知道,但是,说实话我真的不知道如何去做才好。” 晨落说道: “这刚好是个时机,因为投核保系统开发团队是你创建的新团队,这个团队所有的一切都从零开始,我们可以通过这个项目对开发人员进行不同层次的分角色培训,并且结合投核保系统具体案例来培训,我全程参与,按照确定的生命周期,项目执行到哪个步骤,我们针对具体情况进行具体培训。” 徐杰问道: “你的思路是什么?” 晨落想了想,然后在纸上勾画出培训体系图,如图02所示。 图02培训体系图 晨落解释道: “培训体系图是在软件开发模型的基础上结合项目的具体情况设计的,它包含了软件开发模型的三大框架。” “哪些框架?这些框架是如何体现的?”徐杰看着图问道。 “是这样的,我的思路是从业务调研开始到代码实现结束进行分阶段培训。无论软件生命周期如何定义,采取敏捷开发方法也罢,采取其他方法也罢,但是肯定不会少了业务调研、需求分析、软件架构、数据架构、软件实现、数据库实现这些流程,我们将这些流程称为里程碑,针对每个里程碑根据培训需求进行具体培训。这个不知道你能否理解?”晨落说道。 徐杰说道: “这个可以理解。我们对每个里程碑需要进行必要的评审,对于这些评审我们目前的团队没有足够的人力资源,但是,我觉得有必要把这个管理框架组建起来,然后结合项目状况具体培训,并且直接应用到项目中来。” 晨落说道: “很好,这也是我想到的,英雄所见略同!” “技术框架部分我从项目经理那里已经知道了大概的培训内容,那么对于管理框架方面您是如何计划的?”徐杰问道。 “在投核保系统中,我打算将需求管理、项目管理、质量保证、软件测试、配置管理这几个过程域执行到位,按照项目的不同里程碑分别对这几个过程域进行详细培训。”晨落说道。 徐杰说道: “我同意,那么培训内容是如何组织的呢?” 晨落说道: “这个需要给我一点时间,通过与项目经理沟通后再做详细计划,到时候我会将计划呈报给你的。” 徐杰说道: “那好的,谢谢您了,我会全力支持您的工作。” 编写本系列书的思路 在企业培训中,以软件生命周期为主线将技术框架和管理框架的培训融入项目中是一种行之有效的培训方法。朋友们多次建议我把我的培训思想和方法整理成书籍,但是,我心里明白写书并非易事,在忐忑中开始了写书的漫长历程。在初期阶段,我计划写一本关于UML方面的书,但是,我发现UML仅仅是一种描述语言,是软件系统分析与设计的表现形式,是软件技术人员灵魂的体现,单纯地写UML显得有点单簿,没有办法将软件分析与设计的思想、灵魂体现出来。于是有点像笨媳妇和面,水多了加面,面多了加水,然后水又多了,然后面又多了。我通过多次反复思考和论证,最终将本系列书的编写格调定了下来。 本系列书的编写格调是以投核保系统为唯一案例,按照软件工程的基本生命周期,分别按照软件需求开发、软件架构、数据架构、数据库设计实现和软件设计实现等几个阶段介绍,采取较为科学且适用的设计方法完成系统的分析、设计和实现,用UML、PowerDesigner、Struts 2.0、EJB 2.0和HJCA等工具和方法表现出来,较为全面地将软件开发流程展现给读者。 关于软件架构、软件设计实现、数据架构、软件过程管理和软件测试等的书籍可以说为数不少,根据本人观察,在这些书籍中不同的书籍讲了不同的案例,甚至同一本书中也有不同的案例,这就出现了一个现象,也就是读者无法将所有的技术点有效地结合起来,对技术点的理解依然处于零散状态,无法形成一个整体。所以,本系列书在案例应用方面只采用一个案例。本系列书共三本,由11篇组成,使用投核保系统作为唯一案例,然后从业务调研开始到代码实现结束,采取“逐步求解,步步为营”的方法完成案例实现。本系列书将业务调研报告作为开始篇,以编写编码报告作为结束。另外,在解读业务调研报告的基础上都是围绕着需求分析报告内容进行讲解的,实现需求分析报告相关内容的设计。软件架构部分是以投核保系统需求分析报告为依据,以投核保系统概要设计报告为结束。数据架构、数据实现、软件实现、软件开发过程以及软件测试管理都是采取同样的思路。 对于情景再现方面,本系列书将昂特拉软件公司的投核保系统开发过程作为唯一的情景演练案例,将软件生命周期中关键过程域的评审会情景再现给读者,通过对话方式讨论技术点的应用场景等。 本系列书的内容既不是对工具的独立讲解,也不是对独立软件工程的讲解,而是将两者有机地融合起来,采取的思路是技术点讲解、技术点应用场景分析、技术点实现方法,最后将技术点应用到唯一的案例中,全面地展现给读者。 本系列书的文字组织尽量避免采用学术性语言描述,而采用情景再现的方式,通过通俗语言介绍软件架构中的关键概念,将软件开发流程中的关键环节展现给读者,让读者融入到软件开发的整个流程体验中来。 对于案例的选择,在编写本系列书的过程中,有些朋友认为本系列书中的案例不具有广泛的代表性,特别是业务部分很少有读者接触过保险公司业务。但是,如果希望将软件开发的全部过程体现出来,能够覆盖软件开发的全部过程,必须选择一个有一定复杂度的案例,只有这样才能够将软件开发的整体流程全面地展现给读者。 本系列书的组成 本系列书的第一本《软件是这样“炼”成的——从软件需求分析到软件架构设计》出版后,读者的反映非常强烈,不少读者通过QQ或电子邮件的方式给我发来信息,对本系列书提出了宝贵的意见,大家一致认为本系列书应该包含软件开发的整个过程,应该尽量全面,经过再三分析,决定对本系列书做大幅度调整,将原计划本系列的两本书调整为三本书,这三本书分别为已经由清华大学出版社出版的《软件是这样“炼”成的——从软件需求分析到软件架构设计》《软件是这样“炼”成的——软件过程管理与软件测试》以及这本《软件是这样“炼”成的——软件架构设计实现》,将原来的全系列书八篇调整为十一篇。 《软件是这样“炼”成的——从软件需求分析到软件架构设计》包括“软件需求开发”“软件架构(上)”“数据架构”和“软件架构(下)”四篇。 《软件是这样“炼”成的——软件过程管理与软件测试》包括“软件过程改进”“软件开发过程管理”和“软件测试”三篇。 《软件是这样“炼”成的——软件架构设计实现》包括“开发之旅起航”“软件开发环境设计实现”“基于Oracle的数据架构设计实现”“基于Struts 2.0+EJB 3.0的软件架构设计实现”四篇。 本系列书的内容概要如下: 第一篇“软件需求开发”。编写本篇的目的是结合软件需求分析报告的基本元素要求分别介绍需求分析报告基本元素在UML中的表现方式,具体是解读业务调研报告,介绍如何采用面向对象的分析方法实现用例规划设计,使用UML完成用例规划。即解读业务调研报告,介绍数据字典编写方法,完成投核保系统数据字典的编写; 解读业务调研报告,介绍采取面向对象的方法如何分析用例,并且使用UML完成用例描述; 解读业务调研报告,分析面向对象的思想,分析用例及参与者关系,并且使用UML完成投核保系统参与者及用例关系描述; 解读业务调研报告,介绍领域图设计方法,使用UML绘制投核保系统领域类图; 解读业务调研报告,分析非功能需求。在本篇中并且解读需求分析报告国家标准,对需求分析报告国家标准进行裁剪,通过UML建模语言完成需求分析报告的编写,以需求分析报告作为本篇的结束。 第二篇“软件架构(上)”。编写本篇的目的是根据软件架构思想解读需求分析报告,全程演练软件架构流程。本篇结合软件架构基本元素,采用面向对象的分析和UML描述语言实现投核保系统软件架构。“软件架构全程演练”的主要内容包括解读需求分析报告,分析软件架构与UML时序图,以时间顺序为出发点,动态分析对象之间的关系,使用UML绘制投核保系统用例时序图。其中,解读需求分析报告,以动态视角采取面向对象的思想方法分析设计系统活动图,采取UML语言描述投核保系统活动图; 解读需求分析报告,分析投核保系统软件架构与状态图,使用UML语言绘制出投核保系统状态图; 解读需求分析报告,结合用户需求分析软件体系结构风格的应用场景,确定投核保系统体系结构风格设计,分析软件分层设计原则和方法,实现投核保系统分层设计,绘制投核保系统体系结构图。本篇介绍了常用软件架构设计模式,分析了软件架构设计在投核保系统中的应用,并依据设计模式和架构分层方法按照不同层次分别优化类间关系,使用UML描述语言绘制投核保系统实现类图。异常设计是软件架构非常重要的内容之一,解读需求分析报告,完成投核保系统的异常设计。本篇还介绍了包图、组件图、配置图,分析了包图、组件图和配置图的应用场景和设计方法,分别设计投核保系统包图、组件图和配置图,并且解读概要设计国家标准,结合投核保系统需求分析报告和设计方法完成对国家标准的剪裁,以投核保系统概要设计报告作为本篇的结束。 第三篇“数据架构”。本篇是基于数据库设计原理解读需求分析报告,完成数据库设计。本篇也是以需求分析报告作为起点,以投核保系统数据库设计报告作为结束。本篇内容包括介绍数据库实体关系模型概念,解读需求分析报告,使用实体关系基本原理,使用PowerDesigner完成投核保系统实体关系模型设计; 介绍数据库逻辑模型概念,解读需求分析报告,在逻辑设计模型原理的基础上使用PowerDesigner完成投核保系统的逻辑结构设计; 介绍数据表基本类型,解读需求分析报告,使用PowerDesigner完成投核保系统的数据表结构设计; 介绍视图、存储过程和触发器基本概念,分析报告数据需求,使用PowerDesigner完成投核保系统的视图、存储过程和触发器设计; 解读需求分析报告数据安全方面的需求,结合数据库安全设计思想和原理,实现投核保系统的安全设计; 解读数据库设计国家标准,结合投核保系统需求分析报告完成对国家标准的有效剪裁,以投核保系统数据库设计报告作为本篇的结束。 第四篇“软件架构(下)”。本篇的主要任务是介绍使用开源框架及开发工具实现软件架构设计的全程演练过程。本篇解读两个设计文档,它们是投核保系统数据库设计报告和投核保系统概要设计报告。在本篇中,解读架构设计报告,完成界面元素设计; 解读状态图,以状态的视角优化类图以及完成详细设计; 解读活动图,以程序运行的视角设计程序运行流程,优化实现类求精详细设计; 解读时序图,优化实现类,细化详细设计; 解读需求分析报告和架构设计报告,分析数据结构在详细设计报告中的应用,并结合数据结构分析程序算法在详细设计报告中的应用; 解读架构设计报告,选择投核保系统实现技术线路。解读配置图,完成投核保系统开发和测试的硬件环境; 解读组件图,完成投核保系统的软件开发环境; 解读包图,完成投核保系统工程文件的创建; 解读详细设计和数据库设计,分别完成数据库、表现层、业务逻辑层、控制层等的设计。本篇以投核保系统详细设计报告作为结束。 第五篇“软件过程改进”。本篇以昂特拉软件公司为案例,首先对昂特拉软件公司进行全面调查,在分析昂特拉软件公司管理现状和项目的基础上设计了昂特拉软件公司级别的过程模型,包括公司组织结构设计、公司奖励体系设计、软件过程总体方案设计,并且定义了软件项目管理过程域、项目总结过程域、立项管理过程域等13个过程域,其中包括对这些过程域的活动、规程、标准和模板的定义,并且制定了软件过程剪裁规程,为项目组实施公司级过程模型编制了指南性文件。 第六篇“软件开发过程管理”。本篇以投核保系统为案例,在昂特拉软件开发过程模型的基础上结合投核保系统情况按照公司软件过程的基本模型对软件过程进行剪裁,制订了投核保系统软件过程模型,并且全程记录投核保系统的软件过程管理过程。 第七篇“软件测试”。本篇以投核保系统为案例,结合软件测试方法学和软件测试过程管理全程记录了投核保系统软件测试过程,包括软件测试过程定义,软件测试方法学介绍,解读投核保系统不同阶段的文档,完成投核保系统测试需求分析、验收测试计划及用例文档、集成测试计划及用例文档、系统测试计划及用例文档、单元测试计划及用例文档,完成验收测试报告、集成测试报告、系统测试报告和单元测试报告文档等。 第八篇“开发之旅起航”。本篇通过6个主题以讨论的方式分析了软件编程过程中存在的问题和困惑,结合投核保系统提出了投核保系统设计项目的开发模式,为本书的后续编写提供了编写思路。 第九篇“软件开发环境设计实现”。本篇以投核保系统配置设计文档为例,分别介绍软件运行框架的实施、基于Oracle Database和Oracle WebLogic的设计实现等。 第十篇“基于Oracle的数据架构设计实现”。本篇的主要任务是完成“数据架构”中关于数据库设计的实现,本篇以投核保系统数据库设计报告为起点,以数据库编程实现为终点。本篇介绍几种常用的数据库的实现差异和应用场景,解读数据库设计报告,全面实现数据库设计,并且使用Oracle数据库管理系统实现数据库、数据表空间、数据表、视图、存储过程、触发器以及数据库安全等。 第十一篇“基本Struts 2.0+EJB 3.0的软件架构设计实现”。本篇以投核保系统架构设计文档为案例,结合EJB 3.0和Struts 2.0技术,详细讲解Struts 2.0和EJB 3.0,按照投核保系统详细设计报告,最终完成投核保系统的编码和实施。 编者2016年5月于北京 第一篇开发之旅起航 第1章程序员辞职报告讨论 政企分不清必然导致官商勾结,官商勾结自然就会形成工程项目具有一定的政治色彩。有时候,政治风云变幻会导致企业变得人心动荡。与昂特拉软件公司签署投核保系统的天意保险公司尽管是一家民营企业,但是,保险公司必然要接受政府机构的管理,政府机构谈的就是政治,那么企业也必须关注政治了。 前一段时间,管理保险公司的某个政府官员因为经济问题被调查了,据说民营保险公司为了获取一定的市场份额不得不向此官员行贿。保险公司总经理因为行贿自然也被牵连进去了,已经在某个地方受控制了。新调来一位姓张的保险公司总经理,该经理名叫张强(化名),他是由政府指定的,据说张总经理曾经任职于国家某部主管旅游业。张强上任的第一件事就是对保险公司的人员进行大调整,信息中心原主任自然被“拿”下去了,新上任的信息中心主任据说是在政府机构有人,原信息中心主任据说要离开天意保险公司了,具体去向不太清楚。 对于昂特拉软件公司来说,这次天意保险公司的人事变动只能用“晴天霹雳”来形容了,尽管项目不至于停止,但与客户沟通存在问题。另外,昂特拉软件公司的软件过程改进也遇到了不少麻烦,来自架构师、程序员、市场经理、测试经理和质量部门的各种不良情绪以及对公司软件开发的焦虑使得总经理徐杰束手无策。今天在BCD商务中心的某个上岛咖啡厅徐杰与晨落就软件过程改进再次深度讨论。 今天徐杰总经理情绪有点低落,主要是最近的各类繁杂事情让他剪不断、理还乱。晨落坐下来后徐杰总经理说道: “最近遇到麻烦事了。” 晨落吃惊地问道: “徐总,你也会不开心啊?看来确实遇到困难了,我们可否共同分析一下呢?” 徐杰说道: “最近遇到麻烦了,投核保系统项目遇到麻烦了,我们客户的信息中心主任最近要辞职了,据说和原来的保险公司总经理是一批人马,现在新的总经理上任后将原来各部门的主管全部给替换了。” 晨落说道: “这与我们的投核保系统项目有什么关系呢?” 徐杰说道: “当然有关系了,因为现在刚刚上任的信息中心主任张强是新任总经理的嫡系,这个倒没有关系,但是,在我们签署投核保系统合同时遭受到张强的百般刁难,他极力推荐某个软件开发公司,我这里就不说具体名称了,这个软件公司经理刚好是现在新信息中心主任张强的同学。” 晨落说道: “嗯,现在合同签署了,难道他能终止合同不成?” 徐杰说道: “这个倒不会,但是在合同执行过程中不像原来那样好说话了,特别是项目进度问题,投核保系统项目从目前的进度来看没有办法按合同规定的时间完成任务了。” 晨落说道: “那你现在过虑的是如果不按照合同执行会导致张强按照合同的约定处罚违约金吗?” “是的”,徐杰低了低头说道。 晨落继续说道: “按照一般规律,张强也不能太过激,因为他毕竟要照顾信息中心其他成员的感受。” 徐杰接着说道: “问题是在签署投核保系统时张强极力把这个项目推荐给他同学的公司,在市场活动中,我们当时也没有照顾张强这个角色,在市场公关过程中没有给予什么搭点,估计他现在还心怀不满。” 晨落分析道: “一般情况下,一个管理者会有这么几种心态管理自己的团队,第一种是确实想把事情干好,也不考虑个人利益; 第二种是想把事情干好的同时考虑个人利益; 第三种是只考虑个人利益,不考虑事情做好的问题; 第四种人很少见,那就是既不考虑个人利益也不考虑事情做好的问题。根据你的了解,张强属于哪种类型的人?” 徐杰说道: “我不太明白您说的意思。” 晨落说道: “我是这样认为的,可以根据不同种类的人决定我们拓展市场的方法。对于第一种人,与他沟通起来是最理想的状态,他会更加关注项目的质量问题而不是进度问题,他也不会刁难客户的; 第二种人其实好说,那就是均衡利益了; 第三种人只考虑个人利益,我觉得从开发市场的角度来说其实并不难,给他足够的利益就行,反正羊毛出在羊身上,在质量上打个折扣也就行了; 第四种人估计不存在,他毕竟是需要做点什么事情的。” 徐杰说道: “在我看来,他有点像第三种人。” 晨落说道: “那你搞了这么多年市场了,凭你的经验你应该知道怎么处理这件事情了。投核保系统项目的进度尽管按照合同约定要延期了,但是,我觉得这是在我们计划之中和可控制中的,张强上任以后,我们需要加强与张强的沟通,争取获得他的支持。” 徐杰继续说道: “我所担心的是我们前面花了这么多的财力和物力,好不容易抢来的市场份额就这样白白地丢掉了。” 晨落安慰道: “我不这么认为,通过投核保系统项目,我们也锻炼了我们的团队。另外,如果我们的产品质量过关且功能能够完全满足用户的需求,我们就为后续其他保险公司的市场拓展提供了案例。还有,尽管张强这个信息中心主任不是干实事的人,但是他的员工总有一部分人想把事业搞好,我们的产品的使用者是保险公司所有员工而不是张强本人,所以,你不能这样悲观。” 徐杰说道: “那目前我们需要解决的是进度问题,也就是需要和张强协调延迟项目进度了。” 晨落问道: “中心主任现在办理离职手续了吗?张强上任了没有?” 徐杰说道: “刚刚任命,原中心主任还没有离职。” 晨落说道: “有个办法可以解决,在主任的离职手续没有办完之前,你可以考虑写一份项目延期申请报告,在主任离职之前让他签字和盖章,之后张强上任也没有什么可说的了,然后我们加强对张强的公关。” 徐杰说道: “好的,投核保系统的相关事宜就讨论到这里。另外一些事情是软件过程改进中遇到的问题,我这段时间陆续收到各部门写的电子邮件,表达了软件过程改进中的一些自己的看法,我今天选了几份具有代表性的邮件请你看看,然后我们共同分析一下,怎么样?” 晨落说道: “这个应该没有什么问题,有员工反映问题是件好事,说明大家开始执行并且关注软件过程改进了。我们可以共同讨论问题所在并且寻找解决问题的办法。” 徐杰挑选了几份具有代表性的辞职报告发给晨落,张杰的辞职报告全文如下: 尊敬的徐总: 您好!我是研发部程序员张杰,今天很遗憾向您提出辞职申请,对于我的辞职实属无奈之举。下面是我的辞职报告内容: 我是毕业就过来公司,三年的编程经历,虽然使我在各方面都提高了不少,然而离我实际的目标还是有很大的差距,这个跟公司和我自己都有关系,我觉得在公司里短期内不能让自己满意。从目前的情况来看,在公司再待下去也不会有太大的改观。 第一点,自我感觉职业生涯发展遇到瓶颈。三年前我是个程序员,现在仍是程序员,虽然希望自己向技术管理方面发展,但是没有这样的机会。从目前情况来看,在公司继续发展也看不到下一步该如何走,可能仍是一个程序员。 第二点,我在技术上没有太大的提高。三年来我做了不少产品,但技术提高没有如自己所愿。三年前我独立做出了软件,现在仍在吃老本,只是稍微熟练而己。三年来我也在不断地学习,为公司的需要和自身的发展做着准备。从公司目前的产品发展方向来看,我下一步能在技术上有大的突破的机会也不多。 第三点,薪资待遇未能如我所愿。三年来我的薪资虽然上涨了一些,到现在也只是跟市场持平,但持平不是我想要的,薪资到了这个阶段应该有一个大的提高了,我更希望有一个质变,在公司再发展下去也不一定能涨多少。从公司现在的发展来看,现在需要的可能是经验和薪资要求都适中的程序员。 总之,辞职有多方面的原因,最主要的还是我自己的原因,现在我申请辞职,希望领导能够批准,我将尽最大努力做好交接工作。 辞职申请人: 张杰 “还有吗?”晨落问道。 徐杰答道: “有,这是柳枝的辞职报告。” 徐总: 您好!我刚来到这个新环境,开始感觉还不错,真是想好好干下去。事实上也是如此,我很久没在一个公司干过这么长时间。我原来有很多项目,本想拉到公司来做,但是公司的很多事情和你的行为让我感到失望。我以为,跟随一个英明果断、有人格魅力的领导打工,我才有发展和前(钱)途。 在私企干了这么久,我非常了解老板的辛苦,老板也很难,所以我有利益上的不满很少说,当我无法忍受的时候就辞职。但我觉得有些事情不得不说给你听: 1. 作为老总,有些琐碎之事,你不该过问。老总就应该做一些比较大、有水平的事情,整天盯着下边的员工毕竟让人不舒服。例如,哪台计算机给谁使用,怎么又迟到早退啦,关于报销之类的事,等等。小事虽小,却使老总的形象毁于一旦。我从没有见过老总亲力亲为计算每个员工的年薪,并亲自发到每个员工的手中。——这也太平易近人了吧? 2. 纠偏过正。办公开支是应该节省,网是不能无限制地上,车是不能随便地打,话费是不能随便地报,出差费用是不能太高,但是也不要太低,否则员工会怨声载道的。 3. 要讲公平。迟到扣钱,那么加班呢?工作要讲效率,而不能光看工作时间,能不能完成工作要看自觉性,何必非要上下班打卡呢?准时上班我却打瞌睡,有何用呢?比如你自己,迟到多少回了,能说你上班没努力吗?你给我上保险,我很高兴,但这件事情你干得没水平。为什么每个人的待遇不一样,有的人上,有的人却没有?这对别人是不公平的,你怎么能够留住人心呢?这种小把戏完全是个人行为,而不是公司行为。 4. 说话要算数。我来的时候,张磊明确说过: 今年年薪按照一年算。但张磊走了,也无据 可循,你记得不记得我就更不知道了。我来公司已经卖了力气,交给我的工作我都完成了,而且×××的项目我已给公司赚回了我的年薪,而且今年会有更多的项目。公司网络和布线方面没什么利润,这和我没有任何关系,居然年终没有双薪和奖励,而且扣钱,这使我决定走人。 5. 总经理用个人行为来管理公司,认为公司是总经理的,管理公司可以说是随心所欲,将公司管理得一塌糊涂,全凭一个人说了算,狭隘的私有财产心理在作怪,这是典型的小农经济思维方式。 6. 我比较喜欢自由的工作,没有束缚,喜欢有施展自己能力的空间,公司不适合我。我与西北人的工作方法和思考问题的方式基本无法沟通。每次去客户那里做项目,都要求我们喝酒、请三陪、揣钱,这些事完全违心而做,甚至有时候以“用户至上”的名义接受用户的刁难,尊严何在?这样的工作环境令我无法忍受、忍无可忍,因此我在公司无用武之地。 九个月来,我像个打杂的,今天调试产品,明天与客户沟通,或对用户说一些不着边际的谎话,做了很多没有意义和受累不讨好的工作,也没学着什么东西,浪费了不少时间,却没有完成工作的满足感和成就感。 我所做的工作与我来公司预期想象的完全不一样,我想你至今也不知道我擅长什么,我喜欢什么工作、我厌恶什么工作吧! 7. 公司像个小作坊,当一天和尚撞一天钟,没有安全感,大家在一起有混的感觉。无论公司以前怎么辉煌,至少现在公司缺少生气,而且我们拿项目靠的不是技术实力。换句话说,公司舍得在搞关系上挥金如土,在技术上却一毛不拔,一年了,没有任何技术资金投入。这也许就是作技术的与商人的区别。 8. 公司问题太多,不写了,你也不一定爱看。 9. 总之,我之所以在公司提出辞职,是因为公司给我的发展空间有限,而且我表现出的能力,老板不懂得欣赏。我多年跳槽的准则是: 既然老板不给自己发展机会,自己也不会给老板机会——辞职走人。 10. 我觉得公司发展的好好的,开发人员也习惯了目前的工作方式,突然冒出个晨落先生在我们公司搞软件过程改进,比我们管理水平强的软件公司都不愿意搞这些工作,就凭公司目前的管理水平,我对软件过程改进没有足够的信心。另外,自从新的开发规范推广开始,我们整天纠缠在那无聊且毫无用处的文档编写当中,在我看来那就是废纸一堆。当然,我知道公司在这方面已经投入不少资金了,刹车也很难了。 10万年薪,你也许能够找到比我好的职员,但你千万不要以为仅仅靠这10万年薪就可以留住一个技术人员的心。本来现在就是一个双向选择、互炒鱿鱼的时代,少了谁公司都照样运转。我对公司实心实意,公司也要对得起我哦。 我辞职对公司不会有任何影响,高手有的是,祝愿公司兴旺发达! 辞职申请人: 柳枝 “还有吗?我说的是程序员的辞职申请”,晨落问道。 徐杰说道: “这份,你看看,是黄杰的”。 徐总: 您好! 我决定辞职了,有个人原因也有公司原因,个人原因我不便告诉大家,公司原因我说以下几个理由: 1. 自从公司制定了针对程序员的新的绩效考核制度后,我有极其不安全感,这么多的条条框框对我们来说有过多的约束,特别是将工资分为绩效工资和基本工资两部分,绩效工资我个人感觉拿全的可能性不大,因为很少有人愿意也很难按照公司的制度来做了。 2. 成就感越来越差。作为程序员来说,核心任务就是每天能够接触新的技术,能够尽量多地解决技术问题,能够编写出好的程序代码,这也是我的职责所在。 3. 有那么多的文档需要我们来编写,写文档对我们来说是太痛苦的事情了,我们只要在程序中添加足够的注释行就行了,还编写报告什么的,我想做程序员,我不想做文案人员。 4. 最近我阅读了公司的设计文档,我可以这样告诉您,没有几个程序员觉得写的有多好,因为这样程序员变成了“码工”似的,这样或许对公司来说管理方便,效率提高了,但你知道作为程序员如果没有新的技术,反复的工作大家会觉得很少有成就感。 5. 告诉你一个大家都不想告诉你的现象,程序员也有过虑,如果严格按照公司规定的程序规程来做,那么程序员和公司之间的制约砝码是什么呢?从设计到编码都做到如此规范,对程序员的要求降低了,如果公司克扣给我们降薪,那么我们拿什么来制约公司呢? 6. 再说了,就凭我们公司的开发人员的素质,软件过程改进在我看来是很难推行下去的,因为我们公司的员工素质和管理水平都无法达到。 所以,我决定辞职了。 辞职申请人: 黄杰 晨落看了张杰、柳枝和黄杰三人的辞职报告,沉默了许久,然后问徐杰: “徐总,我看了这三份辞职报告,我觉得一点都不意外。这三位员工你都批准他们离职了吗?” “柳枝我让他离职了,其他两位我还是想把他们留下来。”徐杰说道。 晨落说道: “你们公司的员工都是比较有个性的,说话一点也不客气呀!哈哈!” 徐杰说道: “哦,我觉得柳枝这样的员工,敢于直言也是好的,虽然有些话说得很没有礼貌也不客气,但是也可能反映了我们公司存在的真实问题。” 晨落说道: “是的,我也是这样认为的。” 晨落说道: “公司管理存在问题我觉得这是不可避免的,但是,我们的程序员的心态也是个问题。首先,这些程序员轻易言败、没有自信,是没有永不放弃精神的程序员,是有程序员名号的假程序员。一个真正的程序员,知道在程序设计的过程中可能会遇到不计其数的困难和问题,可能有极多的挫折和失败,而成功只有一次。就为解决一个问题,我们可能连续十几甚至几十小时坐在计算机前不停地工作。一个问题解决了,可能又有其他的问题出现。如果你不能坚持下来,从前的一切努力可能都白费了。执着是最可贵的,执着的程序员都是相信自己的人,每时每刻都会鼓励自己,这样才能坚持下去。” 晨落继续说道: “第二,浮华不实,自满自大。夸夸其谈的人不是优秀的程序员。整个程序设计的过程就是一个研究学习,应用,再研究学习,再应用的过程。一名优秀的程序员绝不会认为自己足够好了,不需要再提高了。自满自足的人不会是好程序员,会很快落后以至于落伍。所以越是优秀的程序员越是感觉自己懂得少,不会在人前故意卖弄。浮华的程序员会不懂装懂,不停地强调语言的优劣、平台的好坏,追求所谓的最新、最时尚的技术,停留在表面问题上,或故作深沉,用不适合的方式做不适合的事情。就像孔乙己一样,以为知道“茴”字有四种写法就是学问。最后是简单的做不好,难的也做不好。 第三,死气沉沉,不求甚解。优秀的程序员是充满激情和活力的程序员。求知欲和创造欲是原动力,有求知欲才能不停地学习,有创造欲才能不停地超越自己。死气沉沉的程序员已经对程序设计失去了兴趣,很快就会主动或被迫离开。创造不是指你要发明什么别人不知道的技术或方法,而是说不能仅仅知道怎么做,还要知道为什么这样做。之后你才能创造,其实程序设计的整个过程就是创造的过程。 第四,强调客观,忽略自身,很多程序员都是在失败的时候强调客观因素,而优秀的程序员都是先反省自己。大家要明白自己的缺陷,再努力去学习。没有人事事都做的成功,也没有人生来就什么都会做。所以失败了,多想想自身的原因,这样你才会不停地进步,而不是留在原地抱怨。” 徐杰说道: “你说得很到位,我们现在可以通过程序员辞职报告分析一下软件过程改进中存在哪些不足,因为到下一个阶段就是程序员这个主力队伍上阵的时候了,我们该如何做才能够保证实现过程改进目标?” 晨落说道: “在辞职报告中既反映了公司管理问题也反映了技术问题,同时也有个人问题。今天如果全部都讨论,内容太多,我觉得应该先讨论一下过程改进问题,你觉得怎么样?” 徐杰说道: “可以吧,我们先将这些辞职报告中关于软件过程改进方面的问题点整理出来,然后逐步分析。” 晨落分析道: “从技术角度分析,包含了个人发展瓶颈,觉得自己需要新的出路,个人发展瓶颈的打破有些是需要企业提供机会让他提高,得到发展,有些是企业也无法提供的,所以对于这类我们也只能是爱莫能助了。比如说张杰提出自我发展的瓶颈问题,我个人觉得我在他没有离职之前找他谈谈,看他说的瓶颈具体是什么,公司尽量提供机会,因为张杰总体来说技术比较扎实,也很认真。他毕竟是在我们公司工作三年的员工了,我们争取留下,如果薪资水平确实很低,那就考虑提高一下。” 徐杰说道: “这个我赞同。” 晨落继续分析道: “张杰认为技术上没有太大的提高,这是程序员工作几年之后都会有的正常心态。我觉得工资问题能够帮他解决,给他一个合理的工资报酬就可以了。但是对于技术问题,我要继续和他沟通一下,分析他感兴趣的技术与公司目前应用的技术是否吻合,如果吻合,让他制定个人成长计划,公司尽量给他提供发展空间,对于工作认真、踏实的员工我们需要鼓励他、帮助他。” 晨落继续说道: “在这三份辞职报告中,柳枝提出的问题最尖锐、最直接、最苛刻,说话也最不客气。记得在《投核保系统需求分析报告评审会》中我就已经领教了这小子,说话很尖锐,也不客气,有点自大和自我。” 徐杰接着说道: “是的,柳枝是我的一个重要客户的表弟,是我的客户推荐过来的,开发部门的不少同事在我面前说过对柳枝的不满意,但是碍于客户关系,一直没有辞掉他,今天刚好是他主动提出来辞职,那我就成全他好了。” 晨落说道: “但是,柳枝所提到的问题,特别是软件开发管理方面的问题我们必须要重视。对于他提出的第1点、第2点、第3点、第4点、第6点、第8点、第10点,我个人觉得有些公司管理可能存在这些问题,其他方面纯粹是从个人利益出发,纯粹是价值观存在问题了,不予理睬。 他在辞职报告第7点中提到,公司像个小作坊,等等说法,我觉得他目前还没有站在公司的角度思考问题,他目前还对中国的市场环境和政治生态不太了解,所以,他有他自己的想法,我们无须强求地接受我们的观点。 对于过程改进方面,柳枝的观点其实是自相矛盾的,比如说,在第7点中提到公司像个小作坊,而在第10点中却说觉得软件过程改进没有必要,认为大家都是消极对待软件过程改进的。根据我的观察,虽然大家对软件过程改进有部分内容不理解,但对大部分内容还是持有支持态度的。” 徐杰说道: “柳枝提出的有些观点我赞成,但有些观点纯粹是发泄情绪,是个人看法,不能代表我们做得不好,不予理睬。” 晨落说道: “对于软件过程改进方面,黄杰提出的观点与柳枝提出的某些方面有相似之处。黄杰谈到的第5点可以说是某些程序员的真实想法,这就说明一个问题——公司与员工之间存在着信任危机,也就使程序员感觉极其不安全。其实,根据公司目前的管理水平和薪资水平,不至于员工防备公司到那个程度。但是,无论如何,对员工的细化管理是必不可少的。” 徐杰说道: “过程改进活动发展到今天,我觉得和几年前的那次过程改进情况一模一样,大家都已经开始沉不住气了,开始怨声载道、抱怨连篇,抵触情绪越发严重。还好,我已经有了上次的过程改进经验,已经做好了心理准备。” 晨落说道: “所以,我觉得您不要气馁,我们目前的工作确实存在一些问题,但是总体来看还是向良性发展的。我对软件过程改进中团队的情绪变化做了总结,大概分为启动期、兴奋期、疲劳期、抵触期、抗议期、服从期、习惯期。” 徐杰问道: “那每个周期的表现是什么?” 晨落递给徐杰一份名为《软件过程改进过程中团队情绪变化与效率分析》的文章,全文如下: 软件过程改进过程中团队情绪变化与效率分析 软件过程改进从本质上来说是借助某些方法和管理工具来改变一个团队的工作方法和工作习惯,改变一个人的工作习惯已经是很难的问题了,更何况是改变一个团队的工作方法和工作习惯呢,那无疑是难上加难了。 软件过程改进对开发团队和过程改进推动者是有较高的要求的,因为团队组成成员各有差异、参差不齐,所以对管理者的综合水平要求是相当高的。但是,我若能够把握团队的情绪变化规律,根据不同的情绪变动采取不同的管理方式,就可以完成过程改进任务。我把情绪变化周期分为启动期、兴奋期、疲劳期、抵触期、抗议期、服从期、习惯期,图11描述了软件过程改进中团队情绪变化与工作效率之间的关系。 图11软件过程改进中团队情绪变化与工作效率的关系图 (1) 启动期。所谓启动期就是开发团队管理者或者是团队成员已经意识到软件开发过程中遇到各种困难和瓶颈,并且具有强烈的过程改进意识,咨询专业机构或专家请求改进建议等。在这个阶段大家的情绪处于平静状态,过程改进处于启动期。本阶段为初始阶段,保持着原始的工作效率状态。 (2) 兴奋期。软件过程改进活动启动后,过程改进组织将开展一系列活动来动员开发团队参与到过程改进中来,比如说开激动人心的动员大会,组织者会把软件过程改进活动对个人影响、项目成本、产品质量等多方面好处告知团队成员,这时候团队成员对过程改进结果将有较高的期望。在这个阶段,过程改进组织也组织一系列培训活动,团队成员会明显地感到自己有收获,看到的都是“新鲜”的内容,感觉到自己在进步,团队成员的工作积极性自然高涨,工作效率当然也就有所提高了。 (3) 疲劳期。也就说当我们的软件开发过程确定并且制定了一些过程规范、文档和模板后,要求开发团队成员都按照既定的规范执行,因为有许多规程是需要反复执行的,感觉有些疲劳。另外,每个人对挫折感的承受能力有限,反反复复地修改各种成果物,没完没了地开评审会,这时候团队成员对过程改进的热情度也过去了,大家开始慢慢变疲沓了,于是就出现了疲劳期,这个阶段的工作效率有所下降。 (4) 抵触期。软件过程改进其实是在改变一个团队以及每个人的工作习惯,改变工作习惯是最为痛苦的事。特别是在中国的软件教育中,上大学之前学生认为学计算机就是学编程的,而大学老师将学计算机教成了学代码和语法。大家在潜意识里就没有“工作”这一概念,基本上就是以作坊方式编程,并且通过这些方式取得一定的成果,所以让大家改变这个工作习惯是很难的。在没有进行软件开发过程改进之前,开发团队成员基本上很少受约束甚至是不受约束。过程改进的基本元素就是按规程办事,按要求做事,要组织评审等一系列活动。在这个阶段团队中的每个成员逐渐出现了抵触情绪,在过程执行过程中尽量能够减少工作过程就减少,尽量能够逃避检查和评审就逃避。在这个阶段,其实工作效率是最低的了。 (5) 抗议期。在抗议期开发团队成员的情绪最为低落,这个阶段开发团队出现问题越发频繁,开发团队成员的积极性受到巨大的打击,大家已经对软件过程的定义产生怀疑,认为软件过程定义是错误的,特别是对于那些急于看到成果物的开发人员来说,他们甚至怀疑文档的编写是否有用。如果客户进度要求比较急,特别是在过程改进初期实施阶段,拖延进度是非常正常的现象。在这个阶段有可能出现考核不合格导致工资减少了、奖金减少了等情况,有些员工就开始抗议,比如说柳枝的辞职报告中所讲到的内容就是典型的说法。这个阶段是过程改进“黎明前的黑暗”,如果决策层能够坚持自己的信念并对自己的决策持有坚决态度,那么就可能走向成功,否则会以失败告终,大部分软件企业的过程改进就是在这里没有坚决执行下去。在软件过程改进中最为重要的一个因素就是强制执行,奖惩分明,坚持严格执行各项制度,这是过程改进成功的唯一方法。 (6) 服从期。服从期是指软件过程改进中一次成功、失败反复实验后通过对员工采取强制执行的方法让开发团队成员觉得接受并执行规定是唯一的出路,坚决执行,没有条件。当开发团队成员明白只有执行过程规范才是唯一的出路的时候,大家也就不抵触、不抗议、不反对,按规则执行了。这个阶段的工作效率有了明显的提高。 (7) 习惯期。习惯期也就是开发团队完全接受了过程改进规定的各种规程和规范,并且感觉到了严格执行过程带来的各项益处,比如说产品质量提高了,项目进度可控制性强。不适应过程改进的团队成员也被“洗牌”,接受过程改进的团队成员将过程执行规范等作为工作的唯一依据,形成了团队的过程文化,新入团队成员在过程文化的影响下严格按照过程规范执行,在这 个阶段团队的工作效率基本上是过程改进中效率最高的阶段。 (8) 平稳期。平稳期就是开发团队完全形成了过程文化,在过程文化的影响下管理者、项目经理、质量经理、程序员等形成了某种默契,项目过程的人力资源成本、管理成本、项目进度、软件质量都能够得到有效控制,这时候过程改进带来的“改革”红利才显现出来,并且在企业中持续得到展现,工作效率逐步提高了。 综上所述,在软件过程改进中管理者和开发团队的心理素质起着非常重要的作用,只要我们能够了解这种情绪变化与工作效率之间的关系,那么我们在过程改进中就能够很好地把握团队的情绪状态,了解这种情绪状态下的过程改进手段和工作方法,这样才能够保证我们的软件过程改进顺利进行,为企业管理水平的提高和企业商业目标的实现提供很好的推动作用。 徐杰看完全文,想了想问晨落道: “那我们的过程改进是处于抗议期吗?” “是的”,晨落说道。 徐杰说道: “那应该怎么办呢?” 晨落说道: “两个字——坚持,我建议公司有必要在奖励制度方面讨论一下,然后在强制执行过程中考虑员工利益不受损失的同时奖惩分明,让员工有较强烈的安全感,这样过程改进才能够保证顺利执行。” 徐杰说道: “那制度方面的研究安排什么时间呢?” 晨落说道: “肯定不是今天,具体时间您安排,我积极配合。徐总,您对我的工作有具体要求和指导意见吗?” 徐杰说道: “没有什么,按计划、按步骤严格执行即可,我大力支持。今天通过和你沟通,我的心里踏实了许多。” 第2章设计实现过程讨论 业务调研、需求分析、概要设计、详细设计和数据库设计经过多次修改、客户沟通、多次评审后最终确定下来了,项目组进入软件编程实现阶段。开发编程过程对于昂特拉软件公司来说是空前绝后的挑战,主要因为开发团队的协同开发过程第一次执行,程序员对规范的理解不够清楚,对规范的执行也存在影响。程序员非常反感写文档甚至有抵触情绪存在,将软件测试过程规范化应用在软件开发过程中给项目组与测试部门之间的协调带来了新的挑战,新的技术线路的应用是目前最为头痛的问题,开发部经理的工作经验不足加上从规范到技术都是全新应用,这些对开发部经理李赛强来说简直是新的洗礼,使他有新的蜕变。于是,他甚至有退出项目的念头,总经理徐杰通过其他程序员了解到开发部经理李赛强的思想状况甚至有离职打算,于是建议晨落与李赛强进行一次沟通。 星期六下午七点,开发部投核保系统项目组除李赛强以外的其他员工都已经下班回家了,只有李赛强在办公室忙碌着,因为新的项目要启动了,前期工作内容非常多,另外很大一部分工作内容是他之前从未接触过的。为了解决这些问题,李赛强已经几天没有回家了,就在办公室的椅子上休息了事。今天下午回家的时间也会很晚,因为晨落预约他讨论项目编码实现的相关事宜。晨落如期而至,今天二人约在上岛咖啡厅讨论关于软件实施阶段的工作安排和技术线路的实现方法。 晨落: 辛苦你了,你的工作计划拿来了没有? 李赛强: 在这里,请老师提出修改意见,这份计划书只是针对软件开发过程中的工作安排及项目进度编写的,对于成本控制、质量管理没有编写在其中。 晨落: 我们今天不讨论具体的、详细的开发计划,我只想看一下你编制的甘特图,主要是想了解一下你的工作思路,对于详细计划将组织正式的项目管理计划评审。 李赛强说完打开笔记本电脑,将软件编程实现甘特图显示出来,甘特图如图21所示。 图21投核保系统软件编程实现甘特图 晨落: 这就是你写的甘特图? 李赛强: 是的,我写的不够详细,说实话也没有时间去写这些,因为项目组刚刚创建,有许多工作需要我亲自来干,就软件开发环境搭建一项就搞得我头晕眼花。更何况最近公司员工变更很多,仅这几天我们开发部门就辞职了四名程序员。 晨落: 我觉得这不是理由。 李赛强: 嗯,啊? 晨落: 据我所知,你也动摇了,这也是我找你讨论项目开发的另外一个原因。听说你也打算辞职不干了?那么我先问你一个问题,请你能够坦诚地将自己内心的想法说出来! 李赛强: 请讲。 晨落: 请问这个甘特图是你写的吗? 李赛强: 是的。 晨落: 你是第一次写项目管理计划吗? 李赛强: 原来也写过,但是没有这么详细。 晨落: 你觉得这已经比原来详细了? 李赛强低了低头。 晨落: 请问你觉得你跳槽的资本是什么? 李赛强: 我觉得以我的技术应该能够拿到比目前更高的工资。 晨落: 那你觉得高水平的程序员应该具备哪些素质,当然,和你谈程序员素质不合适,你觉得程序员应该掌握哪些技术? 李赛强: 精通Java EE技术,能够快速编写程序代码,精通各种算法,能够做到程序代码的可复用性、可扩展性等。 晨落: 开发经理呢? 李赛强: 当然是技术高手了。 晨落: 仅仅就这些吗? 李赛强: 当然是有要求了,但不是主要的。 晨落说道: 我觉得你目前跳槽不够资格,因为你根本不具备一位项目经理的基本素质和知识结构。其实一名项目经理,他不仅应该具有高超的技术,还应该具备一定的管理水平和管理常识。而你在技术方面不够精通,对管理方面也一无所知,恕我直言。 李赛强: 哦,那你是否能给我“葵花宝典”呢? 晨落: 没有“葵花宝典”,只有我们共同讨论,分析一下你目前项目计划中存在的问题。其实,你对Java EE的了解根本不够精通。从你的项目计划甘特图中可以看到,在代码实现部分,你的意