软件开发项目是为实现特定的应用而开发的软件产品，随着互联网的快速发展，越来越多的公司投入到软件产品的开发。

基于软件软件产品开发的规模简单分为大公司、小公司。大公司简单定义为参与软件开发人员500人以上。小公司简单定义为参与软件开发人员在100人以下。

大公司伴随自身的成长有比较完善的软件项目管理流程，从组织上有专门的质量管理、配置管理、项目管理等部门，从版本开发流程上有需求分析、系统设计、功能开发、系统测试、版本发布等。

小公司由于人力、物力的限制，无论从组织架构，还是开发流程上，很难按照标准的软件项目流程执行，需结合公司自身规模及业务特点，采用适合自己的软件项目管理流程。本文是对小公司如何更好的做出软件产品的一点思考。

1.明确公司的核心业务目标，并投入重点兵力

小公司最重要的是先活下来，渡过一段时期的输血期后，需尽快具备造血功能，即小公司领导层需基于公司的市场定位及对市场、公司自身的客观分析，明确公司短期/长期的核心业务目标，也就是公司最重要的事情，并将重点兵力投入到核心业务目标上，即首先要想明白让大家干啥，保证大家在做正确的事情。

小公司切忌啥都想做，铺的摊子的太大，公司自身人力有限，每个摊子上只能投入几个兵力，期间又不间断的有员工离职，某员工的离职可能导致某个摊子直接搁置，再费劲招聘新人重新搞这个摊子，搞到一定程度又有员工离职，又搁置，结果几年过去了，发现那个摊子都没有做出可用产品来，更别谈成功的产品。

举一个形象的例子，就好像一个人推石头上山，推到半山腰，这个人离职了，石头落到山底。招聘一个人重新将石头往山上推，推到半山腰，这个人又离职了，循环往复，石头就是到达不了山顶。而一推人推石头上山，其中即时有少数人离职，至少石头不会落到山底，只是向上的速度慢了一些，及时补充人力可以继续往上推，石头终将可以推到山顶。

2.基于明确的核心业务目标组建团队

上图为基于核心业务目标的组织结构图，整个业务目标为项目经理负责制。项目经理对业务成功负责，对公司（老板）负责。项目经理端到端跟踪整个业务过程，包括版本规划、功能开发、功能测试、性能测试、试验点测试、正式商用。

项目经理是业务目标实现过程中最关键的岗位，项目经理需既懂技术，还懂管理。项目经理的输入是公司既定的核心业务目标，项目经理需具备简单分解任务的能力，可对任务进行简单的工作量评估，下发开发任务给开发组长，下发测试任务给测试组长。

在整个业务开发过程中，项目经理要拉通开发、测试，保持项目开发过程中内部信息通畅，沟通交流通畅；对项目过程中的冲突点、关键点具备拍板的能力；对整个业务过程进行跟踪、管理的能力；并起到上传下达的作用。

项目经理一般建议内部培养，工作若干年且绩效优秀的开发组长、或者测试组长可提拔为项目经理，一则熟悉公司的核心业务，方便于后续项目管理中的业务决策；二则熟悉团队成员，在工作分配、任务跟踪中的沟通交流成本会大大降低。

开发组长和测试组长对项目经理负责，从项目经理处接收任务，并对任务进行分析拆解，分配给团队成员，在任务实现过程中需对团队成员进行协助、辅导，保证高质量完成项目经理分配的任务。

3.以测试驱动开发

项目经理分配任务给开发和测试后，开发组和测试组各司其职。开发启动功能开发，测试启动测试方案分析及测试用例写作，期间需经过若干次讨论，保证大家对需求（做的事情）理解一致。

按照项目经理的版本规划，在某时间节点开发需完成基本功能的开发，测试需完成测试方案设计及测试用例输出。项目经理将开发完成的完整的功能编译为可测试的版本，并内部发布，如：V1.0.0版本。

测试获取到发布版本进行版本功能测试，测试中发现的Bug，与开发人员沟通确认并给开发人员提交问题单。

基本功能版本发布后，开发人员负责解决测试人员提出的Bug，并及时合入到版本中，如果有需求变更，或者新的需求，可启动新需求的开发。

开发人员修改Bug的版本发布后，测试人员定期回归测试原来提的问题单，保证问题修改正确，且未引入新的问题。

经过如此多轮的测试，内部发布版本测试发现的Bug会收敛，收敛到一定程度可以正式对外发布测试版本，可安装到试点项目进行现场测试，并对现场测试发现的问题进行修改回归测试，最终发布正式商用的版本

软件项目开发过程中测试是非常重要的，发布版本最终是否可以商用，是依靠测试报告来做评估决策的，通过测试的多轮测试驱动开发进行版本改进，版本的缺陷逐渐收敛，最终形成正式商用的版本。

4.团队内的沟通交流机制

在整个开发过程中，需保证团队内部有良好的沟通交流机制，保证团队内信息通畅，大家不是在蒙头瞎搞。

项目经理需定期组织项目例会，建议至少一周一次，且固定时间，项目例会的目的：跟踪项目遗留问题，通报项目进展，反馈项目中遇到的困难，明确项目进度，及时发现项目风险，让大家对业务目标的理解达到高度一致。

为降低交流成本，每天定期进行碰头交流是最好的，例如：早上固定时间10分钟站立会议。让团队成员都清楚彼此的进展及遇到的问题，说不定你遇到的问题，他人也遇到过，且已经解决，能给你提供很好的解决思路。

从交流效果看，效果从好到差依次为，面对面->电话->即时信息（微信/QQ）->邮件，对于紧急且重要的问题且有条件面对面交流最好是当面交流。对于重要不紧急的事情，最好是先发信息给对方说明情况，如果信息交流能解决问题最好，如果信息说不清楚，及时进行电话交流讨论。通过信息交流可以给对方充足的考虑时间，且信息交流方便后续查询。

讨论交流的问题一定要知会到相关人员，比如测试人员需求助开发人员，邮件一定要抄送给开发人员的主管级自己的主管，对讨论形成的结论，及时发出会议结论，并知会相关人员，最大程度的保证大家信息一致。

总结，小公司的软件项目，首先聚焦核心业务目标，基于合理的资源组织架构，特别强调项目经理岗位的重要性，通过测试驱动开发，保证组织内部通畅有效沟通交流，通过多轮的版本迭代，最终产出正式商用版本，以达到预期的业务目标。