技术管理 | 如何通过提案+评审取得团队共识?
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
TechLead 少个分号
扫码关注公众号
扫码阅读
手机扫码阅读
摘要
文章“少个分号”探讨了软件开发团队中常见的技术偏好导致的冲突,以及Tech Lead如何管理这些冲突。讨论了三种不同的团队治理模式——君主制、军阀制和民主制,并提出了一套基于提案和评审的流程来解决技术冲突。
治理模式
在君主制和军阀制团队中,领导拥有绝对权力,能够制定规则并解决冲突,但这可能会导致技术决策不够民主。与此相对,民主制团队中的Tech Lead需要利用影响力和经验来管理技术偏好问题。
冲突解决机制
为了解决技术冲突,作者建议通过提案和评审的方式来处理团队中的不同意见。这包括团队成员共同维护规范,实施提案改进,并对技术方案进行评审。这样的过程要求提出者提供实际可行的替代方案,并获得半数以上团队成员的支持。
评审机制的好处
提案+评审机制有助于避免成员间直接冲突,促进团队内不同声音的融合,确保提出的是可执行方案,并为重大决策提供决策记录,对未来的架构追溯具有重要帮助。
文章还提醒读者,如有内容错误,可以联系作者领取红包,并推荐读者关注更多技术管理相关内容。
TechLead 少个分号
TechLead 少个分号
扫码关注公众号
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
TechLead 少个分号的其他文章
系统设计 | 企业应用数据交换
如何解决企业应用之间数据交换问题?
自我提升 | 那些童年时期的错误教育
如果我们能认识到童年教育的影响,那么在对某些事情做出反应时,应该认识到这不是处于自然本能,而是来自幼年时期某些经历的影响。
技术管理 | 敏捷项目需要有人走在前面
让部分人提前进行技术方案设计、技术预研,力求在迭代启动后,\x26quot;大部队\x26quot; 所需要的准备条件都已具备。
理解 DDD:编程中的模型思维
业务设计上往往没有建立起特定的领域模型,这是我们架构腐化和软件开发困难的关键原因。**业务领域建立好的模型,并指导代码实践,这就是 ”编程思维“。** DDD 领域驱动设计就是解决这部分问题,与其叫领域驱动设计,不如叫做模型驱动设计。
系统设计 | 对象转换方案
如何轻松地转换和映射 Java 对象?
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线