Szoftver szerepek és címek

Fotó: Henry (CC-BY-2.0)

Nagyon sok zavart vettem észre az iparban a különféle szoftveres szerepek és címek vonatkozásában, még az alapítók, a menedzsereket és a csapatépítőket illetően. Melyek a szoftvercsapat különféle szerepei és felelősségei, és mely címek fedik le általában azokat a szerepeket?

Mielőtt ezt túl sokat tanulmányoznám, szeretném hangsúlyozni, hogy minden csapat egyedülálló, és a felelősségek hajlamosak úszni vagy megoszlani a csapat különböző tagjai között. Bármely személy bármikor átruházhatja a felelősséget másokra, különféle okokból - sok közülük érvényes.

Ha a csapatod nem pontosan az, amit itt leírok, üdvözlöm a klubban. Azt gyanítom, hogy nagyon kevés csapat van, és egyes szoftveres szerepek tökéletesen megegyeznek azzal, amit felfedezni fogunk. Ez csak egy általános keret, amely átlagot ír le, mint bármely konkrét szerep vagy csapat.

A vezetői címekkel kezdem, és körülbelül szolgálati idő szerint különféle szerepeken dolgozom.

Szeretném hangsúlyozni azt is, hogy nem szabad éreznie, hogy korlátozza a beosztása. Szeretek olyan mérnöki kultúrát építeni, amely a következőket támogatja:

  • A címekkel kapcsolatos készségek
  • Folyamatos kézbesítés határidőn belül
  • Támogassa a hibát
  • Együttműködés a verseny felett

Szeretem megnövelt felelősséggel jutalmazni a kezdeményezést, és ha valaki rendelkezik készségekkel és kezdeményezésekkel ahhoz, hogy megszerezzék és kibővítsék azt a címet, amelyre fel vannak bízva, inkább inkább előmozdítom, mint hogy kockáztatnék egy növekvő csillag elvesztését egy másik cég vagy csapat számára.

Szoftverfejlesztési szerepek

  • Mérnöki munkatárs
  • vezérigazgató
  • CTO
  • CIO / digitális vezérigazgató / innovációs vezérigazgató-helyettes
  • Mérnökilelnök / mérnöki igazgató
  • Főépítész
  • Szoftver építész
  • Mérnöki projektmenedzser / mérnöki vezető
  • Műszaki vezető / műszaki vezető / csapat vezető
  • Fő szoftvermérnök
  • Senior szoftvermérnök / vezető szoftverfejlesztő
  • Szoftvermérnök
  • Szoftverfejlesztő
  • Junior szoftverfejlesztő
  • Intern szoftverfejlesztő

Beszélünk egy kicsit arról is, hogy ezek a szerepek hogyan kapcsolódnak más szerepekhez, beleértve:

  • A termékmenedzsment alelnöke / termékvezető
  • Termék menedzser
  • Marketing alelnök
Megjegyzés: Néha a „rendező” vagy a „fej” címek középvezetőket jelölnek a tech menedzserek és a C-Suite között. Gyakran a „Chief” címek jelzik a C-suite címet. A C-suite alkalmazottainak általában közvetlenül a vezérigazgatónak kell beszámolniuk, és potenciálisan sok jelentést lehetnek az általuk irányított szervezetekben. Nagyon nagy cégeknél ezek az alternatív címek gyakran hasonló szerepeket töltenek be, mint a C-suite vezetõk, de jelentést tesznek valakinek, aki a nagyobb szervezeten belül egy kisebb üzleti egység vezérigazgatója. A különböző üzleti egységek néha úgy működnek, mintha különálló társaságok lennének, különálló elszámolással, pénzügyi tisztviselőkkel, stb. Különböző üzleti egységek is lehetnek VP-k, pl. “Mérnöki alelnök, Kereskedelmi Operációk”.

Mérnöki munkatárs

A „fickó” cím a szoftvermérnökök teljesítményének csúcspontja. Általában azokat az embereket ítélik oda, akik kiemelkedően hozzájárultak a számítástechnika területéhez, és általában akkor adják ki, amikor egy mérnök számos legnépszerűbb könyvet írt, olyan díjakat nyert, mint a Turing-díj, a Nobel-díj stb. , a munkatársak általában már híresek a szervezeten kívül, és a vállalat megpróbálja megerősíteni márkájukat azáltal, hogy erőteljesebben társul önmagához csodált és befolyásos emberekkel.

