Kemikaaliviraston kehittämisselvitys
Mitä viraston pitäisi valmistautua ennen kuin se luovuttaa kehityksen.
Virasto-opas kehityksen luovutuksen valmisteluun: asiakkaan tulos, mallit, laajuus, hyväksynnät, riippuvuudet, kaupalliset vastuut ja hyväksyminen.
Hyvä kehitysluovutus ei edellytä, että virastosta tulee ohjelmistokonsultti. Se edellyttää selkeää selvitystä asiakkaan tuloksesta, toimeksiannosta ja päätöksistä, jotka jäävät virastolle.
Tavoitteena on tehdä vastuullisuus näkyväksi. Kehittäjän ei pitäisi joutua arvaamaan, onko puuttuva näyttö, integraatio vai myöhäinen asiakaspyyntö osa sovittua sitoumusta.
Kuvaile asiakkaan tulosta ennen teknologiaa
Selitä, mitä asiakas yrittää toimittaa ja kuka käyttää sitä. Täydennä nämä mallit. Voi olla osa tehtävää, mutta se ei selitä, mitä sovelluksen on täytettävä.
Esimerkkinä voisi olla esimerkiksi: Luo kumppaniportaali, jossa hyväksytyt kumppanit esittävät pyyntöjä ja asiakkaan henkilöstö tarkistaa ne. Virasto toimittaa käyttöliittymän suunnittelun ja vahvistaa asiakaspalautteen.
Se on esimerkki, ei viittaus olemassa olevaan asiakastoimintaan.
Määrittele kehittäjän raja
Ilmoita, kattaako komissio täydellisen hakemuksen, properend-sovelluksen, taustaosan vai integraation. Nimeä osat, jotka virasto tai jokin muu osapuoli toimittaa.
Osittainen rakenne tarvitsee selkeitä integraatiopisteitä. Kuka tarjoaa API:n? Kuka omistaa lopullisen käyttöönoton? Kuka testaa yhdistetyn tuloksen? Ilman näitä vastauksia pieni komponentti voi saada paljon suuremman implisiittisen vastuun.
Antakaa suunnittelupäätökset, mukaan lukien valtiot
Sovellettavien mallien tulisi tunnistaa suunniteltu työpöytä- ja mobiilikäyttäytyminen sekä näytön tärkeät tilat. Tyhjä sisältö, validointivirheet, lataaminen ja valmistuminen edellyttävät kaikki vastausta.
Jos virasto ei ole suunnitellut valtiota, merkitse se ratkaisuksi. Se on parempi kuin jättää kehittäjä keksimään käyttäytymistä ja myöhemmin huomaamaan, että asiakas odotti jotain muuta.
Mikä omaisuus ja teksti on hyväksytty ja ovat väliaikaisia? Kehittämisympäristön ei pitäisi saada paikan haltijaa näyttämään hyväksytyltä asiakkaalle suunnatulta kopiolta.
Uudelleentarkastelun ja viestintäpolun laatiminen
Nimeä yksi henkilö, joka vahvistaa palautetta virastolle. Selitä, osallistuuko kehittäjä asiakkaiden kokouksiin, vastaako hän kysymyksiin viraston kautta vai vain sovittuihin teknisiin keskusteluihin.
Määrittele, kuka voi hyväksyä muutoksen. Asiakasidea, agenttimieltymys ja sopimusvaatimus eivät ole automaattisesti sama asia. Päätösrekisterin pitäminen auttaa kaikkia ymmärtämään, mitä on todella tullut soveltamisalaan.
Valkoisen merkin järjestelyssä tarvitaan myös käytännön sääntöjä: tutustuminen esittelyihin, pääsy, tuotemerkkien merkitseminen ja lupa mainita hanke julkisesti. Nämä kohdat kuuluvat sopimukseen eivätkä oletuksiin.
Jaa riippuvuudet ilman salaisuuksia huolimattomasti
Listaa asiaankuuluvat järjestelmät, asiakirjat, vastaanottojärjestelyt, arkistot ja kolmansien osapuolten tilit. Selitä kuka ne omistaa ja miten asianmukainen pääsy tarjotaan.
Älä aseta salasanoja tai API-salaisuuksia yleiseen projektin lyhyesti tai tavalliseen tiedustelumuotoon. Käytä sovittua suojattua kanavaa ja rajoita pääsyä siihen, mitä tehtävä tarvitsee.
Integraatioiden osalta mukana ovat käytettävissä olevat testitilit, ilman yksityisiä tietoja otettavat hyötykuormat ja yhteystiedot liiketoiminnan sääntökysymyksiä varten. API-linkki ei yksin selitä, mitä asiakas odottaa yhteyden saavuttavan.
Tehkää hyväksymisestä konkreettista
Kuvailkaa, mitä virasto tarkastelee jokaisessa virstanpylväässä. Hyödyllinen hyväksyntäesimerkki kertoo toiminnasta ja tuloksesta: kumppani esittää pyynnön, henkilöstö voi tarkistaa sen ja kumppani näkee sovitun aseman.
Sovitaan siitä, miten asiat kirjataan, miten palautetta yhdistetään ja miten muutoksia käsitellään soveltamisalan ulkopuolella. Tarkoituksena ei ole tehdä korjauksista hankalia. Sen tarkoituksena on erottaa luvatun toiminnon toteuttaminen uuden toiminnon käyttöönotosta.
Määrittele toimituspaketti
Sovittu luovutus voi sisältää koodin, käyttöönottomuistilaput, konfiguraatiotiedot, hallinnon ohjeet ja luettelon riippuvuuksista. Omistus- ja lisenssiehdot määräävät, mitä voidaan siirtää tai käyttää uudelleen; älä päätä niitä pääsystä arkistoon yksin.
Erillinen hyväksyntä, sovittu virhekorjausaika ja mahdollinen tuleva kehitys. Valmistunut projekti ei saa hiljaa muuttua rajattomaksi tekniseksi käytettävyydeksi virastolle tai sen asiakkaalle.
Hyödyllinen ensimmäinen viesti
Anna suunniteltu tulos, osa haluat kehittää, suunnittelu tila, tunnetut integraatiot, haluttu toimitusikkuna ja budjetin parametrit. Sitten nimetä päätöksentekijä ja ensisijainen viestintäjärjestely.
Se riittää keskittyneen keskustelun aloittamiseksi. Yksityiskohtaisesta soveltamisalasta voidaan sopia, kun tärkeät rajat on ymmärretty.
Tutki virastojen kehittämiskumppanuuksia tai lähettää viraston muistion.