对管理层的一些建议

阅读量：5236 次

发布时间：2019-06-14

本文共 3662 字，大约阅读时间需要 12 分钟。

本来是想把这些话写邮件给公司的老总、技术总监的，但是现在看来，似乎已经没有了必要，因为他们认为这个不重要！而且总是说，现在先把项目搞好，这些以后再说，你怎么总是花时间搞这个？我看你项目已经延期很多了！做事要分清轻重缓急、先后顺序！你不要总是说，你先完成了再说。你可以给xx提建议啊。。

我也不知道说什么好了，或许我现在所在的公司根本就不是技术型公司。只是我认为，因为现在的管理方式、项目代码的架构，经常出现的各种问题，无穷无尽的奇妙的bug，各级人员之间的冲突，各种的压力，已经让开发人员任务很重了，需要减负，更没有精力研究新东西，不能一出错就怪罪开发。。我和他们意见很大分歧，我认为所谓磨刀不误砍柴工，先进的工具、技术可以大幅提高工作效率，难道不是吗。需要吐槽的太多太多了，提出这些建议也是想公司变得更好，我也想自己一个人完成改造，奈何没有人支持我，领导也不重视，所以就不管了。不过竟然已经写好了，我就还是发表出来吧！写得有些乱，很多很多的细节，囿于时间限制，自己水平也十分有限，不能说得太细，不能进行细致的分析。下面是我的建议：

项目管理：

构建：使用mvn 构建吧，至少要搞个ant吧。现在所有工作全手工进行，这样真的好吗？我们现在发布新的版本，麻烦又容易出错，而且很慢。发布个补丁，就更加效率低了！现在我将公司的主项目的庞大的 pom已经配置好，mave私服我已经搭建好了，就等切换了。

升级：升级jdk吧，现在都jdk8了，公司却一直使用1.6，各个jar也是非常老的版本了。。这样很多的先进的功能是都无法使用的。。

版本管理：

使用git 做分支管理吧！现在公司的产品分支多，而svn真的效率低，因为他只有一个远程的版本中心，每次操作都要拷贝来拷贝去（这个大家都知道）。而git的分支管理也比svn强大太多了！ —— 用过用GIT+TortoiseGIT都会发现SVN太低效了。。。听说svn也提供了补丁功能，但经过研究，其使用也不是很方便。内部git 服务器我已经搭建好了，只等大家一切来使用了！

缺陷管理：

使用bugfree/mantis进行 bug管理吧，而不是TD，——TD都十几年前的古老的产品了，界面又丑又不好用，而且功能非常有限。

软件测试：

使用junit 单元测试-- lr压力测试吧！而不是还是原始社会一样使用手动的点击进行测试。做测试经理的也要专业点吧，而且一定要测试好，不要等问题到了实施客户阶段才去解决—— 这样成本很高，很麻烦。。

推行自动化测试脚本，自动化部署，自动化构建吧，不然真的人手不够，就算再招很多人都还是会很累的！制定好的测试方案，不能每次开发做了些许小小的改动，你就又全部重新测试，——这样确实会很累而且抵消。

做测试的，绝不是说任何人都可以完成的点点鼠标就可以了的，也要会写代码，需要懂一些专业知识，需要提高测试覆盖率。。

提bug的—— 不能乱写一通，必须的东西要说清楚吧必须的步骤，必须的截图，日志，而且尽量的缩小范围。减少与开发的沟通成本。。另一方面，开发修改完一个bug，提交了重要的更新，应该通知所有相关人，适当讨论，是否应该，否则引起各种bug。

沟通准则：

电话沟通：与客户沟通的时候，应该说，您好，我是xx公司的xx项目经理/负责人，（上次我们在xx见过面的），想和你讨论下xx问题，请您协助下，可以吗？而不是说：我的xx公司的，我是xxx，—— 自我介绍的时候，最后面是一个“的” ，让人觉得不专业！就说，我是xx公司的xx(职位/负责人)，这样别人听着舒服些。

内部人员沟通：

　　qq讨论组的建立准则：对于像我们现在终于的项目型公司(一个产品，N个项目)，应该每个项目建立一个qq讨论组，但是又不能太多，一旦建立好之后，不能随意的改动，并且要维持固定的结构。

　　私下交流与群组交流：个人认为应该少私下交流，应该全部在讨论组里面讨论，否则容易出现各种小团体，小党小派。—— 私下交流和群组交流的效果是不同的，同一个公司，就那么大的地方，才150-200平米的办公室，总是通过qq来讨论，真的好吗？

