公司只有内部的人才是好人。 同样，产品将达到人们允许的水平。 这是我学到的建立产品和培养团队的一些“团队精神”。
发挥团队知识
让技术人员解决技术问题。 让设计人员解决设计问题。 让商务人士解决业务问题。 这并不是说您不应该参与其中，提供意见，引导讨论，但是您不必雇用知识工作者来指示他们应该如何思考。 让您的团队使用和发展他们的知识-每个人都将从中受益。
为团队学习
了解团队成员的工作至关重要。 无论您的背景是什么，拥有全面的知识来补充您的团队技能，都可以使您同情并有效地与他们沟通。 让某人向自己解释3次会减慢工作速度，可能会让您既沮丧又被误解，并且您非常想废除此方法：
交流中最大的单一问题是它发生的幻觉。
萧伯纳（George Bernard Shaw）。
倡导团队
无论您是产品负责人/经理/其他，您的头衔是什么，如果您要管理即将投入使用的产品或在现有产品上进行迭代，则需要对该产品有一个愿景。 您必须在您的团队和组织的其他部门中了解这种愿景。 不仅要了解您的团队，还要对您的团队充满热情。 这种倡导正在进行中； 人类是健忘的生物。
保护团队
即使有倡导，在广泛的业务中也会有想法，时间表和更多的摩擦。 尽管您应该向团队描绘一种紧迫感，但不应因产品方向上的每一次兴致和改变而分散他们的注意力。 路线图计划或重新定义MVP的时间不是隔天的，因此您需要保护您的团队免受影响。 敏捷产品开发并不是要让您的团队在每隔一次迭代中就潜在地改变产品方向，从而使团队负担过重。
了解团队
我发现这种团队合作精神特别有趣。 它类似于“为团队学习”，但较少涉及技能，而是更多关于人性和行为。
我的一个见解来自保罗·格雷厄姆（Paul Graham）的“制造商时间表与经理时间表”的逻辑。 经理的日程安排大致分为1小时单元。 但是对于制造商（工程师/设计师），单位为半天，即每天2个单位。 上午召开会议，讨论制造商时间表，您已将一个制造商部门分解为两部分，它们通常太小而无法完成深入的知识工作。
您的大多数团队都将在Makers上工作-迎合这一需求。
另一本很棒的读物是Randall Koutnik的《实施者》，《求解器》和《发现者》。 有些人想通过预先定义的工作进行耕,，另一些人想解决问题，其他人想找到要解决的问题。 如果您仅提供预定义的工作，那么问题解决者会在其他地方寻找问题，或者会留下来，不高兴，而且成语也是如此：一个坏苹果会破坏桶。
告诉团队
与团队保持一致。 建立信任。 信任对于团队至关重要，而带领人们走上花园的小路，直到最终进入多岩石的山沟中，将恶化信任。 不要做出无法兑现的承诺，也不要告诉其他团队成员略有不同的故事。 同样，如果您不知道，请说“我不知道”，然后找出您需要返回答案的团队内容。
在某些时候，您将不得不告诉您的团队一些不理想的事情。 与不信任的团队相比，建立信任是一个更好的选择。
与团队一起庆祝
启动产品时，您通常可以计划或已经在构建下一个功能或下一个产品。 确保您花时间庆祝，既要团队合作，也要有更广泛的团队/公司。 这有很多好处，既可以得到团队的赞赏，也可以得到更广泛的公司的拥护，并且可以在精神上闭合循环。
您学习了哪些团队合作精神？
