从项目、产品、运营型看发展

上一篇 / 下一篇  2011-12-01 20:34:05 / 个人分类:领域发展与思考

序言:自己身处通信界一段时间,偶然网上看到一些公司的正积极的转型,突然将公司的发展对照着个人的发展以及自己自动化测试工作的进展,深有感悟,也许:一个怎样的公司能持续发展,渐渐在市场上占有一席之地;一个怎样的个人才能持续进步,渐渐的在人群稍有突显;一个怎么的自动化测试策略才能持续提高,渐渐在软件中真正起到至关重要的角色。这都是需要思考的吧。现在就说说自己一点认知吧。

 

一、从项目、产品、运营看公司的发展

首先声明,这些都是我听到的、查阅的再加自己的一点感悟,因为视野局限性,不一定适用,但却是值得去感悟一下;

在通信业界,公司分为三类,项目型公司、产品型公司以及运营型公司;

1、 项目型公司,项目型公司指那些业务是以项目运作方式为主的公司,其针对不同的客户需求提供不同的项目,排除公司规模性的方面,据说这种公司盈利很辛苦,因为其针对每一个的需求就需要对应一个项目,这就是一个开发成本;然后需要对开发过的每一个项目进行维护,这就是一个维护成本。所以,每一个项目都会耗费大量的成本,成本越高,盈利越少。

这种项目型公司需要的是将其项目的技术或者框架进行抽象,使得其项目间能够共享、甚至可以将其满足一定需求的项目拓展成产品。

2、 产品型公司,即拥有一定产品型组织结构,针对一定市场有专门的产品线支撑。在通信界。很多设备提供商都属于这类,而产品型公司的追求向服务型公司转型,其服务型公司是以顾客的需求为中心、以产品为载体、为顾客提供端到端的完整服务,其利润总额,提供服务所创造的利润将占很大一部分;例如:看看大家总说的IBM,其Rational的软件产品,你会发现其主要介绍产品的方式是从能够提供的服务方向来介绍的,而其主要服务理念是为其打造一条完整的软件交付平台。

3、 运营型公司,在通信业界,其三大运行商就是属于运营型公司,其需要从网络角度知道网络运行状况,还需要从服务角度知道网络运行状况。此外,他们需要在提供多媒体服务和应用时有效利用网络资源。在通信业界,因为其特殊性,其运营型体制无可替代。但与通信界不同,互联网的特殊性又决定了一个个大型的运营型公司的兴起,他们以互联网资源为优势,打造了一系列的运营平台,提供给广大客户一个享受服务的通道。

 

二、从项目、产品、运营看个人的发展

也许很多人都有过的疑虑,我在这个公司所学的知识出了公司之后是否还能使用?到底如何建立我的核心竞争力?

1、 项目型个人,即只针对当前公司的状况而获得的技能,而等到了出了这个公司,还需要去学习新的技能。例如:做手工测试,只会对当前公司的产品进行黑盒测试,也许你可以针对这个产品的特性测试的很好,可以出了这个公司,这个技能就不一定适合与另外一个公司了。

2、 产品型个人,即拥有针对一定范围的行业或者公司而拥有的技能,例如:编程的技能、撰写测试用例的技能、性能测试的技能。为什么有一些知识面很广的人却没有竞争力,那是因为就如一个公司,他把市场铺的太大,他也无法去顾及其主要市场,所以一个人不断学习,然后针对其公司和行业需求,抽象出自己的核心竞争力即可。而什么样的核心竞争力,就需要自己对其需求的把握了。

3、 运营型个人,个人认为,此人是一个整合型的人才,也许很多人有疑问,为什么有的人不懂技术,却能位于很高的位置,那是因为他能利用好人力的资源,就像互联网中能利用好互联网资源一样,将其各人的优势进行整合,打造了一个运转的平台。

 

三、从项目、产品、运营看自动化测试的发展

从以后可以联系一下,自动化测试的发展

1、 项目型自动化测试;即脚本开发式,测试开发人员负责给不同测试的测试需求开发不同的脚本,这样就导致了测试开发人员总需要帮助测试人员维护脚本,而且由于开发效率不高,导致自动化测试效果缓慢。

2、 产品型自动化测试,即开发了一系列的自动化测试框架与自动化测试工具,测试人员可以应用这些框架和工具去自己进行自动化测试,测试开发人员只对这些框架与工具负责。

3、 运营型自动化测试,即一个整体的自动化测试平台,这需要与软件产品流程相结合,利用软件开发的资源,把握住软件开发的每一个过程,例如:现在流程的每日构建感觉就是这么一个概念吧。

 

总结:以上只是我的个人一些看法,同意或者不同意的都可以一起探讨,我觉得对与不对,都值得思考,思想碰撞才能提高自身的一些眼界吧。


TAG:

alice的个人空间 引用 删除 alice2003yf   /   2013-12-25 23:21:01
M +1
散步的SUN的个人空间 引用 删除 散步的SUN   /   2011-12-09 18:53:54
说的真好,我得向你多请教一下项目方面的知识了,在项目把控方面,我做的不是非常好
在自动化测试项目中,如何抽象确实是一个问题,只能尽量的分层,将共性进行抽象
原帖由rossini23于2011-12-02 12:17:34发表
“这种项目型公司需要的是将其项目的技术或者框架进行抽象,使得其项目间能够共享、甚至可以将其满足一定.
xin_晴的个人空间 引用 删除 xin_晴   /   2011-12-02 14:50:14
您好,我是51Testing软件测试网的编辑,您的本篇博文被推荐至51Testing软件测试网首页发表:http://www.51testing.com/html/76/n-249976.html
感谢您关注并支持51Testing博客,期待您更多的优秀原创博文。
文青山 引用 删除 wolaizhinidexin   /   2011-12-02 14:16:36
5
引用 删除 rossini23   /   2011-12-02 12:17:34
“这种项目型公司需要的是将其项目的技术或者框架进行抽象,使得其项目间能够共享、甚至可以将其满足一定需求的项目拓展成产品”,这个确实是,很多相似的项目会有一些组件、模块完全或者基本相同,如果每个项目从头开发一遍这些东西,造成很多资源上的浪费,这个现象在很多公司里确实很常见。IPD(集成产品开发)流程里把CBB(Common Building Block,公用构造模块)作为一项核心思想,可见重用性的重要性。
当自动化测试相似项目时,也会遇到重用的问题,包括测试逻辑层面重用、底层函数层面重用等。
测试逻辑层面重用,会遇到DUT控制方式、DUT规格、测试逻辑等方面的差异,需要一些抽象机制能够屏蔽这些差异。
底层函数层面重用,这个层面的相对容易一点。
 

评分:0

我来说两句

Open Toolbar