mainisime seda eelmises postituses parima tarkvara valimise kohta, milles keskendusimeenda eelhinnang ettevõtte äri (ilma milleta pole võimalik tarka valikut teha). Samuti näeme, et hea valiku jaoks on vaja arvestada piiratud arvu müüjatega. Seejärel analüüsida mitte ainult lahendusi "tehnilisest" vaatenurgast, vaid ka nende pakutavaid teenuseid ja inimressursside korraldamist, mis on meie ettevõttes vajalikud, et uuest tarkvarast maksimumi saada. Vastasel juhul kulutame oma raha halvasti, saamata soovitud soodustusi.
Nüüd astugem samm tagasi ja küsime endalt, millised neist funktsionaalsed nõuded ja millised neist kuidas osta peab esitama meie vajadustele ideaalse lahenduse: lühidalt öeldes, millised on peamised eelised, mida me parimast tarkvarast leiame. Nagu ka meie ettevõtte esialgse analüüsi puhul, me ei võta arvesse ühtegi konkreetset toodet ega tehnilisi kirjeldusi: see on järgmine samm. Praegu täidame lihtsalt kontrollnimekirja üksuste "linnuke" märkimisega, mis on järgmistes sammudes kasulikud.
"Me küsime endalt, millised neist funktsionaalsed nõuded ja millised neist kuidas osta peab esitama meie vajadustele ideaalse lahenduse: lühidalt öeldes, millised on peamised eelised, mida me parimast tarkvarast leiame "
Ja ka sel juhul meie oma ülesandeloend see on liigendatud ja hõlmab rohkem otsustajaid meie ettevõtte sisemine: kindlasti mitte ainult IT-osakond.
La äriklassi tarkvara valik see võib olla vajaduse tagajärg, mis avaldub meie ettevõtte sisesektoris, või ettevõtte otsene mandaat tippjuhtkond (millel on üldine ülevaade ettevõtte tulevikuhuvidest ja järgitavast strateegiast). Volituse päritolu ise sõltub suuresti sellest, kas vaadeldav protsess on tuum või teisejärguline äri. Pidades meeles, et sageli on uue tarkvara valimine protsesside muutmise võti.
Igal juhul on see tegelikult oluline kõik kaasatud näitlejad (sealhulgas need, kes ilmutavad vajadust, need, kes teevad otsuseid kõrgeimal tasemel, ja need, kellel on tehnilisi ja funktsionaalseid oskusi tulevaste läbirääkimiste pidamiseks) joondatud valiku eesmärgi ja lahenduse omaduste järgi omandada.
Ainult nende eelduste abil saame tegelikult projekti koostada funktsionaalsete nõuete loetelu. Ideaalis tulevad meie kolm asjaosalist (kasutajad, tippjuhid ja tehnilis-funktsionaalsed analüütikud) kokku ühise ettevõtte jaoks ajurünnak. Kahtlemata sõltub see võimalus muutujast aeg (on vaja arvestada sisekulusid definimine ja juhtimine a projekt).
Ja see joondamistoiming on veelgi olulisem, kui arvestada valiku veel ühte aspekti: nagu igal juhul "Ostja teekond", see tähendab ostuprotsess, mis algab vajadusest ja kulgeb läbi turupakkumisest teabe hankimise, võib leiduda ka "Hallid alad". Tegelikult pole harv juhus, kui tippjuhtkond või ettevõtte funktsioonid, kellele lahendus kasu toob, leiavad, et neil on üldised teadmised kasutatavast lahendusest: ta teab, mida tahab, mitte seda, kuidas seda selgelt ja selgesõnaliselt öelda. Ka see on utile spetsialisti tugi IT-valdkonnas, kui neid juhendavad head funktsionaalsed analüütikud, kes panevad paika õiged oskused.
Siin siis mõned küsimused, mida meeskond küsib: milline on üksikasjalik nõuete loetelu? Kas iga punkt on selge kogu kontrollnimekirja koostanud meeskonnale? Kas see, kes läbirääkimisi viib, peab oma mandaati silmas? Ja kas mandaat ise on konkreetne ja üksikasjalik või on selles lünki? Heaks strateegiaks võiks olla Scrumi meetod: kes projektis osaleb, jutustab loo nii, et diskursiivset tüüpi ekspositsioon soosib. defitöös kasutatavate mõistete väljaselgitamine.
Sageli on ettevõtte lahendused turul ei oma kõiki vajalikke funktsioone ostja poolt. Ettevõtte juhid teavad seda algusest peale. Ja see on põhjus, miks pärast kontrollnimekirja koostamist alustame a indeks prioriteet: igal ettevõttel, kui eesmärgid on seatud, on oma.
"Sageli on ettevõtte lahendused turulei oma kõiki vajalikke funktsioone ostja poolt. Ettevõtte juhid teavad seda algusest peale. Ja see on põhjus, miks pärast kontrollnimekirja koostamist alustame a indeks prioriteet"
Mõni soovitab seostada iga nõude jaoks erinev tähtsuse skoor: iga uuritud lahenduse koondhinne on praeguste nõuete ja nende suhtelise tähtsuse summa. See on terve mõistuse nõuanne, kui te ei ole lõpphindamisel liiga skemaatiline: on loomulik, et hinnang lisaks tarkvarale on ka muid tegureid, mis pole seotud tarnijaga. Näeme neid hilisemas postituses.
Et hinnata sisemist tarkvara kvaliteet on vaja mõned asutada objektiivsed mõõdikud (seega väljaspool funktsionaalseid nõudeid, mis on puhtalt subjektiivsed ja mida ettevõte nõuab).
Kui ei teata, milliseid muutujaid toodet mõõta, tähendab seda, et te ei saa oma teadvustada väärtus. Tahame jällegi nimekirja koostada esimene üksikute lahenduste uurimiseks: me kasutame seda mõõturina tegeliku valiku ajal.
Selle teema kohta on lai kirjandus: tegelikult kirjutage lihtsalt otsingumootor "Tarkvara kvaliteet" leida selleteemalisi postitusi ja raamatuid. Kasulik lähtepunkt on hääl Wikipedia, mis loetleb parameetrite kogum väline (st kasutaja poolt tajutava kvaliteediga), et hinnata omandatava lahenduse kvaliteeti. Nende hulgas: õigsus, töökindlus, vastupidavus, tõhusus. Aga ka interjöör, mida saab kontrollida arendajad: hooldatavus, korduvkasutatavus, modulaarsus on mõned loetletud näited.
Ka sel juhul otsustab meeskond erinevate parameetrite prioriteediindeks: näiteks ettevõtte juhtkond, kellel on projekti strateegiline visioon, võib tarkvara korduvkasutatavusele omistada teisese tähtsuse. Ja muidugi, selles tarkvaravaliku etapis on hea teada programmi arvamust kvaliteedifunktsioon ettevõtte (kui see on olemas).
See on oluline muutuja: enne läbirääkimiste alustamist peate meeles pidama eelarve kokku, mis teil on saadaval tarkvara omandamine (nii tarkvara enda kui ka valimistoimingute jaoks vajalike inimtundide kulude osas). Realistliku summa kindlaksmääramiseks on mõnel juba ettevõtte jaoks varem omandatud lahenduste võrdlusalus, teistel on sama sektori (või samast tööstuskontsernist) kolleegide usaldus suusõnaline. Tarkvara valimise protsessi hõlbustab kontrollimine, kui palju on varem sarnastele lahendustele kulutatud.
"Peate meeles pidama kogu eelarvet, mis teil on programmi jaoks olemas tarkvara omandamine: kontrollige, kui palju on varem sarnastele lahendustele kulutatud, hõlbustab see tegelikult tarkvara valimise protsessi "
Loomulikult on ettevõtte tasemel tarkvara hind otsene tagajärg mitte ainult selle olemuslikule kvaliteedile, vaid ka tarnija poolt selle väljatöötamiseks ja arendamiseks tehtud töösse: kulude amortiseerimiseks on olemas paindlikud omandamisvormid (näeme neid punktis 6).
Sellest ei räägita kunagi piisavalt: iga ettevõte leiab endale asja suurenev andmemaht mis on seotud tema äri ja klientidega. Samal ajal teame, et viimastel aastatel on inimeste arv kasvanud küberrünnakud ettevõtte andmebaasides. Teie teabe kaitsmine on seetõttu teabe haldajate otsene ja vältimatu vastutus.
Läbirääkimisi pidavate isikute üheks ülesandeks on seega teada pakkuja kehtestatud kaitsemeetmeid. Samas ei saa algteadmised riskidest ja lahendustest kahjustada: IKT osakonna juhataja saab ta oma ettevõtte kontakte teavitada mõlemast aspektist.
Otsustage, kas eelistate lahendust pilves (kauginfrastruktuuril) või kohapeal (ettevõtte serveritesse installitud) pole lihtsalt nurisemine: eelarvel ja andmehalduse tüübil on otsene mõju kuidas tarkvara hallatakse.
Paljude juhtide jaoks üks eeldusel olev lahendus see on endiselt seotud stabiilsuse ja kontrolli tajumisega: siiski tuleb kaaluda kõige olulisemaid investeeringuid. Teisest küljest pilv see on paindlikum ja hinna osas odavam, kuid nõuab, et tarnija annaks suuremad tagatised andmete turvalisuse ja kanalite toimivuse osas (st programmi edastamise ja täitmise kiirus).
Muutub ka kulude eeldamise viis: eeldatav hind põhineb üldjuhul tasumisel litsentsimine, kohandamiskulud, esialgne seadistamine, järgnevad hoolduskulud ja nii edasi. Pilv on eeskujuks maksa kasutamise eest: suurem viljakus, seda suuremad kulud. Tavaliselt muudetakse pilverežiimis kõik kulud moodustavad kulud tasuks, mis neid kokku võtab, tavaliselt madalamaks (võrreldes mitmeaastase lepingulise kohustusega, sageli kolmest kuni viie aastani).
See võib tunduda paradoks, kuid see on vaid näiliselt: hea kontrollnimekiri ootustest, mida me uuele lahendusele seame ... ei jäta tähelepanuta muutmist vajava tarkvara analüüs. Muidugi ei pea me silmas esimese installi olukorda.
"Hea kontrollnimekiri ootustest, mille me uuele lahendusele seame ... ei jäta tähelepanuta muutmist vajava tarkvara analüüs"
Esiteks on eesmärk näidata nõrkused: on eripärad, mis ajendasid meid otsima teistsugust toodet. Isegi tarkvara vananemine ja sama agressiivne kohtlemine võivad osutuda valeks käiguks.
Võib-olla peame siiski ka mõned üles kirjutama punti di forza: tegelikult ei öelda, et vana lahendusega oli protsessi juhtimine kõigis aspektides puudulik.
Ka selle analüüsi ajal on kasulik teha ühistööd: funktsionaalsed teadmised e tehnilised teadmised need käivad käsikäes ja aitavad mõlemad kaasa tarkvara kvaliteedi konkreetsemale hindamisele. Isegi seda, mida muuta!
Isiklikult arvan, et kui tarkvara pole enam adekvaatne, pole see kindlasti süü selles, kes omal ajal valiku tegid. lihtsalt turg on muutunud ja see tarkvara ei vasta uutele ärivajadustele. Seetõttu on uusim suundumus üha enam a refactoring pidevad rakendused.
autor Paolo Ravalli
Catania polikliinikus viidi läbi oftalmoplastika operatsioon Apple Vision Pro reklaamivaaturiga…
Peenmotoorika arendamine värvimise kaudu valmistab lapsi ette keerukamate oskuste, nagu kirjutamise, jaoks. Värvimiseks…
Meresõidusektor on tõeline ülemaailmne majanduslik jõud, mis on liikunud 150 miljardi suuruse turu poole...
Eelmisel esmaspäeval teatas Financial Times tehingust OpenAI-ga. FT litsentsib oma maailmatasemel ajakirjandust…
