小型信息化团队在开发管理过程中的最佳实践
卢存业
[摘 要] 在信息化项目管理中，产品的功能以及质量，是我们项目管理的终极目标。而对于达成这个目标，我们就必须采取适合我们团队的管理模式。敏捷开发、X P（极限编程）这些软件工程方法学提供给了我们很好的理论知识，但是实践过程却很少有团队尤其是小型团队能够从这些方法学中收益，归其原因，还是管理者在执行过程偏离了方法论本身，又或者太在意理论的基础，却忘记了实践中的经验积累和过程优化。文章将根据多年中小型团队的管理经验，并借用敏捷开发为例，与大家探讨一下项目管理过程中的一些实践建议。
[关键词] 小型信息化团队；开发管理；实践
中图分类号：G221 文献标识码：A
一、小型信息化团队在开发管理的相关介绍
（一）管理定义
管理的定义很多，在《百度百科》中的定义为“管理是指一定组织中的管理者，通过实施计划、组织、领导、协调、控制等职能来协调他人的活动，使别人同自己一起实现既定目标的活动过程”。这里的计划、组织、指挥、协调和控制是管理的职能要素。而文章对于管理的理解还要加上利于团队各成员团结协作和发挥每个人能力的道义和方法，使我们的管理实践能够摆脱字面的生硬，让我们的管理变得更有活力[1]。
（二）敏捷开发
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征 独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。这里对于敏捷开发需要多做解释的是敏捷开发不是见机行事、也不是越快越好；它的核心是团队拥有自己的统一的工具，管好自己的需求，而且整体过程可视化。
二、小型信息化团队在开发管理过程中存在问题及措施
（一）管理缺乏统一的工具
笔者认为工具其实就是管理制定和实施计划的载体，对于中小型团队的我们来说非得采用高大上，业界领先的工具就一定是好的。我们要做的还是要贴近我们的团队规模以及使用这些工具的成本。其实就算是excel表格，如果我们运用得当，其实也可以发挥出意想不到的作用。而在这里我们实际上应该抓住的这个统一工具的本质，是用于用户团队统一目标、计划的传达、人与人信息传输的一致，降低团队的沟通成本，同时大大提高团队工作效率的同时，又能够保证团队的工作质量。
所以，在实践过程中，要让这个工具保证计划实施从上到下的传递是顺畅的，同时，完成情况以及问题的反馈也能通过工具更好的进行传递和有效互动，因此，工具用途非常大的，哪怕它就是一个不起眼的excel表格。在现代互联网产品的研发时，每个成员都要拥抱互动变化，这样沟通工具就成了一个最大的开发成本，统一的工具就变得非常重要，从实践的经验来说，这是非常实用的[2]。
（二）代码千奇百怪、不受拘束
这个问题是小型团队普遍性存在的一种痼疾，一个潜在的原因是对于小型团队来说，培训制度不健全是一个问题，统一的代码规范不并一定有；这些原因决定了研发人员在开发的过程中，思维没有任何拘束，想到哪写到哪，怎么省事怎么写，最终导致的结果是每个代码都各具特色，或者说千奇百怪。从而也造成了这些源代码很难读懂，同时也会出现各种各样的质量问题。
针对这个问题，公司和团队本身应建立规范标准，但是，在这里所要传达的经验规范标准，不一定从头开始，随着我国信息化产业发展这么多年，很多大型公司的一些代码规范标准已经做到极致，可以延用大型公司代码规范标准即可，因为在特定的技术研发领域内，与其他大型公司的差距不会有太多的差异。
在实践过程中，抓住的关键点是要在最低成本的角度建立起这种约束规范，因此，只有这样研发人员和其工作人员才能遵循统一的规范标准去做事，而且所做的结果会避免大部分错误，同时还能增強所写代码的可读性，从而不断提升研发产品可维护性以及团队整体的工作素养。
（三）以产出论英雄，忽略质量为王
这个可能是老板最喜欢的一条，就是天下武功为快不破；所以很多时候在敏捷开发时，可以进行随机应变，只有这样，研发人员形成了只要做完就提交的习惯。
但是在实践的过程中，应该如何去改正工作人员的懒惰性。这里主要包括以下两个方面：首先，实践方案是绩效考核约束团队成员的一种常见的制度约束方法，也是一种最为普遍的手段。这种方案虽然普遍，但是还是值得肯定的。相应制定考核制度是没有任何问题的，可是最大的问题是制度本身是否起到了相应的作用。如某公司CEO和人事商定一个考核制度，按一定量进行计算开发人员的绩效程度，最后结果是除了研发人员和其他人员都有绩效。这失败经验告诉我们，专业的人做专业的事情，只有完全了解他们的运作机制才能制定切合实际的制度，而不是听了几个词汇，觉得和结果以及质量是密切相关就直接拿来使用，而是抓住问题的本质去制定制度，如bug数量确实决定了人员的水平，但并不是bug的初始数量，而是一个基于时间线的收敛趋势，如果持续一段时间的修改，bug的数量还是没有改善才是真正我们考核的地方。其次，实践方案应是带动团队人员互相监督，让人员互动起来，尤其是完全的开发人员内部也要具备鲶鱼效应，驱动大家对于自身自觉的进行自测，不然就会收到来自不只是测试，而是开发人员对于产品质量的问询，从而督促大家自觉地形成自我约束，相互沟通的习惯[3]。
（四）风险意识比较差，向后兼容意识不足
由于团队人员比较少，尤其在工作量大的情况下，大家只忙于当前功能同时可用不报错即可的心态，容易造成对于已发布功能的潜在bug。
这里举一个案例，例如对于A接口进行改造，或者比较极端，研发人员并没有调查该功能是否被其他地方使用，仅仅是需求说这个功能已经废弃，就直接删掉，这样在使用的地方就会报错，从而产生验证的产品质量问题。
最佳实践解决这个问题有两种方案，一个是我们要调查到每个使用这个接口或函数的地方，了解清楚每个地方所有的逻辑，在充份评估的基础上进行改造，保证所有使用该功能的地方保持正确的持续运行。另一个方案则保留该接口或功能，新增一个类似功能并作为版本号的升级进行改造，这样使用新功能的地方用内新版本号，而原来的地方则保持不变，从而保证向后的兼容性。这些也是在敏捷开发管理过程中保证可持续运行的一个重要原则。还有就是小型团队，不止是需求，人员的变动也是频繁的事情，在实践过程研发、测试、产品等人员也要保证最基本的互补机制，保证在人员流动的时候保证项目运转的稳定性和可持续性。
三、结语
总之，我们可以从技术、制度和文化三个角度做一个归纳，管理的最佳实践是营造合适的文化，制定人性的制度，让技术充分发挥它本身应用的价值，从而达到我们既定的目标。我们去做管理不止是让团队为了绩效为了工资去完成工作，更重要的是在完成了工作的同时我们也应该给员工创造一个可以获得荣誉感和使命感的文化氛围。
参考文献：
[1]薛琨.高职信息化课程开发团队建设与项目管理策略研究[J].中国教育信息化·基础教育，2018（12）：41-45.
[2]李丽君，郭宗和，焦学健.基于科研团队信息化管理的研究生学术能力培养研究[J].教育教学论坛，2020（8）：331-333.
[3]江骏.信息化教学平台中WEB应用开发技术课程的应用研究[J].消费导刊，2019（49）：70.