交流方式有很多种： qq、一对一座位交流、远距离喊话、会议室怎么进行问题讨论和分析。但是每次沟通都应该选择适当的方式。

开发规范：

制定开发/编码规范吧！javadoc ，设计文档，需求文档，开发文档。。。都要必须出来！不然，这代码还怎么开发下去啊！现在的很多东西混乱，只能靠看代码，而代码少注释，深度耦合，低内聚，各种代码泥潭，各种陷阱，各种坑爹，

项目更新：

制定代码更新，补丁准则吧。不然，这代码还怎么更新，打个补丁就3、4小时了，这工作还怎么进行下去。。。。特别是多人开发，并行开发的时候。

公司氛围：

搞好公司内部气氛- 技术氛围吧，技术群是用来讨论技术的，而不是死群。每来一个新人，至少有对新人的欢迎吧，老员工带头吧，所谓的资深高级员工都到了哪里去了呢？怎么都不吭声呢？每次有人在公司总群里发起了话题，应该有人接上才对啊！怎么能没有吹水呢？老总说话都没有拍马屁，这真的好吗？死气沉沉的公司氛围真的好吗？难道每个员工都在想着走吗？为什么这样呢？

招揽人才：

招揽更多高级人才吧 .. 否则，现有人才是很难推动公司发展的，特别是技术部，不能一遇到比较难的问题就回避，选择其他相当简单的却不是最好最合理的解决方案。所谓Engineer重点在于其engineering的能力。高科技公司不重视人才不就是寻死吗？

开发/二次开发/实施准则：

没有规范，没有规矩，没有有效的文档，沟通始终是一个高成本的事情。常常看到的是，新人旧人的沟通非常麻烦而且低效，达不到预期效果。而且离职员工的交接也会变得没有意义。

测试机器的分配：

应该是易找而且已经部署好。应该是每个人一个或两个虚拟机吧，而且应该按照顺序来，而不是胡乱分配，自己的使用自己的虚拟机，而不能动其他人的，测试机器的分配应该也要有个章法吧！能把所有的机器的分配情况列表出来，并标示其功能，安装情况吗？ —— 这样别人就不用每次找个机器问来问去了！而且下次又忘记！

加班管理：

每周1/3/5作为加班的时间，而不是每天下午6点就喊，有没有要加班的？！这个太落后了。。

奖罚管理：

技术人员引入了一门新技术，大的改进，革新，颠覆，应该给予相应的奖励，否则，应该指责。。

引入前端工程师：

。。前端是我的弱项，但是目前的前端也是混乱，样式调整全靠一个美工/UI来完成，而他竟然不懂js 代码。。。于是搞后端的同时也要搞前端，同时还有搞数据库。相互之间没有交流，不能共同学习进步，每个人都要求是全栈工程师，真是苦不堪言。什么都搞的结果是什么都不精。

座位、电脑配置：

座位不要隔开太多了吧！应该一个项目相关人等围成一圈做，不要有隔板。每个人的电脑不要太低了吧，至少要8g内存， cpu i5以上，双显示器。

技术氛围：

多多交流经验技术吧，不然老员工开发的代码，只有老员工懂了，新员工来了也没有一个很好的，系统的，专业的培训，你让新员工如何快速融入公司，如何进行开发？老员工之前的工作没完全做好，接着又调去开发新功能，然后留下一堆没有优化的各种缺陷的代码给新来的人做维护，这样真的好吗？

写代码写得多/快，功能点多，不是你厉害，而是可拓展性，良好结构，容易读懂才重要， —— 若是靠复制黏贴，危害十足，往往是造成痛苦的根源。

公司组织架构：

分工要明确，责任要明确，任务也要明确。界限要尽量清晰。所谓项目经理，一定是做项目经理的工作，而不是什么事情都来插一脚。但是他又什么都做不到最好，做简单的事情花很长时间，反复各种bug，然后还说这个是开发的责任。。。

代码缺陷检查：

测试是对开发完后的代码的检测，但是，还有一个必须的步骤是，对刚刚开发完进行缺陷检查，比如代码的格式检查，警告的排查—— 我在华为也学习到一些基础，java代码中，有些警告是可以忽略的比如泛型，但是最好，还是认真的处理下每个警告的比较好。代码规范的重要性：我想查询 aa = xx,但是有人的写法是aa=xx, 于是就查询不出来了。。