技术型人才与白痴，你喜欢那类？

TOMSSKY

呵呵， laobai1982  兄，一个小team（3-4人），3-4个月，赚4-50W，不错了！

就需求、设计、实现的问题，举个例子：
客户需求：
          提供多个部门之间短消息通信功能，要求短消息支持点对点（一个部门发，一个部门收）、点对多点（一个部门发，多个部门收）模式，客户提供了短信息内容、对应的接收部门。
设计方案：
          我们的技术牛X是这么干的：
          客户没有说明信息分类的方式，为了明确短信息的发送接收关系，首先设计一个“短信息定义功能”---客户先将需要发的短信息内容定义好接收的部门；其次设计一个“短信息发送功能”---客户先选择一个已经定义好的短信息，然后修改、编辑之后发送。
方案确认：
          牛X们将方案提交客户确认，客户问：我提供的这些信息都能准确发送吗？得到肯定的答复后，客户说：OK了。
实现：
          牛X们很高兴，按客户“认可”的方案实现了。
使用：
          客户使用了，第一个月没有问题反映。
          第二个月，客户生气了：为什么新的短语信息不能发？牛X们答复：不好意思，您要先在“管理系统”中定义一下。客户怒了：什么？这么麻烦？IT部门的系统管理员才有增加的权限！我靠！每次都要找他们！不行，你们得改！

innovate511

原帖由 TOMSSKY 于 2011-3-14 16:30 发表
同意 innovate511 大仙的两点高见：
1、国情所致，设计人员又是核心开发人员。
2、设计及实现要有前瞻及扩展性。

要做到第2点，不是一般的难。问题往往出在设计人员，我见过的设计人员，口头禅基本都是：客户有这个需求吗？这么实现客户认可吗？

所以，作为设计人员，甚至开发人员，对业务需求的理解，往往决定了产品的成败。

我们的设计人员所以还需要成长为顾问性设计人员，否则被用户零散的需求拖着走，无论对项目还是对个人的职业发展，都有很大弊端。

需求只是一个概念，他可以是一个想法，也可以是一个业务目标，还可以是具体的需求，就是拿着这个需求，你就可以开发那种。

innovate511

TOMSSKY 举的例子是典型的未从客户角度出发的例子。

比如我们BI方向，绝大多数BI设计者都是按照大框架设计物理模型，就号称架构了。然后开发客户需求，一般都是客户需要什么报表，就开发什么报表。其实这样的严重性更大，因为开发报表可能客户没想清楚，也可能客户没说清楚，还可能哪天客户换领导了，思路重新来。于是就出现了大批BI人忙着重复开发报表，在外界看来，BI就是开发报表的嘛。

其实从BI的角度看，即便是报表，我们也要对报表理解清楚，需求的来龙去脉，报表要解决什么业务问题，客户想用这个报表做什么？只要多问几个为什么，效果就显然不同了，同样的报表，BI也就上升了层次。

123crm

要找到一个平衡点，太过分追求技术肯定不行，中国的软件都是客户驱动的。

过分追求客户也不行，软件的BUG不断，一点小需求都要修改程序，甚至核心代码，而不是通过配置或者外围调试一下就行。

做事情认真是一切的前提，没有这个，技术在牛逼都是空谈。

innovate511

原帖由 123crm 于 2011-3-15 13:41 发表
要找到一个平衡点，太过分追求技术肯定不行，中国的软件都是客户驱动的。

过分追求客户也不行，软件的BUG不断，一点小需求都要修改程序，甚至核心代码，而不是通过配置或者外围调试一下就行。

做事情认真是一切的前提，没有这个，技术在牛逼都是空谈。

个人以为，技术应分为物理技术和逻辑技术之分。物理技术主要是纯技术，包括代码、系统、数据库管理等，而逻辑技术，就是一个实现框架，偏应用层面，需要用合适的方法来处理对应的需求。

123crm

原帖由 innovate511 于 2011-3-15 14:14 发表

