Ugrás a tartalomra

Ez zajlik a háttérben egy webes applikáció / webshop készítésekor a Studio Presentnél

így dolgozunk
design
pm
ui
ux
projekt menedzsment
drupal
drupal commerce

Projektmenedzser karrierem kezdete óra örömömet leltem abban, hogy különböző tanulmányokat, cikkeket, útmutatókat olvassak az optimális munkaszervezésről. Hiszek abban, hogy fontos tudni pontosan melyek azok a lépések, amelyeket meg kell tenni egy adott folyamatban annak érdekében, hogy az átadható, funkcionálisan jól működő és nem utolsó sorban jövedelmező legyen. 

Mindennapos kihívás, hogy megfelelő módon igazítjuk a folyamatokat annak érdekében, hogy a kívánt eredményt kapjuk. Ettől még fontosabb, hogy hogyan kommunikáljuk le ezen módosításokat és folyamatokat a kollégák felé. 

Ebben a bejegyzésben be fogom mutatni a Studio Present által használt praktikákat. Az alábbi útmutató első sorban projektmenedzserek, junior projektmenedzserek és az ügyfelek számára készült. Ahogy mindannyian tudjuk, a tanulás egy soha véget nem érő folyamat. Még ma, 15 év tapasztalatával is, folyamatosan tanulok a tapasztalt vezetőktől, befektetőktől, menedzserektől. 

Az elmúlt évtized és a szervezéssel eltöltött idő elég magabiztossá tett ahhoz, hogy tudásom egy részét átadjam a fiatalabb generáció projekt menedzsereinek. De hasznos tudás lehet ez bárkinek, aki szeretné átszervezni munkafolyamatait.  

Tehát kezdjük is el!

Mindig van egy bizonyos híres első email vagy telefon, amely előbbre viszi együttműködésünet és létrejön

Az első találkozás

Mindig azt támogatom, hogy az első találkozónak személyesnek kell lennie. Ha ez valamilyen okból nem lehetséges, akkor a találkozót videochaten keresztül érdemes megtartani.
Az arckifejezések és a testbeszéd kulcsfontosságú tényezők a zavartalan kommunikáció és a jobb megértés szempontjából. Egyértelmű, hogy nem akarunk félreértéseket, főleg nem az együttműködés ezen jelentős fontosságú, első szakaszában.

Az első találkozó alkalmával meg kell próbálnunk a lehető legtöbb információt összegyűjteni a cégről az érintettektől valamint a megvalósítandó alkalmazásról. 

Mi az pontosan, amit az ügyfél el szeretne érni vagy javítani szeretne? Mi a jelenlegi megoldandó feladat, amihez a segítségünket kérik? Mi az applikáció célja?  

Hogyan fog segíteni az applikáció a profitteremtésben vagy a cég költségeinek csökkentésében? 

Miután a fő célok meghatározásra kerültek, rátérhetünk a találkozó második pontjára, ami a saját cégünk bemutatása. Célszerű pontosan bemutatni mik a szabályok és a cégünkön belüli folyamatok, időben hogyan zajlik maga a munkafolyamat és mik az elvárásaink az ügyfél felé. Ügyelnünk kell rá, hogy az ügyfél megértse ezen irányelveket. Ezzel elkerülhetjük a későbbi félreértéseket. 

A találkozó végén rendelkezünk kell egy képpel, fő ötlettel az applikációról, az applikáció legfőbb funkcióiról. Nem kell részletekbe menni - erre később adódik majd elég időnk. 

Ha a projekt több szakaszból áll - és legyünk őszinték a legtöbb projekt ilyen - tudnunk kell hozzávetőlegesen, hogy melyek ezek a szakaszok. Például, ha az ügyfél egy applikációt kér nagykereskedelmi raktárának menedzseléséhez, de ő már tudja, hogy a jövőben az applikáció egy CRM szoftverhez lesz kapcsolva, akkor ezen információ megosztása hasznos, hiszen a teljes munkafolyamatnál ez figyelembe lesz véve, és az eredmény egy jobb alkalmazás lesz. 

