srcmini本文概述
- 这是给谁的？
- 规则1：了解IT心态
- 规则2：请勿混用软件生产和软件开发方法
- 规则3：使用永久存储作为人类记忆的扩展
- 规则4：在正式时间估算上不要浪费时间
- 规则5：了解切换任务和杂耍优先级的成本
- 规则6：使用架构审查作为改善系统设计的一种方式
- 规则7：价值团队成员
- 规则8：关注团队合作组织
- 建立一个竞争性发展讲习班
在我的职业生涯中, 我参与了多个现实生活中的软件项目, 并观察了各个级别的事情：决策, 实践采用, 团队建设, 招聘, 技能分配等。显然, 不同的方法产生了不同的结果。作为一个以改进为导向的人, 我注意到并收集了最有效的实践和最佳实践技巧, 以帮助我开展工作。
从观察中学习是做到这一点的艰巨而漫长的方法。我将非常高兴能从书本中早点学到这些知识。不幸的是, 我没有找到关于该主题的信息。因此, 我决定与其他寻求此类知识的人分享我的经验。希望这可以节省他们几年的个人研究时间。
在本文中, 你将学习如何通过生产坚固而可靠的软件产品来战胜平均行业表现, 这些产品所需的维护量要少5-10倍。我可以毫不谦虚地说, 在过去的10到15年中, 我(个人和我的团队)超出了所有人的期望, 留下了许多成功的踪迹。经理们不能更快乐。
一旦我的团队在一个不可能的短时间内完成了一个重要项目, 我们就获得了高层管理人员的”高性能团队”奖。所有这一切都无需在夜晚和周末度过。正常工作。
你会看到, 有效的软件生产知识本身就是力量。实际上, 即使用通俗易懂的语言解释, 这也不是什么人能掌握的一种黑魔法。你将免费获得它。如果你想被视为软件生产魔术师, 请继续阅读。
这是给谁的？
让我在这里发表重要的, 重要的, 重要的免责声明。
我针对需要提高生产力的人员解决此问题。并非生活中的一切都与生产力有关。也不是所有的软件项目。在某些情况下, 你不能根据自己的表现来判断。显然, 这些做法将无济于事。
尽管高级软件开发人员也可以从中受益, 但是这些技术对于团队负责人, 架构师和项目经理将最有用。
规则1：了解IT心态
IT行业是科学, 技术, 艺术和商业的混合体。如果不足够好地理解这些方面, 很难导航到那里。最大的问题是该行业本身非常复杂。因此, 最佳做法也很复杂。你需要学习很多, 并通过大量实践来验证自己的知识, 才能成功。
令人难以置信的技术更新速度使其变得更加困难。十年前, 你不再需要任何知识。因此, 你需要加快学习速度。
综上所述, 我们可以说, 在IT领域取得成功不是基于先天的技能或感情, 而是基于实际的例子。永远不要”跟随肠子”或完全基于包括你在内的感觉来相信。
采纳新想法的最佳实践是验证某人之前曾经做过并且能奏效。
如果是的话, 这个想法值得考虑。否则, 需要就如何选择这条道路使你的团队生活变得更好的很好很好的解释。如果通过了此测试, 请安排一个轻量级的概念验证项目, 以通过实验证明它适合你的环境。
这里要了解的重要一点是, 没有对与错的解决方案, 因为有许多解决软件问题的方法。但是, 对解决方案有好有坏的理解。
如果一个人可以清楚地详细阐明想法或通过采用此解决方案与团队的成功建立联系, 以说服其他团队成员, 那么我们可以依靠这个人的愿景和希望获得成功的巨大机会。
规则2：请勿混用软件生产和软件开发方法
软件生产基于软件开发。但是, 这两个目标, 思路和做法完全不同。试图用另一个领域的方法解决这些领域中的一个问题会产生可笑的结果。重要的是要了解这些区别, 并对每个领域使用适当的方法。
软件开发是艺术与工艺的结合。无论那里有自动化工具和软件开发方法如何, 艺术品组件都将永远存在。因此, 解决开发任务需要最大的专注力并屏蔽所有其他干扰信号。
激励有经验的开发人员的最佳方法是以纯技术形式向他们提出一项任务, 其中不包括所有人为因素。所有要求也应以技术语言表达。他们应该易于验证, 以便在他们的单独研究阶段就可以朝目标前进。
相反, 软件生产更多地在业务管理领域。你从一侧知道客户的需求, 从另一侧知道你拥有的团队资源。因此, 现在你尝试引导团队努力实现目标。同时, 你还可以估算进度, 并向老板提出精通的计划。其中的重要技能是了解客户的愿望, 了解团队的优势以及传达正式的计划和时间表。
话虽这么说, 我想强调的是, 软件开发中的许多角色在这两个领域都发挥着作用, 在业务与技术之间架起了桥梁, 例如团队负责人, 架构师, 分析师和项目经理。扮演这些角色的人们应该能够轻松地在现实的两个层面之间走动, 并了解何时该谈生意, 何时该谈艺术。
规则3：使用永久存储作为人类记忆的扩展
人的记忆虽然容量惊人, 但有其局限性。你会以无法预测的准确性和持续时间来记住事情, 而当你忘记时, 就没有办法随意回忆它。
这就是为什么我们使用永久性内存存储以可预测的速度移动的原因。这与你在事后创建的供他人使用的正式文档(例如用户手册)无关。这是关于在工作期间将字面意义上用作文档的外部扩展, 以帮助你完成软件开发过程。
我建议你在遇到非平凡任务或涉及多个人的任务时, 一路记录下自己的想法和计划。尝试使其尽可能便宜。不要创建带有公司徽标的正式文档。一个不错的工具是在你的项目空间中的公司Wiki。为任务或问题创建专用页面(30秒)。然后, 每当你有想法或打算与他人讨论时, 对其进行更新。
暂时停下谈话, 并立即进行更新, 而你仍然对此念头犹豫。
在一次会议上, 说”等一下, 让我放下这个”, 并花10到30秒以书面形式表达出来。撰写的内容不应该广泛, 但应该完整且连贯, 就像你将创意整体转移到纸上一样。稍后, 你或其他任何阅读你的文章的人都应立即理解它。该技巧可以节省大量时间, 但可以让你即时记录文档。
该技术有两个目的。
首先, 它通过将其牢牢地压在石头上来锁定你的成功之路。不再存在有人忘记某件事, 一次又一次地重申同一件事或重新谈判已经谈判过的同一件事的风险。
其次, 你要清醒头脑, 放弃困扰你的问题。现在, 你的思维已迫于下一个挑战。多么提高生产力！
这适用于任何大小的项目或任务。对于较大的页面, 你将拥有较大的空间, 页面层次结构会随着项目的发展而逐渐增长。这里的重要概念是在开始建立快速内存转储协议的任务之前, 准备文档空间和结构！
对于喜欢技术类比的人们, 我将把自己的想法与具有强大处理能力但操作内存有限的处理器进行比较。你基本上可以一次考虑一件事。以此类推, 你的文档充当持久性存储, 而你的思想以迭代的方式解决了复杂的问题。在某个时候, 你决定开始下一次迭代, 阅读以前的文档, 并将当前状态加载到你的操作内存中, 考虑一会儿, 然后使用新发现更新代码和文档。逐步进行直至完成。
综上所述, 我不鼓励人们一次处理很多任务。相反, 任务越少越好。但是, 并没有很多人真正地优化了工作环境, 因此可能需要多任务处理, 并且你必须以某种方式进行处理。上面的技巧有助于更好地处理它。
规则4：在正式时间估算上不要浪费时间
没有两个项目是相同的。下次你执行类似的项目时, 你将拥有不同的客户, 不同的目标, 不同的团队；甚至不同的技术。即使使用标准工具和组件, 你仍然需要自定义其配置和体系结构。处理软件项目时, 请记住, 它们涉及的定制工作介于50％和100％之间。他们需要进行研究, 讨论, 思考, 试验和其他高度不可预测的活动。在实践中, 你可能会遇到表面上完全相同的项目类型和你之前完成的操作之间的巨大差异。通过扩展, 一个新的项目类型几乎是不可能精确估计的。
如果它是如此不可预测, 那么项目经理应该如何提出并遵守项目进度表呢？
文献中描述了一种执行此操作的正式方法。即, 将整个项目分成较小的步骤, 估计每个步骤需要多长时间, 然后通过合并各个部分的工作长度来计算项目总长度。在MBA课程中教授这种方法的背后有大量理论。
不幸的是, 尽管如此, 数学并不能保存它。众所周知, 这种方法是不准确的, 以至于它是完全不可用和不切实际的, 更不用说它是多么耗时了。我从来没有见过一个项目经理使用正式的计算方法而没有任何调整, 甚至没有方法论狂热者。即使公司严格规定使用这种方法也没有！实际上, 绩效最佳的经理使用完全不同的替代方法, 如下所述：
一个好的项目经理可以通过研究和观察许多过去的项目来调适自己的直觉。
一个好的项目经理要注意项目类型, 环境, 所涉及的资源, 组织类型以及所有其他影响实际项目时长的工作方面。当然, 没有人需要从错误中学习。这种观察可以直接或间接地完成。例如, 通过书籍或研究他人的项目, 甚至只是将知识的人传给他人。此类统计顶级知识可改善个人项目进度导航。
我想强调一下上述方法的两个重要结果。
首先, 估计精度会随着经验的提高而提高。一个经验不足的人, 无论采用什么强大的方法, 都不可能擅长于此。其次, 即使是最好的估计也仅从统计角度来看仍然是好的。也就是说, 可以说某个项目可能需要四个到十二个月的时间。假设这是正确的, 则应该理解项目在其八个月的平均时间内运行的可能性为50％。
了解统计预测具有如此令人难以置信的效果。明智的经理只会对这样的项目进行12个月的估算, 然后尽早完成就让所有人赞叹不已。换句话说, 没有人期望团队遵循项目进度。
给项目经理及其老板的一般建议是停止浪费时间在正式的时间估算方法上。相反, 鼓励收集有关项目期限的统计信息, 并在整个公司中共享此信息。我知道在整个公司范围内都采用这种方法的公司, 从而产生了惊人的预测精度。
规则5：了解切换任务和杂耍优先级的成本
人类的思维是自然界惊人地改造而成的。即使令人难以置信, 它也有其局限性。换句话说, 它旨在在特定领域和特定类型的任务中脱颖而出。
开发人员的思想绝对是软件开发中的一项重要资产。作为项目经理, 你是否有兴趣更好地理解它并将其置于性能最佳的位置？
让我们简单地说一下, 避免过多的理论。请记住, 在你需要从经验中学习(无论是你自己的还是他人的)之前, 理论只会带你走很远。
人脑具有强大的解决问题和产生想法的潜力。不幸的是, 并非总是可以利用这种潜力, 主要是因为要支持想法的产生, 你需要将所有问题同时存储在活动内存中。因此, 解决复杂问题的过程要经过简化阶段, 即将任务概括化或重新制定以削减不重要的部分并减少同时保留在内存中的元素数量。换句话说, 我们可以解决一个非常狭窄的复杂问题或多个简单问题。
该比率不是线性的。同时执行的操作数量增加会极大地影响你的解决问题的能力。这就是为什么人类一直雇用并将角色分离作为生活优化的原因。与两个人同时处理两个任务相比, 两个人分别处理两个任务将更快地取得突破。
人类思维的另一个重要特征是它无法像计算机一样在任务之间立即切换。确实, 你不能不停地随意思考。你也无法立即全速考虑新概念。空中交通管制人员可以很好地说明这种精神惯性。即使他们看着雷达并看到整个图片, 他们仍然需要将其加载到内存中以快速运行。新的操作员需要十分钟才能观看屏幕, 然后才能轮班更换旧的屏幕。
更糟糕的是, 我们不能随意忘记事情。我们所学到的一切都与我们在一起, 并且随着时间的流逝逐渐消失, 占用了我们可以用来获取新知识的空间。甚至更糟的是, 这种效果有时会伴随着”未完成的业务”的感觉。忘记已经完成的东西, 而将来你将永远不需要的东西, 要容易得多。而当你将事情搁置一旁以便稍后完成时, 你的大脑自然会抓住标记为”供将来参考”的信息, 而不愿让新知识取代它。
好的。现在, 我们已经概述了切换任务的想法, 让我们看看它在现实生活中(可以说)的思想实验是如何工作的。
想象一下, 你有十位常规开发人员从事十项常规任务, 每人一个任务。假设我们可以将它们封装在一个完美的无干扰的环境中, 那么每一个任务都可以由一个人在一定时间内完成。整个过程将花费完成最长的单个任务所需的时间。
现在, 让我们重复相同的心理实验。这次, 我们将无缘无故(重要)在开发人员之间不断切换任务分配。每天, 每个开发人员都会得到一项新任务来处理。更好的是, 我们每小时进行一次切换。你认为它们要多久才能完成？也许永远不会。
第一种情况下的项目经理能够有效地执行项目。第二个人设法”执行”了它, 肯定是……从某种意义上说, 它们促进了它的死亡。恭喜你这种杀死项目的技术特别有效, 因为除了浪费时间之外, 它还使员工的士气降至零。
当人们体验到这种”任务轮播”时, 他们会失去所有成就感, 并意识到该项目无济于事。
当这样的例子以纯粹的学术方式呈现给他们时, 大多数人都会同意上面的例子。然而, 在现实生活中, 他们在最小的压力下突然忘记了一切。大老板要求进度报告, 或者客户要询问某个功能的实施日期-几乎任何外部事件都可能使项目经理赶到团队并表达他们的关注, 随后又进行了一系列任务重新分配和优先级调整试图在这里和那里赢得一点时间, 最终除了使项目偏离轨道之外, 什么都没有。
不幸的是, 这是现实情况, 经常发生。
一个好的经理站起来, 通过吸收情感冲击波并将其转化为富有成效的未来讨论项目, 从而使团队免受此类轻微干扰。从情感上讲, 这绝对是很难的, 但这是保持团队良好工作节奏并让他们实现目标的唯一途径。
规则6：使用架构审查作为改善系统设计的一种方式
IT行业以过度设计和过度设计的理念运作。当接受采访时, 每个人都说过度设计是不好的。该问题很容易回答, 因为问题本身传达了”过度”的负面含义, 即”太多”。真正的实际知识是, 如何识别架构过度设计并在早期阶段避免这种情况。
让我给你一些我尝试过的, 真正的指针。
首先, 如果有另一个更简单的解决方案可以提供所有必需的功能, 则该解决方案可以算是过度设计。也就是说, 如果你不了解更简单的解决方案, 那么除非有人证明你做错了, 否则你所能提供的最简单的解决方案都是你眼中最好的解决方案。
如果我们虚构的架构师真正地致力于解决方案的完善, 那么通常的架构审查将保证它是最佳的。不幸的是, 架构审查至少需要其他一些合格的架构师。在许多情况下, 它具有无法使用或不切实际的危险。在没有同行评审的情况下, 架构师容易犯常见错误。让我们逐一审查它们, 并讨论每种方法的可能解决方法。
最受欢迎的错误之一是设计时没有考虑到业务目标。显然, 任何工作活动都应与最终用户的满意度, 公司的成功或类似的业务需求联系在一起。然而, 通常你会在不考虑此类目的的情况下看到全部或部分设计的体系结构。这种推理要么不存在, 要么归结为使用尽可能多的现代钟声和口哨声。
在这种情况下, 架构师不会执行消费者支付的费用。相反, 他们玩酷玩具是为了自己的乐趣和乐趣。这在正规行业中绝对不能接受。然而, 无论如何, 它似乎经常发生。
有时, 问题出在建筑师的个性以及他们对某些技术或工具的痴迷。他们只是喜欢使用它们, 而不能连贯地解释他们试图解决的业务需求。与此接近的另一种情况是, 人们除了用小块东西做东西以外一无所知。当然, 任何外部事件都会激发他们进入设计世界的渴望, 而永远不会回到真正的客户身上。即使最初的触发因素可能是有效的业务投入, 但他们长期与现实脱节会降低其作品的实用性。
解决方法很简单, 但是需要自律。优秀的建筑师切勿触摸笔和纸, 直到他们能清楚, 诚实地为自己回答为什么需要笔和纸。这样的需求可能以不同的形式出现。这可能是一个正式的要求, 对产品改进的隐式需求, 或者是新技术的出现, 这些技术使先前的设计效率降低。无论如何, 只要建筑师自己了解驱动力, 它就不应成为正式触发。然后, 他们可以将这种力量用作对其设计质量的最终验证。
另一个较难检测到的问题与块体系结构思维有关。有这种心态的人认为, 万事都有解决方案, 并且该解决方案始终作为构建模块来实施。换句话说, 它们将功能直接转换为组件, 而无需整体评估体系结构。当出现对功能的需求时, 他们可能只是将提供所需功能的组件连接到系统。在大多数情况下, 这满足形式要求, 但使系统处于不连贯的状态。并未基于开发, 支持甚至公司许可模式的现有系统兼容性来选择新功能块。因此, 团队尝试通过现有系统容量修改现有配置或实现此功能。结果, 系统支持和维护逐渐变成了噩梦, 紧接着性能下降。
对于这个问题, 没有简单的解决方案, 因为对系统进行工程设计是一门艺术, 并且永远无法预测是否必须添加或可以避免使用新组件。最佳实践可能是保持积压的维护和体系结构问题, 这些问题会随着时间的推移而累积, 然后定期审查整个系统体系结构。定期审查也可能会考虑新兴技术。因此, 体系结构审查的总体目的不应在于解决问题, 而在于评估预期的改进和整个系统的潜在可行性, 以应对迫在眉睫的过时的不可避免性。
规则7：价值团队成员
在采访中, 大多数IT行业专业人员都被问到他们是否是优秀的团队合作者, 或者他们是否在团队中表现良好。但是, 可能没有人在文学中看到明确的定义。显然, 这样的人通常会为团队的成功做出贡献, 但是很少有人能够真正定义出确保成功的独特个人品质。
我观察到许多人在不同级别上工作, 并看到他们的个人素质如何影响项目进度。我想提出以下有关团队合作中最有用的个人素质的建议。
沟通交流
当然, 最重要的是沟通能力。
想象一个人的沟通能力为零。当然, 没有收到团队成员的反馈会使他们完全无用。这是如此明显, 以至于在面试过程中没有人真正在衡量该技能, 这意味着只要人们能说得很好, 该技能就可以达到足够的水平。
交流不是二进制的是/否技能；它更多是一个信息传递窗口。范围越广, 信息交换越快, 越清晰。
沟通能力是该人拥有的所有其他技能的乘数。
由于该窗口的开放范围在整个人群中变化很大, 因此测量这种窗口的宽度是团队合作者的重要特征。请记住, 我们在此谈论的是传达信息, 而不是在畅所欲言或鼓励人们, 激励他们或通过交谈和沟通组织他们。
沟通方式也无关紧要。信息可以口头, 文字, 图片或混合方式传递。这个人可以说话快或慢。他们可以很友好, 就像一直注视着你的眼睛微笑着, 或者他们可以移开视线, 以单调的声音说话。风格可能会影响你对同事的个人看法, 但是只要你清楚地理解了他们的意思, 任何风格就足够了。
让我们进入检测和衡量沟通能力的实际案例。
一般而言, 沟通技巧有两个主要方面。首先是分享信息的意愿。有些人渴望分享, 而另一些人则试图隐藏信息。这种倾向或多或少是自然的, 但可以通过自我激励和训练慢慢改变。可以肯定地说, 显示一种信息共享意愿的人将来也会证明这一点。这就是为什么该特征有助于预测候选人在团队中的未来成功的原因。
在现实生活中, 试图隐藏信息的人很容易引起注意。他们通常会试图提供故意无用的信息, 而不是实际需要的信息。或者, 他们提出一些初步问题, 以使信息流向内转移, 并最大限度地减少对”需要知道”事件的回答。无论他们采取哪种策略, 最终都会感觉到你没有从他们那里获得所需的信息, 或者获得这些信息需要付出额外的精力。
了解意图很重要, 因为某些类型的开放人可能会问你一些初步问题, 以更好地理解你的问题, 然后以最方便的方式为你提供答案。打算隐瞒信息的人会问其他问题, 只是为了避免谈话, 而永远不会回答你的最初问题。
沟通技巧的另一部分是调谐到听众的能力。
不同的人对主题的理解程度不同, 沟通方式也不同, 甚至对特定细节的兴趣也可能不同。一些善于沟通的人会根据倾听者理解对话和准备答案的能力而改变他们的对话流程, 以传递特定的信息。在这样的准备中, 可能会要求一些初步的问题来缩小听众的兴趣。 “解决”沟通差异的能力确实是一项很棒的技能, 因为它使我们能够在几乎所有情况下达成共识。另一方面, 灵活的讲话者有时可能会陷入无法解决的误解的死胡同。
了解优势和劣势
让我们专注于团队成员必备的另一项个人素质。
大多数人会同意, 团队环境应该比周围的普通世界更加友好, 以促进协作和提高生产力。因此, 团队必须了解每个成员的强项和弱项, 以正确地分配任务并用长处弥补弱点。这条道路的第一步是让所有成员诚实地相互衡量自己的技能。从心理上讲, 这可能很困难, 因为我们自然倾向于将自己的弱点隐藏在别人面前, 保护自己。
这是友好的团队气氛为你提供帮助的地方。
建立信任是一项两人的工作。
因此, 新成员应遵守团队规则。不幸的是, 有些人即使在友好的环境中也无法降低警惕。他们一生都表现得像孤独的狼。这比他们强。可悲的是, 这种态度并不能促进团队合作。
有一种简单的技术可以在采访中识别出这些孤独的狼。他们从不承认自己一无所知。当然, 人们喜欢展现自己的最佳状态, 展示自己的全部能力, 并试图解决每一个难题。但是, 每个人都有一个知识极限。我们的极限决定着我们的技能。不承认限制意味着候选人将自己表现为万事通, 同样擅长一切, 一无所获。
当你聘请专家时, 你可能希望避免这样的人。此外, 这种傲慢的态度通常还带有另一个危险信号：不愿寻求帮助。寻求帮助的能力对于团队合作绝对必要。没有它, 我们将无法尽快发展。这样一个固执的人会消耗公司的资源和时间, 无限期地完成艰巨的任务, 但从不向队友求助。有一个简单的技巧可以在面试中检测出此类候选人。问他们一个没有道理的问题, 或者提及一些废话。一个正常的, 非常好奇的人会说他们不知道并问它是什么。即使你强调没有正确或错误的答案, 并且”我不知道”并没有使他们丧失资格, 防御者也永远不会这样做。
规则8：关注团队合作组织
关于团队合作组织的信息与上述任何以前的主题一样少。每个人都知道团队合作会更好, 但是如何建立和维护团队仍然是一个谜。但是, 即使不可能涵盖团队建设的所有方面, 我们也至少可以在这里探索一些关键的团队建设技术。
建筑专业知识
每个IT项目都是唯一的。为了成功实现这一目标, 需要学习和掌握具体项目。它们可能包括技术知识和非技术知识。非技术知识的示例可以是用于管理, 客户, 技术支持团队等的个人网络。特殊的技术知识是除一般IT技能之外的其他详细信息。
例如, 你可能需要了解Maven才能构建项目。但是, 确切的构建结构, 属性的位置和筛选仍然会因项目而异。与任何类型的知识一样, 掌握这些细节也需要时间。人们投入的时间越多, 他们的表现就越好。时间是你拥有的最宝贵的资源。你希望使你的团队成员尽可能长时间地专注于同一职能领域, 以利用他们的专业知识并进一步发展他们, 从而不断提高团队绩效。
不幸的是, 不可能无限期地这样做。从一方面来看, 人们可能会感到无聊。另一方面, 你正面临失去他们的专业知识的风险, 从而意外地使你的项目面临风险。
让我们看看是否有一些方法可以应对不利方面, 而又不会严重影响团队绩效。
大多数智力工作者是自然学习者。他们想学习一个特定的领域, 直到他们擅长。
在团队成员之间分配重点领域, 并让他们建立自己的专业知识。在某些时候, 它们达到了足够高的水平, 这在该项目的范围内是有意义的。在这一点上, 额外的学习努力不会显着改善它。没有动力和挑战, 聪明的人会变得无聊, 开始讨厌工作。
通过在其他地方为他们提供学习机会来防止这种情况。让他们了解项目和公司的技术堆栈, 并提出新的挑战。如果他们的兴趣在项目范围之内, 那么你将获得双重奖励, 即让你的团队不断挑战并同时扩展有用的团队技能。但是, 任何自我开发都可以避免无聊, 即使它不与眼前的项目需求相交。只要团队专家的大脑投入工作, 他们就会在脑海中不断支持已经学习的项目领域。
离开公司时, 团队专家会带走很大一部分专业知识。你可以使用的对策之一是广泛分发可以即时更新的文档。想一下前面提到的”持久性内存存储”。
尽管如此, 项目经理还是希望在团队成员的头上复制知识。一个简单的解决方案是让每位专家拥有两名专家, 尽管费用是后者的两倍。但是有一种更精简的方法。诀窍是让大多数开发人员在多个领域发展专业知识, 以便每个项目方面都至少由一名资深专家来解决。同时, 选择了一些高级成员来扩大其专业知识的广度。通常, 此角色最好由团队开发负责人或架构师来扮演。团队负责人与所有团队成员互动, 并参与所有任务实施。他们可以利用项目的每个方面, 了解其所有内部。这样, 即使你失去了一位专家, 领导者也可以接管并继续进行项目, 直到你可以雇用和培训替代人员为止。
同样想法的另一种形式是对相邻区域的开发人员进行交叉培训, 让他们观察, 学习并偶尔尝试同行的工作。请记住, 这种交叉培训不需要进行广泛的培训, 因此不会破坏对开发人员主要任务的关注, 也不会影响生产率。在领导力和交叉培训的开发人员中发展专业知识, 可以为你防范意外生命的罪魁祸首, 并为你腾出一些时间来利用项目资源。
减少干扰
软件开发是一系列复杂而富有创造性的问题解决方案。即使随着行业的发展, 这些复杂的问题变得越来越自动化, 工作并没有变得更加容易。它仍然涉及大量的艺术和个人见解, 这很难预测, 有时甚至更难以解决。
开发人员是武器的优势。它们的集中度等于武器尖端的硬度。增加他们的注意力, 你会解决一些问题, 例如用热刀切黄油。分散他们的注意力, 你最终会用钝棍笨拙地戳黄油。
这不能过分强调：可以通过动力或额外的努力来加强非问题解决工作。对于解决问题的工作, 你需要最大限度地脱离平凡的世界。很难将所有日常问题抛在脑后, 一个好的项目经理应该在身心上建立一个安静的开发环境。开发人员的工作场所应类似于感官剥夺坦克。
从物理上讲, 这被实现为封闭的工作空间。每个团队成员都应该至少在一个立方体中可以独处。最好避免大声喧and和过道交谈。应通过电子邮件和聊天保持快速的人际沟通。大型团体应在会议中使用封闭的房间, 以免分散他人的注意力。这是过去办公室生活的相当标准的图片。
不幸的是, 即使在大型办公室中, 开放空间范例也越来越被广泛采用。我警告他不要一时。更糟糕的是, 加上开放空间, 高层管理人员鼓励就地团队对话。从本质上讲, 就是在不参与进来的团队成员的头上向另一排人大喊。一天被二十次大声交谈打断的开发人员再也不会失去专注力了。当然是主要的性能杀手。
允许学习曲线
知识本身就是力量。对于像IT这样的复杂行业来说尤其如此。这里的每个任务都有其定期的周期：学习, 研究, 实施。学习阶段尤其宝贵。更好的理解不仅可以更好, 更快地实施, 而且还必须通过某些知识门槛才能实现目标。当然, 过度学习也没有意义。每个技能都应该与生产需求相匹配, 而不是超出需求。
但是, 开发人员常常面临相反的压力。停止学习, 无所作为。学习被认为是浪费精力, 因为它不会移动任务进度条。坐在家里阅读本文, 这似乎是一个很容易解决的问题。然而在现实生活中, 最小的工作压力却使每个经理变成了要求苛刻的白痴, 他坚持认为每个人”都必须停止学习并开始做某事”。我发誓, 我在整个职业生涯中听到过很多确切的话……一个好的经理和团队领导者应该理解, 学习是过程的重要组成部分, 即使它不会直接增加进度条。
建立一个竞争性发展讲习班
上面介绍的提示和技巧是有效的软件生产专业知识的子集。通过在现实生活中理解和应用它们, 你将逐步提高生产效率。如果你认为它们在很大程度上没有联系并且缺乏理论基础, 那么你绝对正确。
我想强调指出, 建立一个具有竞争力的发展讲习班不是一项单一的任务。它需要多个相邻领域的知识和专业知识。建立这样的专业知识是一项艰苦的工作。没有单一的理论基础或思想可以立即解决你的所有问题。相信这样的灵丹妙药只会使你偏离真正的目标。
在工作中尝试这些技巧, 看看它们是否值得永久采用。如果你发现它们有用(或没有), 请在下面发表评论并分享你的经验！
评论前必须登录！
注册