大型软件开发心得

最近做的一个项目从需求分析到上线绵延了四个月之久,这也是目前接手过功能点最繁复,产品线对接最多的一个项目。从中得到的一些关于设计较大型产品的心得,拿出来跟大家分享。

立项前

1、统一元素设计需考虑周全

也许是初创团队的缘故,我不得不感叹团队对产品经理要求之严格之缜密,项目全程只有一个人负责,所以大到产品线对接,小到一句提示的位置和展示形式都需要一一推敲。

哪些元素应该做到统一?

a、提示方面:统一的操作成功/失败提示;统一的弹窗形式;提示语言采用较统一的句型;为空情况的友好提醒;溢出情况的友好提醒;表单实时验证的提醒形式等。

b、文字方面:是否有统一的段落前“·”号;统一的链接状态;统一的字体、间距、行高等。

c、图片方面:调取图片的统一尺寸;如果是上传图片类的操作,需要考虑周全全站的调取情况,以及考虑是否统一预览图的尺寸等。

d、细节交互:未激活功能的按钮做“灰色”处理(例如用户没有勾选信息时批量删除按钮不可使用);按钮点击的状态统一(例如增加“提交中”的按钮状态,以防止网速慢用户狂点某一按钮的情况);特殊控件的统一等。 也许会有朋友说,上面有些是交互设计师需要做的事,但我一直认为作为一个产品经理考虑周全一些,没坏处。这些“统一”同样可以用在验收阶段,要知道,即使一个像素也可以改变整个产品的感觉。

2、原有功能的去留

我一直觉得升级已有产品比开发新产品难一些。这就像栽培植物一样,新种下一棵果树无非需要选对了土地,然后刨个坑种下去,然而成长期的去病枝、打顶等各种修剪所消耗的精力往往更多。

改进已有产品常常需要面对一个最棘手的问题:原有功能是去是留? 原功能去掉的话是不是会影响部分用户使用?是否需要通过公告、站内信、界面引导等方式友好地告知用户?怎样把对用户的伤害降至最低?

原功能留下的话是不是可以优化完善?听到了什么用户群怎样的声音?是否要在这次升级中做调整?

这些问题当接到项目的时候,产品经理就应该考虑周全了。特别需要注意的是,如果这个产品之前不是自己设计的,那么最好找到prd说明文档细细研究一遍,对把握不准的功能点找到原负责人确认,毕竟树苗是ta摘的,别把将来最能结果的枝干给砍了。

3、产品线上下游的对接

昨天有跟朋友聊起淘宝强势之处,就是产品与产品紧密捏合,线上线下、跨平台跨行业形成了一个盘根错节、根深蒂固的根基,无可撼动。

所以把握产品线上下游和产品周边很重要,即使一个看似简单的新闻展示页面修改也会牵扯到编辑后台、广告位管理、帮助中心,甚至是访问统计、数据需求的变更。

这要求在产品设计开始前,需要把该产品“连根拔起”,仔细梳理相关脉络,如果产品线够长,一个清晰的产品线结构图很有必要。

项目中

1、项目期间来自相关产品线调整的影响

项目期间相关产品线的调整是我最不愿意遇到的情况,这就像你在通往目的地的道路上高速行驶,就快要到达终点了,突然一个人告诉你:你走错路了。

项目里有一个通用模块,产品设计到一半,这个通用模块改了;项目里有一个流程,产品做到一半,这个流程废弃了;最要命的是已经立项开发了,你不得不硬着头皮跟程序员说:“因为一些不可抗拒原因,这个需求咱不做了。”

对于一个耗时较长的项目来说,这种情况难以避免,事出原因私自总结有三:

a、严重体验性问题:例如某个流程遭到大量用户的不满,为防止用户流失,不得不做临时调整,而倒霉的是,你也在用这个流程。

b、相关项目的影响:包括并行项目和新项目。例如你的同事在设计另一个产品,你们的产品相互牵扯较多,所以需求分析时做过很多沟通,但有一天,同事告诉你,ta的一个需求做临时调整了会影响到你,怎么办?

c、老板的突然决定:不举例。

最终的解决方法不外乎三种:立即调整、延期调整、不调整。个人的处理原则一般是对a种情况进行立即调整,对b、c情况讨论并选择性延期。 为什么这么做呢?a情况是必须要改的,时间早晚问题,长痛不如短痛,b、c两种情况必须坐下来细细讨论。需了解这个需求为什么要改?是长期对策还是临时决定?能否延期,记录需求等下一版本再开发?如果b、c情况提出来的需求没过两天又有改变,那与你配合的前端和程序员也太没有安全感了。 这个时代能耐心阅读完XX枚汉字的人越来越少,较大型项目的产品工作心得[下]未完待续,欢迎交流??

