如何管理飞扬跋扈的技术人员

在互联网项目当中,相信每一个项目经理或者制作人,最头疼的就是技术部的管理。因为技术工作看起来是那么的棘手,一般人难以理解,而且技术人员大多数都似乎情商不高。管理人员既不能轻易了解技术工作的内涵,技术人员也觉得很难和管理人员沟通。特别是技术工作,难以在不同人之间交接,很多技术人员都声称无法继续别人做过的项目。这让管理者觉得技术人员特别喜欢耍大牌,而且他们要偷懒也非常容易。但正如军事中的定理,对付坦克最好的武器就是坦克,对付航母最好的武器也是航母,这条理论是通用的。要管理好技术人员,就一定要懂技术。这是任何一种其他号称完美的管理方法都无法替代的。开发是一切——何时写文档对于技术管理来说,很多公司会非常注重文档。虽然开发的结果是代码,但对于管理来说,代码往往难以阅读,也很少有人擅长接手别人的系统。为了让代码不至于被丢弃,公司管理人员就祭起文档这个法宝。我认为文档是很重要的,但也发现这些文档中很典型地存在几个问题:文档和代码不同步;文档的可读性差,需要的文档没写,不需要的文档写了一大堆;文档和代码脱节,文档很多,开发出来的成果很少。我们应该何时写什么文档,这是需要有严格定义,并且有检查过程的,而不是任由大家自然发展就可以完善的。代码的编写需要按不同类型,定义好在各个阶段中所需要完成的部分。设计类文档—— 这类文档往往在项目、模块启动的时候,大家都会想到要去写,作为讨论和最后决议的成果,显然是很自然的。然而在项目进入开发之后,碰到实际问题时,往往就不能完全按照设计的初衷去做了,所以通常设计文档就在这个时候和代码脱离了联系。但有一点是绝对可以做的,就是在重构的时候,按照现有状况,重新增加重构前的系统状况说明,然后再添加上重构后的设计。这样就把重构的设计和文档的更新结合到一起了。API(应用编程接口)文档——现代软件都希望能提高重用的程度,因此很多程序员都会自己构造自己的业务API,以便在之后的开发中使用。而这种业务API,也是很多分工合作的基础。这种代码的说明,会直接影响日常的开发,因此非常有必要保证和代码的高度一致性。使用文档—— 一般来说,一个软件的使用文档必须包含以下几个:《产品版本说明》、《产品安装和部署文档》、《产品使用教程以及例程》、《产品FAQ文档》。这里面的《产品版本说明》应该在每次发版的时候,作为发布流程的一个固有环节来设计。《产品使用教程以及例程》是我认为所有文档中,最值得花大力气去写好的。《产品安装和部署文档》内容越少越好,应该让安装部署尽量智能化、自动化。了解什么是软件架构了解软件架构的范畴,才能有针对性地去把握软件开发中的风险,从而管理好软件开发的过程。简单来说,软件架构就是应对需求所产生的“一系列决定”。软件会根据这些决定来开发。根据软件需要应对的需求,软件架构一般包含以下几个部分。逻辑架构 主要是为了明确“功能性需求”而做的设计,针对需求以及需求变化作为架构目标所做出的关于代码之间的划分、耦合、关联的决定。采用合理的逻辑架构,将会大大降低需求变更对开发的延迟作用。逻辑架构最直接指导代码中互相耦合的情况,仔细设计好耦合的规则,会让后续开发事半功倍。运行时架构 运行时架构是为了满足运行期的质量需求,所做出的关于对象行文、进程结构、通信协议、数据结构等方面的决定。运行架构一旦确定,等于大部分的“实现”代码都确定了,设计有足够扩展性和可用性的运行架构,可以为后续工作节省时间,也降低了系统在运行期对开发工作的干扰。开发架构 为了满足开发时的需求所做的决定,主要是软件根据分工开发、测试验证流程等需求划分的软件层次和区域以及各种接口设计,也包含使用的软件包、组件库、开发工具,以及编译构建的方法。一个好的开发架构,可以让沟通成本降低,开发速度提高。部署架构 现代软件系统,基本上都包括了客户端和服务端程序,如何快速、高效、稳定地部署和发布这些程序,如网络机房的分布、服务器硬件的搭配、监控和维护工具软件的安装、开发测试网络和运营网络的设置。可以获得安全性的配置,良好的部署能力,能推动软件进行更频繁、更全面的测试,从而提高软件质量和开发效率。数据架构 数据是软件项目的核心财富,关于数据的结构,数据的存放、备份、传输会直接影响到运行性能、业务功能、部署、安全等需求。在面向对象的开发模式下,数据到对象的ORM架构也是很重要的设计。一个完整的数据架构包括了数据流图、数据字典、ORM结构(如果需要的话)、数据索引和备份机制等几个方面。何时以及如何评审相信大部分公司都有评审这个环节,评审可以包括方案评审、代码评审、项目专项议题的评审,比如对存留Bug的处理评审等。而这些评审,常常会变成一个挑毛病的会议。要解决评审给产品带来的负面影响,同时发挥这个活动的优点,我们需要关注以下几个方面。评审由谁发起 相对比较好的是,由负责此项目的“领导”来召集人员评审,并且一定要有负责开发的人员参加评审。参与评审的受邀请人员可能会与方案提交者就一些问题有分歧,但提交者有最终决定权。要把权力给有能力承担它的人。这样做可以让“防止风险”的一部分人和“注重效率”的开发人员形成平等的
意见交换。什么时候做评审 应该在每个迭代、每个较大的版本开工前,或者仅仅是某个认为比较重要的决定做出前,都来一次简短的评审。如果开始时只是做一个DEMO,那么需要评审的东西也比较少,而随着不断的开发,评审也能遍历所有的开发。做评审的方法 真正对项目有帮助的,是了解项目的需求,分析面临的难点,思考方案为何这样做,提出自己的解决方案,给项目开发者以建议和启发。多说“我建议这样解决这个问题”,而不要仅仅去说“这样做可能有问题,应该添补这样的功能”。以建设性的心态和思路去做评审,而不是以找问题的思路去做,这就是两种做法的最大区别。分层开发,尽快运行为了降低软件耦合给开发带来的负面影响,正确的做法是要高度重视软件开发方法,从代码风格、软件架构、设计模式、开发模式方面来提高水平。其中一个最简单有效的做法,就是分层。在经典的架构模式中,分层模式几乎是所有模式的基本模式:把代码按照你所需的范围划分层次,然后规定层次之间的耦合接口,层次之间只可单向依赖,而且尽量减少跨层耦合。划分层次的范围,由你的开发团队水平和项目的复杂程度决定。非功能需求决定成败世界上类似的项目非常多,但成功的占少数,失败的占多数,这种现象的背后有一个重要的原因,就是非功能需求。非功能需求具体包括:软件开发效率的相关需求,比如代码结构、代码风格、内容开发工具、自动构建部署工具;软件的质量稳定性的需求,如测试方面的需求,产品结构对于缺陷的防范,代码质量;软件的运行承载力需求,包括可用性、容灾性、可维护性、承载力、运行性能和成本需求;软件的信息搜集方面的需求,如故障上报、数据统计和挖掘。如何才能做好这些非功能需求呢?首先是在项目成本规划时,分配足够多的资源,比如人力和时间,去做好这个事情;其次是要尽量合理地规划和设计这些非功能需求,既不能贪多求全,也不能无所作为。

