Kuinka välttää prototyyppien muodostaminen

Kirjoittaja: Randy Alexander
Luomispäivä: 26 Huhtikuu 2021
Päivityspäivä: 15 Saattaa 2024
Anonim
Kuinka välttää prototyyppien muodostaminen - Luova
Kuinka välttää prototyyppien muodostaminen - Luova

Sisältö

Mitä mieltä olet, kun näet tai kuulet sanan prototyyppi? Ehkä pienoismalli, joka on valmistettu edullisesta materiaalista? Tai ehkä jotain, jonka kanssa voi olla fyysisesti vuorovaikutuksessa?

  • 10 parasta prototyyppityökalua

Joko niin, monilla teollisuudenaloilla prototyypit eivät ole valmiita artikkeleita - eikä niiden odoteta olevankin. Verkkoalalla prototyypit ovat valtava osa elämäämme. Ne ovat uskomattoman hyödyllisiä ja informatiivisia, mutta pelkään, että niitä käytetään usein väärin ja väärin. Ja tämä johtaa "prototyyppien vaaraan".

Harkitse seuraavia tilanteita ...

Prototyyppien skenaario yksi

Projektiryhmää pyydetään selvittämään uuden digitaalisen tuotteen idean toteutettavuus. Kehittäjä käyttää kehystä (tai monia) ilman perusteluja tai tutkimusta, koodauksessa he ovat vain vähän varovaisia, eikä koodikatselmuksia tai parhaita käytäntöjä ole.


Kaikki isännöi tietokoneella, joka ei ole millään tavalla lähellä tuotantoympäristön peiliä. Kehittäjät julistavat sen "melko valmiiksi", ja myös projektipäällikkö näkee sen "valmiina".

Sidosryhmät uskotaan uskovan, että se on valmis, ja allekirjoittavat sen käynnistettäväksi välittömästi. Se joko menee suoraan tuotantoon, jossa on valtava määrä teknistä velkaa, tai sen käynnistäminen kestää odotettua kauemmin.

Prototyyppien skenaario kaksi

Projektiryhmää pyydetään osoittamaan joitain uusia toimintoja olemassa olevalle digitaaliselle tuotteelle. Suunnittelija heittää jotain yhteen valitsemassaan modernissa prototyyppisovelluksessa. Tämä näyttää vuorovaikutusta, siirtymiä, animaatioita ja niin edelleen. Siinä ei oteta huomioon mitään suorituskykyyn liittyviä näkökohtia tai kuinka monimutkaista sen koodaamiseen liittyy.

Suunnittelija julistaa sen "melkein valmiiksi", pääjohtaja / asiakas / sidosryhmät uskovat sen tekevän ja allekirjoittavat sen välittömään käyttöönottoon. Prototyyppien ohjelmisto voi mahdollisesti pystyä tuottamaan koodia, mutta ei ole tietoa sen laadusta tai siitä, kuinka helppoa olisi integroida todelliseen toimivaan kooditietokantaan - se on ehkä kirjoitettava alusta alkaen.


Epäonnistuminen

Molemmissa tapauksissa hankkeet katsotaan epäonnistuneiksi. Sidosryhmien odotukset olivat kuitenkin täysin suhteettomia todellisuuteen johtuen kaikkien projektiryhmän jäsenten heikosta viestinnästä.

Näetkö kuvion täällä? Ongelma ei ole prototyyppien muodostamisessa sinänsä; Niiden kanssa, jotka eivät kerro työtovereilleen / asiakkailleen täysimääräisesti työnsä tilasta prototyypin varhaisessa vaiheessa ja mitä vaaditaan vielä, jotta se olisi elinkelpoinen tuotannossa (olipa se sitten alun perin MVP tai täysimittainen tuote). He olettavat, että vain siksi, että prototyyppi näyttää valmiilta, ei ole enää tehtävää.

Ratkaisu tähän ongelmaan johtuu vastuun ottamisesta. Suunnittelijoiden vastuulla on ymmärtää ja kommunikoida, että heidän prototyyppinsä on edelleen koodattava (ja sen kanssa on käytävä läpi koko joukko keskusteluja ja tehtäviä).


Kehittäjien vastuulla on kommunikoida siitä, mitä vielä teknisesti tarvitaan, ymmärtämällä, että se saattaa hyvinkin tarvita apua muilta tiimeiltä. Pääministerin / asiakkaiden vastuulla ei ole olettaa, että työ on saatu päätökseen tässä hyvin varhaisessa vaiheessa, ja he voivat sitten aloittaa suunnitelman laatimisen projektin asianmukaiselle resursoinnille.

Vastuun ottaminen

Mielestäni projektipäälliköiden velvollisuutena on tässä vaiheessa puhdistaa tie tiimilleen aikaa ja tilaa jatkaa tutkimuksiaan - koska täällä prototyyppi todella alkaa muotoutua ja auttaa ajamaan MVP ja sen jälkeen.

Ideat muokataan uudelleen, koodi kirjoitetaan uudelleen, mutta prototyyppiä ei tule pitää valmiina ennen kuin kaikki palapelin palaset on tutkittu. Tähän tulisi sisältyä infrastruktuuri, turvallisuus, suorituskyky, hakukoneoptimointi, sisältöstrategia ja kaikki sen välissä olevat.

Nämä unohdetaan usein tuotekehitysprosessissa - joskus juuri ennen julkaisupäivää - mutta miksi et aloittaisi aikaisemmin? Niin kauan kuin alamme tarkastella kaikkia näkökohtia, koko tiimille (ja asiakkaalle) annetaan paljon parempi kuvaus tuotteen toteutettavuudesta. Tästä prototyypin pitäisi oikeastaan ​​olla kyse.

Verkkoammattilaisina meidän ei pitäisi pelätä sanoa, että jotain ei ole valmis. Jos voimme kaikki kommunikoida paremmin, epäonnistuneita projekteja ja enemmän iloa kehittää suuria digitaalisia tuotteita käyttäjillemme.

Tämä artikkeli ilmestyi alun perin nettilehti numero 296. Osta se täältä.

Lukijoiden Valinta
Kuinka ladata iTunes Windows 10: ssä itse
Lue Lisää

Kuinka ladata iTunes Windows 10: ssä itse

iTune on Applen oma muiikin ja laitteiden hallintaovellu. en avulla käyttäjät voivat ladata muiikkia iTune-kaupata ja järjetää ne. en avulla voit toitaa muiikkitiedotoja,...
Viisi parasta iOS-salasananhallintaohjelmaa, joilla on täydellinen opas
Lue Lisää

Viisi parasta iOS-salasananhallintaohjelmaa, joilla on täydellinen opas

Applen uui iO-päivity helpottaa alaananhallinnan käyttöä iO-laitteellai. Nämä kolmannen oapuolen ovelluket ovat todella vaikuttavia ja äätävät paljon ...
Ratkaistu Kuinka tarkastella tallennettuja salasanoja Android-laitteessa
Lue Lisää

Ratkaistu Kuinka tarkastella tallennettuja salasanoja Android-laitteessa

Jo joudut joku antamaan monimutkaien alaanan kirjautuakei tilillei mobiililaitteella, voit tuntea ikävyytehtävän käillä. Tai jo unohdat alaanan tilille tai verkkoivutolle, inu...