Perrašyti ar tvarkyti: kaip nuspręsti dėl senos sistemos

„Sistema sena, reikia naujos.“ Šis sakinys pradeda daugiau projektų, nei pasiteisina. Įdomu tai, kad jis beveik niekada nėra techninis vertinimas – tai dažniausiai išvada, prie kurios prieita po kelių nepatogumų metų. Prieš ją priimant verta atlikti keturias patikras, ir nė vienai iš jų nereikia tiekėjo.

Trumpai

• Amžius nėra rodiklis. Rodiklis yra tai, ar pakeitimą galima atlikti nesulaužant kažko kito.
• Perrašymas dažniausiai pasirenkamas dėl organizacinių, ne techninių priežasčių, ir tai verta pasakyti garsiai.
• Naujoje sistemoje atsiranda tos pačios problemos, jei nepakeista tai, kas jas kūrė: neužrašytos taisyklės ir neaiški atsakomybė.
• Dalinis kelias – atskirti vieną sritį ir pakeisti ją pirmą – beveik visada egzistuoja ir beveik niekada nepasiūlomas.
• Didžiausia perrašymo rizika ne kodas, o duomenys ir žinios, gyvenančios žmonių galvose.

Keturios patikros, kurias galite atlikti patys

Pirma: kiek laiko užima nedidelis pakeitimas. Ne didelė funkcija – pavyzdžiui, naujas laukas formoje. Jei atsakymas skaičiuojamas dienomis, sistema tvarkinga. Jei niekas negali atsakyti, problema yra ne sistemos amžius, o tai, kad jos niekas nebeprižiūri.

Antra: kas nutinka, kai kažkas pakeičiama. Jei po kiekvieno pakeitimo lūžta kažkas nesusijusio, sistemos dalys per glaudžiai susijusios tarpusavyje. Tai tikras techninis argumentas, bet jis argumentuoja ne perrašymą – jis argumentuoja atskyrimą.

Trečia: ar galima paaiškinti, kur laikomi duomenys ir kaip juos išsivežti. Jei atsakymas neaiškus, perrašymas yra rizikingiausias iš įmanomų sprendimų, nes jo pirmas žingsnis būtų būtent tai, ko niekas nemoka padaryti.

Ketvirta: kiek verslo taisyklių yra užrašyta. Beveik kiekvienoje senoje sistemoje yra taisyklių, kurių niekas neaprašė ir kurios pastebimos tik tada, kai nustoja veikti. Kuo mažiau užrašyta, tuo brangesnis perrašymas – ir tuo labiau naudinga pirma tai užrašyti, nesvarbu, kuris kelias bus pasirinktas.

Kodėl perrašymas pasirenkamas taip dažnai

Čia jau ne techninis, o sąžiningas organizacinis pastebėjimas. Perrašymas patogus: jis leidžia nespręsti, kodėl sistema tokia, kokia yra, ir kas už tai atsakingas. Jis duoda naują biudžetą, naują komandą ir aiškų naratyvą apie pažangą. Tvarkymas duoda mažiau matomą rezultatą ir reikalauja pripažinti, kad kažkas anksčiau padaryta ne taip.

Tai nereiškia, kad perrašymas visada neteisingas. Tai reiškia, kad prieš jį verta atsakyti, ar šiuo sprendimu sprendžiama techninė problema, ar vengiama organizacinės. Jei antra – nauja sistema po kelerių metų atrodys taip pat, tik naujesnėmis technologijomis.

Trečias kelias, kurio dažniausiai nepasiūlo

Beveik visada galima atskirti vieną sritį ir pakeisti ją pirmą, o likusią sistemą palikti veikti. Sąskaitos, klientų paskyros, ataskaitos – dažniausiai kuri nors dalis pakankamai atskira, kad ją būtų galima perkelti be viso kito. Tai lėčiau nei perrašyti viską ir sunkiau parduoti kaip projektą, bet rizika lieka valdoma: jei nepasiseks, nepavyks viena sritis, ne visas verslas.

Papildoma nauda ta, kad pirmas etapas parodo tikrąjį tempą. Po jo galima priimti sprendimą dėl likusios sistemos jau turint duomenis, o ne prognozę.

Ką iš tikrųjų kainuoja perrašymas

• Duomenų perkėlimas. Beveik visada didesnis darbas nei atrodo, nes senuose duomenyse yra atvejų, kurių dabartinės taisyklės neleistų.
• Dviguba priežiūra pereinamuoju metu: sena sistema turi veikti, kol naujoji dar nebaigta.
• Neužrašytos taisyklės, kurios atrandamos po vieną, dažniausiai jau paleidus.
• Naudotojų mokymas ir laikinas produktyvumo nuosmukis. Jis realus net tada, kai nauja sistema geresnė.
• Matomumas paieškoje, jei sistema aptarnauja viešus adresus. Tai atskiras darbas, ne pasekmė.

Iliustracinis scenarijus, ne kliento projekto aprašymas

Įsivaizduokime įmonę, kuri nusprendžia perrašyti vidinę sistemą, nes ji „per sena ir stringa“. Peržiūrėjus paaiškėja, kad kodas tvarkingas, o stringa dėl dviejų dalykų: neįjungtos esamos sistemos galimybės ir vieno rankinio žingsnio, kuris kartojamas kasdien. Abu ištaisomi per kelias dienas. Perrašymo projektas būtų užėmęs metus ir baigęsis ta pačia rankine praktika naujoje sąsajoje. Tai pavyzdys, kaip vertiname sprendimą, o ne pažadas dėl išvados – kita įmonė su tuo pačiu simptomu gali turėti visiškai kitą atsakymą.

Kaip suformuluoti sprendimą

• Užrašykite, kokį sprendimą reikia priimti ir iki kada. „Ką daryti su sistema“ nėra sprendimas.
• Įvardykite, kas jį priims ir kokios informacijos jam trūksta.
• Atlikite keturias patikras ir užrašykite atsakymus, net jei jie nepatogūs.
• Paprašykite bet kurio tiekėjo aprašyti dalinį kelią. Jei jo nėra – paprašykite paaiškinti, kodėl.
• Atskirkite vertinimą nuo įgyvendinimo. Tas, kas uždirbs iš rezultato, neturėtų vertinti, ar rezultatas reikalingas.

Paskutinis punktas yra svarbiausias ir mažiausiai patogus. Jei vertinimą atlieka būsimas vykdytojas, atsakymas beveik visada bus tas, kuris jam duoda daugiau darbo – dažnai net be jokio nesąžiningumo, tiesiog todėl, kad taip atrodo iš jo pusės.