码迷,mamicode.com
首页 > 其他好文 > 详细

对管理层的一些建议

时间:2016-03-27 11:09:17      阅读:382      评论:0      收藏:0      [点我收藏+]

标签:

 

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

人员管理:

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

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

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

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

 

对管理层的一些建议

标签:

原文地址:http://www.cnblogs.com/FlyAway2013/p/5300440.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!