Moskva -metode: Sådan prioriteres webstedets funktioner for at være effektive.

Har du nogensinde? ... da projektmødet lavede et nyt websted. Alle i teamet har en idé og har brug for, der er "vigtige". Marketing ønsker at få en genial chatbot, salgsafdelingen har brug for et komplekst prisberegningssystem, mens administrerende direktør ønsker, at Internettet skal have en enestående animation som et verdens -klasses websted. Endelig viser det sig, at alt ser "vigtigt ud", indtil jeg ikke ved, hvad jeg skal starte før. Indtil projektet blev forsinket, eskalerede budgettet, og holdet begyndte at løbe tør for ild

Hvis du støder på en situation "Jeg elsker dig." Ligesom dette, skal du ikke bekymre dig. Fordi dette problem er det klassiske problem med at udvikle alle slags produkter, og i dag har vi "The Hero of the White Horse" ved navn Moskva -metoden til at hjælpe dig. Dette er rammer, der vil hjælpe med at organisere de kaotiske behov. At blive en klar og reel plan, der får dit team til at fokusere på at levere arbejde til tiden og i et kontrolleret budget. Hvis vi er klar, så lad os se, hvordan dette værktøj kan gøre kaos til effektivitet.

Det virkelige problem i livet: når "alt" bliver "presserende"

I projekternes verden, især udviklingen af websteder eller software, er det mest klassiske problem "omfang kryb" eller hvad thailandske mennesker kalder "hævede funktioner". Mere end planlægningen til at begynde med forestil dig ...

Begynd projektet med det formål at oprette et simpelt e-handelswebsted, men efter mødet på ubestemt tid foreslog nogen, at "vi skulle også have et loyalitetsprogramsystem." En anden person tilføjede, at "hvorfor ikke sætte AR -funktionen for kunderne til at prøve produktet gennem kameraet?" Og selvfølgelig skal der være "produktanbefalingssystem med AI". Hvad der sker, er fra projektet, der skulle afsluttes om 3 måneder, det blev strakt i 6 måneder eller måske indtil året. Budgetsættet er ikke nok. Holdet blev træt, fordi de var nødt til at tackle et uendeligt behov. Dette er et problem, der har ødelagt utallige projekter. Alt sammen er ofte forårsaget af manglen på god planlægning og beslutning -at skabe i begyndelsen. Også kendt som opdagelsesfase, der er meget vigtig for projektets succes.

Spørg om illustrationer: Mødelokalet er fuld af kaos på tavlen. Der er en post -Det -note. Alle i rummet har et alvorligt og forvirret udtryk. At formidle "funktionen Kreta", der ikke kontrolleres

Hvorfor er det problem: mangler "kerne" i beslutninger?

Problemer "hævede funktioner" er ikke forårsaget af nogen dårlige intentioner. Men de fleste af dem er forårsaget af "strukturen" og "tænkning", der ikke er klare nok. Som den vigtigste årsag der er som følger:

