随笔-72  评论-20  文章-0  trackbacks-1
  2010年3月25日
   工作五年,一晃已年过三十了。读研时,独立做项目,毕业头三年,主要在大公司工作,后来,也就是08年,半创业。具体点,合伙人吧,自己负责IT部门,到现在6人,公司总共20来人,旅游业。这两年严酷的创业经历,让我越发觉得管理(做事),以及领导(带人、待人,不是管人)的重要性。因为,随着组织的扩大,混乱度无形中就会增大,管理和领导,就是让这种混乱重归有序,重归单人作战那种意图和行动的高度统一。

    说得功利点吧,一个人的财富和其影响力是成正比的。影响力本质上就是对他人的价值。比如,郎_xian_评的出场费一天超过15万。作为技术人员,如果我们只能影响周边几个人,那么我们凭什么拿那么高的报酬,除非我们做的事情影响了很多人,比如杨勃的豆瓣网。所以,我还是觉得,技术人员往高处发展,逐渐应该有管理意识、培养自己的管理能力。技术从书本上可以学到很多,管理还真得实践,书上看到的,你觉得很弱智的问题,比如盲目扩张,自己亲身经历时,一样会犯,也许是行为习惯在起作用,看书不足以改变行为。

    回到正题上。
    也许是自己曾经在较大公司或团队的做事习惯和视野,刚创业时,用在这种小团队的商业项目开发上,几乎惨败。
    先说项目开发这块吧。
    大家知道,项目管理和过程管理是两码事,前者关注目标和进度,成本和收益;后者关注做事流程、方法。
    项目管理,体会最深的,就是目标和任务分解、进度控制,以及沟通。

    项目管理软件
    从大公司出来的人,我想最喜欢玩的,就是借助于项目管理软件(核心是甘特图)。市面上的大多数知名的项目管理软件,无论是桌面版还是网页版的,我都试过。当然最后也选择了一款:ConceptDraw Project,用了一年多,也多少有些用。但最后还是发现,它其实对项目进度和质量关系并不大。也许,一个Excel表格更实用。
     项目管理软件,本质上是解决一种沟通和职责分配的问题。比如,一个项目,折叠成一个三层树形结构,老板只关心第一层,也就是整体进度;中间是项目经理关注的功能层,最后一层,也就是具体的任务,是开发人员关注的。想想,如果没有这玩意,你怎么告诉其它项目干系人进度?但又引出几个问题:
    靠文档来沟通,还是靠信任? 太在乎文档,往往导致每天去关注文档如何漂亮、有说服力,并为此花大量时间,而不是项目如何漂亮。另外,是否有文档就可以防止扯皮、兑现承诺?我们是关于项目目标,还是关注彼此的博弈?

    进度偏差 创业型项目,往往都是以前没有接触过,其进度评估往往有很大误差,比如业务需求的挖掘和变化,技术难点,开发人员素质。我们是关注进度,还是关注项目本身的质量?两者都要,但如何兼顾?虽然有方法学,比如砍掉优先级低的,但你怎么让老板相信某个核心功能就得四天时间。
    在我们的进度设计不合理情况下,是否开发人员完成甘特图(WBS)下的任务就ok?远远不够,任务分得太细,往往限制了开发人员的创造性和自我评估能力,如果提前两天完成呢?
    我们现在是以项目管理软件为辅,任务的下达主要以邮件传达,每周一上午的周例会会白板宣布。我发现白板比投影仪PPT好用。

   关于规范
   这也是大公司特别喜欢玩的。
   也许我们前期会制定一个的架构、设计文档,代码规范,这有一个规范建立的时间成本以及规范本书的合理性,再说如果一个开发人员,特别是高手,如果不认同你的设计和规范,你要强推,他要么走人要么怠工。规范的本质是为了协作和后期可维护,如果只有两个人或一个人写某个模块,你觉得有这个必要吗?规范整洁的代码,在项目初期,对用户的价值关系很小,你会关心豆瓣网的js代码写得很漂亮吗?我们应该关注代码的健壮性而不是可维护性,我们不是在开发Windows。

    人适应项目,还是项目适应人
    大公司,往往是来了一个项目,赶快招人,人来适应项目。小公司呢,我现在的看法是,项目适应人。小公司,往往一个项目做砸,公司就面临解散。所以,我认为,最好还是按照开发人员的擅长,保证功能质量,最快的速度上线。另外,为了达成进度,可以在上线初期砍掉不太重要的栏目或功能。
    我在这个上面栽过跟头的。比如开发人员的擅长,如果他擅长jsp开发模式,而不是Hibernate+Spring的分层开发,就让他按自己的意思做吧。因为,创业型项目都不会太大;即使技术实现你感觉完美了,用户可能感觉不爽;再说,项目开发,涉及到业务调研、需求分析、原型界面、架构、开发、部署、推广。开发,也就是代码实现,占去项目时间,也许不到30%。项目如果证实有商业前景,代码重新实现一遍,花不了多少时间。
    但我也深深地意识到我们项目管理的级别,就如同CMM1到CMM4。但我还是觉得目前是最好的选择。
    如果最低层次的用户需求目标都达不到,直接考虑代码怎么有可扩展性、可维护性,对于小公司就是找死。
    另外,尊重和信任、支持开发人员的技术选择,往往是一种激励、增强团队凝聚力的方式。万众一心,比什么目标、进度更有效、实际。
    我们应该培养一种团队成员的内部创业心态,而不只是敬业。

    在进度把控上,我现在更倾向于强调我们的项目目标和紧迫性,而不是他们的任务。因为我希望大家的关注点是项目,而不是他的上级,他应该对项目负责,而不只是对上级负责。

    说说沟通
    项目管理中最难处理好的,就是沟通。以前,我比较关注于工具,如邮件、文档、ppt讲稿会议,逐渐我关注效率和效能,特别是态度。沟通最基础的就是态度。如果网站上线后,订单提交出现一个核心bug,你是直接找开发人员问责;还是告诉他哪儿出了问题,这个问题的严重,并且自己反省,比如测试流程出了问题。出现这种事情,也许需要负责人举重若轻的气度。但更深层次的,如果负责人能够培养其员工质量意识,危机意识,才是治本。因为一个有强烈质量意识的团队,他自然会去对代码健壮性、功能易用性精益求精,自然会去配合测试流程。
   刚才那个沟通问题,对开发人员的态度,前者是负面,后者是中立。那么前者,开发人员的反应是如何不让领导下次责怪自己,比如只做领导安排的事情;后者的反应是怎么去改进,不让这样的事情发生。
   如果你认可创新就可能出错,如果你认可开发人员都是想做好的。那么所有的事情,朝正向发展迈出了最决定性的第一步。

   沟通:命令式还是征询式
   在沟通,特别是下达任务或做决策这类事情上。应该说中国绝大多少管理者都是用命令式。我过去经常在用,但一直在试图改正,改用建议式和征询式。管理者最需要、最难开口的一句话是:Do you think so?命令的方式,经常出现下级不能理解上级的意图,严重的出现抵触。每个人,其实都喜欢别人按自己的想法做事,但你怎么知道自己的想法或决策是对或不是偏颇的,怎么让团队愿意去执行?去征询团队其他成员的意见,让他们参与,往往能够培养其主人翁意识、责任感、向心力,还能够完善自己的想法。但要将员工参与意识,转化为一种习惯,太难。
    当大家都没有主见时,需要领导者的果断、魄力和强势,但这种机会并不多,而且这种情况,需要团队成员对领导者的信任。
   
    遵守制度,还是建立信任
     在大公司,往往是告诉你怎么去遵守公司制度。在小公司,我认为最基础、最核心的一件事,就是建立信任,让团队信任你的人品(说到做到),信任你的能力(能够把大家带到一个新的高度)。建立了信任后,下一步的核心工作,怎么将你的个人目标,也就是团队目标,转化为每个成员的个人目标。
    有了信任这个基础,才会有了团队建设的第二个核心:激励。
    是激励,而不是约束、监督,让团队有战斗力。但大公司往往喜欢后者。也许,大公司都是职业经理人,反正是打工,太关注于事。如果说有个所谓的中国式领导,我觉得就是以人为本,对人的尊重。人的关系处理好了,事情就好做。
    加班、考勤、上网监控,这类对信任、激励极具破坏力的行为,也许是工业型社会对我们这个思考性创造性行业的侵蚀。知识型劳动者,需要一种与体力型劳动者完全不同的管理模式,这种模式也许需要一个从萌芽、生长到成熟期。现在在目前的中国,还只是刚走出萌芽期。
   
    以前完整看过余世维的11套视频,还看过几遍。他那种人本理念我还是很认同,只是,他在大公司、规范公司的做事情方法和风格,完全照搬拿到小公司,非常危险。你能够拿幼儿园那种教育方法来教育成年人吗?小公司不具备大公司那种职业化的环境,也不具备大公司在行业中的市场地位及资金实力。
    如果说大公司讲究做事方法、流程,如SWOT分析法、BCG矩阵,小公司更看重灵活性、市场适应性。小公司应该适当短视、急功近利,否则在你实施一个三年计划时,第二年还不赚钱可能就撑不下去。
    所以我觉得,在跨国大企业呆惯了,出来创业很危险。一个是做事方法不适应,另外一个就是没有平台。如果要出来创业,以前那种大企业的经历可能更是一种劣势。 也许有一种情况,你是大公司的高官,拿到一笔很大的风险投资,然后出来创业。
    
    人事招聘
     薪水  如果公司给得起,并且应聘者能力差不多。 就不要太在乎那200、300。虽然说至少要不低于行业平均值(IT人员是IT行业平均值,而不是本公司所在的行业平均值),但最重要的,还是不要低于当事人的期望值,因为最核心的是满意度,而满意度决定于期望值和实际值的差距。对于小公司,往往一个人技术人员的成本和收益,和其工资差距非常大,有可能10倍。所以,我们的关注点,应该是怎么一开始留住这位人才。然后,怎么让其充分发挥潜力。小公司往往不是因为节省那几千几万的工资成本死掉的,而是充分利用这位人才才活下去了。

     另外,不要以为有多少人才选择的机会,小公司往往不受高级人才的青睐。太高级的人才,可能养不起,而且往往太有个性,很难合作愉快,除非在来公司前有很长时间的了解。
     招聘到合适人才后,应该让其忘掉薪水,专注于工作,寻找工作本身的乐趣。当然,要做到让其在薪水上有优越感,也许是项目很盈利的那一天,开始时很难。

     人才标准 如果其能力和你预期相差不大的话,更应该考虑其态度、做事风格,甚至是价值观。因为其能力的发挥,和这个环境,特别是他的直接利益相关者,也就是上司,关系太大。如果配合得好,一个人可以顶三个。否则,那种内耗导致的进度延期,由此引起的市场机会丧失,公司财力无法支撑,往往是致命的。因为一个几人的IT团队,每一个人的职责就如同那木桶的一块板,缺了那块都存不了水。
     比如关于质量,更确切说是内容质量,我们目前做旅游电子商务,我认为内容质量很核心。但你招进来的同事,始终认为先要量,什么都可以抄,而我强调质,原创、半原创,可以少而精,而不能多而乱。除开项目进度,怎么去沟通?最好两个人一开始都认同原创的力量。

     提升一个人的技能不难,但改变一个人的态度比较难,改变一个人的价值观几乎不现实。所以先找志同道合的人吧。    
     别期望人才是可替代的。我们不是大公司,我们缺了谁,那一块就不转。
     大家都知道,松耦合要付出代价,比如SOAP协议的低性能,AMF私有协议的高性能。创业期,不要太多考虑人才替换,而是关注怎么发挥人的潜力,留住人,尽快高质量完成项目。人才替换的一个假设,可能是你对自己管理的不自信,因为你不相信自己能够留住人。
    
     这次就写这么多吧。
     我似乎有这种体会,考大学、四六级这类资格、证书类考试最好混,因为只要勤奋就可以,再加点方法就可以出类拔萃了。  上班也比较好混,说找工作吧,像我搞技术的,本身对技术很狂热,根本就不愁找不到工作,因为面试时我觉得那家伙应该比我牛,正好可以切磋切磋,没想太多所以没啥怯场或不自信。工作吧,如果是技术类,特别是商业软件,技术难度都不大,按上司意思来,很容易搞定。创业呢,自己要做商业判断、业务决策,还要协调若干人的工作(协调的本质是协调利益)。做事和管事,完全是两码事,有些难。不过,创业还是很有意思,因为你可以按自己的意愿去工作去生活,当然也是受限环境的自由。


