什么是场景创新？所谓场景，就是指什么人在什么时间，什么地点遇到了什么事，然后他们是用什么方法解决的。而创新就是通过分析发现场景里的问题，把问题转化为需求，用更好的产品或服务去满足这些需求的方法。为什么要通过场景做创新？主要是现在的创新成本在变高，创新机会在变少。而我认为场景创新有两大优势：发现新的机会和灵活运用现有资源。1. 发现新的机会这点好理解，社会在发展，用户的场景就会一直处于动态变化中，越
今天给大家介绍一个非常好用的工具：黄金圈法则。黄金圈法则，最内层是Why（为什么）、中间层HOW（怎么做）、最外层What（是什么）从为什么开始，才能激励我们每个人行动。Why：最内层——为什么，做一件事的原因或目的，也可以说是理念和宗旨，属于战略层面；How：中间层——怎么做，针对这个目的或理念的计划，也即如何去做好这件事情，属于战术层面；What：最外层——是什么，最终得到什么，或者要做哪些具
今天给大家介绍两个概念，反馈效应和反馈回路。反馈效应反馈效应是指对活动结果的评价。能强化活动动机，对工作起到促进作用。反馈效应在工作中尤其重要。公司年终业绩汇报结束了，你认为表现得可圈可点。但这只是你以为。现实可能和你想的不一样。一般情况下老板可能有下面三种反馈：零级反馈：老板啥也不说，连一句肯定和表扬的话都没有。一级反馈：只是简单地提出表扬或批评，比如：太棒了，太好了。二级反馈：不仅真挚地表扬了
前段时间和朋友聊天，突然聊到这个话题。作为管理者，他觉得什么事都需要自己做。试过把事情交给下属做，但是经常出问题。我说：“出了问题不可怕，就怕你不知道为什么会出问题。”我以前讲过，如果管理者什么事都亲力亲为，迟早会成为团队的瓶颈。你一个人是做不了所有事情的。不仅是时间精力问题，也有能力问题。很多管理者理解错了授权的意思，授权并不只是将任务分配出去，然后你就不管了。相反，你依然是事情的总负责人，只是
项目的需求来源有很多方面，最终由产品整理出来哪些要做，哪些不做。我前面说过需求评审时，要讲清楚这次版本的目的是什么。这些要做的功能就是达成目的的手段。一般情况下，我们都默认产品或技术总监给需求定优先级。比如优先级高、中、低。实际上这样分还不够细，优先级高的标准是什么？想要做好优先级管理，首先得制定一套标准。不一定要非常准确，但一定要有且公开。任何一个需求，都有其价值。其价值主要分为：商业价值、用户
职场里的上下级沟通，跟平常朋友、同事之间沟通还不一样。下属普遍对上级都有畏惧感，而这可能比我们自己想象的会更严重一点。以下三个场景，管理者需要注意。一、放大领导的意图我意识到这个问题是由于自己的一段经历，有一天我和上级一起吃饭，在这个过程中，他提到了一个产品的功能，问我完成的怎么样了。我说按计划是下周五才能完成，领导说了句进度有点慢哈。吃完饭之后，我就去调整了需求的优先级，提前三天完成了该功能。我
项目测试达标后，就需要启动上线了。项目上线过程中有几点需要注意。一、制定上线清单，先上测试环境清单的要素包括：什么人，在什么时间，需要准备什么资料，做什么事。其中，要明确先后顺序，要明确如何验证是否出现异常、明确验证方式以及问题处理方式。上线之前，先在测试环境预上线一次，把所有的相关环节的资料和流程用清单的形式记录好。尤其是上线过程中遇到的问题。解决后，再从新在走一遍上线流程。全自动部署，减少人工
需求功能都做完了，并且通过了自测，就可以转测试了。UI设计师在这个阶段会验收视觉效果。UI验收也可以在每一个前端页面完成后，是可以提前的，根据设计师的工作情况灵活调配。一般公司还会有UE设计师岗位，是验收交互流程的。我公司是由UI兼任。测试人员会根据测试用例验收功能，首先会进行单元测试和简单的集成测试。本来这个是开发人员做的，但是测试人员会按流程走一遍。如果连基本功能测试都通不过，会直接打回，让研
代码重构重构就是在不改变软件系统外部行为的前提下，改善它的内部结构。重构不是重写，它们的区别你可以理解为，重构是修复代码，大框架不变。重写是扔掉原来的，重新设计框架。为什么需要重构？因为代码不是个静态的东西，他会随着时间变得越来越复杂。什么时候需要重构？当你发现以下几种情况时，应该重构。一、代码不符合代码规范。二、有新的实现方式具有更高的效率。三、你看完代码后觉得应该重构了。重构是一种习惯，而不是
业务也懂了，系统梳理了，要做的需求也弄懂了，是不是就该编码了？对的，确实该编码了。但在写之前，有以下三个方面要注意。统一格式要和团队统一格式。否则你在本地格式化一下，会有很多冲突，代码就很难管理了。一般团队都会给你一个配置文件。配置一下即可。编码规范有一些编码规范，就算公司没要求，你对自己也要有要求。这方面的资料很多，我建议你在编码时问自己几个问题1、我这样写，别人是否能通过命名看出代码的意思？好
时间管理除了提升时间的效率外，还得提升时间的使用质量。毕竟，在公司里，老板最终看的是你创造了多少价值，而不是做了多少件事。我们可以借助“时间管理象限”来弄清楚做什么与不做什么。时间管理四象限法则时间管理四象限法则就是把事情按重要、紧急二个维度分为四个象限：重要而且紧急：安抚愤怒的客户、线上出现的bug、到了截止日期还未完成的任务等。这类问题要立即去处理，但解决问题后，还要去解决问题背后的原因。重要
需求确认好之后，每个人都会领到自己的任务。我们首先要做的是评估个人开发时间和团队的上线计划。任务拆解首先第一步是做好任务分解，拆的越精细，评估时间越准确。就算是最简单的登录功能也可以拆。比如按业务，你可以拆成：微信登录、支付宝登录、账号密码登录、验证码登录。按接口，可以拆为账号登录、验证码登录、第三方账户授权登录。评估工作量第二步对拆解的任务评估工作量。按小时评估或者按天评估。这是一个非常主观的任
一、弄懂需求目的。对开发而言，弄懂需求，就是要知道需求的目的，以及用何种方式去实现。实现后，再看结果跟预期是否相符。如果相符那就做对了。如果不相符，那肯定哪里做错了或想错了。产品经理的需求文档是通过X推导出来的Y。我刚刚工作那会，需求评审会上讲的都是Y，从没人告诉我X是什么。但Y只是实现方式之一，也许还有更合适的方式Z，在不知道X的情况下，团队其他人没办法想到Z方案。有了需求目的，每个参与者都可以
很多人以为程序员刚刚入职就需要写代码，其实大部分程序员入职之后的很多天，都是在看代码，而不是写。看代码是程序员精进的方式之一。我刚刚工作那会，大部分时间都是在看代码。看不懂就调试。调试也是观察代码的一种方式。但很多系统动则几万、几十万的代码。我们先看什么？1、先不看代码，先看文档。看整个架构图。新人入职后最好先让领导讲解整体项目的架构。否则会非常吃力。如果遇到以前写代码同事已经离职，现在这部分代码
真实项目跟以前写着玩的项目不一样。有几方面需要特别注意一、项目协作，你需要快速的融入团队，这不仅仅说跟大家熟悉。你还需要适应团队的文化氛围、团队的编码规范、公司的业务逻辑，以及公司项目运作的流程，而这些都需要时间。二、从简单做起，不要排斥简单的工作任务。大部分人进入新公司也都是从改bug和一些简单的模块做起。我自己的经历就是如此，最开始就是改问题，改着改着，代码结构搞清楚了。改出问题，又要想办法解
在大部分公司，程序员做完功能后，会有专门的测试部门同学来进行专业的测试。其实早期很多大公司都没有测试岗，是随着测试的技能越来越多，对能力要求越来越高，才专门有了测试的岗位。但我觉得哪怕公司有测试工程师，作为研发人员，自己也要会测试。懂一些测试思维。想一想，如果在团队里，你每次提交的代码，反馈的bug最多。是不是也脸上无光？我觉得以下几点，是每个研发人员都应该思考和锻炼的。一、非正常情况思考。在惯性
前面写了好几篇关于程序员入门的文章和相关的话题讨论，这次讲讲如何做好面试。最近5年里，工作的一部分时间都放在了面试上，为了提高面试的质量和效率，我给不同岗位都做了面试必问的几个关键问题。这次分享下我为什么会这么问，以及推荐大家在面试过程中应该如何做。比如，在工作过程中有遇到过什么挑战吗？你觉得这个挑战难点在哪里？你是如何应对的？结果如何？你觉得你的做法有什么改进之处吗？你享受其中吗？其他人有什么做
大部分人都会有找工作的需求。但很多人对公司没有要求，哪个公司给的工资高就选择哪个公司。长期看，这对整个职业发展来说并不是最优选择。工作不能仅看工资，以下几点也需要着重考虑。
话题讨论：公司已经发不出工资了，你会选择坚持还是放弃？这是非常现实的话题，想到这个话题是我前一家公司正好出现这种情况，选择留下的也很多，选择走的也不少，每个人都有自己的理由。从现在回看一年多前同事的选择，从经济角度上看，离开的同事的对的，选择留下的同事工资都还没着落。但项目还没死，在长远了看也还说不定，但对创业公司来说，资金链一旦断了，确实很难起，大家不要低估创业的难度。在疫情期间肯定也有很多类似
我们都知道要代码要写的简单好用。但好代码到底需要具有什么标准？第一级，代码能解决问题，达到目的。大部分刚刚入行的程序员都在这一等级，遇到问题网上搜索一个代码运行能解决就行。第二级，代码要可读，可读的意思是，给任何一个同事看，他都能看懂你代表要表达意思以及解决的问题。而想要达到这个标准，你前提得有一个好的命名、注释等等编码规范。其次就是代码逻辑要简单。第三级，代码要可扩展，可扩展的意思就是在指在需求
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
