我是一位非常年轻的软件工程师/ QA团队负责人。我从事软件开发大约2年了，在其中的1年中，我还担任过软件开发公司质量检查小组的负责人。目前，我仍然是质量检查工具的质量检查小组负责人/软件工程师。最近，我受邀加入一群想创办一家软件公司的朋友和同事。他们希望我成为软件的架构师/技术负责人(我只能说用Java编写的特殊聊天客户端)。我非常善于学习，并且从中学到很多东西。但是，我担心我的经验不足会导致项目失败(或者至少开发不佳)。因此，我想知道我们是否建议我担任该职位，尽我所能，随心所欲地学习？还是我们会建议我拒绝？

如果我们建议我担任该职位，请提供一个或者一个适合于Java初学者的资源吗？

解决方案

• 努力成为房间里最笨的家伙。
• 如果它使我们因恐惧而生病，那就去做。如果它使我们感到恐惧，请逃之.。

我们应该向新团队表达想法。我会说，我们对此持开放态度是一大优势。尽力而为，保持专注体验并不是一切，尤其是当我们意识到自己的缺点时！

神话人物月刊和Peopleware是我们需要阅读的两本书。

我不会告诉你要不要做，但是...

我会告诉你，如果你想真正提高自己的技能并发展自己的职业，就必须冒险并偶尔离开舒适区。

同样，作为开发人员，尽管我们对项目/时间表的乐观程度更高，但我们对自己的技能/能力也常常持悲观态度，并专注于我们不知道而不是做的事情。

如有疑问，我们需要与潜在的业务合作伙伴进行讨论。

既然我们在同一句子中使用了Java和Architect一词，那么我可以建议SCEA认证中使用的学习材料吗？特别是，我发现Core J2EE Patterns对于思考更大的架构问题确实是很有帮助的书。

与小组中的其他所有人保持开放，并确保每个人都意识到风险并了解"最坏情况"。我们还需要对在项目整个过程中投入的所有额外时间感到满意，从技术上讲，这是最快的。

还问自己，如果项目确实失败，我们是否可以在财务上做到这一点。

如果每个人都还在，那听起来像是一次很好的学习经历！

作为跳槽成为一家小公司的架构师的人，我认为以下几点可能会有所帮助：

• 我们知道的比我们想的要多。仅仅因为我们以前从未当过建筑师，并不意味着我们不知道要成为一名建筑师。
• 作为一名架构师，我们始终需要学习并紧贴趋势和技术。准备这样做。
• 听。团队成员将有很好的主意，可以挑战所有偏见。
• 尤其是在小型公司中，我们将必须意识到架构师角色中的政治因素。我不够了解，因此被烧死了。这可能会影响友谊。
• 小公司可能会迅速陷入困境。为此做计划，没有财务承诺，这意味着我们短期内不能失业。

我不太担心成为公司倒闭的潜在原因。提前关注问题，但要通过学习的能力(和愿望)来减轻它。

我们应该自己来审查公司创始人的融资和业务安排。我会说公司倒闭的可能性更大，原因是"业务"原因，而不是技术原因。

如果我们可以在不放弃工作的情况下加入小组，那就太好了。但是，如果我们必须选择要走的路和要走的路，则只有我们可以做出决定。跟随你的心，你将永远不会迷路。

作为团队负责人，我们最重要的资产不是经验，而是我们与之合作的团队。如果我们认识并信任这些人，或者我们可以雇用自己的团队，那么一定要努力。如果我们打算进行任何招聘，请先阅读一本有关良好招聘的书(Joel on Software对此有很好的介绍)。

我们在Stack Overflow上询问它，因此至少我们对此有正确的态度。在需要时寻求帮助。不要通过不谈论问题来过度补偿经验不足。仅仅因为我们不知道问题的答案并不意味着经验丰富的经理也会有。在门口检查自己的自我并完成工作。无论如何，我们将得到更多的尊重。

如果我们要进入一个根深蒂固的团队，而这个团队本身就遇到问题和问题，那么当一名经验丰富的经理真的很有用。对我来说，这听起来像是一个绝佳的机会。如果没有管理，我们将永远不会成为经理。

根据我们到目前为止的发言，该项目将失败。哎呀，大多数新项目失败了。如果我们对此表示满意，那就去做吧！对于我们来说，这将是一个很好的学习体验：)请确保我们不会失去亲密的朋友。

关于软件体系结构，没有太多有用的独立资源。过滤掉供应商营销和手摇的象牙塔东西之后，实用建议似乎很少了。

一个不错的选择是Coding the Architecture，它专注于动手实践，并且为开发人员向架构师的过渡提供了大量信息(我已经以很小的方式参与了全部披露)。

此外，关于建筑博客也有一个类似的问题，其中有一些很好的答案。

多年来，我发现Craig Larman的有关迭代软件开发的书确实很有用。

作为团队负责人，我们需要善于从团队中获取最大的收益，并且需要自己学习。通过将自己的技能提高100％，可以将团队的生产率提高10％。通过将团队的生产力提高100％，我们当然可以将其提高.. 100％。

我们对朋友创业的价值不仅仅在于我们纯粹的编码技能，还在于他们了解并信任我们作为合作伙伴。显然对他们来说，他们觉得我们可以贡献一些真正的价值，所以我的建议是我们"伪造它，直到实现"：