对于做项目的体会--思维要换调调
博客专区 > 威哥 的博客 > 博客详情
对于做项目的体会--思维要换调调
威哥 发表于4年前
对于做项目的体会--思维要换调调
  • 发表于 4年前
  • 阅读 171
  • 收藏 13
  • 点赞 0
  • 评论 0

腾讯云 技术升级10大核心产品年终让利>>>   

摘要: ‘技术能力不等同于工作能力,只能说技术能力是工作能力的一部分,在公司里会发现有些技术不错的程序员并不得志,有些技术不如他的反而得到晋升’ -这点我很认同。最近忙着做一个ERP系统,因为我算是半路接手,很多东西让我一头雾水,可能因为理解不畅,也可能因为项目本身存在很多问题,所以有自己的想法,刚开始是站在前辈的思路上面,等熟透了,就觉得有问题,我相信会有人同意我的说法,以下只做理论的调侃,多多扔蛋。

              我告诉自己,系统与做普通网站还是有区别的,因为系统的复杂度会随着运行远远超出前期的设象,有人说我想多了,我承认我想多了,可这是一个问题,项目实践有一句话:“有可能发生但是没有发生的问题叫风险,如果问题已经发生,那就是真的问题”。我认为对项目本身的控制在于对潜在各种风险的规避。如果处理不好,那就失败,真是这样。

             很多时候,我们都会做一件事情,就是系统调研,用户群体,功能分块,权限角色、产品优势,未来市场等等乱起八糟,可能这不是一个程序员关心的事情,但是这是一个思维方式转换的尝试

            我相信会有哥们对项目任务专注与本身,而没想过以后或者改动怎么办,或者换来的只是先前的代码彻底推翻,甚至重写功能,多加下班,再把功能代码书写一遍,换来的只是费力不讨好,要这样改要那样改,甚至 ‘改尼妹’的想法都有。

            我遇见过两个我最佩服的产品经理,不知是不是因为他们都是技术出身还是其他,他们给我的影响特别大,给我很多很好的建议和编程习惯的转变


           ================================================
            ########  别人的总结很精彩,与我共鸣,与你共勉,以下真的写的挺好,小手摘录
            #######   http://club.techtarget.com.cn/spaceindex.aspx 
           =========================================================

              前期思维能力,未做之前先想透彻,再征求大家意见,再对比


             某项目中的案例,在提测的过程中竟然发现主功能有严重的bug。这样的bug被测试发现确实非常惭愧,把自己骂了好几遍。可能每个人都会为自 己辩解,谁写代码没有问题。但是我在这里说一下我自己的体会:一般来讲写代码“一遍率(整个逻辑盲写,不做测试)”比较高的哥们往往自信心比较高, 因为他对自己的代码有信心。相反经常写出来代码有问题的程序员可能会心虚,即使你后面不管是自测还是靠测试把问题测出来,测出的bug越多,对于自己的打击 越大。特别是一些严重依赖于开发质量的项目,这样会承受比较大的心理压力。后果是什么?有一点小的改动就会畏首畏尾,不敢改。但是真正要做到细致,以我个 人的体会来看,确实很难。
        千万在写代码之前把整个的逻辑细细的想清楚,磨刀不误砍柴工,真理。因为前期没做好的后果就是后面一直在改代码。这样浪费了更多的时间。其实 这是一种思维的转变,很多人也包括我也认同一种观点:代码是写出来的,即使前期想的再清楚,也会有遗漏。但是在工作中这是一种不太好的实践。要慢慢的学会 在前期做更多的工作,后期少的改动。这是一种功力,真的很考验人。对于已经习惯这种思维的人可能不太难。但是如果习惯了在写代码中思考的程序员来说一定要 力求改变,在这里也是在警告我自己。
        这里简单的说一下为什么?道理很简单,如果你是在写代码的时候进行思考说 明是你喜欢发现问题解决问题的方式,这是一种被动的思维方式。这种思维方式可能做一个程序员不会犯太大的错误,至多自己多加一些班。但是如果是一个项目的 owner,这样极有可能犯重大错误,整个项目到后期发现方案不可行,这是要命的。千万不要觉得这仅仅是一种工作方式的问题,这是思维方式的问题。要慢慢 的锻炼自己在前期思维能力,就是主动思考,主动发现问题,这样才可能把项目风险掌握在自己的手中。项目实践有一句话:“有可能发生但是没有发生的问题叫风 险,如果问题已经发生,那就是真的问题”。
       改变思维方式真的很难,要打破重来很痛苦,绝不会在我这里写出来这么简单,所以为什么我觉得成功学看的热血沸腾,发现自己一去做完全是两回事。一个简单的 习惯都很难改变,何况是对于一种已经几十年的思维习惯。这里我举一种思维实践,仅供参考。脑子里想一个问题,反复的想,把它想的非常透彻,然后把这个问题 抛出来,看看大家都对这个问题的看法,再比对自己有哪些遗漏。这一方面是思维的过程,另一方面也算是经验积累的过程。因为很多问题想多了考虑的面自然就会 丰富起来。


        用数据证明观点,而不是简单描述观点


                事件的背景是我在一个小组周会上进行了一个项目经验的分享,准备上也有些仓促,大概两三个小时写了一个简单的PPT。讲完后就被主管批。他说: “在用语言描述项目的时候一定要用技术性的语言进行分析:你为什么做这个项目”。对于这句话我想很多人都不明白什么意思。这里的关键词是"技术性的语言" 这六个字。这里我举一个我在PPT中描述的语言大家就会明白问题出在哪里:"之前大部分依赖于数据库,对于数据库的压力相对较大。目前在DB前面用缓存挡了一层,对数据库的压力减少许多。"这 里注意一下我在上面一句话中标红的那几个词。这种词是严禁在项目总结中出现,什么叫相对较大,什么叫减少许多,一切都要以具体的数据说话。相对较大之前的 数据性能情况是多少,数据拿出来。你做了改动之后具体的数据是多少,拿出来。这前前后做一个对比,很容易就得出你做这件事的意义是什么。在这个项目中你具 体做了哪些改进,而不是简简的说加了一层缓存,这样谁也不明白,你的缓存加在哪里了,是怎么实现的没有说。我刚才的问题一说出来大家都明白,具体实施的时 候很多人都会犯这样的毛病。

        本质是要提高自己认识问题、分析问题、解决问题的思想高度


            提高软件知识和技术只是问题的表面,本质是要提高自己认识问题、分析问题、解决问题的思想高度。软件专业知识的很多方法和原理,可以很容易地延伸、应用到生活的其它方面。

工程师的内涵是:以工程师的眼光观察、分析事物和世界。一个合格的软件工程师,是真正理解了软件产品的本质及软件产品研发的思 想精髓的人(个人观点、欢迎探讨)。掌握软件开发语言、应用语言工具解决工作中的具体问题、完成目标任务是软件工程师的主要工作,但从软件工程师这个角度 来看,这只是外在的东西,并非重要的、本质的工作。学习、掌握软件产品开发理论知识、软件开发方法论,并在实践中理解、应用软件产品的分析、设计、实现思 想来解决具体的软件产品研发问题,才是真正的软件工程师的工作。站在成熟理论与可靠方法论的高度思考、分析、解决问题,并在具体实践中验证和修正这些思想 与方式,最终形成自己的理论体系和实用方法论。

参考

http://blog.sina.com.cn/s/blog_493a8455010003dp.html  

http://news.cnblogs.com/n/84788/

http://club.techtarget.com.cn/spaceindex.aspx

-------------

共有 人打赏支持
粉丝 19
博文 20
码字总数 14506
×
威哥
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: