首页 > 管理

环境、现状与反思

2015-11-16 14:07:05 分类: 管理

1 我们今日的窘境

1.1 环境

  我们所处的环境是一个追求“革命性技术”的业界。公司追求着多、快、好、省地解决问题的捷径,管理者关注的只是软件进度、发布版本、成本和利润,在他们背后,软件缺陷已经埋了下来。专注代码质量的程序员往往不受青睐,因为他们思考的更多,在开发进度方面往往不尽人意。当项目负责人无法评估或不关注代码质量时,客户只会得到一堆调试不良的代码。

1.2 人才流失

  今天的程序员大多数都不会长期从事某一种技术,这与收入紧密挂钩。程序员会倾向与转型为更高收入的技术队伍,或者退出IT业。随着市场供求关系,各个阵营市场占有率,利润等多种因素左右着程序员的收入。即便是在某个技术上十分出众的程序员,面对经济上的现实差距,也无法抵抗金钱的诱惑而转投其他技术队伍。现在的市场,不再尊重那些资深从业者,而是迎合“现学现卖”的投机者。归其根本在于,对代码质量的低要求,使得技术硬手无用武之地。

1.3 系统交互复杂

  今日的信息化系统已经不能由独立的公司或软件产品承担,而是趋于多公司,多平台的相互协作与交互。现实的挑战就是,更大的系统,更多的平台,更繁琐的流程,更复杂的整合需求,以及更多的标准。

1.4 技术快餐

  与之前不同,现今的开发者更为大胆。他们敢于将未经验证的新技术应用与产品或项目。开发者可能经过短暂的学习(一周或者几天)就将学到的并不熟练的技术应用于项目,之后的风险全部转嫁的测试或者客户身上。而此后也不再对这些新技术继续安排学习。程序的可靠程度和可维护性大大降低。

1.5 产品团队不堪重负

  与项目不同,产品的代码版本及分支路线更为复杂,其生命周期更长。当你进入某个产品项目,你很可能面临的是,缺失或低质的项目文档,多种风格并存的代码以及潦草的少的可怜的注释。那些最先搭建系统的前辈可能已经离职,开发团队组成也许已经经过几代,你听到的最多的是抱怨。面对那些延期的bug和新的需求,没人通晓这些堆积如山的代码,牵一发往往动全身。阅读和理解代码占据工作的大部分,面对客户的各种要求往往不堪负重。

2 一些成功的经验

2.1 提高代码质量 

  • 改进QA流程 多数QA仅仅依靠大范围的人工测试来评价项目质量,即多数公司的QA依靠的是测试团队。理想情况下,大范围的测试并不会有很高的错误检出率。(如果你的团队,每次发布版本,你们的新建和重新打开的bug数量仍然很高,我只能说你们的公司尚处于软件作坊阶段,真正成熟的团队,是不会允许交付测试团队一堆调试不良的代码的,即便是在赶工时。)检查缺陷最有效,同时也是检出率最高的方法,就是——代码审查。因此,必须在计划阶段,就为代码审查预留时间,以便让开发人员参与进来。
  • 激励手段 在绩效结构中,应该与质量、进度、复杂度等挂钩,而不是单纯地只看进度。
  • 测试每一个关键里程碑 理想情况下,测试每个版本,测试用例做到100%的覆盖率。但现实中,出于时间、成本等因素,测试不可能细化到边边角角。但对每个里程碑进行全面回归测试是最低的要求,这样软件的bug更少,开发团队更能受到激励(例外是测试报告不尽如人意)。
  • 乐观的对待错误 不要把测试当成是对代码的鸡蛋里面挑骨头,不要埋怨为什么测试现在才测试出之前某个版本的缺陷。PM一定要避免开发团队和测试团队之间的相互指责。
  • 要求清晰、简洁、明清的测试报告 测试报告应该言简意赅,不要过于追求样式华丽,技术型文档能够用一句话说明白就别啰嗦。
  • 使用缺陷核对表 “缺陷核对表”我也想不起它的出处了,也或许是我的主观创造,但从项目实践角度讲,“缺席核对表”能够有效降低缺陷数量。下列显示了一种简单的缺陷核对表:
