一段职场经历的总结1

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/angrysnail/article/details/82772078

今年是2018年,2011年中,我踏入了一段新的职场生涯,必须说,当时和所有的同事一样,都是带着对未来发展的憧憬走入了新的公司。公司不大,名字暂且隐去吧,姑且称之为GT吧。济南作为一个二线城市,软件业的发展相对来说还好,但也并不是好过南京,武汉之类的二线城市。所以,GT作为一家由海归学者创建的企业,老板也得了几个山东这边挺重要的Title,诸如泰山学者,千人计划等,所以也能从政府处得到许多政策上的扶持。在这一方面,做的还是挺好的,可能也是基于此吧,集中了一群有志于去搞一些新东西的年轻人(当时还算年轻人,呵呵,:-)),一起创业出发,但坦率说过程不顺,虽然我现在下车了,公司发展也算稍有起色,但总归是不孚众望吧。

我姑且从一个开发者的角度去总结一下,我们犯的错误吧,首先要说,不一定准确,毕竟我的主要角色还是研发人员,市场啊行业啊,这些方面的研究必然弱于老板们,所以我的总结更多的还是从技术角度去考虑,你们也算偏听一下吧,至于偏信与否,顺从各人的想法吧。

阶段一:

2011年左右的时候,大家处于一个执行力很强的阶段,持续了大概有2年左右的时间。这一阶段,大家有极高的意愿去做老板交待的技术工作,即使心存疑虑,也会不折不扣的执行。其实这对一个创业公司来说是好事,有时听从一个人的指令,比大家讨论来讨论去不知所措,互相质疑要强的多,但前题还是,这一个人的指令要准确且有前瞻信。

我分管公司产品的高可视化的研发,可算作公司产品的重要亮点模块。首先,领导的意思还是有意用svg的技术来实现,但结合具体的情况,还是说服他们去考虑直接基于swing的g2d来进行处理,毕竟在swing里,svg也是借助于g2d来实现渲染的,而且我们有许多交互及动态操作在上面,生成svg再去渲染,不够直接效率也存在问题,而且svg在swing上的处理,api也不是太好用。这一块算少有的更改了领导的想法,效果还不错,至少当时这个细分领域没有做的比我们好的。

