项目开发过程中会遇到很多问题,今天分享十个常见问题及应对思路。
不是每一个问题都值得被追责的,指责也不能修复bug。发现问题后,关键是解决问题。问题解决后,再作复盘。复盘的目的也不是追责,而是为了防止问题再次发生。一个重大的错误应该被当作是一次学习而不是指责他人的机会。团队成员们在一起工作,应互相帮助,而不是互相指责。把矛头对准问题,齐心协力找到解决办法,而不是去指责团队成员。
古语说:欲速则不达。但如果项目眼看着就要延期,怎么办?项目负责人有压力,研发人员同样也有压力。压力过大会让人走捷径,只看眼前利益。哪怕项目负责人不愿意走捷径,怎么落实呢?如果你考核开发人员要准时完成任务,你怎么保证他不会用一些”特殊方案“呢?堵不如疏,还是要用流程来解决这个问题。可以跟团队成员约定好,在项目开发过程中,因为时间不够,但有其他更简单的方案应对时,可以把解决方案抛出来,让大家一起决定。虽说我知道不走捷径本身就是走捷径。但有时候还是要妥协。虽然妥协会给未来埋坑,但只要控制的好,有应对方案,风险就整体可控。
无论是历史原因,还是啥原因,一旦发现某个模块没办法进行迭代的时候,就需要安排时间审查、重构代码。做项目又不是比谁做的功能多。早期公司为了生存求快,可以理解。等到公司度过生存期进入发展期,就应该早点还技术债,不然越到后面越难改。
这是在做需求讨论时,我们都应该自问的一个问题。明明都知道应该对事不对人,但每个人或多或少都有一些自我主义。你很可能见过,对方案设计的讨论失控变成了情绪化的指责——做决定是基于谁提出了这个观点,而不是权衡观点本身的利弊。
很多争论都是主观判断引起的,而解决的方案就是改变沟通方式。最好的沟通方式是yes,and 或者yes, if。先肯定其观点,再提出疑虑或者新的东西。举个例子,同事A针对项目提出了一个实现方式,你觉得有问题。但不要直接说这个问题,应该先肯定yes,谢谢A提供的方案,我们是不是还需要考虑多端登录的问题?(and贡献新东西)。
所有的系统开发久了都会变得很复杂,因此没有一个人能完全明白所有的代码。除了深入了解你正在开发的那部分代码之外,你还需要从更高的层面来了解大部分代码的功能,这样就可以理解系统各个功能块之间是如何交互的。我有一个观点,每一个开发人员都应该理解需求背后的目标或者理由。只有理解需求,你才懂你的代码。想要解决无法维护代码问题,需要从源头开始做规范。
团队存在的意义就是承认一个人干不过来,需要团队一起去干。每个人都会犯错。如果你准备提出一个想法,却担心有可能被嘲笑,或者你要提出一个建议,却担心自己丢面子,那么你就不会主动提出自己的建议了。然而,好的软件开发作品和好的软件设计,都需要大量的创造力和洞察力。分享并融合各种不同的想法和观点,远胜于单个想法为项目带来的价值。事实上,很多公司都会安排一些初学者来提建议。
我们每个人都会有好的想法,也会有不对的想法,团队中的每个人都需要自由地表达观点。即使你的建议不被全盘接受,也能对最终解决问题有所帮助。不要害怕受到批评。记住,任何一个专家都是从这里开始的。你不需要很出色才能起步,但是你必须起步才能变得很出色。
如果你非常确定决策有问题,我建议还是要提的,只是要注意提建议的方式,不要用主观观点去质疑,而应该摆事实。(最好的方式是在会前提出)
如果你没提出,或者提出后方案还是被确定了(不管是什么样的方案),那么就接受它。然后和团队成员通力合作,努力实现这个方案。
根据自己的需求来选择新技术。首先你得明确你需要什么,要解决什么问题。根据具体的问题来评估使用新技术。其次,要了解新技术的利弊,每一个技术都是有局限性的。最适合的才是最好的。最后,你要清楚使用新技术需要付出的代价。
许多新技术都是基于现有技术和思想而开发的,这些新东西也是逐步完善。如果你紧跟技术变化,那么学习这些新东西对你来说就是了解这些增量的变化,如果你不跟踪变化,技术变化就会显得很突然并很难理解。这就好比少小离家老大回,你会发现变化很大,很多地方都不记得了。然而,对于居住在那里的人们,每天看到的都是小小的变化。所以非常适应。
如果你想尝试一门新技术。我的建议是先小范围尝试,宁可慢,不能错。
首先,要明确这种现象是正常情况。哪怕有需求评审会,我们也没办法找出所有问题,有些问题只有在编码的过程中才会发现。
其次,不要自己想解决方案来规避或解决问题。有些你以为的问题,在业务上并不是。或者可以用一些非技术的手段来解决这个问题。
最后,梳理清楚问题,然后跟产品负责人、开发负责人、项目经理一起讨论。如果早上有晨会,可以在晨会上把问题抛出来,确定讨论任务和时间,但不在晨会上做详细讨论。