写这么多非常辛苦，转载请注明出处，谢谢
国内的中小科技公司在进行软件项目开发的过程中，普遍遇到一些问题：团队成员人手不足、技术基础薄弱、缺乏经验，项目周期紧张，开发管理混乱等，这些问题直接导致了项目的交付问题，同时优化、改进不知道如何下手，投入大量的资源重构、重写效果却不明显。
如何认清自身的结合企业自身的实际情况，更有效地利用资源打造更好的产品，改进现有软件产品的质量，成为了企业在行业内是否具有竞争力，是否能持续长远发展的重要关键。
国内不乏市场份额逐渐下降、苟且生存的大公司，也有很多小而精的新生力量，公司的大和小跟产品质量的优劣并没有必然的关系。根据公司的现状，扎扎实实做好自我认知、市场分析、产品定位、质量标准、研发计划、阶段验收、项目总结等工作，是保障产品质量的必要前提。逐步消除既有问题，加大防控未知问题是产品质量提升的不二法则。
产品的质量是一个公司的立足之本。当我们感慨日本、德国这些工业强国所诞生的灿烂如星空的知名品牌诸如：丰田，松下，TOTO，奔驰，博世，西门子时，相信很多企业家也在不停地思索自身和他们的差距在哪里。技术？管理？市场？我们的差距还有多远。
技术基础的薄弱这个是无法快速解决的问题，所谓十年育树百年育人，基础研究人才的短缺并非一朝一夕能够解决。田不但要种，饭还是得吃，目前国内很多企业也尝试通过跟国外企业进行合作、投资、收购等方式加快推进技术进步，近些年很多成果也是非常可观的。
然而当下，更多的问题可能不是我们没有技术，很多国内的企业愿意以市场换技术，国外的公司也非常乐于将自己的某些技术以一个不错的价格转让出去。然而拿到了技术之后是不是就能生产出质量优质的产品，答案无疑是否定的。没有好的管理，即使能拿到好的技术图纸，甚至直接拿到核心的部件，也未必能够生产出有强大竞争力的产品。这样的案例比比皆是，这里就不作举例了。
读过《菊与刀》的朋友们或许知道，我们的邻居日本，是一个社会和家庭等级森严，做事极其讲究条条框框的民族。在我们的印象中，他们有些时候聪明、狡诈甚至阴险，有些时候却隐忍、死板、脑子很不会转弯。任何民族都存在多面性，中华民族有中华民族的多面性，日本也不例外。
如果说要取管理圣经的话，真的不必要远渡重洋向美国，向欧洲。我们小时候玩的FC红白机，里面的游戏超级玛丽，魂斗罗，赤色要塞等等，几乎没见过延迟、卡顿、卡死、崩溃，这让我们产生一种错觉：一切不就应该是这样的吗。直到后来接触了各式各样的电脑软件之后，我渐渐觉得，延迟，卡顿、卡死、崩溃才是正常的，遇到一个能流畅使用很久的软件之后则免不了会赞叹一番。由于知识产权不受保护的问题，我们的起点太高了，80、90后诞生便是免费使用着世界一流的公司开发出来的软件。而今的IT行业80后、90后也都迈入工作岗位，肩负着社会和公司赋予的重任；今天，我们不得不重新思考开发过程中把控软件质量的问题，这关乎到企业的可持续发展，也关乎到项目参与者个人专业水平的提升。
本文以软件开发流程作为主线，从实践出发，结合中小企业遇到的实际问题，论述如何开展项目以及如何处理项目中遇到的问题。因为篇幅有限，其中涉及到的专业的概念不做过多的解释，大家可以自行查阅相关的资料。
1. 软件项目立项
1.1 项目的背景和意义
理论上项目的背景和意义分析作为立项的根本十分重要，但是很多时候中小企业为了解决眼前的生存问题，或者是受限于决策者自身，无法从长远的角度考虑该项目是否符合政策的号召、历史的进步、时代的潮流、社会的需求甚至法律的约束。当然也有一些企业为了追逐利益而故意忽略、否定客观的历史社会背景，歪曲项目的意义。一个项目是否能够可持续健康发展，项目的背景和立意起着不可磨灭的作用，俗话说方向比努力重要。
快播的王鑫虽然在法庭上反复重申技术无罪，但是常理上来说，一个混迹于互联网多年的公司核心人物，是不可能不知道这种分享的技术会带来的麻烦，单就知识产权保护的问题，都是能够简单预见并且不可回避的。迅雷的没落，QQ旋风停止运营，这些其实都是在项目创立之初就已经埋下了伏笔。虽然雷军那句站在风口上，猪也能飞上天，非常振奋人心；但是笔者更认同马云的观点，猪本身不具备飞行的基因，勉强因为偶然的外力飞起来，只会飞得越高，摔的越惨。
所以在立项之前，我们要正视项目创立的初衷，广泛收集信息，做好战略分析工作，尽可能地从长远的角度出发，做符合公司利益的规划。
1.2 立项分析
立项分析包含但不仅限于如下几项：
1.2.1政策、法律分析
分析项目涉及的业务，以及和业务有关的政策法律信息，了解国家是鼓励还是限制开展该业务，有什么管理措施和手段，当地政府是怎样执行有关国家法律法规和政策，对业务有利和不利的影响。
1.2.2行业环境的分析
竞争对手分析，也包括整个行业上下游生态的调查。所谓知己知彼，百战不殆，如果竞品已经在行业内独占鳌头，且垄断了整个生态的大部分上下游产业，那么就应该考虑如何在产品立意方面与对手拉开差异。如果尚未有直接竞争对手，则可以分析一下类似的竞品企业。
当年脑子比较轴的日本人制造的石英手表在走时精准性上打的欧洲传统腕表满地找牙，瑞士手表行业差点找不到北，逼得欧洲腕表行业重新定义了游戏规则：不再强调走时的精准性，宣传上主打文化底蕴、设计美感、品味档次，重新开辟一个对自己有利的战场，并最终得到了消费者的认可，把这个厉害的搅局者挡在了局外。这是一个典型的认清自己、展开差异化竞争，反败为胜（保住饭碗）的例子。
1.2.3自身分析
有一部分创业者是完全凭着热情和对未来美好的预期进入互联网行业的，对自身和行业缺乏认识和了解。笔者碰到过几个从事传统行业的朋友，他们满腔热血，经常大谈如何通过互联网改变自己的行业。其中认识几个果农的同学就立志要创建国内最大的水果电商平台分淘宝一杯羹，认识几个餐厅老板的同学就想着做外卖平台收集用户资料搞社交颠覆腾讯；这些项目缺少理论可行的支撑，通常持续时间很短。
自身分析需要根据团队规模、擅长的领域、技能水平、管理水平、资金能力等方面的客观因素规划项目内容的边界，保证项目稳健，有序地开展，并最终实现预期的盈利。
典型案例，某电商公司没有任何游戏开发基础和经验，想要仿制一款桌游，利用游戏来吸引新客户和增加客户粘性。该公司管理层仅从战略的角度上简单讨论了一下该游戏项目的实现难易程度，认为游戏和普通软件一样，无非就是前端后端，前端接收用户操作，传输到后端进行逻辑判断，输出结果给前端，前端把结果显示出来。立项！这太简单了，半个月时间做出来上线。然后无边无际的痛苦扑面而来。
“原生页面动画效果太差了，我们自己人都接受不了，客户肯定会吐槽，别人都是用游戏引擎做的”技术人员试用了一下半个月做出来的demo说道。高管抱着手机，正在研究竞品：“不，别人也有用原生页面做的”。技术人员反驳道：“但是玩家数量高的都是用的游戏引擎，原生页面的都半死不活”；于是经过了几天的技术调研，游戏放弃原生页面改用游戏引擎COCOS 2D。
游戏引擎之前没有人用过，大家边做边研究，一个多月后，demo出来了,新的问题又来了：“你们的游戏引擎太费电了，玩两把手机就没电了”，“有些手机比较老，不支持最新的引擎，我们为了照顾他们，把引擎的版本降低了”，“那现在这么费电怎么解决”，“那手机较老的那一部分客户还要不要了”经过漫长的权衡，决定放弃手机较老的那一部分用户。
“你们游戏怎么一开始的时候几秒钟是白的啊”
“升级的问题怎么解决啊”
“为什么房间的人突然不见了，我想把一个人踢出去，另外一个人却不见了”
“你们开发了几个月了，并发还没头绪吗，现在一个服务器开两个房间都有问题，A房间的指令都跑到B房间去了，全乱套了”。
九个月后强行上线，用户体验很差，流失严重，花大价钱做推广吸引来的用户玩一两把就走了。公司高层无法预见持续投入的效果，放弃项目。
1.3 需求收集和分析
需求的收集和分析涉及到大量的沟通工作，不仅要沟通业务，还要把业务转化为相应的产品文档。需求沟通整理人员需要具备一定的业务理解能力以及把业务转化为软件项目产品的能力。
需求的收集不仅仅是倾听客户的诉求，要能够真正理解客户的诉求，原封不动地把客户的陈述记录下来并整理成文档的做法是不可取的。客户虽然理解自己的业务，并且有时候客户也会准备文档，但是客户毕竟不能结合软件产品来价绍自己的业务，并且也很难在沟通过程中一次性把业务中的所有细节陈述出来，这就需要业务沟通人员（一般是项目负责人或者产品经理）对客户所提供的业务资料进行梳理，反复跟客户确认业务中有疑惑的点，保证需求的完整性和正确性，最后形成文档。
需求的分析工作是将需求中的业务描述转换成软件项目的产品描述，并大致规划处项目中的几大功能要点以及关键的技术实现思路，分析结束后要能得出该项目的可能性以及预算。
需求分析中涉及到的方法有很多，例如：功能分析法，数据流法，信息建模法，面向对象法，面向本体法，形式化法；这里就不作具体说明，可以自行查找相关资料。
中小企业应该重视需求收集和分析工作，很多中小企业为了节省成本或者是管理问题，压缩这部分的工作时间，在项目后期造成了不同程度的返工；压缩需求收集和分析的工作看似节省了一些时间，但是实际上因此带来的损失不可估量，后期全部推翻重来的案例也不在少数。
所以软件项目前期的工作就是不断地沟通和确认。直到所有的问题和细节都已经清楚。我们知道有一个传话的游戏，开头有个人说一句话，然后一个人一个人传下去，到最后通常得到的结果跟原话对比让人哭笑不得。软件项目通常复杂且庞大，一个小的细节不被重视的话，到最后修改起来都可能影响真个系统的架构。中小企业对于文档的重视往往不够，导致交付的时候客户提出某些方面跟自己的预期不符；写文档复杂繁琐，耗时耗力，并且经常修改，但文档是保证整个项目可持续进行、遇到问题可追溯的强力保障。每个企业可以根据自身情况制定文档的规范和模板。
按质按量按标准完成需求文档，是软件开发工作可管理的前提。
2. 软件项目开发管理
在项目开始之前，客户往往对开发周期提出较高的要求，这是因为客户并不理解软件项目的开发，或者是其他公司为了获取项目而给出的不切实际的承诺，面对此种情况，要尽量从客观的角度出发，正确地评估项目的耗时，并跟客户解释清楚，不要做不切实际的承诺，相信经过专业的分析客户一定能够认同并理解。
开发的阶段的主要工作有原型图设计，UI设计，数据库设计，系统架构（框架）设计，代码结构设计，编码标准制定，数据接口设计，编码，单元测试，功能测试，集成测试，系统测试，验收测试。这里主要针对中小企业在开发中的常见问题做一些讨论，具体的概念和定义不做过多的解释说明。
2.1 原型图和UI设计
程序的使用是通过UI来进行交互操作， 业务逻辑跟UI直接相关，绝大多数客户并不懂得设计知识，也不懂得编程知识，而原型为他们展示出了网站或APP的基本的框架或者说模型，让他们明白它们的基本外观和运作的机制。原型图是我们跟客户沟通的桥梁，是UI设计的参考，当设计和开发流程中有了原型之后，将会节省很多时间，降低成本。有时候我们会认为需求都确认清楚了，项目工期比较紧张，原型图设计的步骤可以省去而直接进入UI设计和开发阶段，甚至将UI作为原型给客户展示并介绍。很多时候我们认为节省了时间，实际上到了项目后期，因为前期工作没有到位导致的回溯、确认、修改、回归测试这样花费的时间往往非常巨大。
产品原型设计工作的内容包括规划总览、版本规划、产品目的和目标、业务说明、功能分类、规范文档、业务逻辑、结构布局、细节说明和逻辑判断等。
有了原型之后，团队成员沟通的时候不需要彼此发送大量的图片和PDF文档了，取而代之的是添加评论和链接，或者是原型工具内建的反馈工具，沟通更快，原型的修订也会更快。
原型工作的高质量完成，后期设计和开发可以同时推进，如果执行好的话，最终的产品体验和最终的原型不会相去太远，最重要的是输出的产品在功能上不会存在大的问题，因为原型阶段已经排除了绝大多数的故障。
UI设计工作建立在原型图的基础上，主要包括三个部分：一是图形设计，软件产品的产品“外形”设计。二是交互设计，主要在于设计软件的操作流程、树状结构、操作规范等。一个软件产品在编码之前需要做的就是交互设计，并且确立交互模型，交互规范。三是UI效果确认，目的在于确认交互设计的合理性及图形设计的美观性是否符合用户的预期，因为不同的目标用户群体对美观的理解并不一样。
2.2 开发管理
管理的对象是人，管理的结果是产品。中小企业的软件项目规模和复杂度普遍不会太高，多以小项目为主，项目周期一般比较短，很少超过一年的，所以在项目管理上也尽量减少不必要的环节，精简体系，注重高效和反应速度，以高速度和高质量完成现有项目，然后投入到市场，进行市场反应的观察。架构设计上建议从长远的角度出发，保证项目的扩展性。
2.2.1 开发文档的重要性
原型设计定型之后即可以开始进行开发工作，这些工作是可以和UI设计并行的，这也是为什么提倡扎扎实实把原型设计做好。开发过程中涉及到的文档有项目开发计划、数据库设计说明书、系统设计设计说明书、接口设计说明书、功能测试结果报告、系统测试结果报告、限制事项说明、提交一览表等等。
写文档是令所有人都很头疼的事情，几乎没有人喜欢写文档。可是反思一下，为什么我们会讨厌写文档，写文档会让我们去强制思考一些问题，很多公司使用意识流式的工作方式，即拿到需求文档和原型图之后直接进行开发，所见即所得，碰到问题走不通之后再去思考，需要返工的时候相互埋怨，这样的事情屡见不鲜。
其实在我们的管理工作中有个误区，技术人员觉得写代码才是自己的工作，写设计文档是额外的工作。这种错误的思想和管理理念应该被纠正，设计工作的重要性要大于编码，在项目中的时间占比要高于编码，设计工作做的严谨优质，编码甚至可以以高度的可控性外包出去。
写文档确实非常费力，要按照一定的格式格式去一个字一个字，一个段落一个段落，一个部分一个部分完成，字，语句，格式都不能出错。很多人抱怨，我是写代码的，是理科生，这个看上去像文科生做的事情，跟开发也没有什么关系，而且写作让我发疯。
有一个典型案例，某公司是一家互联网企业，某技术人员开发水平中等，独自负责该公司安卓端的开发工作，IOS端有两个开发人员，在该公司移动端任务中，安卓端一个人往往比IOS端两个人要更快地交付任务，上级甚是满意。岂料一年多以后该员工家中有事不得不离职。所有代码没有文档，新来的技术人员不能很快理解程序中的写法，同时又迫于任务时间的压力草草应付，导致代码存在两种风格。该员工呆了3个月之后无法忍受前人留下的一堆莫名其妙的代码愤然辞职。然后又来了一个新人，工作中逐渐发现项目中有两种风格的代码，该员工不得不应付两种风格迥异强扭在一起的代码，还要照顾进度追赶IOS，此时在进度上安卓已落后IOS三个版本，经过该员工与上级的沟通，安卓端人手增加到四个，为了年前重要版本的上线，还将一部分工作外包给了一个团队，在夜以继日的疯狂加班中，终于把打满补丁的程序推上线，等待他们的是永无止境的bug修复工作。
2.2.2 开发管理的重要性
为什么会发生上述案例中的问题。
首先我们来分析一下为什么一个人开发会比两个人快：两个人负责一项任务涉及到分工问题，比如如何分配任务，任务分配后如何协作，技术选型可能也要两个人共同参与，碰到问题需要两个人共同讨论。一个人则没有这些问题，用什么技术来实现自己说了算，都是自己写的代码，数据结构设计模式什么的，自己都非常熟悉，想要修改哪里一翻就能翻到，一看就知道代码为什么这样写，这样写是因为考虑到了几个外因内因，一清二楚。
一个人独自展开和维护一个项目的好处我们简单列举一下：不需要协作沟通，决策快、代码结构熟悉、代码内容熟悉、代码风格一致。一个软件工程就像一本小说，小说中的人物主线，结构，事件，各种铺垫伏笔，一个读者走马观花看一遍，是不可能去进行很好的续写的。软件工程也是这样的，代码错综复杂，每一行都可能是诸多思考后写出来的，两个人协作并修改对方的代码或在对方的代码基础上写代码，难免会感觉陷入泥沼，无法前进。
是不是参与项目的技术人员越少越好。在能保证项目进度的前提下，确实是这样的，兵贵精，不贵多。人数少响应更快，每多一个人，沟通成本上升、管理投入增加，但是人少的弊端也显而易见——抗风险能力差，任何一个人员的离岗对项目的影响都非常大。
能不能用更少的人，同时通过管理来避免风险呢，其实是可以的。在文档清晰详实并且整个开发的过程都监管到位的情况下是能够做到在不降低可控性的前提下提高现有人员的生产力的。
2.2.3 开发管理的步骤
项目管理人员（后面简称为项目负责人）需要具备一定的项目管理能力，同时具备一定的技术知识，很多公司项目负责人和技术负责人是同一个人。项目负责人侧重于整个工工程的管理把控工作，技术负责人更侧重于技术选型、难题攻克、系统架构设计以及代码质量的把控，两者的工作内容还是由很大的不同的，而且在一个项目中各自的工作量都不小。
项目负责人拿到产品需求和原型之后，需要立即组织内部会议，对项目的情况做完整细致的介绍，并组织大家讨论，确保对整个需求有一个统一的正确的认识和理解，然后将项目工作划分为几个模块分配到不同的小组。这是第一个会议。
各个模块的负责人，比如网页端、移动端、后端、UI设计，需要展开小组会议根据需求文档和原型进行讨论，确保对需求的理解没有异议和分歧，其中涉及到小组间协作的可以多个小组按照实际情况联合讨论，本次讨论目标是将工作内容细化，分配到人，同时评估开发时间。这是第二个会议。
项目负责人组织将各小组的讨论结果进行汇总，对有异议的问题进行处理，制定阶段目标，让项目参与者对目标有一个清晰明确的认识，并确认开发过程中涉及到的重要事项，比如各种文档的交付标准和时间，阶段时间划分，阶段验收标准等。这是第三个会议。
每一个阶段的结束，需要进行确认，完成时间的提早或者是推迟都需要进行改进，是对自身认识不足，还是对问题分析不足。结果是否符合预期，下阶段工作如何展开等。这是第四个会议。
项目完成后，项目负责人对项目过程中中遇到的影响项目进行的问题进行收集和梳理，并组织进行讨论，吸取经验和教训，项目中的亮点也需要进行发扬和继承。这是第五个会议。
除了以上五个会议之外，还要有三个表，工作计划表，工作任务表，工作实绩表，项目中遇到的各种问题导致提前或延期的，工作不要反复修改工作计划表，应通过实绩表进行记录，便于后续的对比分析。
通过对数个项目严格的管理和执行，相信团队的默契程度以及专业水平都会
得到大幅的提升。
3. 关于项目重构和重写
随着时间的流逝，现有软件功能渐渐不能满足使用，于是新的需求和修改被提出来，需求的增加和业务的变更让代码变得更多更复杂，“之前是一盘白切鸡，现在慢慢变成了宫保鸡丁，每次都要先做白切鸡，然后把白切鸡做成宫保鸡丁，既然这样为什么不直接做宫保鸡丁”。有小伙伴提出要重构甚至重写代码。然而很多重写“善始者众善终者寡”，最后被复杂和难以理解的原代码逻辑打败。
小的重构是需要经常进行的，每次代码的修改和新增都需要把重构考虑进来，不能等到日积月累的问题越来越多之后才想起来进行重构，这样最后往往就只能重写了。代码的重构是比较费时的，而且不容易体现价值，在很多企业，重构不被列入开发工作中。一个项目的参与者通常有多个，重构还有可能还会影响到别人，于是工作量稍微大一点的重构则无限期搁浅下去。
是否进行大的重构（重写）需要综合考虑，比如软件的可持续性，收益情况，重构的投入和重构后的预期改善等。
假设你的项目没有很多bug，稳定性也不错，或者暂时没有在现有框架下很难实现的新的需求，那么不建议进行整个项目重构（重写）。
重构时最容易发生的一类错误是没有能够完全的将原来的功能忠实的重现出来。很多开发者并不是手头的项目的原作者，并且项目也经过了很长时间的迭代，当代码越滚越大的时候，几乎没有人（包括原作者和产品经理）能够完全了解项目到底包含了哪些内容。当你看到重构后的功能和原来一模一样，并且测试人员也没有测出问题的时候，说不定哪个猴年马月添加进来的特殊功能，悄悄的被你干掉了。等到上线后，这个特殊功能的用户突然发现功能没了，于是过来投诉。所以之前我们再三强调文档的重要性。
如果原来的代码没有单元测试、集成测试，有条件的话一定要补充上。为什么测试如此重要？打一个比好，重构就好像对着一把老钥匙来配新钥匙，而测试代码则是老钥匙的模子，我们做出来的新钥匙要能够和这个模子全对上。这个模子越详细，则新钥匙可以正常开锁的概率越大。
4. 关于测试
软件测试的大体流程为测试需求分析和文档审查， 设计测试计划，测试设计（用例编写，测试脚本编写，开发，测试场景的编写），测试执行（包括执行测试的用例，执行测试的脚本，进行测试的开发，对测试场景的执行），发现bug，进行处理 ，回归测试，重复再次执行上述测试 ，出测试报告，测试验收， 测试总结
测试是软件开发中的一道重要的工序，很多小企业没有测试岗位，很多中型企业也对测试并不十分关注，程序员们更是对测试人员恨之入骨，认为他们爱挑刺，无事生非，明明自认为完美优雅的代码，在测试人员手里就是变得那么漏洞百出。
软件测试就相当于生产流水线上的质检，对产品是否符合预期进行严格的检验。测试人员承担着极大的工作压力，上线出了问题首先就是找测试，同时小企业为了节约人力成本，通常把测试给省略，所以测试是一个没事挨骂又不被重视的岗位。我们应该对测试工作足够重视，测试文档的建立和保存，对产品，程序员，对管理者都有极其重要的参考意义，它可能反应的是需求工作的问题，也可能是设计工作的问题，也可能是编码工作的问题，测试文档为项目工作的改进提供了极其重要的依据。
总 结
世界上没有快速成功的秘籍，一个团队的成长是一步一个脚印踩着坑过来的，在我们前进的路上，每踩过的一个坑都是宝贵的经验，每走过一段路都要对这段路上的坑进行总结记录，避免再走一次的时候碰到，也许刚开始我们记录的时候花费了不少时间，路程走的稍微慢一些，但是当我们再次看着记录走一遍的时候速度便快了很多，当记录深印在脑海中之后，我们就可以以无招胜有招的姿态畅行此路。当我们赞叹《笑傲江湖》中的独孤九剑可以用简单的招式破尽天下武功的时候，我们可曾知道，如果没有前期对天下武功的不断归纳总结分析，怎可能会得出这些简单的招式。
4198
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
