栖息谷-管理人的网上家园

标题: 我的项目,请大家指教 [打印本页]

作者: 无心快语    时间: 2003-7-21 15:18
标题: 我的项目,请大家指教
公司背景:软件公司,主要集中于GIS(地理信息系统)领域,100多人(研发70多人),主要客户为政府(规划、国土、环保、统计以及银行等),在华南地区有一定实力,下辖三个核心业务分公司(也就相当于部门):数字城建(40多人)、数字环保(10多人)和商业智能(10多人)。

公司成立5年多,2001年被一上市企业化3亿买下(原属于市规划局),公司目前的老总2001年底上任,政府出身,不懂技术,两个副总均为博士,其中副总A兼公司总工,负责所有技术以及数字环保和商业智能,副总B负责数字城建,但由于B与资方不合,数字城建的工作是由数字城建分公司的老总在负责。

公司所作的项目基本上都是比较传统的GIS项目(目前有一些拓展,主要集中在商业智能部门),一直走的微软的技术路线,开发工具VB为主。

项目背景:这两年,以SUN和IBM为代表JAVA(说具体一点是J2EE)和微软的.net技术已走向了成熟,很多时候与客户聊或者投标,他们开始开口闭口的网络开发,要求系统基于WEB(B/S模式),甚至明确提出要用J2EE(这一点我在北京就亲身经历过),迫于市场压力,公司决定技术转型,从各分公司抽调18、9人成立了技术创新部,这18,9人多数是兼职的形式(他们都有具体的项目),其中抽调了8人成立了核心的攻关小组(这8人是专职的)。任命我为部门的技术负责人,还有一个女孩负责行政事务性工作,我的直接上级是副总A。

这个核心攻关小组的工作是就J2EE和.net两条路线对公司的现有产品和项目做改造,形成一整套的解决方案和系统,系统要求通用,其他部门的开发人员可以在其上做二次开发,最好能做成产品直接拿出去卖。

公司在j2ee和.net上没有任何技术积累,原先的打算是两条线同时做开发,一边4人,我作统筹(我在加入这公司之前做过j2ee和.net的项目,这是任命我为部门的技术负责人的主要原因),核心8人中有4人来自商业智能(即原打算做.net研发的那4人,我也是来自商业智能),但正巧这个时候商业智能中了一个建行的标,其技术路线是.net,于是公司决定以建行这个项目为依托来做.net的研发,即原打算做.net研发的那4人做建行这个项目。这应该说是一个很明智的决定,但问题是我就陷入了两难境地,建行这个项目我一直在跟,包括当初的投标的demo都是我做的,这里面有部分技术公司还暂无人能顶替我,所以公司领导要求我既要做建行这个具体的项目(我只负责一部分开发工作,不是这个项目的项目经理),又要我负责技术攻关小组的工作,两头兼顾,我担心最后两头都没做好。

建行项目10月中旬验收,但银行其实和政府差不多,估计到年底才能真正验收。
技术攻关的项目初步预计年底或明年1月内部验收。

个人背景:本科毕业三年,加入这家公司一年,程序员出身,拿过几个认证,这家公司的开发人员大多GIS出身,相比于他们我的长处就是软件开发技术(尤其是新技术方面),短处就是在传统GIS领域我不如他们。

尽管是技术出身,但我一直对经管感兴趣,参加了2003MBA联考(清华,差10来分未能上线),看过一些经管类书籍,如罗宾斯,萨翁,波特,德鲁克等,比较倾向德鲁克的目标管理。

团队背景:负责建行这个项目的团队大家都来自一个部门,而且有具体的项目,大家目标明确,所以这个团队问题不大。关键是j2ee这一条线,加上我一共4人,但其他3人全部来自数字城建,我和他们不熟悉,而这三人都是公司的骨干,进公司至少有2年,而且都做项目经理,带过项目,技术实力强,但优秀的程序员有个通病:比较固执和自傲,这一点在上周的第一次部门例会上我就领教过了,他们都大力向我推销以前作过的项目,希望把这个项目引到他们熟悉的方向(在他们的话语里面有点认为我做的开发计划过于简单,不符合实际),我暂时没有反驳他们,而是告诉他们先要熟悉新技术,等对j2ee有了足够的了解再来做产品设计,并且分配了任务,一周后检查。


