Sådan effektiviseres dine softwareprojekter effektivt

Siden jeg startede min karriere som softwareingeniør, har jeg lært, at scoping er en af ​​de sværeste ting at få ret. Desværre lærer CS-programmer på universiteter dig ikke rigtig, hvordan du skal omfatte projekter. Så her er mit forsøg på at konsolidere det, jeg har lært om dette emne.

Scoping er ikke noget, du kan bruge en dag på under projektet og aldrig tænke på igen. For at omfatte et projekt nøjagtigt skal du være opmærksom på hele projektet i løbet af:

  1. Planlægningsfasen: de tidlige stadier af at definere projektet og dets mål
  2. Scoping-fasen: det tidspunkt, hvor de fleste mennesker tænker på scoping. Det er her, du prøver at liste op det arbejde, der skal udføres i betragtning af projektets mål, og estimere, hvor lang tid der kræves til at udføre dem.
  3. Udførelsesfasen: når du faktisk implementerer projektet.

Planlægningsfasen

En af de vigtigste ting at gøre i løbet af denne tid er at definere meget specifikke mål for projektet . For eksempel i stedet for "forbedre X for at være mere skalerbar og performant", kan et bedre og mere specifikt mål være at "forbedre X ved at tilføje enhedstest, understøtte 20K-forespørgsler pr. Sekund og reducere det begrænsede gennemsnit af brugerlatens til <= 200ms . ”

At have meget specifikke mål giver dig mulighed for hensynsløst at klippe alt, hvad der ikke bidrager til disse mål, så du ikke lider af funktions krybning. I denne retning kan du også overveje eksplicit at definere anti-mål og adskille must-haves og nice-to-haves .

Minimer projektets batchstørrelse ved at (1) oprette klare milepæle og kontrolpunkter for projektet og (2) gøre det let at starte kun en del af projektet. Dette hjælper ikke kun med at nedbryde projektet, men det giver også holdet mulighed for at sætte projektet på pause eller klippe det tidligt, hvis en anden opgave med højere prioritet kommer op.

Fjern risiko for projektet så hurtigt som muligt . To almindelige måder at de-risikere et projekt inkluderer (1) at arbejde på de mest risikable dele på forhånd og (2) prototypering af de mest risikable dele ved hjælp af dummy data og / eller stillads. Hver gang der bruges et nyt open source-system eller en ekstern tjeneste, repræsenterer det normalt en stor risiko.

Optimer ikke til den samlede mængde udført arbejde. Optimer i stedet for den samlede påvirkning over tid . Når du har fået den mest risikable del af vejen, skal du prioritere at arbejde på den del af projektet, der med det samme vil medføre den største effekt.

Her er en måde at tænke på dette: plot virkningen af ​​et projekt over tid, hvor Y-aksen er påvirkning, og X-aksen er tid. Ved projektets start er virkningen 0%, og i slutningen af ​​projektet er virkningen 100%. Du vil maksimere området under kurven ved at udføre høje ROI-opgaver først.

Prøv at undgå at omskrive store systemer fra bunden så meget som muligt . Når vi foretager en omskrivning, har vi tendens til at (1) undervurdere, hvor meget arbejde det ville være, (2) blive fristet til at tilføje nye funktioner og forbedringer, og (3) opbygge et alt for kompliceret system, fordi vi er for fokuserede på alle mangler ved det første system.

I stedet for at foretage en stor omskrivning, skal du overveje at udskifte undersystemer trinvist. Har gode abstraktionslag, der understøtter udskiftning af en del af det gamle system ad gangen, så du behøver ikke vente på, at alt gøres for at teste det nye system.

