zoukankan      html  css  js  c++  java
  • 聚沙成塔--建设分享型团队

    聚沙成塔--建设分享型团队

    本文图片来自网络

    软件与团队

    程序员是知识的权威和信息的瓶颈 --《实例化需求》

    软件开发是一项团队活动,并且是一项真正的团队活动,很多人在阐述团队概念时喜欢用足球或篮球比赛来进行类比,尽管两者之间具有极大的相似性但是如果仔细分析就会发现不同。

    球赛团队其实是建立在具有若干极高水平(明星球员)球员的基础上,围绕这些球员产生战术,甚至于在特殊情况下,某个球星的发挥就可以帮助球队取得胜利。没有球星只有整体的球队虽然可能稳定地生存,却没法去争取更大的成功,因为缺乏超越整体水平的因子。

    软件开发则无法围绕某位明星程序员,因为这不是一场只有90分钟的比赛,而是场可能长达几周或几个月的活动,漫长的周期、庞大的工作量如果聚焦在某一个或几个程序员身上带来的问题不言而喻(健康,家庭等),并且增加了团队随时瘫痪的风险(伤病、离职或裁员)。如果非要给软件工程中团队在比赛中找到一个可以类比的影子,那么划船这项运动也许才更加合适,它要求参与者同进退,只要有成员的步调不一致,带来的后果就是整个团队的混乱。软件开发团队也是这样,团队的平均产出是衡量一个团队效能的标准,而不是某一位明星程序员的产出,如果不能为团队带来更大的收益,那个明星的贡献也就仅仅是干好了自己份内的工作而已,并没有太多值得称赞之处,因此软件开发团队一定会寻求使整个团队齐头并进,稳扎稳打的工作方法。

    虽然不会围绕明星,但软件开发其实围绕团队中的每个人,程序员一直是团队中的最关键因素和限制因素,经年累月的工作容易造就领域专家,更容易造就"独裁者"。很多团队人为地在程序员之间建造壁垒和沟壑,例如,“一个萝卜一个坑”式的工作分配或者“之前干啥现在也干啥”的工作分配,迫使程序员只能专注于负责工作的知识领域,由此带来的以下显然意见问题:

    • 团队协作离散
    • 知识孤岛
    • 重复地发明轮子

    更加糟糕的是这种看似合理的工作分配方法对于团队内部人员的成长造成了制约,过度依赖也导致了团队信心不足,以及团队内部缺乏信任,不敢将工作交付给其他人,当知识沟壑大到一定程度,他人也不会有信心来修改代码,从而导致了团队运作的恶性循环——看似只差一个任务就能完成,而永远无法交付(很可能负责这段代码的老兄生病住院了)!

    上面这些问题究其根本原因是团队成员变成了“知识黑洞”,而团队没有负责建立一种良性的知识循环机制,造成知识一旦进入某个结点(程序员)就如同进入黑洞一般(外面人的既不知道黑洞里面的,也不敢进入黑洞一探究竟),整个团队看似高手云集却只能各自为战。

    分享与汇聚

    软件是在头脑中创建的 -- 《程序员的思维修炼:开发认知潜能的九堂课》

    软件并不是在集成开发环境(IDE)或其他工具上设计出来的,它是在我们的大脑中想象和创造出来的。一个人对于软件设计的想法再丰富也只是一个人的想法,这样的想法不表达出来影响团队只会有两个结果,要么被自己认定不够成熟重回脑细胞要么被自己遗忘。

    知识循环系统的建立意味着团队变成为一个可以汇聚个人思想的有机主体,它可以接纳每个成员大脑中的想法,无论成熟与否。任何想法通过每一个团队成员的大脑知识循环,使得个体的思想在团队的大脑中汇聚、碰撞、升华和凝练,最终个体的思想不会再是原始的火花而是集体众人拾柴火焰高的火堆,由个体思想升级为集体智慧最显著的特点是个体对于思想的记忆时间和完备程度得到了增强,因此思想和概念是需要在团队中分享和交流的。

    分享帮助团队产生集体智慧,同时也帮助团队成员树立信心。对于个人成长,分享的过程是重新整理个人思路的过程,更重要的是通过讲述或者书写,可以体系化地发现知识的漏洞,加深个人对知识的理解,而从团队获得反馈则弥补个人考虑的片面性。通过交流、沟通与反馈,个人信心的增强同时带来了团队成员之间信任的加深,因为分享增强了对对方工作的理解和认知,既有了信心又有了知识的保障,团队可以更加顺畅地将工作流转起来,而不用担心各种各样的意外了。

    请牢记团队效能来源于:

    • 相信大众智慧是最佳方案
    • 相信充分参与是最佳执行力

    引导与激励

    授之以鱼不如授之以渔

    原理阐述总是简单的,一旦落地就需要团队中的每个人付诸行动。通过适当的引导和激励,遵循一些基本原则,可以让团队氛围改变得平缓而富有实效。

    • 轻松的气氛可以为分享增色,牢记团队分享不是培训或教导,而是一次让精神愉悦的沙龙;
    • 建议固定时间和地点,这样便于团队形成习惯;
    • 由谁来分享完全出于自愿的,分享的内容团队可以进行引导,例如:技术雷达,但不要强制规定;
    • 一旦决定分享就必须认真准备,因为分享是讲述你自己的经验而不是他人的,所以你必须对自己负责,当你认真起来,听你分享的人才能从你的分享中汲取并给予反馈;
    • 每次分享结束可以简单地提醒“下次谁来分享”,尽量让团队成员自荐;
    • 团队应当尽量让老员工分享基础,那样容易能吸引新员工参与,让新员工分享较难的内容,并让老员工辅助,这样容易发现知识体系中的缺漏;
    • 激发团队分享热情可以从树立一块分享墙开始,着重描述分享者和分享话题,例如一份历史分享记录和一份未来分享提醒,既能帮助团队成员了解分享信息,又可以对外展示团队建设的成果。
  • 相关阅读:
    HDU 2089 不要62
    HDU 5038 Grade(分级)
    FZU 2105 Digits Count(位数计算)
    FZU 2218 Simple String Problem(简单字符串问题)
    FZU 2221 RunningMan(跑男)
    FZU 2216 The Longest Straight(最长直道)
    FZU 2212 Super Mobile Charger(超级充电宝)
    FZU 2219 StarCraft(星际争霸)
    FZU 2213 Common Tangents(公切线)
    FZU 2215 Simple Polynomial Problem(简单多项式问题)
  • 原文地址:https://www.cnblogs.com/hxfirefox/p/4593480.html
Copyright © 2011-2022 走看看