项目开发过程中会遇到很多问题,今天我分享十个常见问题及应对思路。
问题一,写的代码出Bug了,是先找到问题原因,找到责任人,还是先处理问题?
不是每一个问题都值得被追责的,指责也不能修复bug。发现问题后,关键是解决问题。问题解决后,再作复盘。复盘的目的也不是追责,而是为了防止问题再次发生。一个重大的错误应该被当作是一次学习而不是指责他人的机会。团队成员们在一起工作,应互相帮助,而不是互相指责。把矛头对准问题的解决办法,而不是人。
问题二、快速实现功能让项目上线,还是追求研发质量?
古语说:欲速则不达。但如果项目眼看着就要延期,怎么办?项目负责人有压力,研发人员也有压力。这种压力会让你走捷径,只看眼前利益。哪怕项目负责人不愿意走捷径,怎么落实呢?如果你考核开发人员要准时完成任务,你怎么保证他不会用一些”特殊方案“呢?堵不如疏,还是要用流程来解决这个问题。可以跟团队成员约定好,在项目开发过程中,因为时间不够,但有其他更简单的方案应对时,可以把解决方案抛出来,让大家一起决定。虽说我知道不走捷径本身就是走捷径。但有时候还是要妥协。但这种妥协,就算会遗留一些问题,只要我们知道,有应对方案,就不可怕。
问题三、发现程序有缺陷,需要时间重构。但是新需求又很多,我该怎么办?
及时反馈,是高效协作的基础。一旦发现原来的实现有问题,就要立即做出反馈。要明确线上的问题优先级是最高的。不能因为新需求而忽视对线上问题的修改。这种情况有时候很难,需要你在团队内承认自己的问题。但从另一个方面说,如果你没有犯过任何错误,只能说明你没有努力去工作。
问题四、我们在讨论需求的时候,到底是对事还是对人呢?
这是在做需求讨论时,我们都应该自问的一个问题。明明都知道应该对事不对人,但每个人或多或少都有一些自我主义。你很可能见过,对方案设计的讨论失控变成了情绪化的指责——做决定是基于谁提出了这个观点,而不是权衡观点本身的利弊。
很多争论都是主观判断引起的,而解决的方案就是改变沟通方式。最好的沟通方式是yes,and 或者yes, if。先肯定其观点,再提出疑虑或者新的东西。举个例子,同事A针对项目提出了一个实现方式,你觉得有问题。但不要直接说这个问题,应该先肯定yes,谢谢A提供的方案,我们是不是还需要考虑多端登录的问题?(and贡献新东西)。
问题五、写的代码由于人员变动,导致没人能维护。
所有的系统开发久了都会变得很复杂,因此没有一个人能完全明白所有的代码。除了深入了解你正在开发的那部分代码之外,你还需要从更高的层面来了解大部分代码的功能,这样就可以理解系统各个功能块之间是如何交互的。我有一个观点,每一个开发人员都应该理解需求背后的目标或者理由。只有理解需求,你才懂你的代码。想要解决无法维护代码问题,需要从源头开始做规范。
- 经常做代码审核,让团队内的其他成员检查你运行的代码。在你不说明的情况下,其他同事能看懂,间接说明你的代码风格很清晰
- 做好单元测试,单元测试帮助你很自然地把代码分层,分成很多可管理的小块,这样就会得到设计更好、更清晰的代码。同时,它能直观看到结果是否与你所想的一致。
问题六、我能力不行,开会时不应该提出自己的见解?
团队存在的意义就是承认一个人干不过来,需要团队一起去干。每个人都会犯错。如果你准备提出一个想法,却担心有可能被嘲笑,或者你要提出一个建议,却担心自己丢面子,那么你就不会主动提出自己的建议了。然而,好的软件开发作品和好的软件设计,都需要大量的创造力和洞察力。分享并融合各种不同的想法和观点,远胜于单个想法为项目带来的价值。事实上,很多公司都会安排一些初学者来提意见。
我们每个人都会有好的想法,也会有不对的想法,团队中的每个人都需要自由地表达观点。即使你的建议不被全盘接受,也能对最终解决问题有所帮助。不要害怕受到批评。记住,任何一个专家都是从这里开始的。你不需要很出色才能起步,但是你必须起步才能变得很出色。
问题七、领导在会议上决定执行一个错误的决策,你作为下级,是否当众提出疑问?
如果你非常确定决策有问题,我建议还是要提的,只是要注意提建议的方式,不要用主观观点去质疑,而应该摆事实。(最好的方式是在会前提出)
如果你没提出,或者提出后方案还是被确定了(不管是什么样的方案),每个团队成员都必须通力合作,努力实现这个方案。
问题八、有一门新技术出现,要不要使用?
根据自己的需求来选择新技术。首先你得明确你需要什么,要解决什么问题。根据具体的问题来评估使用新技术。其次,要了解新技术的利弊,每一个技术都是有局限性的。最适合的才是最好的。最后,你要清楚使用新技术需要付出的代价。
许多新技术都是基于现有技术和思想而开发的,这些新东西也是逐步完善。如果你紧跟技术变化,那么学习这些新东西对你来说就是了解这些增量的变化,如果你不跟踪变化,技术变化就会显得很突然并很难理解。这就好比少小离家老大回,你会发现变化很大,很多地方都不记得了。然而,对于居住在那里的人们,每天看到的都是小小的变化。所以非常适应。
如果你想尝试一门新技术。我的建议是先小范围尝试,宁可慢,不能错。
问题九、如何才能跟上技术变化的步伐呢?
- 迭代和增量式的学习,每天计划用一段时间来学习新技术,当你听到一些新的名词时,简要地记录,然后在计划时间去了解。
- 互联网给了一个我认为最好的方式,找到这个领域里的某一位或几位牛人,跟着他们学。有线上课程的看课程,有线下活动的参加线下活动。出了书的看书。
- 明确自己不需要精通所有技术,也不可能精通每一项技术。只要你在某些方面成为专家,那很容易用同样的方式在新领域成为专家。
- 要理解新出现的技术是为了解决什么问题而开发的,它能用在哪些领域。从而规划自己的项目和职业生涯。
- 应用技术时,必须先评估新技术的优势。然后用一个小的原型系统去验证。
- 打造一个学习型团队,每周固定时间做分享会。让每个人参与。提高学习效率。
问题十、编码过程中发现需求有问题,怎么办?
首先,要明确这种现象是正常情况。哪怕有需求评审会,我们也没办法找出所有问题,有些问题只有在编码的过程中才会发现。
其次,不要自己想解决方案来规避或解决问题。有些你以为的问题,在业务上并不是。或者可以用一些非技术的手段来解决这个问题。
最后,梳理清楚问题,然后跟产品负责人、开发负责人、项目经理一起讨论。如果早上有晨会,可以在晨会上把问题抛出来,确定讨论任务和时间,但不在晨会上做详细讨论。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。