如果你问任何一家软件公司里计算机专业出身的攻城狮们，啥叫软件工程？TA们一定都会下意识的在心中轻嗤一句——你是小白吧？可是真要较真起来呢？……小伙伴们也许会说：“我干嘛非得知道软件工程是啥，干就完了！”这话没毛病。可对于我们的组织（/团队）管理者来说，这个问题很难再绕过去，你打算带着大家咋干呢？咋干能越干越好？其实这本身探讨的并不是一个单纯软件工程定义的问题，而是一个打造组织软件工程能力的问题。

        在2019年初HW001号文件中，任老板敲着黑板提出了“全面提升软件工程能力与实践，打造可信的高质量产品。”犹记得那时深夜在公众号里读到时，让我激动不已，无法成眠，感慨HW已经走到了正确的路上，而我们什么时候才能拨开那蒸腾的经营数据堆砌出的一片繁荣，不再傲慢，正视自己，拿出真正的高品质产品，才能让我们活下去，且活得更好，活得更有尊严。

        节后总有小伙伴来与我探讨有关软件工程能力提升的话题，有时信马由缰的聊得也琐碎零散，遂决定梳理成文，希望能帮助大家在组织内的软件工程能力提升工作中找到有力的抓手，更是抛砖引玉，期待大家提出更多的问题，意见与想法，让我得以继续思考、改正与成长。

        软件工程这一概念在IEEE的软件工程术语汇编中的定义是：将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，也就是软件的工程化。工程化的意思是，我们不希望开发软件是手工作坊似的自由随意的方式，而是一个工程，工程就意味着他需要有规范的过程，系统的、量化的管理，正确的方法，科学的工具，专业的（工）人，这样生产出来的软件才是有质量保证的，让客户满意的，能够持续演进的，可规模化的，能不断给我们带来收益的。

        因此，如果我们希望提升组织或团队的软件工程能力，不妨从下面这四个方面进行考虑：

一、过程

1.我们是否建立了统一的、规范的研发过程，生产交付过程，（设计制造过程，）服务运维过程？

2.这些过程是否满足目前的业务形态生产与交付的需求？

二、管理

1.我们是否设立了专门的职能负责这些过程的实施推行与持续改善，以及各项目执行过程中对过程的遵从性？

2.无论是研发类项目，还是生产类项目，项目是否是可计划？进度是否可跟踪？成本与质量是否可度量？

三、方法与工具

1.我们的软件是否可用（质量问题）？是否好用（业务符合程度问题）？是否耐用（非功能需求满足程度问题）？是否易用？（用户体验问题）

2.我们在规划，需求，架构，开发，测试，实施，运维等阶段是否能够采用正确的方法与有效的工具开展工作？

3.是否知晓在上面这些阶段中“干得好”的标准是什么？

4.我们能否清晰的识别出我们在项目进行过程中哪些环节或阶段出现了问题而影响了业务价值的传递，并知道用什么方法与工具能够尽快解决？

四、人

1.我们对于初级开发与测试人员的培养周期是多久？对他们是否有系统的培养方案与课程？

2.我们目前关键岗位人员规模是怎样的？包括：产品经理，业务领域专家，（业务、技术、数据）架构师，测试运维专家，UCD人员等。是否有专项的培养或引进计划？

3.我们的工程师文化核心理念是什么？通过哪些机制与专项工作将这样的文化渗透到组织内？员工对文化的认知与认可程度如何？外界（客户、伙伴、兄弟部门等）对我们的印象是否是一致的，且与我们希望传递的文化气质相契合？

        以上只是粗略的列出一些供大家思考的检查点，那么我们究竟应该先从哪里入手呢？原则上，过程与管理部分是组织的基础能力（这里特指大规模开发组织，如果你是创业组织，那么完全可以越过这层，直奔目标，快速成事）。在工作有序开展的基础上，我们再去关注方法与工具，首先通过软件价值链去审视并识别我们在哪些环节或阶段上出了问题，将这些问题排定优先级，然后把我们要解决的问题有针对性的设立专项，比如：业务规划专项，需求管理专项，架构质量专项，自动化测试专项，交付工具链专项等等，专项问题解决方案可先在一个或几个业务线进行试点，然后再组织内全面实施推广。而人与文化的部分更多与人力资源领域工作相关，这里只赘述一句话——HR与研发/业务的高度有机协作是这一版块工作成功的关键，对组织里HRBP的能力更加是一种考验。

        软件工程能力这个话题着实很大，这样尝试梳理之后才发现自己能力有限，无法驾驭，如果上面的文字能带给大家一些思路，那将成为我的动力，期待咱们后续更加深入的思考与探讨！