剑客
关注科技互联网

十月份杂谈

Long time no write.

整整一个多月没有更新blog,原因有很多,但主要还是忙~

现在工作岗位偏重需求分析,我需要花大量的精力在与需求方一起讨论工作流程和系统的落地方案上。纯粹的技术性质的问题一般都会交给

其余同事负责跟进。所以一时不知道应该写什么在博客,毕竟之前博客都是偏向具体技术问题的主题。

需求分析

既然提到了需求分析,那也来说说这方面的体会。其实,与客户沟通,以前也不是没做过,只是现在更偏重于这个方向,最明显的体会在于:

你一定要做好充分的准备,因为你是业务人员和技术人员之间的桥梁。你必须既能够消化业务需求,又可以和技术人员共同确定实施方案,最好

还可以独自将业务背后隐藏的一些要素给挖掘出来,这样程序员在理解你的方案时才能够充分的明白上下文环境。否则,你可能会处于一种两面

夹击的境地之中:一面是业务人员给你提出各种莫能两可的需求,还不停的责怪你为何无法理解;一方面则是程序员对你提出的实施方案产生质疑,

始终无法投入编码。

其实要规避这种境界也不难,嗯~~至少,说起来不难:

  1. 必须和双方都建立一个良好的人际关系:对于业务人员,你要让对方当你是朋友,这样会更有利于沟通;而对于程序员,则简单多了,你要让他
    信服你,只需要在关键时刻拿出自己的技术实力即可,例如:讨论方案时对某领域透彻的分析,或辩论时能在技术层面提出强有力的质疑并顺带拿出
    更好的方案。毕竟嘛,团队协作,以人为本,所以人际关系永远是最重要的。
  2. 最好可以直接和真实用户接触,如果和你提出需求的永远是间接用户,那你很难拿到需求真正的痛点,从而存在纸上谈兵的风险。
  3. 任何时刻都应有轻重主次划分,此时团队整体的事务永远大于个人。例如,我也会实际负责一个模块的开发,但我不能总是试图先把自己负责的
    模块弄好再管别人,这就大错特错了。

总之,要明白的是,公司不会因为我自己负责的模块做的多完美而表扬我,因为我的本职工作是确保项目整体交付。

云服务

现在做一个web项目,早已不和以往一样了。大量成熟高效的基础设施和公共服务已经摆在你眼前,它们既廉价又强大,不仅省去了你自己运维的成本,

而且还提供了非常高的可用性和安全性。可以说,现在的程序员,真是TM的幸福,更幸福的是:我就是现在的程序员!

由于项目的原因,客户更信赖Amazon,但就我之前使用阿里云的经验告诉我,国内云服务也非常的棒!不论如何,如果你在拿到需求后第一时刻如果不是

对照云服务来设计你的方案,那你真的是落伍了。

凭我的个人经验告诉我:

  1. 绝对不要自己来维护数据库,因为你的能力真的解决不了产品上线后的数据安全和稳定问题,放手使用RDS吧;
  2. 绝对不要搞vps,因为它太麻烦了,你可以选择云实例(阿里的ECS或AWS的EC2),至少它提供了更好的监控措施和便捷的状态管理。不过,更佳的策略是使用应用容器(AWS的Elastic Beanstalk);
  3. 绝对不要自己来管理文件,还是交给文件云吧,阿里的OSS,AWS的s3,国内的七牛又拍等。

其它诸如消息队列啊,数据分析等,更是应该首选云服务,因为成熟嘛~不过需要解决的我认为最重要的问题是:说服老板!!!

写代码

其实,我的岗位工作内容中是没有被要求必须写代码的。相反,是我一直在争取写代码。一开始是搭建前端团队要用的框架,再后来是做一些相对独立的中间件服务。我认为,永远不能远离代码,前面提到的技术素养全靠写代码来培养。

如果你被团队当成外行来看,那你在团队里基本上任何工作都难以开展,毕竟程序员的世界里,真的容不下产品经理!!!

总结和分享

这也是这篇文章存在的理由~~

写在最后

《行尸走肉》第七季,一定要看!

《生活大爆炸》第十季,不能错过!

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址