Véleményem szerint a szervezeteknek nem szabad megkísérelni bérezni „társ” szerepeket. Ehelyett keresse meg a legjobb és legfényesebbet, bérelje fel őket, majd adja meg a címet (és az előnyöket), ha a mérnök megérdemli.

Egy munkatárs általában egy másik címet is visel a társaságban. Gyakran egy műszaki vezető, építész, a műszaki vezérigazgató vagy fő szerepe, ha vezethetnek, mentorozhatnak, vagy példaként és inspirációként szolgálhatnak a szervezet más tagjai számára.

vezérigazgató

A vezérigazgató a szervezet legnagyobb tekintélye. Általában a jövőképét és az északi csillagot állítják be a társaság számára. Mindenkit egységes megértés mellett vonnak össze, hogy miért létezik a vállalat, mi a küldetés és mi a vállalat értékei. A vezérigazgatók gyakran a társaság nyilvános arca is, és egyes esetekben a márkanév szinonimáivá válnak (pl. Steve Jobs az Apple-vel, Elon Musk a Tesla / SpaceX-vel stb.)

Bizonyos esetekben a vezérigazgatók egyben a szoftver szervezet műszaki alapítói is, ebben az esetben gyakran a CTO szerepet is betöltsék, és működési, értékesítési, stratégiai és marketing alelnökökkel rendelkeznek, amelyek segítik a többi általános vezérigazgatói felelősséget. .

Egy kis cég vezérigazgatója gyakran nagyon sok kalapot visel, mivel valószínűleg felvette az összes többi olyan szerepet, amelyek a vezérigazgatói címből kikerültek, amikor megemlítettem, hogy néhány vezérigazgató vezet a technológiai csapatot.

Mindenesetre, ha fontos szervezeti döntéseket kell hozni, akkor a felelősség láncolatát a vezérigazgatónál magasabbra vezetheti.

Ha Ön vezérigazgató, ne feledje, hogy végső soron felelős vagy, és bízzon az ösztöneiben, de ne felejtsd el, hogy még a leghíresebb vezérigazgatóknak is vannak mentói és tanácsadói, akikkel rendszeresen konzultálnak. Bízzon a bélben, de keressen okos, éleslátó embereket, akik szintén kihívást jelentenek javítására.

CTO

A vezérigazgatói szerephez hasonlóan a CTO szerepe is idővel változik. A fiatal induló vállalkozásoknál a CTO gyakran műszaki társalapú látnok vagy domain-vezérelt vezérigazgató. Gyakran nem képesek arra, hogy egy nagyobb társaságban megszerezzék a címet, és remélhetőleg növekedni fognak abban, ahogy a vállalat növekszik. Gyakran egy induló CTO azt találja, hogy inkább a műszaki mérnöki szerepeket részesítik előnyben, és visszatelepülnek más szerepekbe, például főmérnök, műszaki vezérigazgató vagy főépítész.

Sok szervezetben az érett CTO szerepe kifelé néz. Részt vesznek üzleti fejlesztési találkozókon, gyakran segítve a nagy partnerségek vagy az eladások kiépítését. Közülük sokan eljutottak a konferencia körébe, és sok időt töltenek a szervezet fejlesztési tevékenységeinek a szélesebb világba történő evangelizálásával: megosztják a cég innovációit és felfedezik a piacon olyan lehetőségeket, amelyek jól illeszkednek a vállalat alapvető kompetenciáihoz. A CTO-k gyakran szorosan együttműködnek a termékcsapattal a termékstratégia terén, és gyakran rendelkeznek belső szemlélettel a műszaki tervekben, mint például a Mérnöki Főosztály.

A CTO-k gyakran meghatározzák a mérnöki csapat jövőképét és északi csillagát. A csapat céljainak elérése.

CIO / digitális vezérigazgató / innovációs vezérigazgató-helyettes

