当项目预算紧张、利润空间微薄甚至出现亏损时，技术团队是否应该考虑成本？本文通过两个实际案例，探讨了技术团队在项目中考虑成本的必要性、成本控制的意义以及如何在技术实施过程中平衡成本与交付质量，为项目管理提供了新的视角和思考方向。

思考场景：

当前A项目是做数转服务，预算不高，且有集成商对缝抽成，到我们手中没有盈利空间，且技术初步评估会超预算（约45w），最终到我司成交额约20w。考虑到标杆、参观、资源等战略角度，总经理特批承接项目。

这个项目工期非常紧、并且对甲方来说我们是用集成商的名义实施，还增加了和集成商对接的成本支出。增加集成商以后还增加了许多沟通成本，在这种情况下，公司考虑已经赔本干了，希望从其他维度节省一些成本，对项目组的出差控制十分严格，而人不至现场导致客户信任度下滑，又和乙方再生龃龉。因此这个项目干得是怨声载道。

从商务角度：这个项目如果能一炮打响，能极大程度增加在该地区的市场影响力，并且能借到客户的资源开拓新的机会。

从技术角度：我们为这个项目付出的足够多，加班加点完成工作内容，就这样干，甲方甲方不满意说我不来现场，领导领导不满意说我成本用得太多，那要我怎么样呢？最终成交额没有成本高是我的原因吗？不如以后成交额什么样就不关我事，我就按成本干，反正赚了没我们的，赔了倒要压榨我们。

天天嚷嚷就20w的项目，成本这样能控制住吗？就这还不得赔死？技术十万分的困惑：我也没给你报20w啊，报价我报了45w，签了20w回头就拿20w要求我，那我死也干不出来啊。

而同时在接触的其他项目让A项目显得格外有戏剧性，对比冲突强烈：B项目是2期的项目，1期已经交付完毕，客户满意度很高并决定合作二期领导评估客户愿意支付160w，然后要有20%的利润，那就成本要控制在128万。其中要收20万服务咨询费，剩下了108万，还要减去他们提前做的和去需求调研花的费用（220人天*2000），这样子就剩下64万。然后这64万还要按照2000/天去估工时，这样子，技术就只能再报300多人天的工作。然后拿这个功能清单去跟客户聊。结果十分离谱，技术无法理解：都用2000/天去报价了，为什么还有20%的利润。然后还有20万服务费也不知道是啥。成本到底在哪里？哪部分才是真的成本？我们研发要参考的又是什么成本？

B 端产品经理如何快速成长？

产品与业务架构主要是将整个业务工作流进行分层，梳理，然后抽象出一个个需求，将业务需求与产品合情合理的映射起来，最终使业务数据在产品中流动，执行，记录，使用。

查看详情 >

这样看，新客户赔本赚不来吆喝，老客户往死里宰往死里得罪，这样的项目怎么干呢，而在项目实施的时候，技术真的需要考虑成本吗？考虑成本的意义在哪里呢？

在我最开始受到的项目管理的理念的教育中，项目和产品最根本的区别就是成本的引入，对于一个产品来说，我们通常以需求、业务和用户体验为核心，而做项目则是在规定的时间范围内尽可能用所有的资源完成项目需求内的工作任务。

所以产品的概念在很多时候是一种乌托邦的状态，如果我们预设资源无限，我们当然愿意在我们聚焦的产品上精益求精，甚至不惜吹毛求疵。

但现实是资源是有限的，需求是无限的，在产品管理中，一个经营中的需求池往往是需求海，不管投入多少的开发资源，我们似乎都会犹嫌不足，对上无边无际的需求显得捉襟见肘。面对如何取舍，如何设定优先还是排后的决策时，产品第一次触及到了成本这个概念——它来自ROI投入产出比。

当产品学着衡量这个需求要付出多少、又会带来多少的收益时（虽然有时有些问题并不能使用ROI进行解决，或者不能用具体的金钱和数值去量化收益，但这个概念的引入无疑是对需求分析的一种通用解法），已经开始用自己的方式去衡量成本。

项目往往更加实际、更加落地、也就更加琐碎。我在最初几年投入工作的时候，我对成本的感知是“人天”——也就是我需要用多少人天完成需求清单中所罗列的需求内容。这个时候我的问题复杂度升级了一点，但也尚且应对得过来，在执行项目的产品角色中，我要警惕的是需求的边际蔓延和计划与实际的进度差异。

