Jeg har altid været morede på hvordan langt bag softwaren industrien er fremstillingsvirksomhed. Der er ingen tvivl om, selvfølgelig, at software er i det store og hele erstattet produktion i USA. Der er ingen tvivl om at amerikanerne arbejder mere med at skabe nye ideer end håndgribelige varer. Stadig, i måde at tænke og forvaltning af processen, software halter bagefter.
Tag for eksempel software-projekt i problemer. I fremstillingsindustrien er hver person, der er involveret i jobbet ansvarlig for generelle succes. Når maskinerne er ved at blive oprettet før begynder at gøre noget, er setup mændene ansvarlig for at bemærke, når noget er galt med værktøjet og lade folk vide. Før linjen starter, setup mænd og linje leder er ansvarlig for at køre en testkørsel og validering af at de er ved at opbygge det rigtige, at det opfylder specifikationerne, og at der er intet galt med det endelige resultat før de spilde virksomheden ’ s penge bygning tusindvis af forkerte widgets. Når linjen starter, er hver arbejderen ansvarlig for at stoppe processen, hvis de opdager noget galt. Toyota og andre producenter har været kendt siden 80 'er for de allestedsnærværende “ kvalitet linje ”, den magiske linje, at en arbejdstager kan trække og er ansvarlig for at trække Hvis de ser, at processen er gået ned sporene. Fremstilling ved, at jo længere du venter med at løse et problem, jo mere det koster, og at du er bedre ud for at stoppe og lave ting og savner din deadline, end du er til at levere de forkerte ting.
Ikke så i software-verdenen. Branchen er fyldt med diskussion om emnet. Nye artikler pop online. Afhængig af hvem du læse, projektlederen er ansvarlig, udvikling manager er ansvarlig, BA er ansvarlig, listen bliver ved og ved. Nogle (med rette) erklærer, at ligesom i fremstillingsindustrien, alle er ansvarlige.
Man kunne drøfte det hele dagen lang, men virkeligheden er, vi ’ re alle stiller de forkerte spørgsmål. Folk ønsker at gøre gode arbejde (medmindre de ’ re bare værdiløse medarbejdere). De ønsker at gøre det rigtige. De don ’ t gerne spilde deres tid. Alle er villige til at erklære, at projekter skrider ned den forkerte vej, hvis det er det rigtige at gøre. Forudsat at du mener, at om dine medarbejdere (og hvis du don ’ t, du har den forkerte personale), hvorfor de ikke trække linjen? Hvorfor ikke trække linjen en epidemi i software udvikling og projekt ledelse?
Svaret er da virksomhedsledelseselement lærer os alle, der trækker linjen er forkert. Lederskab skyder messenger 99 gange ud af 100. Død marts skal fortsætte. Ingen ønsker at fortælle kunden vi ’ ll være sent. Vi ’ re undervisning vores arbejdstagere gennem en næsten pavlovsk straf model, en eller anden måde kunden vil være gladere, hvis vi levere en halv-arbejde ting at isn ’ t hvad de bad om i stedet. Dette er drevet af en masse ting-frygt for konflikt med kunden (foregiver, der vandt ’ t være konflikt når vi levere skrald), frygt for at fortælle aktionærerne (foregiver den bestand isn ’ t påvirket ved at levere skrald), frygt for at forsøge at stoppe inertien eller at blive kaldt en finger pointer (foregiver, at hvis nogen har skruet og ikke taget ansvaret for det.finger bør ikke være spidse).
Af alle problemerne i corporate kultur i dag skal dette, mere end nogen anden, ændres. I de sidste femten år har jeg ændret virksomheder et halvt dusin gange. Flere af mine venner har ændret arbejdspladser så mange som et dusin. I næsten alle tilfælde har årsagen spores tilbage til dette. Virksomhedens ledelse nægter at klare deres problemer og skyder budbringere, indtil enten virksomheden folder eller så mange projekter mislykkes at der er en betydelig udrensning af personale inden for virksomheden. Du vil aldrig, aldrig levere det rigtige indtil du aktiverer dine medarbejdere til at være i stand til at holde op med at levere de forkerte ting. Hvis du er en corporate leder derude i dag, stille dig nogle spørgsmål:
- Har jeg en kultur i min virksomhed, hvor folk kan trække linjen uden frygt?
- Har jeg selv en linje? Er der et sandt, korrekt administreret proces for at hæve det røde flag på projekter med passende synlighed?
- Må folk kender processen for at rejse røde flag? Er at sikre de ved hvordan en del af projektet kickoff og projektstyring?
- Er processen effektiv? Er der konkrete foranstaltninger med varer kan behandles som følge af den røde flag proces? Er de overvåges og følges?
- Har jeg et belønningssystem for at rejse flag? Hvis hæve flaget gemmer mig fra at spilde penge, hvorfor i alverden ikke?
- Hvis jeg er ansvarlig for førende, er det ikke i sidste ende min skyld hvis vi mislykkes på grund af flag ikke rejst? Isn ’ t min egen karriere i sidste ende på linje her?
Der er en populær talemåde i virksomhedens IT-verden, der har altid moret mig: ” ingen nogensinde blev fyret for at købe IBM. ” vi lever i en risiko-negative kultur, hvor den største risiko vi undgå er konflikt. Jeg udfordrer dig til at løse dette problem og pund løsning hjem, indtil du høre dette under møder i virksomheden i stedet: ” ingen nogensinde blev forfremmet til at dække op problemer ”.
