网站如何做市场推广/企业微信营销管理软件

 

前两部分，我们提到创新提升要基于一个目标，知道现状，然后定一些具体的改进计划。当一个企业要用这个方式来提升，与个人提升的主要区分是增多了很多干系人与活动。

 

我们这次就分享企业如何基于个人创新的思路，用于公司的提升。

下一篇会利用这公司提升的例子，解读 CMMI V2.0 (与 V1.3)。

 

1「引子」

 

刚才一个杭州的企业做了一些咨询访谈，有员工就建议高层应该尽量不要直接插手管理项目（例如：有时把一些项目所需要的关键资源调走，导致项目受影响）。

 

当一个企业从本来几十人，增加到几百人时，管理者很难从原来亲力亲为的管理心态转变为由系统管理公司的心态，反而阻碍了公司的发展。

 

这时候需要引入一个从上而下的系统，驱动整个公司的提升，就可以避免刚才那种Micro - manager的情况。

 

过程改进与几百年前那些音乐家的创作最大的区分是过程改进需要整个公司所有人上上下下的协作，目标也要一致。比如你要提升生产率，正如前面所说，整个系统都要配合，无论工程、项目管理、需求、测试，但是这些都是不同人执行，所以主目标要细分。

 

贝多芬自己就能完成一些传世之作，是由于当时的发展速度和现代社会差很多，在一些贵族的支持下，他可以慢慢琢磨一些佳作，莫扎特要写很多作品来保持自己的收入。他们的效率以现在的角度来看不高。但是，我们过程改进不同，现在项目变化快、提交期短，需要有系统，协调各个层次的目标，与公司总目标保持一致。

 

 

2「举例」

 

举一个实例来介绍企业如何用一个简单系统来管理整个公司的提升。

1. 识别公司的总目标

例如在下一年，要一年内生产7个新的产品系统。

2. 描述公司的现状

例如现状是：平均一年只能产出3个新产品，有2个开发团队。但开发人员的能力有限，质量也不好，导致用了不少精力，去维护已经完成的产品，没有时间来开发新的，招新人也不容易，比较难找得合适的，也没有时间培养新人，扩大工作。

3. 形成具体行动计划

例如简洁、清减的开发流程，加强代码评审和编码能力，来减少缺陷导致的返工，要跟市场部密切合作，确保新产品满足客户的要求，给客户带来价值。

 

延续刚才从上而下的例子，我们就可以定一个公司的上而下的总计划，但真正的计划需要更具体、有数字，例如下图：

4. 当我们定好明确的最终结果，也了解真正的现状，有一些行动计划，下一步是具体到每活动的完成日期和负责人。

 

 

所以如图，写上计划的完成日期与负责人。要注意计划不是一个人定出来，最好召集主要的干系人一起使用一些大白纸一起讨论，不建议在初步的计划直接用电脑、系统，这样导致整个计划变成一个人的事情，其他人都是观望；反过来，大白板是让每个人都参与的平台。

 

 

刚才说到的每一项的行动大家可以想象不是单靠一个负责人可以完成的，例如我们要提高产品质量，减少返工就会牵涉到各个研发、测试，甚至需求，都要做一些改进行动才可以体现，所以大家可以想象，一个真正可行的计划，从上而下有多个层次，比如刚才的质量例子，他可以从公司总的质量目标，分解成各个相关活动，再分配给相关负责人。甚至还有更下一层的分解，比如我们说质量提升要看开发人员写代码的质量要完善，和提升代码评审，单元测试等。这些很可能要分解到研发人员的一个改进子计划，才可以把里面的培训、新的检查单、引进一些自动化工具等，配合起来才可以让每一位干系人看到全局，就如图,一层层分解：

    

 

每个层次的活动都有具体负责人与日期。更有一个要令整件事复杂化的，就是活动之间也可能有相互依赖关系。例如：

 

我们要开发学如何写好代码，就需要先邀请一些老师来进行培训，

或

要做自动化的代码检查，可能要依赖公司的系统支持，先升级相关的服务器。

 

要把所有不同层次或有依赖关系的活动，就需要有一个支持WBS（work breakdown structure工作任务分解）的系统，不可能单靠写在纸上或 XLS表格。

 

 

 

 

 