问题:1、这个项目成败的关键在何处?技术,管理,团队?
我的观点:我认为团队是关键。
2、我如何控制这两个团队进度?
3、如何建设好团队?
4、project这种工具需不需要(我以前用过project2000,但觉得好像对项目没有太大的用处)?需要看哪些书(短小精悍为宜)?
作者: 无心快语    时间: 2003-7-21 15:19
絮絮叨叨的写了这么多,不知把问题说清楚了没有,还请大家多多指教
作者: asususa    时间: 2003-7-21 16:58
提示: 作者被禁止或删除 内容自动屏蔽
作者: fangrobert    时间: 2003-7-22 17:28
管理肯定是最重要的,至于技术和团队只是你在管理好这个项目中的一部分。目前的问题是如何使你的项目组成员尽快就项目的总体目标方面达成一致,给他们一个美好的愿景,他们目前之所以不愿意采用新技术,除了对J2EE了解不多以外,更重要的是在他们心理还没有真正把你放在领导的位置上,这个时候要象楼上说的那样发挥你的个人魅力,同时你要考虑在这个项目建设中会给他们带来什么好处,一定要让他们清楚的知道这些。

至于这两个项目,我个人任务不管从公司的发展战略方面还是基于J2EE技术的美好前景,你都不应该将你的主要精力放在银行项目上,更何况你是新项目的项目经理,甚至你可以说服领导退出银行项目,全力以赴一件事情,对你现在的情况来说更合适。
作者: 无心快语    时间: 2003-7-23 09:57
楼上两位说的甚有道理,今天较忙,改天得空再慢慢聊
作者: 无心快语    时间: 2003-7-23 10:04
这是一个项目组成员给我的mail(略有删节)

XX,您好!

  谢谢,我已从您共享的目录中查看了一些文件。
    对于项目的开发,我有一些建议,供您参考。这是初步建议,希望对您有帮助。
    1、我们开发的项目的JAVA技术背景比较薄弱,并且由于开发时间只有短短的一个多月,所以时间显得非常的紧。
    2、我们已做的OA系统已比较成熟,它是服务端与客户端相分离的,所以定义起来比较灵活。
    3、以及我们投标过程中,遇到的需求是应用要求是B/S结构,而定义等(属于服务端内容)则C/S、B/S不限。
    4、鉴于目前的情况,我建议吸取已有项目的精华部分,而实现我们急需的功能。
    5、现在主力开发的应是客户端的功能,
    6、对于业务定制,可利用现有的服务端,在服务端定义人员机构、权限、业务表格及数据库维护等内容。做到一次定义,C/S、B/S都可运行的目的。既可把以有的内容得以充分利用,也可保护客户的劳动成果。(当然,现有的服务端也需要针对JAVA进行修改。)
    7、如果客户端实现后,时间允许时,我们再把业务定义的功能用JAVA实现。

    另外,建议您抽时间过来看看我们现有的系统。会更清楚些。
    让我们齐心协力,共同把项目做好。

我的回信:
非常感谢你的建议,我谈谈我的想法,供你参考:
1、从现在起一直到8月中旬,我们的主要工作还是集中在对新技术的把握上面,根据我的经验,从了解java到j2ee编程,至少是2个月时间(我当初是自学的),而根据目前项目的计划只给你们一个月左右的时间,所以时间很紧,对你们的要求也很高。所以我的考虑是在这一个月时间里,你们暂不要考虑将来要做什么?以技术为主,过早的考虑业务问题会束缚住你的手脚的。

2、公司现有的OA肯定是要去了解的,下周新机器应该能到位,到时候我希望你、XX还有XXX把你们原做的项目安装在那台新的服务器上(新服务器的系统安装还请你多费心了),抽个时间大家一起来看看这几个系统找出一些有共性的通用的东西作为将来项目设计的方向。

