«Product engineer» ескі жұмысқа қойылған жаңа атау сияқты естіледі, бірақ айырмашылығы бар. Дәстүрлі инженер жұмыс көлемімен өлшенеді: жабылған тикеттер, талапқа сай жасалған функциялар. Product engineer нәтижемен бағаланады: пайдаланушы әрекетті шынымен орындады ма, көрсеткіш өзгерді ме, бизнес төлеген құнын алды ма? Код сол күйі қалады; оны жазар алдындағы сұрақ өзгереді.
Іс жүзінде product engineer жұмысты басқаша атқарады. «Қалай?» демей тұрып «Неге?» деп сұрайды: қандай мәселені, кім үшін шешеміз және нәтиже болғанын қалай білеміз? Қарапайым нұсқа бірдей құнды үш есе жылдам берсе, техникалық талапқа қарсы пікір айтады. Макеттегі сәтті сценариймен шектелмей, пайдаланушының бүкіл жолын — жүктелу, қате және бос күйлерді қоса — ойлайды. Релизден кейін жасыл CI белгісіне ғана емес, аналитикаға, қолдау өтінімдері мен сеанс жазбаларына қарайды.
Бұл рөл кең ауқымды талап етеді. Дерекқордың үздік маманы не ең мықты дизайнер болу міндетті емес, бірақ бүкіл тізбекпен жұмыс істей білу керек: деректер моделі, API, UI, деплой, аналитика және енді ЖИ. Сондықтан full-stack инженерлері жиі product engineer болып өседі: функцияны басынан аяғына дейін өзің басқарсаң, «неге?» деген сұрақты тапсыратын адам болмайды. Мен үшін бұл Postgres схемасынан Next.js экранына, одан функцияны пайдаланғанын көрсететін оқиғаға дейін жалғасады.
Product engineer шағын қадамдармен шығарып, тез үйренеді. Бірінші нұсқа — алты айдан кейін шығатын платформа емес, feature flag артында өндірістік ортада өлшенетін бір әрекет. Қай тұста жеңілдетуге болатынын (әкімші панелі көріксіз болуы мүмкін, қолмен істейтін кезең бір ай сақталуы мүмкін), қай тұста болмайтынын (төлемдер, рұқсаттар, деректер тұтастығы) біледі. Жұмыстың көбі осы пайымға сүйенеді; ол өз шешіміңнің салдарымен өмір сүргенде ғана қалыптасады.
Бұл — коммуникация рөлі де. Product engineer құрылтайшылармен фреймворктерді емес, тәуекелді, құн мен уақытты талқылайды. Дизайнерлерге ненің қымбатқа түсетінін айтып, арзанырақ балама ұсынады. Қолынан келген сайын пайдаланушылармен сөйлеседі. Шешімдерді де жазып қояды: алты айдан кейін бір шешімнің себебі туралы қысқа жазба кодтың өзінен де құнды болуы мүмкін.
Өзімді product engineer деймін, өйткені жұмыстың ең маңызды бөлігі — pull request емес, нақты адамның жасаған өнімімізді қолданып, оның дұрыс жұмыс істеген сәті. Сондықтан екі аптадан кейін тапсыра салғаннан гөрі ұзақ мерзім жұмыс істегенді ұнатамын: нәтижесін көрмейтін іске жауап бере алмайсың. Қолайсыз сұрақтар қойып, содан кейін шешімді жеткізетін инженер керек болса, маған жазыңыз.
Келесі өнімге онымен бірге қалатын адамды беріңіз.
Бастауға дайынсыз ба? Маған жазыңыз — қазір бастап, әрі қарай қалуға дайынмын. Екі апталық тапсыру емес, ұзақ мерзімді келісімдер. Жобаңызды, талаптарды және алға жылжудың ең тиімді жолын талқылайық.