`

关于项目管理、软件开发的一些思考

阅读更多
    有时候在脑海里会浮现一些观点或问题,有些经常遇到,有些可能从未遇过。思考是个很神奇的东西,世界之所以会发展这么快,很大程度上就是思考的成果。刘未鹏的一篇文章《为什么你应该(从现在开始就)写博客》,鼓励我们去学习、思考、写博客。事实上,写博客是对知识的一种总结方式。总结是对知识的归纳与梳理,在这个过程中少不了进一步的学习与思考,因为总有一些东西我们还不懂或没完全懂,所以学会总会很重要。
    
    下面总结几个曾经思考或遇到过,觉得有必要梳理一下的观点:
 
做项目的公司
    很多做项目的公司,太过于注重速度而非效率,注重结果而非过程,注重功能点而非质量,以销售为主,看重利润,对投入资源方面特别吝啬。当然,公司为了生存,这些其实都可以理解。但就我个人感觉,很多公司在这方面做得太过了。他们可能从未真正想过,如何通过N多项目,慢慢积累起来,形成自己的核心产品,或者说形成自己的核心竞争力。你也许反对这种观点,是的,你说的这些老板经常站在上面喊话:你们要将这个项目做成公司的一个产品,然后进行推广,接更多的项目。下边在听的人早已习惯了老板的这番豪情壮语,听完了就当啥事都没发生过,继续干自己的活。
    有些老板因为站得太高,看不到下面的事儿,给下面的人的支持太少;有些老板因为不懂技术,一味的控制成本,生怕被下面的人耗光了。呵,老板通常都是比较抠门的。无论是哪种情况,这种公司很难形成一个好的产品,很难形成自己的核心竞争力。有些公司只能勉强过日子,活得也挺辛苦;但有些公司却真的发展壮大了起来,日子美滋滋的。当然,这跟中国的大环境有很大的关系,只要有权、钱或关系,公司就很难倒闭,不仅不会倒闭,日子还会越过越好。最广为人知的例子当属国企了,那真的是高成本、低效率,但国企依然很有钱途,你明白的。后面这类公司其实不在我讨论的范围之内。
    就像中国的应试教育一样,我们已经习惯了某种标准,进入了某个圈套,被某种规则所束缚了,很难或不愿意跳出那个框框。如果你跟公司提建议,改善这种做事的方式,公司会告诉你,如果不这样做公司就会生存不下去。真的是这样吗?我看是一厢情愿吧?我们应该多学学《重来:更为简单有效的商业思维》(Rework中文版)一书里面的一些观点,书里面的观点非常独特而富有说服力,是一本值得反复阅读体会的书籍。里面的观点告诉你,失败并非成功之母;要想让客户接受你的产品,首先得让你自己接受;计划就是瞎猜等等原先你并不知道,原先你认为是正确的,但它却告诉你是错的的一些独特观点。
 
    我自己没开过公司,所站的角度也不同,有些因素可能没考虑到。
 
项目管理
    什么是项目管理?说得简单通俗一点,就是利用各种手段与资源,在指定的预算与时间内完成项目。时间与预算基本是不变的,资源只能有限度的调配,但手段却有无数种,正所谓有100个项目经理就会有100种管理方式。
 
    抛开一切外在的因素,项目的成败,很大程度取决于项目经理的管理水平,以下是关于项目经理的几个问题:
  • 项目经理真的完全理解客户的需求吗?——正确理解需求,才能减少返工,项目进展会更快
  • 项目经理把需求完整的传递给项目组了吗?——吃苹果怕吃到半条虫,说话怕只说一半
  • 项目经理关心过某个功能模块的业务流程吗?——通常项目经理最了解业务流程,能够给项目成员们最好的业务指导
  • 项目经理登录过几次系统?用过哪些功能?这个丑陋的玩意儿真的是客户所期望的吗?——通常项目经理最了解客户的需求,这时项目经理就是最好的客户代表。可以从功能界面、业务流程、业务术语等检验系统是不是客户符合客户最初的期望,是否有需要改善的地方。
  • 项目经理,你有没有把客户后续的反馈意见传达给项目组了吗?——项目组的所有成员都应该知道客户的想法,而不仅仅是项目经理知道
  • 项目经理不正确的决策,导致项目加班加点,项目进度滞后——多征求项目组的意见,你的意见不一定是对的
    以上第3、4点,通常最直接的导致客户的不满。每当你给客户演示系统的时候,客户经常会对你提的一些问题:
  • 界面太丑
  • 界面的业务术语或操作提示完全是从技术人员的角度进行设计的,项目经理或分析人员到底有没有参与到这些业务流程的设计,对术语、提示进行梳理,并指导技术人员进行开发?——例如,有些技术人员在做异常提示的时候,把后台代码抛出的异常直接显示到页面了,这是非常低级的一种错误
  • 这个问题已经提了好多次了,我不知道为什么这么简单的问题你们就是不改?真受不了你们
  • 你们从来都不会主动去考虑这个事儿应该怎么做,如何改进,每次都要等到我主动提出的时候你们才会去做,最后做完了还有一堆问题,我真不知道你们想干什么?
 
简洁
    大道至简,大道理通常都是很简单的,简单到一两句话就可以说明白。同样,越是伟大的产品,其设计与使用会越简洁。比如苹果和Google的产品都极其简洁,但却不失其伟大之处,它们都有许多粉丝,都受到很高的评价;再如时下最流行的jQuery框架,语法也是非常简洁,但功能却很强大,而且很高效。
    同样,在做项目的时候,当你问客户希望系统的功能界面是什么样子的,客户常常会告诉你:简洁、大方。虽然这听起来很扯淡,似乎没有任何价值,问了等于白问,客户也许压根儿就没想过这事儿。但由此我们基本可以得出一个结论,简洁的确非常重要!
 
    在这个行业呆的时间越久,就越发觉简洁的重要性,但我发现身边好多人都没有注意到。
    软件的简洁性,不仅仅指系统功能界面及操作上的简洁,而是要保持软件工程的整个过程都尽可能的简洁。比如,做需求分析的时候,尽量考虑既能够满足用户的需求,又不会投入过多的资源,需求分析不一定要面面俱到。功能界面的设计要抓住用户关注的重点,如首页应该摆放什么内容,应该展现什么字段?我们经常忽略的一点是,未深入的考虑界面展现的内容对客户有什么作用,而是一味的往界面堆数据,结果给客户演示的时候,客户会问你,你有没有想过展现这个数据或者用这种实现方式有什么作用?业务流程的设计,尽量保持流程简单,清晰,易于实现。数据库的设计,尽量用最少的表,最少的字段来实现。当然有时需要考虑对数据的冗余,可能会增加表或字段,但这样通常可以减少表之间的关联性,提高处理性能,降低业务处理的复杂性,所以最终整个软件会变得更加简洁。代码上,对于同一功能的实现,也尽量用最少的代码、最简单的方式来实现,这样既减少了代码量,也使代码更清晰易懂,易于维护。
    我发现,保持软件的简洁性不仅能够减少不必要的投入、提高开发效率,而且能够提高产品的质量、更好的满足客户的需求。
    IT大佬苹果公司和Google公司的产品在简洁性上几乎体现得淋漓尽致。
 
程序员的代码不太靠谱
    在这里,我并不是想对所有程序员进行否定,只是想说明一种常见的现象。
 
    一个项目,从开始到结束,可能会经历各种各样的需求变更、功能修改或人员变动,从而项目本身潜在的问题也会越来越多。归纳起来有两大原因:
  • 代码测试不充分
  • 业务不理解
    先抛开测试团队与代码走查等因素,程序员首先必须对自己实现的代码负责。有些程序员,代码写完了,就不会再去看了,他们脑子里的概念是写完代码就是完成任务。有些程序员,测试自己实现的功能时,像是在走过场,跟没测试没太大区别。有些程序员,对业务不理解,但他就是不说,非得要写出不正确的代码;而有些程序员理解业务,但事实上他理解错了。
 
    我们可能经常会问程序员的问题:
  • 这个功能你完成了吗?——答:完成了
  • 做完之后你测试过吗?——答:测试过了,没问题
  • 对于这几种情况,你都测试过吗?——答:测试过了,都没问题
  • 要测试仔细一点,有问题尽早修改,不要到最后交付给客户时才发现问题——答:我都测试过了,肯定没问题
    这下可放心了,工作完成了,测试也没问题。可过几天给客户演示的时候,却突然冒出这样那样的问题,而且还不少,很多都是客户自己发现的。这是为什么呢?当然,软件的问题总会有,但有些确实是不应该出现的。
 
    每当我检查其他同事写的一些代码时,有些时候真的很无奈,甚至想不明白为什么会这么写,为什么会经常犯这样的错误?——真的是不看不知道,一看吓一跳!
 
    所以,有一位真正理解业务的技术人员,对代码进行检查很重要,特别是对核心代码、关键业务模块的实现流程的检查。
 
别再拍脑袋做事儿
    拍脑袋做事真的很危险:
  • 客户提的需求别拍脑袋答应,尽量快速评估一下再答复。如果无法现场确认,回公司讨论之后再给客户答复
  • 客户原来已经认可或正在使用的功能,别拍脑袋随便修改,即使你的很好想法,但在实施之前最好与客户沟通确认之后再做,自作聪明是需要付出代价的
  • 别拍脑袋写代码,先把思路理清楚,画个流程图或伪代码之后再动手也许会更好
 
不要浮躁
    关于浮躁,程序员们应该有比较深的体会。我曾经在《五年程序员人生的点点滴滴》中也提过,但没做详细的讨论。其实只要你摆正价值观,降低姿态,怀着热情去工作,浮躁自然就会不复存在,而且工作也会更开心了。
    在这方面建议看看罗浩的《野兽派游戏》、《降级论》两篇文章,相信里面的一些观点会与你产生共鸣,使你豁然开朗,从增加自己的自信,更坚定自己的目标。
 
注重反馈,提高服务
    最后再提一下,客户的反馈很重要,客户多次提到的问题要特别关注。提高服务意识,多与客户交流,及时反馈问题。
 
    以上内容纯属个人观点,不具有普适性,大家慎用!
 
(转载请注明来源:http://zhanjia.iteye.com/blog/1876344)
2
1
分享到:
评论
5 楼 s11065115 2013-06-21  
    
4 楼 zhanjia 2013-05-27  
damoqiongqiu 写道
挺不错,很多现象都非常普遍

至少大部分我都经历过
3 楼 zhanjia 2013-05-27  
ywbrj042 写道
有很多观点深表同意! 技术人员必须要有理想和追求,有自己的原则并要坚守!

责任心很重要
2 楼 damoqiongqiu 2013-05-27  
挺不错,很多现象都非常普遍
1 楼 ywbrj042 2013-05-27  
有很多观点深表同意! 技术人员必须要有理想和追求,有自己的原则并要坚守!

相关推荐

    简单之美-软件开发实践者的思考(中文高清版)

    第2章 关于软件开发方法论的思考 2.1 方法论的实践场景 2.2 CMM的精髓 2.2.1 过程定义 2.2.2 成熟之路 2.3 敏捷软件开发的精髓 2.3.1 人与实践 2.3.2 海岸灯塔 2.4 最好的软件开发方法 2.4.1 中庸 2.4.2 ...

    信息系统项目管理师 论文 信息系统项目管理师范文

    项目管理师论文写作指南 6 1.大纲中的要求 6 2. 为什么会觉得论文考试难 6 3.论文的格式与写作技巧 7 3.1 格式要求 7 ...项目与项目管理软件 465 周伯生教授谈软件研发项目管理 466 我的项目经验总结 469

    软件开发项目成本控制的几点思考

    软件开发项目成本控制的几点思考,

    软件项目管理师大全(大纲+论文格式+经典案例)

    花money购买的资料,感觉不错,拿出来分享,资料内容包括软件项目管理师经典案例;九大知识领域范文欣赏;项目管理师经验分享;...项目与项目管理软件 465 周伯生教授谈软件研发项目管理 466 我的项目经验总结 469

    关于CMM关键过程域-软件配置管理的一点思考

    此时,如果仍然把软件看成一个单一的个体,就无法解决所面临的问题,于是配置的概念逐渐引入软件领域,人们越来越重视软件配置的管理工作,不懂软件项目的配置管理,就不懂软件开发管理,不对软件项目进行配置管理,...

    项目管理修炼之道(带详细目录)

    这些真知灼见不仅适用于软件项目管理,同样适用于其他产品的开发项目。这是一本可使项目经理即刻上手的名副其实的实战指南。任何类型的项目经理,无论你是使用瀑布式、迭代式、还是敏捷式生命周期模型,都应该反复...

    敏捷软件开发.pdf

     5A.3.1敏捷项目管理  5A.3.2测试  5A.3.3用户体验设计  5A.3.4规划管控、Burn图和系统工程  5A.3.5用例和用户故事  5A.4经久不绝的问题  5A.4.1最佳击球点和下降  5A.4.2固定价格、固定范围的合同  5A.4.3...

    网站项目管理规范指南.rar

    另一方面,在项目管理思想上,国内还处在一个刚起步的阶段,很多公司都处于封闭状态,自己制定独立规范和开发自用软件,进步缓慢;而国外则已经发展有开放的,系统的管理理论和先进的管理工具。这方面的差距是我们...

    从软件开发角度解密_OWASP_TOP_10_应用安全与安全的开发.pdf

    并简述从高层领导到项目管理到业务前线,每个角色有不同的安全挑战和安全思考,如何自上而下的统一对应用安全、安全活动、安全流程的认识,落地安全开发流程。并着重通过示例(OWASP TOP 10 )来解释从研发的视角...

    超市销售管理系统设计报告.docx

    第一阶段:开发前的设置和思考 题目要求: 需求分析 概念结构设计 逻辑结构设计 实体(红色表示主键) 联系(红色表示主键) 数据库逻辑结构设计 登录用户 商品表 供货商 订货单表 订货明细 入库单 库存商品 销售...

    2018年全球软件开发大会资料PPT第二部分

    《Java 自动内存管理技术的现状和未来》-陆传胜.pdf 《JVM问题定位典型案例分析》-李嘉鹏.pdf 《Kubernetes- 面向未来的开发和部署》-Michael Chen.pdf 《OpenResty十年开源的历程和思考》-温铭.pdf 《Oracle区块链...

    软件测试经验与教训

    应该承认,这是一本很吸引人的书。它的精彩之处在于它使各类软件测试人员,甚至是与测试人员打交道的人,都能得到很好的...很适合有一定实际经验的软件测试、项目管理、软件开发、软件工程等方面的工程技术人员阅读。

    地理信息系统应用项目组织和管理

    在最后,介绍了软件研制和开发的质量控制的两个标准,ISO9000系列标准和CMM模型,作为项目开发机构的指导。 本章和地理信息系统软件工程技术一章讲述的内容是互相依赖的,后者重点在于技术,而本章则侧重于组织和...

    需求分析期末复习思考题(1-8章).docx

    案例二:某软件开发小组所开发的一套工具缺少某一特定的功能 重要性:这说明那怕需求明确无误并构思准确,如果我们没有编写文档,软件也达不到期望目标。通过需求文档回复设计人员提出的各类问题。依据需求对系统...

    全程软件测试(朱少民)

    本书以两个典型项目为背景,按实际项目进行的先后次序,循序渐进地阐述了软件测试的全过程。从软件项目启动、需求评审、...本书也可作为软件开发人员、项目经理等的参考书,更适合用作软件测试的培训教材或教学用书。

    禅道 开源项目

    禅道项目管理软件的主要管理思想基于国际流行的敏捷项目管理方法—Scrum。Scrum方法注重实效,操作性强,非常适合软件研发项目的快速迭代开发。但它只规定了核心的管理框架,还有很多细节流程需要团队自行扩充。禅道...

    PerCM个人代码管理软件

    1、现有的代码管理软件的组织构造,自己合理联想; 2、ICSharpCode.TextEditor的重新研究,加速合成; 3、sqlite数据库的使用; 4、自动更新技术的研究; 5、界面库的引入。 立刻行动起来吧! 对陈灯代码管理软件的...

    质量·软件·管理:系统思维(第1卷)2-2.pdf

    在第1卷《系统思维》中,作者指出了开发质量软件包件首先必需具备的一个条件——学会如何对问题、答案以及质量本身进行正确的思考。他同时也给出了一些指导方针,这些方针能够促进我们进行必要的此类思考。“及早...

    利用AOP的思想,通过方法交换(Method Swizzle黑魔法思考类似需求的处理方案.zip

    软件开发设计:PHP、QT、应用软件开发、系统软件开发、移动应用开发、网站开发C++、Java、python、web、C#等语言的项目开发与学习资料 硬件与设备:单片机、EDA、proteus、RTOS、包括计算机硬件、服务器、网络设备、...

Global site tag (gtag.js) - Google Analytics