浅谈PM(项目管理)
浅谈PM(项目管理)
(2009-04-22 20:44:34)
标签:
项目管理高风险软件开发满意度it |
分类: Erp项目管理 |
一.商务谈判
1.作人的姿态 降低作人的姿态需要从多个方面去实施,最主要应该记住:人不可貌相,更不可以地位衡量。很多公司为了保持公司形象,会统一叫员工打扮的好看一点,看起来象个白领的样子。然而,老板多半是没有约束的。中国改革开放才二十年,很多有钱的老板实业家文化层次都不高,往往是当大学生们只会把屁股坐在板凳上肆意挥霍父母辛苦积攒的财富时,他们已经在各地奔波,积累丰富的商业经验并对金钱,人生和社会的本质有了充分的认识,形成了自己稳定的思维框架。这些人,很多都是穿着旧旧的衣服,戴着破破的手表,说话的时候经常会带上三字经,钻进上海的人堆里,搞不好你会把他当成民工。因为到他们所处的社会地位,已经不需要任何华丽的外表来衬托自己的身份,他们有的是底气。对PM来说,这是个非常危险的挑战。虽然说项目在初期有意向时会对对方的人事和关键人物有一定的了解,然而大项目里能说的上话的人太多了。上海人最瞧不起的就是土气,很多人谈项目的时候看到民工或很俗气的表现不免会皱皱眉头,往往在皱眉头的时候就失去了项目,也就是失去了市场和金钱。PM必须作到能与每一个层次的人交谈,尤其是看起来比自己层次要低的群体,哪怕是公司里扫地的阿姨。只有作到谦虚谨慎,不摆架子,尊重别人,才会得到别人的尊重,才有机会赢得项目。鼻子比眼睛高的人只会把自己的鼻子撞扁。 2.丰富的知识面 我一个朋友(PM)打一个单子时,发现对方对什么都不太感兴趣,费了很大力气也找不到突破口。对方这个人非常顺利,金钱地位美女样样不缺。他花了好多天和对方交谈,以自己的博学逐渐取得了对方的信任。后来他隐约发现对方对数学和天文学的发展史有所涉猎,如获至宝,回家花一个通宵的时间在网络上搜索相关资料。第二天他根本不谈项目的事情,只跟对方大谈特谈哥白尼,布鲁诺,伽利略这些人的生平,整整吹了一天。对方点头如捣蒜泥,态度和热情都来个一百八十度转弯,隔天他就拿到了单子。这是个经典的战例,谁能事先想到哥白尼会来帮助IT的人赚钱?这个PM靠的就是博学和由博学引申出的敏锐的感觉抓住了机会,让客户产生共鸣。客户感觉他层次也很高,而且和自己有共通之处,信任度大大增强,把项目交给他放心。如今这种例子在商务谈判中已经屡见不鲜了。对PM来说,并不要求在各个方面都很精通,那是不可能的事情,只要PM对一些流行的话题和天文地理历史各方面的知识有个大概的了解,在需要的时候能尽快的掌握,才有机会创造机遇和把握机遇。 3.强大的沟通能力 4.优秀的售前团队 在商务谈判的实际操作中,存在着各式各样的问题,PM的职责和要求绝非以上几点所能描述详尽。根据环境,政策,人文,关系等各方面的不同情况,PM的不同成长经历,每个PM最终都会建立自己对商务谈判的看法和经验。但是有一点可以肯定,这是PM成为PM的第一道关,也是最重要的一关。接不到单子,PM将失去存在的意义。与销售有所不同,PM在该阶段的任务除了接单,还要尽可能的搜集客户关键人物的资料并与对方各个阶层的负责人建立良好的客户关系,以便在项目实施时充分调动资源。 二.启动阶段 1.项目的一些基本概念 项目如何成功?也有一些关键的因素。个人的理解也不尽相同,通常包括以下几个方面:界定工作目标及工作任务;老板或高层的支持;优秀的PM和开发团队;充足的资源;良好的沟通;对客户的积极反应以及适当的监控和反馈。这里要注意的就是资源和高层的支持。一个上规模的公司总是同时会有很多项目,可是再大规模的公司资源也不足以保证每个项目都能组建最合适的开发队伍或拥有最好的环境。这时候各个团队或者部门之间不可避免的会发生资源争夺战,摩擦再所难免。这时候对PM的作人再次提出挑战。除了高层对PM项目的重视程度,如果PM平时在公司与同事相处的好往往能使很多别人看起来很棘手的问题迎刃而解。相反,一个不会作人的PM由于人缘差,即使高层强压别的部门或团队配合,别人也会能拖就拖,延缓项目的进度和质量。有时候,这种内耗对项目和PM来说是毁灭性的。对客户的积极反应也比较关键。一般来说PM已经被项目里大大小小的事情搞的筋疲力尽,要PM去主动要求客户配合是很吃力的事情。然而,这个时候,越是困难,越是觉得累,越是要去主动。客户往往也不是特别的积极,主动与客户联系沟通和测试能及早发现问题。从风险控制的角度来说,问题发现的越早,风险越小,损失也就越小。积极的态度可以带动客户的积极性,在项目完工的时候,客户对你的感激往往是难以用语言描述的,这对以后接单或者做二期三期会打下良好的基础。因为在和别的新客户谈判的时候,新客户自然会找你的老客户了解情况,这时老客户随意的一句话顶的上你很费心的十句。 项目具有商业行为的几个重要特征,有消费源,有参与者,有成功关键因素,有财务目标,有风险。 2.启动阶段的主要任务 需求分析的主要参与人员有PM,总体架构设计师,系统分析员,熟悉业务流程的客户。PM统领的团队这时候还不是真正的开发团队,我们叫做前期团队。随着需求分析的逐步深入,新的团队成员不断加入,启动阶段结束的时候正式的团队将建立。对一个已经启动的项目来说,需求分析直接决定了项目的成功与失败。最初的需求体现在客户的工作说明书或招标文件及附件上。这种需求一般比较含糊,无法体现客户真正的需求。前期团队要根据自己的经验和客户沟通并引导客户进入正轨。有时候客户会很不讲道理或者思路僵化,就要求按照他的思维去定一些明显错误的需求。这个时候团队成员要耐心和客户举事实,谈经验,讲道理,用图形或模型等直观的方式将需求描述出来,比如常见的数据流图等。所以说,争论再所难免,客户有时候会吹胡子瞪眼睛拍桌子甚至会说“这个东西不要你们做了”之类的话。PM此时除了要亲身参与需求分析综合整理文档之外,还要处理好团队成员与客户的关系,确保关系不会恶化到无法收拾的地步。只要PM尽力约束团队中的成员,这个度还是很容易控制的。 对快速开发和叠代开发来说,需求和实现往往是同步进行,开发速度快是一大优势。对有相同或类似模式的小项目来说采用快速开发或叠代开发是很合算的做法,时下流行的极限编程就是针对这方面建立的思维模式。然而,大中型项目中有太多不一样的需求和模块。如果不是因为项目有差异,那么市场上就只有产品而没有项目了。所以,大中型项目的需求要认真仔细的去做。我们要讨论一个问题,究竟应该在需求分析和总体设计上花费多少时间?我们熟悉的瀑布开发模式基本上分需求分析,总体设计,软件开发,测试等几个阶段,然而究竟应该在前两个阶段上花多少时间却没有定论。实际项目操作的例子表明,分析设计的时间越长,需求设计做的越详细,测试的时间就越短,返工率越低,风险也越小,成本越容易得到控制。而需求分析和总体设计没有做好就急忙上马进行开发的项目在项目初期进展顺利的时候问题不大,到了项目后期和测试阶段一些潜伏期比较长但是破坏作用比较大的问题就会凸显出来,造成返工,延长测试时间。所以与其把问题堆积到紧张的项目后期,不如把时间多花点到需求分析和总体设计上。基础夯实了,金字塔就容易造了。 在日本公司打工的程序员们可能都知道,小日本的软件规范非常厉害,他们花在需求分析和总体设计上的时间通常在40%到50%左右,远远超过国内软件项目的实施,效果也要强的多。他们总体设计的规范甚至详尽到某个过程该如何判断,确立什么样的条件,换言之就是把什么时候该如何写 (if...else)语句都帮程序员定好了。在这样的软件规范下,程序员更象是装配流水线上的工人,对一个模块或技术熟悉到一定程序就变成了完全的重复性劳动。所以在日本和欧美经常会有程序员是低级工作一说,很多人不明就里,对国内程序员也照搬,对国内的程序员来说是很不公平的。在国内,只会照抄别人代码,一点都不懂创新,凡事依靠别人,快下班就盯着表看的程序员是不少,这种人一般很难有什么前途。但是,优秀的不断进取的程序员也很多。由于国内没有象CMM这样的软件规范或者很少,所以这类优秀的程序员不少都是干着系统分析员甚至PM的活,拿着程序员的工资。这类程序员虽然在起步时会吃很多亏,而且是主动找亏吃,然而几年之后与前一种程序员的社会地位会出现明显的分化。当上进的程序员们作为PM进行商务谈判的时候,前者还在各个公司里频繁跳槽,跳来跳去都不满意。有些扯开了,回到我们的话题。日本的软件规范与CMM有惊人的相似,其中至少有35%以上都是几乎一模一样的。最近经济不景气,东京倒闭了160家软件公司,这个数字是今年6月份的,还在不断增加。这些公司纷纷抢滩上海,招收技术人员。如果去这样的公司应聘就要考虑清楚了,进去可以学到他们的规范和质量控制,可是要想从程序员成为系统分析员或PM,比登天还难。往往一个程序员进去干了好几年,对自己的那一块熟的不得了,而对隔壁同事所做的东西一窍不通。拒传华为正在尝试CMM4(华为印度研究所已经通过CMM4),对在华为工作的程序员们来说可谓福祸难料。当然,已经作到PM或QA或者热爱CODING的朋友例外。 详尽的需求分析有一个额外的好处就是对一些双方都很陌生或者从来无人尝试的领域将是一个决定是否进行项目的判断标准。有时候,这种大项目在签单时双方都没有绝对把握保证可以出成果,一旦在需求分析阶段发现难以逾越的技术难关,就会放弃项目。典型的例子就是NMD洲际导弹防御系统。上世纪八十年代初美国搞星球大战计划,拖跨了苏联。大家对那段历史有些含糊,很多人认为苏联人上了美国的当。其实并不完全如此,苏联人的情报机构无孔不入,并非那么容易上当受骗。实际上当时美国国防部已经开始着手NMD系统软件的需求分析,前后耗资数亿美圆,耗时两年,仅仅是做需求分析,终于发现存在着在当时技术上无法达到的高度,随后项目被放弃。 3.项目启动 三.计划阶段 1.定义结构分工结构图(WBS) WBS的定义还是很麻烦的。PM要召开团队进行讨论,向成员提供与项目相关的所有详细资料,并把WBS树分解到二层三层。然后要花上一段时间让成员进行头脑风暴式(BRAINING STORM)思考,制订工作产出和相应人员的职责,记录每一个工作包的完成标准。在头脑风暴式思考时,会有很激烈的争论,PM要协调关系,调节气氛,从自己能考虑到的各个角度旁推侧敲,提示成员的思维角度和方向并加以总结。尽管很麻烦,制订WBS仍然是非常值得的。如同需求分析一样,WBS准备的越充分,编码的进度越快。 2.风险管理 首先要识别风险。这是个难度很高的活。PM要先召开风险识别会议,这个会议面向公司,高层,跨部门的有经验的人都将参加。然后审核由项目小组生成的风险清单并与重要成员进行风险沟通,检查一些重要的风险源如WBS,成本(时间)预估,人员计划,采购管理等等。最后就要用到PM本身在以前类似项目中得到的经验教训。 识别之后要进行分析。我们可以进行粗略的量化分析(精确分析是不可能的事情)。有经验的人可以一起参加讨论,把提交出来的风险进行分类。首先按发生的可能性分,一般分成高,中,低三个级别,虽然很勉强,但是好歹也有个量化了;然后按耗去的成本分,也是高,中,低三级。我们可以把这两种类别的三个级别进行组合,碰到可能性也高,成本也高的风险就定位为不能接受。碰到这种风险只好让客户修改需求或者增加风险预留成本,否则一旦亏起来不是亏一点点,有可能赔的很厉害。高和中,中和中的搭配都是属于高风险,中和低,低和低搭配属于低,高和低搭配属于中。 针对出现的可能性,需要采取一些手段降低风险。到目前为止也没有一个定论说有绝对好的方式,只能尽其所能的避免。有几种方法可以考虑,第一种是将风险纳入项目管理计划并指定负责人,由外部人员定期检查项目风险,一旦风险发生,执行风险管理计划;第二种是保险,这种属于风险转嫁;第三种方式有点奸,不过最保险,就是把客户拖下水,让他们一起参与风险管理,呵呵,到时候就好说话了:) 3.预估 4.进度计划 显示进度计划一般有先后顺序图,甘特图和里程碑图表。上回邵卫老师讲课,推荐的工具是m$的PROJECT,这个工具我还不会用,因为没时间去摸索。我的头倒是用的很溜了,近一个月来他就用这个PROJECT画了一个又一个的里程碑图,不停的折磨我和同事的神经。我们一般都是一边开发一边做UNIT TEST,效果上来看,因为有强大的时间压力,效率上比之前确实要提高不少,可是我们也只能结结巴巴的赶完进度。由于TEAM里人少,我们都是一个人做几个人的活。我每天早晨六点多出门,经过将近两小时颠簸,八点多点已经坐在位子上,中午吃15分钟的饭,干到晚上八点下班,到家吃完饭往往已经11点了。一个多月我从来没吃过早饭,没有睡过六个小时以上的懒觉。虽然强大的压力使我们能在短时间内掌握尽可能多的技能,开发更多的模块,但是对我们的情绪也是有很大的影响。所以说,项目里程碑是一把双刃剑,合理安排才能既促进效率也不至于打击士气。团队成员士气的逐级衰落会给项目后期的开发带来难以估计的影响,进度将会大大延缓。关于PM和团队的问题我们后面会讲到,这里我先祥林嫂一把,然后跳过。 里程碑图表的特征是任务,成员和时间,任务和成员用文字标志,时间用数字描述并辅助以图线跨度,象阶梯一样非常形象,一目了然。管理起来非常方便,完了的打个钩就可以了。 网络逻辑图是表示任务和逻辑关系的示意图,可以用先后次序表示,也可以用关键路径表示。其实把各个活动划分为1,2,3,4等阶段,每个阶段包括小活动1.1,1.2,2.1,2.2,2.3,2.4,3.1,3.2,3.3,4.1,4.2等,日程计划也分四种,一般只提到从前向后和从后向前两种。从前向后的概念就是某项活动必须相同或晚于直接指向这项活动的的所有活动的最早结束时间的最晚时间。有些绕口,我们打个比方:2阶段指向3阶段,那么2阶段里的4个子阶段也都指向3。假设2.1结束时间为1月12日,2.2结束时间为1月22日,2.3结束时间为1月15日,2.4结束时间为1月20日,那么,2阶段中最晚的结束时间是2.2的1月22日,所以在3阶段中的3个子阶段3.1,3.2,3.3的最早开始时间都不能早于1月22日。至于从后向前的例子大家自己去推吧,我就不举了,刚才几个123打的我累死了:) 项目经常需要调整进度。在不改变项目范围的情况下,调整进度有几种方法:利用快速跟踪手段来改变任务间的关系;将串行的任务改成并行;改变工作方法(可能改变WBS);改变日期限制,使关键路径上的任务开始或结束的更早。虽然方法多样化,在我看来只有一条,就是拼命的压榨程序员的劳动力。如何压榨,还是个技巧。如前面所分析的,需求分析恨不得多分点时间给它,压需求是不太可能;测试阶段后期接近完工,罗里巴唆的事情一大堆,忙都忙不完,那时候PM一门心思提前/按时完工,好收钱,压那段时间似乎也不太可能。说来残酷,最能压的还是CODING,编码阶段往往是压缩重点,总之大家埋头苦干就是了,大项目压缩的时候程序员吃喝拉撒都在公司是很正常的事情,相信不少人都有很深的体会,这里伤心事情也就不提了。只是我总结一下,让未来的PM们有压榨后来人的依据,呵呵。测试前期也可以适当的压一压,那时候人刚完工,都比较懒散。国内一般企业规模都不大,没有专门的质量控制部门,所以质量保证和测试往往就是程序员或PM本身。其实质量保证和测试人员的人数和素质都应该要高于程序员。在日本和CMM实施的公司里,编码压缩是很容易实现的事情,因为那些程序员真的是技能熟练的装配工人,压起来方便的很。他们这样培养人的目的或许就是为了压缩吧?! 四.控制和执行阶段 1.软件开发 有个问题需要单独对还没有PM觉悟的程序员说,其实是在调研的时候就定了的,就是使用什么样的开发工具。没有经验的程序员往往会拿着C++或者 JAVA的资格证书或者拥有一两个开发工具的一些经验而得意洋洋。其实老板和PM根本不看重这个,他们关心的是使用什么样的工具能尽快的达到目的。管你什么C++,DELPHI,PB还是JAVA,只要能做的出来,VFP都可以用。我举这个例子并非说不看中工具,而是提醒想转型为PM的程序员,第一要把工具当作工具,而不要被工具套进去,钻研一些一辈子都用不上的技术;第二要掌握的并非是单独的一个工具,而是流行的程序设计的思想,以及在最短时间内掌握一门陌生工具的能力。只有建立了这样的思维,才有可能转为PM,否则一辈子都是技术工人,最多就是个技术总监。 2.变更 需求做的好,文档清晰又有客户签字,那么后期客户提出的变更就超出了合同的范围,需要另外收费。这个时候千万不能手软,并非要刻意赚取客户的钱财,而是不能养成客户经常变更的习惯,否则后患无穷,维护的成本会让PM吃不消。在客户提出变更请求时,要建立变更申请登记表和变更申请表,并让客户签字。当然,有时候一些不是非常关键的模块PM也不至于一点不讲情面,该卖面子的时候还是要卖,尤其是当着对方领导的面,千万要卖面子,但是也别卖的太干脆,不要让他们得到的太容易。 需求做的不好,客户抓住漏洞或者非常不讲道理,麻烦就大了。有时候争论会很厉害,到非常白热化的地步,PM与客户代表几乎沟通不了。PM在客户关系和短期利益两方面难以取舍,一般都是向客户妥协,最终形成恶性循环。这种情况非常难办。一般这种情况都是到了项目后期,做重大的更改几乎是不可能的事情,如果白做就要亏钱。而这个时候如果PM跟对方高层的人关系搞的定,可以透过对方高层把事情压住。然而由于已经到后期,客户代表不会轻易更换,对方这次没有改成,必然心怀不满,下回在别的模块依然会找麻烦或者在谈二期的时候动动手脚,都是很让PM伤脑筋的事情,这方面目前还没有什么好的解决方法,所以尽可能的做好需求比什么都重要。相对需求来说,什么WBS,风险管理,计划进度都是扯淡,需求做好了,一帆风顺。还有一种办法就是装可怜,要装的非常的象,在对方的领导面前装,而且不能让人看出是装的样子,要让你自己都觉得你自己是真的可怜,那么就算这次客户硬是要求改了,下回他也必然不好意思再叫你改。其实人心都是肉长的,如果可能的话,我还是不赞同使用一些手段的,但是有时候客户非常难以在短时间打动而工期又将接近,这种情况下就要靠PM耍一些手段了。各人有各人的方式,八仙过海,各显神通吧。 PM在变更管理中需要做的是分析变更请求,评估变更可能带来的风险和修改基准文件。 3.质量控制 4.成本管理 五.结束阶段 1.项目结束 项目结束意味着可以收钱了。PM辛苦了那么多,终于可以高兴一下了,收到最后一笔款项,意味着递交件的移交和团队的解散,项目也转入维护阶段。不过收钱未必代表着赚钱,要看项目是否按时完工。一般来说,提前完工的项目很少,但是能赚大钱;按时完工的赚小钱;延期的要赔钱。一个人首次承担PM,如果没有人带,多半会失败。失败没什么,所有的PM(注意是所有,不是几乎所有)都失败过,然而失败会成为教训和经验,推动你继续前行。在美国,每年至少有40%的项目无法实施被搁浅。只有在项目中和生活中不断磨练,培养自身素质和作人的基本准则,才能成为赚大钱的 PM。 2.项目完工会议 3.客户满意度 六.团队管理 1.建立团队 2.核心程序员 PM要特别注意爱护核心程序员,尤其是他们的生活困难和精神状况,有时候,他们耍性子或者不合作PM要妥协,要从自己身上找原因。其实在国内,我还没碰到过敢这么做的程序员。相对PM来说,程序员是绝对的弱势群体,没有任何发言权,几乎可以说PM想怎么做,想怎么改,程序员就要付出一切代价去达到目标。 3.奖励与惩罚 4.管理冲突 5.承担责任 6.资源争夺 后记:写到这里实在写不动了,控制阶段的合约管理和项目跟踪没有写进去,一方面我不熟悉,另一方面让大家自己去做一些思索。其实前天我就在构思这篇文章了,本来还想把CMM也写一篇的,如今看来太高估自己的能力了,时间实在是不允许。抬头一看,东方已露鱼肚白,外面隐约传来麻雀的嬉叫声。今天我还要去跟人谈祖房子的事情,明天还要上课,星期一开始又要没日没夜的加班,多想睡个懒觉呀! |
0
喜欢
已投稿到: |
排行榜
|
---|
转载列表:
转载是分享博文的一种常用方式...
浅谈PM(项目管理)相关推荐
- 「软件项目管理」一文浅谈软件项目风险计划
一文浅谈软件项目风险计划 序言 一.风险基本概念 1. 风险的定义及特性 2. 风险三要素 3. 风险图示 3. 风险类型 (1)预测角度 (2)范围角度 二.风险管理过程 三.风险识别 1. 定义 ...
- 浅淡计算机网络安全管理论文,工程项目管理-浅谈计算机网络强化计算机网络安全管理的有益学术论文格式(2)-优度********网...
关于无人值班变电站设计的思考-论浅析城市交通规划管理体系的构建建筑市场招投标管理工作的探讨浅谈支架龙湖大桥大跨度连续箱梁谈述路基公路工程路基施工毕业论建设项目工程的全过程造价控制阐述调制基于小波变换的 ...
- 浅谈CMMI几个过程概念流程管理 (转)
浅谈CMMI几个过程概念流程管理 CMMI(Capability Maturity Model Integration)能力成熟度模型集成,正如它的名字一样,它是一个模型.个人觉得它更是一种概念.它带 ...
- 从系统设计到市场痛点,浅谈英国自助结账系统
PMCAFF(www.pmcaff.com):互联网产品社区,是百度,腾讯,阿里等产品经理的学习交流平台.定期出品深度产品观察,互联产品研究首选. 外包大师(www.waibaodashi.com): ...
- 【转】图标字体化浅谈
在做手机端Web App项目中,经常会遇到小图标在手机上显示比较模糊的问题,经过实践发现了一种比较好的解决方案,图标字体化.在微社区项目中,有很多小的Icon(图标),如分享.回复.赞.返回.话题.访 ...
- 浅谈eform自定义表单工具和协同办公系统
浅谈eform自定义表单工具和协同办公系统 提起"协同办公",随便在百度或者Google搜索一下,就能让你看到眼花缭乱的信息,国内的各大协同办公软件厂商都在鼓吹着自己对协同的理解和 ...
- 浅谈语音助手的对话管理与策略制定
本篇文章首先梳理了对话系统中的对话管理的原理,包括中控系统的分发.各类bot处理Query的逻辑.候选回复融合和排序的功能,其中也包含了垂直领域知识图谱的构建.最后从PM角度思考,为了提升bot的表现 ...
- 浅谈这半年的实习感想
public class 浅谈这半年的实习感想{ private final static String DIGEST = 写这篇文章,一是作为这半年实习的总结,二是分享自己想说的话.文中观点,小部分 ...
- 浅谈狄利克雷分布——Dirichlet Distribution
浅谈狄利克雷分布的概念与简单使用. 文章目录 定义 二项分布(Binomial Distribution) 多项分布(Multinomial Distribution) 贝塔分布(Beta Distr ...
- 浅谈 MVC、MVP 和 MVVM 架构模式
2019独角兽企业重金招聘Python工程师标准>>> 谈谈 MVX 中的 Model 谈谈 MVX 中的 View 谈谈 MVX 中的 Controller 浅谈 MVC.MVP ...
最新文章
- 16~40K | 星猿哲科技招聘3D视觉算法工程师
- 15、四大组件--BroadcastReceiver
- .net中调用esb_大型ESB服务总线平台服务运行分析和监控预警实践
- 最近的日子,很惬意!
- 确认!聚划算百亿补贴要向iPad 8等新品下手,这次是真的刚刚好
- QQ超市模拟排配2D版1.14 (XNA4.0) (增加截图功能、新建地图功能)
- 【转】OC门与线与逻辑(含逻辑图)
- 移动端车牌识别sdk——技术干货
- 2022最新可用网页百度分享按钮安装教程【网站添加百度分享按钮代码】
- java this final_JAVA中的this,final,surper的用法
- mysql upgrade 是什么意思_Upgrade是什么意思?
- Android简单学习使用PictureSelector框架图片选取裁剪
- 酒店点菜系统c语言,求一个用最基础的C语言编写的简单饭店点菜系统
- 转载:Java语言学习
- 处理器后面的字母含义_电脑CPU型号末端的字母是什么意思?让小编来告诉你吧...
- 聊聊 Apache、Tomcat 静态网页、动态网页
- 奇数点偶数点fft的matlab,电子科大 数字信号处理实验2_FFT的实现
- python有道-Python3基础 访问在线的有道词典
- virtualbox安装失败报严重错误
- js 正则表达式禁止输入框输入特殊字符遇到的坑以及解决方案