精华内容
下载资源
问答
  • 2019-04-03 15:19:22

    一、运维需求背景

    现在阿里云线上服务器由开发同事管理,主要负责应用的发布/升级;同时对系统进行维护/服务器监控、资源回收等运维工作; 目前已实施对阿里云线上服务器软硬件资源的监控,实现短信/钉钉/邮件等告警举措; 由于java后台开发人力资源紧张,多项目并行开发,同时,需要回到本职开发及日常管理工作,加上运维的工作量出现倾斜, 鉴于此,我们需要招聘一名运维人员来管理维护系统,保障现有<产品>的线上服务的健康运行环境。

    二、不同级别运维工程师的能力体现

    1、初中级运维

    从申请域名开始,购买/租用服务器,上架, 调整网络设备的设置,部署操作系统和运行环境, 部署代码, 软硬件资源监控等

    2、中高级运维

    资源评估、控制服务器成本,完成申请资源; 软件硬件资源监控、应用服务评估运行状态; 对网络流量波动、程序bug等问题的出现制定预案; 服务管理,包括资源整合、扩容、流量调度等; 有一定编码能力,需要结合业务开发运维平台,实现自动化部署方案。

    3、高级运维

    懂开发技术架构为前提:

    a、项目立项之初,评估产品结构设计的合理性,

            熟悉产品业务,便于做到应用业务级别的监控;

    b、产品发布过程中,实现内测限制<ip白名单>及对外开放服务,

            同时需要保障不中断对外提供服务的能力;

    c、产品上线后,对于运维监控的级别又有了新的挑战:

            i>、软硬件资源监控,可以不依赖阿里云生态;

            ii>、做到应用服务监控,往下便到了日志级别监控;

            iii>、业务级别监控,需要与运营/开发协作了解业务;甚至有直接解决bug的能力。

    d、收集工作中的问题和数据进行分析,制定相关改进计划,对以下能力评估体现:

    e、故障处理能力:服务中止、服务器奔溃等问题制定预案;

    f、服务容量管理:需要评估服务的容量,规划好服务资源;

    g、服务性能优化:包括网络、系统、应用等方向,提高服务的性能和响应速度,提高用户体验;

    h、服务集群管理、成本管理等等服务质量、效率、成本、安全等方面的工作;

    三、目前面临的问题

    1、无法及时响应反馈线上问题,快速定位bug或服务器问题,且无法及时解决;

    - 定位系统的问题,需要一位深入业务的高级开发便可以直接修正bug;

            - - 但是对于其职能定位?定然会照成资源浪费;

    - 对突然出现的问题做到快速响应和处理;

    -保证服务的稳定运行。

    2、这个点的问题在于运维或开发在休息日是否有条件(网络、电脑设备、位置)来解决问题;

    3、需要解决上面的问题,尤其是后台bug,至少需要一名中高级的后台开发工程师,且需要深入了解公司业务,且不能全职运维;这是一个尴尬的局面,如果遇见节假日反馈问题且需要及时响应,那么可能出现另一种工作状态,他必须在节假日上班,与正常出勤的同事无缝衔接;

    4、现有公司硬件资源有效利用:从业务角度,调配资源,资源使用率最大化,从而节省资源;

    5、有时扩容需求,这时需要监控现网数据来预测服务的增长趋势,对软件和系统性能进行调优。

    四、解决现状的办法

    1、招聘一位中高级运维,解决日常运维问题(环境、网络等方面),需要监控系统运行状态,懂开发技术架构,深入业务解决运营痛点,能做到业务级别监控,协助开发定位业务bug;

    2、运维技术层面需要会和开发做elk日志分析系统,熟练运用k8s集群,这会解决服务器自动伸缩(在服务器资源吃紧时增加实例,空闲时减少实例)、负载均衡(不能再依赖nginx来做)

    3、最终运维的作用将会是协助开发定位问题,获取日志、sql查询数据、服务器维护等或其他运维工作。

    更多相关内容
  • 谈谈程序员解决问题能力

    万次阅读 多人点赞 2017-03-25 12:36:47
    谈谈程序员解决问题能力 解决问题能力,程序员立业之本。 一般写文章我不会特意去写,而是有感而发的时候刚好又有时间我就会去写写文字。本想推些技术文章的,但写技术文章又很耗时,写得太浅显又没有技术含量...

    谈谈程序员解决问题的能力

    解决问题的能力,程序员立业之本。

    一般写文章我不会特意去写,而是有感而发的时候刚好又有时间我就会去写写文字。本想推些技术文章的,但写技术文章又很耗时,写得太浅显又没有技术含量,写多了恐怕大家也没耐心去看(不就是懒么,给自己找这么多借口)。公众号这么多,你又能看的了多少呢?小巫这个公众号不会像某些网红那样每天都想破脑袋去写文章,也不期望这个公众号能给我带来什么,毕竟以我的尿性我让我每天写鸡汤文我自己都会恶心。好了,进入今天这篇文章的主题,跟大家谈谈程序员解决问题的能力。

    为什么会想写这篇文章?

    前面我写过一篇关于独立思考的文章-你是怎么思考的?[1],大家感兴趣可以去看下。关于独立思考,我觉得每个人都应该要有,作为一个成年人,很多事情都要别人讲得很明白才懂得怎么去做,那别人也不太愿意把事情交给你办,也不太相信你能办好,你也很难掌控自己的命运。今天的这个主题虽然讲的是程序员解决问题的能力,其实也还是讲独立思考的能力,因为解决问题的能力也是源自你是否会独立思考。之前写过一些文章,有的同学想让我写写在鹅厂的一些经验,其实说真的,在鹅厂工作也是因人而异的,不管在哪里工作最终还是取决于你是怎么赋予工作的意义,每天纠结自己工作重复繁重,纠结工作技能得不到提升,纠结薪水满足不了自己的欲望,纠结这纠结那是毫无意义的。问题的根本也不在于这些,而是你是否足够沉得住气去提升自己。如果你连日常工作的一些问题都解决不好,你也别期望自己能在很短的时间内提升很高的水平。还是那句话,就算你有十年的工作经验,如果你只是一年的工作经验用了十年,那真的怪不得别人比你厉害了,人到中年的时候那真的有危机了。

    吐槽一些开发者白纸一般的脑袋

    之从做了SDK开发者之后,每天帮助用户解决各种各样的问题,那我真的有理由相信为什么国外的月亮会比国内的月亮圆了,因为国内的一些开发者真的让我很方啊。国内的开发者复制黏贴的能力是一流的,嗖得一声就能把功能实现,感觉好厉害的样子(皮皮虾,我们走)。集成我们提供的SDK的时候,也是嗖的一声遇到问题不知道怎么解决。

    小白开发者A:为什么升级弹窗提示不了?我已经完全按照文档集成了啊,求救啊。。
    小白开发者B:为什么集成热更新SDK之后,修复不了我的问题?
    小白开发者C:集成SDK之后,编译出错了,谁能帮忙看下。
    小白开发者D:怎么开启混淆啊。。。
    小白开发者E:为什么没有mapping文件。
    小白开发者F:为什么接入SDK之后,没有看到log。
    小白开发者G:这个异常怎么解决?
    更多。。。

    虽然标注的是小白开发者,但我也遇到很多工作好几年的开发者同样这样问问题,这个已经不是经验上的的问题了。换个角度思考一下,如果别人向你这样问问题,你会理睬他么,说真的我还不如利用这些时间多修几个bug,很多开发群最终都会沦为水群就是这个道理。大家都有当小白的经历,人生这一辈子不懂的事情太多了,那你总不能让别人牵着你走,作为一个程序员要对得起程序员这个称号,作为一个工程师,你是否能体现自己工程方面的能力。如果连基本的解决问题的能力都没有,那还是尽快放弃当程序员,这一行当没你想得这么好玩。

    怎样才算具备解决问题的能力

    我先说一下我的一家之言吧,说这些并不是为了吹嘘自己能力有多强,只是把我看到的和想到的东西用文字说出来,至于别人怎么去解读我是无所谓的。

    第一点:主动尝试解决问题

    程序员的解决问题能力不是天生的,自然得靠后天的经验积累。我们工作中会遇到各种各样的问题,比如需要去跟踪调试产品所产生的bug,又比如说使用第三方组件所遇到的一些问题,再比如说使用一些插件或者IDE所产生的一些编译问题。这个时候第一反应不是去别人那里寻求帮助,而是自己尝试去看去解决问题。首先得确定这是一个什么样的问题,对这个问题下一个定义,看它是自己编码上的问题,还是一些编译上的问题,再或者是第三方库引入的问题。确定之后,你可以根据运行时产生的崩溃信息或者编译时出现的编译错误,找到错误的根源。如果是代码上的问题其实是很好定位的,我们只需要根据错误的堆栈找到出错的地方,然后你再去看这部分代码的处理逻辑,只要不是特别复杂的业务处理,基本上能很快解决。如果是编译时出的问题怎么办?你先看具体的编译错误是什么,看自己以前是否有遇到过,是否能够确定是什么环节导致的编译错误,比如是开发环境版本问题,或者是插件的版本问题,又或者是代码导致的编译问题,这类问题只要逐个排除相信也能够轻松解决。那如果是业务逻辑导致的问题怎么办?那我就建议你自己根据需求重新梳理清楚业务逻辑,可以通过debug来验证你的结果,又或者可以通过日常写单元测试用例来保证业务逻辑的正确性。关于各类问题的解决,解决办法总是能找到,就看你是否足够耐心去寻求解决方案。

    第二点:学会提问

    刚才说的第一点,对开发者能力有一定的要求,并不是所有开发者都能够做到这一点,那如果依靠自身能力解决不了问题该怎么办?没错,就是向别人提问,但这里要注意一下提问的技巧,就不要像我所吐槽的白纸一般的开发者。关于提问的技巧很多人都在提,感同身受最深的应该是那些为开源项目做贡献的开发者了,只要一开源就必定会有很多人过来问问题,提issue。以我作为SDK开发者来说,我希望开发者这样向我提问:

    1. 首先态度诚恳,平等尊重(这很重要)
    2. 问题标题有针对性
      标题指明环境、错误时机、现象。如:
      较差的标题(×):发现一个兼容性bug(太宽泛,完全没有点进来看的欲望)
      较好的标题(√):Vivo X5上xxx SDK调用初始化时导致崩溃的兼容性问题求解
    3. 问题描述详细
      问题描述详细,可以方便其他用户帮您定位问题。尽量提供详细的环境、错误时机、堆栈、日志、现象、截图等等。
      可以参考如下格式:
      【问题描述】
      描述出现问题的环境:Android版本、设备型号、网络状态、SDK版本等等
      描述为了解决问题作出的一些尝试,例如Google查到的相关资料
      【错误堆栈】
      贴出由Bugly分享出来的错误堆栈(分享链或截图)

    这里有一篇文章也推荐大家看下- 提问的智慧[2],想提高自己解决问题的能力,首先得学会如何提问。

    第三点:经验总结

    我们日常遇到的问题就类似打怪升级一样,你解决的问题越多你的能力就会越强,经验自然也会越来越丰富。但人的脑袋不可能记住所有事情,将自己遇到的问题沉淀下来对以后自己查阅也有很大的帮助,就不必每次都要去Google,自己也能够有一个索引库。经常自己总结,也能够提高自己的写作能力,以后写文章、ppt总结提炼自然也难不倒你了,也是一举两得的事情。还有你以后求职面试过程中,提及自己这方面的能力的时候,也能够为自己面试加分哦。

    第四点:知识经验传承

    精神哥说过:不总结哪来的经验,不分享经验有何用?

    一个人能产生多大价值取决于他的影响力有多大,之前看到有人在我们内部论坛提问说提高影响力有什么用?你看看马云就能知道有什么用了,他说一句话比你说上百句都管用,毕竟人家的影响力在那里。很多微商都经常拿马云来说话,尽管马云自身没说过这些话,但为什么别人拿马云来忽悠人,不拿你来忽悠人,这就是影响力的作用。我们程序员做知识经验的传承,不仅能够提高你自身的影响力,还能够帮助你提升逻辑思维能力,因为你需要去总结提炼,你需要将问题梳理清楚,并且要将知识点描述得能够让别人更容易接受。你的经验虽然是你自己的,但如果你的经验能够帮助到别人,那你的价值就不一样了。

    总结

    笔者在写开发文档的时候,经常都会去思考怎么让开发者通过这个文档更加轻松的接入我们SDK,怎么样设计接口会更符合开发者的思维,多提几个为什么可以帮助自己让自己的思考更加完善,这篇文章是笔者入行这两三年的一些思考,也希望能够帮助到广大开发者能够清晰认识到自己在这方面的能力,最后谢谢大家能够看到这里。

    [1] . http://www.jianshu.com/p/e698fea61a39
    [2]. https://github.com/tvvocold/How-To-Ask-Questions-The-Smart-Way

    展开全文
  • ERP原理_能力需求计划

    千次阅读 2010-09-17 14:23:00
    <br />能力需求计划(简称为 crp)主要用来检验物料需求计划是否可行, 以及平衡各工序能力与负荷。...  能力需求计划主要解决以下问题:  1、各个物料经过哪些工作中心加工

    能力需求计划(简称为 crp)主要用来检验物料需求计划是否可行,

    以及平衡各工序能力与负荷。

    一、能力需求计划?及可解决哪些问题?

           对各生产阶段和各工作中心所需的各种资源进行精确计算,得出人力负荷,

          设备负荷等资愿负荷情况,并做好生产能力与生产负荷的平衡工作,最后制

          定出能力需求计划。

        能力需求计划主要解决以下问题:

         1、各个物料经过哪些工作中心加工

         2、各个工作中心可用能力及负荷是多少

         3、工作中心的各个时段的可用能力和负荷是多少

          能力需求计划与粗能力需求计划同属于对以上问题的求解,都是为了平衡工作中心的能力

           负荷,实现计划的可执行性与可靠性。

    二、能力需求计划的分类?

          ERP求解能力需求计划的方式有无限能力计划和有限能力计划两种。

          1、无限能力计划

               无限能力计划是指在做物料需求计划时不考虑生产能力的限制,而对各个工作中心的能力与负荷进行

               计算,得出工作中心的负荷情况,生产能力报告。这里所说的无限能力只是暂时不考虑能力的约束,

               尽量去平衡与调度能力,发挥最大能力,或进行能力扩充,目的是满足市场的需求;

         2、有限能力计划

               有限能力计划订为工作中心的能力是不变的,计划的安排按照优先级进行。先把能力分配给优先级高

               的物料,当工作中心负荷已满时,优先级别低的物料被推迟加工,

               该方法计算的计划可以不进行负荷与能力平衡。

    三、能力需求计划的计算方法?

           考虑能力需求计划的计算方法时,要把物料需求计划的物料需求量转抽象为负荷小时,即把物料量需求转

           换为负荷小时数。即把物料需求转换为能力需求。不但要考虑MRP的计划订单,还要结合工作中心和生产

           日历,同时还要考虑工作中心的停工及维修情况,最后确定各工作中心在各时间段的可用能力。

           公式:负荷 = 该产品产量 * 占用该工作中心的标准工时(或台时);

           若: 能力 - 负苛  >= 0.。则满足加工要求,能力富余。

                   能力 - 负荷 <   0     则不能满足加工要求,能力不足

         编制能力需求计划的具体做法:将MRP计划的各时间段内需要加工的所有制造件通过工艺路线文件进行编制

         得到所需要的各工作中心的负荷,再同各工作中心的额定能力进行比较,提出按时间段划分的各工作中心的

         负荷报告。由管理人员根据报告提供的负荷情况及订单的优先级因素加以调整和平衡。

    四、编制能力需求计划的步骤?
         1、收集数据

              (1)任务单数据

              (2)工作中心数据

              (3)工艺路线数据

              (4)工厂生产日历" 工厂生产日历是企业用于编制计划的特殊日历。

          2、计算负荷

          3、分析负荷情况

          4、能力/负荷调整

          5、确认能力需求计划

    五、能力需求计划的平衡与输出

           能力需求计划中有两个要素:负荷和能力。解决负荷过小或超负荷能力问题的方法有3种

           调整能力、调整负荷、以及同时调整两者;

          调整能力的方法有:
                 加班

                 增加人员和设备

                提高工作效率

                更改工艺路线

                增加外协处理

         调整负荷的方法有:

             修改计划

             调整生产批量

             推迟交货期

             撤消订单

             交叉作业


    展开全文
  • 怎么去思考一个问题,提高解决问题能力 前言: #:本文转发自【半路歌雨】 #:http://blog.jboost.cn/think-like-a-programmer.html #:如有侵权,联系即删 技术人员的价值,不在于你能写出多么优美的代码,也不...

    怎么去思考一个问题,提高解决问题的能力

    前言:

    #:本文转发自【半路歌雨】
    #:http://blog.jboost.cn/think-like-a-programmer.html
    #:如有侵权,联系即删

    技术人员的价值,不在于你能写出多么优美的代码,也不在于你能设计出一个多么大而全的高屋建瓴的架构,而在于你实实在在的解决问题的能力,在于你使用技术手段服务于业务的能力”。

    导入:

    先罗列一两个遇到的现象:

    某同事汇报,测试提了一个Bug,当某个用户绑定的卡信息超过50个的时候,后台显示数据就会出现混乱,问能不能限制绑定的卡不超过50个。我问:数据显示出现混乱是什么意思?答:不清楚;我再问:为什么超过50个就会混乱了,少于50个有没有可能出现混乱,造成混乱的原因是什么?答:不知道。我说你先去搞清楚什么叫“混乱”,然后再搞清楚为什么会出现“混乱”再来说解决办法。经过与测试人员的一番沟通后,跟我反馈说不是显示混乱,是显示不全,自己通过查看实现是因为在服务端做了字符串拼接,超过多少就被截断了。

    某同事在抱怨,这个问题很难复现,我不知道怎么解决,要不要把这块整体优化下算了。我问他你优化的目的是什么,是优化目前实现的流程、结构?还是通过优化来解决这个难以复现的问题?答:来解决这个问题。我说你问题都没定位到,怎么通过优化来解决,不怕老问题没解决,优化出新的问题出来了?

    你有没有也曾经说过或听过“这个问题太复杂了, 我解决不了”,“这个功能我没办法实现”,“我也不知道为什么会出现这个问题”之类的话语。

    以上的现象与话语,可能都是一个人解决问题的能力或方式方法还不成熟的体现。那么如何来提高解决问题的能力,我想首先需要先从思维方式或思维习惯上寻求改变。在网上看到有这么一篇文章——《How to think like a programmer — lessons in problem solving》(文章地址见文末参考部分),介绍了通过5个步骤来帮忙人们建立高效解决问题的思维框架。本文以这5个步骤为基础,结合自身的理解与体会进行介绍。

    一.怎么去看待问题

    “这个国家的每个人都应该学计算机编程,因为它会教你如何思考”

    像程序员一样思考
    像程序员一样思考,到底意味着什么,需要如何来做?
    像程序员一样思考本质上来说,是一种更为有效的解决问题的方法。

    解决问题的能力是一项元技能
    什么叫元技能
    类比于元数据——描述数据的数据叫元数据,我理解元技能就是提升技能的技能,就是说当你掌握了解决问题的能力,你就可以通过这种能力去提升其它各项专业技能。

    解决问题的能力也是最重要的能力,比精通编程语言,调试能力,以及系统设计能力都更为重要。

    提高解决问题能力的方法
    我们平时解决问题的方式可能是:

    尝试一种解决方案。
    如果这种解决方案无效,再尝试另一种方案。
    如果还是没有用,重复第二步直到你碰巧把问题解决了。
    这种方法被作者 Richard Reis 定义为解决问题最糟糕的方式。因为它不但浪费时间,而且能不能达到目的还得看运气。

    一.怎么去解决问题

    经过对优秀程序员在编程时的思维框架的分析,作者总结出提高解决问题能力的最好方法包括:

    有一个处理问题的框架
    按照这个框架反复练习
    那么,当你遇到一个新的问题时,该如何来解决?

    第一步:理解
    遇到问题时,我们应该先要弄明白问题本身。大部分情况下,问题之所以难解决只是因为你没真正理解它们(很多时候是出于沟通的不充分),理解问题是解决问题的第一步。

    如何确定自己是否真正理解一个问题?

    最有效的方法是,尝试用自己的语言来说出它,看有没有逻辑漏洞。当你能讲清楚一个问题时,说明你理解了它。优秀的程序员编程时,一般都会写下自己遇到的问题,画出流程或序列草图,或同产品经理、其它开发人员、测试人员等一起讨论确认。这个过程,就是在确定自己对问题的理解有没有偏差。

    “如果你不能用简单的语言来解释一个事情,那意味着你根本就没有理解它” —— Richard Feynman

    面对一个新需求时,你应该了解这个需求产生的场景——什么人,在什么时候通过执行什么操作,来达到什么目的?这个场景及其中的行为逻辑是否合理,设计是否存在漏洞,然后带着问题来与需求提出方讨论确认,而不是断章取义或不经任何思考直接编码开干。不做代码的搬运工,要做有思想的程序员。

    同样,面对一个 Bug 时,你应该首先了解这个 Bug 产生的场景——什么人,在什么场景,通过什么操作会产生这个问题?要追本溯源,定位问题的本源在哪里。
    我认为定位问题的本源比解决问题更重要!因为你只有正确地找到了问题的症结,才有可能去解决它,而解决办法却可能有多种。且从花费的时间来说,定位问题往往会占整个解决问题时间的一半以上。

    如果没有找到问题的本源,只是头痛医头脚痛医脚,那么可能不仅对解决问题无事无补,甚至还可能引进新的问题。常见的头痛医头脚痛医脚的处理方式包括,CPU占用高了,内存溢出了——升级服务器配置(可能过两天又得升级了!);接口超时了——增大超时时间(可能导致用户投诉或其它依赖的服务级联超时),等等。

    那么日常工作中,如何来定位问题的根源?对于一般问题来说,可能通过查看日志大致就能找到问题所在,对于比较棘手的问题,针对问题的性质一般可通过如下方法进行定位:

    对于易复现的问题: 常用的就是 Debug,通过 IDE 断点来跟踪数据的流转与变更,一个个环节检查数据输入输出是否正确来进行排查。可借助条件断点、异常断点等技巧来提高 Debug 效率。
    对于不易复现的问题:可通过对比法——对比其它地方的类似功能或实现,寻找两者之间的差异,差异之处往往就是问题所在;分析法——走读整体流程代码,捋清各个环节的逻辑,分析定位问题;日志法——在各个关键环节添加日志,将场景镜像下来,当下次复现的时候,通过分析日志定位问题。
    第二步:计划
    理解了问题,接下来就是解决问题的方案。没有明确的方案计划时,不要轻易去着手解决问题,不要寄希望于碰运气蒙混过关。许多开发人员习惯于快速扫一眼需求,就打开 IDE 开始垒代码,垒完发现要么与需求不符,要么漏洞百出。

    nobug

    制定计划,就是制定解决问题的战略步骤。

    不论面对需求还是 Bug,都应该好好计划你的解决方案。设计好解决方案中的各个环节,如业务需求的数据表设计、接口设计、流程逻辑,Bug 修复的具体实施步骤。并给自己一点时间思考与预演,该解决方案可能存在的漏洞与影响有哪些,除了这样处理,还有没有另外更好的解决方案。

    在没有想清楚解决方案时,不要直接上来就撸代码,暂停一下,给你的大脑一些分析问题和处理信息的时间。

    第三步:分解
    这是思维框架中最重要的一步。

    分解,就是化繁为简,就是我们常说的分治思想,拆分法——将大问题拆分为若干个小问题,然后逐个击破各个小问题,再合并总结。微服务架构,MapReduce 算法,都是这一思维(或思想)的体现。

    不要尝试一次解决一个复杂的大问题,而应把复杂的大问题分解成若干个简单的小问题(或子问题),从最简单的子问题开始(最简单意味着你知道怎么解决它或它更容易被解决,也或者这个子问题的解决不需要依赖于其它子问题),一个一个逐步解决。一旦你解决了所有的子问题,把它们串联起来,一般就意味着你解决了之前的那个复杂的大问题。

    分解问题的能力是解决问题的基石。这也是优秀的程序员在编程中最常用到的技能,对于他们来说,分解问题的能力,要比编程语言的熟练度、系统设计等技术更为重要。

    第四步:卡壳了怎么办?
    当你理解了问题,做出了解决方案的计划,将复杂问题分解为子问题后,在处理子问题时依然卡壳了怎么办?

    首先,淡定!然后告诉自己,这很正常,每个人都会遇到。

    优秀程序员或解决问题的高手,与普通人之间的差别就在于,他们对问题更有求知欲,更有耐心,他们的注意力更多地是在如何解决问题上,而不是为此恼火或甩锅发牢骚。

    当遇到卡壳的情况时,可以试试这几种方法:

    Debug:与前面定位问题一样,一步一步调试,直到找出究竟哪里出错了。
    “Debug 的艺术关键在于你究竟让软件干了些啥,而不是你以为你让软件干了些啥。”—— Andrew Singer

    重新评估问题:退回去,从另一个角度重新审视问题,别让自己迷失在细节里,有时候我们容易迷失在具体的细节中而忽略了更一般的原则。重新评估问题的另一种途径是推倒重来,可以删除(回滚)所有已做的事,重新开始,有时这是非常行之有效的方式。

    搜索解决方案:利用搜索引擎找到类似问题的解决办法,向他们学习。使用搜索引擎需要学会提炼关键字,关键字越有代表性,越容易找到答案。对搜索结果应该抱着参考的态度,而不是照搬,要明白为什么如此这般处理就能解决问题,并在解决问题后能依次延伸了解其上下游或相关知识,比如SQL查询慢,发现是索引未生效,则可以延伸了解都有哪些场景会导致索引失效;比如并发问题,则可以依此了解如何保证线程安全,同步机制,锁机制等相关知识。事实上,即使问题已经解决,你也可以经常这么做,因为这样你可以从其他人的解决方案中及上下游知识中学到更多。

    寻求支援:当通过以上方法都无法获得解决办法时,向你的同事、上级或朋友求援,如果是开源项目,到开源社区、技术群,或 github 的 issue 列表中发帖求援。

    记录问题与解决方案:将你本次遇到的问题与最终的解决方案用(电子)笔记本记录下来,便于后面回顾或参考。

    第五步:练习
    罗马不是一天建成的,你也不可能期盼通过解决一两个问题就能成为解决问题的高手。但是,如果你能以学习的态度来寻求问题的解决办法,通过以上四个步骤来建立一套解决问题的思维框架,每一个问题的处理都是提高你能力的机会。那么距离成为一个解决问题的高手,就只差一步了,那就是:练习,练习,再练习。在问题中练习,训练你的思维方式与习惯。

    “我不害怕一次练习1000个踢打动作的人,但我害怕将一个踢打动作练习1000次的人”

    总结
    其实,解决问题的能力,不论在IT技术领域,还是在其它各个领域,都是一种最基本的技能。当你在说出“这个问题我解决不了”,“这个问题我没办法定位”前,试试本文介绍的理解、计划、分解、卡壳时怎么处理的建议方法,多一些耐心,一步步实践,说不定慢慢就看到曙光了。按照这个处理模式或习惯,在日积月累的问题处理中,你可能已在不知不觉成为了解决问题的高手。

    展开全文
  • 物料需求计划MRP (Material Requirements Planning)是ERP的前身,要想真正了解ERP就必须对MRP有一个全面深刻的认识。本文论述了MRP的基本概念、原理和相关问题,希望能对大家有所帮助。 一、什么是MRP? MRP ...
  • 文章目录解决问题的理论模型解决问题的战略模型客户需求分析汇报管理实施领导力本书侧重探讨此模型的分析、汇报和管理部分 本书的基础是麦肯锡所实践的解决问题流程 关于解决问题流程 解决问题的理论模型 战略模型...
  • 解决办法:需求获取方能够适当的引导和挖掘 用语不准确,可能内心清楚但是表达能力欠缺 解决办法:尽量理解用户用于表述他们需求的思维过程。充分研究用户执行任务时做出的决策过程,并提取出潜在的逻辑关系。流程图...
  • 软件需求工程复习

    千次阅读 多人点赞 2020-04-22 09:52:17
    第1章 需求工程导论 1.软件生产中产生需求问题的最大原因在于对应用软件的...5.应用型软件分析阶段的主要目的是发现人们利用软件的原因(目的),找出需要软件解决问题,理解应用环境中的领域知识,保证功能的 ...
  • 产品经理的私房菜 - 腾讯产品模型 - 沟通能力

    万次阅读 多人点赞 2021-09-30 17:45:13
    产品经理的私房菜 - 腾讯产品模型 - 沟通能力篇 编辑导语:第三章是关于“沟通能力”的分享。本系列就围绕”腾讯产品的能力模型“,一起从头梳理,每一个能力项的提升思路。希望大家从梳理过程中,找到提升的方向...
  • 需求变更”,一旦提到软件开发项目...本文中,与您共同探讨软件开发项目中的需求变更发生的原因、需求变更控制,以及当发生需求变更的时候如何应对解决。   一、令人烦恼的需求变更   作为一个软件项目经理
  • 一、软件需求说明书 1引言 2 1.1编写目的 2 1.2背景 2 1.3定义 2 1.4参考资料 2 2任务概述 2 2.1目标 2 2.2用户的特点 3 2.3假定和约束 3 3需求规定 3 3.1对功能的规定 3 3.2对性能的规定 3 3.2.1精度 ...
  • 需求解决问题的前提。 其中标注为软件系统工程的一些活动,是作为系统工程工作的一部分被实施的。 Q:什么样的陈述可以被称为需求? 1.这个需求是否有必要?–&gt;必要的(Necessary) 2.会不会产生歧义?–&...
  • 产品经理的私房菜 - 腾讯产品能力模型(序章)

    万次阅读 多人点赞 2021-04-16 18:41:49
    编辑导语:为了解决”产品经理“职业成长中,不自信的问题。本系列就围绕”腾讯产品的能力模型“,一起从头梳理,每一个能力项的提升思路。希望大家从梳理过程中,找到提升的方向! ❞ 「初稿|木深、木小深」 「...
  • 可靠性问题。云用户要求云服务商能够提供一个可靠的服务,如果云服务商在实施重大任务的过程中出现严重失误,应该可以按照预期规则明确划分责任。2008年2月15日亚马逊的S3服务中断两小时。虽然随着云计算技术的成熟...
  • 了解大一新生需求,并针对的给出解决方案,帮助大一新生解决问题 调查结果与分析 5想家之后会做什么事 调查表明 1一部分人想家会留在心里,独自一个人难受不知道要怎么办 2大多数同学想家之后会与家人...
  • 今天的这个主题虽然讲的是程序员解决问题能力,其实也还是讲独立思考的能力,因为解决问题能力也是源自你是否会独立思考。 之前写过一些文章,有的同学想让我写写在鹅厂的一些经验,其实说真的,在鹅厂工作也是...
  • 软件需求工程笔记

    千次阅读 多人点赞 2019-11-28 22:55:16
    项目范围: 指出当前项目主要解决产品长远规划中的哪一部分。范围的声明为项目化定了需求的界线。 定义范围的必要性: 加强用户和开发人员的理解,降低风险 通过定义项目范围,帮助涉众建立现实的期望 为项目化...
  • 【软件工程】需求分析文档——需求规格说明书

    万次阅读 多人点赞 2021-03-18 10:13:37
    文章目录1 引言1.1 编写目的1.2 背景1.3 术语和缩略词1.4 参考资料2 任务概述2.1 项目概述2.1.1 项目来源及背景2.1.2 项目目标2.1.3 系统功能概述2.2 用户特点2.3 假定和约束3 功能需求3.1 功能划分3.1.1 系统功能...
  • 高性能MySQL实战课

    万人学习 2020-05-21 15:07:35
    使用MySQL解决大量数据以及高并发请求已经是程序员的必备技能,也是衡量一个程序员能力和薪资的标准之一。 为了让大家快速系统了解高性能MySQL核心知识全貌,我为你总结了「高性能 MySQL 知识框架图」,帮你梳理学习...
  • 软件工程需求分析方法

    千次阅读 2019-11-28 17:12:02
    详细介绍软件工程需求分析方法,转载自别处,
  • PMP项目管理13个计划

    千次阅读 2019-06-14 09:57:50
    1、变更管理计划 所属过程:制定项目管理计划 含义:定义管理项目变更的过程,用来明确如何对变更进行监控。为管理变更控制过程提供指导,记录变更控制委员会的情况。 内容:当项目需要变更的时候,如何进行变更。 2...
  • 一个真正的高手,其实应该有能力用一套方法论去解决问题的所有,不管这个问题再难,再新鲜,再简单都能搞定。 什么是问题?一言以蔽之,问题来源于现实与目标的差距。 因此,问题产生的原因可能是: ...
  • 需求分析师应具备的几项能力

    万次阅读 2017-09-19 22:21:59
    需求分析师应具备的几项能力(不断总结中) 转载▼   1、沟通能力:  1)与客户:通过与客户交谈,挖掘本质需求。  举例:有时候客户会提出增加一个字段,一线的实施人员或销售...
  • 软件测试测试人员遇到的问题解决方法(面试)

    万次阅读 多人点赞 2018-04-10 11:09:00
    这个问题很广,主要方面是面试人想看被面试人遇到问题,是怎么解决的 1. 经常会遇到页面中内容或数据显示错误,甚至不显示回答是:我会进一步了解这个BUG的问题出在那里,并且简单的使用浏览器自带开发者工具或者...
  • 软件需求工程-需求工程概述

    万次阅读 2019-10-21 10:09:43
    一、需求工程的重要性 1.软件项目成败因素分析 软件项目成功因素: 用户的参与 执行层的支持 清晰的需求描述 合适的规划 现实的客户期望 较小的里程碑 有才能的员工 ...不完整的需求 ...技术能力缺乏 … ...
  • 面试题,你是如何做需求分析的?

    千次阅读 2021-01-03 17:20:00
    我们学员在面试中遇到这样一个问题,面试官问,项目中你是怎么做需求分析的?这类问题也比较常见,这里总结一下,提供一个答案供大家参考。题目分析:这一题是对产品经理专业技能的考察,主要考察需求...
  • 成为跨领域的「解决方案架构师」需要什么素养?

    万次阅读 多人点赞 2018-01-08 00:00:00
    「文末高能」编辑 | 哈比跨领域解决方案架构师的养成在架构师这个职业路线上,笔者理解的路径是这样的:从一个相对专注的架构师到解决方案架构师,再到更抽象,全面,具有企业顶层设计能力的企业级架构师,这个过程...
  • 中国航空发动机正处于向自主研发迈进的跨越发展时代,研发能力建设与型号研制并行,数字化工具更应“雪中送炭”,发挥补全研发能力短板、解决工程实际问题等现实作用。同元软控MWorks全面支持基于模型的系统设计与...
  • 软件需求工程2018期末题

    千次阅读 多人点赞 2019-10-17 10:07:29
    三、多项选择题 3.1 以下哪些属于需求工程活动的独立阶段() 需求获取 需求分析 形成需求规格说明 需求验证 ...3.4 CCB的主要作用 获取其他需求 制定决策 交流情况 设计系统部件 重新协商约定 ...
  • 如何进行需求评审

    万次阅读 2018-09-04 09:22:24
    作为产品经理,一般都经历过需求评审,或者是自己主持的需求评审,或者是参加别人的需求评审...所以说需求评审体现了产品经理的综合能力,如果完成的好,后续实施会比较顺利,也会提高自己在团队中的影响力,如果完...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 630,059
精华内容 252,023
关键字:

能力需求计划解决的主要问题