软件研发管理:置身其中看问题

以前刚毕业的时候,心高气傲。见什么都有自己的一套想法,总觉得哪里都有不顺眼的地方。记得一次到客户那里,对方IT问了些软件在流程设计上的问题,我就以管理思想的大话回了。不想他们经理听到了,马上拉我过去:”谈管理是吧,来来,我们聊聊管理!” 。虽然和这位经理合作一直愉快,这次还是被客气地修了一顿。事后心里也明白显然话过了头,这是对我教育最大的一次。

再后来随着工作经历的增加,我才真正懂得了什么是”存在即真理”。企业家努力打拼,创造一个几千人,甚至几万人的工厂,自然有其成功的道理。我们这些自以为是的年轻人总顶着某些至理明言、或者某些条条框框,盯着一些细节,大谈什么BPR, 6个sigma,确实太天真了。真正要做的是认可这个企业,再去思考如何改进它。即使企业家有再大的胸怀,我们也要清楚自己的角色。小到一个小作坊,大到一个大型工厂,都有其说不完的问题,但也有使其存在亮点。

在厦门一家公司在ERP项目启动会上,甲方一位管理部门的经理纠正顾问的话:”以后,就是咱们公司的事了!” 这句话让我印象深刻。从局外人的角度的确可以清晰的发现问题,但很难得到一个合适的解决方法。 只有将自己融进公司,融进团队,才能更清楚了解问题的本质,才能有好的应对方案。举个例子,质量管理的一些工具曾经非常流行,比如鱼骨图,思维导图之类的。 如果清楚了解现场的人,是不需要这些工具的。一堆质管工程师在办公室讨论半天,可能还不如一个产线工程师了解问题。这正是稻盛和夫提倡的到现场去的原因。

这些都是我刚毕业那几年从事ERP这类软件开发工作的心得。后面做得事更加专注于软件,但这些经验一直受用非浅。

软件研发的管理也是这样。现在的问题是市场变化的太快,产品的周期短,产品存在的周期也变短了,管理问题并不像以前那么突出,因为被太多更为紧急的事掩盖了。面向一帮正在努力求生存的人推销假期旅游就不是什么好主意。但是问题仍然是存在的,只是在这些问题的投入度是有限的。界线在哪?只能是融入团队后才能找到答案。先找到自己的定位,以恰当的方式推动工作。无论是潜移默化的引导,或是大刀阔斧的制度化推动,只要适合团队就行。反之,就会带来灾难。

那么什么是合适的方式呢? 一是定位团队所处的阶段,理清管理问题的迫切性。二是做好向上沟通,确认自己的理解和执行方式得到认可。

总之,既要抽身事外发现问题,更要置身其中看问题!

纯属一些感想,没有特别准备,不当之处,欢迎交流!



《More C++ Idioms》已经翻译17条了!详细的页面请看这里:

https://github.com/HorkyChen/MoreCPlusPlusIdioms

版权声明:本文为博主原创文章,未经博主允许不得转载。

软件研发管理:置身其中看问题

时间: 2024-10-05 16:20:31

软件研发管理:置身其中看问题的相关文章

转:几个软件研发团队管理的小问题

几个软件研发团队管理的小问题 最近在与一位总经理交流的时候,他谈到他们公司的软件研发管理,说:"我们公司最大的问题是项目不能按时完成,总要一拖再拖."他问我有什么办法能改变这个境况.从这样一个问题开始,在随后的交谈中,又引出他一连串在软件研发管理中的遇到的问题,包括: . 现有代码质量不高,新来的开发人员接手时宁愿重写,也不愿意看别人留下的"烂"代码,怎么办? . 重构会造成回退,怎样避免? . 有些开发人员水平相对不高,如何保证他们的代码质量? . 软件研发到底需

几个软件研发团队管理的小问题

最近在与一位总经理交流的时候,他谈到他们公司的软件研发管理,说:"我们公司最大的问题是项目不能按时完成,总要一拖再拖."他问我有什么办法能改变这个境况.从这样一个问题开始,在随后的交谈中,又引出他一连串在软件研发管理中的遇到的问题,包括: . 现有代码质量不高,新来的开发人员接手时宁愿重写,也不愿意看别人留下的"烂"代码,怎么办? . 重构会造成回退,怎样避免? . 有些开发人员水平相对不高,如何保证他们的代码质量? . 软件研发到底需不需要文档? . 要求提交代码

敏捷项目管理框架(APMF)