Az innovációs vezérigazgató (CIO) olyan, mint egy CTO, de általában olyan társaság alkalmazottja, amelyet általában nem tekintünk „tech vállalatnak”. A CIO célja, hogy átalakítsa a társaságot olyan vállalattá, amelyet a fogyasztók technikai értelemben hozzáértőnek és innovatívnak látnak: Hogy megmutassuk a világnak az ipar jövőjét, függetlenül attól, hogy mi ez az iparág. Például egy otthoni átalakító szupermarket láncban lehet a CIO, amely felelős a technológiai vállalatokkal való együttműködésért, hogy összeállítson egy vegyes valóság alkalmazást, amely megmutatja a vásárlóknak, hogy egy adott kanapé vagy falszín hogyan néz ki a nappaliban, vagy blokkláncokat és rejtjeleket használ a az ellátási lánc logisztikájának biztonsága és hatékonysága.

Nem szabad összetéveszteni az információs vezérigazgatóval (CIO), egy olyan címet, amelyet általában azokban a vállalatokban használnak, akik még jobban el vannak távolulva a technológiától, és érdekli őket, amennyiben az segíti az alapvető működésüket. Az innovációs vezérigazgatótól eltérően, az információs tisztviselő inkább a technológiai integrációs és adatáttelepítési projekteket vezeti, mint új alkalmazásokat épít, és megpróbálja kitalálni, hogy egy vállalat miként képes zavarni magát belülről. Vannak olyan információs tisztviselők, akik inkább az innovációs vezérigazgatók körében viselkednek, de véleményem szerint a megfelelő címet kell használniuk.

A legtöbb tech-natív vállalat (alkalmazásfejlesztő stb.) Nem rendelkezik ilyen típusú informatikai vezetővel. Ehelyett ezek a felelősségek a CTO-ra és a Mérnöki Alelnökre hárulnak.

Mérnöki Alelnök / Mérnöki Igazgató

Míg a CTO-k gyakran kifelé mutatnak, a Mérnöki Főképviselő gyakran befelé néz. A mérnöki tisztviselő gyakran felelős a mérnöki csapat felépítéséért, valamint a mérnöki kultúra és működés kialakításáért. A CTO elmondhatja a mérnöki csapatnak, hogy mit kell tennie nagy léptékben, például: „Legyen a vezető újító az ember és a számítógép közötti interakcióban”. A mérnöki tisztségviselő elősegíti a „hogyan” irányító kultúra előmozdítását. A legjobb mérnöki tisztségviselők először találkoznak valakivel, aki ott van, hogy segítse a csapat hatékony működését, majd majdnem eltűnnek. A csapat fejlesztői jól működnek együtt, mentorálnak, hatékonyan kommunikálnak, és azt gondolják: „Hé, nagyszerű csapat vagyunk. Nagyon jól működünk együtt! ” és talán azt gondolják, hogy ez mind szerencsés baleset.

Az igazság az, hogy szinte soha nem történik véletlenül. Ez azért történik, mert a mérnöki helyettes folyamatosan figyeli a csapat előrehaladását, folyamatát, kultúráját és a kommunikáció hangját. Arra ösztönzik a fejlesztőket, hogy használják bizonyos eszközöket, bizonyos típusú találkozókat tartanak meghatározott időpontokban annak érdekében, hogy elősegítsék a jobb együttműködést kevesebb megszakítással. A mérnökök legjobb mérnökei a mérnökök voltak, mind diszfunkcionális, mind pedig rendkívül funkcionális csapatoknál. Ismerik a hatékony szoftverfejlesztési munkafolyamatok mintáit és anti-mintáit.

A termékfejlesztőkkel és a termékmenedzserekkel működnek együtt annak biztosítása érdekében, hogy egy jó termék-felfedezési folyamat legyen (nem vezetik, vagy nem vállalják át azt, csak ellenőrzik, hogy valaki rajta van-e és jól csinálja-e), és hogy ez a termék és A tervezési eredményeket a mérnökök megfelelően felülvizsgálják a megvalósítás átadása előtt. Megállok, mielőtt könyvet írok az összes, a hatékony fejlesztési műveletek vezetésével kapcsolatos munkáról. A témával kapcsolatos további gondolataimmal kapcsolatban lásd: Hogyan állítsunk össze nagysebességű fejlesztőcsapatot.

Számos induló vállalkozás túl kicsi ahhoz, hogy teljes munkaidős műszaki vezérigazgató-helyet foglaljon el, de továbbra is nagyon fontos, hogy a mérnöki kultúrát a lehető leghamarabb megkapjuk. Ha segítségre van szüksége ezzel kapcsolatban, keresse fel.

