小软件部门的开发规范

[hust_wangyajun]

我是一个软件部门的研发工程师。部门结构：一个硬件出身的领导，一个技术出身的部门经理，一个年龄较大的程序员（40岁），两个应届生（现已有1年半经验），我自己（至今工作两年半C++），一个应届（软件技术上比较薄弱，系统工程师），一个女研究生（虽然是计算机专业，但并没有写软件的天赋和兴趣，一直做文档和测试）。我因为写代码比较快，工作比较积极，成果也比较显著，为了完成部门的核心方案加班不少，算得上是主力军。领导也很器重我，也很重视我的意见，提拔我上位做小组长。现在这个方案已经趋于稳定，但我还不敢说成熟，已经有不少公司与我们签订单合同。
但现在面临的问题是，我觉得部门开发的规范化很差，我看了华为的《软件开发行为规范》，觉得上面的规范确实很详细，我们很多也其实都有做（比如质量认证SQA），产品化，但是就是一片混乱，没有章法。软件的稳定性，程序的稳定性不敢保证，测试也不详细，完全靠程序员的细心，个人的能力。天天忙里忙外缺少调理，效率也不高。如果按照规范来，人手成为很大问题，很多文档如《需求分析》《软件开发计划》《概要设计》《详细设计》《需求管理》等等真的很难都实现，人员素质也参差不齐。领导最近招人估计也是应届生没经验。对于这样的小软件项目如何让开发更加规范，更有效率呢？

[缪军]

8个人的部门,只有3到4个人能写点代码,连个设计师都没有, 从人力资源的角度说,已经是亏本了, 这种情况搞任何规范都是得不偿失的, 讲义气就可以了, 等你们能够真正产出的开发人员超过6个人再说规范吧, 想提高效率,不如多想想能为开发人员做些什么,能为他们提供更多的支持才是正确的思路(而不是要求别人这样那样)

[ckc]

达到目的是需要代价的，或者说需要成本的 你为了提高工作效率想规范 可是你这样的环境，规范本身就需要付出相当的代价。 你的同事，你的领导对规范有什么认识？大家都觉得规范有必要有意义吗？ 不管是谁对这个事情不以为然，将来都会成为阻力，这些全都是需要付出的代价。 如果代价太高，高过了规范带来的效率提高， 那么就应该放弃规范，或者说放弃过高的规范要求。

[hust_wangyajun]

经过我的建议，领导决定部门开一次集体会议，每个人都发表自己在工作遇到的问题，阻力，效率低下的问题，并提出了各自的解决方案，建议，或者认为需要遵循的规范。因为各自对别人的活动都不熟悉，只是谈谈自己的工作这一方面，所以如果按照规范比较是对每个人都有利的，对每个人的工作也都有支持作用。有的同事谈到了各自的工作没有交集，需要相互学习，共同提高；有的同事提到了缺少备份媒介，每个人配备两个U盘；有的人表达了因为计划不知如何写才能保证十全十美感到困惑；有的人觉得应该建立相互检视机制（不是纯粹检查或监督，而是检阅别人的工作内容），不仅保持质量，而且使自己工作不至于太单调。我建议了统一建档机制，每个大小问题统一建档保存，定期相互学习，小到一个个人经验（如如何安装GCC），大到一个研发主题（自动更新设计）。

[hust_wangyajun]

现在会议已经开完了一个星期了，每个人配备了两个U盘（32G，16G），领导买了一个讨论专用纸黑板，每次讨论的内容都会记录在案，每个专题一页。其他的暂时也没有看到明显的变化，但关键是大家并没有对讨论的结果感到反感。我很希望的提议能够实施，那样就可以互相学到多个的经验和技术，促进团队共同进步。

[hust_wangyajun]

