Capcana scope creep-ului: cum să spui nu funcțiilor care sună bine, dar nu sunt
Ai construit ceva ce utilizatorii adoră. Acum vor funcții care sună rezonabil, dar care ar duce aplicația în zece direcții diferite. Iată cum să decizi ce cereri să construiești și pe care să le refuzi politicos.
Ai lansat o aplicație. Au apărut utilizatori. Și acum inbox-ul tău e plin de cereri de funcții care sună toate ca niște idei bune.
„Putem adăuga export în Excel?” Rezonabil. „Pot fi trimise facturile automat?” Are sens. „Ne putem integra cu Stripe?” Acolo trăiesc banii adevărați. „Poți adăuga o aplicație mobilă?” Toată lumea o cere. „Putem face white-label din asta pentru proprii noștri clienți?” O, acum avem un model de afaceri.
Fiecare cerere în parte sună inteligent. Împreună, sună de parcă ai construi cinci produse diferite.
Asta e scope creep și omoară mai multe aplicații mici create cu IA decât o vor face vreodată problemele tehnice. Nu pentru că ai construi funcțiile — ci pentru că rămâi fără timp, fără bani sau fără minte încercând.
Cum omoară scope creep-ul o aplicație funcțională
Iată ce se întâmplă. Spui da la primele trei cereri, pentru că par rezonabile. Îi ceri creatorului tău cu IA să le adauge. Durează două săptămâni în loc de una, pentru că fiecare funcție nouă se ciocnește de codul existent. Acum ai o aplicație care face cinci lucruri și face trei dintre ele bine și două dintre ele acceptabil.
Apoi sosește cererea a patra: „Putem avea niveluri diferite de permisiuni?”. Dintr-odată trebuie să regândești cine poate vedea ce pe fiecare ecran. Asta nu e o funcție; e o schimbare de arhitectură. Îi ceri creatorului tău cu IA să o facă. Atinge totul. Două săptămâni devin trei. Aplicația devine mai lentă pentru că ai adăugat logică în fiecare vizualizare.
Până la cererea a opta, ai încetat să mai lansezi lucruri noi pentru utilizatorii tăi inițiali, pentru că ești prea ocupat să ții în funcțiune mașinăria cererilor de funcții. Oamenii care adorau aplicația acum trei luni sunt frustrați pentru că nimic din ce au cerut nu e gata. Oamenii care fac cereri noi sunt frustrați pentru că funcțiile durează o veșnicie.
Ai construit ceva ce funcționează. L-ai stricat încercând să fii totul.
Cadrul de decizie
Ai nevoie de o poartă. Fiecare cerere de funcție trece prin trei întrebări:
Întrebarea 1: Locul ăsteia e în această aplicație sau e o aplicație diferită?
Prima ta aplicație face o singură treabă cu adevărat bine. O aplicație de programări programează lucruri. O aplicație de facturare facturează. Sunt aplicații diferite. Dacă cineva îi cere aplicației tale de programări să factureze, nu adaugi o funcție — îi ceri unei aplicații de programări să facă contabilitate. Ăsta e un produs diferit.
Un test bun: „Dacă aș lua această funcție și aș lansa-o de sine stătătoare, ar vrea oamenii să o cumpere?”. Dacă da, locul ei e probabil într-o aplicație diferită. Dacă răspunsul e „nu, are sens doar ca parte a lucrului mai mare”, atunci construiești în limita potrivită.
Vei primi cereri de genul „integrează-te cu CRM-ul nostru”. Ce înseamnă cu adevărat asta e „fii propriul tău CRM”. Ăsta e o aplicație diferită. Te poți integra cu un CRM mai târziu. Nu poți adăuga cât un CRM de funcții fără să devii un CRM.
Întrebarea 2: Rezolvă asta o problemă pentru majoritatea utilizatorilor tăi sau doar pentru acesta?
Un client îți adoră aplicația și are o idee de funcție. E o problemă reală pe care o are. E și o problemă reală pe care o are doar el.
Dacă ai douăzeci de utilizatori și unul cere ceva, verifică: așteaptă și ceilalți nouăsprezece asta sau persoanei tocmai i-a venit ideea? Îi poți întreba direct: „Înainte de tine, te-ai gândit să întrebi pe altcineva dacă are nevoie de asta?”. De obicei răspunsul e nu.
Asta e întrebarea periculoasă, pentru că singurul client care cere ar putea fi cel mai important client al tău. S-ar putea să fie nevoie să-l ții fericit. Asta e o decizie de afaceri, nu o decizie de produs. Dar intră cu ochii deschiși: dacă construiești ceva pentru un singur client, nu-ți crești aplicația, ci construiești o practică de consultanță.
Întrebarea 3: Cât costă asta și care e costul pentru ideea inițială?
Totul costă ceva. Exportul în Excel te costă timp de inginerie. Costă complexitate pentru aplicația ta. Costă concentrare. Construiește-l în loc de o optimizare de performanță de care utilizatorii tăi se plâng zilnic și ai făcut o alegere.
Întreabă concret: „Dacă construiesc asta, ce nu construiesc?”. Dacă răspunsul e „nimic, avem timp infinit”, nu ești sincer. Nu avem. Timpul e limitat.
Costul pentru ideea inițială e adesea invizibil. Când ești adâncit în cereri de funcții, încetezi să întreții lucrul de bază pe care oamenii îl adorau la tine. Nucleul devine mai lent. Nucleul devine mai plin de bug-uri. Nucleul pare neglijat. Și în cele din urmă oamenii pleacă, pentru că aplicația ce funcționa grozav acum funcționează acceptabil și face lucruri pentru care nu a fost niciodată concepută.
Un exemplu real: formularul de preluare
Cineva a construit un simplu formular de preluare a clienților. Clienții îl completează, antrenorul îl revizuiește, apoi programează. Asta e aplicația.
Cererea unu: „Pot marca preluările urgente?”. Da, e o variațiune a fluxului de lucru de bază. Construiește-o.
Cererea doi: „Pot exporta preluările în Excel pentru evidențele mele?”. Asta e o funcție de documente. Nu e treaba aplicației. Preluările trăiesc în aplicație. Dacă au nevoie de Excel, pot copia și lipi. Dar bine, exportul ar putea avea sens ca o comoditate. Construiește-l.
Cererea trei: „Pot preluările să creeze automat evenimente în calendar?”. Acum faci programări. Aplicația era pentru preluare, nu pentru programare. Dacă cineva vrea ambele, probabil vrea un sistem de programare adevărat, nu un cârpaci care lipește unul deasupra. Refuză politicos.
Cererea patru: „Pot antrenorii să trimită urmăriri ale preluării prin SMS?”. Acum ești un sistem de comunicare. Nu.
Până la cererea trei, ai ajuns la graniță. Aplicația e preluarea. Orice altceva e o aplicație diferită. Te poți integra cu acele aplicații mai târziu. Nu le poți adăuga fără să devii acele aplicații.
Cum să spui nu
Partea cea mai grea e chiar să o spui. Nu vrei să-ți frustrezi utilizatorii.
Fii sincer: „E o idee grozavă, dar e un produs diferit de ceea ce construim aici. Ce construim noi este [singura ta treabă]. Dacă încercăm să facem programări, sau facturare, sau lucruri de CRM, vom fi acceptabili la toate și grozavi la niciunul”.
Adesea clientul va înțelege. A cerut pentru că i-a venit ideea, nu pentru că te testează.
Uneori va insista. „Dar am nevoie de ambele.” Atunci e momentul să recomanzi: folosește aplicația de programare adevărată. Folosește aplicația de facturare adevărată. Folosește CRM-ul adevărat. Apoi folosește această aplicație pentru ce face ea bine. Ăsta e răspunsul sincer.
Tentația de a fi totul
Partea cea mai grea când construiești un produs mic e să spui nu. Nu-ul pare că lași bani pe masă. Dacă acel client chiar ar fi plătit pentru ambele? Dacă acea funcție te-ar fi făcut de zece ori mai mare?
Poate. Dar nu ești un produs de zece ori mai mare dacă nu-l lansezi. Ești un produs pe jumătate terminat care face cinci lucruri prost. Oamenii care adorau nucleul sunt frustrați. Oamenii care voiau funcțiile noi sunt frustrați. Și te-ai băgat singur într-un colț unde să adaugi orice lucru nou înseamnă mai întâi să refactorizezi cinci lucruri vechi.
Produsele care cresc sunt cele care fac o singură treabă cu adevărat bine și apoi adaugă cu grijă. Nu încearcă să fie Salesforce din prima zi. Sunt aplicația la care apelezi când ai nevoie să faci acel un lucru și aplicația în care ai încredere că e rapidă și fiabilă când o faci.
Spune nu. Protejează nucleul. Fă asta și vei construi ceva ce oamenii chiar vor să folosească.