这个阶段,一个重要的决策失误出现了——许多想法没有去做市场印证,有闭门造车的嫌疑。这一点,是在公司全体大会上,我们作了检讨的。当时也有一些话头,要颠覆这个传统行业的领域,我们做的是新的东西,和传统的一些东西不一样。这种想法,现在想来还是有些孟浪了。因为对这个行业,我们能明显的感觉到,对大家来说,这是一个新的行业,即电力行业。在这个行业,几乎的有的从业公司,都软硬件一体的研发公司。但早期,公司错误的认为我们应该放弃不熟悉的硬件研发,集中全部精力于软件研发,借助于通用的硬件搭载我们的软件来组装我们的产品以售卖。这直接导致产品有严重硬伤,如果用软件去弥补硬件的工作,这决不是一个好招。所以当时在午饭的路上,我们几个研发的同事也进行了诸多讨论,同时鼓励有硬件经验的同事,上书陈情,但都被驳回了。产品成形后,与比较大的业内一家企业进行合作,产品的售价定在了80w,与一般客户设想差距很大,所以整体销售情况,不乐观。这三个问题,直接导致公司,第一次的低谷,几个很好的同事也是朋友离开了公司,:-(

阶段二:

随后,能感觉到,大家对老板的技术决定有了一些迟疑。举个栗子,曾经要给河南客户做个东西,工具类的作图软件。结果设计会后,结果是前面用swing,中间用上诸如hibernate,spring,再搭上一个mysql的数据库来存储图元间的连接关系以备随后的拓扑检查。同事也是好友,作了个把月,种种原因,无奈离开。从思路上,这种设计肯定是不合理,感觉上还是缺乏应用软件这个领域一些认识。所以,接手后,悄悄去除诸如数据库之类的东西,顺利完成,效果也不错。随后,为了考虑产品的小型化,我们进行了诸如windows平板,linux平板的尝试。这些尝试,从UI的角度都不是太可行,毕竟pc上的东西,原封不动放到平板上,肯定效果差之千里。在这一点上,感觉大家建议的力度不够,走了不少弯路。最后,公司还是上下一心,决定要做一个android平板产品,将我们的产品做一个彻底小型化。这需要勇气,一方面,前面没有进行硬件研发力量的积累,另一方面android的软件开发,也积累很少。但还是上下一心,做出这个决定,应该给大家点个赞。这一时期,公司也走出了第一个低谷,作了二次融资,整体还是向上走的。

阶段三:

坦率说,android的研发,还是有不少的波折,毕竟,在一些新领域的积累少。但上下一心,开发进度还是不错的。15年左右,一些app也是一个个的开发出来,每个周期都有进步。但技术上还是存在一个问题——缺乏一个统筹全局的架构人员。这句话,读者一定把重点放在“统筹全局”上了吧,其实我是希望大家放在“一个”上。这里的“一个”不一定是“一个人”,我们可以理解成是一个思路,或一个风格。其实前面产品也能感觉到,接口的定义经常是功能相关的同事就直接定了,没有一个人去统一把握一下,原因也很简单,大家水平相近,在职务上公司又非常提倡扁平化,所以形成了这种局面。在这一点上,能感觉到,团队是最复杂的,谁也不知道不同性格的人放在一起会有什么化学反应,所以大家都努力追逐性格平和一些的,能宽口径去适应不同性格同事的人,有利有弊吧,这个让人力专家去操心,我们在此不深表。书归正传,接口上的一致性,对一个系统影响很大,许多人不重视接口的设计,认为就是约定一下即可。其实,接口设计时要考虑几个事——边界情况怎么处理,异常情况如何应对,细分功能在哪边实现等。如果没有一个统一的设计,那就成了,研发人员谁强势谁来决定设计或者谁工作负荷少,谁就在这里多干点,细分功能就由你实现,不考虑合理性。其实有些事情,并不是非黑即白,我们时刻要努力去做到最合理,只有这样才能保证系统的最优化运行,否则这里将就一下,那里敷衍一点,最终的系统就是纸糊的,不稳定。
一些交流问题,也逐渐暴露,由于上下层开发,不相统属,经常一个棘手问题,好久解决不了。发送数据,有丢包现象,这种非必现的问题,是软件最大的痛点,排查起来很难。又涉及到好几个人开发的功能,所以出现一个情况是,大家都去赶新功能,这些问题都潜意识的优先级放低了,都不认为是自己的问题。最终还是FPGA的同事,潜下心来,找到问题,通过调整系统的参数解决了这种问题。其实软件这个行业,应对这种问题是有成法的,就是封闭相关人等,集中精力到一个点上来解决这个问题,这个问题还是困了大家很久,感觉还是力度不够,自己有责任。另一个问题是,被竞争对手影响了开发节奏,有一段时间,能明显感觉开发要先稳一下,将一些基本的功能,深走一下,稳定下来,以支撑我们上层的一些高级功能,但竞争对手的高级功能接连推出,我们这边只能是去对拼,结果造成产品的不稳定,这特别让人无奈,缓也不是急也不行,毕竟这不仅是一个技术问题,也是一个市场问题,所以协调上还是有一些问题。
硬件上,由于大家的经验,还是有一些内伤,如散热,功耗等,不是太乐观。
但总体,从产品形态上,功能等,我们的产品还是有优势的。市场推广的力度也很大,听说融资的钱也花了不少,但市场及效果却一直不好。感觉上,还是产品形态的变化不是一个质变,竞争对手已经于几年前推出了小型化产品,客户已经认可了他们,我们再想朝里挤,需要拿出一些雷霆手段,但整体市场推广还是老路子,试用——反馈——购买/返回。太过平和了,但还是花了很多钱。

随后还有一些新的东西该写,先写到这里吧,改天有空再写,写的有些乱,想到哪里写哪里,组织上差点,多担待。。

猜你喜欢

转载自blog.csdn.net/angrysnail/article/details/82772078