Tässä artikkelissa jaan kokemukseni ideoiden valinnasta tuotteidemme toiminnallisuuden kehittämiseen ja kerron kuinka tärkeimmät kehitysvektorit säilytetään.
Kehitämme automaattista selvitysjärjestelmää (ACS) - laskutusta. Termi
Tuotteemme käyttöikä on 14 vuotta. Tänä aikana järjestelmä on muuttunut teollisen mittarin ensimmäisistä versioista modulaariseksi kokonaisuudeksi, joka koostuu 18 toisiaan täydentävästä tuotteesta. Yksi ohjelmien pitkäikäisyyden tärkeimmistä näkökohdista on jatkuva kehittäminen. Ja ideoita tarvitaan kehittämiseen.
Ideat
lähteet
On 5 lähdettä:
- Yritystietojärjestelmien kehittäjän tärkein ystävä on asiakas. Ja asiakas on kollektiivinen kuva päättäjistä, projektisponsoreista, prosessien omistajista ja toteuttajista, talon sisäisistä IT-asiantuntijoista, tavallisista käyttäjistä ja suuresta määrästä eriasteisesti kiinnostuneita ihmisiä. Meille on tärkeää, että jokainen asiakkaan edustaja on potentiaalinen ideoiden toimittaja. Pahimmassa tapauksessa saamme vain negatiivista palautetta järjestelmän ongelmista. Parhaimmillaan asiakkaan puolella on henkilö, joka on jatkuva parannusideoiden lähde, joka tarjoaa jäsenneltyä tietoa asiakkaan tarpeista.
- meidän myyjät ja tilivastaavat ovat toiseksi tärkein parannusideoiden lähde. He kommunikoivat paljon ja aktiivisesti alan edustajien kanssa, vastaanottavat ensikäden laskutustoimintoja koskevia pyyntöjä potentiaalisilta asiakkailta. Kauppiaiden ja tilien tulee olla tietoisia kaikista merkittävistä toiminnallisuuksiensa muutoksista ja kilpailijoiden uusimmista ohjelmistopäivityksistä, pystyä perustelemaan eri ratkaisujen hyvät ja huonot puolet. Juuri nämä työntekijämme kokevat ensimmäisenä, jos joistakin laskutusominaisuuksista tulee tosiasiallinen standardi, jota ilman ohjelmistoa ei voida pitää täydellisenä.
- Tuotteen omistaja joku huippujohtajistamme tai erittäin kokenut projektipäällikkö. Pitää yrityksen strategiset tavoitteet mielessä ja muokkaa tuotekehityssuunnitelmia niiden mukaisesti.
- arkkitehti, henkilö, joka ymmärtää valittujen/käytettyjen teknisten ratkaisujen mahdollisuudet ja rajoitukset sekä niiden vaikutuksen tuotekehitykseen.
Kehitys- ja testaustiimit. Ihmiset, jotka ovat suoraan mukana tuotekehityksessä.
Osumien luokittelu
Saamme raakadataa lähteistä - kirjeistä, lipuista, suullisista pyynnöistä. Kaikki
valitukset luokitellaan:
- Kuulemiset merkitys "Kuinka se tehdään?", "Kuinka se toimii?", "Miksi se ei toimi?", "En ymmärrä...". Tämän tyyppiset puhelut menevät tason 1 tukilinjalle. Konsultointia on mahdollista kouluttaa uudelleen muun tyyppisiksi valituksiksi.
- Tapahtumat joiden merkitys on "ei toimi" ja "virhe". Käsittelee 2 ja 3 tukilinjaa. Jos korjaustiedosto on korjattava ja vapautettava nopeasti, se voidaan siirtää tuesta suoraan kehitystyöhön. Se on mahdollista luokitella uudelleen muutospyynnöksi ja lähettää se ruuhkaan.
- Muutos- ja kehityspyynnöt. Päästä tuoteruuhkaan ohittaen tukilinjat. Mutta heille on olemassa erillinen käsittelymenettely.
Sellaisia osumatilastoja on olemassa - heti julkaisun jälkeen osumien määrä kasvaa 10-15% lyhyen aikaa. Puhelut tulevat myös silloin, kun pilvipalveluihimme tulee uusi asiakas, jolla on paljon käyttäjiä. Ihmiset oppivat käyttämään ohjelmiston uusia ominaisuuksia, he tarvitsevat neuvoja. Pienikin asiakas polttaa helposti yli 100 tuntia konsultaatiota kuukaudessa aloittaessaan työn järjestelmässä. Siksi uutta asiakasta yhdistäessämme varaamme aina ajan alustavaan konsultaatioon. Usein valitsemme jopa tietyn asiantuntijan. Vuokrakustannukset eivät tietenkään korvaa näitä työvoimakustannuksia, mutta ajan myötä tilanne tasoittuu. Sopeutumisaika kestää pääsääntöisesti 1-3 kuukautta, minkä jälkeen neuvonnan tarve vähenee merkittävästi.
Aiemmin käytimme itse kirjoitettuja ratkaisuja puheluiden tallentamiseen. Mutta vähitellen siirtyi Atlassian-tuotteisiin. Ensin siirrettiin kehitystyötä helpottamaan Agile-työskentelyä, sitten tuki. Nyt kaikki kriittiset prosessit sijaitsevat Jira SD:ssä, ja ne on varustettu erilaisilla Jira-laajennuksilla sekä Confluencella. Itsekirjoitetut ratkaisut jäivät vain yrityksen toiminnan ei-kriittisiin prosesseihin. Kävi ilmi, että tehtävämme ovat nyt päästä päähän, ne voidaan siirtää tuen ja kehityksen välillä hyppäämättä järjestelmästä toiseen.
Tästä paketista saamme tietoa kaikista tehtävistä, suunnitelluista ja toteutuneista työvoimakustannuksista, voimme käyttää erilaisia laskutusvaihtoehtoja asiakkaille sekä tuottaa dokumentaatiota sisäisiin tarpeisiin ja raportin asiakkaille.
Muutospyyntöjen käsittely
Tyypillisesti nämä pyynnöt tulevat ominaisuusvaatimusten muodossa. Analyytikkomme tutkii pyynnön, luo spesifikaation ja huipputason TOR:n. Siirtää spesifikaation ja TOR:n hyväksymispyynnön lähettäneelle henkilölle - meidän on oltava varmoja, että puhumme samaa kieltä asiakkaan kanssa.
Saatuaan asiakkaalta vahvistuksen, että olemme ymmärtäneet toisiamme oikein, analyytikko kirjaa pyynnön tuotevarastoon.
Tuotteen ominaisuuksien hallinta
Tilauskanta kerää vastaanotetut muutos- ja kehityspyynnöt. Puolen vuoden välein kokoontuu tekninen neuvosto, johon kuuluu johtaja, ylläpito-, kehitys-, myyntipäälliköt ja järjestelmäarkkitehti. Keskustelumuodossa neuvosto analysoi ja priorisoi hakemukset ruuhkasta ja sopii 5 kehitystehtävää toteutettavaksi seuraavassa julkaisussa.
Itse asiassa tekninen neuvosto vastaa alan ja markkinoiden vaatimuksiin ottaen huomioon hakemuksiin kirjatut tarpeet. Kaikki vähämerkityksinen jää ruuhkaan eikä saavuta kehitystä.
Muutospyyntöjen ja rahoituksen luokittelu
Kehitys on kallista. Siksi kerromme heti, mitä vaihtoehtoja meillä voi olla, jos muutospyyntö tulee asiakkaalta, ei työntekijältä.
Muutospyynnöt luokitellaan seuraavasti: toimialakohtaiset tarpeet tai yrityksen yksilölliset ominaisuudet; huomattava määrä uusia toimintoja tai pieni korjaus. Pienet korjaukset ja yksittäiset pyynnöt käsitellään ilman hienouksia. Yksittäiset pyynnöt lasketaan ja toteutetaan tietylle asiakkaalle osana projektityötä hänen kanssaan.
Jos kyseessä ei ole valtava teollisuuden tarve ja toiminnallisuuden määrä on suuri, voidaan tehdä päätös uuden erillisen moduulin kehittämisestä, joka myydään päätoimintojen lisäksi. Jos asiakkaalta tulee tällainen pyyntö, voimme kattaa moduulin kehittämiskustannukset, toimittaa asiakkaalle moduulin ilmaiseksi tai osamaksulla ja saattaa moduulin julkiseen myyntiin. Tällaisessa tilanteessa asiakas ottaa osan metodologisesta taakasta ja itse asiassa suorittaa moduulin pilottitoteutuksen.
Jos tämä on valtava teollisuuden tarve, voidaan tehdä päätös sisällyttää perustuotteeseen uusia toimintoja. Kustannukset maksamme tässä tapauksessa kokonaan me, ja uudet toiminnot näkyvät ohjelmien nykyisessä versiossa.
Vanhoille asiakkaille tarjotaan päivitys.
Saattaa myös olla, että useilla asiakkailla on samanlainen tarve, mutta se ei vedä massatuotteeseen. Tässä tapauksessa voimme lähettää eritelmän näille asiakkaille ja tarjota kehityskulujen jakamista heidän kesken. Loppujen lopuksi kaikki voittavat: asiakkaat saavat toiminnallisuuden toteutuksen edullisesti, me rikastamme tuotetta, hetken kuluttua myös muut markkinaosapuolet voivat saada toiminnallisuuden omaan käyttöönsä.
DevOps
Kehitys valmistelee kaksi suurta julkaisua vuodessa. Jokaisessa julkaisussa on varattu aikaa 5 tekniseltä neuvostolta saadun tehtävän toteuttamiseen. Näin ollen liikevaihdon takana emme koskaan unohda tuotteen kehitystä.
Jokainen julkaisu käy läpi asianmukaiset testaukset ja dokumentaatiot. Lisäksi tämä julkaisu asennetaan vastaavan asiakkaan testiympäristöön, joka puolestaan tarkistaa kaiken huolellisesti ja vasta sen jälkeen julkaisu siirtyy tuotantoon.
Julkaisujärjestelmän lisäksi on olemassa nopea bugikorjausmuoto, jotta asiakkaat eivät elä virheiden kanssa kuuteen kuukauteen. Tämän keskitason muodon avulla voit reagoida nopeasti ensimmäisten prioriteettien tapauksiin ja täyttää ilmoitetun SLA:n.
Kaikki yllä oleva pätee ensisijaisesti yrityssektoriin ja on-premise-ratkaisuihin. Pk-segmenttiin keskittyneissä pilvipalveluissa asiakkailla ei ole näin laajoja mahdollisuuksia osallistua tuotekehitykseen. Pk-yritysten vuokrasopimus ei edes ehdota tätä. Yrityksen selkeiden vaatimusten muodossa olevan muutospyynnön sijaan on vain tavanomaista palautetta ja palvelua koskevia toiveita. Yritämme kuunnella, mutta tuote on massiivinen ja yhden asiakkaan halu tuoda jotain tuttua vanhasta historiallisesta järjestelmästään voi olla ristiriidassa koko järjestelmän kehittämisstrategian kanssa.
Lähde: will.com