编程与计划[关闭]

最近，由于团队的主要开发人员离职，我被要求承担更多的高层计划任务。我讨厌长期计划。我的大脑似乎并不自然地对此感兴趣，并且我对它没有足够的兴趣来花时间学习它（很难跟上图片的编程方面）。

如果没有高级计划者，还能成为一名优秀的程序员吗？

作为高级程序员，是否有人会擅长计划整个产品并选择完成日期？

详细的长期项目计划通常因极其不准确而臭名昭著。该系统的功能不可避免地会在发布前发生变化，人们通常花很长时间来制定规范中的细节，只是让利益相关者最多能粗略浏览一下。

您应该阅读有关敏捷计划的更多信息，您可能会发现它更适合您的心态。许多敏捷方法论试图找到摆脱详细的长期计划的方法。

敏捷方法试图尽量减少详细的技术规范和文档，以支持自记录代码，孤立的原子用户故事以及最终的工作软件。在高效的敏捷团队中，将花费最少的时间进行计划。

阅读《敏捷宣言》，并研究Scrum。使用迭代开发和动态系统开发方法来指导项目。

敏捷方法的主要缺点是，您必须公开承认您不知道项目的确切范围，而让管理层认同这一想法可能非常困难，通常需要一段时间。有关此方面的一些提示，请参见此问题和解答以及此帖子。

但是，可以肯定的是，随着您成为一名更高级的程序员，您可能会减少编码工作，但是我认为，在敏捷团队中，不是意味着您编写更多的技术规范，而是要花费更多的时间进行管理和辅导您团队中的成员并制定有关代码的架构决策。

对的，这是可能的。但是，如果您想成为一名优秀的软件工程师或软件架构师，那么高级计划就可以发挥作用。对我而言，程序员和工程师之间的主要区别在于查看全局的能力。

有可能成为一个好的程序员而不是一个高级规划师吗？

有一段时间，是的。可以长期这样做吗？没有。

如今，对于许多雇主而言，降低生活成本来提高行业竞争力是一种标准的操作程序。如果您没有提高自己的能力，不要尝试解决更大更难的问题，那些具有行业竞争力的加薪将使您在五到十年内被淘汰出市场。坚持下去，您的雇主最终将开始寻找摆脱您的原因，并且您在其他地方的就业能力也将大大降低。

当然，从程序员的角度来看，您可以成为一名优秀的程序员。从管理层的角度来看，还有另一个问题。以我的经验，参与计划过程是1）获得更多有趣的编程任务和2）以所需方式完成任务的最佳方法。

换句话说，一旦制定了短期计划，许多选择就将浮出水面。如果您首选的解决方案将花费六周时间，但他们只预算了两周，那么您就可以坚持他们的决定。如果您担心他们在长期计划中已经讨论过的问题，那么他们就不想重新进行讨论。

如果您对这种状况感到满意，那么您将获得更多权力。大多数人对获得更多的体验感到不满意。

肮脏的小秘诀是没人擅长长期计划和评估。更好的计划者是意识到自己的局限性的人，所以不管您相信与否，您都处于领先地位。获得一些有关估计估计不确定性的训练。查看诸如基于证据的计划或Scrum之类的技术，这些技术依赖于历史数据来显示估计的准确性。如果您在工作中拥有更大的发言权，那么从长远来看，您会更加幸福。

有可能成为一个好的程序员而不是一个高级规划师吗？

简短的回答：是的，这是可能的。

但是，您对所涉及的项目类型有更多的了解，就会有更好的计划构想。理想情况下，作为程序员，我们有一些解决问题的方法，或者我们寻找一种方法。因此，如果我们知道方法，那么我们可以开始考虑计划了：)

另一种可能的途径是，成为优秀计划者的程序员最终也将走向项目管理。因此，如果您对项目管理感兴趣，则可以朝该方向付出一些额外的努力。

是和否是您的答案。

一方面，您正被推向项目管理。IMO，所有好的程序员都具有一定程度的项目管理能力，但是他们是不同的技能。长期计划的能力提高了您与实际项目管理人员沟通的能力。因此，“不”如果没有长期计划的能力，就不能成为一名优秀的程序员。