Omfangsfasen

  • Det er kun de ingeniører, der skriver koden, der skal scope opgaverne. Ikke deres ledere, ikke premierministeren eller de vigtigste interessenter i virksomheden.
  • Modstå fristelsen til under-scope . Vær ærlig over, hvor lang tid opgaver vil tage, ikke hvor lang tid du eller en anden (såsom din manager eller Go To Market-teamet) ønsker, at de skal tage.
  • Opdel projektet i små opgaver, der hver tager to dage eller derunder . Når du har opgaver, der er omfattet til " ca. 1 uge ", ender det ofte med at tage længere tid, fordi du ikke tæller alle de underopgaver, du muligvis skal udføre.
  • Definer målbare milepæle for at nå projektets mål. Planlæg hver med en bestemt kalenderdato, der repræsenterer, hvornår du forventer, at denne milepæl nås. Opret derefter en slags ekstern ansvarlighed på disse milepæle ved for eksempel at forpligte dem til din manager og oprette milepælsindtjekninger.
  • Tænk på projekttidsestimater som sandsynlighedsfordelinger , ikke bedst tænkelige scenarier. I stedet for at fortælle nogen, at en funktion er færdig om 6 uger, skal du fortælle dem noget som "der er 50% sandsynlighed for at afslutte funktionen om 4 uger, og en 90% chance for, at vi vil afslutte den om 8 uger . ”Dette har en tendens til at tvinge folk til at være mere realistiske.
  • Tilføj buffer til konto for: (1) Dev tid! = Kalendertid på grund af møder, interviews og helligdage. Jeg multiplicerer normalt dev-tiden med 1,5 for at komme til kalendertiden. (2) Uventet projektopgaver tid, da der altid er opgaver, som du ikke var klar over, at du skulle udføre før meget senere, såsom refactoring af gammel kode, fejlretning af tilsyneladende uforklarlige opførsler, tilføjelse af tests. Jo mere erfaren du er ved scoping, jo mindre vil denne multiplikator blive.
  • Brug historiske data. Hold styr på, om du tidligere har haft tendens til at overskride eller underskrive projekter (de fleste har tendens til at understrege). Juster din scoping i overensstemmelse hermed.
  • Husk, at 2X antallet af mennesker ikke betyder 1 / 2X dev-tiden , som et resultat af kommunikationsomkostninger, rampetid osv.
  • Overvej timeboxing åbne dele af projektet . I stedet for "find den bedste stream-behandlingsramme til dette system", som kan tage flere måneder med forskning og prototyper, skal du tidsfaste den til "at finde en passende ramme om streaming-behandling på en uge." Brug din vurdering her for at afbalancere dette mod at pådrage sig langsigtede operationelle omkostninger.

Udførelsesfasen

Re-scope regelmæssigt under projektets udførelse. For hver opgave skal du spore, hvor lang tid du estimerede, at opgaven ville tage, hvor lang tid det faktisk tog dig at gennemføre den. Gør dette for hver målbar milepæl. Hvis din scoping er slukket med 50% for de første dele af projektet, er det sandsynligt, at din scoping også er slukket med 50% for resten af ​​projektet.

Brug milepæle til at svare "hvordan går projektet?" Som ingeniører er det fristende at svare "det sker i næste uge" eller "indtil udgangen af ​​denne måned." Men disse typer af vage svar har tendens til at skabe projekter, der altid er 2 uger væk fra færdiggørelsen. Brug i stedet de (genoprettede) milepæle til at give et konkret svar baseret på hvor meget arbejde der er tilbage.

Hvis projektet glider, skal du sørge for, at alle forstår, hvorfor projektet er gledet. Derefter udvikler du en realistisk og revideret version af projektplanen . At droppe projektet eller klippe det kort er en potentiel mulighed, der bør overvejes. Læs mere om The Sunk Cost Fallacy, hvis du er nysgerrig over, hvorfor folk har en tendens til at forudindtage et projekt halvt.

At give kredit, hvor kredit skyldes, en masse information her kommer fra at tale med ingeniører og ledere som Spencer Chan og Nikhil Garg, læse bøger som The Effective Engineer af Edmond Lau og personligt scope mange projekter med varierende grad af nøjagtighed.

Til sidst, hvis jeg er ærlig, er jeg på ingen måde ekspert på scoping, og jeg laver regelmæssigt fejl som ikke at følge nogle af de bedste fremgangsmåder ovenfor. Jeg regnede bare med, at jeg indtil videre ville dokumentere mine erfaringer, så jeg kan henvise til dette i fremtiden.

Hvis du kan lide dette indlæg, skal du følge mig på Twitter for mere indhold om teknik, processer og backend-systemer.