时间: 2024-10-27 01:18:49

如何管理飞扬跋扈的技术人员的相关文章

谈谈技术人员转管理岗的问题

现代通信网络中,交换机发挥的作用越来越大:海量的数据到达这个信息节点,然后按照既定的规则,快速有效地传送到目的地.网络里的交换机就象一个组织里的管理者,把任务拆解分配给不同的人或者单元,并确保任务的完成. 交换机的工作原理并不复杂,硬件基础就是普通的服务器,只不过上层加载的是专用软件,能够快速高效地完成数据和信息交换的任务.如果数据量不大,IT系统中不必引入专用的交换机,通过自行开发的软件也能实现信息交互的目标.就象在一个小规模的组织里,或者完成一项不太复杂的任务,就不一定需要专用的管理人员,技

联通技术人员单价1万倒卖信息 内部管理机制受疑

部分掌握公民个人信息的大公司,正逐渐成为信息泄露的主要源头.1月14日,重庆市公安局江北分局打掉了一个倒卖公民信息的团伙,该团伙联合重庆联通公司一名技术人员,利用联通机房的系统漏洞,提取系统中的短信内容,以每单高达1万元的价格出售. 重庆联通公司一名员工向< 每日经济新闻>记者透露,对于客户的个人信息,联通公司有一套保护机制,但其中也有缺陷.比如联通公司针对内部员工查询客户个人信息设置了相关权限,但在执行过程中,对于权限的应用则比较"灵活",存在越级查询的可能性. 有 业内

技术人员谈管理之项目风险规避

