![\"Swing](\"\/app\/uploads\/2024\/05\/swing-software.jpg\")
<\/p>\n<\/p>\n
Bildk\u00e4lla: perfectdigital.com<\/em><\/p>\n Jag tycker att det visar mycket v\u00e4l att stora avvikelser och brist p\u00e5 visioner kan f\u00f6rekomma i Utveckling av programvara<\/a> projekt mellan alla deltagare och inblandade personer.<\/strong> Problem uppst\u00e5r ofta redan i b\u00f6rjan, n\u00e4r kunden kommer med en (teoretiskt sett) slutgiltig Produkt<\/a> vision och presenterar den f\u00f6r Team<\/a>. Sedan kommer ytterligare missf\u00f6rst\u00e5nd, feltolkningar och till slut projekt<\/a> snabbt g\u00e5r in p\u00e5 fel utvecklingsv\u00e4g.<\/p>\n N\u00e4r jag analyserar grafen ovan kommer jag steg f\u00f6r steg att presentera alla m\u00f6jliga hot och f\u00f6resl\u00e5 hur man kan bek\u00e4mpa dem. L\u00e5t oss g\u00e5 rakt p\u00e5 sak!<\/p>\n Det kommer att finnas avvikelser i produktvision<\/a> fr\u00e5n allra f\u00f6rsta b\u00f6rjan. Varf\u00f6r \u00e4r det s\u00e5? Anledningen \u00e4r mycket enkel - alla tolkar verkligheten p\u00e5 sitt eget s\u00e4tt, har en id\u00e9 om n\u00e5got i huvudet och kanske inte exakt presenterar denna vision f\u00f6r den andra parten. Om du med ord beskriver en produkt som du skulle vilja bygga, \u00e4r det mycket troligt att den utvecklingsteam<\/a> kommer att f\u00f6rst\u00e5 din vision p\u00e5 ett annat s\u00e4tt \u00e4n du t\u00e4nkt dig.<\/p>\n Naturligtvis \u00e4r det m\u00f6jligt att undvika detta. Du b\u00f6r b\u00f6rja visualisera s\u00e5 snart som m\u00f6jligt och diskutera enskilda delar av produktfunktionaliteten utifr\u00e5n skisser. Intressant nog har de f\u00f6rsta skisserna vanligtvis inget gemensamt med slutprodukten. I det h\u00e4r skedet \u00e4r det viktigaste dock att g\u00f6ra visionen sammanh\u00e4ngande.<\/p>\n Undrar du varf\u00f6r den f\u00f6rsta och den andra bilden \u00e4r s\u00e5 olika? Projektledaren kommer alltid att ta en n\u00e4rmare titt p\u00e5 produktvisionen. Men hur som helst, \u00e4r det viktigt att en s\u00e5dan person, som i huvudsak ansvarar f\u00f6r hela<\/strong> programvara utvecklingsprocess<\/a><\/strong>, f\u00f6rst\u00e5r till fullo problemet och de behov som \u00e4r relaterade till produkten<\/strong>. Projektledaren m\u00e5ste ha en tydlig \"st\u00f6rre bild\". Som du kan se skiljer sig inte de b\u00e5da bilderna \u00e5t n\u00e4r det g\u00e4ller funktionalitet. De ser bara olika ut. F\u00f6r att b\u00e4ttre f\u00f6rst\u00e5 denna punkt, l\u00e5t oss \u00e5terv\u00e4nda till bild nummer ett. I b\u00f6rjan av projektet fanns det inga skisser och det ledde redan till ett missf\u00f6rst\u00e5nd. Produktens funktionalitet \u00e4r korrekt, men designen \u00e4r helt annorlunda.<\/p>\n Ibland k\u00e4nner analytiker och utvecklare inte till anv\u00e4ndarnas behov eller fastst\u00e4llda aff\u00e4rsm\u00e5l. De ser bara en liten del av hela projektet, som f\u00e5ngar deras huvudfokus. De kan inte se det ur ett bredare perspektiv, och detta \u00e4r s\u00e4rskilt fallet f\u00f6r stora projekt d\u00e4r m\u00e5nga utvecklare arbetar samtidigt.<\/p>\n Vi kan ocks\u00e5 anv\u00e4nda ett annat exempel. Det kan h\u00e4nda att problemet som ska l\u00f6sas beskrivs p\u00e5 ett felaktigt s\u00e4tt, till exempel av produkt\u00e4garen. Detta inneb\u00e4r att man ger ofullst\u00e4ndig information som ligger till grund f\u00f6r utvecklare<\/a> eller designer g\u00f6r sina egna tolkningar och produkten avviker mer och mer fr\u00e5n den avsedda utvecklingsv\u00e4gen.<\/p>\n Hur kan man \u00e4ndra p\u00e5 det? Jag tror att en bra l\u00f6sning \u00e4r att se till att de personer som \u00e4r nyckelpersoner i projektet har detaljerad kunskap om det - den s\u00e5 kallade \"st\u00f6rre bilden\". Om det uppst\u00e5r missf\u00f6rst\u00e5nd blir det l\u00e4ttare f\u00f6r dem att ta med Process f\u00f6r utveckling av programvara<\/em> tillbaka p\u00e5 r\u00e4tt sp\u00e5r. Kom d\u00e4rf\u00f6r ih\u00e5g - om alla bara ser sitt lilla fragment av den utvecklade funktionaliteten blir missf\u00f6rst\u00e5nden i visionen ett sannolikt hot.<\/p>\n H\u00e4r \u00e4r fr\u00e5gan enkel. Produkten m\u00e5ste s\u00e4lja. Du m\u00e5ste sticka ut p\u00e5 n\u00e5got s\u00e4tt, s\u00e5 att till exempel en enkel gunga f\u00f6r din tr\u00e4dg\u00e5rd f\u00e5r extraordin\u00e4ra element. Tanken \u00e4r att \u00f6vertyga en potentiell k\u00f6pare. Marknadsf\u00f6rings- och f\u00f6rs\u00e4ljningsavdelningen kommer s\u00e4kert att g\u00f6ra allt f\u00f6r att visa att produkten \u00e4r unik.<\/p>\n Avsaknad av dokumentation \u00e4r ett mycket vanligt problem. Ibland kan det vara sv\u00e5rt att skapa dokumentation under produktutveckling<\/a> verkar som ett on\u00f6digt sl\u00f6seri med tid. Detta \u00e4r ett misstag. Jag s\u00e4ger ofta att f\u00f6r\u00e4ndringar g\u00f6rs snabbare p\u00e5 papper \u00e4n i verkligheten. kod<\/a>och det ligger n\u00e5got i det. Dessutom \u00e4r det l\u00e4ttare att h\u00e4nvisa till dokumentationen f\u00f6r att sp\u00e5ra eventuella f\u00f6r\u00e4ndringar. Tro mig, ett projekt utan dokumentation l\u00f6per en mycket stor risk att missa visionen.<\/p>\n Detta steg avser att placera milj\u00f6n p\u00e5 servern. Som i punkten om programmerare och analytiker, utan fullst\u00e4ndig data<\/a> och med kommunikationsbrister kan det visa sig att bara en del av den n\u00f6dv\u00e4ndiga milj\u00f6n har skapats.<\/p>\n Det \u00e4r resultatet av d\u00e5lig kommunikation, brist p\u00e5 UX<\/a> och s\u00e5 vidare. N\u00e4r det uppst\u00e5r fel \u00f6kar utvecklingstiden. Och tid \u00e4r pengar, eller hur? Mitt tips \u00e4r att driva projektet i enlighet med Agile<\/a><\/strong>, uppr\u00e4tth\u00e5lla h\u00f6gsta kommunikationsstandard och ha tydliga budgetriktlinjer. Jag tvivlar inte p\u00e5 att ni genom att g\u00f6ra detta kommer att undvika s\u00e5dana problem.<\/p>\n Kunder fokuserar ofta bara p\u00e5 att bygga en produkt och avsluta med det. Vi lever dock i en tid med m\u00e5nga f\u00f6r\u00e4ndringar och tekniska innovationer, vilket \u00e4r anledningen till att det \u00e4r n\u00f6dv\u00e4ndigt att uppr\u00e4tth\u00e5lla konstant teknisk support. Tanken \u00e4r att undvika en situation d\u00e4r n\u00e5got pl\u00f6tsligt slutar fungera eftersom det blir f\u00f6r\u00e5ldrat och produkten f\u00f6rlorar sitt v\u00e4rde. Denna aspekt b\u00f6r inte heller gl\u00f6mmas bort.<\/p>\n Vi har n\u00e5tt den sista punkten. Titta p\u00e5 skillnaden mellan den f\u00f6rsta och den sista grafen. N\u00e4r allt kommer omkring relaterar b\u00e5da till kundens perspektiv. Varf\u00f6r \u00e4r det s\u00e5 h\u00e4r? Alla ljuger om att det \u00e4r s\u00e5 enkelt \ud83d\ude42 Unders\u00f6kningsresultat skiljer sig alltid fr\u00e5n dina respondenters faktiska behov. N\u00e4r de svarar p\u00e5 forskarens fr\u00e5ga vill anv\u00e4ndarna visa upp sin b\u00e4sta sida. D\u00e4rf\u00f6r \u00e4r det s\u00e5, DE SVARAR OFTA INTE SANNINGSENLIGT<\/strong>utan snarare p\u00e5 ett s\u00e4tt som de tycker att de borde svara. I grund och botten vill de inte uts\u00e4ttas f\u00f6r andras negativa bed\u00f6mning. H\u00e4r \u00e4r ett litet tips till dig - n\u00e4mn i instruktionerna att det varken finns bra eller d\u00e5liga svar.<\/p>\n Var annars uppst\u00e5r skillnaderna? M\u00e4nniskor vet ofta inte vad de verkligen vill ha. Ofta s\u00e4ger anv\u00e4ndarna f\u00f6rst att de beh\u00f6ver 10 funktioner i produkten, men senare anv\u00e4nder de i sj\u00e4lva verket bara, s\u00e4g, 3.<\/p>\n S\u00e5 hur l\u00f6ser man det h\u00e4r problemet? F\u00f6rutom att fr\u00e5ga anv\u00e4ndarna vad de vill ha och beh\u00f6ver, l\u00e5t dem testa produkten, helst p\u00e5 autentiska f\u00f6rem\u00e5l f\u00f6r att bibeh\u00e5lla trov\u00e4rdigheten. Ju fler tester under skapandet av produkter, desto st\u00f6rre \u00e4r chansen att resultatet blir korrekt.<\/p>\n Om du n\u00e5gonsin blir medlem i en Utveckling av programvara<\/a> projekt, kom ih\u00e5g mina exempel och dra slutsatser s\u00e5 att du inte kopierar ovanst\u00e5ende fel. Och kom ih\u00e5g att dessa begrepp \u00e4r mycket viktiga f\u00f6r att bygga en produkt (applikation) fr\u00e5n grunden:<\/p>\n - bra UX och tester, s\u00e5 att du kan l\u00e4ra dig vad dina anv\u00e4ndare verkligen beh\u00f6ver,<\/p>\n - kommunikation inom projektet, s\u00e5 att en djup f\u00f6rst\u00e5else f\u00f6r problemet och behoven finns tillg\u00e4nglig f\u00f6r nyckelpersoner i projektet,<\/p>\n - utveckla produkten i enlighet med Agil<\/a>,<\/p>\n - gl\u00f6m inte teknisk support.<\/p>\n L\u00e4s mer om detta:<\/strong><\/p>\n - Hur hanterar man utvecklare p\u00e5 distans p\u00e5 ett effektivt s\u00e4tt? En guide f\u00f6r CTO:er<\/a><\/p>\n - Python vs. Ruby? Vilken teknik ska du anv\u00e4nda f\u00f6r produktutveckling?<\/a><\/p>\nDu k\u00e4nner till den h\u00e4r bilden, eller hur?<\/h2>\n
1. Hur f\u00f6rklarade kunden sin id\u00e9?<\/strong><\/h2>\n
2. Hur uppfattade projektledaren det?<\/strong><\/h2>\n
3. Hur har analytikern utformat den? och<\/em><\/strong> 4. Hur skrev programmeraren det?<\/strong><\/h2>\n
5. Hur beskrev aff\u00e4rskonsulten det?<\/strong><\/h2>\n
6. Hur har projektet dokumenterats?<\/strong><\/h2>\n
7. Vilka operationer installerades?<\/strong><\/h2>\n
8. Hur fakturerades kunden?<\/strong><\/h2>\n
9. Hur st\u00f6ddes det?<\/strong><\/h2>\n
10. Vad beh\u00f6vde kunden egentligen?<\/strong><\/h2>\n
Sammanfattning<\/strong><\/h2>\n