问题描述 根本原因 缺陷类型 严重程度 出现次数 解决方法
修改下拉列表内容后,进行操作会触发未处理异常。 数据完整性约束被破坏,阻止操作。 设计缺陷 严重 4 禁止修改下拉列表选项。
上传大文件报错。 服务端限流。 配置缺陷 一般 2 修改配置文件的消息大小限制。
... ... ... ... ... ...

  这份表格是否好用,在于其更新的频率与用户群。它能够帮助PM及时发现bug集群,并可以通过例会或邮件打预防针,防止缺陷核对表上的bug蔓延。

2.2 为人才流失做准备

  • 注重文档的积累并注重代码注释和编码规范
  • 推动团队内部的交叉培训
  • 在某些共识的环节上推动自动化
  • 建立健全的雇员框架

2.3 一些成功的系统整合经验

  • 组建跨职能团队 公司各个智能部门都有义务参与进系统整合,通过关键用户来平衡各部门的需求。
  • 制定合理的进度计划 PM能够顶住压力,制定现实的计划,而不是通过削减范围或质量来迎合公司。
  • 认真评估资源 很多项目需要外部开发人员参与,所以需要对这类资源进行能力评估,以便合理安排进度。
  • 并行上线 在新系统没有通过最终审核之前,请保证旧系统的良好运作,同时维护好旧系统的数据。
  • 做好打持久战的准备 不同于制作网站或OA,整合项目牵扯到更多的需求,更复杂的系统和业务流程,因此,请做好需求频繁变更以及打持久战的准备,并让团队了解现状,防止团队因为长时间的开发和过少的里程碑而形成挫败感。

2.4 有效降低产品的维护成本

  • 创建并维护文档 文档如代码一样是宝贵的组织过程资产。虽然敏捷软件开发注重可以工作的代码,但是,也不能打着敏捷的旗号来抵制文档。一些必须有的文档,比如:需求说明书、软件规格说明书、开发计划、设计文档、测试报告、变更控制等,需要纳入到配置管理中去,并且在维护过程中进行同步。
  • 严格遵守编码规范 编码规范必须在项目组内部达成共识,所以开发人员必须严格遵守,有条件的推荐进行自动化的编码规范审查。
  • 做好配置管理 请参考本人博文 SVN与SCM
  • 推动自动化 推动测试、发布、代码审查的自动化。
  • 推动交叉培训 不要等到人员即将离职才分享他的经验,要在工作间隙,利用暗时间,推动团队形成交叉培训的习惯,使关键技术不会局限在单点。
  • 快速处理产品问题 对于延期的bug要尽快处理,越晚处理,其修复成本越高,一旦开发者离职,让其接任人员来修复这些延期bug则有些强人所难。
  • 对新技术提高警惕 评估新技术带来的风险与收益,选择那些满足企业宏观目标的技术,尽量不要在高风险项目上引入未经实践的技术。对于技术探索项目,范围不要太大,而且,一次不要引入两个以上的新技术(也有保守的公司,规定技术探索项目,只能引入一个新技术点),以便能有效地评估收益和影响。在引入新技术的过程中,一般用1/3的项目时间快速学习和吸收,用1/3的的世界培养团队自立,最后1/3的时间让团队成员完全掌握。
  • 完善项目管理 建立完善的项目管理流程,能够形成以客户为中心的,有完善体系的产品团队,即有效地协调需求、开发、测试、质管、实施等不同资源,快速应对来自不同客户的需求。

2.5 让团队成员参与项目管理

  如果团队成员没能参与项目管理,则项目管理将大打折扣。为了让团队的每位成员都参与到项目管理中去,有以下建议:

  • PM需要从团队成员角度思考某些问题 PM需要理解和接纳程序员的某些工作风格和激励因素。
  • 适度的授权 对有能力的成员授权,不仅能提高其积极性,也能让PM能专注于其他业务。
  • 常开会,开小会 经常与成员沟通,了解项目现状,但不要开那种冗长的会议。
  • 对于团队性决策力求达成共识 PM不要以权压人,对于如编码规范这类影响较大的规定,需要促成团队成员的共识,而不是自我的独断专行。如果PM搞独裁,那团队成员也会玩非暴力不合作。
  • 在员工入职培训时强调项目管理 在入职培训课程中,明确项目组的各种规定,流程以及工作各种辅助管理软件的使用。

