谁动了我的产品

2014年3月中旬离开了自己奋斗三年的公司,这是一家海关政府公司,三年里无论是做项目需求分析、项目开发、项目测试、项目上线实施、项目上线跟踪、收集反馈、做项目版本修改,我和我的团队都在一个有非常明确目标、有非常明确思路的过程中,大家齐头并进,团结一致的去为了满足客户需求而奋斗着(当然也是在为工资奋斗着,哈哈!)。对于项目中的每个环节,我的项目经理是一个资深海关业务项目的开发人员,团队中一个决策的关键人物,对于技术的把关、业务的把关、我们都是需要向他汇报,同时也是问题解决的关键者,在这个团队中我们有3个开发业务后台(系统交互)、4个开发业务前台(c/s界面) 两个领导分别把关后台和前台,当年我们开发人员内部也是经常交流和盘问对方的状况,谈不上结对编程,但也是每周会有个内部例会来把我开发进度、问题等。对于这个状态3年里一直贯彻和执行着,所以项目非常有效的进展并最终上线,一个历时开发1年多的项目终于交付客户使用也是我成长和锻炼最为开心的一年。

来开这家公司后,我进入一家依托SAP B1做软件代理开发的公司,起初对于这个还是模糊至极,但是后来发搜集了好多SAP的资料和新闻后顿时觉得要有很多新的技术挑战和好玩的东西来等着你。然而后来发现我错了,进入公司4个月,我决定今天总结下这5个月了自己犯过的一些错误和看法来提供给博友们希望大家欢迎讨论。

我是3月底进入这家公司,公司第一天就赶上SH的一个同事来讲我们开发的东西顿时觉得有点小激动,开始介绍例会内容时,他的定位是我们要开发一个产品(待会分析下和项目的不同),这时我们是3个人,我(激进派、追问派(后来发现这样不好,不利于产品开发))、一个架构师(学术派、理论派)、一个开发(懒散派、表象派),对于这位演讲的人提的需求我简单描述下如图

对于这个需求简单描述下,因为不能透露更多,但是从这个需求中分析,我们的使用客户是面向不区分语言、不区分人员机构、不区分机构人员组成结构、不区分机构人员的操作行为的,因为就是什么都要灵活配置。开始我觉得不太可能,但是我看到SAP B1之后发现原来是有这个可能,好吧下面轮到我们技术人员了,描述下我这个苦逼技术人员的开发历程。

我们的产品是一个基于B/S Web的项目,对于这点呢,我主导了项目解决方案的主要搭架(不是有架构师么?我只能呵呵了)解决方案采用了还是比较装逼的三层吧,业务逻辑层,视图层、数据访问层、对于业务层和试图层提取一个抽象工厂来提供视图层所需业务类的调拨,对于几个比较关键的技术点是界面语言切换问题,我大概用了一周多时间开发完(第一次么,都没有经验你懂得 哈哈!),对于可以实现自定义字段么?我只能呵呵了 这个实在是太难了?我只能做到配置,但是配置完的数据绑定显示到页面还是困难重重,现在还没不会做,字段配置只需要一个存储就可以了,然后提供一个维护界面。对于系统交互么,我是开发了三年的WCF,我提出了我的解决方案,但是最后开发完demo之后,项目领导说去开发业务去吧。这个解决方案的过程大概持续了一个月将近,其中最浪费时间的是与几个同事的配合吧!因为技术他们只能说是你要给他培训了,我觉得我用的这些,asp.net mvc 4 、entity framework 4、jquery 、jquery easy ui、ztree 、jqgrid、fastreport 这些东东不是有太多技术含量吧(博友们说呢)?

好了进入5月份后开始完数据库的讨论(哎 这个是那个架构师搞得 被他玩惨了),我觉得一个好的软件系统,三个方面1、好的数据库设计2、好的需求设计3、好的团队开发实现,

这个数据库的设计我罗列以下几点吧,

1、表最好不要用联合主键提供一个单一主键,操作和维护都方便,用代码层次控制数据的唯一和校验

2、表数据字段如XXX代码,最好有编码规范,不要让用户乱维护(虽然是产品但是我们也有点话语权吧)如现在一个问题公司和部门子父级结构他们的代码随便填时

公司0001   部门0001 所属公司 0002 

公司0002   部门0002 所属公司 0001

这个递归,你们看看!

3、设计的数据库最好有个体现需求的描述文档,每个需求体现在哪张表上,不然像现在一样,有些需求通过之前的表设计,串不起来了哎,有些表可以废掉,有些表需要加,有效表需要加上字段

就这样我们就开始开发了,没办法还!

数据库将近半个多月设计的第一版后开始6月份,这时这个架构师hold不住了,开始走人了,我也是想走过,但是之前做的代码努力还是不甘心觉得需要在努力挑战下,于是接手他所有手里的活(当然也没什么活,大哥一行代码没写,文档呢也是断断续续),后来我开始了新成员的组建,这样6月中旬找齐了新的两个开发一个测试,继续下面的任务的开发。

把前期需求,产品规划,现有代码结构通过EA画的用例图、组件图、类图用两天的时间描述完团队进入开发阶段。8月中旬开始完这个第一版吧。但是公司又来了个架构师,一个想转java平台的架构师,只是说我们的界面不好看(这怪我么?)、(我们的有些需求不能串起来)、这个框架不能满足10月份交差的需求、确实是他拿了自己以前做的东东给老板看了,那是什么东西(一个集团公司开发了2年的东西来和我们这个3个人开发两个月的东西比,我靠有可比性么?)。

就这样我觉得我失败了,对于失败的总结我如下分析吧

1、技术不是装逼用的,是满足客户需求的,满足客户想要的就行,他不关心你用什么技术。

2、产品不是你一个人能管理把控的,而是一个市场、团队好多人需要共同努力的

3、不要在没讨论完需求的情况下去开发只会伤害自己

4、数据库设计前一定要求需求模型或文档(需求上的内容描述、字段描述和需求数据间的关系描述)除非你是一个懂需求的人

5、不要应用你不熟悉的技术领域去开发产品(除非你有些好的同事共谋)否则只会坑掉你自己

6、其实有很多装逼人搞技术,你要么别跟他合作、要么早点揭穿,否则最后拍拍屁股走人,还是坑你

7、产品是阶段性的项目过度设计和过度挖掘不利于开发和实现

8、技术积累随时要总结和完善这样才有利于技术的成长

原文地址:https://www.cnblogs.com/qianthinkover/p/3946213.html