http://david-lv.javaeye.com/blog/230708[@more@]
自从写了关于《三五个人十来条枪 如何走出软件作坊成为开发正规军》走出软件作坊:三五个人十来条枪 如何成为开发正规军(二),系列文章后,收到了很多网友的评论,也收到了很多网友的疑问请教。而大部分人都已经当上了项目经理,手下有个2-3个人或5-6个人。少部分人还在上学或者才毕业出来1-2年,询问的还是学什么语言和什么才是核心技术的之类问题。
从接到的请教来看,许多中国国内软件公司都是以项目为主,有单做单,没单就干靠,靠的时间长了老板心毛了就裁人,来活了就招人,就这样反反复复。所以,大量的公司没有开发部(因为除了销售,开发部从开发到实施到支持都全做),当然也没有开发部经理,只有项目经理。更不用提技术总监和CTO。即使有个技术总监的头衔,也是为了给客户的名片,而手下也就5-6个人,项目一来,技术总监也需要编码和实施,其实就是一个项目经理。
在国内,项目经理这个词如此常见。均为实施项目经理和开发项目经理混为一身,统称项目经理。虽然,开发和实施是软件产品的不同阶段,不同阶段关注的重点也有不同。但既然都为项目经理,那么其关注点也有共性之处。
项目经理,主要职责是:
项目范围定义
项目计划制定、分解、分配、协调、汇报
项目质量控制
项目需求变更控制
国内项目经理一般没有人事权和财务费用权。老板给分配什么人就带什么人,自己只是一个最能干的工人加工头而已,当然更没有财务费用权,要想请客户吃顿饭,当然需要和老板打报告(自己团队想休息娱乐会,只能联机打把游戏,想团队吃顿饭,不可能给费用的)。
不过,从现状来看,国内现在的项目经理,连项目范围和项目需求都无法控制。老板说什么就是什么,客户说什么就是什么,用户说什么就是什么,只要自己和自己的团队能做,并且不累死或者不跑路,能做的都照单全收。当然,做什么,什么时候做完,都不属于自己管理和控制,当然,项目计划的制定由项目经理制定,就是虚设了。唯一剩下的,就是项目质量控制:开发有代码的质量,实施有实施的质量。
接到网友很多询问,都问我工具的使用情况(对组织结构和流程问的极少,可能觉得都自己改变不了,根本没有机会实现,道理能不能行的通也就不用去想了,因为想了也白想)。问我现在的团队使用什么UML工具、什么压力测试工具、什么数据库设计工具、什么版本管理工具、什么需求管理工具、什么进度管理工具、什么BUG管理工具。
在他们眼里可能觉得,一个团队,只要用上先进的工具就会成为一支装备了机关枪的军队。就跟我们的客户一个想法,只要上了这套ERP软件,我们的管理就上了一个台阶,我们的盈利就会提升。这个想法,真是奇怪,就如同一个人拿了一把屠龙刀,人没砍到,倒是把自己砍伤了。一把好厨子的刀,到了不会做菜的人的手里,仍然做不出好菜,就这么浅显的道理,但大家还在幻想。
许多人想得到答案,觉得一个正规的开发团队应该使用是Rose、Together、LoadRunner、PowerDesigner、VSS、CVS、SVN、ClearRequest等等。
但其实,我们也并没有使用这些工具。
我一直在商业软件公司工作,也深深的明白自己的责任就是帮助公司最大限度的利润最大化。而利润最大化的实现手段就是最小的成本、最少的人、最少的时间、最简单的方法达到老板的目的,拿出合适质量和功能的产品,包装好,卖上尽可能高的价格。只要能赚到老板想赚到的钱,达到老板的目的,只要不影响这个目标,不影响大目标,小磕磕碰碰自然难免,有问题解决问题,没问题继续前进。哪个企业没个矛盾没个利益集团,哪个企业没个问题没个埋怨,有人爱自然有人恨。就是这样,这样是常态,不是异常。所以,我使用工具,一般都是在各种手段我都使用的差不多的情况下自然使用的,而非为了正规而正规,而是为了解决问题,而且是很有效的解决问题,而且是最简单的解决方法。我从来不为面子工程付出成本。
我们最先遇到的问题当然也是软件质量的问题。软件的质量问题,引起了实施培训、实施推动上线的困难、客户使用效果的困难、支持费用的增高、支持难度的加大。最后实施部不愿意实施、销售部不愿意销售、支持部直接把电话转开发部。所有人对把自己工作的不顺利和不顺心归罪到开发部。当然,这样的开发部,不被老板开掉才怪。
于是我空降入主了。
我采取的第一个策略就是:专门划出一个辅助开发人员(因为他对客户需求也不了解,讲了3遍也不懂,写的代码也考虑不周全,所以代码漏洞百出。不过这个小伙耐心还不错,就是有些懒。看来懒人一般都耐心不错。不过还是有些得过且过,做一天和尚撞一天钟。就这么个才。),让他做技术支持兼测试。
过去是实施部有不少人,每个人都直接打开发员的电话。支持部也是。客户也是。老板呢,不懂软件也不深入操作研究软件,却从使用者角度老提意见,看到哪里想到哪里就直接给开发员打电话让开发员修改,从最皮毛的字的字号到最深入的商业智能问题,都提,而且让立即改掉,其他所有人包括客户提的都靠后。这样,一个开发被干扰的无法工作,最后离职。
我划出开发部专人支持后,规定流程。所有的需求,不管是哪个部门或哪个客户,都归口到他这个人手上。即使还有人直接打给开发员,包括老板打给开发员的,开发员必须把需求或问题再并口到这个技术支持手里,我来统一安排调度开发。
开发人员是消停了,可以安心按我的安排的进度和优先级修改了。而支持小伙子呢,电话开始被打爆。幸好我给小伙子的指示是,都先接上记录好,能不能解决,能不能快速解决,看自己能力,不着急,谁跟你急,你跟我说。于是,小伙子被吃了一颗定心丸。
小伙子一开始使用的是一个EXCEL。别人提的问题都自己记录在里面。但是弄到最后,我的手里、小伙子手里、开发人员手里、支持人员手里,都出现了不同版本的EXCEL。互相都说这个已经修改了,那个说没有修改。这个说有多少BUG,那个说不可能。
于是,我上了第一个工具,BUG管理系统。不管是BUG还是需求还是建议还是疑问,谁想提,都提到这里来,随时记录。不管你是出差还是在支持部坐班,都记录到这里来。凡不记录者,一律不解决。
于是,天下太平。经过技术支持和开发人员努力,一个大风浪过去。利益冲突处于一个平衡或者可能随时崩塌引来下一次冲突。
我于是给支持小伙子分配了另一项重要工作。测试。为了不让你以后继续享受折磨,那么你必须卡好关。你自己卡不好,那么以后的技术支持仍然很痛苦。小伙子为了自己以后能过上幸福的上班生活,于是测试做的不错。所有测试出来的BUG也记入到BUG管理系统。 现在,开发人员工作量和工作质量有了量化,支持人员的工作量和工作质量也有了量化,给我安排计划和考核人员和申请资源做了大量的支持工作。
所以,一个BUG管理工具,能把计划、进度、质量、需求、BUG都能管理起来,而且能追溯,能考核,能统计工作量和工作质量。真是必备。
但是,接下来发现了一个问题。就是在修改的时候,老误会客户的需求。程序员一天在家里面开发,不了解外面的客户和在第一线战斗的实施人员到底想表达什么。于是修改完,程序员觉得自己费了很大的劲,而实施人员和客户却非常恼火,一点不领情还发怒。最后,搞的开发人员和实施人员冲突不断。
需求如何描述清楚,成了必须提上日程的事情。许多没有经验的项目经理尤其会在这一步犯晕。UML工具、数据库设计工具,需求管理工具,能上的都上,最后也没解决问题,把自己和自己的团队累的半死。
我使用了PPT+WORD+脑图+EXCEL的描述方法。
因为很多需求都是这个支那个叉出来的。程序员往往想的了这头想不了那头。这就是人的思考的周密性差异。
想让人能从千万丝绦中理出头绪,于是脑图软件上场。把各个分支来龙去脉表现清楚。
到了描述某个节点的时候,PPT上手。一页PPT相当于一个界面窗口。每页PPT的图形模仿了菜单、输入框、按钮。按钮按下,还可以跳转到其他的PPT页上,和软件操作流程非常相似。
PPT让程序员很直观的看到未来软件作出来是什么样子。关于PPT的详细描述,如字段,流程,特殊注意,特殊控制,都用WORD说明好。
遇到有报表功能的时候,用EXCEL把报表画出来,让程序员喜闻乐见。
这样,从表及里,从概要到详细,从分支到关联,都表述OK。客户也能明白,程序员也能明白,实施人员也能明白,老板也能明白(这点非常重要。虽然老板不懂软件,但他要干涉软件,他如果不明白,他就不知道这帮家伙到底在干吗,是在真正干活还是在偷懒,到底工作量是大是小,软件功能是复杂还是简单。老板如果不明白,老板在给与资源和时间上就会很谨慎,处处提防。这是许多项目经理都忽略了大事。还拿UML做秀,谁也看不懂,谁也用不了,白花费时间画那些好看的图。这就是中国的现状,我们站哪个山头就唱哪个山头的歌,有效解决问题提高销售收入才是我们的根本任务,我们不抱怨不幻想踏实推进解决问题)。
于是,老板的天平开始向开发部倾斜了。资源,当然就容易申请了。
画这些EXCEL+PPT+脑图+WORD,当然很费时间(我直到引进了日本外包开发过程管理才发现,我们的解决方法和强调质量的日本人的做法非常相似)。于是,我申请一个人,把过去实施的一个项目经理(还居然会写点SQL,从数据库查数据,调整个报表。实在太强了)调入开发部,专门编写这些文件。
开发部开始蒸蒸日上。项目经理、开发人员、测试兼技术支持已经到位。工具也已用的不亦乐乎,深入到了公司的每个部门。每个部门都按照标准描述方法和标准流程走。现在,连实施人员都会画EXCEL报表格式、PPT界面。
软件到位,就需要包装,否则软件就卖不上好价格。这是很自然的事情。干啥都要个品相。漂亮的姑娘谁都喜欢。
软件包装,第一步就需要帮助文件、视频操作、解决方案、产品介绍、演示系统。当然,文案人员很快到位。美工美化也自然到位。能多赚钱干吗不做,老板也不是傻子。谁喜欢卖一个土灰土脸的产品。
有了好的产品,出不去开发部也是个问题。只有自己内部人知道功能怎么用,怎么满足客户的需求,其他部门都不知道。许多人都不知道新功能和旧功能的改变。文档中都写了,更新说明也有,就是没有人看。还是打电话找技术支持,技术支持只能不断解释。问题又来了。
文案出马。每次版本发布,功能更新,文案反复举办集中培训,办班,一批次一批次的培训,百其不厌。
四套马车,于是真正的天下太平了。
从此,开发人员和实施人员过上了幸福的生活。
后续记:
接到很多网友的评论,都说老板不可能给资源的。说我写的太理想。
嗯,如果你看完我的文章就直接找老板要资源,当然是会被赶回来的。因为,你什么都没有做就开始要资源。
有人还说,公司就这几条枪,能干活的更是那几头蒜。根本不可能给你派人。
嗯,如果你思考的目标不是为老板赚取更多的钱,那么老板不可能给你一丁点的,甚至还会把你干掉。如果你觉得,这样的老板我还不伺候呢,那么中国大部分都是这样的公司,除非你转行不干这行了。要干,就别混日子。想得过且过让老板公司倒闭,这个基本不可能。再说老板倒闭了对你一点好处都没有。
迈出你的第一步吧。不迈出第一步,你都会觉得这是不可能完成的任务。
想过幸福的生活,从现在就开始脚踏实地的动手吧。
从接到的请教来看,许多中国国内软件公司都是以项目为主,有单做单,没单就干靠,靠的时间长了老板心毛了就裁人,来活了就招人,就这样反反复复。所以,大量的公司没有开发部(因为除了销售,开发部从开发到实施到支持都全做),当然也没有开发部经理,只有项目经理。更不用提技术总监和CTO。即使有个技术总监的头衔,也是为了给客户的名片,而手下也就5-6个人,项目一来,技术总监也需要编码和实施,其实就是一个项目经理。
在国内,项目经理这个词如此常见。均为实施项目经理和开发项目经理混为一身,统称项目经理。虽然,开发和实施是软件产品的不同阶段,不同阶段关注的重点也有不同。但既然都为项目经理,那么其关注点也有共性之处。
项目经理,主要职责是:
项目范围定义
项目计划制定、分解、分配、协调、汇报
项目质量控制
项目需求变更控制
国内项目经理一般没有人事权和财务费用权。老板给分配什么人就带什么人,自己只是一个最能干的工人加工头而已,当然更没有财务费用权,要想请客户吃顿饭,当然需要和老板打报告(自己团队想休息娱乐会,只能联机打把游戏,想团队吃顿饭,不可能给费用的)。
不过,从现状来看,国内现在的项目经理,连项目范围和项目需求都无法控制。老板说什么就是什么,客户说什么就是什么,用户说什么就是什么,只要自己和自己的团队能做,并且不累死或者不跑路,能做的都照单全收。当然,做什么,什么时候做完,都不属于自己管理和控制,当然,项目计划的制定由项目经理制定,就是虚设了。唯一剩下的,就是项目质量控制:开发有代码的质量,实施有实施的质量。
接到网友很多询问,都问我工具的使用情况(对组织结构和流程问的极少,可能觉得都自己改变不了,根本没有机会实现,道理能不能行的通也就不用去想了,因为想了也白想)。问我现在的团队使用什么UML工具、什么压力测试工具、什么数据库设计工具、什么版本管理工具、什么需求管理工具、什么进度管理工具、什么BUG管理工具。
在他们眼里可能觉得,一个团队,只要用上先进的工具就会成为一支装备了机关枪的军队。就跟我们的客户一个想法,只要上了这套ERP软件,我们的管理就上了一个台阶,我们的盈利就会提升。这个想法,真是奇怪,就如同一个人拿了一把屠龙刀,人没砍到,倒是把自己砍伤了。一把好厨子的刀,到了不会做菜的人的手里,仍然做不出好菜,就这么浅显的道理,但大家还在幻想。
许多人想得到答案,觉得一个正规的开发团队应该使用是Rose、Together、LoadRunner、PowerDesigner、VSS、CVS、SVN、ClearRequest等等。
但其实,我们也并没有使用这些工具。
我一直在商业软件公司工作,也深深的明白自己的责任就是帮助公司最大限度的利润最大化。而利润最大化的实现手段就是最小的成本、最少的人、最少的时间、最简单的方法达到老板的目的,拿出合适质量和功能的产品,包装好,卖上尽可能高的价格。只要能赚到老板想赚到的钱,达到老板的目的,只要不影响这个目标,不影响大目标,小磕磕碰碰自然难免,有问题解决问题,没问题继续前进。哪个企业没个矛盾没个利益集团,哪个企业没个问题没个埋怨,有人爱自然有人恨。就是这样,这样是常态,不是异常。所以,我使用工具,一般都是在各种手段我都使用的差不多的情况下自然使用的,而非为了正规而正规,而是为了解决问题,而且是很有效的解决问题,而且是最简单的解决方法。我从来不为面子工程付出成本。
我们最先遇到的问题当然也是软件质量的问题。软件的质量问题,引起了实施培训、实施推动上线的困难、客户使用效果的困难、支持费用的增高、支持难度的加大。最后实施部不愿意实施、销售部不愿意销售、支持部直接把电话转开发部。所有人对把自己工作的不顺利和不顺心归罪到开发部。当然,这样的开发部,不被老板开掉才怪。
于是我空降入主了。
我采取的第一个策略就是:专门划出一个辅助开发人员(因为他对客户需求也不了解,讲了3遍也不懂,写的代码也考虑不周全,所以代码漏洞百出。不过这个小伙耐心还不错,就是有些懒。看来懒人一般都耐心不错。不过还是有些得过且过,做一天和尚撞一天钟。就这么个才。),让他做技术支持兼测试。
过去是实施部有不少人,每个人都直接打开发员的电话。支持部也是。客户也是。老板呢,不懂软件也不深入操作研究软件,却从使用者角度老提意见,看到哪里想到哪里就直接给开发员打电话让开发员修改,从最皮毛的字的字号到最深入的商业智能问题,都提,而且让立即改掉,其他所有人包括客户提的都靠后。这样,一个开发被干扰的无法工作,最后离职。
我划出开发部专人支持后,规定流程。所有的需求,不管是哪个部门或哪个客户,都归口到他这个人手上。即使还有人直接打给开发员,包括老板打给开发员的,开发员必须把需求或问题再并口到这个技术支持手里,我来统一安排调度开发。
开发人员是消停了,可以安心按我的安排的进度和优先级修改了。而支持小伙子呢,电话开始被打爆。幸好我给小伙子的指示是,都先接上记录好,能不能解决,能不能快速解决,看自己能力,不着急,谁跟你急,你跟我说。于是,小伙子被吃了一颗定心丸。
小伙子一开始使用的是一个EXCEL。别人提的问题都自己记录在里面。但是弄到最后,我的手里、小伙子手里、开发人员手里、支持人员手里,都出现了不同版本的EXCEL。互相都说这个已经修改了,那个说没有修改。这个说有多少BUG,那个说不可能。
于是,我上了第一个工具,BUG管理系统。不管是BUG还是需求还是建议还是疑问,谁想提,都提到这里来,随时记录。不管你是出差还是在支持部坐班,都记录到这里来。凡不记录者,一律不解决。
于是,天下太平。经过技术支持和开发人员努力,一个大风浪过去。利益冲突处于一个平衡或者可能随时崩塌引来下一次冲突。
我于是给支持小伙子分配了另一项重要工作。测试。为了不让你以后继续享受折磨,那么你必须卡好关。你自己卡不好,那么以后的技术支持仍然很痛苦。小伙子为了自己以后能过上幸福的上班生活,于是测试做的不错。所有测试出来的BUG也记入到BUG管理系统。 现在,开发人员工作量和工作质量有了量化,支持人员的工作量和工作质量也有了量化,给我安排计划和考核人员和申请资源做了大量的支持工作。
所以,一个BUG管理工具,能把计划、进度、质量、需求、BUG都能管理起来,而且能追溯,能考核,能统计工作量和工作质量。真是必备。
但是,接下来发现了一个问题。就是在修改的时候,老误会客户的需求。程序员一天在家里面开发,不了解外面的客户和在第一线战斗的实施人员到底想表达什么。于是修改完,程序员觉得自己费了很大的劲,而实施人员和客户却非常恼火,一点不领情还发怒。最后,搞的开发人员和实施人员冲突不断。
需求如何描述清楚,成了必须提上日程的事情。许多没有经验的项目经理尤其会在这一步犯晕。UML工具、数据库设计工具,需求管理工具,能上的都上,最后也没解决问题,把自己和自己的团队累的半死。
我使用了PPT+WORD+脑图+EXCEL的描述方法。
因为很多需求都是这个支那个叉出来的。程序员往往想的了这头想不了那头。这就是人的思考的周密性差异。
想让人能从千万丝绦中理出头绪,于是脑图软件上场。把各个分支来龙去脉表现清楚。
到了描述某个节点的时候,PPT上手。一页PPT相当于一个界面窗口。每页PPT的图形模仿了菜单、输入框、按钮。按钮按下,还可以跳转到其他的PPT页上,和软件操作流程非常相似。
PPT让程序员很直观的看到未来软件作出来是什么样子。关于PPT的详细描述,如字段,流程,特殊注意,特殊控制,都用WORD说明好。
遇到有报表功能的时候,用EXCEL把报表画出来,让程序员喜闻乐见。
这样,从表及里,从概要到详细,从分支到关联,都表述OK。客户也能明白,程序员也能明白,实施人员也能明白,老板也能明白(这点非常重要。虽然老板不懂软件,但他要干涉软件,他如果不明白,他就不知道这帮家伙到底在干吗,是在真正干活还是在偷懒,到底工作量是大是小,软件功能是复杂还是简单。老板如果不明白,老板在给与资源和时间上就会很谨慎,处处提防。这是许多项目经理都忽略了大事。还拿UML做秀,谁也看不懂,谁也用不了,白花费时间画那些好看的图。这就是中国的现状,我们站哪个山头就唱哪个山头的歌,有效解决问题提高销售收入才是我们的根本任务,我们不抱怨不幻想踏实推进解决问题)。
于是,老板的天平开始向开发部倾斜了。资源,当然就容易申请了。
画这些EXCEL+PPT+脑图+WORD,当然很费时间(我直到引进了日本外包开发过程管理才发现,我们的解决方法和强调质量的日本人的做法非常相似)。于是,我申请一个人,把过去实施的一个项目经理(还居然会写点SQL,从数据库查数据,调整个报表。实在太强了)调入开发部,专门编写这些文件。
开发部开始蒸蒸日上。项目经理、开发人员、测试兼技术支持已经到位。工具也已用的不亦乐乎,深入到了公司的每个部门。每个部门都按照标准描述方法和标准流程走。现在,连实施人员都会画EXCEL报表格式、PPT界面。
软件到位,就需要包装,否则软件就卖不上好价格。这是很自然的事情。干啥都要个品相。漂亮的姑娘谁都喜欢。
软件包装,第一步就需要帮助文件、视频操作、解决方案、产品介绍、演示系统。当然,文案人员很快到位。美工美化也自然到位。能多赚钱干吗不做,老板也不是傻子。谁喜欢卖一个土灰土脸的产品。
有了好的产品,出不去开发部也是个问题。只有自己内部人知道功能怎么用,怎么满足客户的需求,其他部门都不知道。许多人都不知道新功能和旧功能的改变。文档中都写了,更新说明也有,就是没有人看。还是打电话找技术支持,技术支持只能不断解释。问题又来了。
文案出马。每次版本发布,功能更新,文案反复举办集中培训,办班,一批次一批次的培训,百其不厌。
四套马车,于是真正的天下太平了。
从此,开发人员和实施人员过上了幸福的生活。
后续记:
接到很多网友的评论,都说老板不可能给资源的。说我写的太理想。
嗯,如果你看完我的文章就直接找老板要资源,当然是会被赶回来的。因为,你什么都没有做就开始要资源。
有人还说,公司就这几条枪,能干活的更是那几头蒜。根本不可能给你派人。
嗯,如果你思考的目标不是为老板赚取更多的钱,那么老板不可能给你一丁点的,甚至还会把你干掉。如果你觉得,这样的老板我还不伺候呢,那么中国大部分都是这样的公司,除非你转行不干这行了。要干,就别混日子。想得过且过让老板公司倒闭,这个基本不可能。再说老板倒闭了对你一点好处都没有。
迈出你的第一步吧。不迈出第一步,你都会觉得这是不可能完成的任务。
想过幸福的生活,从现在就开始脚踏实地的动手吧。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/249132/viewspace-1010019/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/249132/viewspace-1010019/