Šiek tiek mažiau pokalbių

Kada buvo paskutinį kartą suplanavote susitikimą ir pakvietėte aštuonis žmones, o ne tris žmones, kuriems tikrai reikėjo būti vien dėl to, kad nenorėjote, jog kas nors jaustųsi paliktas?

Kada paskutinį kartą išsiuntėte įmonės mastu el. Laišką, kuriame buvo parašyta: „Ei, dėmesio kavos gėrėjai: jei baigsite puodą, pagaminkite dar vieną!“ nors iš tikrųjų yra tik vienas asmuo, kuris pažeidžia šią taisyklę (ir ji yra jūsų bendraįkūrėja)?

Kada paskutinį kartą įsitraukėte į ilgą diskusiją dėl naujos brošiūros spalvų paletės su programuotoju, kuris neturi nieko bendro su brošiūra, bet tikrai žino, kad nemėgsta oranžinės spalvos?

Tai yra bendros ligos simptomai: per daug bendravimo .

Dabar visi žinome, kad bendravimas yra labai svarbus ir kad daugybė organizacinių problemų kyla dėl nesugebėjimo bendrauti. Daugelis žmonių bando išspręsti šią problemą didindami bendravimo kiekį: siunčia visus el. Paštu, rengia ilgus susitikimus ir kviečia visus darbuotojus ir prašo visų dviejų centų prieš įgyvendinant sprendimą.

Tačiau ryšių išlaidos padidėja greičiau, nei jūs manote, ypač didesnėse komandose. Tai, kas anksčiau dirbo su trimis žmonėmis garaže, visi kalbėjo apie viską, tiesiog neveikia, kai jūsų galvų skaičius pasiekia 10 ar 20 žmonių. Visi, kuriems nereikia dalyvauti tame susitikime, žudo produktyvumą. Visi, kuriems nereikia skaityti to el. Pašto, yra išsiblaškę. Tam tikru metu perdėtas bendravimas tiesiog nėra efektyvus.

Tai ypač klastinga greitai augančių pradedančiųjų įmonių problema. Kai tu esi tikrai mažas ir tu tik pradedi, tu neturi tiek daug žmonių, todėl, kad visi laikytumiesi visko, tikrai nereikia tiek daug laiko. Tačiau didėjant žmonių, galinčių dalyvauti bet kurioje konkrečioje diskusijoje, skaičius didėja, o dirbant daugėja dalykų, kuriuos atliekate kaip įmonė, o laikas, kurį galite sugaišti per daug bendraudami, tampa rimta problema.

Kai įmonės plečiasi, jose esantys žmonės pradeda specializuotis. Tokiu metu kai kurie vadybininkai priims išvadą, kad jiems iškyla problema „išlaikyti visus tame pačiame puslapyje“. Tačiau dažnai tai, ką jie iš tikrųjų turi, yra „sustabdyti žmonių kišimąsi, kai jau yra pakankamai protingų žmonių, sprendžiančių kažką“.

kokios rasės laimi Džoana

Nėra taip, kad buhalterijoje dirbantis Bobas neturi nieko naudingo pasakyti apie naujos reklamos kampanijos fotografiją. Taip, Bobas turi dailės magistro laipsnį. Taip, Bobas yra fotografas mėgėjas. Ir galbūt jis netgi turi geresnį skonį nei rinkodaros žmonės. Vis dėlto Bobas neturėtų sakyti rinkodaros vadybininkui, ką daryti, nes tai tiesiog nėra efektyvu. Tiesą sakant, tai labai neefektyvu.

Organizacijų per daug bendravimo išlaidas Fredas Brooksas patikslino savo 1975 m. Mitinis žmogaus mėnuo . Brooksas padėjo vykdyti OS / 360 projektą IBM, sukurdamas milžinišką įmonės pagrindinių kompiuterių operacinę sistemą. Tais laikais kompiuteriai buvo didelės, kambario dydžio, aušinamos vandeniu mašinos, kartais turinčios didžiulę 256 000 baitų pagrindinę atmintį. „OS / 360“ buvo bene didžiausias kada nors bandytas programinės įrangos projektas. Ir buvo monumentaliai vėlai.

Kiekvieną kartą, kai kuris nors projekto aspektas atsilikdavo nuo grafiko, IBM paskyrė dar keletą žmonių. Brooksas pastebėjo, kas vis dar stebina žmones, kad tai neveikė. Jo pastebėjimas buvo žinomas kaip Brookso įstatymas: įtraukus žmones į vėlyvą projektą, jis būna įgyvendinamas vėliau.

Perskaitykite šį sakinį dar kartą, nes jis nėra intuityvus. Brooksas atrado, kad įtraukus žmones į projektą tai bus naudinga toliau atsilieka nuo grafiko .

