论产品和项目

为什么要写这个话题呢,其实也不知道该怎么写,但是今天我却想跟大家探讨一下这个话题,其实话题是这样引起的,今天老板问我最近做了那些东西,然后我给他仔细的叙述了一遍,在我叙述的过程中老板这样问了我一句,在这个医院的项目中已经改了,为什么要在另一个项目中改,还有,为什么这个医院可以直接打印,单位这个却不能直接打印要重新设计。然后他我们做的是产品,不是就一个工程吗?我瞬间无语。话题就是这样。

那么我先说说我对产品和项目的理解吧,首先是产品,我的理解是可以在同类行业中通用的一个应用软件,稍作改动或者说是后台配置就可以使用运行的。不需要做大规模的程序修改。这就是产品。产品是在大量的项目中提取和综合通用的东西,然后做整理重新设计。虽然有了大的改动,但是对以后其他的项目方便 了。项目呢,项目是针对一个单位,一个方面做针对性的开发设计,有很强的针对性和指向性。现在我所在的城市,同一行业,不同单位,差异性特别大,而且又是新打造的产品,很多都没能及时扩展,虽然很多地方已经提前做了扩展设置,但是前端时间说一家医院要上而且把需求都给拿回来,但是和现在的产品差距很大,很多地方需要修改。所有独立出来一个版本,另一家医院运行过程出出现一些小的bug或者优化上的改动,在这个里面也需要修改。而且是比较老的版本独立出来的,很多需要去加,改了那个还要改这个,很多优化的地方在一个里面还不只一处地方。老板说就那么几个问题,改一周,那么他怎不去说一次动两个版本的东西呢,一个问题改一处一天就完了,大家说呢,难点的一个用一天吧,那也很快的。但是不止一个地方做改动。很多地方要去找。还说我最近工作状态差,工资就不说了,咱是打工的,老板给不了多少,憋气,一个人干3个人的活。有时候改的这个项目的东西,他说来,看看这个问题。不是我负责的也会叫过去。我是一个人,不是神。我没有分身术。

还是言归正传,产品是多个项目积累整合的,通用的。项目是针对的,我做过的项目不少,现场改东西也不少在少数,经常做救火队员。产品也做个几个,虽然不多,但是也知道其它的一些东西。重头打造的产品虽然这个是第二个,曾经也经历过一次。如果说要打造一个好的产品,我估计的时间是至少10年完全成型,要在短期成品完全不可能,除非那就是个项目。项目给出详细的需求,做好设计方案之后,几个月就可以搞定,剩下的就是后期的修改和新的需求。也只是在这个项目适用,产品却以一个例子为蓝本开发,做扩展,能在几个地方通用就很不错了。今天我认了,也忍了。下次,不会有下次了。

其实我写这个是想让大家给说说一个产品怎么能快速打造出来。

时间: 2024-10-13 15:59:21

论产品和项目的相关文章

人人都是产品经理-项目的坎坷一生

项目的坎坷一生 从产品到项目 一切从kickoff开始即立项 关键的青春期,又见需求 成长,一步一个脚印,配合完成项目的发布 山寨级项目管理,从流程,文档,敏捷三方面讲项目管理 物竞天择适者生存,讲了一些作者亲身经历的例子

我经历过的失败产品和项目(七):定位模糊的面向移动互联网的视频通话应用

背景 2011年下半年的时候,随着移动互联网的普及,移动端的应用越来越多,移动互联网模式初现,强烈的冲击着我们这家做通信公司.作为专业做视频的公司,公司老板决定在移动互联网上面试下水,对于产品只说了这么一句话:大家看下tango,用户只需要在我们的APP上输入手机号,收到短信,就能注册,登录就能免费用我们的视频通话功能,我们先做着,等用户量起来了,我们再做其他想法. 就这样,我们启动了这个项目. 描述 由于我之前刚刚兼任了移动终端组的负责人(从媒体服务器负责人兼任移动终端组负责人,跨度是很大的)

程序猿职业规划随感:做产品还是项目?

作者:易仔阿克(李福东)    时间:2014年8月1日 对于程序猿的职业,由于新技术总是不断出现,软件工具版本也在不断更新,注定程序猿的生活要拥抱变化,另一方面,中国的程序猿也注定具备中国特色:较短的职业生命周期和缺少计划性的没有尽头的加班加点.虽然有人看见程序猿偶尔挣的多些羡慕,但我感觉我国的程序猿大多是靠辛苦靠加班挣来的,性价比一般般. 不过,对于大多数人来说,做不做程序猿也不是自己说了算,尤其是那些做了多年程序的人选择余地就更小了.那么,程序猿怎样选择工作发展方向呢?笔者曾经在私企.外企

