技术管理中常见的几个问题

简介:
    前几天跟朋友聊天时,朋友说他刚刚从一家知名软件公司面试出来,朋友去面试的是一家公司的技术管理岗位,所以在面试的时候被问及的问题也偏重于技术管理方 面的问题,在与朋友的聊天中将这几个问题归纳了一下,大致归为如下几个问题。

在日常中你是如何行使管理职能的
      这个问题以我的经验来及参考常见的一些开发方法,在实际中我都是早询问及晚反馈的方法。也就是早上上班后的半个小时内主动询问开发人员是否有不能及时解决 的问题,如果有组内组员讨论解决方法;下班的时候组员可以以邮件或者其它方式汇报自己的进度,并评估当前进度与预计进度相比是否有滞后。为防止有些内向的 组员不能用口头的方式反馈自己在开发中所遇到的问题,可以允许他在下班前的反馈报告中说出自己所遇到的重难题。作为技术管理人员,可能在工作中管理也要占 相当一部分时间和精力,抽出适当的时间和精力做做走动式管理,也就是主动走到开发人员身边询问他们目前手头的工作并询问是否有无法解决的难题,尽早发现问 题尽早解决问题,使项目尽量按预计日期交付。

如果发现因为种种原因导致实际工期远远超出预计工期时,你应该怎么做
      实际上除非客户主动限定交付日期,一般自己估算工期的时候都会在理论工期(根据经验估算出来的)的基础上再乘以一个系数作为交付日期,但是确实也有即使这 么做了仍远远超出工期的情况,比如在开始的时候对某些风险预计不足等,遇到这种情况个人觉得可以采取如下几种办法:
      一、增加人手,增加人手可以适当缩短项目周期。
      二、增加每日工作量,增加每日工作量尽管会被广大开发人员讨厌(我自己也相当讨厌,但是在没有办法的办法之下只好如此),但是也可缩短项目周期。
      三、和客户人员反馈和交涉,看能否博得对方理解而延长工期。
      四、如果客户人员不同意延长工期,那就再和客户人员商量,是否可以将项目的优先级列出来,在规定时间内将高优先级的功能开发出来,这样不影响客户使用大部 分功能,其余功能可以在客户使用过程中逐步添加。
      五、如果客户人员不同意延长工期并且也不同意在规定期限内部分交付,那就要和自己的上级汇报,毕竟处在自己所在级别范围内该做的、能做的都做了,那么就向 上级反馈,让公司级别的高层与对方公司级别的高层交涉,看是否有变通的办法。
      六、如果以上均行不通的话,那么只能退而求其次,尽量在满足用户使用和不违反合同约定的情况下简化或者缩减功能。
      项目实际工期比预计工期长这种情况并不少见,有时候由于种种原因比如开发队伍人员变动大或者对原有技术难点估计不足都有可能会导致这种问题。遇到这种情况 之后我们首先尝试从我们自己的层面看能否解决这个问题,如果确实不能解决就应该及时反馈到公司高层,从高层的角度寻求解决办法,而不是设法掩盖问题,等到 公司高层发现问题时连补救的办法都没有了,给公司造成经济和声誉上的损失。

在平常需求分析阶段你们以哪些方式与客户进行交流 和反馈
      最常见的一个办法就是合同约定,将客户需要的功能以白纸黑字的形式描述在纸上,这种情况下客户对将来交付的产品仅仅限于我们的描述,不过一旦客户签字之后 即使客户发现最终交付的产品与自己所期望的产品不一致也不能有什么办法,毕竟这些都在白纸黑字上写明了并且客户签字确认了的。这样做的坏处是这次可能会交 付成功(哑巴吃黄连),但是客户与公司之间不会再有下次合作机会了。
      在实际中我们还用过一种办法,那就是界面原型法。对于网站,那就是设计一套静态页面形成的网站,客户可以通过我方人员的演示看到各个页面之间如何跳转及每 个页面的功能;对于软件,也是设计出各个界面,客户可以通过演示看出各个界面之间如何交互及每个界面的功能。通过原型法,客户可以直观感受将来交付的产品 是什么样子的,避免仅通过语言交流而带来的理解误差。一般情况下我都是采用这种发发和客户交流的。