A találkozón rendkívül fontos, hogy minden figyelmünket az ügyfél felé fordítsuk. Ebből kifolyólag szokásommá vált, hogy hangfelvételt készítsek a beszélgetésről természetesen az ügyfél megkérdezése után. Ez a hangfelvétel rendkívül hasznosnak bizonyul amikor előkészítjük a következőt:  

Műszaki dokumentáció és vázlat

Amikor komplex web alkalmazást készítünk, mindig megkérem az ügyfelet, hogy delegáljon egy vagy két munkatársat, akikkel közelebbről együtt fogunk dolgozni, és állandó kapcsolatban fogunk lenni. Enélkül egyszerűen elképzelhetetlen, hogy jó szakmai dokumentációt készítsünk vagy a fejlesztést szilárd alapokra helyezzük.  

A dokumentáció elkészítése a legtöbb esetben Google Docs segítségével történik. Íly módon létre tudok hozni vázlatos címeket és alcímeket, szakaszokat, mindezt az első találkozás jegyzeteire építve, immár beleszőve saját meglévő tapasztalatomat is. 

Ezen dokumentum meg van osztva az ügyféllel, de csak átnézésre vagy hozzászólásra - szerkesztési opció nélkül. 

Ez megkönnyíti a hozzászólások és kérdések gyors megválaszolását egy-egy konkrét résznél már a folyamat elején. Ilyenkor az e-mail is egy opció.

Ha az ügyfél nem rendelkezik semmilyen dokumentációval, az azt jelenti, hogy magamra kell vállalnom az irányító szerepet, és az ügyfél szolgáltatja számomra a mérvadó adatokat. Ebben a szakaszban már konzultálok senior programozókkal is. 

Amennyiben az alkalmazás elkészítése túl komplex érdemes vázlatokat, diagramokat készíteni. Ha rendelkezünk ezen vizuális elemekkel a fejlesztést sokkal egyszerűbb átadni a csapatnak vagy az ügyfélnek elmondani hogyan működnek az egyes részek. Diagramok segítségével ábrázolhatjuk a főbb blokkokat az alkalmazáson belül és ezek belső kapcsolatait. 

Diagramok és drótváz (wireframe) elkészítéséhez az Axure RP-t használom a könnyű megosztási lehetőségei miatt. 

Ajánlat drótváz és ui / ux tervezéshez

Az alkalmazás összetettségének és meghatározatlan jellegének függvényében az elmúlt néhány hónapban egy új munkamenet mellett döntöttünk. 

Mielőtt egy hozzávetőleges becslést adnánk a teljes alkalmazásfejlesztésre, először készítünk egy drótváz és design prototípust. 

Az eddigi tapasztalatokat figyelembe véve könnyedén meghatározzuk mennyi időre van szükség az adott projekt kivitelezéséhez. 

Miután elkészült a design, az ügyfél és a fejlesztő csapat is képet kap a projektről. Összehasonlítva az egyszerű diagramokkal, ezek a vizualizációk hozzásegítenek, hogy láthassuk, mely elemeket kell eltávolítani vagy esetleg hozzáadni.  

Drótváz

Ez az a szakasz, amelyben elkezdjük felépíteni a webes alkalmazás vázát. A dokumentáció, diagramok és meghatározott prioritások alapján drótvázat készítünk amely egyes esetekben egy kattintható prototípus. Minden oldal amely rendelkezik bejövő adatokkal vagy adatbázisból húz adatot a legnagyobb figyelemmel készül.

Ebben a folyamatban üdvözlünk mindennemű közreműködést az ügyfél részéről mivel ez egy felbecsülhetetlen visszacsatolás és jóváhagyás afelől, hogy minden mező és kritérium a helyén van. Ez egy kritikus szakasz, mivel e folyamatnál megtanítjuk az ügyfelet arra, hogy a projektre fordított idő rendkívüli fontosságú és a későbbiekben megtérül. 