• Mangel på et klart mål (mangel på klare mål): Når holdet ikke har det samme billede, hvad er det "mål" for projektet i denne fase? (For eksempel at teste markedet, for at øge salget eller skabe opmærksomhed). Hver idé vil se ud som "mulig" og "skal gøre".
• Alle parter har deres egen "betydning (tavede prioriteringer): Marketingafdelingen ses fra blygenereringens perspektiv, salgsafdelingen kiggede ud fra konverteringens perspektiv, kundeserviceafdelingen så ud fra perspektivet om at reducere spørgsmål, når der ikke var nogen central ramme i vurderingen. Alle vil skubbe det, de synes er det vigtigste.
• Bange for "mangler" (frygt for Mr. at det at bære de fleste funktioner fra starten vil gøre produktet til det bedste på trods af at det kan skabe en kompleks og forvirret oplevelse for brugerne
• Der er ingen "ingen rammer til at sige 'nej': ingen principper, som alle accepterer sammen, hvilket gør projektleder eller produktejer ikke i stand til at nægte forskellige anmodninger. Kan være rimeligt og ofte ender med at" acceptere "alt for at undgå konflikter

Spørgsmål om illustrationer: Infografisk stilmalerier med 4 personer (repræsentanter i hver afdeling) trækker rebet i forskellige retninger, med ordet "projekt går" i midten, der er ved at mangle. At formidle manglen på fælles mål

Hvis det er tilbage, hvordan vil det påvirke: katastrofen kaldes "projektulykker"

At lade omfanget krybe problemet fortsætte uden ledelse. Ikke bare at gøre projektet "langsommere", men det kan føre til en mere alvorlig katastrofe:

• Budgettet eskalerede og en spildende ressource: dette er den mest klare effekt. Hver tilføjet funktion er den tid og penge, der skal betales. Hvoraf de fleste normalt er mere end mange indstillinger
• Oppustet produkt: I stedet for at få et websted, der møder brugeren og let at bruge, kan vi returnere "monstre", der er fulde af ubrugte funktioner, hvilket gør brugeroplevelsen (UX) værre og til sidst slipper kunder fra.
• Holdet løber tør for magt og effektivitet (Team Burnout): Arbejder under pres og omfang af arbejde, der ikke er klart i lang tid. Får teamet til at blive træt, modløs og kan føre til fratræden af vigtigt personale
• At miste forretningsmuligheder (Misted Maiket Opportunity): Mens vi har travlt med at skabe en "maj" -funktioner ", bruger ingen konkurrenter, det kan lancere et enklere produkt, men markedet reagerer på det punkt og bruger kunderne først .

Spørg om illustrationer: Et stort skib, der er fyldt med tunge ting og er ved at synke ned i havet. Med tegnet skrevet som "Project Timeline & Budget" for at formidle det projekt, der er ved at gå ned på grund af de for mange funktioner

Er der nogen løsning? Og hvor man skal starte: Lær Moskva -metoden at kende

bruge en enkel, men kraftfuld ramme som Moskva -metoden Det er en prioritet, der hjælper teamet og interessenterne. (Interessenter) Alle forstår, hvad der er "nødvendigt" i hvert projekt.

Navnet Moskva er ikke relateret til Ruslands hovedstad. Men det er forkortelsen af de 4 kategorier af prioriteter:

• M - skal -Hove (skal have): er funktionen, eller hvad "det er absolut nødvendigt", hvis der ikke er nogen projekter eller produkter, der leveres, er slet ikke perfekte eller slet ikke. Kort sagt, "Kan ikke mangle hende", f.eks. På webstedet "e-handel" og "betalingskurv".
• S - Bør -Hav (burde have): er en "vigtig" funktion og vil gøre mange forskelle. Men ikke nødvendigt for den første lancering, som produktet stadig kan fungere, selv uden disse funktioner. Men det kan være noget underordnet, såsom funktionen "se ordrehistorikken" eller "sammenligne produkter"
• C - kunne -have (måske): er noget, der "ikke har noget godt", er en funktion eller en lille forbedring, der vil hjælpe med at øge brugernes tilfredshed. Men uden det påvirker det næsten ikke hovedforbruget. Disse funktioner udføres normalt, når der kun er tid og ressourcer, såsom at ændre farveknappen.
• W - vil ikke -have (denne gang ikke har): er funktionen eller behovet for teamet "enig", der "ikke vil gøre" i dette arbejde (denne gang). Specificeringen af denne kategori er meget klar. Fordi det hjælper med at styre alles forventninger og beskytte omfanget kryb. Betyder ikke ikke at gøre for evigt, men kan overvejes i fremtiden

Dette princip er vidt brugt i førende organisationer over hele verden, da ProductPlan forklarer, at det er et vigtigt værktøj for produktchef og Asana. Det anbefales at oprette en klar køreplan.

Spørg om illustrationer: Infografisk, der er klar og smuk, opdelt i 4 kanaler til M, S, C, W med ikoner og korte beskrivelser. Det er let at forstå for hver kategori

Eksempler fra den rigtige ting, der plejede at opnå: Casestudier lanceringen af SaaS -starten

For at være klarere, se på et eksempel på et SaaS -startfirma, der ønsker at skabe en platform til projektstyring. De har mange ideer til funktioner. Men kun 3 måneder begrænset til den første version (MVP - Minimum Vible Product)

Startproblem: Varefunktioner, som jeg vil have projektoprettelse, tildeling, chatsystem i teamet, oprettelse, Gantt -diagram, tidssporing, forbindelse med Google Kalender

Brug af Moskva -metoden: Holdet har organiseret værksted og deling af alle funktioner i 4 kategorier:

• Must-Hove: Registrering og log ind, oprettelse af projekter, stigende og tildeling (opgave), forfaldsdato bestemmelse, fordi uden disse ting kan platformen ikke fungere i henhold til hovedmålene.
• Bør-have: anmeldelse system (anmeldelse), vedhæftning af filer i opgave, kommentar (kommentar). Disse ting er meget vigtige til reel brug. Men hvis ikke den første dag kan stadig fungere
• Kun​
• Vil ikke have (til denne MVP): Gantt-diagram, tidssporing, oprettelse af rapport, forbindelse med tredjepart.

Resultater: Holdet kan lancere MVP med succes inden for 3 måneder som planlagt. De fik det produkt, der fokuserer på hovedfunktionen. Gør det muligt at indsamle feedback fra den første gruppe af brugere hurtigt og bringe disse oplysninger til at udvikle funktioner i bør-har og ikke-hove-gruppen med tillid og på det tidspunkt. Den passende struktur i SaaS -forretningen er vigtig for bæredygtig vækst og øger antallet af ansøgere

Spørg om illustrationer: Før/efter. Venstre er tavle, der er fuld af rodede funktioner. Højre side er en computerskærm, der viser MVP -versionen, der ser ren og nem at bruge. Med brugergrafer, der begynder at vokse

Hvis du vil følge, hvad skal jeg gøre? (Kan bruges med det samme): Tjekliste Organiseret workshop Moskva

Du kan begynde at bruge Moskva -metoden med dit projekt med det samme. Dette er et simpelt skridt i organisering af værksted for at prioritere:

1. Forberedelse (forberedelse):
   • Inviterer alle relevante interessenter (produktejer, projektleder, udviklingsholdsrepræsentant, forretningsrepræsentant/marketing)
   • Indstil "hovedmålet" for dette projekt eller Sprint tydeligt (såsom målet er at starte så hurtigt som muligt for at gemme feedback).
   • Indsamling af funktioner, brugerhistorier eller alle behov (kan komme fra efterslæb eller brainstorming)
2. Udfør workshop (udførelse):
   • Forklar Principles of Moskva (skal, bør, kunne, ikke) for alle.
   • Medbring hver funktion til at overveje en vare ad gangen.
   • Åben for "debatten" -teamet og "udvekslingsårsager", hvilken kategori af funktioner skal være baseret på "hovedmålet" -sættet.
   • Brug spørgsmål, såsom "Hvis vi ikke har denne funktion på lanceringsdagen, hvad vil der ske?" "Fungerer produktet stadig?"
   • Prøv at få holdet enig. Men hvis der opstår en konflikt, skal produktejer eller den mest magtfulde beslutningsmyndighed være en beslutning.
3. SAMMENDRAG OG KOMMUNIKATION (Færdig og kommuniker):
   • Når gruppen er komplet for at tage billeder eller registrere resultaterne tydeligt
   • Kommuniker dette resultat til alle i teamet og de relevante ledere. For alle at se det samme billede, som "hvad skal der gøres" og "hvad gøres ikke" i denne runde?
   • Fortsæt med at planlægge planen i køreplanen eller sprintplanlægningen.

Prioriteterne for funktionen er bare en del af teamledelsen. Der er stadig et spørgsmål om struktur og rolle for teamet, især inden for e-handelsbranchen, der skal overvejes sammen

Spørg om illustrationer: Smukke tjeklistebilleder med ikoner for hvert trin (forbered, værksted, opsummer) for læserne for at se klare processer og kan let bruges.

Spørgsmål, som folk har en tendens til at undre sig, og de svar, der er ryddet

Spørgsmål 1: Hvad skal man gøre, hvis alle interessenter bekræfter, at alle deres funktioner er 'must-hove'?
Svar: Dette er en klassisk situation! Løsningen er at vende tilbage til "hovedmålet" for det aftalte projekt og kan være nødt til at specificere kvote som "I denne fase kan vi ikke gøre mere end 5." For at tvinge alle til at vælge den vigtigste ting, skal de, der er produktsejer eller projektleder, fungere som forhandler og beslutte fordelen ved projektet. Ikke nogen af dems behov

Spørgsmål 2: Kategorien 'Will'-Hove' får folk til at foreslå ideer til at tabe eller ej?
Svar: Nej, hvis vi kommunikerer korrekt, skal altid understrege, at 'ikke-have' ikke betyder "dine ideer er ikke gode" eller "vi vil ikke gøre det for evigt." Men det betyder "Vi vil ikke gøre det i denne runde." Og bringe de gode ideer til efterslæbet for at overveje i fremtiden, det er en bedre forventning om forventninger end lovende og ikke kan gøre det.

Spørgsmål 3: Hvor ofte gennemgår vi Moskva?
Svar: skal gennemgå regelmæssigt. I det mindste, hver gang du starter et nyt værk (ny sprint eller ny fase) på grund af forretningssituationer, kan feedback fra kunder eller tekniske begrænsninger ændres på alle tidspunkter. Funktioner, der plejede at være 'bør-have', kan blive 'must-hove' i den næste fase. Fleksibilitet er hjertet.

Spørg om illustrationer: Arbejdslampikon med spørgsmålstegn og nogen smiler og giver tillidssvar til at formidle løsningen

Resume for at være let at forstå + vil prøve at gøre

Moskva -metoden er ikke en magisk medicin, der kan løse alle problemer, men det er en stærk ramme. "Kaos" for at blive en "klarhed". Dets hjerte er at skabe kvalitetssamtaler og tvinge alle på holdet til at besvare det vigtigste spørgsmål, at "hvad er virkelig nødvendigt? For at vi kan nå målet nu?"

Stop med at prøve at gøre alt på samme tid, og drej derefter for at fokusere på at levere hovedværdien til brugeren så hurtigt som muligt er en strategi, der er skarpere end på lang sigt, det hjælper med at reducere risikoen, spare budgettet, opretholde teamets moral. Og det vigtigste er at få dig til at oprette produkter, som kunderne ønsker. Ikke det produkt, du "tænker", han vil have

Det er tid til at stoppe målet om at sigte og kredsløbet til den "hævede funktion". Prøv at bruge tjeklisten. Værkstedet Moskva, som vi sørgede for dit næste projekt. Og du vil opdage, hvor magtfulde prioriteterne er.

Hvis du leder efter et professionelt team, der vil hjælpe dig fra opdagelsesplanlægningsprocessen, skal du prioritere og udvikle websteder, der virkelig imødekommer forretningsbehov. Vision X Brain Team er klar til at konsultere og arbejde sammen med dig for at skabe et fantastisk resultat.

Spørg om illustrationer: Billedet af holdet smiler lykkeligt og med tillid og peger på køreplanen for det projekt, der er arrangeret i overensstemmelse med Moskva. At formidle succes og klarhed i arbejdet

‍