软件开发中需要避免的6个错误

作者: 江苏久北万网络科技有限公司 浏览:185 时间:2017年04月08日

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

我们经常解决无法预见的问题,如果你不犯这些常见的软件开发错误,许多问题是可以避免的。我将引导大家解决错误,这些错误可能会破坏自己的辛勤工作并使有前途的项目白白失败!
软件开发
作为开发人员、分析师、产品负责人、主管或 CTO,我遇到过这些所有问题,尽管有些看起来很基础,但它们仍然会伤害你的团队。请与我深入了解~

不了解产品

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

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

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

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

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

假设即事实

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

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

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

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

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

缺乏沟通

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

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

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

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

关键要点是什么?

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

商业与技术语言的障碍

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

技术人员用技术术语,业务人员不明白;

技术人员希望业务人员做出技术决策,但业务人员不知道如何做出决定,因为他们不了解技术观点;

商务人士用商业术语,技术人员不明白;

业务人员试图在不理解的情况下使用技术术语;

在商业和技术中使用不同含义的相同词汇。

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

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

错误 404:未找到上下文

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

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

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

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

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

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

团队内部孤岛

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

我们从产品的角度来看。

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

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

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

最后

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

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


本文来自网络,如有侵权联系客服删除!

相关推荐

行业解决方案

服务热线 17312121964

  • 项目咨询

  • 方案报价

  • 行业解决方案咨询

江苏久北万网络

0.061985s