A drótváz egy durva vázlat mely nélkülöz mindenféle design elemet tehát a figyelmünk az alapfunkciókra fókuszál. Ez az az idő amikor az első változás is megtörténik az alapdokumentumban leírtakhoz képest. 

Design UX / UI

Amint a drótváz elfogadásra került a designer elkezdheti a jövőbeni design elkészítését. Ennél a lépésnél választjuk ki a színeket, betűtípust az alkalmazás stílusát hozzá alakítva az egyes eszközökhöz ahol majd használatba kerül.  

Kulcsfontosságú, hogy figyeljünk az adott célcsoport típusára (kor, nem, foglalkozás stb.) alapján, akik majd a szolgáltatást igénybe veszik. 

Miután több oldal designja elkészült ismét kapcsolatba kell lépnünk ügyfelünkkel, hogy átbeszéljük a dolgokat. Ebben a szakaszban is felkérjük ügyfelünket, hogy adjon visszajelzéseket adjon hozzá vagy töröljön bizonyos opciókat. 

A legtöbb ember számára nehézkes elképzelni a végeredményt a technikai dokumentáció alapján, mivel az túl száraz vagy túl elvont. Mindemellett, ha egyszer meglátják a design elemeket hirtelen valósággá válnak az elképzelések és könnyebb reagálni azokra. 

A design bemutatásához létrehoztunk egy belső platformot. Úgy képzeljük el, mint egy “profil oldalt”, mely tartalmazza a legfőbb adatokat az ügyfélről, raktározza a design oldalakat, verziókat és az adott projekthez tartozó drótvázat is. A platformon belül őrizzük az ügyfél logó könyvtárát és egyéb vizuális elemeket, amelyeket később felhasználunk.  

Néha a mobil designnal kezdünk néha pedig asztali gépre tervezünk előbb ez az alkalmazás jellegétől függ. 

Ennél a folyamatnál a designer bemutatja a logót és egyéb márka anyagot mint pl. piktogramok vagy egyéb design elemek. 

Hány embernek kell dolgoznia az adott projekten?

Amint megvan a projekt dokumentáció, drótváz és design, be tudom mutatni a projektet a senior fejlesztőknek. Ez lehetőséget ad arra, hogy megtervezzük a projekt egészét és rámutassunk a nehézségekre.

Fő feladatom, hogy segítsek elkülöníteni az olyan részeket amelyeket még soha előbb nem fejlesztettünk, mivel ezeknél plussz időt kell kalkulálnunk az ezt megelőző kutatásra. A senior fejlesztők kulcsfontosságúak ebben a szakaszban. 

Megbeszéljük a technológiát, amelyet használni fogunk és az alkalmazás fejlesztésének folyamatát. 

A frontend és backend fejlesztők szintén hozzáadják gondolataikat, így e megbeszélés végére már 80%-ig biztosak vagyunk abban, hogy hány emberre lesz szükség a projekt kivitelezéséhez, milyen feladattípusok vannak és mely feladatok adhatóak junior programozók részére. 

Ettől kezdve már értesíthetjük az ügyfelet, hogy mikor tudjuk elkezdeni az applikáció kódolási részét. 

Ajánlat egy webes alkalmazás elkészítéséhez

Erre a szakaszra már rendelkezünk elegendő információval ahhoz, hogy kezdeti ajánlatot adjunk ügyfelünknek. Az elmúlt 3 évben a legtöbb projektünknél komplex webes alkalmazás fejlesztésére is sor került. Legtöbb esetben agilis módszerekkel dolgozunk Scrum vagy Kanban elemekkel. Ez azt jelenti, hogy a fő célunk, hogy mielőbb létrehozzuk a minimum projektet, hogy minél korábban visszajelzéseket kaphassunk. 

