是的，软件开发绝不是在公园里散步。

我们经常解决无法预见的问题，如果你不犯这些常见的软件开发错误，许多问题是可以避免的。我将引导大家解决错误，这些错误可能会破坏自己的辛勤工作并使有前途的项目白白失败!

作为开发人员、分析师、产品负责人、主管或 CTO，我遇到过这些所有问题，尽管有些看起来很基础，但它们仍然会伤害你的团队。请与我深入了解～

不了解产品

为什么软件开发如此令人兴奋?对我来说，这是因为有机会学到很多行业的知识。通过引入该领域的项目来创造并塑造它们的未来。比如人们有机会在人力资源、医疗保健、金融和各种行业的产品上创造价值。

虽然了解不同领域令人兴奋，但也极其具有挑战性。

如果你渴望构建成功的产品，则必须了解其行业背景。对于我而言，软件开发不是编码，而是关于在盈利的同时为最终用户寻找最佳解决方案。

软件工程师的关键要点是——了解业务核心和应该实现的每个功能。如果你只是一个听命令的机器人，那开发可能是工作链条中最昂贵的部分，每个错误并不便宜。

我相信技术咨询和代码审查任务是技术专家的附加价值，他们可以纠正最初雇用你的公司业务人员的错误观点。而能够交换意见是团队相对于个人的最大优势。

假设即事实

决策是每个产品开发的核心部分。

很自然地，人们对以前的项目和假设看法会发挥作用。请注意这些问题，猜测比询问别人更简单，但它很危险!如果你碰巧做对了，那么幸运的，但如果不是，在开发周期的后期如果出现问题，那将会付出很昂贵的代价。

如何避免这种悲伤但常见问题呢?

与你的团队保持联系，互相支持。如果你处理一个超级复杂的问题并且无法就最终结果达成一致，请咨询或准备一个小型实践。

咨询该领域的专家或用户可以对这件事有新的认识。假设和实验特征的结果非常适合收集反馈，它允许人们实现一个可能是错误的行为，但已经具有验证其正确性的机制。该机制可能是一个指标、一项调查、一个关于该功能的实验性质的可预见警告，包括获取用户反馈的简单方法，然后由你和团队为特定假设选择最优机制。

缺乏沟通

沟通很重要。真的么?这句话你听过多少次?天天说无数次。

然而在与各种规模和性质的团队合作后，这仍是一个问题。而创建一个没有人害怕发言的安全开放的环境，是避免无声的积压改进、制定毫无意义的冲刺计划和漫无目的的每日 Scrum 会议最行之有效的方法。

如果您想要的不仅仅是将项目从一列移动到另一列，请找到一位能帮助您指导开发的导师。比如你遵循 Scrum 框架但没有 Scrum Master，则应该去找一个。就像足球运动员不会在没有教练的情况下比赛。

当你意外发现只有 10% 的后端为你刚刚完成的新 FE 功能做好了准备，或者实现的 API 调整不兼容时，去专注于沟通吧，它可以避免你在 sprint 结束时有意外惊喜。

关键要点是什么?

建立团队精神，让人们喜欢彼此分享想法，如果觉得沟通太困难，请找一位 Scrum Master 或教练来简化整体流程。

商业与技术语言的障碍

相互理解是有效团队的基石。软件开发将两个通常不知道如何沟通的世界结合在一起。以下是一些事情向南而失去意义的例子：

技术人员用技术术语，业务人员不明白;技术人员希望业务人员做出技术决策，但业务人员不知道如何做出决定，因为他们不了解技术观点;商务人士用商业术语，技术人员不明白;业务人员试图在不理解的情况下使用技术术语;在商业和技术中使用不同含义的相同词汇。

是不是很熟悉?如果想诚实地交流，而不是假装交流，请了解您的听众并使用他们理解的词语。

从上下文开始，概述问题，提出解决方案，解释结果，提供示例，并确保你的听众完全理解。

错误 404：未找到上下文

假设为功能准备新需求。你可以简单地描述该功能应该做什么，为什么重要，以及它将如何让它更接近目标。

或者，您可以概述从 A 到 Z 的所有内容，而一点没有讨论的余地。哪一个更好?我相信大多数开发人员会更喜欢第一种方法。

新需求是讨论的起点，而不是最终作业。因此，产品负责人应该始终从上下文描述和反馈收集开始。了解问题及其背景的团队成员更有可能提出更好的想法。让开发人员按照所写的内容精确地编程会浪费工程师们的潜力，并会导致误解。

“为什么的问题”不是不信任或攻击性的表现，而是兴趣的表现，它是区分成功团队和不成功团队的关键。

是什么让产品负责人重蹈覆辙?时间压力是一个答案，但不能成为借口。有时需求完成得太晚了，开发人员的反馈没有空间。设计已完成，文档已编写。在这种情况下，停止并丢弃需求可能具有挑战性，但如果您没有找到原因的答案，这仍然是值得的。

一些资源被浪费了，但许多资源被节省了，所以这里的教训是——尽快共同参与并从为什么开始。

团队内部孤岛

你的团队由后端、Web、移动、业务或测试人员的不同孤岛组成。你需要所有这些都有意义地进行，没有人可以做所有的事情。每个气泡或筒仓都应该有自己的冲刺目标吗?

我们从产品的角度来看。

从一个项目开始，项目和用户故事都不应该被孤岛隔开。他们不应该指定哪个仓可以完成这项工作。重要的是为 sprint 评审提供一个可交付部分——最终用户可用的东西。

如果团队经常无法在一个 sprint 中交付完整功能，要么是 backlog 项太大，要么是团队结构错误，要么是 sprint 太短。让孤岛合作来改进工作流程，永远不要将孤岛分配给顺序冲刺，让它们相互等待

积极主动，走出孤岛，从一开始就精诚合作，调整流程并尽可能实现自动化。

最后

当然，没有硬技能就不可能编码。无论您处于什么职位，合作、沟通或演说技巧等软技能将决定将项目推进何种成功程度。优秀的公司不会寻找能够胜任工作的人士，而是寻找能够提供附加值的人才。

合作，理解他人，永远追求最好!