Főépítész

Kis szervezeteknél a főépítész műszaki társalapító lehet az öntudatossággal annak felismerése érdekében, hogy a vállalat növekedésével nem akarják a CTO felelősségét. Lehet, hogy nem szeretnek utazni, vagy egyszerűen inkább a szoftver-tervezés iránt érdeklődnek, mint a konferenciabeszélgetések, üzleti fejlesztések és értékesítési hívások, amelyek behatolnak sok CTO életébe. A főépítész felelős lehet a technológiai halmok kiválasztásáért, az együttműködések és a számítási rendszerek közötti interfészek megtervezéséért, a számítási szolgáltatások kínálatának (AWS, Azure, ZEIT Now stb.) Kiértékeléséért és így tovább. A főépítész az iparág kínálatának széles skáláját értékelheti, és előre jóváhagyott vagy kedvezményes ajánlásokat tehet az egyes gyártókkal való együttműködésre.

A vállalat érett állapotában a főépítésznek szintén szorosan együtt kell működnie a CTO-val és néha partnerszervezetekkel a szolgáltatások közötti integráció fejlesztése érdekében. Sok vállalatnál a CTO főépítészként is szolgál.

Szoftver építész

A szoftver-építész számos főépítész célját szolgálja, de általában a kisebb funkcionalitások keresztmetszetekért felel. Az építészek gyakran együttműködnek a főépítészekkel, hogy megvalósítsák a nagyobb építészeti elképzelésüket. A szoftver-építészek gyakran a technológiai verem választását választják bizonyos alkalmazásokhoz vagy szolgáltatásokhoz, nem pedig a vállalati szintű döntéseket.

Mérnöki projektmenedzser / Mérnöki vezető / Projektmenedzser

A mérnöki projektmenedzser (más néven „Engineering Manager” vagy egyszerűen „Project Manager”) felelõs a mérnöki csapat munkafolyamatáért. Néhány nagyobb társaságnak van mind műszaki vezetője, mind projektvezetője. Ebben az esetben a mérnöki vezető általában úgy viselkedik, mint a mérnöki helyettes a helyi csapat körében, míg a projektmenedzser vállalja az itt leírt felelősségeket.

A projektmenedzserek általában kapcsolódnak mind a termékvezetőkhöz, mind a mérnöki vezetőkhöz, például a mérnökök VP-jéhez, a CTO-hoz vagy egy középvezetőhöz a munkamaradások átalakításához és megrajzolásához, a munkajegyek előrehaladásának nyomon követéséhez, a részletes előrehaladási jelentésekhez (mérföldkő leégett diagramok, kitöltött vs nyitott jegyek, havi / havi jelentések stb.) Gondolhat rájuk, mint a gyártó összeszerelő üzletvezetőjének analógjára. Figyelembe veszik a munkapadot, és ellenőrzik, hogy az összeszerelő sor zökkenőmentesen működik-e, és hogy a munkatermék nem halmozódik fel a földre szűk keresztmetszet előtt.

A legjobb projektmenedzserek sok időt töltenek a problémák és hibák osztályozásával annak érdekében, hogy elemezzék a mutatókat, például a hibasűrűség jellemzőpontonként, mi okozta a legtöbb hibát (tervezési hiba, specifikációs hiba, logikai hiba, szintaxis hiba, típushiba stb.) stb. Az ilyen típusú mutatók felhasználhatók a különféle kezdeményezések hatékonyságának mérésére, és rámutatnak arra, hogy miként lehetne javítani a mérnöki folyamatot.

A mérnöki vezetők hajlamosak megérteni a különféle csapattagok erősségeit, és jól tudják elosztani a munkabérleteket a megfelelő felelős feleknek, bár ennek együttműködési erőfeszítésnek kell lenniük, amely visszajelzést kér az egyes fejlesztőktől arról, hogy mi a karrier céljaik és mit akarnak összpontosítani a rendelkezésre álló projekt hatókörén belül.

Ha időbeli nyomás vagy munkamaradás halmozódik fel, a projektmenedzsernek együtt kell működnie a mérnöki és termékvezetőkkel a kiváltó oka kiderítése és a működési zavar mielőbbi kijavítása érdekében.