3、我了解到你们三人都是公司的骨干,做过很多的项目,但现在有一点需要转换思维的是我们这个项目组的目标是做产品而不是针对哪个具体的项目,我们不仅仅要考虑城建、规划领域,数字环保还有商业智能等其他的部门都要能用上我们做出来的系统,甚至最好是把我们的系统包装成产品,这就要求我们的设计要尽可能的通用化和抽象化。而且由于现在大家对j2ee还不了解,如果一开始就一个成熟的系统来要求,我担心做不出来大家会有挫败感,所以我抽象了一些很通用的模块,大家从简单的做起,最后把这些小的模块合成一个大的系统。

4、对客户端和服务端的功能如何如何界定,这一点我希望等到大家对技术有了一定的了解之后,大家一起来商讨这个问题,以前我们项目的很多功能是放在服务端,那是因为我们对WEB编程不了解,而放在服务端处理起来更容易,但现在既然我们的目标是B/S的开发,我个人希望还是弱化服务端,尽可能让客户端完成绝大多数功能(当然是有权限控制)。

这个项目对公司很重要,而对个人也是挑战和激励(不然公司不会把你们三人集中在一起了),相信只要大家齐心合力,年底我们肯定能给公司交上一个满意的答卷的。

(至于项目时间问题,我会尽力向公司争取,公司高层对这个项目的要求也是质量第一,时间上可以适当宽松一点)
作者: asususa    时间: 2003-7-23 14:47
提示: 作者被禁止或删除 内容自动屏蔽
作者: asususa    时间: 2003-7-23 14:57
提示: 作者被禁止或删除 内容自动屏蔽
作者: bywill    时间: 2003-7-24 18:10
说得都不对劲吧! 呵呵

可能大家都不了解技术的原因。

我现回答一下问题:
问题:
1、这个项目成败的关键在何处?技术,管理,团队?
前提是高层的支持力度。
这是一个外部客户推动内部技术转型问题,但是,内部的中、低层有抵触(技术人员的这种抵触很厉害)。
关键是团队精神

2、我如何控制这两个团队进度?
坦诚相见,强弱结合,技术服人。

3、如何建设好团队?
同上

4、project这种工具需不需要(我以前用过project2000,但觉得好像对项目没有太大的用处)?需要看哪些书(短小精悍为宜)?
大家习惯用什莫就用什莫。工具是为了好的结果。

但是,这里面大家同心协力最重要。

或许,你用小公司创业的思路考虑一下更合适
作者: 扬子    时间: 2003-7-25 15:45
大家一起出去 FB 一下( 可以再叫上几个与项目相关的人员 ).

国人的习惯, 办公室说不下来的事, 在玩乐中饭桌旁或许能敞开谈出真心的顾虑和托词后面的理由.
Seek first understand, then to be understood.
作者: 扬子    时间: 2003-7-25 15:54
三人都是公司的骨干,进公司至少有2年,而且都做项目经理,带过项目,技术实力强,

==> 这就涉及到如何建立你的权威的问题.  这方面你不是技术专家, 不能靠技术"震"住他们; 他们资历不浅, 未必"服"你; 如何通过组织授予的权力以及个人对项目的大局把握让他们接受你, 个人认为这是项目的关键.

他们都大力向我推销以前作过的项目,希望把这个项目引到他们熟悉的方向(在他们的话语里面有点认为我做的开发计划过于简单,不符合实际),

==> 这个分析还可推敲. 他们真的是不了解新技术 ? 还是有别的想法 ?
作者: tulip    时间: 2003-7-25 18:04
呵呵,分析团队建设冲突对项目造成的分险,我也插上两句拙见啦。

分析目前的分险
不仅仅看他可能造成的威胁
是否更要看他的根源在哪里,这些根源现在的表现是什么

就比如现在团队成员对你的工作计划安排有意见,造成分歧的后果,同时影响你在团队中的权威;
而他为什么会对你有上述疑问,难道仅仅是因为他是公司技术骨干,也作过成功的研发项目吗?