在客户不能描述自己期望的产品的情况下, 你应该如何和客户进行交流和反馈
      在有些情况下我们会遇到一些客户,他们很希望借组软件来改变目前落后的操作和管理方式,但是客户也无法用语言来描述自己所期望的产品的功能和样子,这种情 况下我们该怎么做呢?
      首先看市面上是否有类似于客户所需要的产品,如果有,可以借鉴这些产品并结合我们的理解做出界面原型来与客户进行进一步的交流(朋友说我这样有抄袭的嫌 疑,呵呵)。
      如果不使用上面的方式,那我们还可以采用引导的方式和客户交流。就像我们去生病去医院,我们通过自己身体的不舒服知道自己生病了,但是我们不知道自己得了 什么病,医生就会引导我们,比如会问头晕不晕、嗓子疼不疼、眼睛酸不酸、腿软不软等,通过这些询问医生就能确定我们得了什么病了(当然在医院里,我说的那 些是理想情况,若遇上一心扑在偷菜事业上的医生,人家只会引导你进鬼门关了,还有那种医生一进去就不管三七二十一就让你做一大堆化验的医生,曾经有位哥们 感冒了被化验出宫外孕来,白衣天使成了夺命魔鬼)。通过对客户的引导,可以进一步发掘需求,并且将客户的一些不太合理的要求化解,使我们能在尽量满足客户 要求的基础上开发出比较理想的产品。
      当然以上是朋友能回忆起的问题和我针对这些问题的理解,事实上针对软件的开发和管理有很多办法,我们不能实际也不可能纸上谈兵式对这些问题进行阐述。就像 在数据库设计时我们可以尽可能遵循一些范式,但是并不是满足了这些范式的系统就是一个好的系统,我们也不是一定要满足所有的范式,我们可以结合具体情况进 行分析,最终我们的产品是一个在各种因素影响之下的产品。


















本文转自周金桥51CTO博客,原文链接:http://blog.51cto.com/zhoufoxcn/284495  ,如需转载请自行联系原作






相关文章
|
敏捷开发 程序员 API
最怕程序员学会了隐身术!创业者最应该看的软件开发风险管理
  看到这个标题,我想应该不少人都有苦涩的回忆,我这几年的创业经验中,也碰过几次程序员人间蒸发导致技术开发难以接手的案例,也听说过类似的烂摊子也的确不少,我都有遇过,通常创业者本身不懂技术或是对技术一知半解的状况,就更容易被程序员唬得一愣一愣的。别以为这种事只有遇到外包才会发生,我也看过技术合伙人学会隐身术后就人间蒸发的惨痛案例。   因此,经过去年一年在程序员客栈工作,我都建议每个非技术背景的朋友,可以至少知道一些基础,这样当程序员发生问题的时候,就不致于发生不知道代码、资料库不知在何处的窘境。为了把风险降到最低,以下来谈谈创业者在与程序员合作时需要注意的几个重点。
825 0
如果我是一线技术主管……
技术主管和团队成员应该是什么关系?只能是普通的领导与被领导的关系吗?如果,你作为一个一线技术主管,你会怎么管理团队?
2363 0
|
开发者
技术团队管理者的软技能(上):关于团队文化和领导力
技术管理者或者技术领导者绝对不能够只有优秀的编程能力,其他的软技能也是对于架构师成长必不可少的。本文由中生代技术分享群申健为大家分享的关于技术团队管理者的那些软技能。精彩不容错过。
3767 0
团队建设三境界
一、乌合之众,强权政治(新手)   很多新手都会经历这样的过程,新组建的团队冲突不断,大家对当各种制度措施,报以反感。为保证执行力和项目成功,项目经理会选择强权压制,尤其是技术比较好的项目经理。
974 0
|
项目管理
艾伟也谈项目管理,技术管理中常见的几个问题
  前几天跟朋友聊天时,朋友说他刚刚从一家知名软件公司面试出来,朋友去面试的是一家公司的技术管理岗位,所以在面试的时候被问及的问题也偏重于技术管理方面的问题,在与朋友的聊天中将这几个问题归纳了一下,大致归为如下几个问题。
995 0
一个技术管理者的苦逼【技术管理漫谈】
希望给你3-5分钟的碎片化学习,可能是坐地铁、等公交,积少成多,水滴石穿,谢谢关注。 角色转变      从工程师转技术管理这两年,好比头马变成车夫,除了角色认知的转变,还要看方向,定计划。
1445 0
|
Java 应用服务中间件 项目管理
突破技术管理,IT人中年危机变契机
作为一个老技术人,今天不聊技术,就聊点技术人员职业发展的事情:对技术管理岗位的认知,比如技术总监。 先贴一张技术人员职业发展路线图,按照管理路线和技术路线区分。
1342 0
|
敏捷开发
技术管理
最近一直在思考技术转管理过程中需要注意到的一些事情,现在就总结下分享给大家看看 在转变过程中,需要注意到一下三个方面 业务管理 团队管理 技术管理 业务管理 业务管理,主要就是管理我们需要处理的业务需求。
1263 0