敏捷，文档，人才，文化——谈小公司研发管理

爱被打了一巴掌 2022-07-15 11:06 174阅读 0赞

> 下面是最近对公司研发管理的一些思考，和大家一起讨论。
> 
> ## **一：关于敏捷：** ##
> 
> ### 1）敏捷是否适合电信行业？ ###
> 
> 对于想互联网这样“小而快”的行业，[敏捷][Link 1]开发无疑是适合的。但是对于电信行业这种“大而笨”的行业，是否也适合？我一直有这样的疑问。
> 
> 电信行业有他自身的特点，比如，需求变化一般不大，相对比较稳定；对稳定性的要求比对快速发布的要求要高，如果稳定性有问题，影响一般很严重；一般采用更底层的语言（比如c）来进行开发。将敏捷理解成“裸奔”，通过牺牲质量来达到快速交付也许有些狭隘，但是在快速的交付的同时保持高质量，这对开发人员和开发工具（特别是自动化[测试][Link 2]工具）的要求较高，我们很难满足这个要求，一般小公司也很难满足这个要求。况且很多项目对持续交付的要求并不强烈。
> 
> **更具启发的一种思路是，不要把敏捷认为一种流程（比如scrum）或工具，而是一系列行动的思想和原则——他本来或许就是如此。**这样的话，我们可以适当的引入一些有启发的思想和原则来武装我们的大脑：

> > 1、个体与交互 重于 过程和工具。
> > 
> > 2、最有效的沟通方式是面对面的沟通。
> > 
> > 3、自组织团队。
> > 
> > 4、要做到简洁，即尽最大可能减少不必要的工作。
> > 
> > 5、定期反省，思考对团队和工作的优化。

