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

TOMSSKY

MD，20:30分客户直接打电话给我，告知主机无法访问！运维、技术忙活到22:10分才恢复，郁闷+鸭梨！

TOMSSKY

好吧，兑现承诺，开始漫谈IT人的修养。

入门级---快乐

其实啊，XDJM们，选择做IT本质是很辛苦的，谁说搞IT赚钱容易了，说这话的一定不是IT。

在学校学了N年（N=3,4,7,10）专业，能混毕业的，就不容易，当然有偷懒专业课挂掉的，然后靠打点老师过关的，说学的不苦，我只能无语。还有半道出家搞IT，弄个两三年自称成才的，我也见过一批，一聊原来多是用Foxpro写代码的，后来多半去弄Java去了。

IT的基础很重要，基本上本本毕业的，均是在打基础，俗话说基础不牢地动山摇啊。为何？网络基础、系统架构、操作系统、数据结构、数据库原理、编译原理这些是本本们必过的专业课，都是基础。那在实际应用开发中用得到吗？太用得到了，就好比小学学的汉语拼音、汉字、造句，那是以后说话、写文章的基础。有很多程序员在编程时对数据包的概念很浆糊，就是没学好数据结构，很多数据的组织、计算、操作的方法，在里面都有，融会贯通之后，很多问题很简单。

我对半道出家的IT报敬畏之心，他们中基础扎实的，当然是敬仰，对其余而不求甚解的那是相当畏惧，因为这些其余的都有蛮勇无畏的精神，是崩溃与无序之源。

既然辛苦，快乐从何而来？结果！过程是辛苦的，而在过程中并不感觉辛苦，孜孜以求，感受代码顺畅跑起来的快乐！作为技术人员，你的工作成果在客户那里使用，给客户带来价值，不是非常快乐的事情吗？

如果你没有这种快乐的感觉，那我认为你不太适合继续IT下去，去干别的事情吧。

laobai1982

按理说LZ说的技术大牛 在项目中的角色定位应该是架构、核心设计人员，架构与设计与客户需求一致就差不多了，实现就不应该多参与了；LZ说的这样的技术牛人应该还是理论与实践应用未同步，过于理想化，在客户、老板、开发面前几面不是人。

tangchaoql

技术白痴见多了。。。

UpalInternation

同意~

原帖由 innovate511 于 2011-3-11 21:17 发表
我是先设计架构，然后自己和其他人一起开发，满足客户需求的同时，还推销我们的想法，这样才是IT应用技术未来的主流嘛

innovate511

原帖由 laobai1982 于 2011-3-14 09:07 发表
按理说LZ说的技术大牛 在项目中的角色定位应该是架构、核心设计人员，架构与设计与客户需求一致就差不多了，实现就不应该多参与了；LZ说的这样的技术牛人应该还是理论与实践应用未同步，过于理想化，在客户、老板、开发面前几面不是人。

现在只有顶级大公司，或者预算充裕的团队，才会一个架构师只做架构设计，不参与具体开发，大多数情况要开发的，而且要开发得比较快才行，至少部分开发得比较快，开发思路比别人清晰得多，这就是国情，否则这样的架构师难以吃得开的。  

innovate511

原帖由 UpalInternational 于 2011-3-14 14:09 发表
同意~

有的时候，你提出一个想法，虽然不见得用户完全按照这个来提需求，但至少是一个方向，他们只是在上面做点花头，而你不但得到在业务方面的足够尊重，而且需求会相对稳定和全面，并且使你的技术具体相当的扩展性。但如果你没有想法，完全按照需求做，不好意思，你只是一个IT工具，给别人干活的。那时候业务上的事，你插不上手，需求合理不合理，只有做出来才知道，搞砸了，人家说你IT的事情，当然你也可以反驳是需求没提好，然后人家说你IT找借口。

IT无数个杯具就这么反复重演

TOMSSKY

同意 innovate511 大仙的两点高见：
1、国情所致，设计人员又是核心开发人员。
2、设计及实现要有前瞻及扩展性。

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

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

laobai1982

也是啊 国内的总是这样 资源总是很缺 预算总是不足 一个所谓的PM从需求调研、分析、设计、核心开发、测试、实施全上，再带一个开发 弄上3,4个月 赚个4,50万 齐活。

TOMSSKY

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

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