话虽这么说，项目管理是一种不同的技能，可吸引与编程相关但又不同的方面。这就是“是”的作用所在。您不必成为项目经理就可以成为出色的程序员。

对于您的特定情况，请尝试使公司变得更客观，以及公司喜欢做什么。您的问题反映出太多的自我，这使您无法看待这种情况。如果您在继续做自己喜欢做的​​事情的同时找到了为雇主做出更多贡献的方法，那么您应该考虑这些问题，并与老板讨论此事。

规划与邦吉老板

迪尔伯特（Dilbert）关于邦吉老板有很多条条。我们对计划的挑战和期望可能既是领导能力的成因，也是结果。我在《财富》 100强公司的经验是，一年之内，所有以项目负责人身份开始这一年的人都退出了。也许这是由于计划问题。不知道您的前任领导是否由于这个原因离职，但是当您的职位要求您制定有承诺的计划时，如果该计划未能兑现，通常会导致与最后期限相关的退出。

规划的组织环境

如果您对计划感到不舒服，也许您不愿意在记录或理解要解决的问题之前对对市场或其他利益相关者的承诺负责。这是一个很好的本能。

规划是重要的工具。不要忽略它。不要误会它。

计划与承诺，问责制和谈判能力紧密相连。敏捷计划有很多优点。您应该了解其技术以及计划方法学的技术。您的组织可能有自己的方法，并且获得建议并与在许多项目中幸免于难的人一起工作可能会产生令人惊讶的帮助。

一个简单的计划示例-不得与软件有关...

如果一家屋顶公司来我家竞标替换，如果他们出价太低，他们可能会在工作中赔钱，但是如果出价太高，他们将根本无法获得这份工作。无论哪种方式，它们都将倒闭。在您担任新职位时，如果您的职位太低，您将运行项目直到问责制开始，然后您就会遇到问题。如果您估计一个项目有足够的填充量以确保在截止日期之前成功，那么他们中的许多人只会选择其他人来领导。更重要的是，您不像屋顶工。他可以看到屋顶有多大，并具有有关屋顶需要多长时间的历史数据。

成为更好的计划者

您可能希望考虑某种培训。在敏捷方法论和最新计划的方法论中，估计是一个团队范围的活动。因此，您也应该考虑为您的团队提供培训。

根据经验，我可以告诉您，推迟将要推迟的团队成员做出估计，让他们根据任务名称在两分钟内做出估计而没有参考要求或功能描述或现有代码，可能会令人沮丧。他们坚持说，您列出的几个任务可以在一天的一小部分时间内完成，即使过去的项目在类似问题上花费了数周的时间。

有各种各样的项目经理培训课程和认证，但我会注意其中一项获得独立认证的课程。如果您希望与敏捷团队合作（或反之），在选择使用基于计划方法的方法进行认证之前，可能需要重新考虑。

SLIM是Putnam在1970年代在GE和其他公司从事国防部项目后发明的一种方法。SLIM具有影响力，他的公司QSM提供的认证似乎从他们制造的工具中流失了。根据您的公司是否采用他们的工具，它可能没有价值，也可能没有价值。

Steve McConnell（《代码完成》的作者）还写了一本有关软件评估的书，他的公司Construx教授了PDU学分的两个类，这些学分是通过项目管理协会认可的。我有他的书，如果我想通过课堂培训来学习这个主题，我可能会选择Construx。他们还进行Scrum培训，并管理通过Scrum.org认可的各种Scrum评估。

可以提供有关软件项目估算的出色学术训练的另一个来源是USC的Barry Boehm的小组，基于他们在COCOMO和COSYSMO建设性成本建模方面的广泛工作，该工作已在NASA和其他大型承包商中用于估计非常大的项目。我不确定我是否真正相信COCOMO，但我喜欢他们为将规模和成本驱动因素对进度持续时间的影响进行关联所做的经验性工作。

我还从 O'Reilly出版的教科书中找到一章，其中简要讨论了主要的软件评估方法，包括Watts Humphreys PROBE和Kent Beck的计划游戏。PROBE包含一个概念，工程师可以跟踪自己的生产率指标，然后将其应用于新项目的指定部分。规划游戏在开发人员和其他利益相关者之间是高度协作的。