Megengedjük ügyfeleinknek, hogy változtassanak az applikáción, amíg az a fejlesztés fázisában van. A munkám, hogy pontosan elmagyarázzam ügyfelünknek, hogy az aktuális változtatás mit eredményezhet. 

Hogyan befolyásolja az adott változás a projekt egyéb funkcióit, árat vagy a határidőket?

Ennek a rugalmasságnak van egy hibája. A projekt ára nem lehet fix ár. Az ár, amelyet megadtunk a hozzávetőleges ajánlatnál inkább informatív jellegű és az esetek 99%-ában magasabb lesz. 

Teljesen normális az, hogy az ügyfél nem tudja pontosan mire lesz szüksége a jövőben (vagy legalábbis nem tudja addig, amíg nem készült el az applikáció első verziója). Ez mellett a fejlesztők sem tudják pontosan előre jelezni minden egyes lépés lefejlesztésének az idejét. Teljesen lehetetlen pontos becslést adni egy nagy összetettségű applikációnál. 

Még a mögöttünk lévő összevont 50 év tapasztalat mellett is újra és újra szembesülünk nem várt szituációkkal és kihívásokkal. 

Az ügyféllel történő párbeszéd ennél a lépésnél is kulcsfontosságú. Bemutatjuk az egyes opciókat, amely magában foglalhatja bizonyos funkciók elhagyását az eredeti verzióhoz képest vagy egyes feladatok módosítását a következő fejlesztési szakaszban.   

Gyakori és őszinte kommunikáció egy kölcsönös tiszteletet eredményez az ügyfél és az ügynökség között, amely nélkülözhetetlen a projekt sikeres kivitelezéséhez. Ennél a folyamatnál már egy hosszú távú üzleti kapcsolatban kell gondolkodnunk arra kell törekednünk. 

A projekt összetettségétől függően kínálatunkban szerepelnek különböző fajta karbantartás csomagok: 

A karbantartás magában foglalja: 

  • A weboldal havi átvizsgálása
  • Szerverkarbantartás és ezek szerverei
  • Biztonsági frissítések
  • Gyors válaszadás a folyamatban lévő kérdésekre

Amikor az ügyfél igent mond a karbantartási megállapodásra, az azt jelenti, hogy lefoglalta az időnk egy részét, és biztos akar lenni abban, hogy azonnal cselekszünk. 

Szerződés

A személyes megegyezések és a kézfogások fontosabbak számunkra, mint egy valós szerződés. Mégis, néhány játékszabályt az üzleti életben érdemes követni. Ez pedig nem más mint a szerződés aláírása. 

Cégünk szerződése egyszerű nyelven íródott, mindenféle komplikált jogi beszéd nélkül. Elmagyarázza mindkét fél jogait és kötelezettségeit. 

A Studio Present életében (2006 óta) még sohasem voltak jogi problémáink, s erre igen büszkék vagyunk. Voltak esetek amikor nézeteltéréseink akadtak egyes ügyfelekkel, de ez legtöbb esetben a célok eltéréséből eredt. Ezekben az esetekben mindig jobb volt megszakítani az együttműködést még a legelején. 

Feladatok és felhasználóI felület beállítása

A Studio Presentnél a következő csapatok között osztjuk fel a munkát:

  • Projekt menedzserek
  • Designerek
  • Az oldal felépítéséért felelősek - Sitebuilders
  • Backend fejlesztők
  • Frontend fejlesztők
  • Minőségellenőrzés - QA
  • Szerver csapat
  • Tartalomért felelős csapat 
  • Online marketing 

A csapatok menedzserei és tagjai felelősek a feladatok elkészítéséért és a megfelelő kezdésért. Tehát hogyan is zajlik a folyamat? Például a minőségért felelős csoportnak nincs feladata amíg a programozók be nem fejezik munkájukat. A megfelelő sorrendet gondosan össze kell hangolni és koordinálni annak érdekében, hogy az egész folyamat zökkenőmentesen működjön. 