呵呵,赞成扬子的看法,干脆大家出去聚会一下,闲谈中问题虽不至于灰飞烟灭,也会展现根径;
了解问题本质后再思量解决措施,总比现在冷冰冰的文字沟通得到的信息实在;
从人的心理来说,环境的改变=心情的改变=行为方式内容的改变
远离固定的工作环境会改变大家说话的态度--------环境会影响团队成员的沟通
很多问题,可能就在谈笑间浮出水面
作者: blacksoul    时间: 2003-7-27 09:23
我的观点:
他们三个以前做过项目经理,他们应该会知道沟通、协调的重要性。
他们应该知道什么样的团队是一个好的团队,应该怎样配合项目经理的工作。

或许他们还不适应由项目经理到开发成员的转变,而你就是要改变他们的心态,关键他们意识到这个问题。
如果他们个性太强,你则需要做好整个团队的冲突管理,较好的办法就是提前了解他们的意图,预防冲突的产生。
作者: 无心快语    时间: 2003-7-28 11:08
看来选择这个论坛发帖子是选择对了,我把这一周发生的事情描述一下,也许能侧面的回答大家的一些问题。

先解释一些背景,我和那位副总B在进这家公司以前就认识(里面的关系三言两语解释不清),私交很好,其实实际上我是他挖过来的,但在公司我们是纯粹的上下级关系,副总B是位很谨慎的人,我进这公司是从最底层做起的,他从不用行政命令提拔我,这次任命我为负责人是公司高层领导的决定。
我与项目的成员的优劣势在与他们比我进公司早,在传统GIS技术方面,他们绝对是比我强,而且在GIS业务流程方面经验也比我丰富,这是我的劣势,我的优势在于我在新技术方面比他们强,我在公司里多次给全体技术人员作培训,经常会有其他部门的人向我请教技术问题。

上上周第一次和大家开会的时候,我给他们三人布置了学习j2ee的任务,要求在下周同一时间每人上台花20分钟来讲解j2ee的架构,以检查学习的效果。这周开会(副总B也在)他们三人加起来讲的时间不到40分钟,只有一人算是对j2ee有了一点了解,其他人还没找到门,于是我站起来,在白板前讲了1个半小时(我事先没作任何准备),讲完后,大家鸦雀无声。我想在这一刻我建立起了我的威信,后面再来布置任务就轻松多了,他们也就不再和我讨价还价了,事后副总B找我谈话,充分肯定了我的工作,要求我按照原定的计划坚定走下去,若有人不配合,则可马上告诉他。

其实在上上周布置工作的时候,我就预计到一周的时间是不可能对j2ee有很深的了解的(但没预想到会这么差),一来是想给他们以压力,迫使他们花力气去学习,另一方面也确实是想给他们一个下马威。

杨子说的FB问题我考虑过,但一直找不到好的机会,下周就将把项目组成员集中到一个房间,而且给每人重新配了新机器,所以我想安定下来后和大家一起去FB,FB。但说实话FB可以给大家一个熟悉了解的机会,但要把事情做好,解决一些深层次的问题,光FB肯定是不够的。

另外银行的那个项目让我有些头疼,其实我是很希望能尽快从这个项目中脱出来,而且也和B谈过此事,但B还是希望我能多负责一下这个项目(这个项目的项目经理也是技术出身,但性格比较柔,事情一急的时候就会迷失方向),我的初步打算是8,9月份将主要精力集中在银行项目,从9月中下旬开始就要转移工作重点。

Asususa提到的:看那位员工的信,应该知道他关心的是技术上的问题。作为团队的领导者,传道授业解惑是你必须的,除此之外是不是可以多一点赞扬和激励呢?信中写的是对你是一种挑战,那么对你的下属呢?是不是同样也是一种挑战?不能只想到自己,很多人都不能很好的做到这一点!嗬嗬嗬……

在email等会留底的文件中我认为是不宜谈太多的个人激励,不是说激励不重要,而是有很多的话是很微妙的,或者说是上不了台面的,在私底下开会的时候(领导不在场)我和他们讲过,其实程序员还是很单纯的,他们很清楚学习j2ee这种流行的新技术对于他们意味着什么。

Bywill和blacksoul分析得很中肯,似乎是同道中人?
也非常欢迎tulip MM的加入(现在这两个项目都是和尚团队,我都在考虑是否要男女搭配一下:-P)
作者: bywill    时间: 2003-7-30 11:46
不要用太多的上级指令方式给大家压力。技术人员很反感这样做。只要让他们感觉到高层的支持就好了。