研读许秀影博士的<敏捷项目管理:基础知识与应用实务>一书,其中提到传统项目管理与敏捷项目管理的混合管理模式—敏捷项目管理架构(Agile Project Management Framework,APMF),估计是普遍大部分公司所需要的,也比较认可的模式,可以很好的实现传统项目管理向敏捷项目管理转型.这本书很值得推荐,从现在软件管理的大势所需,到对软件研发管理发展史的剖析,到推崇的敏捷项目管理框架,到敏捷项目管理的企业导入,到敏捷创新模式讲解,让你在软件项目管理方面有了更加开阔的视野.如果你对

如果更注重成本,从长期来看,成本将增加、质量将下降;如果更注重质量,从长期来看,成本将下降、质量将提升

最近看到一句关于软件研发管理的话,觉得挺有道理的,所以拿出来和大家分享一下:如果更注重成本,从长期来看,成本将增加.质量将下降:如果更注重质量,从长期来看,成本将下降.质量将提升. 这句话其实很好理解.前半部分,如果更注重成本的话,就有可能在该加人手的时候不加人手,一些时候为了赶工期而忽视一些问题,这样就可能在质量上埋下一些隐患.如果为了降低成本,导致一些问题最终流到产品发布之后,再去解决问题的代价就是在内部发现的10倍,甚至更多.这样将造成总体成本的上升.总结一句话,出现这种现象的根本原因是:

项目管理书籍推荐

http://blog.csdn.net/hbqhdlc/article/details/6207513 项目管理书籍推荐 一.人件 <人件>第1版于1987 年出版,专门讨论了软件开发和维护团队的管理问题,并向人们的传统认识提出了挑战.作者在书中推崇人本管理思想,正确指出知识型企业的核心是人,而不是技术,呼吁给予软件工作者充分的自由和信任.本书推出后,立即在西方引起了轰动,被誉为“几十年来对美国软件业影响最大的理念”.与<人月神话>一样,<人件>现已成为软件团队管理的

实践敏捷估算(1)——不不过估不准的问题

摘要: 说起估算问题,我们第一反应往往是"估不准"!估得准又怎样呢?假设估算结果是须要5个月才干完毕,但合同要求3个月交货,你怎样办?所以事实上我们另一个"估得多"的问题,而在"估不准"和"估得多"这两个问题之前,还有"不敢估"的问题. 估算问题非常复杂,我们首先要做的是拆解这个问题,这样才干更好地找到合适的解决方法. 我们从不同角色的视角来看看估算的问题: 老板怎样看估算? 老板是非常了解自己的手下的:假

打造实用绩效考核(深圳站 2014-6-21)

 课程概述合适的盈利模式 + 合适的绩效考核办法 = 强劲的企业业绩!绩效考核可能是最重要的一种制度,但也可能是最有杀伤力的一种制度:?优秀的考核制度,驱动员工和公司一起进步,员工每天充满激情地工作,公司业绩蒸蒸日上:?平庸的考核制度,仅仅是一种考核需要,每次考核走走形式,"轮流"做优秀员工:?低劣的考核制度,严重挫伤员工工作积极性,甚至逐步将有价值的员工逼到"离职"的境地.本课程分享老师十多年的绩效考核经验,帮助你打造实用有效的绩效考核机制,运用好绩效考核这个&q

系统即服务,如何提升系统全局把控和设计能力?

来个接力,谈谈自己的看法,班门弄斧,拋磚引玉,期待更多小伙伴的分享. 系统即服务 大到传统的物流系统,小到一个部门wiki系统,归根到底都是需要人来使用的,人使用的目的是满足某种需求,系统为用户的需求而服务. 试想一个没有服务功能的IT系统,哪怕代码算法写的再牛逼,编程语言使用世界上最好的语言PHP,数据库有全宇宙最牛逼的oracle,存储用的是全银河系最牛逼的EMC设备,不能给用户提供可靠稳定安全的服务,它就只不过是一堆成本昂贵,毫无价值的垃圾. 服务的方向就是,提升用户使用和服务支持的性价比

TFS实战培训 - 博时基金公司 (2016年8月)

博时基金管理有限公司是中国内地首批成立的五家基金管理公司之一, 是目前我国资产管理规模最大的基金公司. 博时信息技术部的的软件研发团队是负责公司信息化的核心技术部门,为提升软件产品的研发效率和质量,计划引入TFS系统作为自己的软件研发管理平台,实现从需求管理到产品上线的全流程管理平台.通过几天的培训和项目实施,研发团队对TFS系统的研发和管理能力有了一个全新的认识. Figure - 培训现场 Figure - 与客户探讨解决方案 Figure - 博时基金