2、需求变更

承上,需求变更是每个程序员、产品经理、设计师等都会遇到的情况。产品经理不是神,项目组也不可能是开了无敌状态抵挡任何外界的影响。

当遇到不得不变更需求的时候,产品经理应该怎样处理呢?下面是个人的四条建议:

a、积极处理。往往,当一个设计愈是趋于完成,人们愈是倾向于局部调整,而不是做重新设计。当一个需求因为众所周知的原因不得不调整的时候,作为产品经理需要做的第一件事便是积极面对问题,积极处理。

项目开发往往是一个紧张的过程,每半天甚至每几个小时就有若干个功能点开发完成,当一个需求变更传达出现“延迟”,这个变更对项目的正常进程的“破坏力”就会更大一些。

b、保持沟通。“说话容易,沟通很难。很多事除非对方自己想明白,劝是没有用的。所以,很多时候,沟通是个自己挣扎的过程”这话没错。需求变更直接会影响到下一道工序,产品经理需要将需求变更的细节和原因传达给相关人员,包括视觉、前端、程序、测试等。

这是很多产品经理表示非常痛苦的过程,因为可能会遭到数落和冷眼,日本有一个礼仪原则是“不要给别人添麻烦”,但是在项目中,这不可避免。 个人认为所有沟通的障碍都源于思想的不统一,如果让大家觉得这个需求修改是在浪费时间,那么沟通上的不畅快在所难免。项目不是这样算的,需求既然更改一定有所目的,产品经理需要将这个原因讲明白,不做修改或节约沟通时间导致的返工,后果往往更严重。

 

第二篇:软件开发心得

软件开发心得体会

08软件(1)班 陈会敏 24号

岁月流转,时光匆匆,转眼间我的大学生活已经接近了尾声。回首往昔,有太多美好的,也有太多艰辛。我的大学生活的主旋律还是学习,我所选学的专业是软件技术,在这条道路上走了那么久,也有一些小小的感悟与体会。

还记得上初中时,英语课本上有一篇关于比尔盖茨的文章,当时真的很佩服比尔盖茨,也就是那时我才第一次接触到软件一词,学过那篇文章后我有个想法,就是也要做个比尔盖茨,可是由于家庭条件的限制,那也只能是个美好的梦想。后来上了高中,再报考时我就选择了软件技术这个专业,这样我想就向那个遥远而又美好的梦想迈进了一点点吧。

然而当我真正上了大学,学了这个专业,我才知道要做个比尔盖茨是多么的难,要想学好我的专业要花费很大的精力。第一学期我们开设了C语言这门课程,当时我学着真的是云里雾里、一窍不通,很是失落,学了不久之后我开始觉得自己可能并不喜欢这个专业,只是一时昏了头,错以为喜欢了。现实的打击让我有点不知所措,然而我已经选择了它,有句话说:既然选择了远方便只顾风雨兼程。我既然选择了这个专业,我便也只有硬着头皮也要走下去了。有了这样的想法之后,在之后的一段时间里,只要是没课的时候我就抱起了C语言课本,努力的看,记语法知识,语法规则,学语句、小算法等等。经过一段时间的研究学习,我发现C语言并没有我想象中的那么难

了,还是很有意思的。就这样在学与玩中我的大学第一个星期就过完了。

后来又开设了很多课程,有VB、网络、数据库、操作系统、数据结构等。在这些课程中最令我头疼的就是数据库了,老师讲的时候老是划重点,讲的很少,当时学的时候真的好难受,一学期下来啥也不会,后来看书上的操作,一步一步的操作,才终于学会了建个数据库,做下备份还原等操作。开设的那么多课程也有我很喜欢的课程,比如数据结构,这门课程理论的比较多,上机操作的很少,这门课程是很需要理解的,当然有的还是要死记的。学习这门课的时候,我觉得并不像其它课程那么吃力,可能高中是学理科的缘故吧,理解起来并不太费劲。所以当时就很喜欢这门课,然而这门课表皮的好学,但要深学起来还是很有难度的,所以期末考试的时候我的成绩并不太理想,但这些打击不了我对它的兴趣,至少我知道我所学的这个专业还是有很多我是很喜欢的。