Kaip tai gali būti? Na, kai jūs įtraukiate naują asmenį į komandą, tas žmogus turi bendrauti ir derintis su visais kitais komandos žmonėmis. Tai neatrodo didelė problema, bet taip yra. Naujas vaikas nežino, kas vyksta, todėl kažkas kitas komandos narys - kažkas, kas tik praėjusią savaitę dirbo produktyvų darbą, turi nutraukti savo darbą ir parodyti šiam naujokui virves.

Kuo didesnė komanda, tuo blogiau. Kai turite vieno asmens komandą, jums nereikia jokių bendravimo reikalavimų. Nė vienas.

Pridėkite antrą asmenį, ir dabar jūs turite vieną ryšį: Adomas ir Marija turi kalbėtis tarpusavyje.

Charleso Stenlio grynoji vertė 2016 m

Dabar pridėkite trečią asmenį, tarkime, Srinivą, ir staiga mes perėjome nuo vieno ryšio prie trijų, nes Srinivas turi kalbėtis su Adomu ir Marija.

Pridėkite ketvirtą asmenį. Čia trūksta vardų, kurie man padėtų - Gerai: Britney. Jei mes ją pridėsime ir jai reikės derintis su visais, gausite šešis ryšius.

Matematiškai linkusiems žmonėms formulė yra tokia: jei jūsų komandoje yra n žmonių, jų yra (n^du-n) / 2 jungtys. Ši diagrama parodo, kaip tai tampa problema:

Kaip matote, komunikacijos išlaidos pradeda augti gana greitai, kol didelėse komandose viskas, ko kada nors turi laiko, yra derinti veiksmus su visais kitais - ir niekas neatlieka jokio darbo. 2006 m. Moishe Lettvin, buvęs „Microsoft“ programuotojas, parašė tinklaraščio įrašą, kuriame aprašė metus, kuriuos jis praleido derindamas elementų, kurie bus rodomi viename „Windows Vista“ meniu - meniu, kurį naudojate kompiuteriui išjungti, sąrašą. (Matyti „Windows Shutdown Crapfest“ .) Lettvinas suprato, kad 43 žmonės visi turėjo balsą kurdami šį vieną meniu. 43! Brookso formulė reiškia 903 ryšių valdymą. Lettvinas sako, kad tiek laiko praleido koordinavimo užduotims atlikti, kad per 12 mėnesių sukūrė mažiau nei 200 kodo eilučių.

Kaip viršininkas, turite susikurti būdus, kaip sumažinti ryšių kelius. Pašalinkite visos įmonės adresų sąrašus - arba bent jau sumokėkite 1,50 USD, jei norite už juos paskelbti. Nustokite rengti didelius susitikimus. Jums reikia kultūros, kurioje žmonės nesijaudina, nes nebuvo įtraukti į susitikimą, o tai reiškia, kad jums reikia kultūros, kuri apdovanotų žmones už jų darbą ir susirauktų kišdamasi į kitų žmonių darbus.

Kiekviename projekte paskirkite po vieną asmenį, kad įsitikintumėte, jog komunikacija vyksta, bet tik teisingai. Priešingu atveju komanda tiesiog pradės ilgus susitikimus su visais ten esančiais žmonėmis ir, tiesą sakant, žmonės bendraus, blovieduos, kalbės ir ginčysis dėl dalykų, kurie jiems nelabai rūpi, kad tik išgirstų savo balsus.

Manau, kad tai tikriausiai yra vienas iš tų atvejų, kai senasis, 1950-ųjų valdymo stilius netyčia kažką sutvarkė. Tose „General Motors“ stiliaus įmonėse jie bent jau sumanė, kaip informacija reikalinga norint judėti aukštyn ir žemyn tvarkingose, pulkų turinčiose organizacijų lentelėse, o tai parodė menką pripažinimą, kad teisingas atsakymas nėra tas, kad kiekvienas žmogus organizacijoje turi atkreipk dėmesį į viską.

Kai pradėjote savo įmonę, tikriausiai puikiai dirbote bendraudami. Visi vienas kitam viską pasakojo. Jūsų klientams tai patiko, nes kai paskambino paklausti apie pirkimo užsakymą, visi žinojo, kur jis yra. Tačiau didėjant jūs negalite nuolat visiems sakyti apie kiekvieną pirkimo užsakymą, todėl turite išrasti specifines ryšių sistemas, kad tai sužinotų tinkami žmonės ir niekas kitas. Ne todėl, kad tai konfidencialu. Nes tai gaištamas laikas.

Joelis Spolsky yra „Fog Creek Software“ įkūrėjas ir generalinis direktorius bei populiaraus tinklaraščio „Joel on Software“ vedėjas. Norėdami rasti jo stulpelių archyvą, eikite į www.inc.com/author/joel-spolsky .