Artikulu honetan, gure produktuen funtzionaltasuna garatzeko ideiak hautatzen dudan esperientzia partekatuko dut eta garapenaren bektore nagusiak nola mantendu esango dizut.
Likidazio sistema automatizatua (ACP) garatzen ari gara - fakturazioa. Epea
Gure produktuaren bizitza 14 urtekoa da. Denbora horretan, sistema industria tarifa sistema baten lehen bertsioetatik bata bestearen osagarri diren 18 produktuz osatutako konplexu modular batera igaro da. Programen iraupenaren alderdi garrantzitsuenetako bat etengabeko garapena da. Eta garapenak ideiak behar ditu.
Ideiak
iturri
5 iturri daude:
- Informazio sistemen garatzaile korporatibo baten lagun nagusia da bezeroa. Eta bezeroa erabakiak hartzen dituztenen, proiektuen babesleen, prozesuen jabeen eta exekutatzaileen, barneko IT-en espezialisten, erabiltzaile arrunten eta interesdunen kopuru handi baten irudi kolektiboa da. Guretzat garrantzitsua da bezeroaren ordezkari bakoitza ideien hornitzaile izatea. Kasurik txarrenean, sistemaren arazoei buruzko iritzi negatiboak baino ez ditugu jasotzen. Kasurik onenean, bezeroaren alboan hobekuntzarako ideien iturri etengabea den pertsona bat dago, bezeroaren beharrei buruzko informazio egituratua ematen duena.
- gure saltzaileak eta kontu-kudeatzaileak hobetzeko ideia-iturri garrantzitsuenak dira. Industriako ordezkariekin aktiboki eta zabal komunikatzen dira eta bezero potentzialen fakturazio-funtzionalitateei buruzko lehen eskuko kontsultak jasotzen dituzte. Saltzaileek eta kontuek beren funtzionalitatean eta lehiakideen softwarearen azken eguneraketen berri izan behar dute, eta irtenbide ezberdinen alde onak eta txarrak justifikatu behar dituzte. Hauek dira gure langileak fakturazio-gaitasun batzuk de facto estandar bilakatzen direla sumatzen duten lehenak, eta hori gabe softwarea ezin da osatutzat jo.
- Produktuen jabea β gure goi-zuzendarietako bat edo esperientzia handiko proiektu-kudeatzaile bat. Konpainiaren helburu estrategikoak gogoan ditu eta horien arabera doitzen ditu produktuak garatzeko planak.
- arkitektoak, aukeratutako/erabilitako soluzio teknologikoen gaitasunak eta mugak eta produktuaren garapenean duten eragina ulertzen dituen pertsona.
Garapen eta proba taldeak. Produktuaren garapenean zuzenean parte hartzen duten pertsonak.
Eskaeren sailkapena
Datu gordinak jasotzen ditugu iturrietatik: gutunak, tiketak, hitzezko eskaerak. Denak
errekurtsoak sailkatzen dira:
- Aholkularitza βNola egin?β, βNola funtzionatzen du?β, βZergatik ez du funtzionatzen?β, βEz dut ulertzen...β esanahiarekin. Mota honetako eskaerak 1. mailako laguntza lerrora doaz. Kontsulta beste eskaera mota batzuetara birmoldatzea posible da.
- Gorabeherak "Ez du funtzionatzen" eta "Errorea" esanahiarekin. 2 eta 3 laguntza-lerroek prozesatua. Zuzenketak azkar eta adabaki bat askatzea beharrezkoak badira, euskarritik zuzenean garapenera transferi daitezke. Posible da aldaketa-eskaera gisa birkalifikatu eta atzerapenera bidaltzea.
- Aldaketa eta garapen eskaerak. Produktuen atzerapenean sartzen dira, laguntza-lerroak saihestuz. Baina prozesatzeko prozedura bereizi bat dago.
Eskaeren estatistikak daude: kaleratu eta berehala, eskaera kopurua % 10-15 handitzen da denbora laburrean. Erabiltzaile ugari dituen bezero berri bat gure hodeiko zerbitzuetara etortzen denean eskaeren gorakada ere badago. Jendea software gaitasun berriak erabiltzen ikasten ari da, aholkuak behar ditu. Bezero txiki batek ere, sisteman lanean hastean, erraz erretzen ditu hilean 100 ordu baino gehiago kontsultak. Horregatik, bezero berri bat konektatzean, beti erreserbatzen dugu denbora hasierako kontsultetarako. Askotan espezialista zehatz bat ere hautatzen dugu. Alokairuaren prezioak, noski, ez ditu lan kostu horiek estaltzen, baina denborarekin egoera berdindu egiten da. Egokitzapen-epea 1 eta 3 hilabete bitartekoa izan ohi da, eta ondoren aholkularitza-beharra nabarmen murrizten da.
Aurretik, norberak idatzitako irtenbideak erabiltzen genituen eskaerak gordetzeko. Baina pixkanaka Atlassian produktuetara aldatu ginen. Lehenik eta behin, garapena transferitu genuen Agileren arabera lan egitea errazteko, gero laguntza. Orain prozesu kritiko guztiak Jira SD-n bizi dira, eta Jira-rako hainbat pluginek onartzen dute, eta Confluence-n. Norberak idatzitako irtenbideak enpresaren jardueretarako kritikoak ez ziren prozesuetarako bakarrik geratu ziren. Ematen du gaur egun gure zereginak zeharkakoak direla eta laguntza eta garapenaren artean transferi daitezkeela sistema batetik bestera salto egin gabe.
Esteka honetatik zeregin guztiei buruzko datuak lor ditzakegu, aurreikusitako eta benetako lan-kostuak, bezeroentzako hainbat prezio-aukera erabili eta barne beharretarako dokumentazioa eta bezeroei txostenak egiteko.
Aldaketa-eskaerak prozesatzea
Normalean, eskaera horiek funtzionaltasun-eskakizunen forman datoz. Gure analistak eskaera aztertzen du, zehaztapen bat eta goi-mailako zehaztapen teknikoak sortzen ditu. Zehaztapena eta zehaztapen teknikoak onarpen-eskaera hau aurkeztu duen pertsonari transferitzen dizkio, bezeroarekin hizkuntza bera hitz egiten dugula ziurtatu behar dugu.
Bezeroarengandik elkar ongi ulertu genuela berrespena jaso ondoren, analistak eskaera produktuaren backlog-ean sartzen du.
Produktuaren funtzionalitateen kudeaketa
Atzerapenak aldaketa eta garapen eskaerak pilatzen ditu. Sei hilean behin biltzen da kontseilu teknikoa, zuzendariak, laguntza, garapen, salmenta eta sistema-arkitektoak osatzen duten arduradunek. Eztabaida formatuan, udalak atzerapenaren aplikazioak aztertzen eta lehenesten ditu eta hurrengo bertsioan ezartzeko 5 garapen-zeregin adosten ditu.
Izan ere, kontseilu teknikoak industriaren eta merkatuaren eskaerei erantzuten die eskabideetan adierazitako beharrak aztertuz. Garrantzi gutxi duen guztia atzerapenean geratzen da eta ez da garapenera iristen.
Aldaketa Eskaeren Sailkapena eta Finantza
Garapena garestia da. Hori dela eta, berehala esango dizugu zein aukera izan ditzakegun aldaketa eskaera bezero batena bada eta ez langile batena.
Aldaketa eskaerak honela sailkatzen ditugu: industriaren beharra edo enpresaren ezaugarri indibiduala; funtzionalitate berrien kopuru esanguratsua edo konponketa txiki bat. Konponketa txikiak eta eskaera indibidualak inolako frilrik gabe prozesatzen dira. Banakako eskaerak bezero zehatz baterako kalkulatzen eta ezartzen dira, berarekin proiektuaren lanaren zati gisa.
Hau industriaren behar handia ez bada eta funtzionalitate-bolumena handia bada, funtzionalitate nagusiaz gain salduko den modulu bereizi berri bat garatzeko erabakia har daiteke. Bezero batengandik eskaera hori jasoz gero, modulua garatzeko kostuak ordain ditzakegu, bezeroari modulua doan edo partzialki ordainduta eman eta modulua bera salgai jarri. Egoera horretan, bezeroak karga metodologikoaren zati bat hartzen du eta funtsean moduluaren inplementazio pilotu bat egiten du bere baitan.
Hau industria-behar handia bada, orduan oinarrizko produktuan funtzionaltasun berriak sartzeko erabakia har daiteke. Kasu honetan kostuak gure gain daude guztiz, eta funtzionalitate berria programen egungo bertsioan agertzen da.
Bezero zaharrei eguneraketa bat eskaintzen zaie.
Baliteke ere hainbat bezerok antzeko beharra izatea, baina ez du produktu masibo baterako kalifikatzen. Kasu honetan, zehaztapena bidal diezaiekegu bezero horiei eta garapen-kostuak haien artean banatzeko eskaintzeko. Azkenean, denek irabazten dute: bezeroek kostu txikian jasotzen dute funtzionaltasuna, guk produktua aberasten dugu eta denbora pixka bat igaro ondoren, merkatuko beste parte-hartzaileek ere erabil dezakete funtzionaltasuna.
DevOps
Garapenak urtean bi bertsio nagusi prestatzen ditu. Oharra bakoitzean, kontseilu teknikotik jasotako 5 zereginak gauzatzeko denbora gordetzen da. Horrela, errutinaren erdian, ez dugu inoiz produktuen garapena ahazten.
Argitalpen bakoitzak proba eta dokumentazio multzo egoki bat jasaten du. Ondoren, kaleratze hau dagokion bezeroaren proba-ingurunean instalatzen da, eta, aldi berean, dena zorrotz egiaztatzen du eta horren ostean bakarrik oharra ekoizpenera pasatzen da.
Kaleratze sistemaz gain, akatsak azkar konpontzeko formatu bat dago, bezeroak sei hilabetez akatsekin bizi ez daitezen. Tarteko formatu honek lehen lehentasuneko gorabeherei azkar erantzuteko eta adierazitako SLA-ak betetzeko aukera emango dizu.
Aurreko guztia egia da batez ere sektore korporatiborako eta tokiko soluzioetarako. SMB segmentuari zuzendutako hodeiko zerbitzuetarako, ez dago bezeroek produktuaren garapenean parte hartzeko aukera zabalik. SMB alokairu formatuak hori ere ez du bere gain hartzen. Alderdi korporatiboaren eskakizun argien formako aldaketa eskaeraren ordez, hemen zerbitzuaren iritzi eta nahi arruntak baino ez daude. Entzuten saiatzen gara, baina produktua izugarria da eta bezero batek bere sistema historiko zaharretik ezaguna den zerbait ekartzeko nahia sistema osoaren garapen estrategiarekin kontraesan dezake.
Iturria: www.habr.com