当前位置:首页 > 开发 > 研发管理 > 正文

大道至简

发表于: 2014-01-03   作者:clq9761   来源:转载   浏览:
摘要: 一、编程的精义所谓编程实际上就是把一件事情交给计算机去做,你认为这件事该如何做,就用“程序语言”的形式描述给计算机。程序=算法+结构,在这个公式里,代码是不存在的,存在的只是思想。   二、懒人造就了方法人的精力终归是有极限的,提出新的“方法”,解决的将是影响做事成效的根本问题。   三、团队缺乏的不只是管理1、从管理的角度来看,项目失败与否与项目经理的经验直接相关。&

一、编程的精义
所谓编程实际上就是把一件事情交给计算机去做,你认为这件事该如何做,就用“程序语言”的形式描述给计算机。程序=算法+结构,在这个公式里,代码是不存在的,存在的只是思想。

 

二、懒人造就了方法
人的精力终归是有极限的,提出新的“方法”,解决的将是影响做事成效的根本问题。

 

三、团队缺乏的不只是管理
1、从管理的角度来看,项目失败与否与项目经理的经验直接相关。
  项目的成功主要由两个方面来评估的:项目完成质量和项目完成时间。


2、体制的内涵是分两个方面的,其一是“体”,即“体系”,其二是“制”,即“制度”。“ISO质量体系”所产生的那份手册只是“制度”,在这份制度的背后,所要求的是对旧有“体系”的改变,而不是搬来一本“管理制度”给每个员工读一遍就可以了。


3、组织模式确定的同时,相应的制度也应随之建立。制定制度既要做到人性化,又要做到公平性。
通常情况下动摇制度的人往往不是犯错的员工,而是管理者自己。


4、跟随蚂蚁,但不要栽进蚂蚁洞里,尽管你也是团队中的角色,但千万记得离蚂蚁洞远点。你在洞外张望,可以发现问题,你在洞内,就只有做“循规蹈矩”的蚂蚁。管理者是那个可以在洞外放木棍的人。


5、确定被“弹性分工”的员工需要可以快速地转换到新的角色。但首先要考察的并不是他是否“有能力”胜任
这个角色,能力可以通过学习来增强,而角色的转换,则首先是思想的转换。

 

四、流于形式的沟通
1、“问道于盲”是没有错误的,真正的错误是你睁着眼睛问。


2、你要确认你的沟通方式是否有效,而不是去追求这种方式是不是UML,以及你用UML表达得是否正确。
  客户是因为他认为你理解了他的需求,而在“需求确认书”上签字,而不是因为你的UML图画得是否精准。


3、沟通的三层障碍:沟通的第一层障碍并不在于你要表达的内容,而在于你如何表达,换个说法就是不知所云。
沟通的第二层障碍出现在跟聪明人的讨论中,让人觉得“不知所为”。这种情况下应当预设前提,并尽早阐述结论。沟通的第三层障碍主要表现是:不知缓急。解决之道是不要把沟通目标设定为让对方认同。


4、沟通不过是手段,是工具的一种,而管理者的目标是项目本身。用尽可能少的人、在尽可能短的时间内做出决策,这是降低沟通成本的关键。有的“异”观点无关宏旨,无碍大局,可以存而不论。


5、应保障每一次沟通的有效性,得到的每一次沟通机会,都是向客户了解更深层次需求的机会,
因此最好在见到客户之前,就已经设计了所有的问题和提问方式。


6、应该为项目做好历史记录,历史记录为项目的后续开发、维护提供了可能,为不存在的角色留下了沟通的渠道。历史记录包括需求阶段、设计阶段、开发阶段、测试阶段等各个阶段的文档和报告。


7、在每一次回顾项目时都应该注意:流于形式的沟通,极有可能是你的项目被不断推翻和不断延迟的最直接原因。

 

五、失败的过程也是过程

1、实现才是目的,很多人把问题的本质给忘掉了。从最开始,从我们编程开始,我们的目的就是实现一个东西。
无论这个东西是小到称手的一个工具,还是大到千万的一个工程,我们的目标,都是要“实现”它。


2、越是简单的东西,往往越是接近于本质。


3、工程不是做的,是组织的。我们当然不能“做”工程,而是要“组织”工程。项目经理的工作,
  就是要去组织这个工程中的各个角色,使得分工明确,步调一致,共同地完成这个项目。


六、谁是解结的人
1、企业文化是一种群体现象。群体现象本身除了长期的自我演进之外,另一种就是由管理者所引导的团队文化
 所扩散出来并进而产生影响的现象。


