Ebben a cikkben megosztom tapasztalataimat a termékeink funkcionalitásának fejlesztésére vonatkozó ötletek kiválasztásával kapcsolatban, és elmondom, hogyan lehet fenntartani a fejlesztés fő vektorait.
Kidolgozunk egy automatizált elszámolási rendszert (ACP) - számlázást. Term
Termékünk élettartama 14 év. Ez idő alatt a rendszer az ipari tarifarendszer első változataiból egy 18 egymást kiegészítő termékből álló moduláris komplexummá fejlődött. A programok hosszú élettartamának egyik legfontosabb szempontja a folyamatos fejlesztés. A fejlesztéshez pedig ötletek kellenek.
Идеи
forrás
5 forrás létezik:
- A vállalati információs rendszereket fejlesztő fő barátja az ügyfél. Az ügyfél pedig a döntéshozók, a projektszponzorok, a folyamatok tulajdonosai és végrehajtói, a házon belüli informatikusok, a hétköznapi felhasználók és a nagyszámú érdeklődő egyének kollektív képe. Fontos számunkra, hogy a megrendelő minden képviselője potenciális ötletszállító legyen. Rosszabb esetben csak negatív visszajelzést kapunk a rendszerben fellépő problémákról. A legjobb esetben a kliens oldalán van egy személy, aki állandó fejlesztési ötletek forrása, strukturált információkkal szolgál az ügyfél igényeiről.
- mi értékesítők és ügyfélmenedzserek a második legfontosabb fejlesztési ötletek forrása. Aktívan és széles körben kommunikálnak az iparág képviselőivel, és első kézből kapnak kérdéseket a számlázási funkciókkal kapcsolatban a potenciális ügyfelektől. Az eladóknak és a fiókoknak tisztában kell lenniük a funkcionalitásukban bekövetkezett minden jelentős változással és a versenytársak szoftvereinek legújabb frissítéseivel, és tudniuk kell indokolni a különböző megoldások előnyeit és hátrányait. Ők azok a munkatársaink, akik elsőként érzékelik, ha egyes számlázási lehetőségek de facto szabvánnyá válnak, amelyek nélkül a szoftver nem tekinthető teljesnek.
- Terméktulajdonos — egyik felsővezetőnk vagy egy nagyon tapasztalt projektmenedzser. Szem előtt tartja a vállalat stratégiai céljait, és ezekhez igazítja a termékfejlesztési terveket.
- építészmérnök, olyan személy, aki megérti a választott/használt technológiai megoldások képességeit és korlátait, valamint azok termékfejlesztésre gyakorolt hatását.
Fejlesztő és tesztelő csapatok. Olyan emberek, akik közvetlenül részt vesznek a termékfejlesztésben.
A kérelmek osztályozása
Nyers adatokat kapunk forrásokból - levelek, jegyek, szóbeli kérések. Minden
A fellebbezések osztályozása:
- Konzultációk jelentéssel: „Hogyan kell csinálni?”, „Hogyan működik?”, „Miért nem működik?”, „Nem értem...”. Az ilyen típusú kérések az 1. szintű támogatási vonalhoz érkeznek. Lehetőség van a konzultáció átképzésére más típusú kérésekre is.
- Incidensek „Nem működik” és „Hiba” jelentéssel. 2 és 3 támogatási vonal feldolgozza. Ha azonnali korrekciókra és egy javítás kiadására van szükség, akkor azok közvetlenül átvihetők a támogatásból a fejlesztésbe. Lehetőség van változtatási kéréssé átminősíteni és hátralékba küldeni.
- Változási és fejlesztési kérések. A támogatási vonalakat megkerülve bejutnak a terméklemaradásba. De külön feldolgozási eljárás van számukra.
A kérésekről van statisztika: közvetlenül a megjelenés után rövid időre 10-15%-kal nő a kérések száma. Akkor is megnövekszik a kérések száma, amikor nagy számú felhasználóval rendelkező új kliens érkezik felhőszolgáltatásainkhoz. Az emberek megtanulják használni az új szoftveres képességeket, tanácsra van szükségük. Még egy kis ügyfél is, amikor elkezd dolgozni a rendszerben, könnyedén éget el több mint 100 órányi konzultációt havonta. Ezért új ügyfél csatlakozásakor mindig tartunk időt a kezdeti konzultációra. Gyakran még egy konkrét szakembert is kiválasztunk. A bérleti díj természetesen nem fedezi ezeket a bérköltségeket, de idővel kiegyenlítődik a helyzet. Az adaptációs időszak általában 1-3 hónapig tart, ezt követően jelentősen csökken a tanácsadási igény.
Korábban saját írásos megoldásokat használtunk a kérések tárolására. De fokozatosan áttértünk az Atlassian termékekre. Először fejlesztést vittünk át, hogy megkönnyítsük az Agile szerinti munkát, majd a támogatást. Mostantól az összes kritikus folyamat a Jira SD-ben él, valamint a Jira különféle bővítményei, valamint a Confluence támogatják őket. Az önállóan megírt megoldások csak azoknál a folyamatoknál maradtak meg, amelyek nem voltak kritikusak a cég tevékenysége szempontjából. Kiderült, hogy feladataink ma már átívelőek, és átvihetők a támogatás és a fejlesztés között anélkül, hogy egyik rendszerről a másikra ugrálnánk.
Ezen a linken adatokat kaphatunk az összes feladatról, a tervezett és tényleges munkaerőköltségről, különböző árazási lehetőségeket használhatunk az ügyfelek számára, valamint dokumentációt állíthatunk elő a belső igényekhez és az ügyfelek felé történő jelentésekhez.
Módosítási kérelmek feldolgozása
Az ilyen kérések jellemzően funkcionalitási követelmények formájában érkeznek. Elemzőnk megvizsgálja a kérést, elkészíti a specifikációt és a legmagasabb szintű műszaki specifikációkat. Átadja a specifikációt és a műszaki leírást annak a személynek, aki ezt a jóváhagyási kérelmet benyújtotta - meg kell győződnünk arról, hogy ugyanazt a nyelvet beszéljük az ügyféllel.
Az elemző a megrendelőtől kapott visszaigazolást követően, hogy helyesen megértettük egymást, a kérést bevezeti a termékállományba.
Termék funkcionalitás menedzsment
A lemaradásban halmozódnak a beérkező változtatási és fejlesztési kérelmek. Az igazgatóból, a támogatási, fejlesztési, értékesítési vezetőkből és a rendszertervezőből álló műszaki tanács félévente ülésezik. A tanács vita formájában elemzi és rangsorolja a lemaradásból származó pályázatokat, és 5 fejlesztési feladatban állapodik meg a következő kiadásban való megvalósításhoz.
Valójában a műszaki tanács az ipari és piaci igényekre reagál az alkalmazásokban megfogalmazott igények áttekintésével. Minden, aminek nincs jelentősége, lemaradásban marad, és nem éri el a fejlesztést.
Változási kérelmek és pénzügyek osztályozása
A fejlesztés drága. Ezért azonnal közöljük, hogy milyen lehetőségeink lehetnek, ha a változtatási kérelem ügyféltől és nem alkalmazotttól érkezett.
A változtatási kérelmeket a következők szerint osztályozzuk: iparági igény vagy a vállalkozás egyedi jellemzői; jelentős mennyiségű új funkció vagy egy kisebb javítás. A kisebb javításokat és az egyedi kéréseket minden sallang nélkül feldolgozzuk. Az egyedi igények kiszámítása és végrehajtása egy adott ügyfél számára a vele folytatott projektmunka részeként történik.
Ha ez nem egy hatalmas iparági igény, és a funkcionalitás mennyisége nagy, akkor döntés születhet egy új külön modul kifejlesztéséről, amelyet a fő funkcionalitás mellett értékesítenek. Ha az ügyféltől ilyen igény érkezik, akkor a modul fejlesztésének költségeit fedezni tudjuk, a modult ingyenesen vagy részleges ellenérték fejében átadjuk az ügyfélnek, és magát a modult is eladásra kínáljuk. Ilyen helyzetben az ügyfél átveszi a módszertani terhelés egy részét, és lényegében a modul pilot implementációját hajtja végre magán.
Ha ez óriási iparági igény, akkor döntés születhet arról, hogy új funkciókat építsenek be az alaptermékbe. A költségek ebben az esetben teljes mértékben ránk hárulnak, az új funkcionalitás pedig a programok aktuális verziójában jelenik meg.
A régi ügyfelek frissítést kapnak.
Az is előfordulhat, hogy több vásárlónak is van hasonló igénye, de ez nem minősül tömegterméknek. Ebben az esetben ezeknek az ügyfeleknek elküldhetjük a specifikációt, és felajánlhatjuk a fejlesztési költségek megosztását közöttük. A végén mindenki nyer: a vásárlók olcsón kapják meg a funkcionalitást, mi gazdagítjuk a terméket, és egy idő után a többi piaci szereplő is hozzájuthat a funkcionalitáshoz.
DevOps
A fejlesztés évente két nagyobb kiadást készít elő. Minden kiadásban a műszaki tanácstól kapott 5 feladat végrehajtására van fenntartva idő. Így a rutin közepette soha nem feledkezünk meg a termékfejlesztésről.
Minden kiadás megfelelő tesztelésen és dokumentáción megy keresztül. Ezután ez a kiadás a megfelelő ügyfél tesztkörnyezetébe kerül telepítésre, aki viszont mindent alaposan ellenőriz, és csak ezután kerül át a termelésbe.
A kiadási rendszeren kívül van egy formátum a gyors hibajavításokhoz, így a kliensek hat hónapig nem élnek hibákkal. Ez a köztes formátum lehetővé teszi, hogy gyorsan reagáljon az elsőrangú incidensekre, és teljesítse a megadott SLA-kat.
A fentiek mindegyike elsősorban a vállalati szektorra és az on-premise megoldásokra igaz. A kis- és középvállalkozások szegmensét célzó felhőszolgáltatások esetében nincs ilyen széles lehetőség az ügyfelek számára a termékfejlesztésben való részvételre. Az SMB kölcsönzési formátum ezt nem is feltételezi. A céges fél egyértelmű követelményei formájában megfogalmazott változtatási kérés helyett itt csak szokásos visszajelzések és kívánságok vannak a szolgáltatással kapcsolatban. Igyekszünk hallgatni, de a termék masszív, és az egyik ügyfél vágya, hogy valami ismerőst hozzon a régi történeti rendszeréből, ellentmondhat a rendszer egészének fejlesztési stratégiájának.
Forrás: will.com