A legtöbb alkalmazás nem azért bukik el, mert rosszul van megírva.
Hanem azért, mert túl sok mindent akar egyszerre megoldani.
Ismerős a helyzet?
Van egy remek ötleted. Leülsz tervezni, és sorra jönnek az új funkciók.
„Legyen chat.”
„Legyen értesítési rendszer.”
„AI is kell bele.”
„Statisztikák.”
„Pontgyűjtés.”
„Achievementek.”
„Sötét mód.”
„Még egy admin felület.”
Mire elkészül az első verzió, hónapok telnek el.
A kód tiszta.
Az architektúra példás.
A tesztek zöldek.
Majd publikálod…
…és a felhasználók a funkciók 80-90%-át egyszer sem nyitják meg.
Üdv a funkció-temetőben.
A legdrágább funkció az, amit senki sem használ
Sok fejlesztő úgy gondolja, hogy egy új funkció „csak még egy hét fejlesztés”.
Valójában azonban minden új funkciónak ára van.
Nem csak egyszer.
Hanem folyamatosan.
Minden új képernyő:
- tesztelést igényel,
- dokumentálni kell,
- karban kell tartani,
- hibákat fog termelni,
- lassítja a fejlesztést,
- növeli a komplexitást,
- és hosszú évekre technikai adósságot jelenthet.
Ha pedig a felhasználók végül nem használják…
akkor ez az egész befektetés nulla üzleti értéket termelt.
A legtöbb funkció csak feltételezés
Ez az egyik legnehezebben elfogadható igazság.
Amíg nincs valódi felhasználód, addig szinte minden funkció csak egy hipotézis.
Te azt gondolod, hogy kell chat.
A felhasználó lehet, hogy csak egy gombot akar megnyomni.
Te statisztikákat tervezel.
Ő két másodperc alatt szeretne végezni.
Mi szeretjük azt hinni, hogy tudjuk, mire van szükségük.
A valóságban viszont ezt csak a használati adatok döntik el.
Az MVP nem félkész termék
Az MVP-t sokan úgy fordítják le maguknak, hogy „csináljunk valami olcsót”.
Pedig pontosan az ellenkezője.
Az MVP nem a lehető legkevesebb munka.
Hanem a lehető legkevesebb funkció.
Egy jó MVP egyetlen problémát old meg.
De azt kiválóan.
Az Uber első verziójának nem attól volt értelme, hogy száz funkciója volt.
Hanem attól, hogy néhány érintéssel autót tudtál hívni.
Minden más később épült rá.
A jó fejlesztő nem csak programoz
A fejlesztők szerepe is megváltozott.
Régen elég volt végrehajtani a specifikációt.
Ma már egy jó fejlesztő rendszeresen felteszi a kellemetlen kérdéseket.
„Biztos, hogy szükség van erre?”
„Mi történik, ha ezt kivesszük?”
„Milyen problémát old meg ez a funkció?”
„Ki fogja ezt használni?”
Ezek néha kellemetlen kérdések.
De gyakran hónapok fejlesztését és több millió forintot spórolnak meg.
Az AI sem oldja meg ezt a problémát
Sőt.
Az AI miatt még könnyebb funkció-temetőt építeni.
Ma már néhány óra alatt elkészülhet egy olyan modul, amelynek megírása korábban napokig tartott.
Ez azonban nem jelenti azt, hogy szükség is van rá.
Az AI olcsóbbá tette a fejlesztést.
De nem tette olcsóbbá a rossz termékdöntéseket.
Sőt, még gyorsabban lehet rossz irányba fejleszteni.
Mielőtt új funkciót fejlesztesz, tegyél fel három kérdést
- Milyen konkrét problémát old meg?
- Miből tudom majd, hogy valóban használják?
- Mi történik, ha egyáltalán nem készítem el?
Ha a harmadik kérdésre az a válasz, hogy „igazából semmi”…
akkor valószínűleg még nincs itt az ideje.
A cél nem a legtöbb funkció
A cél egy olyan termék, amit az emberek újra és újra megnyitnak.
Mert valódi problémát old meg.
Nem attól lesz jó egy alkalmazás, hogy száz funkciója van.
Hanem attól, hogy van egy, amiért újra visszatérnek.
A kód értékét nem az határozza meg, hány sort írtál meg.
Hanem az, hogy a felhasználók közül hányan érzik azt: „Pont erre volt szükségem.”