个人以为，技术应分为物理技术和逻辑技术之分。物理技术主要是纯技术，包括代码、系统、数据库管理等，而逻辑技术，就是一个实现框架，偏应用层面，需要用合适的方法来处理对应的需求。

没有这么完美的东西的。在一个公司的大环境下，你不可能只做你说的物理技术。。首先出现的情况是纯物理技术的人是待遇上不去的。至少不那么受欢迎，必须要懂业务。。
做架构也好，做规划也好，必须要懂业务，而业务+技术，就是你的逻辑技术。

技术还是为business服务的。。过分偏重那个方面都不行，过分偏重技术，则产品不适应客户，过分偏重业务，则产品质量不行。。

当然其实这些都是浮云，在中国，重点还是关系。呵呵

innovate511

原帖由 123crm 于 2011-3-15 15:12 发表


没有这么完美的东西的。在一个公司的大环境下，你不可能只做你说的物理技术。。首先出现的情况是纯物理技术的人是待遇上不去的。至少不那么受欢迎，必须要懂业务。。
做架构也好，做规划也好，必须要懂业务，而业务+技术，就是你的逻辑技术。

技术还是为business服务的。。过分偏重那个方面都不行，过分偏重技术，则产品不适应客户，过分偏重业务，则产品质量不行。。

当然其实这些都是浮云，在中国，重点还是关系。呵呵

这样细分，并不是每个人就会一样，这怎么可能呢？

而是说每个人的擅长的地方，可能不同，如果一个团队，普遍擅长物理，逻辑、业务不擅长，那么注定处处被动。而如果一个团队都擅长业务和逻辑框架，而物理技术不行，那很可能出现稳定性、效率低下的毛病，导致失败。

我觉得关系论在某种情况是误导人的，再好的关系，碰到利益问题，都得破碎。但如果你能做出显著地成果，你到哪里都拿得出手，吃得开，成果是一个人工作成绩的最好证明，其次才是工作经验总结、理论形成等。

TOMSSKY

在国情之下做事，关系确实重要。但关系也是以技术为基础的，没有基础，再好的关系也维系不久的。
物理技术、逻辑技术。我看重逻辑技术，在技术实现的大前提下，没有哪家公司具掌握别人没有的核心物理技术，关键还是在利用成熟的物理技术，逻辑上快熟实现客户的业务需求，先人一步占领一定的市场份额。

TOMSSKY

团队核心价值，还是在逻辑技术是否成熟。
一款产品客户认为是否有价值，在于客户认为是否解决了他关心的业务需求，是否能嵌入他们的流程之中，是否具有前瞻性。
客户不会因为你的物理技术先进，就决定购买你的产品，相反，越先进的物理技术，客户选择时越慎重，因为客户永远不想当实验品。

TOMSSKY

呵呵，不好意思，我上述评论太泛了，检讨一下。
我是想借身边的例子，具体讨论技术实现的一些问题。
就上述“短信息发送”的例子，探讨一下，希望引出大仙们的卓见。

就“短信息发送”类似例子，现实中，我遇到过2类技术牛X的实现：
1、僵死型：（该类型是我最痛恨的，即是我称之为技术白痴实现）
      将客户提供的短信息，按客户描述的发送、接收关系，以程序硬编码的方法实现。
      可想而知，此方法做出的东东，毫无扩展性，短信息内容稍有变化，就要修改代码。
2、自我型：（即为 innovate511 兄所言“未从客户角度出发”的实现）
      技术们貌似提供了灵活性，当有新的短信息时，可以使用定义的功能。
      但是，最终用户没有定义功能的权限，（一般，客户有IT部门，他们负责系统的维护，包括用户权限的管理、数据维护等工作）。
      所以，这个貌似灵活的实现，在客户使用中，失去了灵活性。因为最终用户、系统管理员分属两个不同的部门，部门间的繁琐沟通与文件审批流程，足以让最终用户头痛。
      牛X们想当然的认为，提供了定义功能，客户按要求去做就OK了，全然不知实际的使用环境。