2017年内部变革意见与建议

一、变革目标

以提高项目开发效率为核心,用规范化、可量化项目开发与管理技术,保证项目的可控性与高质量;增强员工专业技能,提高团队整体竞争力;促进内部良性竞争,活跃技术氛围;增加公司资金积累与技术积淀。

二、现状与痛点

a) 旧框架的尴尬处境

之前的旧框架对于公司初期提高项目开发效率的确起着至关重要的作用——使用门槛低(低到基本上只要有是java入门级别的就可以独立开发一个功能模块)、开发速度快。

如今,旧框架已成“鸡肋”——虽说开发效率很高,但系统界面风格老旧且不易扩展、代码质量差。个人分析有以下几个原因:

1、框架对第三方技术的封装违反了不污染源代码与适配的原则,造成框架对extjs的依赖版本极其严格,却又无法兼容其新特性的致命弱点。

2、框架仅由一人维护且脱离实际项目应用场景,仅进行bug修改,缺乏框架的统筹设计与持续升级

3、框架的使用降低了使用人员的技术门槛,但在缺乏规范性培训与基础技能培训的环境中,框架的优势很容易被劣质代码所引起的不可维护性与低性能所冲淡。

a) 新开发模式无法积淀

2015年起所使用的新型开发模式按说应该在一年半多的使用经验中进行了归纳与总结。但由于在项目中一味尝试新技术(有的技术其实已经过时并淘汰)却浅尝辄止,无暇也无法进行新架构的积淀。

不过,还好在在各种“尝新”的过程中,血淋淋的教训告诉了我们:

1、只注重业务功能的堆积,而不注重系统的性能与可维护性,产品上线之日就是产品死亡之日。

2、企业不是实验室,一味“尝新”的代价可能是断送一个企业的前程。

3、任何成果都要以文本的形式进行总结并进行最大范围的分享。没有总结的成果不算“组织过程资产”

4、执行力!执行力!还是执行力!从上到下不要抱着得过且过的态度做事。不要懒,项目没有文档只有代码没啥用。不要怕,非正式沟通(电话、即时聊天等)与正式沟通(邮件)都不可少。不要拖,遇到问题及时沟通,该与干系人交涉的就去交涉。

a) 前途是光明的,道路是曲折的

现在公司领导已经意识到问题的严重性,决心要调整。虽已有所做为,但仍有几点明显或潜在的问题需要解决:

1、全新框架意在提高开发效率、规范架构模式。目标是通过组件化(包括微服务)与工具化提高复用度。但当前的全新框架及其工具的开发过程就不符合其目标。——代码散乱堆积、无版本控制、与旧框架有过多裙带关系。

2、全新框架的开发与完善非一朝一夕,需要专人统筹与升级

3、全新框架能否广泛地、持久地应用,与高层的决心有着至关重要的关系。框架研发框架使用培训框架推广使用反馈采集框架升级,环环相扣,任何一个环节执行不到位,都会重蹈覆辙。

4、鼓励大家勤于总结,乐于分享。围绕全新框架形成“技术社区”的氛围

三、变革方案

a) 系统架构组件化与项目开发工具化

依据核心库、工具库、业务库进行划分,通过jarwar的形式组织系统体系中的组件库。适当的抽象与小粒度,再配合适配器设计模式,可以适用于单体、微服务等系统架构方式,可扩展性、易维护性、高复用性将是其主要特点。

项目开发工具化,最大程度的减少开发者对非业务逻辑代码的编写,不仅可以减少代码编写量,提高项目开发效率,而且可以增加开发者在业务理解与业务设计上的能力提升。从整体上提高团队的项目管理能力。

b) 开发规范化的培训与贯彻

有了好的开发工具与结构体系,并不意味着所有使用者都可以快速开发出一个高效率的项目。细节很重要!细节很重要!对于框架的使用与工具的使用,必须提供全面而且持续的培训,不断更新开发人员的使用技能与知识体系,规范项目开发过程。在此过程中,也反过来通过切实的需求,促进架构与工具的完善升级。

c) 成立专门的QA团队

成立围绕项目生命周期全过程对公司董事会负责QA团队。QA团队要对项目关键文档进行跟进,对项目的代码质量进行规范与检测,对系统功能与性能进行测试。

d) 规范项目关系人间的沟通方式

在项目内部干系人(同事间)以及同外部干系人(客户、第三方等)规范沟通方式。采用非正式沟通(电话、短信、会议、即时聊天工具等)与正式沟通(邮件)相结合的方式。与项目相关的变更确认等决定需要有邮件作为依据,并把附件在项目文档中归档。

e) 进行资金、人才、客户与运营经验的储备

应着眼现实并从长远考虑,通过短平快的项目与自主产品,进行资金、人才、客户与运营经验的积累。以待“寒冬”过后,抓住机会迅速发展,做到“厚积薄发”。

© 2017, 李德涛博客. 版权所有.

《2017年内部变革意见与建议》有5个想法

  1. 嗨、博主你好,我是Feeey 我又来咯,你的博客真棒,做友链吗? 我网站名称:Feeey个人博客 如果交换友链挂上我的链给我留言吧。

发表评论

电子邮件地址不会被公开。 必填项已用*标注