大型软件开发心得

人的想法不一样，能力不一样，眼界不一样，人是复杂的，尤其是思维，心得也在一直变换。心得体会是每一个学生必须经历的写作训练，心得体会可以总结出具体的经验和想法。怎么才能在写心得体会时更全面呢？经过小编精心整理，推出大型软件开发心得，欢迎你收藏本站，并关注网站更新！

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

立项前

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

这是很多产品经理表示非常痛苦的过程，因为可能会遭到数落和冷眼，日本有一个礼仪原则是不要给别人添麻烦，但是在项目中，这不可避免。

个人认为所有沟通的障碍都源于思想的不统一，如果让大家觉得这个需求修改是在浪费时间，那么沟通上的不畅快在所难免。项目不是这样算的，需求既然更改一定有所目的，产品经理需要将这个原因讲明白，不做修改或节约沟通时间导致的返工，后果往往更严重。

f132.cOm更多心得体会扩展阅读

软件开发项目实习心得

一直以来期望从事自己喜欢的事业的我，对软件开发有者及大的兴趣，可由说种种原因使我从事工作以来走了好几年弯路，心中的梦想迟迟不能得以实现，可程序员的梦想从来没有从我的心中抹去，但这扇大门好像并没有向我敞开，今天，贵公司给了我敲开这扇大门的机会，让我真实体验了程序员的诞生过程。早就听说，程序员的前几个月是最苦的，可从来没有感受到，海马实习基地让我提前感受到了刚刚进入软件行业的压力和困惑，再也没有在自己家里随便写段小程序后的那种“自豪”感了。要面对每天必须面对的问题，再也不可能以“逃避”而了之了。也让我感觉到做为一个程序员所应该具备的基本素质在这不到一个月的实习过程中也让我深深体会到了作为一个合格的程序员应该具备的基本素质。

团队精神和协作能力是程序员应该具备的基本素质，最近的工作中让我深深休会到了这一点，由于小组成员配合不好，使本来很方便的cvs给自己的工作带来的及大的麻烦，一不小心自己写的的东西就会被小组别的成员在上传文件的时候给覆盖掉，一整天的工作可能就这样被反工，我们小组这次就是因为协作不好，导致各模块之间不法连接，给工作带来了及大的麻烦，消耗了大量的劳动力还没有提高工作效率。这使我深深的体会到：一个成功商业性软件的开发必须有一个有强大凝聚力的团队，个人的力量是有限的，团队精神和良好的协作会使我们做出优秀的软件。

良好的文档是正规研发流程中非常重要的环节，作为代码程序员，30%的工作时间写技术文档是很正常的，缺乏文档，一个软件系统就缺乏生命力，在未来的查错，升级以及模块的复用时就都会遇到极大的麻烦。这次的这个小小的项目，就因为文档上的一点点理解错误让我们花了很大的工夫去改代码，改页面。很庆幸的是，这是一个小项目，要是大项目，这种问题可能就会导致大量的代码修改，可见文档在一个项目中起者巨大的做用。

此外，良好的代码编写习惯，不但有助于代码的移植和纠错，也有助于不同技术人员之间的协作。作为一个程序员，对需求的理解能力也是很重要的，只有真正理解了一个模块的作用，才会写出高效率的代码，才能使整个软件项目作出来更加优秀，具备更好的安全性和稳定性，我在写代码的过程中就遇到了需求理解上的问题，使得写出来的代码功能不全，幸好不是给客户发现在，要不，这个软件的商业价值可能就会打折扣了。单元测试对于一个程序员来说是不可不做的一项工作，不做好测试就会给后期的集成工作带来麻烦，往往为了一个小问题会让我们查找好多模块，给后期工作带来很大麻烦。

这一段时间的工作也让我明白了一点：一个优秀的程序员必须不断的学习，随时总结，找到自己的不足，这样逐步提高，才能让自己很快的成长起来。

软件开发公司实习心得

不知不觉，在大庆实习的日子快过去半个月了，记得刚来大庆的头几天，感觉非常不适应。首先是环境：这里吃的东西很贵，而且这里的物价很高。其次是大庆人：大庆人办事的效率很高，这就是铁人的精神吧。

