开发慢谈==技术价值体现

好几年没有写技术博客，从事开发不知不觉也过了20多年了。

我今年也四十好几了，虽然已管理项目为主，但还是坚持写核心代码，今天主要做一个如何看待技术与价值的关系及如何把有限的技术最大化转换为价值(如：薪水，职位，核心成员等)。

对一整个项目来说，通常情况下技术层面的东西占了其中约30%， 虽然技术的东西是一个项目的是否成功的必备条件，但不是充分条件，很多开发者参加项目后，总是以技术的角度去看事个项目创建及发展过程，他认为技术代表了项目的全部，但实质并不是这样，说白了可能就是一个跑龙套的角色，因为很多解决问题的方式或方案是可以通过非技术的手段来解决的。我们站在项目投资人的角度想一想，我想要是这个项目能按要求按进度完成就OK了，他并不太关心你用的是什么技术，需要保证他需要的功能能实现就可以了，至于是否用什么技术或非技术的手段来实现他并不太关心，他关心的是能不能在最短时间内做出想的的东西。我说一个例子：有一个需求：需要在系统上实现客服与用户之间的在线聊天功能。我想对于开发者而言，只要给出理想的开发时间，这个功能在技术上不是问题，由于整个项目的进度紧，没有太多的时间做这个功能，我的解决方案就是在系统上留下客服的QQ号，让用户用客服QQ，另一个方案去搞一个现有的(付费的或开源的)直接架接到系统中去，基本上不用写代码就可以实现。但是当时项目组的开发人员，还在烧脑的想用什么技术及架构及需要多少人能又快又好的完成这个功能，（也许我十年前也会这个干）这个例子就是一个开发者的价值的体现，我想很的开发人员在团队中发现过这样的人，而这样的人过了几年过可能变成了老板的红人。。。，我相大家应该会有体会。

我们再说另个逻辑推理的例子，如果一个人认识汉语字典中所有字并知道字的写法及意思，我想问：这个人就一定能写出好文章吗？显然是不一定，反之一个能写出好文章的人，就一定认识所有的字吗，不一定吧。

那么我们接刚才说的一个项目，技术只占了30%，那么一个项目的技术占了我们学的技术的比例是多少呢?，我告诉你，通常情况下一个项目（团队协作的情况下）中能用到一个成员的技术不到20%，或者说项目中80%的技术是我们常用的技术，而这些常用的技术只占了我们所了解的技术的20%.(而不常用的80%的技术，都是用在核心业务上， 但在项目代码量来说不到%5)。

通过上述的认知，我们发现一个开发团队的一个现象：开发团队的带头人(项目管理者)的技术能力都一般般（很少象我这样的人,技术行，管理也行，你别想在技术上忽悠我, 哈，，，）。

说到这里，前提需要业务知道非常了解，这个了解的层度不单是仅仅了解业务过程或流程这个简单，对业务认知的重要性在某个有效时期内能快速提升你的领导层面的价值体现。

我不可否认，这是一种耍小聪明的把戏，但对现实项目的开发环境下，迎和上级的价值认同及的保证相关部分的协作关系，还是有一定的作用，这个把戏只能用到边缘性的功能及在指定时间内无法完成的技术工作量(一口吃不了的东西，分多口吃)的临时处置方案也是可以的。另一面，我也不是说大家知道用这种非技术的手段后，技术的东西就可以理了，这么说吧，非技术的手段只能短期方案，而技术手段的长期方案，如：一个人习惯用筷子吃饭，如果某天在野外没有筷子的条件下，你不可能因为没有筷子而不吃饭吧，为了解决吃饭生存的问题，先用手抓来吃，等吃饱后，有时间有体力的时候 再解决找筷子的问题

 

从项目角度分析，你能保存了项目的进度，又具备了最底条件的功能要求，对上级有交待，对下级没那累，这就是双赢，你很好体现了个人价值。

上述仅是个人的经验之谈，仅供参考。