Ahol csak lehetséges, a projektmenedzsereknek kellene csak azoknak lennie, akik a feladatokat közvetlenül az egyes mérnökökre ruházják át a többszörös főnök problémájának elkerülése érdekében. A mérnököknek világosnak kell lenniük arról, hogy kinek közvetlenül számolnak, és ki felel a rájuk delegálásért. Ha Ön másfajta mérnöki vezető, és bűnös azért, hogy közvetlenül a mérnökökre ruházza át, akkor valószínűleg jó ötlet egyeztetni az általa delegált jelentés felelõs mérnöki vezetõjével, és átruházni azon keresztül, hogy a a munka helyes, összehangolt prioritást kap, és a mérnöki vezető tisztában van azzal, hogy az egyes mérnökök miként aktívan dolgoznak egy adott pillanatban.

Nagyon kicsi szervezeteknél a mérnöki vezető gyakran a mérnöki műszaki vezető és a műszaki vezérigazgató (a megfelelő címekkel vagy anélkül). Ha ez te vagy, ne aggódj az előző bekezdés miatt.

Általános diszfunkció az, hogy a mérnöki vezető elkezdi azt gondolni, hogy azért, mert a termék megszakítja a mérnöki munkát a megvalósítás érdekében, és mivel a mérnöki vezetők szorosan együttműködnek a termékcsoportokkal, a mérnöki vezető jelentést tesz a termékmenedzsernek. Minden esetben, amit láttam, hogy ez történt, hiba volt. Lásd alább a „Működési zavarok elkerülése” című részt.

Technikai vezető / csapatvezető

A Tech Lead vagy a Team Lead általában néhány fejlesztő vezetője. Általában idősebb mérnökök, akik mentorokként, példákként és útmutatókként viselkednek a csapat többi tagja számára. Általában a mérnökök jelentést tesznek a projektmenedzsernek vagy a műszaki vezetőnek, de egy technológiai vezető felelős lehet a csapat kódminőségi intézkedéseiért, például annak biztosításáért, hogy megfelelő kódértékeléseket végezzenek, és hogy a csapat műszaki szabványai (mint például a TDD) fogadható el.

Mérnök karrier előrehaladás

A mérnökök általában két karrierút egyikét választhatják: menedzsmentbe léphetnek, vagy kódolhatnak. A vezetői pozíciók nem mindenkinek szólnak. Sok mérnök inkább a műszaki úton marad. Ez a haladás több irányt, fordulatot és fordulatot vehet fel, de így néz ki:

Gyakornok -> Junior szoftverfejlesztő -> Szoftverfejlesztő / mérnök -> Senior szoftvermérnök -> Fő szoftvermérnök -> Szoftverarchitektúra -> Senior Szoftvertervező -> Főépítész -> CTO -> Mérnöki munkatárs

Alternatív megoldásként azoknak a mérnököknek, akiket az emberek vezetői szerepe érdekel, az előrehaladás így néz ki:

Gyakornok -> Junior szoftverfejlesztő -> Szoftverfejlesztő / Mérnök -> Csapatvezető / Technológiai vezető -> Mérnöki vezető / Projektmenedzser -> Senior Engineering manager -> Mérnöki igazgató -> Mérnöki főnök

A műszaki vezetés működési zavarainak elkerülése

Az IMO-nak, a műszaki vezérigazgató-helyettesnek, a CTO-nak, a termékért felelős VP-nek és a marketingért felelős VP-nek mind közvetlenül az ügyvezető igazgatónak kell beszámolnia. Mindegyiküknek felelősnek kell lennie a saját folyamatáért. A külső felületű CTO-knak nem kell közvetlen jelentéssel rendelkezniük (ha igen, ez általában azt jelenti, hogy mind a CTO-t, mind a Mérnöki Szerepek VP-jét kitöltik). Ehelyett a mérnöki vezetők jelentést tesznek a mérnöki alelnöknek. Ennek célja a két főnök diszfunkciójának elkerülése, hanem azért is, mert ezek a szerepek alapvetően különböznek: az egyik az ügyfelekre és a szervezetnek a szélesebb világba illesztésére összpontosít, a másik a belső, napi műveletekre összpontosít. Két vadul különféle képességkészlet, néha versengő prioritásokkal.