3「控制」

 

 

有计划也必须有控制，（对计划的跟踪、监控），

这也需要有系统，让管理层管理进展。也避免了管理层需要记住/跟踪每件事，他只要看到系统就可以看到全局，能够比较计划和实际。

让管理者，与所有参与者都即时看到所有相关活动。好比我们做项目，先有个大的总计划，每个人都知道有什么要做？现在什么状况？

 

 

 

4「目标的分解」

 

 

 

公司定一个总的目标：质量提升。也要分解到子目标才能控制好。例如我们要提高员工的生产效率、产物，可能要细分到编码人员提升多少，测试的效率提高多少，才能达到总目标。

 

 

下面是一个公司利用项目管理工具过程改进WBS的实例：

 

质量目标同样可以分解。

 

所以后面我与杭州公司的管理层如此说：如今公司规模扩大，管理层应该提出总目标，让下级去实现，而不是自己亲力亲为计划如何来做，这样才能让下级有提升的空间，你们可以用现在的项目管理系统，把整个过程改进的小组工作做出，现在只是定了一个很概括的总目标，但是以前没有系统进行控制，这个想法没有任何执行，应该像项目计划一样具体，才能产生效果。

 

以上说的方法听起来很简单，大家都懂与个人要创新突破的问题一样在有想法，但缺乏执行。 大部分公司都会在年初制定目标，但很多目标都是老板拍脑袋随便定的，也没有任何数据（以往的历史、或行业标杆）来参考、支撑，也没有具体的分层行动计划与相关监控。

 

5「怎么开始？」

 

正如我们前面做个人改进一样，要改变人过去的习惯，做一些提升，是不容易的。

企业要改变更难，如何开始呢？

基于我们的经验，从易入难，先动起来 （解冰）。

可以先基于现有项目，让项目经理依据现在的情况做一些尝试、试点，看看如何。

有了效果，再以此具体定制一些过程、模板、系统相互配合，让其他项目沿用这一套东西。

 

 

推广产生作用后，就可以扩大到整个部门。

 

在没有确定效果前盲目推广（或制定流程）只会带来反效果。

无论试点还是推广都可以按照刚才项目管理的行动来变成具体的细化和控制。

 

 

公司过程改进小组没有真正运作起来，很多是因为没有依据改进目标一起制定一个详细的行动计划。大家可以想象过程，改进需要每一个部门都参与，才可以提升公司的最终目标，公司是一个系统，所有员工参与改进整个系统：

 

（上图参考 M. Weisbord, Productive Workplaces Revisited）

 

如果没有按照上面说的步骤，形成具体行动计划，很难取得效果。

 

过程改进不是一两个月、两三个月就出成绩，开始时候，员工可以关于创新、改进有想法，写文章分享，但要这个作为习惯继续下去，是需要有些新的想法和思路，这可以借助公司内部培训，比如有没有过程域相关的参考资料，内部分享会，学习小组，定期有老师的辅助指导，定期体检、诊断。例如我们软件开发提升其实最核心是写好代码，做好测试。这些需要具体的培训和老师的指导，才有成绩。同时，公司也需要完善的度量体系，以数据说话，这个很多时候需要相关自动化系统支持，否则无法确保数据的真实与即时，单靠人工收集是无法做到。

 

 

 

 

6「怎么开始？」

 

以上都是CMMI如何可以帮助公司实际提升的元素：

模型 + 系统 + 人员 （有度量）

 -    用度量让员工了解现在的不足，制定具体的目标；

 -    用模型+评估促进员工改变习惯，开始改进；

 -    用系统把改进后的过程持续下去。

但必备条件是：领导和公司员工不满于现状，都觉得必须要改进与提升。 

 

7「实例」

 

实例：如何提升开发的质量与效率。

 

自动化测试

 

我接触过的大部分软件公司仍然只靠手工测试。昨天一位专注编码和测试咨询的顾问就分享了好几个实际案例：

 

每次咨询开始，他都先关注公司是否有做自动化测试。

 

问：现在测试覆盖了多少功能？

