前几天跟朋友聊天时，朋友说他刚刚从一家知名软件公司面试出来，朋友去面试的是一家公司的技术管理岗位，所以在面试的时候被问及的问题也偏重于技术管理方面的问题，在与朋友的聊天中将这几个问题归纳了一下，大致归为如下几个问题。
在日常工作中你是如何行使管理职能的
这个问题以我的经验以及参考常见的一些开发方法，在实际中我都是早询问及晚反馈的方法。也就是早上上班后的半个小时内主动询问开发人员是否有不能及时解决的问题，如果有，组内组员讨论解决方法；下班的时候，组员可以以邮件或者其它方式汇报自己的进度，并评估当前进度与预计进度相比是否有滞后。为防止有些内向的组员不能用口头的方式反馈自己在开发中所遇到的问题，可以允许他在下班前的反馈报告中说出自己所遇到的重难题。作为技术管理人员，可能在工作中管理也要占相当一部分时间和精力，抽出适当的时间和精力做做走动式管理，也就是主动走到开发人员身边询问他们目前手头的工作并询问是否有无法解决的难题，尽早发现问题尽早解决问题，使项目尽量按预计日期交付。
如果发现因为种种原因导致实际工期远远超出预计工期时，你应该怎么做
实际上除非客户主动限定交付日期，一般自己估算工期的时候都会在理论工期（根据经验估算出来的）的基础上再乘以一个系数作为交付日期，但是确实也有即使这么做了仍远远超出工期的情况，比如在开始的时候对某些风险预计不足等，遇到这种情况个人觉得可以采取如下几种办法：
一、增加人手，增加人手可以适当缩短项目周期。
二、增加每日工作量，增加每日工作量尽管会被广大开发人员讨厌（我自己也相当讨厌，但是在没有办法的办法之下只好如此），但是也可缩短项目周期。
三、和客户人员反馈和交涉，看能否博得对方理解而延长工期。
四、如果客户人员不同意延长工期，那就再和客户人员商量，是否可以将项目的优先级列出来，在规定时间内将高优先级的功能开发出来，这样不影响客户使用大部分功能，其余功能可以在客户使用过程中逐步添加。
五、如果客户人员不同意延长工期并且也不同意在规定期限内部分交付，那就要和自己的上级汇报，毕竟处在自己所在级别范围内该做的、能做的都做了，那么就向上级反馈，让公司级别的高层与对方公司级别的高层交涉，看是否有变通的办法。
六、如果以上均行不通的话，那么只能退而求其次，尽量在满足用户使用和不违反合同约定的情况下简化或者缩减功能。
项目实际工期比预计工期长，这种情况并不少见，有时候由于种种原因，比如开发队伍人员变动大或者对原有技术难点估计不足都有可能会导致这种问题。遇到这种情况之后我们首先尝试从我们自己的层面看能否解决这个问题，如果确实不能解决就应该及时反馈到公司高层，从高层的角度寻求解决办法，而不是设法掩盖问题，等到公司高层发现问题时连补救的办法都没有了，给公司造成经济和声誉上的损失。
在平常需求分析阶段你们以哪些方式与客户进行交流和反馈
最常见的一个办法就是合同约定，将客户需要的功能以白纸黑字的形式描述在纸上，这种情况下客户对将来交付的产品仅仅限于我们的描述，不过一旦客户签字之后，即使客户发现最终交付的产品与自己所期望的产品不一致也不能有什么办法，毕竟这些都在白纸黑字上写明了并且客户签字确认了的。这样做的坏处是这次可能会交付成功（哑巴吃黄连），但是客户与公司之间不会再有下次合作机会了。
在实际中我们还用过一种办法，那就是界面原型法。对于网站，那就是设计一套静态页面形成的网站，客户可以通过我方人员的演示看到各个页面之间如何跳转及每个页面的功能；对于软件，也是设计出各个界面，客户可以通过演示看出各个界面之间如何交互及每个界面的功能。通过原型法，客户可以直观感受将来交付的产品是什么样子的，避免仅通过语言交流而带来的理解误差。一般情况下我都是采用这种发发和客户交流的。
在客户不能描述自己期望的产品的情况下，你应该如何和客户进行交流和反馈
在有些情况下我们会遇到一些客户，他们很希望借助软件来改变目前落后的操作和管理方式，但是客户也无法用语言来描述自己所期望的产品的功能和样子，这种情况下我们该怎么做呢？
首先看市面上是否有类似于客户所需要的产品，如果有，可以借鉴这些产品并结合我们的理解做出界面原型来与客户进行进一步的交流（朋友说我这样有抄袭的嫌疑，呵呵）。
如果不使用上面的方式，那我们还可以采用引导的方式和客户交流。就像我们去生病去医院，我们通过自己身体的不舒服知道自己生病了，但是我们不知道自己得了什么病，医生就会引导我们，比如会问头晕不晕、嗓子疼不疼、眼睛酸不酸、腿软不软等，通过这些询问医生就能确定我们得了什么病了（当然在医院里，我说的那些是理想情况，若遇上一心扑在偷菜事业上的医生，人家只会引导你进鬼门关了，还有那种医生一进去就不管三七二十一就让你做一大堆化验的医生，曾经有位哥们感冒了被化验出宫外孕来，白衣天使成了夺命魔鬼）。通过对客户的引导，可以进一步发掘需求，并且将客户的一些不太合理的要求化解，使我们能在尽量满足客户要求的基础上开发出比较理想的产品。
当然以上是朋友能回忆起的问题和我针对这些问题的理解，事实上针对软件的开发和管理有很多办法，我们不能实际也不可能纸上谈兵式对这些问题进行阐述。就像在数据库设计时我们可以尽可能遵循一些范式，但是并不是满足了这些范式的系统就是一个好的系统，我们也不是一定要满足所有的范式，我们可以结合具体情况进行分析，最终我们的产品是一个在各种因素影响之下的产品。