Nagyon sok működési rendellenességet láttam a mérnöki vezetésben, mert zavarban van, hogy a műszaki vezetők miért felelősek, és ez általában a katasztrófa receptje. Bármi is legyen a szervezetének megfelelő, ügyeljen arra, hogy a felelősség és a hatalmi lánc egyértelmű legyen, annak elkerülése érdekében, hogy a mérnökök két vagy három „főnök” között szakadást érzzenek.

Hasonlóképpen, elegendő méretű szervezetben a terméknek és a mérnököknek két külön vezetett csapatnak kell lenniük. Ez alatt azt értem, hogy a termékmenedzsernek kell a tulajdonosa a termék ütemtervének. A felhasználók evangélistainak kell lenniük, és valóban csatlakoztatni kell őket a felhasználókhoz, gyakran 1: 1 arányban vegyenek részt velük, és mélyen megismerjék munkafolyamataikat és fájdalompontjukat. Szakértőknek kell lenniük a piac igényeihez, és nagyon ismerniük kell a társaság erősségeit és képességeit ezen igények kielégítésére.

Ennek ellenére a mérnöki alelnöknek (vagy bárkinek, aki ezt a szerepet tölti be) felelnie kell a szállításért és a gyártási ütemért. Míg a termékmenedzsernek kell lennie az ütemtervnek, addig a műszaki vezetőknek felelősséget kell vállalniuk az ütemterv prioritásainak elfogadásáért, a műszaki kapacitásokhoz való hozzáigazításáért és az időzítés jelentéséért. A termék- és marketing csapatoknak erős véleményük lesz arról, mikor kell valamit szállítani, de csak a mérnöki vezetés mérlegelheti, hogy ezek a szállítási határidők lehetségesek-e vagy sem, tekintettel az ütemterv követelményeire. A mérnöki csapatnak nemcsak az időzítés visszaszorítására, hanem a legtöbb esetben az időzítés teljes megszervezésére, a vezérigazgató, a termék- és marketing csapatokkal való együttműködésre van szüksége a prioritások meghatározásához, a vállalat stratégiai igényeinek megértéséhez, majd az alakításhoz. egy olyan fejlesztési ütemterv, amely kielégíti ezeket az igényeket anélkül, hogy behúzza a határidőket, amelyek végül sértik a vállalat azon képességét, hogy megbízható ütemben szállítson minőségi termékeket.

A legjobban teljesítő csapatok, amelyekben valaha is részt vettem, csatlakoztak a határidők nélküli megközelítéshez. Kiváló termékeket építünk anélkül, hogy előzetesen bejelentenénk őket, majd hagyjuk, hogy a marketing csapatok előmozdítsák a már elvégzett munkát. Alternatív megoldásként, ha nyilvános nézetben dolgozik, az átláthatóság nagyszerű megoldás. Tetszőleges határidő betartása helyett inkább ossza meg előrehaladását a jegyek leégési táblázataival, a fennmaradó munka, az előrehaladás, a tempó és a fennmaradó hatály pontos áttekintésével, valamint az idő múlásával, amely jelezheti a hatókör kúszását. Ha részletes információkat oszt meg az elért haladásról, és osztja azt a filozófiát, miszerint nem tudjuk megígérni a szállítási határidőt, de megoszthatunk mindent, amit tudunk a fejlődésről, az emberek maguk is megnézhetik a munkát és a tempót.

Az eltérő, gyakran egymással versengő célok miatt a terméknek, a marketingnek és a mérnöki tevékenységnek külön szerepköröknek kell lennie, amelyeket közvetlenül az ügyvezető igazgatónak kell bejelenteni, ha egyikük sem tudja diktálni egymást. Ha a csapata időben nyomást gyakorol a túlórákra, vagy összecsap, hogy valamilyen kulcsot el lehet érni valamilyen lemondási határidő előtt, ez a működési zavarra utal. Vagy a mérnöki vezetők rossz embereknek számolnak be, vagy a csapatnak nincs erős mérnöki vezetője, aki megérti a szoftverbecslések hiábavalóságát, valamint azt, hogy együttműködésre van szükség-adás-vételre van szükség a mérnöki és a termék között a szállítás rugalmassága érdekében visszatérő MVP-k, hogy elérjék a szállítási célokat.

