Hogyan kezelsz tisztázatlan vagy kétértelmes üzleti követelményeket, mielőtt megkezdenéd a kódolást?

Question

Accepted Answer

A találgatásra való kódolás a legdrágább módja annak, hogy felfedezd a követelmény félreértéseit. Ha egy kérés homályos, az én feladatom az ambivalencia feloldása egy közös, írásban rögzített megértéssé, *a kódolás előtt*, majd ezt olcsón validálni. Az ambivalencia nem egy olyan blokker, amelyre vissza kell lökni; ez a munka normális része, hogy felszínre hozzuk.

## Hogyan szódom meg a homályból

- **Kérd meg, hogy miért, ne csak hogy mit.** Milyen kimenetelt akarunk elérni? A kérés mögötti ok gyakran egy egyszerűbb vagy eltérő megoldást tár fel, mint az, ami kimondott.
- **Találd meg a valódi felhasználót és a siker metrikáját.** Ki érzi a fájdalmat, és hogyan tudunk majd arról, hogy megoldódott? A "kész" szükséges egy olyan definíciót, amelyre rá tudsz mutatni.
- **Fogalmazd meg vissza a megértésedet.** Saját szavaiddal való átfogalmazás azonnal felszínre hozza az ellentmondásokat, sokkal olcsóbb, mint a demóban felszínre kerülnének.
- **Használj példákat, vázlatokat és elfogadási feltételeket.** Konkrét termékek arra kényszerítik a homályos ötleteket, hogy elköteleződjenek. "Adott X, amikor Y, akkor Z" a véleményeket tesztelhető kijelentésekké alakítja.
- **Tárj fel边eseti eseteket korán.** Mi van az üres állapotokkal, hibákkal, nagy bevitelekkel, engedélyekkel? Ezt most megkérdezni olcsó; a produkciónban való felfedezés nem.
- **Írd le és erősítsd meg.** Egy rövid írásban rögzített összefoglaló, amelyet az érintett felek jóváhagynak, a közös igazság forrása lesz és az a dolog, amelyre a fejlesztést alapozod.

## Majd kisben validálj

- Építs meg a **legkisebb szeletet**, amely a megértést bizonyítja, egy vékony végponttól végpontig történő utat vagy egy gyors prototípust, és szerezz visszajelzést, mielőtt a teljes fejlesztésbe invesztálnál. A valódi szoftver egy érintett fél előtt több tisztázást nyújt, mint bármely dokumentum.

## Miért számít ez

A legtöbb projekthibát nem a rossz kód okozza, hanem a nem megfelelő dolog építése. Egy Tech Lead, aki megbízhatóan ambivalenciát tiszta, elfogadott hatókörré alakít, megvédi a csapatot az átdolgozástól, megóvja a becsléseket, és bizalmat szerez az üzlettől azzal, hogy az ténylegesen szükséges dolgot szállítja, nem azt, ami szó szerint megfogalmazódott.