有时候在脑海里会浮现一些观点或问题,有些经常遇到,有些可能从未遇过。思考是个很神奇的东西,世界之所以会发展这么快,很大程度上就是思考的成果。刘未鹏的一篇文章《为什么你应该(从现在开始就)写博客》,鼓励我们去学习、思考、写博客。事实上,写博客是对知识的一种总结方式。总结是对知识的归纳与梳理,在这个过程中少不了进一步的学习与思考,因为总有一些东西我们还不懂或没完全懂,所以学会总会很重要。
下面总结几个曾经思考或遇到过,觉得有必要梳理一下的观点:
做项目的公司
很多做项目的公司,太过于注重速度而非效率,注重结果而非过程,注重功能点而非质量,以销售为主,看重利润,对投入资源方面特别吝啬。当然,公司为了生存,这些其实都可以理解。但就我个人感觉,很多公司在这方面做得太过了。他们可能从未真正想过,如何通过N多项目,慢慢积累起来,形成自己的核心产品,或者说形成自己的核心竞争力。你也许反对这种观点,是的,你说的这些老板经常站在上面喊话:你们要将这个项目做成公司的一个产品,然后进行推广,接更多的项目。下边在听的人早已习惯了老板的这番豪情壮语,听完了就当啥事都没发生过,继续干自己的活。
有些老板因为站得太高,看不到下面的事儿,给下面的人的支持太少;有些老板因为不懂技术,一味的控制成本,生怕被下面的人耗光了。呵,老板通常都是比较抠门的。无论是哪种情况,这种公司很难形成一个好的产品,很难形成自己的核心竞争力。有些公司只能勉强过日子,活得也挺辛苦;但有些公司却真的发展壮大了起来,日子美滋滋的。当然,这跟中国的大环境有很大的关系,只要有权、钱或关系,公司就很难倒闭,不仅不会倒闭,日子还会越过越好。最广为人知的例子当属国企了,那真的是高成本、低效率,但国企依然很有钱途,你明白的。后面这类公司其实不在我讨论的范围之内。
就像中国的应试教育一样,我们已经习惯了某种标准,进入了某个圈套,被某种规则所束缚了,很难或不愿意跳出那个框框。如果你跟公司提建议,改善这种做事的方式,公司会告诉你,如果不这样做公司就会生存不下去。真的是这样吗?我看是一厢情愿吧?我们应该多学学《重来:更为简单有效的商业思维》(Rework中文版)一书里面的一些观点,书里面的观点非常独特而富有说服力,是一本值得反复阅读体会的书籍。里面的观点告诉你,失败并非成功之母;要想让客户接受你的产品,首先得让你自己接受;计划就是瞎猜等等原先你并不知道,原先你认为是正确的,但它却告诉你是错的的一些独特观点。
我自己没开过公司,所站的角度也不同,有些因素可能没考虑到。
项目管理
什么是项目管理?说得简单通俗一点,就是利用各种手段与资源,在指定的预算与时间内完成项目。时间与预算基本是不变的,资源只能有限度的调配,但手段却有无数种,正所谓有100个项目经理就会有100种管理方式。
抛开一切外在的因素,项目的成败,很大程度取决于项目经理的管理水平,以下是关于项目经理的几个问题:
- 项目经理真的完全理解客户的需求吗?——正确理解需求,才能减少返工,项目进展会更快
- 项目经理把需求完整的传递给项目组了吗?——吃苹果怕吃到半条虫,说话怕只说一半
- 项目经理关心过某个功能模块的业务流程吗?——通常项目经理最了解业务流程,能够给项目成员们最好的业务指导
- 项目经理登录过几次系统?用过哪些功能?这个丑陋的玩意儿真的是客户所期望的吗?——通常项目经理最了解客户的需求,这时项目经理就是最好的客户代表。可以从功能界面、业务流程、业务术语等检验系统是不是客户符合客户最初的期望,是否有需要改善的地方。
- 项目经理,你有没有把客户后续的反馈意见传达给项目组了吗?——项目组的所有成员都应该知道客户的想法,而不仅仅是项目经理知道
- 项目经理不正确的决策,导致项目加班加点,项目进度滞后——多征求项目组的意见,你的意见不一定是对的
以上第3、4点,通常最直接的导致客户的不满。每当你给客户演示系统的时候,客户经常会对你提的一些问题:
- 界面太丑
- 界面的业务术语或操作提示完全是从技术人员的角度进行设计的,项目经理或分析人员到底有没有参与到这些业务流程的设计,对术语、提示进行梳理,并指导技术人员进行开发?——例如,有些技术人员在做异常提示的时候,把后台代码抛出的异常直接显示到页面了,这是非常低级的一种错误
- 这个问题已经提了好多次了,我不知道为什么这么简单的问题你们就是不改?真受不了你们
- 你们从来都不会主动去考虑这个事儿应该怎么做,如何改进,每次都要等到我主动提出的时候你们才会去做,最后做完了还有一堆问题,我真不知道你们想干什么?
简洁
大道至简,大道理通常都是很简单的,简单到一两句话就可以说明白。同样,越是伟大的产品,其设计与使用会越简洁。比如苹果和Google的产品都极其简洁,但却不失其伟大之处,它们都有许多粉丝,都受到很高的评价;再如时下最流行的jQuery框架,语法也是非常简洁,但功能却很强大,而且很高效。
同样,在做项目的时候,当你问客户希望系统的功能界面是什么样子的,客户常常会告诉你:简洁、大方。虽然这听起来很扯淡,似乎没有任何价值,问了等于白问,客户也许压根儿就没想过这事儿。但由此我们基本可以得出一个结论,简洁的确非常重要!
在这个行业呆的时间越久,就越发觉简洁的重要性,但我发现身边好多人都没有注意到。
软件的简洁性,不仅仅指系统功能界面及操作上的简洁,而是要保持软件工程的整个过程都尽可能的简洁。比如,做需求分析的时候,尽量考虑既能够满足用户的需求,又不会投入过多的资源,需求分析不一定要面面俱到。功能界面的设计要抓住用户关注的重点,如首页应该摆放什么内容,应该展现什么字段?我们经常忽略的一点是,未深入的考虑界面展现的内容对客户有什么作用,而是一味的往界面堆数据,结果给客户演示的时候,客户会问你,你有没有想过展现这个数据或者用这种实现方式有什么作用?业务流程的设计,尽量保持流程简单,清晰,易于实现。数据库的设计,尽量用最少的表,最少的字段来实现。当然有时需要考虑对数据的冗余,可能会增加表或字段,但这样通常可以减少表之间的关联性,提高处理性能,降低业务处理的复杂性,所以最终整个软件会变得更加简洁。代码上,对于同一功能的实现,也尽量用最少的代码、最简单的方式来实现,这样既减少了代码量,也使代码更清晰易懂,易于维护。
我发现,保持软件的简洁性不仅能够减少不必要的投入、提高开发效率,而且能够提高产品的质量、更好的满足客户的需求。
IT大佬苹果公司和Google公司的产品在简洁性上几乎体现得淋漓尽致。
程序员的代码不太靠谱
在这里,我并不是想对所有程序员进行否定,只是想说明一种常见的现象。
一个项目,从开始到结束,可能会经历各种各样的需求变更、功能修改或人员变动,从而项目本身潜在的问题也会越来越多。归纳起来有两大原因:
- 代码测试不充分
- 业务不理解
先抛开测试团队与代码走查等因素,程序员首先必须对自己实现的代码负责。有些程序员,代码写完了,就不会再去看了,他们脑子里的概念是写完代码就是完成任务。有些程序员,测试自己实现的功能时,像是在走过场,跟没测试没太大区别。有些程序员,对业务不理解,但他就是不说,非得要写出不正确的代码;而有些程序员理解业务,但事实上他理解错了。
我们可能经常会问程序员的问题:
- 这个功能你完成了吗?——答:完成了
- 做完之后你测试过吗?——答:测试过了,没问题
- 对于这几种情况,你都测试过吗?——答:测试过了,都没问题
- 要测试仔细一点,有问题尽早修改,不要到最后交付给客户时才发现问题——答:我都测试过了,肯定没问题
这下可放心了,工作完成了,测试也没问题。可过几天给客户演示的时候,却突然冒出这样那样的问题,而且还不少,很多都是客户自己发现的。这是为什么呢?当然,软件的问题总会有,但有些确实是不应该出现的。
每当我检查其他同事写的一些代码时,有些时候真的很无奈,甚至想不明白为什么会这么写,为什么会经常犯这样的错误?——真的是不看不知道,一看吓一跳!
所以,有一位真正理解业务的技术人员,对代码进行检查很重要,特别是对核心代码、关键业务模块的实现流程的检查。
别再拍脑袋做事儿
拍脑袋做事真的很危险:
- 客户提的需求别拍脑袋答应,尽量快速评估一下再答复。如果无法现场确认,回公司讨论之后再给客户答复
- 客户原来已经认可或正在使用的功能,别拍脑袋随便修改,即使你的很好想法,但在实施之前最好与客户沟通确认之后再做,自作聪明是需要付出代价的
- 别拍脑袋写代码,先把思路理清楚,画个流程图或伪代码之后再动手也许会更好
不要浮躁
关于浮躁,程序员们应该有比较深的体会。我曾经在《五年程序员人生的点点滴滴》中也提过,但没做详细的讨论。其实只要你摆正价值观,降低姿态,怀着热情去工作,浮躁自然就会不复存在,而且工作也会更开心了。
注重反馈,提高服务
最后再提一下,客户的反馈很重要,客户多次提到的问题要特别关注。提高服务意识,多与客户交流,及时反馈问题。
以上内容纯属个人观点,不具有普适性,大家慎用!
(转载请注明来源:http://zhanjia.iteye.com/blog/1876344)
相关推荐
### 软件开发的哲学思考 #### 一、引言 在《软件开发的哲学思考》这篇译文中,作者探讨了软件开发的本质及其面临的挑战。尽管文章写作于1996年,但对于当今的软件开发领域仍然具有深远的意义。本文将深入分析该...
作者通过对软件开发过程中存在的问题进行分析,揭示了软件开发与人类思维、创造力之间的密切联系,并提出了关于如何改进软件开发过程的一些思考。 #### 二、软件开发的本质 软件开发是一种高度依赖于人类思维的...
这本书专注于软件开发过程中的最佳实践,特别是微软的研发模式。书中可能包含了敏捷开发、Scrum框架、团队协作以及持续集成与交付等内容。通过阅读,读者可以了解到如何在大型企业环境中构建高效的研发流程。 3. **...
"软件项目管理思考题" 软件项目管理是指对软件项目的规划、组织、协调、控制和监理,以确保项目的目标和要求得到实现。软件项目管理思考题是对软件项目管理的重要组成部分,它帮助项目经理和团队成员更好地理解软件...
关于OEM汽车软件管理的思考,随着新能源汽车与通信技术的发展,硬件工程师们需要面对越来越多的挑战,尤其是在物联网时代。汽车不再仅仅是机械装置,而是一个复杂的集成系统,其中软件起着核心作用。软件管理成为...
综上所述,《软件项目管理与软件工程过程文档规范》这份资料将帮助读者理解软件开发的全貌,掌握项目管理的核心技巧,明确文档规范的重要性,并启发我们在实践中不断积累经验,深化思考,以适应日新月异的软件工程...
思考与简答题可能要求读者分析项目管理的重要性,讨论在实际工作中如何有效地进行项目规划和控制。实训部分则可能要求读者实际操作,制定一个具体项目的进度计划,这将锻炼他们的计划编制和时间管理能力。 第二章...
重难点章节安排:根据软件开发和项目管理的实际要求,结合高职教育特点和我院的实际,在吸收其它同类教材的优点情况下,我对《软件项目管理》的教学内容进行了以下整合:将第3章软件项目管理和第4章计算机系统工程...
在软件开发领域,许多观念和做法常常引起...这些观念忽视了软件开发的实际挑战,如适应变化、团队协作效率和项目管理的重要性。软件开发需要综合考虑各种因素,包括技术、团队、管理和策略,才能成功完成高质量的项目。
在软件开发过程中,项目管理扮演着至关重要的角色,它确保了项目的顺利进行,合理的时间安排,以及资源的有效利用。这份2018年由谢俊兰同学完成的实验报告,详细阐述了软件项目管理中的关键环节,特别是项目进度计划...
软件开发不再是单打独斗的时代,大型项目需要团队共同合作才能完成。只有具备良好的团队精神和协作能力,程序员才能在项目中发挥出最大的效能。如同Linux的成功,正是Linus Torvalds领导的全球开发者团队共同协作的...
《简单之美——软件开发实践者的思考》是一本深入探讨软件开发艺术与哲学的书籍,它强调在复杂的IT世界中寻找并实现简洁之道的重要性。作者通过自己的实践经验,分享了如何在软件设计、编码、项目管理等多个层面追求...
本文将从需求分析、系统设计、系统实现、应用效果等方面,对基于软件开发项目管理的信息系统进行几点思考。需求分析是建立项目管理信息系统的第一步,也是最关键的一步。在需求分析阶段,需要深入了解项目的具体需求...
【软件项目管理(双语)】是一门针对JAVA软件开发的课程设计,旨在教授学生如何在实际项目中有效地管理软件开发流程。这门课程的独特之处在于采用双语教学,兼顾中文与英文,使得学生能够在国际化的环境中提升技能。...
### 软件开发项目成本控制的关键因素及策略 #### 一、引言 软件开发项目的成功与否,很大程度上取决于其成本控制是否得当。合理的成本控制不仅能帮助企业节省不必要的开支,还能确保项目的顺利进行,最终实现项目...
接下来,工作量量化是项目管理中的重要环节,尤其是在软件开发领域,由于其工作的复杂性和不确定性,量化工作难度较大。有效的项目计划应当根据项目实际进展而非日历时间来编写,同时,计划应涵盖项目内容的深入思考...