2、经验,是源于对过去的思考,而不是对过去的复制。面对那些在你面前说“我们曾经这样成功地做过”的空降者,不妨先把他们想象成一条条肺鱼。只有提得出质疑,才能换个角度去看到那些成功经验所依赖的背景,
也才能看到某些成功背后的偶然的或者关联的因素。


3、应该记住管理者的责任也包括“监督,发现问题并防止扩散“。因而要主动给自己留下时间和空间来发现问题,在问题出现之前定位它、分析它,并组织人力去解决它,而不是等到问题出现之后再去冲到前面,
然后在还没有清楚地意识到问题的根源时就试图解决之。


4、先人后已,管理者一定不要忘记在开始“忙”之前做一件事:驱动你的团队。
问问自己:“如果这件事不做,会如何?那件事不做,又会如何?”找出影响面最大的一件,
交给别的人(或者大家)去做,而自己做“不是太重要”的那件事就可以了。


5、如何看待一个问题是不是问题取决于你对问题的观察角度。普通球员关注于眼前的得失,
所以看到了失球的“问题”,乔丹关注于比赛的得失,所以看到了得分的希望。


七、从编程到工程
1、语言只是工具,程序=算法+结构。这是编程的本源定义,也是原始的状态。


2、《三十六计》更多的时候是被当成方法论来读的。其根源在于“计谋”本身只是方法,而不是战略。


3、BOSS(经营者)决定了一个方向,组织者保证决策与这个方向是同步的,而工程是在这样的一个方向、
决策的构架下的一个具体行为。


4、实现是软件开发的本质需求。因而实现方法总是最先出现的,而后才有分析和设计方法。


八、你看得到工具的本质吗
1、使用工具的方法,比工具本身更关键。所以“欲善其事,先利其器”这样的言率,未见得是全对的。


2、工具的本质,如同工程与编程,单以编程而论,讲究技法之精妙,追求细节与枝节是可以的;但对于工程来说,能让团队理解、统一执行、迅速有效的实战技法,才是真实所需的。就像战争一样,团队化的工程中,
技术的优劣并不是关键。关键在于某种技法是否能为团队带来整体的成效,而不在于某个人是否喜欢,或者深谙于此。


3、沉浸于技法越深,便越容易忘记使用这种技法的最初目标和应用场合—就如同陈尧咨仅仅把射箭看成技艺,
而看不到它作为战场武器的本质;亦如同卖油翁一味演练技法之高妙,而不考虑卖油才是目的,而技法只是表面。


4、工具之用,到了融通地步,也就无所谓“选择哪个工具”了。但是所谓融通,是基于对工具背后思想的了解。


5、了解Interface之后,才真正地有了“软件设计”的观念。而一旦有了软件设计的观念,“实现”的过程,
就变得越来越不重要。


九、现实中的软件工程
1、愚公如果停下来,思考的问题可能是碎石的“方法”。而项目经理从细节中跳出来,思考的问题就应当是
完成工程的“方法”。评价这个方法的好坏的标准只有一个:节约成本。

 

2、不计成本的项目计划不会得到经营者的支持;毫无目的地消耗成本是项目中的慢性毒药;
最致命的风险是成本的枯竭。


十、具体工程
1、广义工程的定义:面向“软件活动的根本任务”;程序实现的过程无助于求解根本任务。


2、狭义工程的定义:面向“具体工程活动的需求”:实现;求解“根本任务”只是将“实现”作为一个过程或
结果的探索活动或附加价值。


3、在所有实践活动中最重要但也是最难保障的就是:控制规模。规模分成规、模两个方面,前者是边界,
后者是形态。做更多的事情,以及把事情做到“更好”,等等,这些都是项目边界的失控。


4、从思维法的角度来看,广义工程考虑的是对工程问题的“统治”,而具体工程则考虑的是“分治”。
分治关键在于隔离问题域,找到造成混乱的问题之间的关系,以及分类出无关的问题。


十一、是思考还是思想
1、知律而变,死读一本《软件工程》的人不会做真正的软件工程。

 

大道至简

  • 0

    开心

    开心

  • 0

    板砖

    板砖

  • 0

    感动

    感动

  • 0

    有用

    有用

  • 0

    疑问

    疑问

  • 0

    难过

    难过

  • 0

    无聊

    无聊

  • 0

    震惊

    震惊

版权所有 IT知识库 CopyRight © 2009-2015 IT知识库 IT610.com , All Rights Reserved. 京ICP备09083238号