A terméknek a folyamatos felfedezési folyamat birtokában kell lennie. A folyamatos szállítási folyamatnak a mérnököknek kell lennie. A marketingnek együtt kell működnie a termékcsoporttal annak biztosítása érdekében, hogy a termék világszerte történő üzenetküldése pontosan megjelenjen. Az egésznek össze kell illeszkednie, mint egy csővezetékbe, simán áramló, pozitív visszacsatolási ciklust létrehozva. A futószalaghoz hasonlóan a folyamat leglassabb szűk keresztmetszetének is meg kell határoznia a folyamat többi részét, különben egyre növekvő elmaradáshoz vezet, amely annyira felhalmozódik, hogy a hátralévő elemek elavulttá válnak, és a hátralékkezelés teljesé válik. -idős munka.

Azoknak a termékcsoportoknak, akik úgy érzik, hogy a mérnöki munka nem lép lépést, először a mérnöki kézbesíthető anyagok minőségére kell összpontosítaniuk. Megfelelően megvizsgáltuk a terveket? Volt-e egy mérnök konstruktív visszajelzést adni a kézbesítés előtt? A szoftverhibák 80% -át specifikációs vagy UX-tervezési hibák okozzák, és ezek közül sokat meg lehet engedni, mielőtt a munkát valaha átadják egy mérnöki csapatnak. Miután ezt a folyamatot finoman befejezte, kérdezd meg magadtól, vajon valóban alaposan feltárták-e a termék dizájnterületét. Építettél egy UX-t, és úgy hívtad, hogy kész, vagy kipróbáltál több variációt? A felhasználói munkafolyamatok variációinak felépítése és tesztelése az egyik legértékesebb hozzájárulás, amelyet a termékcsapat nyújthat. Van olyan megbízható felhasználók vagy ügyfelek csoportja, amelyekkel A / B prototípus teszteket futtathat?

A szoftvercsapatok egyik legnagyobb diszfunkciója az, hogy a termékcsoport al-par teljesítményeket állít elő (néha alig több, mint néhány rohanó, hibás makett), és az ügyfelek vagy a mérnökök egyikét sem tudja futtatni, mielőtt azokat átadnák. . Ez a működési zavar halom újrahasznosítást és műszaki lemaradást okoz, amelyet gyakran a műszaki csapatoknak hibáztatnak.

Ügyeljen arra, hogy a felelősség-átruházás ésszerű legyen, hogy ne tegyen indokolatlan idő nyomást a mérnöki munkára, és hogy van egy nagyszerű termékcsapat, amely részt vesz az együttműködésen alapuló termék-felfedezési folyamatban, és valódi felhasználókkal dolgozik a legjobb termék elkészítésében.

Mérnöki vezetők, nem hagyom, hogy lekapcsoljon. Ha ezek a működési zavarok léteznek a csapatodban, akkor a te felelőssége, hogy kezelje őket termék-, marketing- és üzleti vezetéssel, valamint a mérnökökkel szemben támasztott követelményekkel. Az is a felelőssége, hogy megóvja csapata termelési ütemét, de további forrásokért küzdjön denevérre, ha a csapata nyomást gyakorol arra, hogy a jelenlegi kapacitásainál nagyobb mértékben tudjon termelni, egyértelműen számoljon be a munka üteméről és elmaradásáról, valamint a befejezett munka bemutatójára és győződjön meg arról, hogy csapata esedékessé válik az elvégzett finom munkáért.

Ne hibáztasson, hanem bizonyítsa, hogy csapata a legjobb munkáját végzi.

Eric Elliott elosztott rendszerek szakértője és a „Szoftver készítése” és a „JavaScript alkalmazások programozása” könyvek szerzője. A DevAnywhere.io társalapítójaként megtanítja a fejlesztőknek a távoli munkához és a munka / magánélet egyensúlyához szükséges készségeket. Fejleszti és tanácsadó fejlesztőcsapatokat kriptoprojektekhez, és hozzájárult az Adobe Systems, a Zumba Fitness, a Wall Street Journal, az ESPN, a BBC és a legjobban felvevő művészek, például Usher, Frank Ocean, Metallica és még sok más szoftveres tapasztalatainak fejlesztéséhez.

Élvez távoli életmódot a világ legszebb nőjével.