![\"Swing-ohjelmistot](\"\/app\/uploads\/2024\/05\/swing-software.jpg\")
<\/p>\n<\/p>\n
kuvan l\u00e4hde: perfectdigital.com<\/em><\/p>\n Mielest\u00e4ni se osoittaa hyvin, ett\u00e4 suuria eroja ja n\u00e4kemyksen puutetta voi esiinty\u00e4 seuraavissa asioissa. ohjelmistokehitys<\/a> hankkeet kaikkien osallistujien ja asianosaisten v\u00e4lill\u00e4.<\/strong> Ongelmia syntyy usein heti alusta alkaen, kun asiakas tulee (teoreettisesti) lopullisen tuote<\/a> visio ja esittelee sen joukkue<\/a>. Sitten tulee lis\u00e4\u00e4 v\u00e4\u00e4rink\u00e4sityksi\u00e4, v\u00e4\u00e4rintulkintoja ja lopulta projekti<\/a> menee nopeasti v\u00e4\u00e4r\u00e4lle kehityspolulle.<\/p>\n Analysoidessani edell\u00e4 olevaa kuvaajaa esittelen vaiheittain kaikki mahdolliset uhat ja ehdotan, miten niit\u00e4 vastaan taistellaan. Menn\u00e4\u00e4n suoraan asiaan!<\/p>\n Poikkeavuuksia esiintyy tuotevisio<\/a> alusta alkaen. Miksi? Syy on hyvin yksinkertainen - jokainen tulkitsee todellisuuden omalla tavallaan, h\u00e4nell\u00e4 on mieless\u00e4\u00e4n k\u00e4sitys jostakin asiasta, eik\u00e4 h\u00e4n v\u00e4ltt\u00e4m\u00e4tt\u00e4 esit\u00e4 t\u00e4t\u00e4 n\u00e4kemyst\u00e4 tarkasti toiselle osapuolelle. Jos kuvailet sanoin tuotteen, jonka haluaisit rakentaa, on eritt\u00e4in todenn\u00e4k\u00f6ist\u00e4, ett\u00e4 kehitystiimi<\/a> ymm\u00e4rt\u00e4v\u00e4t visiosi eri tavalla kuin tarkoitit.<\/p>\n T\u00e4m\u00e4 on tietenkin mahdollista v\u00e4ltt\u00e4\u00e4. Visualisointi kannattaa aloittaa mahdollisimman pian ja keskustella tuotteen toiminnallisuuden yksitt\u00e4isist\u00e4 elementeist\u00e4 luonnosten pohjalta. Mielenkiintoista on, ett\u00e4 ensimm\u00e4isill\u00e4 luonnoksilla ei yleens\u00e4 ole mit\u00e4\u00e4n yhteist\u00e4 lopullisen tuotteen kanssa. T\u00e4ss\u00e4 vaiheessa t\u00e4rkeint\u00e4 on kuitenkin saada visio yhten\u00e4iseksi.<\/p>\n Ihmetteletk\u00f6, miksi ensimm\u00e4inen ja toinen kuva ovat niin erilaisia? Projektip\u00e4\u00e4llikk\u00f6 tarkastelee aina tarkemmin tuotevisiota. Kuitenkin, on t\u00e4rke\u00e4\u00e4, ett\u00e4 t\u00e4llainen henkil\u00f6, joka on olennaisesti vastuussa koko toiminnasta.<\/strong> ohjelmisto kehitysprosessi<\/a><\/strong>, ymm\u00e4rt\u00e4\u00e4 t\u00e4ysin tuotteeseen liittyv\u00e4n ongelman ja tarpeet.<\/strong>. Hankkeen johtajalla on oltava selke\u00e4 \"kokonaiskuva\". Kuten n\u00e4et, molemmat kuvat eiv\u00e4t eroa toisistaan toiminnallisuuden suhteen. Ne vain n\u00e4ytt\u00e4v\u00e4t erilaisilta. Jotta ymm\u00e4rt\u00e4isimme t\u00e4m\u00e4n kohdan paremmin, palataanpa kuvaan numero yksi. Projektin alussa ei ollut luonnoksia, ja jo se johti v\u00e4\u00e4rink\u00e4sitykseen. Tuotteen toiminnallisuus on oikea, mutta muotoilu on t\u00e4ysin erilainen.<\/p>\n Joskus analyytikot ja kehitt\u00e4j\u00e4t eiv\u00e4t tunne k\u00e4ytt\u00e4jien tarpeita tai vahvistettuja liiketoimintatavoitteita. He n\u00e4kev\u00e4t vain pienen palan koko projektista, joka vangitsee heid\u00e4n p\u00e4\u00e4huomionsa. He eiv\u00e4t kykene tarkastelemaan asiaa laajemmasta n\u00e4k\u00f6kulmasta, ja t\u00e4m\u00e4 koskee erityisesti suuria hankkeita, joissa ty\u00f6skentelee paljon kehitt\u00e4ji\u00e4 samanaikaisesti.<\/p>\n Voimme k\u00e4ytt\u00e4\u00e4 my\u00f6s toista esimerkki\u00e4. Voi k\u00e4yd\u00e4 niin, ett\u00e4 esimerkiksi tuotteen omistaja on kuvannut ratkaistavan ongelman v\u00e4\u00e4rin. T\u00e4ll\u00f6in annetaan puutteellista tietoa, jonka perusteella kehitt\u00e4j\u00e4<\/a> tai suunnittelija luo omia tulkintojaan, ja tuote poikkeaa yh\u00e4 enemm\u00e4n suunnitellusta kehityspolusta.<\/p>\n Miten se voidaan muuttaa? Mielest\u00e4ni hyv\u00e4 ratkaisu on varmistaa, ett\u00e4 hankkeen kannalta keskeisill\u00e4 henkil\u00f6ill\u00e4 on yksityiskohtaista tietoa hankkeesta - niin sanottu \"kokonaiskuva\". V\u00e4\u00e4rink\u00e4sitysten sattuessa heid\u00e4n on helpompi tuoda esiin ohjelmistokehitysprosessi<\/em> takaisin oikealle tielle. Muista siis, ett\u00e4 jos jokainen n\u00e4kee vain oman pienen palasen kehitetyst\u00e4 toiminnallisuudesta, v\u00e4\u00e4rink\u00e4sityksist\u00e4 visiossa tulee todenn\u00e4k\u00f6inen uhka.<\/p>\n T\u00e4ss\u00e4 tapauksessa asia on yksinkertainen. Tuotteen on myyt\u00e4v\u00e4. Sinun on jotenkin erotuttava, jotta esimerkiksi yksinkertainen keinu puutarhaan saa poikkeuksellisia elementtej\u00e4. Ideana on vakuuttaa potentiaalinen ostaja. Markkinointi- ja myyntiosasto tekee varmasti kaikkensa osoittaakseen, ett\u00e4 tuote on ainutlaatuinen.<\/p>\n Puuttuvat asiakirjat ovat hyvin yleinen ongelma. Joskus dokumentaation luominen aikana tuotekehitys<\/a> tuntuu tarpeettomalta ajanhukalta. T\u00e4m\u00e4 on virhe. Sanon hyvin usein, ett\u00e4 muutokset tehd\u00e4\u00e4n nopeammin paperilla kuin todellisuudessa. koodi<\/a>, ja siin\u00e4 on jotain per\u00e4\u00e4. Lis\u00e4ksi on helpompi viitata dokumentaatioon mahdollisten muutosten seuraamiseksi. Uskokaa minua, projektissa, jossa ei ole dokumentaatiota, on eritt\u00e4in suuri vaara, ett\u00e4 visio j\u00e4\u00e4 saavuttamatta.<\/p>\n T\u00e4ss\u00e4 vaiheessa ymp\u00e4rist\u00f6 sijoitetaan palvelimelle. Kuten ohjelmoijia ja analyytikkoja koskevassa kohdassa, ilman t\u00e4ytt\u00e4 tiedot<\/a> ja viestint\u00e4aukkojen vuoksi voi osoittautua, ett\u00e4 vain osa tarvittavasta ymp\u00e4rist\u00f6st\u00e4 on luotu.<\/p>\n Se on seurausta huonosta kommunikaatiosta, puutteellisesta kommunikaatiosta, puutteellisesta UX<\/a> ja niin edelleen. Virheiden ilmaantuminen lis\u00e4\u00e4 kehitysaikaa. Ja aika on rahaa, eik\u00f6 niin? Vinkkini on, ett\u00e4 projekti on toteutettava ketter\u00e4sti.<\/a><\/strong>, yll\u00e4pit\u00e4\u00e4 korkeimpia viestint\u00e4standardeja ja pit\u00e4\u00e4 kiinni selkeist\u00e4 budjettiohjeista. En ep\u00e4ile yht\u00e4\u00e4n, etteik\u00f6 n\u00e4in toimimalla v\u00e4ltett\u00e4isi t\u00e4llaisia ongelmia.<\/p>\n Asiakkaat keskittyv\u00e4t usein vain tuotteen rakentamiseen ja sen loppuunsaattamiseen. El\u00e4mme kuitenkin monien muutosten ja teknisten innovaatioiden aikaa, mink\u00e4 vuoksi on v\u00e4ltt\u00e4m\u00e4t\u00f6nt\u00e4 yll\u00e4pit\u00e4\u00e4 jatkuvaa teknist\u00e4 tukea. Tarkoituksena on v\u00e4ltt\u00e4\u00e4 tilanne, jossa jokin lakkaa yht\u00e4kki\u00e4 toimimasta, koska se vanhentuu ja tuote menett\u00e4\u00e4 arvonsa. My\u00f6sk\u00e4\u00e4n t\u00e4t\u00e4 n\u00e4k\u00f6kohtaa ei pid\u00e4 unohtaa.<\/p>\n Olemme saavuttaneet viimeisen pisteen. Katso ensimm\u00e4isen ja viimeisen kuvaajan v\u00e4list\u00e4 eroa. Loppujen lopuksi molemmat liittyv\u00e4t asiakkaan n\u00e4k\u00f6kulmaan. Miksi n\u00e4in tapahtuu? Kaikki valehtelevat, ett\u00e4 se on niin yksinkertaista \ud83d\ude42 Kyselytutkimusten tulokset poikkeavat aina vastaajien todellisista tarpeista. Vastatessaan tutkijan kysymykseen k\u00e4ytt\u00e4j\u00e4t haluavat n\u00e4ytt\u00e4\u00e4 parhaan puolensa. Siksi, HE EIV\u00c4T USEINKAAN VASTAA TOTUUDENMUKAISESTI<\/strong>vaan pikemminkin tavalla, johon heid\u00e4n mielest\u00e4\u00e4n pit\u00e4isi vastata. Periaatteessa he eiv\u00e4t halua altistua muiden negatiiviselle arvioinnille. Pieni vinkki: mainitse ohjeissa, ettei ole olemassa hyvi\u00e4 eik\u00e4 huonoja vastauksia.<\/p>\n Miss\u00e4 muualla erot n\u00e4kyv\u00e4t? Ihmiset eiv\u00e4t useinkaan tied\u00e4, mit\u00e4 he todella haluavat. Usein k\u00e4ytt\u00e4j\u00e4t sanovat aluksi tarvitsevansa tuotteeseen 10 toimintoa, mutta my\u00f6hemmin he k\u00e4ytt\u00e4v\u00e4tkin vain esimerkiksi 3 toimintoa.<\/p>\n Miten t\u00e4m\u00e4 ongelma ratkaistaan? Sen lis\u00e4ksi, ett\u00e4 kysyt k\u00e4ytt\u00e4jilt\u00e4, mit\u00e4 he haluavat ja tarvitsevat, anna heid\u00e4n testata tuotetta, mieluiten aidoilla tuotteilla, jotta uskottavuus s\u00e4ilyy. Mit\u00e4 enemm\u00e4n testej\u00e4 tuotteiden luomisen aikana tehd\u00e4\u00e4n, sit\u00e4 suurempi mahdollisuus on, ett\u00e4 tulos on tarkka.<\/p>\n Jos sinusta tulee joskus j\u00e4sen ohjelmistokehitys<\/a> hanke, muistakaa esimerkkini ja tehk\u00e4\u00e4 johtop\u00e4\u00e4t\u00f6kset, jotta ette kopioi edell\u00e4 mainittuja virheit\u00e4. Ja muista, ett\u00e4 n\u00e4m\u00e4 k\u00e4sitteet ovat eritt\u00e4in t\u00e4rkeit\u00e4 rakennettaessa tuotetta (sovellusta) tyhj\u00e4st\u00e4:<\/p>\n - hyv\u00e4 UX ja testit, jotta saat selville, mit\u00e4 k\u00e4ytt\u00e4j\u00e4t todella tarvitsevat,<\/p>\n - projektin sis\u00e4inen viestint\u00e4, jotta projektin avainhenkil\u00f6t ymm\u00e4rt\u00e4v\u00e4t ongelman ja tarpeet syv\u00e4llisesti,<\/p>\n - kehitt\u00e4\u00e4 tuotetta Ketter\u00e4<\/a>,<\/p>\n - \u00e4l\u00e4 unohda teknist\u00e4 tukea.<\/p>\n Lue lis\u00e4\u00e4:<\/strong><\/p>\n - Miten hallita tehokkaasti et\u00e4kehitt\u00e4ji\u00e4? Opas teknologiajohtajille<\/a><\/p>\nTunnet t\u00e4m\u00e4n kuvan, eik\u00f6 niin?<\/h2>\n
1. Miten asiakas selitti idean?<\/strong><\/h2>\n
2. Miten hankkeen johtaja ymm\u00e4rsi sen?<\/strong><\/h2>\n
3. Miten analyytikko suunnitteli sen? ja<\/em><\/strong> 4. Miten ohjelmoija kirjoitti sen?<\/strong><\/h2>\n
5. Miten yritysneuvoja kuvasi sit\u00e4?<\/strong><\/h2>\n
6. Miten hanke dokumentoitiin?<\/strong><\/h2>\n
7. Mitk\u00e4 toiminnot asennettiin?<\/strong><\/h2>\n
8. Miten asiakasta laskutettiin?<\/strong><\/h2>\n
9. Miten sit\u00e4 tuettiin?<\/strong><\/h2>\n
10. Mit\u00e4 asiakas todella tarvitsi?<\/strong><\/h2>\n
Yhteenveto<\/strong><\/h2>\n