同时,开始看到你贴的那个邮件就觉得合作不会有问题的。写邮件的那个人很坦诚。一个团队里只要有一个这样的人就不会出现大的分歧的。 :)

技术攻关阶段不要男女搭配!一定要一鼓作气攻下主要问题。封闭起来比较好 呵呵
作者: yukixue    时间: 2003-8-4 15:21
对技术我是外行,但对管理略知一二。楼上说得对,其实有两个方面:一、是你自已不管是技术还是人格魅力都要好。二、是学会用情感、用”我为你着想”来管理自已的团队。
作者: 无心快语    时间: 2003-8-4 22:45
己所不欲,勿施与人

我从来都是这样来要求自己

部门要扩大,项目组要再招3人,事情越来越多...
作者: blacksoul    时间: 2003-8-5 00:08
项目组有新的成员加入,现在要看你的协调能力了,尽快让这三个人融入现在的团队,并且让原有成员迅速接受他们。当大家能融洽共事的时候,合理分配任务给他们,令他们在自己的岗位上最大限度发挥作用。------个人观点,比较笼统,还请见谅!
作者: sun_weihua    时间: 2003-8-6 03:48
项目经理的位置在那里?


项目经理的主要工作是什么?
个人认为, 项目经理对整个的项目负责, 在规定的时间,有限的人力,资源, 和
一定的条件下, 达到清晰确定的最终结果。 所以, 首先要和小组成员, 直接领
导层一起来制定一个大家都可以接受的,清晰明确的项目目标和结果。然后具体的
同小组成员来确定整个项目的过程,计划, 里程碑(每一个里程碑都可以看作一个
小的项目, 有清晰的结果,目标, 时间和资源。每一里程碑完成之后,小组进行
讨论,总结,可以对以后的里程, 计划进行修改。), 里程碑中平行或前后进行的
项目模块(小组讨论,确定每一模块的时间,负责人, 所需资源,等等。  每一模
块完成之后,小组进行讨论,总结,可以对以后的模块,里程, 计划进行修改。),
等等。 让每一小组成员明确他们的权利和义务。
一个清晰,明确的计划不是全部, 但一定是一个成功项目的前提。

软件项目的特殊性是什么?
比较印度软件业和中国的区别可能是, 他们的软件结构清晰, 完整, 但人员的编
程能力没有我们强。不好意思, 我只写过一些小程序, 或许说的牛头不对马嘴,
请见谅。但我想,无论是不是原来的结构可以用, 你蒙都需要在原有的基础上对
程序进行改进,可以对其结构进行模块化, 透明化(如:模块的清晰定义,完整的
中间件,等等)。然后可以以软件的结构为依据对整个的项目进行计划和设计。如果
整个软件(项目)可以细分为一个个很小,相当容易完成的模块, 那整个的软件(项
目)也就可以掌握了。当然说的容易,做的难,但如果可以利用一切“资源”(主要
是小组成员)的话, 一定可以有一个可行的计划出来。(一个开放的环境; 奋进的
成员; 一定的压力; 和谐的关系; 确定的目标;详细的条件和基础的分析;等等
是制定一个可行计划的前提条件。)

一个好的团队需要一个好的项目经理, 一个好的团队需要一个好的领导者,一个好
的团队首先是一个团队。
作者: 无心快语    时间: 2003-8-7 20:32
中国和印度的软件业有很大不同,这个问题太大了,有空再聊。

现在遇到一个人员招聘的问题:
A君:2002年毕业于美国阿拉巴马大学(阿拉巴马在美国东南,弗洛里达上面),学制是1年半,通过了解,应该是正规考G出去的(其实我并不是很在乎学历、专业这些东西),74年,本科国贸(辅修计算机),研究生是计算机,曾经考上国内TOP10的B笑计算机系研究生,大二的时侯出去的。
我对A的感受是书生气较重,97年本科毕业后就一直在B校计算机的软件中心工作,然后到美国2002年毕业,一直在学校的环境中,2002年毕业后在一家硬件公司从事内部ERP的开发,主要在后台数据库的开发(说实话这种工作在国内本科生绰绰有余),所以在技术上来讲能力和经验都很有限,但长处在于他英语好,学习和接受新知识的能力强(面试的时候测试过),在美国学校跟导师作过一些研究,有过一定的研究经验,在眼界方面比一般程序员开阔一些,而且海龟的背景说不定将来打单的时候有点作用,但快30的人了,现在再要他去编码,他愿意吗?就算把他招进来了,能长久吗?

