|
前段时间我一直在看这本《精益数据分析》，这本书属于【精益创业】主题下的一本书，书中提到一个很有价值的观点：每个公司在每个阶段都有一个【第一关键指标】。我先简单解释下这个名词，第一关键指标指的是在当前阶段高于一切、需要你集中全部注意力的数字。作者举例一家Saas软件公司，这家公司已经过了产品验证市场阶段，进入规模扩张阶段，它们定义了公司的第一关键指标是净增加（新付费客户数-退订客户数）。借着这个知识，我联想到一些岗位是否也有类似的黄金指标或衡量标准？今天我们就来说说2B软件的项目经理这个岗位做得好不好，有没很简单、直观的衡量标准？文章开始，我还是想先对今天要讲的这个岗位的职责做下说明，毕竟现在相同岗位名称，做着不同工作的事的太多了。今天讲到的项目经理，适用于甲、乙方，项目经理的岗位职责是管理软件项目过程直至成功上线，且同时看上线后的应用效果。同时为了不把“经理”两个字用烂，我们也特意强调下这里说的对经理的要求。项目经理的核心不是管人，是把项目顺利完成，所以我们认为能处理好项目问题的，才符合项目经理这个title。我们先上结论：一个项目经理工作好与坏的衡量标准就看他做过的项目，在项目上线后，软件运维的成本有多高？注意：这里说的成本指的是，为维持用户正常使用软件，需要持续投入的软件运维成本。这里要排除服务器、网络等基础架构，也排除掉大部分外购软件厂商行业潜规则的每年“保护费”（这两类不在项目经理可控范围内）嗯，相信看到这里，你可能会提出不同软件项目的用户数不同，模块数不同等客观因素。所以我们这里说的是一个相对的软件运维成本（不要急，看到最后你想要什么都有）。是不是谈到这里，发现每个企业都有差异，讨论这个问题就没有意义了呢？嗯，这是多数人最好的混蒙过关的借口：大家都不同，我们公司有特殊性。然后解释权就都在自己这里了。当然一说要看软件运维成本，你可能就会想到我们要用什么公式计算？先别急着找公式，我们先看一个项目经理的工作状态就可以看出七八成了。项目经理如果一直陷入到已上线项目的运维，你就知道这个项目做得如何了？做的好的项目，都有个特点：低运维（我不希望我们的读者有人是为了低运维，而采用不让用户用哈）。我说到这里可能会得罪不少同行，但今天我们的目的是让有觉知力的项目经理们想想自己应该做什么，所以也就豁出去了。前两年我在内部分享一门产品经理有关的课的结尾，有一页PPT写到：产品不够，运维来凑。我们就从这句话开始来解释低运维。低运维是产品设计时把常见的正向、分支、异常情况都考虑进去，所以未来用户在用软件时，不会出现频繁修改软件的情况。这是项目经理的事吗？从目前我供职过的甲、乙方公司，这还真是绝大多数项目经理的事。一些纯定制化、大项目才有配备产品经理岗位，但哪怕有产品经理，甲方最终也只找项目经理这个人。所以目前国内多数公司的项目经理还真得背产品经理的工作责任。至少你得是检查产品经理工作的责任人哈。那么不在原来项目范围的新需求，市场环境等不可控变化带来的需求变更，这些属于运维的范畴吗？这些能明确定义为不属于原来项目的，还真不能纳入我们说的运维的范畴内。项目经理是个人，没有神的预测能力哈。那同个需求，用户说是原来项目的范围，项目经理认为是需求变更？如何判断？项目过程管理文档的作用这时出来了。大家有《需求规格说明书》/原型，就应该以这种工程文档作为判断依据。我知道看到这里，不少甲方项目管理者会犯难。你说的这个东西，是把双刃剑呀。我们以这个为标准，我们内部需求单位会认为我们偏袒乙方。那么请问，一件事如何没有行业的公认标准，那么谁来认一堆糊涂账？最终的结局可想而知，大家来回打太极，一起分担点，然后往后互相算计或者将就着用吧。说句大实话：一个工程类项目，咱们真弟弟有像盖房子、建桥这样的硬件建筑标准来对待它（我希望我们的读者是有把一个产品用10年的长远眼光的）。咱们不会只讲概念，继续来深入看看软件运维包含了哪些？1、为了让用户正常使用，而投入的人力、财力运维成本。这是大家最容易理解的，软件项目的价值是从上线使用后才开始。但用户用得好不好（上线前后做同一件事花的时间），沉淀的数据准不准、及不及时。才是检验软件项目效果的【关键指标】。为了让用户正常使用，IT部门/软件公司需要投入在这上面的人力、财力成本有多高？而相比其他做得好的同等规模的项目，人家的成本又是多高？我知道还有人会提出，市面上很难找到类似用户规模，模块数的可类比。这时可以简单采用【费曼估算法】（知乎上找找）。注：这里说的运维主要指对使用过程的问题处理，包括权限、审批流、新基础资料建档等。这个点比较容易被多数行外人忽略。但却是多数软件运维人员头疼的事。这里的成本实际上包含了软件运维教用户的时间成本，还包括新用户学习、适应软件所用的时间成本。哈哈，说到时间成本，大概率是我们最无感的一类成本。很多管理者会想，反正公司本来就是付员工月薪，员工多工作点时间对我没啥损失。事实真的是这样吗？这个不深入了，请分别从不同人的视角切换考虑，会有新答案的。这里的教人成本和学习成本，其实都应该在产品设计阶段尽量考虑，这也是现在一直在推崇的软件设计理念【一看就大概率要会用】所有能讲清楚的，才能称之为问题。软件上线后还会出现BUG或上面说到的遗漏分支、异常情况的考虑带来的用户无法使用的问题。这些问题要么是项目过程管理问题，要么是方案力不足。但一旦上线了，这些都会带来新的运维成本。只是这时换了名词：开发成本。但真正有价值的开发不应该是去收拾历史烂摊子。我知道你一直在等我们说的【第一关键指标】的计算公式。到了结尾，我们还是要能给出点东西的。看完前面的软件运维怎么衡量，我相信作为从业者你应该要具备自己的估算能力。我简单说下三类成本的计算原则。1、用户正常使用的运维成本，可通过投入的软件运维人员的时间成本来算2、新用户学习成本，可通过教与学的人从接触到能上手分别花费的时间成本来估算3、软件缺陷、设计不足的再开发成本，可通过公司额外支出的开发费用，和由此造成的影响业务开展的隐形成本来估算说到这里，我们讲到的是本企业付出的成本，既然要衡量我们项目运维成本的高低，那就得和同行或同规模的企业对比。那么如何拿到、估算这个数呢？外购软件项目：你可以和软件厂商的商务人员、有经验的项目经理聊。只要大家合作关系良好，拿到这个对他们来说没啥机密的数据并不难。如果你问不到，要想的是沟通能力的问题。定制开发项目：你可以看同行竞品每年的运维成本。多比较几家，结合前面说的【费曼估算法】和项目估价用到的【三点估算法】，也就大差不差了。如果你拿不到，要想的行业资源的问题。好了，今天讲到衡量一个2B软件项目经理的能力高低，就看他做的已上线的项目的运维成本。欢迎同行一起讨论、提出新观点哈，让这个行业更加蓬勃向上
|