对于以上种种，待了3，4天基本就适应了，难怪一些长辈老是说：习惯了，就好了。

来的第一天，我们听了付丽萍老师讲了一节课，可以说完全不知所云，但还是可以听到一些东西的，譬如：工作环境的适应，人与人之间的交际，处理各种事情的能力，其中最重要的就是养成良好的工作习惯。有良好的工作习惯，才会被上司，老板和同事认可，将来也会比同辈有着更快更多的升职机会，而且一个良好的工作习惯，无论你从事哪个行业，都是受用终生的。然后，就是认识我们的董亮老师了，一个可亲可爱的老师，传说中他们一个月会赚十几万呢！天文数字，望尘莫及啊。

在随后的一段时间里，我们被分为了八组，每组六七个人，有一个组长带领。我们组织作一个项目——论坛，在第二，第三个礼拜感觉没有刚来时那么拘谨了，我更明显感觉到自我计划，制定目标的重要性了。在我们犯错误的时候，老师会惩罚我们，陈发的方式很另类——唱歌或者讲笑话，不算是体罚大事可以达到对我们的约束。然而，歇息期间有组织我们做游戏，看似很简单的游戏其实是想培养我们合作意识。

在实习的过程中，我深刻的体会到了三点：第一，项目是以迎合客户和使用者为目的的，不可能像教师那样为我们制定一套教学计划。想要知道些什么，渴望懂得些什么，全要靠你自己想学，你自己不问，没人会主动来告诉你。第二， “纸上得来终觉浅，绝知此事要躬行！”在短暂的实习过程中，让我深深的感觉到自己在实际运用中的专业知识的匮乏，在行业中的经验真的很重要。

第三，能更早的接触你所在行业的真实情况。不出来自己转一圈，根本不知道自己学的一些专业知识，哪些是十分重要，十分实用的。就比如说英语。以前听老师说过，听朋友也说过，将来工作了，英语相当有用，外企就更不用说了。当时没什么感觉，但当我频繁的看到一打打英文资料手册、帮助文档时，我已经切身地，的的确确地感受到英语的重要性。

这次实训让我学到的东西太多，使我受益非浅，它让我知道了工作上的辛苦，让我知道工作并不像在学校里学习一样轻松。不过，虽然辛苦了点，但能让我学到不同的东西、很充实，我心里还是高兴的。人非生而知之，要学得知识，一靠学习，二靠实践。没有实践，学习就是无源之水，无本之木。以上就是我在成都的进行实训的心得和感受。 不到半年的时间就将步入社会的我们，面临是继续深造，还是就业的压力，我想我们更应该把握住最后的一段时间，充实、完善自我，争取做一名出色的大学生！对于这次实习，我很珍惜也很怀念。

软件开发心得体会

受某文化公司委托，开发一款用于视频和图像处理的软件，开发难度高，高到从未搞过，开发周期长，长到是我以前项目监控最长开发周期的两倍，开发成本之底，让我觉得程序员成了高级打字员。首先是需求分析书、产品规格说明书、设计说明书、代码规范说明书、测试计划，光文稿就不知道熬了多久才做完。

紧接着，遇到一系列问题，首先是语言选择，vc++和c#都是可以保证开发完成的选择，但是vc++内存容易报错，界面很难修改，而客户要求的界面质量甚至比程序的功能更严格，没办法，客户就是上帝，上帝做事一定有他的道理。c#语言易于开发，而且图形界面绘制也易于修改，可以做出客户体验很好的界面，但是在资源的消耗上，让我很吃惊。做到第二个月，大概的界面已经完成时，出现界面刷新的问题，刷新时开始卡，界面不流畅。没办法，改。

开会，总结，技术骨干找问题，拿出解决方案，力争第一次做软件把它做好：

重新做软件开发进度计划和软件测试计划，并且让独立功能demo制作和测试先行；

用direct draw、direct 3d或者opengl中的一个替代c#本身的gdi绘图，将在接下来的开发任务中加入进去。

事无巨细，当我满意的看着界面流畅，功能也已实现时，发现软件在低分辨率或者小本上根本乱到没法看，甚至是界面功能按钮错位，重叠等等。没办法，改。毕竟软件的多分辨率兼容和操作系统兼容是必须要做的。

