惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
T
The Blog of Author Tim Ferriss
博客园 - 司徒正美
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
有赞技术团队
有赞技术团队
量子位
S
SegmentFault 最新的问题
博客园 - 聂微东
博客园 - 【当耐特】
J
Java Code Geeks
美团技术团队
Hugging Face - Blog
Hugging Face - Blog
H
Help Net Security
V
V2EX
人人都是产品经理
人人都是产品经理
博客园 - Franky
罗磊的独立博客
Engineering at Meta
Engineering at Meta
A
About on SuperTechFans
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
酷 壳 – CoolShell
酷 壳 – CoolShell
云风的 BLOG
云风的 BLOG
Y
Y Combinator Blog
Apple Machine Learning Research
Apple Machine Learning Research

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
G端项目怎么了?为何好多IT民工不愿意做
平心而论 · 2024-04-05 · via 人人都是产品经理

C端产品大家都愿意做,毕竟成功了名声和钱都有了。B端产品做的人也不少,毕竟专业壁垒比较高有门槛。但G端产品的从业者寥寥无几,除了公司少的原因外,还有这四个因素。

可能还有些童鞋不太清楚什么是G端产品,其实也可以理解是B端产品的一个分支,和B端产品类似。但G端产品服务对象不一样,主要为政府或事业单位开发的产品或服务,因为服务的群体的一些特殊性,因而独立出来的一个名称:G端(就是Government政府的意思)。

再来科普一下G端的相关服务范围,主要分为3类:

  1. 公共服务类,就是服务全国或某一地方民众的公共服务类。比如前几年疫情时大家使用的粤康码功能、大家使用的12306购票网站、还有面向深圳的APP:I深圳 、粤商通,这是典型的公共服务类。
  2. 内部服务类, 不对外服务的,主要服务政府或事业单位内部人员使用的系统。比如内部OA或办公类的系统,我之前在中广核智慧工地的一个比较宠大的内部系统,这是属于内部服务系统。
  3. 行业监管类,主要起到对各行业的监管效果。我做过对金融行业7+4机构的监管平台,这是面向金融行业的一个监管项目。

为什么有很多人(主要指IT行内人员)不愿意做G端项目的乙方角色,我最近几年都是服务G端项目产品,以上三个类型都做过,相对来说最好做的应该是行业监管类,最难的是内部服务类。主要如下几点:

一、需求经常变动

如果你负责的G端项目是偏向内部服务类的项目,那需求变动是常事,为何呢?因为内部服务类的项目系统经常有人在用。有人使用就会有优化,即使立项文档中有写明功能范围也无济于事,因为业务部门只在乎实际工作中实用的内容,对于立项文档来说是没用的。他们也从来不会看这个,主要原因是他们不是签合同的审计人员。所以哪怕是他们之前提的需求也会赖账。

很多需求功能上个月刚确定好,上线后发现不对,又得改需求,小改还好,有些甚至大改。主流程都变动了,而对于插在中间的产品人员真是两头受难,既要忙着应对客户,还得应对研发人员的冷嘲热讽。

如果你想和客户他们据理力争,几乎是没啥用,而且可能会影响后期的合作。那怎么办? 我们能做的就是把合同外的功能点、工时备份好,到时候和他们核对成本。

二、需求沟通成本大

G端项目主要是面向政府或事业单位,提需求的人大多是编制以内的人,甚至大多数人不太懂IT知识,很多时候随意一两句话的需求,也不会给你文字上的信息,只是口头描述,很多比较抽象,如果你不太懂业务知识,基本不太可能胜任任这个岗位。所以为什么现在越来越多的公司招聘产品岗位时,必需要求同行同岗位。

在需求沟通时,因为他们没有相关知识,需求随意提,要不就直接按XX这样做,如果你说做不到,他会说XX都能做,为什么你们就不能做。其实真实情况不是不能做,是因为项目成本有限,这个成本问题需要考虑好。不是他们提什么就能做什么。

比如我之前在某事业单位做的一个智慧工地的项目,那边靠海手机几乎没有信号,但是需要做设备巡检,怎么做?就是离线功能,先在本地上传数据,等有网络后自动上传到服务器。这个原理是成立的,但实际上实际有一定的难度。难在哪呢,一是成本问题二是技术实力有限

三、随叫随到,没有时间观念

G端项目的客户,多少有点官架子,作风有点偏向官僚主义,总觉得他们高高在上,你们乙方是他们的下属,是他们的服务对象。所以有事时习惯随叫必需随到,不能拖延,但是当他们在忙的时候,你有事情你找不到他们,座位上没人,电话也不接,这时候应该在开会,要不休假了,休假期间一般不会管工作上的事情。

什么叫没有时间观念?就是客户以主观角度来评判你的输出时间,比如和你需求沟通完,然后立马确定上线或输出时间,过几天向你要结果。他也不会关心你手头是否有其他任务,如果到时间你没有及时输出,轻则怼你,重则投诉你。此外周末和法定节假日要随时待命,因为有时候周末他们其他部门上班,需要项目或产品协调开发去解决BUG 。关键问题是G端项目文件好多部署在政务云端上,没法通过远程线上处理,需要到现场连接他们的网络才能写入脚本,然后确定无问题后再布置上线,因此客户现场需要有一个技术待命,我觉得挺难的。

四、输出要求高、数量多

前期我们说过G端项目有点形式主义,需要输出好多文档,包括PPT,还有原型,流程图。和甲方需求沟通时,多是需要输出流程图,或比较高保真的原型,这样相对沟通成本低一些,但这些都是需要制作出相对好看的原型,这些太费时间和精力。

当然还有其他问题,比如答辨,交付,培训等,总的来说G端比B、C端项目要难做一些。随着国家布局数字化战略,加上鸿蒙系统问世,我相信未来G端的项目需求可能会越来越多。

作者:平心而论,公众号:书海智慧之窗

本文由 @平心而论 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。