这是一个创建于 190 天前的主题，其中的信息可能已经有所发展或是发生改变。
楼主进了一新公司，该公司目前向扩下规模，从哪些维度分析比较好。做的 tob 模式，原先是到每家单位去部署，现在是想集中到云上，做 saas 多租户模式，根据业务线评估吗？譬如一条业务线需要 2 个后端，一个前端，一个测试，一个产品之类的？
 | 1 mumbler 190 天前 过去的经验已经过时了，现在有 AI ，1-2 个人足够负责一条业务线了 |
 | 3 renmu 190 天前 via Android 一楼说得对，让前端兼职 ui ，后端兼职产品，两人再当当测试，什么你说做不了，那你们不符合新时代 ai 人才啊 |
 | 6 angeni 190 天前  31 真 tm 反感那些无脑吹 AI 的傻逼 |
 | 7 joynvda 190 天前 标准是按照功能点 FP 估算。需求转化为多少个功能点，然后估算前后端分工比例，完成能力。 有基于经验和严格安装标准的做法。通常，都是用前者(拍脑袋)。:) AI 不过是把工作效率提升而已。 |
 | 8 wusheng0 190 天前 via Android 很烦那种说啥都扯 AI ，众人皆醉我独醒 以前负责不了业务线的，给他 1000 个 AI 也负责不了。 之前负责的，什么资源哪方面配合，1 个 AI 全代替了是痴人说梦。 |
 | 10 leegradyllljjjj 190 天前 tob 的业务一般项目配置是售前 1 人，后端全栈 1 人，测试 1 或 0 人，实施兼项目经理 1 人 豪华级项目一般是产品&需求 1~2 人，架构师 1 人，后端 3~4 人，前端 1~2 人，运维&DBA1 人，项目经理 2~3 人，测试 1-2 人 |
 | 11 4UyQY0ETgHMs77X8 190 天前 @mumbler #5 ai 知道人怎么想的怎么控制人吗？ ai 知道多少社会共同约定的潜规则？ ai 很了解产品吗知道怎么转化吗？ AI 不是万能的，起码在关键时刻人类社会的无痕迹约定比摆在明面上的多得多 |
| 12 4UyQY0ETgHMs77X8 190 天前 产品、后端、架构、前端、测试、UI\UE\UX 、运维、运营 按业务需求分割安排适量的人，一般前端少，但我司业务前端比后端基本上 1：1 所以业务不同配比也不同，也和人业务能力有关 |
 | 13 SageXiong 190 天前 有 v 友 说了 基于功能点 FP 的方法，的确是软件定制行业内比较有数据依据的一种方法，不过不一定适用。FP 针对软件定制项目的数据是比较全的，但是每个公司的团队划分，就缺少依据了。我个人的经验是看 ROI ，当新招 1 个人的成本能用新的业务完全覆盖的时候，就可以考虑新增 1 个岗位。团队规模的扩展，按部就班 一个一个的来，别急。很多都是盲目扩张规模，导致入不敷出，最后崩盘的。 |
 | 14 littlecreek 190 天前 @angeni 讨厌的是这帮人只负责吹, 吹完让别人做. 如果他们吹完自己靠 AI 搞出来, 我也敬他是条汉子. |
 | 17 chihiro2014 190 天前 拉 excel 排工时，分析难点，然后就知道需要多少了。AI 最多也就能辅助 30%，剩下再怎么样都得靠人力去堆。遇上不想干活的时候，AI 没人用，一样没进度 |
 | 19 liang723 OP @chihiro2014 问题是新业务，在原有的系统上重构。 |
 | 21 GuLuDaDuiZhang 190 天前 只说研发团队的话，个人感觉主要看需求开发成本、发版速度，如果需求都是各种大功能或者大改开发起来很耗时，那为了保障按时发版要的开发肯定多，例如后端业务逻辑改的多就多加几个后端。发版速度同理，定制多东西要的急，要求开发快，自然要的人也多，还有就是在此基础上最好加点人力冗余，可以临时分出来对付突发的现场问题也不影响版本进度，资本一点就不需要冗余，让手下多幸苦下，但可能还是会影响进度。 然后产品测试，都要 1 个，基本是够了，但不能没有。其中要说下的是测试也是有必要的，研发自测质量难以去竞标，他们很容易想当然的我是这么实现的、我认为是这样的，所以这样的效果逻辑没问题。需要有测试去和他们撕逼，多发现点问题，所以测试起码还是要有一个。除非你的业务是非常技术向的东西，找能测这块的测试很贵，那就多加个研发让研发多点时间自测了。 有闲钱就多加点研发人力加快开发速度，或者加个交互设计优化下使用体验，tob 业务起来后各种定制版本多，一个测试测不过来，到时候就要多加点测试。 总的大致就是一条新业务线，起步需要 1 个后端，1 个前端，1 个测试，1 个产品，后端多就多加 1 个后端，前端页面改的多就多加 1 个前端，一般会是后端要的人多一点，例如 2 后端 1 前端，5 后端 2 前端这样子，具体加多少人真就得领导们判断了，不急的话可以一点点往上加，找到成本和效率都合适的组合，或者大集团内部能协调人力的话，起步先抽调 6 、7 人过来快速搞个成熟版本，后面就留一点人维护迭代就行了。 其实 tob 还有个非常关键的就是售前，销售那些人，能把屎一样的产品卖出去让客户吃下去我觉得是真 nb ，都怀疑是和甲方拍板的商量好了吃回扣。嘛，不过这个也得看具体的产品业务，有些确实要求要有点产品力。 |
