技术管理 | 如何通过提案+评审取得团队共识?
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
TechLead 少个分号
扫码关注公众号
扫码阅读
手机扫码阅读
摘要
文章“少个分号”探讨了软件开发团队中常见的技术偏好导致的冲突,以及Tech Lead如何管理这些冲突。讨论了三种不同的团队治理模式——君主制、军阀制和民主制,并提出了一套基于提案和评审的流程来解决技术冲突。
治理模式
在君主制和军阀制团队中,领导拥有绝对权力,能够制定规则并解决冲突,但这可能会导致技术决策不够民主。与此相对,民主制团队中的Tech Lead需要利用影响力和经验来管理技术偏好问题。
冲突解决机制
为了解决技术冲突,作者建议通过提案和评审的方式来处理团队中的不同意见。这包括团队成员共同维护规范,实施提案改进,并对技术方案进行评审。这样的过程要求提出者提供实际可行的替代方案,并获得半数以上团队成员的支持。
评审机制的好处
提案+评审机制有助于避免成员间直接冲突,促进团队内不同声音的融合,确保提出的是可执行方案,并为重大决策提供决策记录,对未来的架构追溯具有重要帮助。
文章还提醒读者,如有内容错误,可以联系作者领取红包,并推荐读者关注更多技术管理相关内容。
TechLead 少个分号
TechLead 少个分号
扫码关注公众号
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
TechLead 少个分号的其他文章
系统设计 | OAuth2 的通俗解释和几个常见问题
OAuth2 不是一个很难的话题,但是我发现在很多场景下被反复讨论。
领域建模的原则(战术篇)
当团队规模非常大、系统极其复杂的时,我们就需要制定一些原则来评审、检查各个各个团队产出的模型是否合适。
建模和编程中的契约 —— Design By Contract
1. 业务是生意,不是功能也不是交互,人是生意的主体。\x0a2. 人是不可靠的,需要用契约来约束生活的方方面面。\x0a3. 把软件组装起来的连接点就是接口,接口也是契约。\x0a4. 开发软件是关于生意的生意,管理团队也需要契约。
周末杂谈 | 追不上热点,但想聊聊程序员的心理问题
本来不想追这种热点的,这篇文章纯粹是为了分享一下我个人的经历,因为这段经历从后面来看其实非常宝贵。
架构案例 | 如何设计服务边界?
文 | 付施威 (转载请注明出处)
关注公众号:DDD和??
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线