对管理层的一些建议

Posted 2020-06-29 10年 Java程序员，硬核人生！勇往直前，永不退缩！

 

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

人员管理：

良好管理应该是 良好规则的制定/实施/推行， 最佳实践的试用和实践， 而不是以威视逼人。。

对于员工，应该对于每个人都给其指定一套升职路线，给予升级空间。而不是对下级员工不闻不问，明细的区别对待—— 开个周例会，分了好几批。。。

采用最先进的管理技术，开发技术， 比如极限编程、结对编程、敏捷开发。。。

关于管理，有太多的东西可以讨论， 个人本身也不太懂，不多深入探讨了