我将我的一个回复放在这个地方,特示警醒:
告诫各位处于开发第一线的朋友,千万不要受本文的误导,把规范和设计文档不当回事。

我的看法:
1、文档的多少和深度决定于项目环境。
    如果是大项目,比如二三十开发人员,架构文档、需求文档、代码规范等都是必须,否则开发人员不能迅速了解项目技术和业务特点,从而无法快速开发,也即是规范可以降低培训成本和团队沟通;另外,项目开发中后期可能根本不可控,谁都看不懂其它人的代码。部署时看到的一些bug无法及时修复,因为到处都有地雷。我以前经历过这样的项目,最后加班都没用。

    如果是产品型,规范更重要。当然我说的产品可能是2.0版以后,因为这时候的产品基本得到了市场的认可。而在初版时,代码写得烂都没关系,因为你不不知道用户会不会买单,也不知道能否按进度开发完成。而在后续版本,如果没有规范文档,维护的成本都不亚于重新开发。特别是处于一线的开发人员会怨声载道:为什么要我来收拾残局?那么,这样的士气,开发效率怎么会高,项目质量怎么会高?

2、成熟型大公司那套做事流程,可能高手受不了,但可能是最优的方案。因为,到项目后期维护,往往只是一些业务功能的删减改进,不需要技术高手,这个过程可能漫漫几年,项目维护成本会非常高,雇佣高手一来他不愿意干二来也不需要这种人,如果项目代码还维持在一种“秩序”,初中级开发人员就可以胜任,有什么不好呢?
   项目上线时,是为了追求利润。项目维护期,是为了省成本。