这样走着走着就到了大二的下学期了,那个学期,我们有一门课是C++,这门课的老师很和蔼,能力也很高,从他那里我学到了很多东西。老师教给了我们很多算法,也很系统的讲解了语法知识,还教我们做小系统,有的时候他会给我门们一些小系统的代码,让我们去改写,刚开始的时候我也是不会,后来经过学习请教改写成功了,这个时候我就会很开心,很有成就感。就这样在学与玩中,在快乐和忧愁中我们迎来了我们的大三时光。

大三刚一开学,老师们就告诉我们这学期就上十二周的课,然后

就考试,就毕业了。这让我很有紧迫感,一想到毕业在即,心头就有种不舍,这儿有我美好的时光,然而我就要对这里说再见了。大三了我们的课全变成了专业课,也几乎全成了上机课,老师还给我们布置了一个程序,就是一个小组要交一个系统来算作成绩。我们这小组所选的课题是图书管理系统,针对这个系统,我们上机的时候,利用网络资源在网上查找了相关的资料,因为说实话,我们对此并不太理解,也只有通过网络来查找信息,做好需求分析,功能模块设计等工作。在这同时我们还去了学校的图书馆理解了相关的信息,这个系统并不要求功能有多么强大,关键在与一种锻炼,思维的锻炼,对所学东西的总结等。建立数据库时我们就根据需要建立几个表,里面的数据也是从我们学校图书馆里找来的。后来的界面设计,为了追求美观,我们又在网上搜了很多美丽的图片来美化界面。具体到功能的时候,有很多东西都不会,后来老师在课堂在做了讲解,我们就把它用到了我们的系统中,真的就是学一步做一步的。整个的系统做下来,我学到了很多东西,也对那么知识有了很好的应用能力。

现在这个星期也就到了期末,这短暂的校园时光也在飞速的流逝着。回首过去学习的经历,真是苦中有乐,乐中亦多苦,然而无论如何这些都已经走过去了,未来的路还要我们好好的走下去。人生本就是一个不断的学习的过程,也是一个不断完善的过程,在未来的道路上我会更加努力地学习,走出一个美好的人生。

 

第三篇:软件开发心得总结

有感于网盘开发过程

有感于网盘开发过程 .............................................................................................................................. 1

一、软件开发个人体会: ................................................................................................................. 2

二、做软件开发我觉得要明白: ..................................................................................................... 2

三、在开发中遇到问题应该怎么去解决? ...................................................................................... 2

四、怎么样才能提高自身的能力?.................................................................................................. 2

五、怎么样才能做好软件开发? ..................................................................................................... 2

六、文档的重要性 ............................................................................................................................. 3

七、我的收获 ..................................................................................................................................... 3

八、网盘项目开发的最大体会 ......................................................................................................... 4

九、软件测试(单体测试和连接测试) .......................................................................................... 4

一、软件开发个人体会:

1. 软件领域中的知识在于积累。

2. 做软件开发,就类似算数学题和世界杯足球赛一样:重在结果,而不在乎过程。

3. 软件服务于人类,软件是在解决一些生活中的问题和错误,问题决定解决方案。

二、做软件开发我觉得要明白:

1. 职业的乐趣:

(A) 用自己的智慧去创建新事物的快乐

(B) 开发对别人有用的东西

(C) 不断学习来充实自己

2. 职业的苦恼:

(A) 总是追求完美

(B) 所有要实现的功能由他人而定

(C) 概念设计计是有趣的,但找Bug总是很苦恼的

三、在开发中遇到问题应该怎么去解决?

1.

2.

3.

4. 不明白就多问,不要自已一直去琢磨。 一个问题如果30分钟还没有解决就应该考虑是不是问问别人。 一个问题在没有用过3种以上的方法解决过就不要去问别人。 解决问题思路是关键:

相信问题总归有解决的办法,就算连技术上都没法实现的问题,相信通过良好的沟通终究也会有解决的方法。

5. 解决问题的前提是:理解别人的意思,理解别人的需求,多沟通,及时给客户反馈信息。

四、怎么样才能提高自身的能力?

1. 程序员怎么样进步最快? - 理论结合实践

2. 不要怕出错,不怕遇到错误,有错误就有挑战,这样才可以进步,但不要让同一个石头

把你绊倒2次。

五、怎么样才能做好软件开发?

1. 首先要明白解决的问题是什么,理解问题,其次再决定怎么解决这个问题

2. 碰到很复杂的问题,我们就简单想,把问题简单化,细化到能够实现为止