Egy adott feladat létrehozásakor megbecsüljük az időt amely szükséges az adott funkciók fejlesztéséhez. Sok esetben a nagyobb feladatok kisebb alfeladatokból állnak össze és szinte mindig prioritási sorrendet kell létrehozni. Gyakran szembesülünk előre nem látott problémákkal melyek azonnali megoldást kívánnak tőlünk. 

A tapasztalt munkatársak itt is alapvető szerepet kapnak mivel az ő tapasztalatuk a legmérvadóbb arról, hogy mennyi időre van szükség egy egy részfeladat vagy nehézség leküzdésére. 

Csapatunk “kick-off” meetingje

Elérkezett az idő, hogy egy asztalhoz ültessük az egész csapatot és átbeszéljük az applikáció működését. 

Mindemellett több rövid összefoglaló is létezik a legfőbb célokról. Az összes feladatot sorra vesszük és további kiegészítéseket teszünk hozzájuk ha szükséges. Ez az alkalom, amikor meghatározzuk a fő prioritásokat az első 2 hét fejlesztése kapcsán. 

A senior programerek feladata, hogy irányítsák a juniorokat. Ez szintén egy jó alkalom, hogy definiáljuk a projekt legfőbb kihívásait és meghatározzuk a legjobb megoldást. 

A fejlesztőI környezet létrehozása

Azon kollégák akik a szerveroldalért felelnek el kell hogy végezzék a szükséges beállításokat, melyek utána minden fejlesztő “letölt” a saját gépére és úgy végzi a fejlesztést. A verziókövetés konfigurálása is megtörténik, így az ügyfél már ebben a szakaszban követni tudja a változásokat egy teszt domainen keresztül. Mindemellett fontos hozzátenni, hogy a fejlesztés ilyen korai szakaszába bevonni az ügyfelet csak abban az esetben érdemes, ha megfelelő rálátással rendelkezik a technikai, informatikai dolgokra. 

Az oldal felépítése és frontend fejlesztése

A “sitebuilder” vagyis az oldal felépítéséért felelős munkatárs az alkalmazás alapjait állítja össze. Az ő feladata az alap mezők, tartalomtípusok, régiók, blokkok valamint nézetek létrehozása a frontend és backend programozók számára. 

Több nap sitebuild munka után a csapat többi tagja elkezdhet dolgozni a saját területén. 

A frontend fejlesztők feladata, hogy a meglévő desin alapján egy működő terméket hozzanak létre. Szintén fontos, hogy lefejlesszék az oldal dinamikáját és felhasználó baráttá tegyék CSS és JS használatával a designerekkel szorosan együttműködve. 

Például:

  • A “sitebuilder” létrehozza a szükséges mezőket, konfigurálja az alapvető modulokat melyek majd használatban lesznek, beállítja az egyes oldalak alapvető strukturáját.
  • A frontend fejlesztő beállítja az applikáció stílusát általában, amelyet a designer már meghatározott. Feladata, hogy definiálja a betűtípusokat, gombok stílusát és meghatározza az összes használatban lévő HTML elem stílusát. 

Programozás

Mindenekelőtt legfontosabb, hogy meggyőződjünk arról, hogy a programozó megértette a feladatát. A következő lépés, hogy létrehozzon egy adatbázis sémát és megvizsálja a relációkat. Ha valamely funkcióval elkészült azt már prezentálhatjuk is az ügyfélnek a teszt domainen keresztül. Ez lehetőséget ad az ügyfélnek hogy meggyőződjön arról, hogy minden úgy működik ahogy kell. Például az ügyfél szeretné látni, hogy a szállítási költséget meghatározó funkció, mely a termék súlya szerint számol helyesen működik -e. 