我不是太想要这人,但公司老总对他似乎还有点看重
作者: 无心快语    时间: 2003-8-8 15:41
今天还面试了一个牛人,华南地区的一个工科名校本科生,3年工作经验,大概有1年左右分析、设计的经验,在投递简历的时候就明确指出低于6500不干,6500这个价位不算高也不算低,不过在面试之前就敢说这话到也是颇有个性,于是早上面试的时候我还准备多花点时候和他好好聊聊。

简单的寒暄之后,我问他是否了解struts(是apach组织开发的一种较轻量级的j2ee技术架构,而很多大型网站就是架设在apach之上),他说没用struts作过具体项目,但看过一些文档,作过一些小例子,然后接着来了一句我认为struts做得很糟糕,我完全可以开发一套比他好得多的产品来。当时听了这话我整整愣了10秒,真的是又可气又可笑,且不说struts是世界级的大牛开发的(你可以藐视权威),世界上有那么多的公司包括国内都已开始有公司采用struts做成熟的商业应用了,难道这么多人都是笨蛋???

这时我已经意识到再往下谈已没什么意义了,简单问了2个问题:
1、为什么离开原来的公司?
办公环境差,领导不懂管理。

2、能不能将你以前做过的项目演示一下?
限于保密的原则,不想拿出原来项目的源代码(这个原因可以接受),但他又加了一句:原先的代码没什么用处,我的记忆力好得很,我只用带走我的思想就可以了。

狂啊,真狂人也!
作者: zhms    时间: 2003-8-8 15:47
以下是引用无心快语在2003-8-8 15:41:00的发言:
今天还面试了一个牛人,华南地区的一个工科名校本科生,3年工作经验,大概有1年左右分析、设计的经验,在投递简历的时候就明确指出低于6500不干,6500这个价位不算高也不算低,不过在面试之前就敢说这话到也是颇有个性,于是早上面试的时候我还准备多花点时候和他好好聊聊。

简单的寒暄之后,我问他是否了解struts(是apach组织开发的一种较轻量级的j2ee技术架构,而很多大型网站就是架设在apach之上),他说没用struts作过具体项目,但看过一些文档,作过一些小例子,然后接着来了一句我认为struts做得很糟糕,我完全可以开发一套比他好得多的产品来。当时听了这话我整整愣了10秒,真的是又可气又可笑,且不说struts是世界级的大牛开发的(你可以藐视权威),世界上有那么多的公司包括国内都已开始有公司采用struts做成熟的商业应用了,难道这么多人都是笨蛋???

这时我已经意识到再往下谈已没什么意义了,简单问了2个问题:
1、为什么离开原来的公司?
办公环境差,领导不懂管理。

2、能不能将你以前做过的项目演示一下?
限于保密的原则,不想拿出原来项目的源代码(这个原因可以接受),但他又加了一句:原先的代码没什么用处,我的记忆力好得很,我只用带走我的思想就可以了。

狂啊,真狂人也!

不知道天高地厚。要6500不是什么问题。不了解struts也没什么问题,apache不用也可以,贬低原来的公司不是很好,办公环境差是客观条件,领导不懂管理不好说,演示一下不需要源代码,带走思想的说法没错。双方沟通有点问题。
作者: 无心快语    时间: 2003-8-8 16:11
演示系统确实不需要源代码,但源代码最能说明一个程序员的能力与经验(我根本就没打算用他的源代码,因为我相信他们公司在软件复用方面不会投入太大,40人左右的小公司而已),在面试的这么多人当中,我只要说希望能看看以前的作品,他们马上就同意(其实如果是我出去应聘,我肯定会带上笔记本,这样更有说服力,也更能证明我的诚意),只有这一位来一句我不需要!

晕倒