3、刚入道的朋友,最好是按规范来,就像学武术,先要学套路。否则,养成的编程坏习惯,比如文件名叫Aaa1.java,代码没有缩进。过几年非常难改。而好的编程习惯,可以提升开发效率,还能让自己思维清晰。
   学技术阶段,一定要注意代码的可维护性、健壮性及灵活性,只有养成对代码精益求精的态度,你才可能成为技术高手。技术学好,做技术管理就有了基础,而且别人也会服你。

原文地址:http://www.javaeye.com/topic/646406
posted @ 2010-05-06 12:35 前方的路 阅读(514) | 评论 (0)编辑 收藏
     摘要: 开发和架构的界限难以捉摸。有些人告诉你它根本不存在,架构只是开发者们所做的设计过程的简单扩展。 另外一些人认为这是一个鸿沟,它只能由那些做到高度抽象,而且不会陷入实现细节的开发者才能跨越。通常,在这两个极端的观点中间某处有个可操作的平衡点;不论如何,怎么从开发转换为架构师都是个有趣的问题。

经常被用来区分软件架构和软件设计开发的关键几点包括 伸缩性和抽象程度的增加以及作出正确设计决策意义的增强。软件架构是通过一个全局的观点,宏观的视角来理解软件系统作为一个整体如何工作。

即使这能够帮助区分软件开发和架构,它并不能帮助理解某人如何从开发提升到架构。 并且,它也不能帮助识别谁能够成为一个好的软件架构师,如果你想雇人的话你如何去寻找他们以及你是否是一个软件架构师。
  阅读全文
posted @ 2010-04-19 16:50 前方的路 阅读(269) | 评论 (0)编辑 收藏
     摘要: Flashback 技术是以Undo segment中的内容为基础的, 因此受限于UNDO_RETENTON参数。要使用flashback 的特性,必须启用自动撤销管理表空间。
在Oracle 10g中, Flash back家族分为以下成员: Flashback Database, Flashback Drop,Flashback Query(分Flashback Query,Flashback Version Query, Flashback Transaction Query 三种) 和Flashback Table。  阅读全文
posted @ 2010-04-14 17:38 前方的路 阅读(540) | 评论 (0)编辑 收藏
     摘要: 代码检查是白盒测试的一种静态测试方法,是众多软件测试方法中发现软件缺陷最有效的方法之一。本文结合国内外学者在相关领域的研究情况,介绍代码检查相关的基本概念、过程和分析方法。  阅读全文
posted @ 2010-03-25 18:17 前方的路 阅读(2415) | 评论 (1)编辑 收藏