3 IT治理

  IT治理就是要明确有关IT决策权的归属机制和有关IT责任的承担机制,以鼓励IT应用的期望行为的产生,以联接战略目标、业务目标和IT目标,从而使企业从IT中获得最大的价值。

3.1 IT治理成败20条

10条有效运用资源的方法:

  1. 针对IT治理价值,与开发者保持坦率的沟通,解决其中问题而不是压制言论。
  2. 组建公司级跨职能IT治理委员会,保证治理顺利推行,保证技术体现客户最大利益。
  3. 建立量化指标,利用公认的指标评估治理进度。
  4. 保证IT基础设施各部分的透明。
  5. 将公司IT治理策略延伸到外包商。
  6. 建立能表现业务目标的全景视图。
  7. 将IT治理视为促进企业成长的基石,利用奖金引导员工的正确行为。
  8. 对公司员工和团队内跟不上变化,相关技能欠缺等等迹象多加注意。
  9. 在软件开发周期的每个环节都实施IT治理,以防留下盲区,导致差错。
  10. 推进自动化,但不抛弃人工评审流程。

10种白白挥霍资源的行为:

  1. 未经解释就强制推行的官僚流程。
  2. 架屋叠床的监督层级。
  3. 无人能懂的报表。
  4. 被隔离于代码之外的开发者。
  5. 仅限于单个部门的努力。
  6. 企图一切尽善尽美的紧张神经。
  7. 仅在一两个方面实施IT治理的开发流程。
  8. 缺乏跟踪IT管理的支出和效果评估。
  9. 重复创造的策略。
  10. 对IT治理资源充足程度的盲目自信。

3.2 衡量IT治理和相关投资成效的10个问题

  1. 管理层是否支持和实施IT治理?
  2. 开发者是否参与其中?
  3. 是否是公司的主动战略行动?
  4. 是否增加了企业透明度,使部门和员工权责分明?
  5. 是否让引入新技术和企业合并时的基础设施融合更加容易?
  6. 能否帮助员工改进行为?
  7. 是否给所有干系人提升价值?
  8. 能否做到极尽精益和高效?
  9. IT基础设施可否随时抽检,而保证没有问题?
  10. 是否减少了软件缺陷?

4 杂谈——终结IT业七大流言

  1. 信息技术是精确的科学 现实是, 建立应用依靠的是程序员的代码,而编码是一门艺术,程序员是匠人,信息技术同样需要工艺。
  2. 下一个版本能解决这些问题 软件开发商的常用伎俩。
  3. 开箱即用 企业级软件往往很难达到开箱即用,这往往是软件厂商的吹嘘。
  4. 代码文档完善 现实是,开发人员被进度和变更压榨了120%的时间,无力维护文档。
  5. 文档说明一切 文档质量参差不齐,有时不得不聘请外部顾问。
  6. 团队不需要“黑客”和“牛仔” 前者指那些擅长安全技术的人员,后者则指那些技术强硬但特立独行的人员,他们的共同特点是技术过硬,工资不菲。其实开发团队中如果有掌握安全技术的成员,能使你开发的系统更安全;而如果能驾驭牛仔,他将能帮助团队冲破围城。
  7. 最大的安全威胁在公司外部 现实是,绝大多数攻击源自公司内部。

 

参考文献:

  《差错 软件错误的致命影响》

 

 

参考手册

W3c0.com 提供的内容仅用于培训。我们不保证内容的正确性。通过使用本站内容随之而来的风险与本站无关。W3c0 简体中文版的所有内容仅供测试,对任何法律问题及风险不承担任何责任。 当使用本站时,代表您已接受了本站的使用条款和隐私条款。版权所有,保留一切权利。 鲁ICP备15022115号