> 对于流程优化，我的基本思想还是缺陷驱动：[缺陷驱动的流程优化和技术引进][Link 3]。
> 
> ### 2）小公司与敏捷 ###
> 
> 小公司在骨子里就和敏捷开发走得很近，也许他们真的有什么“血缘”关系？
> 
> 有几点是小公司生就具备的，比如看重个体交互胜过过程工具，看重工作的软件胜过面面俱到的文档，看重对变化的响应而非遵循计划（有的时候可能没有计划）等等，虽然做的不是尽善尽美，但是有这样的价值取向。
> 
> 有一点我印象比较深刻。在上一家公司的时候遇到过一件事情，由于工作中正式沟通使用邮件，两个开发人员背对背坐着，为了说某件事情发邮件发了半个小时。那个时候我也有邮件综合症，刚到现在这家公司的时候，我问同事有没有邮件系统，他好奇的问我要做什么，我说可能要沟通事情，他笑着说喊一声或者走过去就可以了（通信基本靠吼）。
> 
> **对待开发一定要摆脱那种非此即彼的思路**。我们为什么非要在结构化开发和敏捷开发中作出一个选择？为什么选择了敏捷就一定要排斥结构化开发？要摆脱这种非此即彼的思路，就要用渐进的方式来思考他们，看下图，我心中的结构化开发和敏捷开发：
> 
> ![0_13138413670iWF.gif][]
> 
> 从左到右，从结构化到敏捷，都是一个渐进的过程，代表了几个不同的价值取向：
> 
> 流程和工具——个体和互动  
> 详尽的文档——工作的软件  
> 合同谈判——客户合作  
> 遵循计划——响应变化
> 
> 我们要选择的，是根据自己的实际情况，选择一个自己的位置。针对我们目前的情况，我们的位置以及理想中我们的位置：
> 
> ![0_1313841587YUun.gif][]
> 
> 我们目前的位置并不是说我们敏捷的很远。过犹不及，我们之前一直受一些问题的困扰，比如过分重视工作的软件忽视文档，甚至没有文档；过分重视个体和交互而基本没有流程；响应变化而很少有计划等等。我想这可能是很多小公司都可能面临的问题。
> 
> 结合我们的项目特点以及我们团队的特点，我们理想中的位置应该是在结构化开发和敏捷开发之间而偏向结构化开发。具体的措施可能是宏观上采用结构化开发的思想，而微观上这借鉴敏捷开发的思想。至于如何达到这个效果，还要继续实践。另外，根据具体项目的不同，可能采用的方法也不尽相同，并不是我们所有的项目都处于此位置。
> 
> 一个比较另我纠结的问题是，如何从现在的位置移动到理想中的位置？一定要体验一下完全的结构化开发，理解一下结构化开发的痛才能够移动到目前的位置？直接引入敏捷的思想是否会出现拔苗助长的现象：即开发人员没有相关成长体验、无法理解敏捷开发而对它存在抵触？
> 
> ## 二、文档 ##
> 
> 用一个词来描述我这几年开发对文档的体验，最贴切的也许就是“**鸡肋**”了：
> 
> 1、食之无味：在上一家公司体验过完全的结构化开发，对文档要求相当严格，开发过程中花费了巨大的精力写了大量的文档。而到了项目后期，随着需求和设计的更改，保持最终的程序和文档的同步又耗费巨大的精力。关键是，开发完毕后，大部分文档就被束之高阁，不见天日 了。
> 
> 2、弃之可惜：在这家公司也遇到过时间很急，匆匆忙忙开发而没有文档的项目。到维护期时，做了什么，怎么做的都无从查起。特别是遇到人员流动的情况，更加难于处理。
> 
> 之前写过一篇文章：[软件开发过程文档如何写作？——“文档==鸡肋”？][Link 4]
> 
> 也许应该利用“二八定律”来对待文档：花20%的时间来记录文档，获得80%的价值。至于另外20%的价值，也许花费80%的时间，这一块可以放弃。关于如何写这20%的文档，可以参见上面的这篇文章。
> 
> ## 三、人才 ##
> 
> 这是一个比较沉重的话题。
> 
> 每年总有那么一段时间，和自己工作多年的同事要离开。其实这也是没有办法的事情，公司的规模，成长的空间和机会决定了他能够留住多少人。要想留住更多有经验的人，必须要有大的发展才可以。至于如何才能有大的发展，涉及的因素相当多。如果真的有这样的机会，我想很多人才还是会选择留下了的。在一个公司成长壮大的过程中，会产生很多的机会，包括职位，技术，物质等各个方面。
> 
> 加之整个行业风气有些浮躁，小公司在人才问题上有些伤不起。
> 
> 在招聘方面，主要的渠道还是应届毕业生。小公司在校园招聘上处于劣势，无论是薪水，福利，品牌。即便是其他一切都相当，我想很多学生还是会选择大公司。所以我们只能招聘大公司“挑剩下的”。不过这个不是什么问题，多年的经验让我们发现“人才是培养出来的”。只要毕业生爱学习，会学习，踏实，招过来好好培养一下，在工作中多给他们一些机会，他们一般情况下都会成长的很快。我总是感觉（也是我个人的体会），小公司提供给新员工成长的机会，可能会比大公司要多，特别是在技术方面。
> 
> 不要担心这样的团队是取得成功瓶颈。看一下《团队之美》中对丑陋的团队的描述，看一下他们要如何才能战胜明星团队。另外也可以参考一下刘邦的创业团队：[创业的首要因素][Link 5]。
> 
>   
> 
> 
> ##    四、文化 ##
> 
> 一家小公司的文化很多都取决于它的创始人，应该是创始人性格的写照。
> 
> 一个企业最难改变的也许就是文化了。想在一个企业中创建一个文化迥异的团队是一个非常大的挑战，要面临大环境的同化，非得有强大而坚韧的影响力才可以。
> 
> ## 五、生存和发展 ##
> 
> ## 六、年迈的小公司。 ##

[Link 1]: http://lib.csdn.net/base/agile
[Link 2]: http://lib.csdn.net/base/softwaretest
[Link 3]: http://blog.csdn.net/chgaowei/article/details/6571235
[0_13138413670iWF.gif]: /images/20220715/411c9dd13ddf45319858592c43743508.png
[0_1313841587YUun.gif]: /images/20220715/d5e00f1ca6694388975b034477309c44.png
[Link 4]: http://blog.csdn.net/chgaowei/article/details/5945461
[Link 5]: http://blog.csdn.net/chgaowei/article/details/6041734