一 .风险管理的重要性 项目的风险管理既是一门艺术又是一门科学.它通过识别.分析和应对整个项目生命周期中的风险来最大程度地满足项目目标.风险管理对项目选择.项目范围的确定.制定现实可行的进度和成本估计都有积极的作用.它既能帮助项目干系人更好地理解项目的性质,让团队成员参与便是优势和劣势,并且有助于把他们的项目管理知识结合到一起. 伴随着软件开发技术的不断更新.软件数量的增多.软件复杂程度不断加大.客户对产品的要求也在不断的提高,随之而来的是软件开发项目给软件开发企业和需求企业带来的巨大风险.软件

网络生活管理软件——“e秘书”寻求北京或成都的具有网络通信软件开发能力的兼职创业技术人员合作!

问题描述 "e秘书"是由北京市龙文蛛网科技持有,由著名整合营销策划大师.著名经理人龙辉策划并主持,由管理博士.信息与通信博士后汪文元主持技术工作的一款e生活管理软件,它是基于类似pidgin功能的多功能聊天平台上的一个功能强大的e生活管理软件,软件管理功能几乎涵盖了网民的全部网络生活项目管理,并有细腻而周密的项目研究.项目实现.项目推广方案(符合条件并有意合作者可以来函联系与索取),公司现计划扩充技术队伍,欲寻找具有网络通信软件开发能力,最好有实际项目经验(如几个知名IM软件的开发经验

联通技术人员单价1万倒卖信息内部管理机制受疑

配图与文章内容无关 图片来源:资料图部分掌握公民个人信息的大公司,正逐渐成为信息泄露的主要源头.1月14日,重庆市公安局江北分局打掉了一个倒卖公民信息的团伙,该团伙联合重庆联通公司一名技术人员,利用联通机房的系统漏洞,提取系统中的短信内容,以每单高达1万元的价格出售.重庆联通公司一名员工向记者透露,对于客户的个人信息,联通公司有一套保护机制,但其中也有缺陷.比如联通公司针对内部员工查询客户个人信息设置了相关权限,但在执行过程中,对于权限的应用则比较"灵活",存在越级查询的可能性.有业内

IT软件技术人员的职位路线(从程序员到技术总监) - 部门管理经验谈

以前写过一个文(IT从业者的职业道路(从程序员到部门经理) - 项目管理系列文章),主要介绍笔者的职业发展之路,不过该文需要后续了,因为笔者现在从事的是"产品经理"一职.从笔者的导航文([置顶]博文快速导航)里,定义了IT软件领域的职业路线,基本涵盖了IT软件领域的发展思路.后续笔者会对职业路的职业做描述,但是,本文主要从IT软件工程师的角度去描述IT软件技术人员的发展历程道路.   一.软件工程师: 软件工程师是最基本的IT软件职位,但是他做的是最重要的底层的代码编写.所以说,软件工

如何才能做好向技术人员简洁准确的描述需求

网页制作Webjx文章简介:产品人员怎么向技术人员描述需求. 近日参加一个子产品的新版本需求讨论,过程中负责该子产品的产品人员(某聪明帅小伙,哈哈)在前期需求讨论时不管是综合听取他人意见还是表达自已观点时,都很顺利,但总是在最后进行需求要点的总结陈词时犯卡壳,抓不着重点,说不清楚,思路打结,自已说到一到都挠头,更不要说听者犯晕了. 数次下来不得法,之后我自已总结了下,如何才能做好向技术人员简洁准确的描述需求: 在这儿(in Here) 做了事(Do something) 发生了什么,得到了什么(

老板,请尊重您的技术人员

 尊敬的老板:        您好,此刻我在北京拥挤的公交车上给您写这封信,很荣幸能有这个机会.虽然我现在已经离开您的公司有将近半年的时间了,但是在贵公司工作的这段时间会是我以后长久的回忆.从大四开始进入贵公司工作,三个月的试用期不到一千块钱的薪水,开始了我踏上社会的第一份工作.        在公司的一年多时间里我看到了公司的快速成长,人数从30多人发展到了60多人,公司业绩也是一路攀升,但在业绩的背后也有许多让我们这些为公司发展做出了贡献的技术人员颇为寒心的事情.首先就是公司给员工的待遇问题

技术人员如何跟传统行业打交道?

前几天,读了一本书叫<高难度谈话>,这本书主要讲的就是「沟通」问题,而本书的主题就是「人」--我们这些并不完美却真实的人.人是一种复杂的个体,我们每个人都有自己的观点.思想和感情.技术人员如此,传统行业的「老板」也是如此! 而在很多技术人员眼中,跟他们打交道要比敲代码要复杂「1000」倍.本期移动开发精英俱乐部讨论的主题就是「技术人员如何跟传统行业打交道?」,让我们来听一些技术同学的吐槽,还有哪些解决办法吧!本文系 OneAPM 市场部整理. 程序员眼中的传统行业 晓书生:我觉得跟传统行业打交