3. 出了问题,我们要先分析问题,然后知道引起问题的原因,最后并想出问题的解决办法

4. 我们应该从2个方面去把握一个项目:从业务角度和项目的关键问题上去把握一个项目

(A) 从不同的系统场景

(B) 从不同的用户角色(充当什么角色)

(C) 从不同的系统使用角度(拥有那些权限)

5. 其实我觉得开发人员说实在应该要比使用系统的人更了解系统需求,只有真正彻底的了

解了项目的业务需求,我们才能做真的做好这个项目

六、文档的重要性

记得我当初刚开发项目的时候都是写个大致的需求说明书,做一个E-R图,画几个大致的数据流程图,然后建立数据字典和表结构关系。 再接着搭建一个开发环境,配置几台服务器,划分一下模块,分工,我们就可以Coding了,一直到项目结束了,也没有完整的设计文档,更没有完整的测试文档,虽然这样的确是很快的完成了Coding工作,感觉上好像节省了好多成本和开发时间,但后期的维护和Bug 就是经常出现的事。

小项目没有文档关系不大,但如果遇到一个大项目的时候,那这样的开发方式就很有问题很危险的。

大项目没有文档: 首先维护就很麻烦,也很乱,写的代码,过几天都不知道它是完成什么功能的了,其次系统的稳定性和可靠性也让人怀疑,扩展性就不用说了。

七、我的收获

A.程序员大多都不喜欢写文档,我们以前也是特讨厌,记得以前都是系统开发完了,为了应付项目验收,就匆匆忙忙的一组人在那里补文档。在我们的思想里,所谓的文档就是一些废话,一句话硬是用十句话来代替的无聊透顶。

B.代码风格要规范

以前做项目,我们都是不怎么去注意代码风格和写代码的规范,都是稍微想一下就直接开始写代码了。注释也很少用,总感觉我们自己写的代码,我们怎么会不知道它做了些什么事呢 ?总觉得我们自己写的代码我们怎么会不知道它是用来做什么的呢。一直都不相信这是个事实,但事实上,项目验收后,系统刚开始使用的人少,也就不会出现潜在的错误,随着时间的增加,久而久之,当大量用户并发访问的时候,系统的Bug 就暴漏出来了,那时你再用熟悉的Eclipse打开整个项目的源码时,再去看自己写的代码的时候,真的发现,我们定义的这个变量名是什么意思啊 ? 我们的这个Flag 是用来判断什么的啊 ?我们的if()中条件不知道是判断什么? Function () 也忘记是什么功能了? 想想好可怕啊。 难道真的都忘记了吗 ?回答是肯定的: 真的忘了。

C.心得体会:

通过做该网盘项目,在这2年的锻炼中,我们才真的体会到,良好的文档是正规研发流程中非常重要的环节,一个好的程序是先写好设计文档再进行编程的,在设计文档的指导下,才能写出安全的代码。如果你不写文档,一开始就写程序,这样你就不会按已设计好的路线走,而是想到哪写到哪。小功能还好说,要是大功能,就容易混乱.

刚开始我们还很不习惯这一系列的编程风格,很多的规范,尤其是命名,方法和注释,都有这着很多限制,让我们觉得真罗唆,写个程序完成功能不就可以了吗,明明1小时做完的事情非得让人用3、4个小时去做,我们现在真的明白这样做的好处了,我们已经习惯这样的编程风格了,这也养成了我们的一个编程习惯了,深有体会啊。

最忙的时候就是我们成长和收获最多的时候。

八、网盘项目开发的最大体会

我们觉得项目开发的开始时候,应该由项目负责人很好的对项目是什么项目,具体大概做什么事情,是谁提出来的,目的是解决什么问题,以及里面用到的很多专有名词做个细致的说明,而不是从一开始就分几本式样书,给个静态Html 的Demo看看,然后搭建好开发环境就按照式样设计书来开发。

九、软件测试(单体测试和连接测试)

我们首先认为,编写程序的时候不要想出了问题再解决,而是要想如何不会出现问题,要根据经验来预测可能出现的问题,然后避免出现。

测试,说的直接点就是给软件找错误。

很多人认为发现错误是软件测试的唯一目的,查找不出错误的测试就是没有价值的测试,实际上我们不这么认为。

我们觉得对开发人员来说,我们要把测试出来的Bug都应该做个分析,知道错的原因之后,我们就应该在下个项目中防止类似的错误发生,而真正来提高我们开发的效率。

相关推荐