Moskou -methode: hoe u de website -functies kunt prioriteren om effectief te zijn.

Heb je ooit? ... toen de projectbijeenkomst een nieuwe website maakte. Iedereen in het team heeft een idee en behoeften die "belangrijk" zijn. Marketing wil een geniale chatbot krijgen, de verkoopafdeling heeft een complex prijsberekeningssysteem nodig, terwijl CEO wil dat het web een uitzonderlijke animatie heeft zoals een World -Class -website. Ten slotte blijkt dat alles er "belangrijk" uitziet totdat ik niet weet wat ik eerder moet beginnen. Totdat het project werd vertraagd, escaleerde het budget en begon het team zonder vuur te raken
Als je een situatie tegenkomt "ik hou van je." Maak je geen zorgen. Omdat dit probleem het klassieke probleem is bij het ontwikkelen van allerlei producten en vandaag hebben we "The Hero of the White Horse" genaamd Moskou -methode om u te helpen. Dit is raamwerk dat zal helpen bij het organiseren van de chaotische behoeften. Om een duidelijk en echt plan te worden waardoor uw team zich concentreert op het leveren van werk op tijd en in een gecontroleerd budget. Laten we eens kijken hoe deze tool van chaos in efficiëntie kan veranderen.
Het echte probleem in het leven: wanneer "alles" "dringend" wordt
In de wereld van projecten, met name de ontwikkeling van websites of software, is het meest klassieke probleem "scope creep" of wat Thaise mensen "gezwollen functies" noemen. Meer dan de planning stelt zich in eerste instantie voor ...
Begin het project met de bedoeling om een eenvoudige e-commerce-website te maken, maar na de vergadering stelde iemand voor onbepaalde tijd voor dat "we ook een loyaliteitsprogrammasysteem zouden moeten hebben." Een andere persoon voegde eraan toe dat "waarom niet de AR -functie voor klanten plaatsen om het product via de camera te proberen?" En natuurlijk moet er "productaanbevelingssysteem met AI" zijn. Wat er gebeurt, is van het project dat binnen 3 maanden zou moeten worden voltooid, het werd 6 maanden of misschien tot het jaar uitgerekt. De budgetset is niet voldoende. Het team werd moe omdat ze te maken hadden met een eindeloze behoeften. Dit is een probleem dat talloze projecten heeft vernietigd. Die allemaal vaak worden veroorzaakt door het ontbreken van goede planning en beslissing -in het begin. Ook bekend als de ontdekkingsfase die erg belangrijk is voor het succes van het project.
Prompt om illustraties: de vergaderruimte staat vol met chaos op het whiteboardbord. Er is een post -it -noot. Iedereen in de kamer heeft een serieuze en verwarde uitdrukking. Om de "functie Kreta" over te brengen die niet wordt gecontroleerd
Waarom is dat probleem: ontbreken "kern" in beslissingen?
Problemen "gezwollen functies" worden niet veroorzaakt door de slechte bedoelingen van iemand. Maar de meeste van hen worden veroorzaakt door de "structuur" en "denken" die niet duidelijk genoeg zijn. Welke de belangrijkste oorzaak er als volgt zijn:
- Gebrek aan duidelijk doel (gebrek aan duidelijke doelstellingen): wanneer het team niet hetzelfde beeld heeft dat wat is het "doel" van het project in deze fase? (Bijvoorbeeld om de markt te testen, de verkoop te verhogen of om bewustzijn te creëren). Elk idee zal eruit zien als "mogelijk" en "zou moeten doen".
- Alle partijen hebben hun eigen "belang (siled prioriteiten): de marketingafdeling wordt bekeken vanuit het perspectief van leadgeneratie, de verkoopafdeling heeft uit het perspectief van de conversie gekeken, de klantenservice keek vanuit het perspectief van het verminderen van vragen wanneer er geen centraal kader was in de beoordeling. Iedereen zal pushen wat zij vinden dat de belangrijkste is.
- Bang voor "ontbreekt" (angst voor de heer dat het dragen van de meeste functies vanaf het begin het product het beste zal maken, ondanks het feit dat het een complexe en verwarde ervaring voor gebruikers kan creëren
- Er is geen "geen raamwerk om 'nee' te zeggen: geen principes die iedereen samen accepteert, waardoor projectmanager of producteigenaar verschillende verzoeken niet kan weigeren. Kan redelijk en vaak eindigen met" alles accepteren "om conflicten te voorkomen
Prompt voor illustraties: Infographic Style -schilderijen met 4 personen (vertegenwoordigers in elke afdeling) trekken het touw in verschillende richtingen, met het woord "project go" in het midden dat op het punt staat te ontbreken. Om het gebrek aan gemeenschappelijke doelen over te brengen
Als het links is, hoe zal het dan beïnvloeden: de ramp wordt "projectcrashes" genoemd
Het probleem van de scope laten doorgaan zonder management. Niet alleen het project "langzamer" maken, maar het kan leiden tot een serieuzere ramp:
- Het budget escaleerde en een verspillende bron: dit is het meest duidelijke effect. Elke toegevoegde functie is de tijd en het geld dat moet worden betaald. Waarvan de meeste meestal meer zijn dan veel instellingen
- Opgeblazen product: in plaats van een website te krijgen die aan de gebruiker voldoet en gemakkelijk te gebruiken, kunnen we "monsters" retourneren die vol zijn met ongebruikte functies, waardoor de gebruikerservaring (UX) erger is en ten slotte klanten ontsnappen.
- Het team raakt van kracht en efficiëntie (teamburn -out): werken onder druk en reikwijdte van het werk dat niet lang niet duidelijk is. Waardoor het team moe, ontmoedigd wordt en kan leiden tot het aftreden van belangrijk personeel
- Het verliezen van zakelijke kansen (Misted Maiket Opportunity): hoewel we bezig zijn met het creëren van een "may" -functies "die niemand concurrenten gebruikt, kan het een eenvoudiger product lanceren, maar de markt reageert op het punt en zal de klanten eerst gebruiken . Zal helpen deze risico's te verminderen, maar moet met een effectieve prioriteiten komen.
Prompt voor illustraties: een groot schip dat vol zit met zware dingen en op het punt staat in de zee te zinken. Met het bord geschreven als "Project Timeline & Budget" om het project over te brengen dat op het punt staat te crashen vanwege de te veel functies
Is er een oplossing? En waar te beginnen: leer de methode van Moskou kennen
een eenvoudig maar krachtig raamwerk te gebruiken de Moskou -methode Het zijn een prioriteiten die het team en belanghebbenden helpen. (Stakeholders) Iedereen begrijpt wat "noodzakelijk" is in elk project.
De naam Moskou is niet gerelateerd aan de hoofdstad van Rusland. Maar het is de afkorting van de 4 categorieën prioriteiten:
- M - Must -Hove (moet hebben): is de functie of wat "het is absoluut noodzakelijk" als er geen projecten of producten zijn die worden geleverd, zijn helemaal niet perfect of helemaal niet nuttig. Simpel gezegd, "kan haar niet missen", zoals op de website "e-commerce" en "betalingsmand".
- S - moet -hebben (zou moeten hebben): is een "belangrijke" functie en zal veel verschillen maken. Maar niet nodig voor de eerste lancering kan het product nog steeds werken, zelfs zonder deze functies. Maar het kan enigszins inferieur zijn, zoals de functie "Zie de ordergeschiedenis" of "Producten vergelijken"
- C - Zou (misschien) kunnen hebben: is iets dat "niet goed heeft" een functie of een beetje verbetering is die zal helpen de tevredenheid van gebruikers te vergroten. Maar zonder dit heeft het bijna geen invloed op het hoofdgebruik. Deze functies worden meestal gedaan als er alleen tijd en bronnen zijn, zoals het wijzigen van de kleurenknop.
- W - zal niet - deze keer hebben (deze keer niet zal hebben): is de functie of de behoefte aan het team "mee eens" dat "niet" zal doen "in dit werk (deze keer). Het specificeren van deze categorie is heel duidelijk. Omdat het helpt om ieders verwachtingen te beheren en de scope kruip te beschermen. Betekent niet dat het niet voor altijd doet, maar kan in de toekomst worden overwogen
Dit principe wordt veel gebruikt in toonaangevende organisaties over de hele wereld, omdat ProductPlan uitlegt dat het een belangrijk hulpmiddel is voor productmanager en asana. Het wordt aanbevolen om een duidelijke routekaart te maken.
Prompt voor illustraties: Infographic die duidelijk en mooi is, verdeeld in 4 kanalen voor M, S, C, W met iconen en korte beschrijvingen. Dat is gemakkelijk te begrijpen voor elke categorie
Voorbeelden van het echte ding dat vroeger werd bereikt: casusstudie van de lancering van de SaaS -startup
Bekijk een voorbeeld van een SaaS -startup -bedrijf dat een platform wil maken voor projectmanagement om duidelijker te zijn om duidelijker te kijken naar een SaaS -startup -bedrijf. Ze hebben veel ideeën voor functies. Maar slechts 3 maanden beperkt tot de eerste versie (MVP - Minimum Vible Product)
Beginprobleem: itemfuncties die ik wil hebben projectcreatie, opdracht, chatsysteem in het team, creatie, Gantt -grafiek, tijd volgen, verbinding met Google Agenda en Dashboard Custom maken
Met behulp van Moskou -methode: het team heeft een workshop georganiseerd en alle functies in 4 categorieën gedeeld:
- Must-hove: registreren en inloggen, projecten maken, toenemende en toewijzing (taak), vervaldatumbepaling omdat zonder deze dingen het platform niet kan werken volgens de hoofddoelstellingen.
- Zou moeten hebben: meldingssysteem (melding), bestanden bij het toevoegen van taak, commentaar (commentaar). Deze dingen zijn erg belangrijk voor echt gebruik. Maar als het niet op de eerste dag kan werken
- Kon have have: de themaleur wijzigen, drag-drop drag-dorp
- WILT WILT (voor deze MVP): Gantt-grafiek, tijd volgen, rapport maken, verbinding met derden.
Resultaten: Het team kan de MVP binnen 3 maanden met succes lanceren zoals gepland. Ze kregen het product dat zich richt op de hoofdfunctie. Maakt het mogelijk om feedback van de eerste groep gebruikers snel te verzamelen en die informatie te brengen om functies te ontwikkelen in de moeten have en zal de groep niet vol vertrouwen en op dit punt. De juiste structuur van de SaaS -activiteiten is belangrijk voor duurzame groei en het vergroten van het aantal aanvragers
VOORBEELD VOOR ILLUSTRATIES: voor/na. Links is whiteboard dat vol zit met rommelige functies. De rechterkant is een computerscherm dat de MVP -versie toont die er schoon en gemakkelijk te gebruiken uitziet. Met gebruikersgrafieken die beginnen te groeien
Als je wilt volgen, wat te doen? (Kan onmiddellijk worden gebruikt): Checklist Organized Workshop Moskou
U kunt onmiddellijk met uw project de Moskou -methode gaan gebruiken. Dit is een eenvoudige stap in het organiseren van workshop om prioriteit te geven:
- Voorbereiding (voorbereiding):
- Alle relevante belanghebbenden uitnodigen (producteigenaar, projectmanager, vertegenwoordiger van de ontwikkelingsteam, bedrijfsvertegenwoordiger/marketing)
- Stel het "hoofddoel" van dit project of sprint duidelijk in (zoals het doel is om zo snel mogelijk te lanceren om feedback op te slaan).
- Het verzamelen van functies, gebruikersverhalen of alle behoeften (kunnen afkomstig zijn van achterstand of brainstormen)
- Workshop uitvoeren (uitvoering):
- Leg de principes van Moskou uit (moet, moeten, niet, niet) aan iedereen.
- Breng elke functie om één item tegelijk te overwegen.
- Open voor het "debat" -team en "ruilredenen", welke categorie functies moeten zijn gebaseerd op de "hoofddoel" -set.
- Gebruik vragen, zoals "Als we deze functie niet op de lanceringsdag hebben, wat zal er gebeuren?" "Werkt het product nog steeds?"
- Probeer het team ermee in te laten. Maar als er een conflict optreedt, moet een producteigenaar of de krachtigste beslissingsautoriteit een beslissing zijn.
- Samenvatting en communicatie (voltooi en communiceren):
- Wanneer de groep compleet is om foto's te maken of de resultaten duidelijk vast te leggen
- Communiceer dit resultaat aan iedereen in het team en de relevante leidinggevenden. Voor iedereen om hetzelfde beeld te zien dat "wat er wordt gedaan" en "wat is niet gedaan" in deze ronde?
- Blijf het plan plannen in de routekaart- of sprintplanning.
De prioriteiten van de functie zijn slechts een deel van het teammanagement. Er is nog steeds een kwestie van structuur en rol van het team, vooral in de e-commercebedrijf die samen moet worden overwogen
Prompt voor illustraties: mooie checklistafbeeldingen met pictogrammen voor elke stap (voorbereid, workshop, samenvatten) voor de lezers om duidelijke processen te zien en kan eenvoudig worden gebruikt.
Vragen die mensen de neiging hebben zich af te vragen en de antwoorden die zijn gewist
Vraag 1: Wat te doen als alle stakeholder bevestigt dat al hun functies 'must-hove' zijn?
Antwoord: Dit is een klassieke situatie! De oplossing is om terug te gaan naar "het hoofddoel" van het overeengekomen project en mogelijk moet het quotum zoals "In deze fase specificeren, kunnen we niet meer dan 5 doen." Om iedereen te dwingen het belangrijkste te kiezen, moeten degenen die producteigenaar of projectmanager zijn als onderhandelaar optreden en het voordeel van het project bepalen. Niet de behoeften van iemand
Vraag 2: De categorie 'Won't-Hove' zorgt ervoor dat mensen ideeën voorstellen om te verliezen of niet?
Antwoord: Nee, als we correct communiceren, moet altijd benadrukken dat 'niet-have' niet betekent dat "uw ideeën niet goed zijn" of "We zullen het niet voor altijd doen." Maar het betekent: "We zullen het niet doen in deze ronde." En breng die goede ideeën naar de achterstand om in de toekomst te overwegen, het is een betere verwachting van verwachtingen dan veelbelovend en kan dit niet.
Vraag 3: Hoe vaak beoordelen we Moskou?
Antwoord: Moet regelmatig beoordelen. Op zijn minst, elke keer dat u een nieuw werk begint (nieuwe sprint of nieuwe fase) vanwege bedrijfssituaties, kunnen feedback van klanten of technische beperkingen te allen tijde veranderen. Kenmerken die vroeger 'moeten' hangen 'kunnen' must-hove 'worden in de volgende fase. Flexibiliteit is het hart.
Prompt om illustraties: icon lamp pictogram met vraagteken en iemand glimlacht en geeft vertrouwen antwoorden om de oplossing over te brengen
Samenvatting om gemakkelijk te begrijpen te zijn + willen proberen te doen
Moskou -methode is geen magisch medicijn dat alle problemen kan oplossen, maar het is een krachtig kader. "Chaos" om een "duidelijkheid" te worden. Het hart is om kwaliteitsgesprekken te creëren en iedereen in het team te dwingen de belangrijkste vraag te beantwoorden dat "wat is echt nodig? Voor ons om het doel nu te bereiken?"
Stop met proberen alles tegelijkertijd te doen en draai dan om te gaan om zich zo snel mogelijk te concentreren op het leveren van de hoofdwaarde aan de gebruiker is een strategie die scherper is dan op de lange termijn, het helpt het risico te verminderen, het budget te besparen, het moreel van het team te behouden. En het belangrijkste is om u echt producten te laten maken die klanten willen. Niet het product dat u "denkt" dat hij wil
Het is tijd om het doel van het richten en het circuit van de "gezwollen functie" te stoppen. Probeer de checklist te gebruiken. De workshop Moskou die we voor uw volgende project hebben verstrekt. En u zult ontdekken hoe krachtig de prioriteiten zijn.
Als u op zoek bent naar een professioneel team dat u zal helpen bij het planningsproces van Discovery, het prioriteren en ontwikkelen van websites die echt voldoen aan de zakelijke behoeften. Het Vision X Brain Team is klaar om te raadplegen en met u samen te werken om een geweldig resultaat te creëren.
Prompt voor illustraties: het beeld van het team lacht gelukkig en vol vertrouwen, wijzend op de routekaart van het project dat is gerangschikt in overeenstemming met Moskou. Om het succes en de duidelijkheid van het werk over te brengen
Recente blog

Wilt u over de hele wereld verkopen? Vergelijk de voordelen van de voordelen tijdens het gebruik van Shopify-markten en taalvertaling-apps. (Mulilingual Apps) om het systeem te selecteren dat het meest geschikt is voor uw winkel.

Voeg klanten toe om te huren met SEO! In -diepte, SEO -strategie voor huurbedrijven, vooral van lokale SEO tot de productpagina.

Stop met het verspillen van tijd om een te rapporteren te maken! Leer u hoe u verbinding kunt maken met N8N met Google Looker Studio (Data Studio) om een dashboard en automatische marketing te maken.