半技工半文员的一些项目感慨

 

     前一段时间一直忙文档性工作，也就是和商务配合做技术方案、标书等。技术上没有具体写代码，主要还是看资料为主。充分利用家到公司坐地铁30分钟的时间，看一些hadoop、NoSQL方面的资料。

        在最近的工作中遇到的问题还是比较多的，让我有了很深的反思。在做文档方面，得到的教训比较的多。比如文档在严谨性上其实不亚于程序的严谨性。程序的不严谨可能导致程序不能运行，优化一下仍然能运行起来就行。可是为商务所做的一些文档的不够严谨非常有可能直接导致项目无法拿下，造成机会利益的丧失。一个纯做技术工到一个半工半文员的转变期还是比较的痛苦的，但也还是值得的。学到的知识不仅仅局限于技术，我想更多的是在知识面的拓广，思维方式的转变，视野的拓展。

       不知道大家有没有过这样的经历，在和商务讨论客户发过来的需求时候，商务坚持一点，而我们技术坚持一点，有可能处于僵持阶段。为什么会出现这样的局面呢？我想可能是从工作身份所决定的立场不同：商务坚持用户方便，也许有些“粗鲁”，而程序员要的是简单方便的去用代码实现功能。于是乎，争执从此开来。商务更多的是从用户角度来看，好的商务应该是最佳测试，他们不完全从技术角度来考虑问题，更加的贴近用户需求。商务从客户那边得到第一手的需求，而程序员得知的至少是第二手的了，理解的也有不完全。解决这个问题没有标准的答案，只能是让程序员或者项目经理站在商务的角度上来考虑一些问题。多沟通，相互理解，共同研究出用户的需求。

        我们公司也做一些比较大的企业级应用，很多领导有的时候不是为了提高工作效率来上某个项目，具体目的大家懂得。这种冲动性的需求通常都是拍脑袋或者是听别家说这个软件不错，我们也上这个项目，于是，需求来了。我最痛恨这种需求又特别喜欢这样的需求。

        为什么痛恨呢？
        这样的需求捉摸不定，今天可能是这个明天又是这个。比如，领导把脑袋拍出了个包包后说，我们搞个手机监控，监控外派工作的员工每天干什么，什么时间干的。这样的一句需求，你懂的。费事、费时、费脑细胞。要帮客户梳理他们的业务流程，整理出业务的特性，搞出这个业务流程的解决方案。然后写需求，然后领导出现新的包包了，然后再分析再整理。我是真实遇到这样的情况，去年10月份在深圳一家国内知名电视制造商那边搞“云服务”平台的时候就出现这个情况，弄的我直接要吐血，说的夸张点话挣的钱还不够看病。对于这样的情况，我们原先是直接上，上边说改什么我们就弄什么，完全被动。后来发现这样下去真的会无穷无尽，后来我们直接找他们这个项目的老大谈话，明确功能，确定需求，项目进行到这个地步的时候，我们也处于相对主动地位了。这个项目最大的一个缺憾或者漏洞，就是一开始的时候就没有明确需求最终产出的结果是什么。开始就是说需求而没有说产出的需求结果是什么，也是导致我们无穷无尽的玩下去的最大的原因之一。

        为什么爱呢？
        这个项目简直就是炼狱，回来后大家还以为我们去了索马里兼职海盗去了。从这些项目最大的收获就是总结了两句话：
        1、提炼客户需求时，明确目的，协商规定产出。
        2、站在行业专家的角度上来提供解决方案。
         如果你要提供解决方案，仅仅是根据客户的需求来做，我觉得只能是需求解决方案。而没有为客户解决他们还未想到的问题，没有深度挖掘出客户的需求。所谓，当局者迷，旁观者清。客户在自己行业里对自己清楚，但是还是没有从宏观和行业大势上来认识。我们最近的一个项目是为国内应该算是第一奢侈品连锁商城做移动支付。他们先前提出的移动支付只是客户不再需要拿纸质发票去收银台付款而只要拿出一个卡片，记录客户购买的东西和需要付款的金额而已。通过我们对奢侈品零售行业的调研，提出可以直接付款的移动支付方案。这个需求客户本来他们也不是非常的清楚，我们站在行业大势的角度上深度挖掘出的需求。

结尾：
         今天下午稍微闲了一点下来，胡思乱想了一些最近工作的收获。工作也五年了，感觉这样的收获的机会真的不多。不仅仅是完成项目，在人生的道路上也可以做些指引。有日子没有碰我的hadoop集群了，下班回家开机子，跑一跑了。

 

/*************微博*************************/

http://weibo.com/u/1177608391 南京思通