在我最初工作的时候，我曾扮演过一个小H5项目的项目经理兼产品经理，一个5个人的小团队、一个一周的工作任务，一套简单的充电流程页面，评估需求内容、设计需求页面和功能、需求传递、进入开发并每日站会，最开始一切都顺利得不可思议，甚至对预估的时间还留有余地1.5天左右，谨慎的我并没有对开发说明预估时间在交期之前的事情，很快，在当时领导N姐的提示下，我得知了一个此前遗漏的功能点，经过评估研测需要三天左右完成，职场3周新人的我当即出了一身冷汗。

当时的我并不完全理解这种恐惧，只觉大事不妙。现在我的明白了，是因为当时的我没有评估项目风险、也没有承担项目失败的后果的能力，我的恐惧不仅仅是出于对失败的恐惧，还有失败后面跟紧随的未知的恐惧。

我立刻汇报了这件事，求助N姐，N姐却问我打算如何处理，后来这件事通过和其他项目组借调资源、和研测成员商量阶段性提测（感谢当时的前端C哥、L哥、后端L哥、测试P哥对稚嫩的我的全力配合和包容）、原预留空余时间打满的多角度配合下艰难地按时交付了这个项目，交付完成后我松了一口气，半年内都心有余悸不敢碰项目。

如今回看当时的项目正好触发了项目中最常踩雷的点，而我的实现方式误打误撞也正是一套极佳的解决方案。

问题：范围蔓延，延期风险。

解决方案：

1. 站会每日控制进度；
2. 对外交期和内部交期中间留容错空间；
3. 发现问题第一时间汇报风险并且申请资源协调解决；
4. 协调外部资源的同时内部也通过灵活调整计划的方式进行一定程度的计划优化。

再后来，我在项目中摸打滚打逐渐变多，渐渐开始接手对外的技术报价时，我遇到了“成本”的另一面。

在内部的项目管理中，“成本”是一个虚拟围栏，也是不断流逝的资源池，我每使用掉一天，成本就流失掉一天，在这个范围内，就代表着安全，出了范围，就代表着危险，它如此切实地标记、填充在每一个人的每一天。

而外部的技术报价，“成本”是一个黑匣，报价时我无需考虑是由谁来完成，也不用在意实施的具体方案，我面对着客户的需求清单，评估着：“这个功能有一套常规的增删改查，查看页面中有一部分需要太特殊实现，报前端4，后端3”、“这个报表页前1后1”……按照人天再乘上标准人工成本，然后求和，总体再增补核算运营或者成本项目分摊部分，好，完成，报价。

但是报价很少一次性成功的，常常要修改反复很多次，商务拿到报价，修修改改，呈递到客户处，客户大摇其头，商务为难，咬咬牙小手一挥写下一个价格，客户仍然摇头，商务只好颠颠跑回来，求助技术是否仍有降价空间。在这个过程中，就会产出多个报价，其中最有价值的就是最终成交价和技术成本价。显然，在控制项目管理过程中，我们会使用和参考的是成本价。

成本价是怎么个报法，以及成本价要怎么使用，大体上所有公司大差不差，但是细节的执行上显然极大程度地影响了技术以及实施后续的操作空间。从我最初的项目管理尝试中就可以感受到成本对于技术的限制禁锢程度之重。

一般公司会将商务报价部分和技术报价部分隔离，技术无需了解对外这个产品卖了多少钱，而商务也不需要了解这个产品公司的技术成本是多少。从哪一步开始隔离——这是第一个分歧点。扁平一点的，技术报价后直接按照一定规则涨幅——这里涨幅涨的就是公司经营的成本分摊，给到商务后商务再进行一定程度的涨幅——这里的涨幅就是公司的盈利空间。制度再完善一些、业务再复杂一些的情况下，公司组织还需要分化出采购、财务以及成本部门，不能本公司自产销的、本公司产能不足需要外协或者采购的成本价格交给采购部门去报，而公司的运营成本则交给财务部门去精算和预估。

在这种模式下，技术的成本及范围都是自身认可的，后续在执行和实施的时候也具有较高的置信度——毕竟估算的时候是自己评估的，如果超出范围没有评估到，那也是技术应该精进和改进的地方。而商务在成本之上做的文章无论如何也不应该动摇到技术成本以下，更不能以经过特审的战略性成本当做技术成本要求技术完成项目范围。

成本的意义再哪一个环节出现，又扮演着什么样的角色，这才是公司管理应该思考的内容吧。