扫码阅读
手机扫码阅读
技术管理 | 如何通过提案+评审取得团队共识?
64 2024-08-27
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
文章来源:
TechLead 少个分号
扫码关注公众号
摘要
文章“少个分号”探讨了软件开发团队中常见的技术偏好导致的冲突,以及Tech Lead如何管理这些冲突。讨论了三种不同的团队治理模式——君主制、军阀制和民主制,并提出了一套基于提案和评审的流程来解决技术冲突。
治理模式
在君主制和军阀制团队中,领导拥有绝对权力,能够制定规则并解决冲突,但这可能会导致技术决策不够民主。与此相对,民主制团队中的Tech Lead需要利用影响力和经验来管理技术偏好问题。
冲突解决机制
为了解决技术冲突,作者建议通过提案和评审的方式来处理团队中的不同意见。这包括团队成员共同维护规范,实施提案改进,并对技术方案进行评审。这样的过程要求提出者提供实际可行的替代方案,并获得半数以上团队成员的支持。
评审机制的好处
提案+评审机制有助于避免成员间直接冲突,促进团队内不同声音的融合,确保提出的是可执行方案,并为重大决策提供决策记录,对未来的架构追溯具有重要帮助。
文章还提醒读者,如有内容错误,可以联系作者领取红包,并推荐读者关注更多技术管理相关内容。
想要了解更多内容?
文章来源:
TechLead 少个分号
扫码关注公众号
TechLead 少个分号的其他文章
分布式事务场景、概念和方案整理(含概念图)
从场景和问题出发,讨论分布式事务的实现思路,并对业界常见的概念进行了辨析,用于指导分布式事务方案选择。
为什么 DDD 又火了起来?
比如在分布式系统当中,我们必须要考虑到事务的问题、性能的问题,还有数据查询等等各种各样在单体世界里面不需要考虑的问题,因此对我们的模型创建又提出了更高的要求和挑战。人们选择了 DDD 来 “一本正经” 的建模,而不敢再 “拍脑袋”。
DDD 中的多对多关系建模
多对多关系是软件建模中比较的麻烦的场景,如果梳理不清楚对软件架构伤害很大。在不久前的一个项目中,十足的体验了一次多对多关系带来的痛苦。
系统设计 | 解决困难问题的思路
我们想要得到什么,就要先想想什么可以失去。
专注编码,一次只做一件事
如果专注做一件事情,很容易进入一种类似禅定的忘我状态,这种状态被有些人叫做 “心流”。进入这种状态,可以获得极大的效率。\x0a\x0a这种状态不仅可以获得较高生产力,还可以让内心充盈、满足的愉悦感。
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设
白皮书上线