软件行业早已不再是个人英雄主义,一个优秀的团队的战斗力绝对超过一个优秀的人(而且说实话,中国的软件业无非做做应用,没什么核心技术可言,只要不是一个太笨的人,很多技术都是可以掌握的),如果仅仅因为自认为自己技术出众而缺乏团队精神,则既毁了自己又毁了自己的团队。

(此人6月份就辞职了,找了一个多月的工作还没找到,他临走的时候我很想给他一个忠告,但想想还是算了,他多半是听不进去的)
作者: zhms    时间: 2003-8-8 16:22
以下是引用无心快语在2003-8-8 16:11:00的发言:
演示系统确实不需要源代码,但源代码最能说明一个程序员的能力与经验(我根本就没打算用他的源代码,因为我相信他们公司在软件复用方面不会投入太大,40人左右的小公司而已),在面试的这么多人当中,我只要说希望能看看以前的作品,他们马上就同意(其实如果是我出去应聘,我肯定会带上笔记本,这样更有说服力,也更能证明我的诚意),只有这一位来一句我不需要!

晕倒

软件行业早已不再是个人英雄主义,一个优秀的团队的战斗力绝对超过一个优秀的人(而且说实话,中国的软件业无非做做应用,没什么核心技术可言,只要不是一个太笨的人,很多技术都是可以掌握的),如果仅仅因为自认为自己技术出众而缺乏团队精神,则既毁了自己又毁了自己的团队。

(此人6月份就辞职了,找了一个多月的工作还没找到,他临走的时候我很想给他一个忠告,但想想还是算了,他多半是听不进去的)


他带着源代码也不一定是他写的,而且一般源代码都是公司财产,而不是程序员个人财产。我想还是让他做一段,或者你拿出一段,让他评述评述哪里好,那里不好等,看他的理解更好。
作者: 无心快语    时间: 2003-8-8 16:30
代码是不是他自己写的,相信在这一点上他是骗不到我的,让这种人进来,哪怕只是一段很短的时间,恐怕也会给现有成员带来负面影响(其实在现有团队里面已经有了一个和他类似的人了,要是让他们在一起,那就只能是火星撞地球了,这种风险是我不能控制的),我后来和人事经理交换过意见,他同意我的看法,连复试机会都没必要给了.
作者: zhms    时间: 2003-8-8 16:34
以下是引用无心快语在2003-8-8 16:30:00的发言:
代码是不是他自己写的,相信在这一点上他是骗不到我的,让这种人进来,哪怕只是一段很短的时间,恐怕也会给现有成员带来负面影响(其实在现有团队里面已经有了一个和他类似的人了,要是让他们在一起,那就只能是火星撞地球了,这种风险是我不能控制的),我后来和人事经理交换过意见,他同意我的看法,连复试机会都没必要给了.

呵呵,这种人影响团队是毫无疑问的。对他不需要用其他测试方法了。

至于说代码是不是自己写的,如果他接手维护,而且又确实做过类似东西的话,还是很难分辨的。不过如果这样,不是他自己写的也不要紧。人力资源的东西还是很复杂,我也一直很头疼这方面的问题,因为一开始测试一个人的真实实力不容易,以个人的实际品行也不容易。毕竟象上面那位老兄那样,直接可以做出判断的情况是少数。
作者: txlgwmw    时间: 2003-9-23 12:18
以下是引用无心快语在2003-8-8 16:30:00的发言:
代码是不是他自己写的,相信在这一点上他是骗不到我的,让这种人进来,哪怕只是一段很短的时间,恐怕也会给现有成员带来负面影响(其实在现有团队里面已经有了一个和他类似的人了,要是让他们在一起,那就只能是火星撞地球了,这种风险是我不能控制的),我后来和人事经理交换过意见,他同意我的看法,连复试机会都没必要给了.

对于这种人你的决定是对的,因为他进入一个团队,只是会对团队带来负面影响,并且江山易改,本性难移,如果你被他张狂的表象所迷惑而冒险收他进入团队,后面会带来太多的苦恼,你应该就是提前控制风险。




欢迎光临 栖息谷-管理人的网上家园 (http://bbs.21manager.com.cn/) Powered by Discuz! X3.2