所谓的程序员其价值只有写代码么
自从业以来有时会经常发现,在程序员的日常工作中.难点根本不是在于技术难题. 或者说技术难题并不是工作中最重要的一块.
最近我有幸了解的诸多大师的"工作法", 在反思自己在平时工作时的不足点至于, 也在暗暗震惊与国内开发团队在整体开发流程上与国外开发者的差距
那么难点从哪来?
1): 沟通.
说到沟通这是一个老生常谈的话题了,业务人员 或是产品经理与程序员之间的梗也由来已久,
面对此我能做的只有 放缓语气,抓住问题点, 一个一个来.
首先抓住他人的问题点,(如果有时间可以加以总结),
然后按照你的思路把解决方案说出来,直到业务人员同意或否定,否定之后就要讨论为什么,.
在讨论为什么的时候,可以换一种思路从当前问题是否有必要花费如此大的精力去解决,以及当前问题对客户的重要性来入手.
就一般而言的推荐的是将一个问题解决完之后在进行下一个,但是如果此问题要被搁置,那么请在搁置前 弄清楚
- 当前问题是否有必要花费当前精力投入进去
- 当前的问题解决之后,可以预见的收益有多少
- 当前的问题如果不解决是否在可承受范围之内
ps:在面对业务人员的时候,尽量不要以技术实现的难点来反驳他们的观点,
除非当前的技术难点足以上你的上级领导或是更上级的领导认同你的观点.
2): 技术思维和业务思维
其实在开发人员与业务交流的时候常常会有一种鸡同鸭讲 的感觉,
这也是因为 程序员满脑子全是实现的技术细节,以及对业务的陌生.和当前的开发思路并未转换过来,
我初始的时候也会经常带着开发的思维去与业务谈论需求,但是最后发现效果不大,除非业务人员是技术出身. 所以要么程序员具备业务思维, 要么业务人员具备技术思维,
正是因为这样的人少之又少,所以这也就是为什么经常要有项目经理,or 产品经理的缘故了, 他们的作用就是为了封装业务的复杂度将其做一层编译功能交于程序员,由程序员实现,
然而有些公司的产品经理or项目经理的级别过高,此时就有了各大项目组中的负责人俗称组长.
在有时就算有了项目经理和组长也不一定能完全屏蔽掉业务人员,业务攻击.
所以此时你只能与业务人员进行交涉.此时要么你具备业务思维,要么业务具备技术思维,
但是我还是倾向于自己具备业务思维,毕竟你不可能把选择权交给他人,
其实我个人对于与程序员是否要关注业务这一方面是持有赞成态度的.
因为作为一个程序员, 在工作中会遇上很多非开发者本职的工作,但是只要它数据软件开发流程中的一环,那么我就会乐于接受.
毕竟,君不见 业务,软件 开发生命周期等事务 一般都是你现在的上级解决掉的么
3) 非本职工作
每当一提起开发者的本职工作的时候, 你首先会想到什么?
如果作为一个前端开发者,无疑是 前端页面展示,与css样式等.
如果作为一个后台开发者 无疑是 后台业务逻辑实现,与编码完成
都有个共同点,那就是编码,顶多在加个单元测试, 因为我一开始也是如此想法.
但是工作之后却发现了整个软件维护的生命周期, 包括 新需求的提出与评估需求是否可以进入开发,以及当前系统是否能满足业务需求,
更重要的是 是否必须进入开发阶段,只要是开发, 无论多么顺畅的流程, 都必然是极重的
所以对于是否需要进入开发阶段,是需要尽量避免的,有时在需求中多问几个 “为什么?” 不会让别人觉得你很傻, 反而是 加分的表现
4): 约定留存
在工作中 对于一些不可追溯 工作历史 之间的互相扯皮也是 必不可少的.
其一: 是因为时间太长,过了那么就谁也记不清当时是如何约定的.
其二: 则是谁也不想担责
所以对于在与业务沟通中,约定好的事宜,最好留存下来.形成文档
其一: 是为了有迹可寻
其二: 是为了让后面的接受你工作的人迅速了解当前业务的一大利器,(你要知道这个人往往就可能是你自己)