面试如何谈产品和项目? -转

谈一下你做的一个产品或者项目 这个问题其实不难回答,我之前经常会说,无论是你回答什么样的问题,其实都要从以下几点去努力做出合适的回答 核心7点 任务发生的背景 面对的目标用户 我们针对的场景 用户发生的问题或需求 在这个过程中做了哪些事情 达成了什么样的量化结果 最后有哪些沉淀和收获 这些点都是我们回答这个问题的核心套路, 其实这个和结构化面试的STAR原则,即Situation(情景).Task(任务).Action(行动)和Result(结果)非常接近,但是要更加细,更加偏向于我们通过案例来

产品和项目区别

1. 对质量要求 做项目的第一要求是在要求的时间内开发出满足客户需求的软件,它的第一准则是客户永远是对的,开发者必须按客户要求的做,但是因为客户提出的要求往 往是发散的.弱逻辑的.非系统的,所以开发出的软件需要很多硬编码,再加上时间紧迫,不能对已经开发出来的模块进行必要的重构,项目最终越来越难以维护, 性能越来越差. 而做产品则会很注重质量,第一准则是开发出比其他同类产品更好用,更快的系统,当发现某模块的架构不合理时,能够花人力和时间去重构它,最终使产品 越来越快,越来越好用. 2. 团队构成不

我经历过的失败产品和项目(六):体验很差的视频会议系统

背景 这个产品从07开始做,到13年基本停止开发,持续了6年时间.当时上这个,主要是我们公司的媒体服务器专注视频,而视频的应用,但是也就视频会议的应用比较广泛. 所以在07年的时候,招了几个兄弟,开始基于媒体服务器,开发会议服务器 描述 公司那几年,在视频会议上面投入的精力是最多的,每年至少有20人的投入,主要分为4个小组:硬件平台组.媒体服务器组.应用服务器组.测试组,整个产品由研发主管领导.主要里程碑点: 08年落下第一单,河南网通,小几百万的单子 09年完成中移动研究院的测试: 10年尝试

我经历过的失败的产品和项目(五):没有前途的视频呼叫中心

背景 也是在3G大环境下,公司在视频领域尝试的一种业务形态. 大概就在10年的时候,三大运营商也都在做视频呼叫中心的业务评估,不过基本属于规范制定中,其中中联通走的比较快,而且他们的视频呼叫中心最终也上线了(但业务一直起不来),也有一些传统的语音呼叫中心厂家在尝试做这方面的工作.我们在经过一段时间的评估和考察之后,在2010年初的时候,决定和一个Avaya和思科呼叫中心的代理商合作,启动视频呼叫中心的项目,由我来领导这个项目组. 描述 产品比较明确,就是在Avaya和Cisco的语音呼叫中心的基

我经历过的失败产品和项目(四):没有落单的多媒体彩铃媒体服务器

背景 2009年国家发布3G牌照,一时间运营商纷纷上线视频业务.对于我们这个专业做视频硬件服务器的公司来说,正好赶上了大环境,也是纷纷开始开发各类的视频业务,多媒体彩铃是其中一款. 我们公司07年成立,之前一直处于开发硬件的媒体服务器阶段,该服务器只是提供基础的音视频处理能力,其在功耗.性能和体积上面,再国内外都处于领先. 但我们在具体的业务层面从来没有接触过,2009年底的时候正好有家国内比较大的运营商业务提供商找到我们,他们已有的彩铃产品需要添加视频业务,升级成多媒体彩铃.底层的媒体处理这块

我经历过的失败产品和项目(九):综述

分析这么多产品,我们从头来看,可以得出如下: 产品启动的太草率,产品结束的太草率 产品不聚焦 不聚焦,导致2个问题: 公司的研发和技术没有聚焦,产品无法越做越完善.做研发的清楚,产品出来DMEO很容易,也很快:但完善和优化的过程是需要较长时间的,甚至是无止境的,而且如果没有实际的项目和用户驱动,很多问题都是无法暴露出来的 市场也无法聚焦.市场的能力和市场的关系网也是一个逐渐积累的过程,如果行业经常换.大方向经常换,市场销售团队也是无所适从. 一个好的循环应该如下:公司层面根据公司现有能力,决策1