对管理层的一些建议

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

人员管理:

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

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

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

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

时间: 2024-10-18 18:55:01

对管理层的一些建议的相关文章

如何在管理层变动中存活下来

Anne Fisher为<财富>杂志<向Anne提问>的专栏作者,这个职场专栏始于1996年,帮助读者适应经济的兴衰起落.行业转换,以及工作中面临的各种困惑. 去年全球的并购交易同比增长47%.如果你的公司也被兼并,你有可能面临被裁掉的风险.面对管理层的变更,你不应该选择回避,而应该主动出击,尝试着向新老板提出解决方案而非问题,一切顺利的话,你不仅不会被炒鱿鱼,而且有可能晋升到更重要的岗位.       亲爱的安妮:去年晚些时候,我工作的公司宣布合并,事实证明这更像是一次收购.如今

新三板:精选反馈问题103题(建议收藏)

计兮网·新三板 新三板:精选反馈问题103题(建议收藏) 全国中小企业股份转让系统 发表于 2015-05-27 19:16 百博生物 1.  请公司说明上述股权转让过程是否合法有效,转让完成后百博广联的股权结构是否清晰(是否存在代持或潜在纠纷),百博广联与公司间的同业竞争关系是否完全解除.请主办券商及律师就上述问题发表意见. 2.  请公司补充披露其所有租赁房产的取得.使用及权属情况,是否存在因权属不清而导致的搬迁风险及应对措施;租赁房产的租金价格.定价依据及公允性.报告期各期租金金额.即将到

给计算机学生的几点建议

给计算机学生的几点建议关键字: 计算机 编程 虽然大概一两年前我还在夸夸其谈桌面应用程序是将来的潮流,大学生们现在还是偶尔向我请教职业发展的问题.所以我把我的建议写下来.以供学生们阅读,嘲笑,忽略. 大多数锐气十足的学生从来不向前辈征求意见.在计算机科学领域,这样做是正确的.因为前辈们很可能说些"在2010年前,市场对于那些只会敲击键盘的代码工人的需求将会超过一亿(因此前景是乐观的)",或者诸如"Lisp语言现在真的很热门". 我和那些前辈也差不多,当我给别人建议时

CIO需加强对战略管理层面的掌控-精华篇

当代CIO面临提升信息化作用的新机遇.CIO在企业中,不能满足于职能性的技术支撑角色,要找到新的着力点,以发挥信息化在全局战略中的作用,把信息化力量聚焦于做强做优,提高国际竞争力上来,成为企业不可或缺的战略支持和保障系统. 同是定位于战略全局的角色,如果把CIO同政委.参谋长或党委书记的作用加以比较,可以看出CIO的弱势来.这种弱势,直接制约了信息化对于实现中央企 业战略目标的作用的发挥,在转变发展方式这条主线上留下隐患.不过,这也是CIO的机遇,可以通过加强工作,而取得事半功倍的战略功效. C

写给未来程序员的建议

给计算机系学生的建议 大概在一两年前,我还在高喊,有着良好用户体验的Windows图形界面式客户端(rich Windows GUI client)将是未来的潮流.尽管我这样说了,但是时不时地还是有大学生写信给我,问我对于找工作有何建议.既然现在又到了招聘季节,我想我还是把我的标准建议写下来,让那些大学生读一读,笑一笑,然后忘掉. 大多数大学生都很自以为是,从不会虚心向前辈求教,他们觉得那样太麻烦.但是,很幸运,在计算机领域,这样做是对的.因为他们的前辈很可能会说一些不靠谱的话,比如"到2010

代码重构的必要性分析及实施建议

代码重构在软件开发过程中,是一项重要非紧急的工作.但大多数情况下,人们都会因为其非紧急,而忽略其重要性.等到代码重构演变成重要且紧急的工作时,一般就只有放弃了,因为由于长期的技术欠债,此时代码已经变得无法扩展,成为一堆僵死的代码. 代码重构的重要性 代码重构是为了使代码具有很好的可读性.可维护性.可扩展性.可重用性. 为什么要进行代码重构? 代码在演化过程中,会由于各种不同的原因,不断产生bad smell.如果不及时清理,bad smell会不断积累,代码逐渐腐化,最终导致代码不可用. 代码腐

大牛给计算机专业学生的 7 个建议

layout: default title: 大牛给计算机专业学生的 7 个建议[转] category: [技术, C/C++] comments: true --- 七个建议 看到名字时候,只是好奇,看完之后,还是决定把文章转载一下了.不知道是不是因为其中的一个选择的缘故,我之前也徘徊了好久时间. 具体的内容 文章如下: 导读:由于Joel Spolsky的双重身份(昔日耶鲁大学计算机系学长,今日Fog Creek软件公司的CEO),所以听听他的建议,对于当今无数困扰于就业压力的中国高校计算

大牛给计算机方向学生的 7 个建议

? 转自:CSDN 地址:https://blog.csdn.net/jHstGeWWubw/article/details/79546895 导读:由于Joel Spolsky的双重身份(昔日耶鲁大学计算机系学长,今日Fog Creek软件公司的CEO),所以听听他的建议,对于当今无数困扰于就业压力的中国高校计算机专业学子来说,是大有裨益的.你们会发现,大多数建议,都在强调"软实力"的价值. 如果你喜欢编程,那么你真是受到了上天的眷顾.你是非常幸运的少数人之一,能够以自己喜欢的事谋生

Python——深入理解urllib、urllib2及requests(requests不建议使用?)

深入理解urllib.urllib2及requests            python Python 是一种面向对象.解释型计算机程序设计语言,由Guido van Rossum于1989年底发明,第一个公开发行版发行于1991年,Python 源代码同样遵循 GPL(GNU General Public License)协议[1] .Python语法简洁而清晰,具有丰富和强大的类库. urllib and urllib2 区别 urllib和urllib2模块都做与请求URL相关的操作,但