附上个人对问题建档的提议方案： 在团队内部建立常见问题建档机制，档案存储问题的分类，描述，提供者，参与者，解决者，解决方法，解决时间，修订时间，验证次数等。提供者应该给与鼓励和支持。解决者应该享有问题成功解决获得考核奖励的权利和对问题解决方案进行合理解释的义务，并在问题后续延伸和扩展时积极参与跟进的义务。问题不一定是疑难杂症，可以是比较简单但又专业的知识，比如ssh认证，比如双网卡绑定都可以。问题建档还应该体现出集中性，关键性，能直观的描述和有条理的解决思路。问题可以被重定义和更新，覆盖，合并，分解，但都必须有一个更新日志给与详细记录。详细记录问题重现机制，检测方案，输入输出，适用范围，出错情况等。问题建档可以使用书面档和电子档，应当有多个安全的备份。每个问题建议生成一份报告，作为问题的最终存档方式，报告的格式应该相对统一，使用面向对象的思路，尽量涵盖问题所需求的各种属性，可以体现出问题的独立性。报告可以让大家阅览，并根据难度，重要性，解决方案合理性进行打分评判并由领导批阅，可作为基础资料学习，可以作为工作成果考核。这些常见问题应该在部门内部进行培训，达成共识。花费少量的时间进行培训不仅可以让大家检验问题，增强问题及其解决方案的实用性，还提高了成员的技术水平，更利于项目团体协作能力，提高团队每个人的综合能力，提升团队整体战斗力。问题存档对系统恢复，系统修复，人员培训也有积极作用。我主要列举以下几种情况： 软件、工具使用类 1 基本工具，如windows VS2012打包工具installshield的使用，Linux 和windows下的网络测试工具，TCP、UDP测试包测试工具，VSS版本控制工具等。 2 调试小工具，如以前写的swapbuffer工具，帧率带宽计算工具。 3 基础版本程序，如最原始的UI程序经常在系统故障时用来做调试，应该是每个人都会使用的。Sail库的原始版本也应该是。甚至发送程序的拷屏版本也是比较基础和稳定的。 4 编译平台，VS2012，QT，PYCharm，g++、gcc等工具的常用方法，以及编程语言的语法应当被每个人熟悉。 硬件、工具使用类 1 主机基本结构，硬件需求，交换机，显示器，服务器，其他特殊硬件如采集卡，摄像枪等介绍，价位等。 2 装机，装系统，网络设置，bios设置，维修方法，注意事项 经验总结类 1 过程经验（重要）：Hiper系统安装过程，双网卡绑定过程，SSH认证过程，系统环境变量配置过程，大图片安装过程，大图片使用方法，自动开机设置，计算机自动休眠设置，摄像枪网络设置。 2 问题收集：是问题解决的关键步骤，问题收集是问题定位的必要步骤，所有的问题解决都应该先从问题收集开始。 3 错误解决：大屏起不来，自动开机失败，大图片启动失败，发送程序上墙失败，大鼠标上墙失败，网络ping不通 4 工作成果展示，核心代码分享学习，工作流程介绍。如python的代码统计了系统信息，是如何具体在代码中做到的，而不是彼此之间没有交流。这个成果应该建档，供大家学习。可以提升自己和大家的水平，也可以使工作成果更加坚固，还可以作为业绩考核的标准。如果有时间可以集中培训，未参加培训的同事，也有建档可供私下学习交流。 5 工作专题报告，如自动更新问题解决方案，大图片问题解决方案，大鼠标问题解决方案，Hiper 发送端SDK库解决方案等，大屏幕截图解决方案。也可以是模块解决方案，如UI声控子模块解决方案等。 6 个人小经验（可以详细到一个好的下载链接，一个程序安装的方法，如何方便激活系统等）

[对酒当歌今夕何夕]

scrum 啊，你这个规模 敏捷就好了 kanban也行啊

[以专业开发人员为伍]

还没怎么着呢，就学起来国营企业IT部门、管理部门那一套文山会海而慢慢磨噌招数了。 你这种会，一个公司3年开一次就够了。

[以专业开发人员为伍]

推卸责任的人其实有一个他不自知的技术瓶颈，他不知道如何保证质量，只会给同事们压力，然后事后2个月之后才来说三道四。 这种pm，辞职，工作3年之后再来做pm，才是明智的。

[cmm2cmmi]

我觉得作者在思考如何持续改进，是值得肯定的 可以在执行过程不断的回顾思考持续改进，但一些原则要坚持一段时间才能看到效果 华为的规范不一定适合你们可以借鉴参考 我在华为做三年多QA了，华为有自己的质量问题，有自己企业文化的问题，但规范是有各方面制约的，要依靠流程的力量，以人为核心，技术不断进步才能有高质量的产品 一家之言仅供参考，祝你成功～～

[gaof_lee]

依据企业的规模，需要不同的体系，如果只有一两个人，根本不需要任何体系，自己做主或两个人商量着来就把工作做了。待人员稍微增多，达到十人左右，这时候就会因为技术问题发生冲突，这时候就可以建立一套技术体系来约束大家，保证工作的顺利进行，再大一些，到了二十人左右的时候，就需要一套管理体系来进行约束，因为技术体系不够用了，再大一些，到了50人左右，那就需要一套质量体系来约束，再往更高层次，那就必须建立研发体系，通过各种规范来保证各部门和人员之间的配合是出于可控范围内。 对于楼主所说的这种规模，建立一个简单的技术体系我觉得就够了，更高层次的管理体系或质量体系、研发体系将不会带来任何运营上的优势，反而会增加企业的运营成本的。