Ebben a fázisban a nem szükséges, hogy az egész design kész legyen. Ez az agilis módszer szépsége, hogy már ilyen korai szakaszban is tudunk tesztelni egymástól elkülönülő funkciókat. 

Egy elterjedt programozási feladat, hogy az applikációt összekössük egy már létező meglévő alkalmazással. Ez az API-n keresztül megy és kapcsolódhat a CRM szoftverhez, ERP-hez vagy hírlevél küldő rendszerhez. 

Tartalom

Mikor web alkalmazást készítünk a tartalom nem számít annyira kritikus elemnek amivel már az első lépésnél foglalkozni kell. 

Mindemellett mire teszteljük az egyes funkciókat szükséges lehet hogy rendelkezzünk releváns tartalommal. 

Néhány példa az állandó tartalomra: 

  • Demo termékek
  • Árlista
  • Csapattagok
  • Üzleteink lokációja
  • ...

Minőségellenőrzés - QA

A szerződésnek megfelelően minden munkatársunk minőségellenőrzést kell hogy végezzen a saját feladatain. A projektmenedzsereknek tesztelni kell az alkalmazás egyes részeit. A minőségért felelős csapatnak tesztelni kell a teljes munkát a designtól a fejlesztésig. 

Abban hiszünk, hogy a legjobb megközelítés az, ha egy negyedik felet is bevonunk a  tesztelésbe, aki az ügyfél cégének munkatársa. Egy külső szem sokszor meglát olyan dolgokat, melyeket mi nem veszünk észre. Mindezen ellenőrzések kombinációja hozzásegít ahhoz, hogy a végeredmény egy működő, jól tesztelt alkalmazás legyen. A végső megerősítés az applikáció megfelelő működéséről a végső felhasználóktól fog érkezni. 

Production - az alkalmazás áthelyezése a publikus szerverre

Az élő szerverre történő áthelyezés (production)
Miután meggyőződtünk arról, hogy rendszerünk megfelelően, hibák nélkül működik, minden bug javításra került, elkezdjük az alkalmazás áthelyezésének folyamatát a publikus szerverre. 
Ettől a pillanattól kezdve az applikációnk az igazi domainhez csatlakozik és bárki számára hozzáférhetővé válik. 

A szerveres kolléga konfigurálja az SSL (https) tanúsítványt, e-maileket, mi pedig valós adatokat viszünk fel pl. Kártyás fizetés esetén. 

Karbantartás
Feltételezve, hogy a cél az alkalmazás vagy a weboldal gördülékeny működése a belátható jövőben szükséges egy megegyezés az ügyféllel egy karbantartási csomag tekintetében. 

Elméletileg létrehozni egy stabil rendszert egészen egyértelmű. Mindemellett számos előre nem várt faktor okozhat előre nem látott mértékű bonyodalmakat amelyek még a legjobban kifejlesztett applikáció működését is kudarcba juttatják. 
Javasoljuk ügyfeleinknek, hogy bizonyos technikai feltételeket iktassanak be a szerződésbe így később joguk lesz visszakövetelni az esetleges károk megtérítését.

Amennyiben egy egészséges üzleti kapcsolat jött létre, a karbantartás mellett mindig lesz helye az applikáció továbbfejlesztésének. Egy komplexebb karbantartási csomaggal ügyfelünk az időnk egy részét lefoglalja, így mindig lesz alkalom és idő a kisebb hibák kijavítására és kisebb újításokra. 

Újítások és új funkciók

Hadd folytassam az előző mondatnál. Legtöbb esetben egy online üzletág rohamos ütemmel fejlődik szinte napi szinten. Új szolgáltatások jelennek meg, melyeket automatizálni kell, ezek miatt pedig magát a webes jelenlétet vagy az adott alkalmazást is újítani kell. 

A jelenlegi álláspontunk a Studio Presentnél az, hogy rendszeres párbeszédet kell folytatunk ügyfeleinkkel a jövőre vonatkozó fejlesztési terveikről.  