接下来一大堆的麻烦找了上来，软件出现各种各样想都想不到的问题，总算是按时将第一个版本发布出去，并且开始接下来的升级开发任务。

最后，给刚刚接手软件开发项目的朋友一些忠告：

一、相关的文档不是给别人看的，而是给自己看的，相关文档一定要齐备，而且让所有涉及开发的人员都清楚的知道你文档里所要表达的意思；

二、一定要注意多做demo，多做实验，一个demo程序员几个钟头就可以完成，甚至更少，但是不做demo，核心程序没有做实验，其他的东西都围绕核心程序做了上去，到时候耽误的可不是几个钟头

三、程序设计要注重用户体验，当初客户对我要开发软件提出近乎苛刻的要求时我不在意，但是当我自己反复使用软件时有了很多体会，流畅美观的界面带给人心理的快感的确能替代一些尚未开发完整的功能带给用户的遗憾。

四、测试计划多次进行，分批进行，不要全部开发完成再对软件做测试。

还要坚持三个月，软件马上发布，希望大家的支持，谢谢！！！

软件开发心得体会（2）：

作为ｐｍ，有时需要招聘软件开发人员。这几年也一直在想，如何能在短短的30分钟或1小时内，快速识别出，坐在你对面的应聘人员，是否适合你的team。这几年也一直在观察和反思，经历过的team和现在team中的软件开发人员。有几点小的心得。

1. 倾向于招什么样的软件开发人员

- 经历过历练的人

吃过苦的，比如以前工作，经常被外派出差，又如曾在业内都知道以加班多而著称的公司呆过，还有些，留过学，但都是自己边打工边读书的，等等。

这些人员，入职后，通常都是能干活，能作为骨干。

- 思路清晰，思想活跃的人

让谈谈自己现在的产品，如果能清晰表述，有条理，会发散，但又能适当控制住，并收回到原话题。谈到技术问题和解决过的难题时，眼中有光芒：）

这些人员，今后工作中，学习能力强，对解决难题有帮助，能作为中坚。

- 坦诚、坚定、平和的人

面试中，坦诚，目光坚定。有时坦诚到甚至于显得有点木讷：）

我曾经遇到一个，面试下来，我最后介绍我们产品中用到的技术，他对这些技术知之不多，最后他说，我可能不是非常适合，我知道一个朋友，他可能更适合。我综合评估后，最后还是选了他，事实证明，他后来做的很不错。

坦诚坚定的人，会有恒心去学习，去解决问题。这些人员会作为team的基石。

- 有缺陷的人才

这是一个朋友（lance）的想法，我认为还是有道理的。

大公司，会看重综合素质，而如果是小公司，可以考虑选择一些有缺陷的人才。所谓有缺陷，是指，比如他英语很差，或沟通不清晰，但他能用程序员该有的思维去思考问题。这样的人员，通常进不了大公司，故会相对踏实地呆在一家公司，做好自己的工作。

2. 谨慎考虑这样的开发人员

- 太活泼，太易兴奋

太易兴奋，说到投机处，是是是是，对对对对。。。，又蹦又跳，还时不时来点，oh yeah, you are right，然后还摆个 v 手型。讨论问题，不易固守在技术问题本身，时常跑到我们产品中用到的技术（或第3方产品）很强，我挺他们，不可能有问题，又或者我们对客户要强势，我们要坚持我们的产品没问题。

软件开发工作本身，显得比较沉闷，优秀的技术人员，都略显有些内向，因为解决问题，很多时候需要耐得住寂寞，时刻保持相对冷静。

太活泼的人，会在遇到问题之初，表现出很强的冲劲，但当长时间不能解决时，会表现出没有耐心，会经常抱怨（对team、管理、产品、流程等），非常情绪化。有些女程序员还会吵，会哭，这时项目经理只能放下手中的活，下去给她买点零食来哄哄，莫哭，这里有你最爱吃的猫哆哩。一边擦着鼻涕、眼泪，一边嘴里塞满东西，鼓鼓啷啷这是酸角口味的，那个西番莲口味的才叫好吃...

这些通常不太容易在面试时表现出来，在试用期时，要观察。