答：不同项目不一样，可能70%左右

问：为什么不能达到100% ？

答：人手不够时间不够

问：自动化不是可以帮你解决吗，为什么不用？

答：现在的的测试工作太忙了，没有时间学习自动化测试。

 

其实只要用了自动化测试，效率便可以提升；自动化的测试还可以随时复用，改善回归测试。

 

编码质量例子

 

组长们都同意老师提出的代码陈旧问题。

 

老师说： 为什么不完善，避免发生缺陷？

他们会接着说，这些只是少数，你看我这些高手的代码都挺好，都没有问题。

 

老师说，如果这些确实是潜在的问题，便应定好规范，避免发生问题，而不是让开发人员单靠自己的经验来判断。

 

老师做培训的时候，通常都会直接看客户的真正代码，他还会先说：“依据过去的历史经验，几乎每一行代码都会找出一些潜在问题。”

 

大家半信半疑，他接着说：“这些问题可能在极小的机会才会发生影响，但还是应避免。”

 

果然第一行便发现了一命名问题，第二行也发现了 。 。 。

 

过了两个小时白板上写就写出了一堆代码评审发现的问题。

 

问组长为什么不讨论讨论怎么完善这些代码的问题？

 

组长说写代码，不是我的主要关注点，我更关注总体架构。

 

老师请他具体说说最近研究过什么新架构或做了什么改善？组长却说不出来。

 

开发平台/环境例子

 

问：你们现在C++开发用那个版本？

答：98

 

问：为什么不用11版

答： 用了很久，习惯了，

 

想想吧： 刚毕业的学生都已经是用17年版了，但公司的专业开发还是使用接近20年前的版本！

 

应怎样开始？

 

以自动化测试为例，我问老师是否要学很久？

他答：“我们去年在杭州的敏捷与自动化测试试点项目，那位测试人员也只用了4个月便把握了自动化测试。”

所以三四个月的试点是挺好的第一步。

 

反思

 

我说：类似的情况我在接触的公司常常见到，这都不应怪员工，应看成是公司整个系统的问题 —— 没有不断提升超越自己的环境，导致大家安于现状，养成习惯，天天继续“努力”工作 、埋头加班。

 

这是一家专注通信的产品的软件公司的现状，我们可以想象，其他不是做产品，只是做项目到了在开发公司问题更严重。

 

这些都是公司没有实际的度量来驱动提升，大家都没有优化和改善驱动力的案例。

 

 

以上只是一些写代码与测试的例子，老师也跟我分享他自己的一些提升数据：

03年： 平均每一个功能点要21行代码；

15年：平均每一个功能点要14行代码；

18年：平均行数便更低了。

 

他说他培训过的产品公司，很多产品的代码行数，开发人数等都会有几倍的提升空间（与他估计如果整个产品的软件由他写来比较）。 

 

所以要改进必须从上层到员工都需要从实际度量数据中，意识到有不足才可以驱动持续的改善。

 

他的总结 - 成功要素是：

管理者不满意现在的开发与测试效率——如果遇到的工作量增加只想增聘新人解决的话，公司想从手工转到自动化都不会成功。

 

反过来，如公司老板都有很高要求，以下场景便不会再出现：

问一些部门经理，他们主要关注什么？九成会说——进度。

再问，提升目标是什么？

有一半在经过思考后，说希望提升10%。那再问，过去的进度偏差是多少？

他就无法说出，因为没有可靠的数据支撑。

以项目管理为例，大部分公司因为缺乏项目管理的信息化系统，都没有一些项目管理的可靠数据。

 

后记

这是创新系列的的3篇，第1、2篇也在本公众号，发的比较早，题目没有标识上创新二字，大家可以对应一下：

（创新 1）为什么创新(Creativity) 不够 ？

（创新 2）怎样才能创新、提升？

（创新 3）公司如何提升？

（创新 4）领导的工作

（创新 5）如何激励知识工作者

 

References参考:

Robert Fritz, The path of least resistance for Managers  

 

联系我们

电话：18921395967

QQ：1228021190

微信：processis2009

地址：香港/北京/江苏

官网：www.processis.org

邮箱：claire@processis.org