Ügyfeleink megváltoztathatják a prioritási sorrendet és betekinthetnek az adott munkafolyamatokba. Az átláthatóság ilyen mértékét helyesnek találjuk, hiszen az ügyfél azonnal reagálhat ha bármilyen sürgős feladat (show stopper) jelentkezik vagy amikor bármilyen jellegű információra van szükségünk ahhoz hogy folytatni tudjuk a munkát. Természetesen ügyelünk arra, hogy ügyfeleink döntései helyesek legyenek illetve bizonyos esetekben stratégiai tanácsot adjunk legjobb tapasztalatunk szerint. 

Ezen fázisra az ügyfél és a Studio Present között erős kötelék “üzleti házasság” alakult ki melynek folyamodványa, hogy természetes közös fejlődés alakul ki.

Marketing

Időnként előfordul hogy az adott üzletágban az adott applikáció nincs monopolhelyzetben. Más hasonló szolgáltatások is a piacon vannak és versengeni kell a részesedésért. Ez azt jelenti, hogy bizonyos fokú marketinget be kell iktatni. A Studio Presentnél tapasztalt marketing szakemberekkel rendelkezünk, akik kézbe tudják venni a cég digitális jelenlétét a márkaépítéstől egészen a konkrét marketing kampányokig. Többet megtudhat a marketingről a következő weboldalon: 
https://www.studiopresent.com

Ha ügyfelünk érdeklődik marketing szolgáltatásunk iránt a marketing csapatunk egyik tagja is jelen van aki segít meghatározni a következőket: 

  • Mik a kulcsfontosságú értékek amiket népszerűsíteni szeretnénk
  • Miket szeretnénk hangsúlyozni az új oldalon
  • Harmonizáció vagyis az üzlettulajdonosok és egyben a végső fogyasztók igényeinek együttes kielégítése

A második eset amikor a marketing csapat közreműködése nélkülözhetetlen az az olyan eset, amikor egy meglévő weboldalt vagy projektet készülünk felújítani. Ilyenkor a csapat rámutat a bizonyos technikai elemek beépítésére a meglévő analizált adatok alapján. A marketing csapat további fontos részletekkel egészíti ki az oldal optimalizációját, a közösségi médiát, az egyéni felhasználókat vagy a keresőmotorokat érintő kérdéseket.  

Fizetés

Tudatában vagyok, hogy a számlázás és a pénz megvitatása általában nem kedvelt témák. Ennek ellenére szeretném bemutatni hogyan is működik ez nálunk.

Amennyiben egy komplex alkalmazásról van szó az ügyfél számlát kap a technikai dokumentáció megküldésekor. 

A második számla megküldésre kerül a drótváz és a design megküldésénél a ráfordított munkaórák alapján. Amikor meghatároztuk egy konkrét projekt értékét ügyfelünknek az összérték egyharmadát kell kifizetnie előlegként. 

A hónap elején elkészítjük a számlákat az előző hónapról szintén óradíj szerint az projektre fordított órák alapján. 

Összegzés

Ezek után már ismeri a munkafolyamatot. A gyarkolat azt mutatja, hogy félévente változás történik. Bizonyos dolgokat frissíteni, újítani szükséges. Mint bármely más vállalkozásnál, az IT állandó változása elkerülhetetlen. 

Nem győzzük hangsúlyozni ügyfeleinknek, hogy nem kell félni a változástól, be kell mutatni azokat a kollégáknak és elmondani miért lesz valami jobb. Mikor elmondjuk az ügyfélnek miért szükséges valamit megtenni vagy miért jobbak bizonyos dolgok az előzőeknél leginkább pozitív visszajelzéseket kapunk. 

Időnként a változások meghosszabbítják a munkát, de cserébe egy teljesen új, stabil, jobb minőségű termék a végeredmény.