| 22 liang723 OP @GuLuDaDuiZhang 很中肯的建议 |
 | 23 davidoff567 189 天前 看评论区 AI 神棍闻到味儿就过来了，他们想的是招一个能接受初级工资的人，干前端、后端、UI 、测试 4 个工种的“蒙眼拉磨驴”，资本家都比他们仁慈点 |
| 24 SageXiong 189 天前 @liang723 产品的产出是按团队核算效能的，你不可能量化到每个人。再者，你量化的目的是为了啥？软件开发不是工厂计件，可以有经验曲线来估算，颗粒度拆到这么细，管理成本也是成本，沟通成本也是成本。最后都想量化，最后就都量化不出来。 只是想配人的话 @GuLuDaDuiZhang 说得算是比较中肯的了，一般公司按这个方式来问题不大，本质就是水多了加面，面多了加水的问题。不过，你要是想做公司或者团队的 绩效度量 框架，然后来做运营成本的管理，那就是另外一回事了。 |
 | 25 dododada 188 天前 资源池啊，同样的人，按项目进度抽调，统一管理，你一个客户几个人，客户丢了这几个人去哪儿 |
| 27 dododada 175 天前 @liang723 项目管理有所谓的矩阵管理，就是条块管理。 项目有多个，每个项目有自己的进度管控；前端后端 UI 实施什么的，每个人都有多个项目，因为每个项目的侧重不一样嘛，所以同一个项目，有的忙有的闲。 我们一般是先评估项目要哪些资源，然后做工时评估，再报给项管进行项目排期，排期相对宽松，也相对粗糙； 每个项目的负责人根据优先级评估自己的项目进度； 每个开发也根据优先级评估自己的开发进度； 测试团队、数据团队、算法团队是共用的，因为资源相对集中； 产品经理有自己的团队； 其他杂活儿是项目经理的事儿。 当进度受限，有人喊不行的时候，评估一下受限节点，看受限的部分是可以分流还是真的忙不过来，再考虑加人了； 其实产品怎么样，无所谓的，上面那个兄弟说佩服售前，其实售前演示的东西相当漂亮，客户收到的东西看起来也很漂亮的，但是里子就靠保质期保障，多一天都不要想； tob 有个验收环节，所有没有写明的验收内容，后面都是要收费的，和保险一样；至于质量和维保，很大程度看老板的口碑和做百年老店的决心 |
Select Language