软件开发到底难不难？

最近，有一位老板和我说，“真搞不懂为什么软件项目开发那么难，投入了上百万的费用，拥有十几个人的研发团队，最后做出来的系统难以交付，还得要推翻重来进行大重构才能继续往上迭代新需求。”

这是一段真实的经历，也是一个值得思考的问题。软件开发，到底难不难？不就是写几行代码吗？但，真的就只是写几行代码的问题吗？

项目失控、代码难以阅读理解和维护、系统故障不断频频“救火”、交付日期延后延后再延后、核心开发人员流失严重、改个文案技术说要半天时间、线上服务器时不时报木马攻击……如果管理不当，很可能你的项目和团队也会遭遇到如此的困境。

软件经济

据说，一家企业，人均产值每年在20万是及格线，在30万及以上是优秀，在50万或更高则是卓越中的佼佼者。

因此，即使项目管理到位，产品研发交付成功，技术人员团队也稳定，技术上游刃有余，把“事情都做正确”了，也可能因为没有“做正确的事情”，最终业绩是平平如也，因为没能达到软件经济的及格线。

尤其对于一家是靠软件产品和服务产生经济经益的企业，研发产能是苦劳，产出是功劳，产效才是业绩、是ROI、是生命线和现金流。

举个例子，一家企业10个员工，平均每人每月1万工资，光人力成本一年下来就是120万，还不包含其他成本、五险一金和年终奖、调薪等。假若这家企业人均产值只是10万，一年收入就是100万，至少资金缺口是20万以上，是亏本不盈利的。

简而言之，作为CTO或技术负责人，你带领技术团队把软件产品做出来了还不行，还得要配合公司通过软件直接或间接实现业务的增长和盈利。

关于研发团队的产能、产出和产效

结合近十年的研发管理经验，我的总结是，研发团队的产能是每个研发人员每天的工时记录，按小时计算，按有效的工作日计算。我们不能强制技术人员加班，但技术团队在公司宝贵的工作时间，这部分的资源和宝贵时间，我们应当充分利用和发挥它的价值。

而研发团队的产出，则是每天、每周、每月或每个版本的新需求、新功能的迭代和交付情况，包括产品功能点、交付质量、性能等，是构成可交付给最终用户使用的软件产品或系统。要结合用户体验、客户需求、市场趋势、公司管理需求、MVP、敏捷开发、技术架构等，利用现有的资源，更快更好更频繁进行持续交付，持续交付和递送有价值的软件产品和服务。

把软件产品做出来是第一步，接下来更重要的是把做好的软件交付给用户或客户使用，产生使用价值和服务价值，让软件这一产品成为能解决客户问题或提供价值的工具载体。配合企业运营和市场推广、BD、售前售后、客服等，促成交易、达成合作、客户成单、创造收入。

正如某家数据服务公司拉的大横幅所说的“冲刺9000万销售业绩目标！”。

下面结合YesDev研发协同工具，分享如何管理和提升研发产能、产出和产效。

研发产能的管理

研发产品的管理是基础的，没有太大的技术难度，也没有深奥的理论，但需要极强的执行力。

通过工时登记以及敏捷看板，你可以在线轻松管理、汇总、登记和分配任务，每个任务有TODO、DOING、DONE三个状态，以及工时评估，即预计需要多少小时，也就是我们日常所说的工时。

让团队成员每周按时登记工时，可以实现研发产能的统计、可视化，方便进行研发产能的调整、评估和计划。

例如，当有了工时评估，可以关联到项目，形成整个项目的整体工时评估，方便外包项目或内部项目的工时统计和报价。另外有了工时登记，也可以很清楚了解每位开发人员每天的工作情况和安排，方便及时调整。

此外，敏捷看板，也为个人、为团队、为项目组、为特定项目提供了很好的研发协同的依据和信息共享。

与此同时，结合放假调休的智能提醒和企业自定义配置（每家企业的单双休不尽相同），和每个成员的实时工时统计，可以更加直观、智能进行任务的分配和指派。

关于工时登记和研发产能，这里有几个经验总结。

1）任务登记越多，工时评估越细的成员，往往是最为活跃主动、更为高效的人员；

2）正常情况每周5天，共40小时，但除去开会上洗手间等，剩下有效的研发时间约32小时；

3）管理上要“抓大放小”，针对项目的工时和个人工时，重点抓工时评估最多的，二次确认是否合理或是否需要协助；

4）让一线开发人员自己评估工时，相信他们！

研发产出的提升

研发的产能，即工时登记，应该由技术负责人进行督促和管理，由一线开发人员自己评估和更新，管理者尽量不要做好人，帮下属来登记填写，任务指派除外。研发产能是受控制的，只要技术负责人坚持督促和汇总，肯定是能做到的。

接下来讨论的是研发的产出，也就是技术团队每周交付和上线的版本、新功能。

这时候，就需要多方面的关注、多团队的协同以及跨部门的沟通。最重要的源头在于需求。需求一方面要梳理，形成书面的需求文档；另一方面要进行需求评审，确保技术团队能够理解新的需求以及实现起来的技术方案；最后还要在需求评审后进行需求排期和跟进。

产品经理，要确保技术团队每周都有“活”干，都有需求在做。需求在堆积，有时候是好事，说明业务在迅速发展。如果真的暂时没有业务上的需求，这时技术负责人就要“趁机”安排进行重构优化、单元测试的补充、技术文档编写、内部技术分享、性能优化、团队建设、工具创新、技术调研和学习。

迭代良好的信号是，你会看到每周在合理的需求在排期，同时允许适当的变化和调整，每天会有按计划地发布上线，当你看到YesDev系统发出的每周需求汇总，可以及时知道当前的迭代状况和最新动态。

我见过有把需求当项目来做的团队，也遇到过一个人就可以做一个项目的优秀开发者。至于研发产出如何提升，一方面在于技术人员、开发工程师本身的专业技能以及他本人的时间投入、意向和和主动性；另一方面，也依赖于团队不同项目角色的通力配合和频繁协作。

研发产效的本质

一直在强调加班的，不是持续健康的办公氛围；一直在自我打鸡血，也不一定就有狼性文化。

作为计算专业出身的人，都在算法中学过最短路径、最优算法。我们可以想办法，一起努力把软件产品做出来，在更短时间内按满足客户需求和验收标准的系统研发并交付。但最终，这个软件赚钱了吗？它盈利了吗？甚至有人会买单吗？我们不得而知，或者说，“这不是我作为技术人员应该关心的问题。”

但我觉得，编程开发，会写代码，是我们掌握的一种专业技能，是一种赋予我们去创造价值的能力。在开发功能，进行业务开发时，我们应该更多站在用户的角度、站在公司的角度思考问题，这个需求重要吗？这个需求紧急吗？这个需求还有哪些点需要多考虑的？

打个比方，假如我要从广州开车去深圳，约100多公里的路程，我（作为用户）需要的是一条全程畅通无阻的高速公路，而不是40万吨的水泥（1公里高速公路要消耗水泥4000~12000吨）。

而通过研发成本核算，我们可以实时得到特定项目的收入、研发成本和ROI，有利于进行成本控制和风险识别。做外包，可别亏本了。