Хто такі продуктові інженери і чому ми відкрили першу в Україні таку вакансію?

Передісторія

Мене звати Радомир — я засновник фінтех-стартапу Saldo Apps. Нещодавно ми перші в Україні відкрили вакансію Product Engineer. Можна подумати, що то ми просто вирішили виї..ся придумати хіпстерську назву для звичайної вакансії розробника, ну типу як в ресторанах сухарики називають croûton, а фрикадельки — мітболи. Але ні, це окрема позиція. Скажу більше — я втратив більше мільйона доларів через те, що не знав цього терміну і не хочу втрачати ще.

Вже 10+ років як я світчнувся з сервісного бізнесу на створення продуктів. Спочатку самостійно, згодом у складі Netpeak Group, зробив кілька екзітів і наче тут можна було б розповісти про успішний успіх і почати продавати курси, але... щось пішло не так...

Ми жваво почали робити класні продукти в Saldo Apps і вийшли на $1M річного ревеню, аж от нам знадобився повноцінний бекенд. Як майже в будь-якому стартапі у нас був хаос, відсутність делівері-процесів, зрозумілих ТЗ та інших атрибутів сталого бізнесу. Що в нас було не так, як в інших стартапах, — у нас не було засновника з технічним бекграундом або СТО.

Майже півтора роки ми змінювали бекенд-розробників, і я не міг зрозуміти, в чому проблема, — я ж до того побудував вже не один продуктовий бізнес, а тепер як на ручник встали. Уявіть: бекенд-розробники просили чіткі ТЗ :)

Я ніяк не міг допьохати, чому це вони не можуть самі подумати, як зробити якусь фічу так, щоб юзерам було зручно. Бо iOS та Android розробники, з якими я працював вже на багатьох проєктах, чомусь не просили чітких ТЗ. При тому це були кваліфіковані бекенд-розробники з крутим досвідом в великих компаніях.

І ось тут і ключова каверза, яку я раніше не усвідомлював.

Стартапам потрібні трохи інші розробники, ніж великим компаніям, або компаніям зі сталим продуктом та процессами.

Є дуже круті розробники, які вирішують неймовірно складні задачі, але їм можуть бути цікаві саме технологічні виклики. Тоді як стартапам на ранніх стадіях важливіше бажання та вміння розробника побути у взутті кінцевого юзера і зрозуміти, як саме буде використовуватися продукт або фіча.

Десь в голові і в спілкуванні з командою я використовував термін «продуктовий майндсет», але не було чіткого формулювання, що то таке. І найголовніше — я не розумів, що «продуктовий майндсет» — це не щось, притаманне більшості розробників. Скоріше навпаки. На попередніх проєктах мені просто випадково (чи все ж не випадково?) щастило працювати з розробниками саме з продуктовим майндсетом, тому і виходило все без детальних ТЗ та відбудованих процесів.

Я хотів наймати таких розробників як мені треба і не наймати таких як мені не треба :) (навіть якщо це круті розробники). І я почав думати (нарешті!) як мені визначити тих, хто мені потрібен.

  1. Виписав конкретні кейси та життєві ситуації, де мої очікування відрізнялися від поведінки розробників.
  2. Ейчари Netpeak Core, консалтингової компанії, що входить до складу Netpeak Group, допомогли мені визначити, які здібності та навички відповідають за ті чи інші поведінкові патерни, які я описав.
  3. На основі цих кейсів ми розробили анкету-тест на «продуктовий майндсет» і валідували на десятках розробників, про яких ми знали, що в них яскраво виражений той самий продуктовий майндсет.
  4. Параллельно ми з командою сформулювали тези Культури Розробки Saldo Apps.

Наступним етапом треба було сформулювати опис вакансії, і я вирішив подивитися якісь приклади, коли в вакансії шукають розробників саме з продуктовим майндсетом.

Я поліз в цей ваш інтернет і виявилося, що я не перший з таким запитом (ахаха, сюрприз).

Ось декілька найбільш цікавих, на мій погляд, посилань:

  1. Product engineers. We had just finished a customer... | by Sherif Mansour
  2. The Product-Minded Software Engineer

Що стало несподіванкою, так це те, що 9 прикмет/рис, притаманних продуктовим інженерам, майже один до одного збігаються з тим, що ми сформулювали в нашій Культурі Розробки.

Скажу відверто — перша реакція після того, як я прочитав ці статті, була близька до відчаю. Бо нахіба було втрачати стільки часу та грошей і чому було не пошукати готові відповіді/рішення своїх проблем.

Але зрештою ми з командою дійшли до того що, мабуть, воно на краще, що ми все зробили самі. Бо це дві великі різниці: коли ти береш якийсь готовий фреймворк, або коли це вистраждані власним досвідом правила. Ми по кожному пункту знаємо чому нам треба саме це. А знайдені статті корисні тим, що підтверджують, що ми дійшли правильних висновків.

Ось так ми і дійшли до вакансії Product Engineer.

Важливий момент, що продуктовим інженерам, скоріш за все, буде нудно в великих компаніях, бо їм зазвичай цікаво мати вплив на продукт. І навпаки — компаніям зі сталими процессами та продуктами може бути навіть небезпечно мати забагато продуктових інженерів, бо такі розробники завжди з чимось незгодні і можуть витрачати купу часу продуктової команди та менеджменту на спори. І якщо (а так в великих компаніях буває частіше за все) до їх думки не прислухаються — вони сумують і вигорають.

Мій висновок:

Стартапам на початковій стадії краще мати в команді більшість продуктових інженерів (розробників з продуктовим майндсетом), а компаніям зі зрілими процесами та сталими продуктами корисніше мати більшість традиційних розробників.

Буду радий посперечатися в коментарях ;)

👍ПодобаєтьсяСподобалось6
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Hiring dysfunctional managers -> writing an article “Why I need a dev who does analytics and product discovery”. Не забудьте не звільняти дисфункційний менеджмент.

Цікаво дізнатись пан Радомир втратив більше мільйона реальних доларів, який в нього був, чи віртуальних які не заробив не ввівши особливий тайтл для працівника стартапу (робиш усе і ще починаєш принтер, за зарплатню в 1/4 від ринку) ? Чи це як в тому анекдоті — коли потенційно маємо три мільйони доларів, а реально дві щльондри і старий гей.
aprogrammerlife.com/...​OYoNxq41dD6cesnnvZ-P7RfpQ

Більше мільйона реальних долларів. Щодо принтера та зарплатні в 1/4 від ринку не зрозумів

Справа в тому — що ніякого «продуктового майдсету» не існує, процес створення ПЗ він насправді жодним чином не залежить від типу компанії. Це набір знань та вмінь (навичок) який або є в організації, або його нема (інженерна культура). В великих колетктивах зазвичай є розділення праці, менеджмент в декілька рівнів, інколи професійний, інвестиції в навчання і т.п. Тобто технологія яка гарантує результати при відповідних вкладеннях часу та необхідних ресурсів. Збір вимог, проектування, притопування, розробка, контроль якості, планування та бюджетування, маркетинг та стратегії виходу на ринок тощо з цього людство набуло багато знань, є відповідні спеціалісти написані книги безцелери зокрема, авторів : Алан Купер, Роберт Мартін, Кент Бек, Фредерік Брукс, Джоел Сполькі тощо.
Коли я працював в стартапах джуніором та мідлом над продуктами, усе це читалось спочатку з під палки потім по рекомендації колег тощо. Оскільки це були стапртапи в нас навіть QA коли були, то вже було великим плюсом усе інше робили ми самі власними силами, навіть по форумам типу стек оверфлоу нахвалювали свій софт, після чого справді з’являлись клієнти на сапорт (який теж між іншим довго було як відкритий форум зроблено). І так ЗП була значно менша ніж на ринку на який вийшли аутсорс компанії, ніяких опціонів і т.п. теж не було, було лише ентузіазм (хоча на початку враховуючи бідність країни ЗП взагалі то була не погана враховуючи загальний рівень та загальні ціни).
Це класика стартапів, зазвичай, це робота мрії лише для засновника — для інших це робота. Звісно як не вмієш торгуватись по молодості та відсутності досвіду з бізнесу, ну тобі і кататимуться, це в принципі усюди таке в повний зріст, та в корпораціях трошки важче проходить, є стандарт як та кого обьэгорити.
А за мільйон доларів ви легко могли винайняти великого аутсорсера, який би вам усе зробив під ключ. З таким бюджетом з вами з радістю вже будуть розмовляти. Так є клієнти і на сотні мільйонів, та таких мало. Більшість не дотягне і до пів мільйона.

Не згоден категорично.
Є девелопери які вникають в бізнес і розуміють що треба вирішувати бізнес задачі.
А є девелопери що кажуть створити мені таксу і детально розпиши що я маю зробити. І аутсорс нажаль продукує і цінить других, бо це лягає ідеально на їх бізнес модель. Чим більше фреймворків ти знаєш тим ти крутіший і цінніший бо легше продати вже і подорожче.
Але стартапам і маленьким продуктам потрібні перші.
Особливо коли домен складний.

Проблема топікстартера що в нього бізнес український і він хоче платити на тому ж рівні що й аутсорсери, а платити треба 2х інакше людям не цікаво буде працювати.

Швидше — що нема грошей на команду з великої кількості спеціалістів різного профілю тому треба «продуктовий віжен», тобто розумні дураки.
Та якщо дійсно йдеться про мільйонні бюджети (про що я особисто дуже сумніваюсь) то він в цілому хернею займається, краще звернутись до перевіреного вендора, а в штаті мати лише CTO партнера чи невелику кор команду, яка ставитиме завдання та перевірятиме результат. За мільйон я гарантую в Україні можна на рік отримати команду десь на 50 людей усіх потрібних профілів, з обладнанням, тренінгами з підвищення кваліфікації тощо. Мільйон це чудовий бюджет. Хоча знавав я даму з Англії яка зуміла і такий великий бюджет за овербеджетити, переважно тому що їй довелось купляти компьютери для дата центру і на розробку софту не вистачило та на сам перед просто вона була не ІТ менеджером, що потрапила в ІТ і просто розгубилась, а одна відома американська контора цим відверто скористалась і запустила її компанію на паровозики. Та і вендор теж не відставав, видавши купу джуніорів за сініорів.

Як людина що пропрацювала в аутсорсі 20 років не раджу нікому ніколи аутсорсити.

За мільйон я гарантую в Україні можна на рік отримати команду десь на 50 людей усіх потрібних профілів, з

То як?)

10 людей по 7к$ і на 12 місяців і вже є 840к$. Ще техніка, амазон, софт, бізнес тріпи і т.п. і той 1кк легко за рік виходить.

І то тут без бізнесу як такого (маркетинг, сейли)

Легко по сініорськкому рейту 40-42 на годину йде тільки необхідна кількість сініорів і в реаліях тільки не досвідчений менеджер буде набирати самих сініорів в проект і йти в мінуса.

Ще техніка, амазон, софт, бізнес тріпи і т.п. і той 1кк легко за рік виходить.

Це усе в реаліях вкладається в менші суми, якщо звісно не митарити. Кажу як бачів на власні очі — за такий бюджет менеджери ладні один одному розгризти горло. Від мільйона це вже починає бути смачно. Більшість проектів має значно скромніший бюджет.

Девелопери які кажуть робити таску де усе написано (на достатньому для оцінки трудовиьрат рівні 100% вимог рідко коли можна дізнатись, 75-80% зазвичай вже достатньо), це зазвичай досвідчені люди яким вже дістало, не фіксування зобов’язань коли не розписана таск виливається тобі в переробки безкоштовні овертайми, скандали з QA, scope creep та провал делайнів які повісять на тебе. Розписана таска як і документація (в розумних об’ємах) повністю необхідна річ. Коли тобі надають таску без зрозумілого і на достаньму рівні фіксованого формалізованого об’єму роботи і ти на це погоджуєшся, ти закриватимеш чуже сачкування або некомпетентність втратою власного рейту. Так іноді доводиться погоджуватись на такі вимоги, скажімо коли на ринку нема роботи чи треба взяти нового клієнта (тобто надати скидку). Але як таке це йде довго , абсолютно точно сядуть на шию, це модель співробітництва Win Loose не на твій рахунок.
А коли це ще і систематично — то клієнт і усю компанію може кинути і результат такий, що клієнт або власник весь відділок кинув. Працювали витратили час та гроші (запросто ще і обладнання і різне світло там чи інтернет купляли за свої), овертаймили — а результат у мінус по фінансам потрапили. Тоді як власник купив новеньку не дешеву машину яку «так беріг», що побив вже наступного тижня. А з вас регоче уся контора, і задрачують, ходять питаючи як ви там подали корпоративну ліцензію? Може вам якусь премію надали і т.п. Потім ще сейлс звільниться, бо в нього ще і борги по зарплатні при цьому усьому.

Ви розписали типові проблеми аутсорсу але вони не мають ніякого відношення до стартапів. Топікстартер описав типову проблему найму людей в стартап, а йому починають описувати проблеми аутсорсерів.

Який у вас досвід роботи в продуктових компаніях і стартапах?
Мені здається, ви пишете саме про досвід у сервісних компаніях, де є «клієнт» який щось замовив на певну суму, і далі всі намагаються в цю суму вкластися. Крок вліво-вправо від початкових вимог — це вже додаткові витрати, які б’ють по прибутковості.
Тут ТС про інше зовсім пише.

4 роки. Я знаю про, що пишу. Капіталізм не вирізняється від кількості посередників в оборудці як то галери. У будь якому випадку ви виробляєте програмне забезпечення за гроші тобто виробляєте продукт і ключовий тут момент, ви самі маєте з цього заробляти. Гарантую в будь якому типі компанії вас намагатимуться нагріти.

які б’ють по прибутковості

Відкриваю простий секрет — будь яка розробка не безкоштовна, коли : програмістам платять зарплатню, витрачається електрика, амортизація обладнання, оренда серверів тощо. Ви ходите (або підключаєтесь) на роботу теж з конкретними ціллю — заробляти гроші першочергова ціль. І коли будь який продукт вам втирає, різні : «продуктові віжени», «act like a startup», «ми не компанія а родина» це усе звичайнісіньке маніпуляції з ціллю отримання від вас діскаунту. Погоджуючись на проділки продукта який залишає за собою право будь коли міняти вимоги, розширювати скоуп, зрізати строки, не платити за необхідне обладнання (сервера, мобільні ліцензії на софт типу джири тощо) ви особисто попопадаєте в мінус, бізнес ведеться зокрема за ваш рахунок. Так усі хто продає, надають знижки особливо коли є велика конкуренція, але їх має бути певний рівень щоб не піти зовсім в мінус типу 996 та no life.
Про супер-дупер класний «продуктовий бізнес» можете розповісти десяткам тисячь людей звільнених з FAANG торік. Виявляється в Америці подвійні стандарти, одні декларуються в комерційний цілях як то «корпорація добра», інші — мільярдні статки засновників та інвесторів виявляються пріоритетом номер 0. Аж до рівня коли можуть президенту дзвонити не атакувати нафтову переробку у федерації, бо в Америці зростає ціна на нафту і люди переживають, що зароблять менше (насправді ціна зменшилась).

оборудці
галери
вас намагатимуться нагріти
продукт вам втирає
звичайнісіньке маніпуляції
проділки продукта
ведеться зокрема за ваш рахунок
подвійні стандарти

Або у вас з якихось причин був вкрай негативний досвід з вашими роботодавцями, не пощастило, або ж навіть не знаю звідки така концентрація негативу(:.

Про супер-дупер класний «продуктовий бізнес» можете розповісти десяткам тисячь людей звільнених з FAANG торік

Можу помилятися, але мені здається, що в усіх цих випадках компанії повністю виконували свої зобов’язання з точки зору виплат і попереджень. Іноді додавали «зверху». І я і ви в будь-який момент можемо змінити роботу, чому нас не можуть замінити так само? Тут немає обману ніякого, все абсолютно чесно.

Повернувшись до теми, хочу сказати, що люди різні: комусь цікава виключно технічна частина, комусь взагалі нічого не цікаво в роботі (тому будь-яка задача сприймається як покарання від якого треба навчитися ухилятися), а комусь цікавий і продукт і бізнес. Типовому аутсорсеру скоріше буде цікавий спеціаліст із першої групи, бо замовники і проєкти змінюються, а вся ключова продуктова розробка часто на стороні клієнта. Продукту (як мінімум маленькому) або стартапу потрібні люди з третьої групи. Люди з другой нікому не потрібні(:.
От тут ТС і описує як зміг для себе вирішити пробему пошуку тих, хто підійде, от і все. А його звинувачують що він когось обманути хоче чи ще щось таке, хоча ж навпаки мова йде про чітке співпадіння взаємних інтересів компанії і програміста.

Є девелопери які вникають в бізнес і розуміють що треба вирішувати бізнес задачі.
А є девелопери що кажуть створити мені таксу і детально розпиши що я маю зробити

Так це про сіньйоріті.

Є девелопери які вникають в бізнес і розуміють що треба вирішувати бізнес задачі.

Девелоперы не решают бизнес задачи, а автоматизируют их. Девелопер Вася из Епама не будет многомиллионным бизнесам навязывать бизнес процессы и пытаться их изменить. Он может только стараться вникать в бизнес-флоу данное Богом свыше и стараться его автоматизировать.

Ну тут не зміг втриматись. Аутсорс і стартапп— з мого погляду це про тверде і квадратне. В аутсорсі до речі, теж можна втрапити в стартап, ну якщо можеш, бо це таки челендж і потребує таки дійсно специфічного погляду на речі. Слово Тшапед ото про те. А стартапп прямо посеред корпорації з топ 10 явище теж поширене. З усіма стартапними речами — з півотами за потоками грошей, підбором та обгрунтуванням тех вибору, та пошуком кращого маркет фіт, модерні технології, використання модерних баззвордів так як вони задумувались, наприклад біхевіорал сайенс— для профілювання користувацького досвіду та вкорінення звичок )

А є девелопери що кажуть створити мені таксу і детально розпиши що я маю зробити

Есть специально обученные люди — БА, которые должны преподносить разрабам такие таски. Если вы сидите, обсуждаете с заказчиком часами его бизнес и что он хочет и превращаете это в таску, значит ваш БА получает зп зря (или вы недополучаете его полную величину зп).

Згоден. Я більше звернув увагу на це:

і детально розпиши що я маю зробити

І згадав, що є девелопери, які хотять, щоб вже технічну формалізовану таску йому розписали як само треба зробити.

«БА», «замовник», «рейт» — це все на аутсорсинговому(:.
Подивіться на типову орг структуру в продуктових технологічних компаніях: там немає ні замовника, ні БА.

Є девелопери які вникають в бізнес і розуміють що треба вирішувати бізнес задачі
Особливо коли домен складний.

Коли домен складний то треба наймати продукт менеджера або бізнес аналітика.
А не очікувати що інженер буде робити з себе Т/Ш спеціаліста (а насправді ущербного інженера) бо бізнесу так дешевше.

Так, є люди яким цікаво і код писати і фічі видумувати. Я між переходом з сіньора на ліда теж таким займався. Але за рік стало зрозуміло що я не стану ні хорошим продуктом, ні хорошим інженером одночасно.

Щодо опису культури розробки до яких ви прийшли. Ось цей пункт мене здивував:

There should be no black box in architecture or code. Architecture and code should be transparent and understandable to anyone. Kludges are unacceptable. Any exceptions must have substantial justification and be approved at the highest level. «I made a kludge coz someone rushed me» is a mortal sin, not an excuse.

Стартап який змінює бекендера, який має лише пару бекендерів хоче щоб інженери не пояснювали гівнокод тим що у них дедлайн занадто скоро і немає часу на чисту архітектуру. Не віриться що ви цього досягаєте. З мого досвіду ви якраз на етапі коли такого технічного боргу створюється багато. Як на мене баланс досягається не декларуванням що ми всі в білому пальті, а наступним:
— описом в коді або документації як ти нагівнокодив і чому/як треба переробити.
— відповідальністю переробити це бо ти ж це створив
— хорошою документацією як все працює

Власне принципи розробки з IBM (коли вона не була аутсорсовою галерою) і стартап :) Класика книжки для Зулусів, які прагнуть в ІТ бізнес. Хоча безумовно нічого не вірного в тезі нема, крім того — що не сказано, що розробка по правилам вона як і видобича вугілля в шахті, достобіса дорога.

Згоден. Зауважу що я не кажу що принцип неправильний. Просто зазвичай так не відбувається у стартапі.

Хоча дивлячись який стартап, хто в ньому працює які інвестиції, які консультанти тощо. У більшості стартапів проблеми виникають зовсім не з кодуванням www.youtube.com/watch?v=IBt_z2ZZSLI (усе це бачів в живу, неоднаразово, нові відділки в корпораціях це теж стартапи за тим же Кавасакі в його книгах).

Мені здається що у більшості уявлення про продуктових інженерів не вірне. Продуктовому інженеру не обовʼязково вміти в UX, або аналітику. Але мати бажання покращувати продукт для користувачів обовʼязково.
Продуктовий інженер має сказати продукту що ідея херня. Бо вкладемо кучу ресурсів в реалізацію (ну бо продукт менеджер не може цього знати не розуміючи архітектури і не знаючи кодової бази). А замість цього запропонувати щось схоже і примітивніше, але те що легко кладеться на архітектуру і тому займе не так багато часу.
Продуктовий інженер має вміти декомпозувати проблему. І іноді приходити і казати що через підводні камені те як ми хотіли зробити швидко не виходить. І UX вийде не той, і технічного боргу створимо багато, і фіча зможе бути використана лише 10% користувачів для яких фіча першочергово планувалася (це часто стає відомо в процесі розробки коли достатньо контексту про технічну реалізацію). Давайте відмінимо фічу.

Продуктовий інженер має розуміти свій домен. Не просто як сервіс Х викликає сервіс У, а чому фіча так побудована. Чому вона така складна (регуляції, застарілість системи подачі звітності в податковій, тощо). Це дає можливість знаходити продуктові інсайти поки ти розробляєш код. І це дає змогу бачити що маленька фіча не така вже і маленька, бо щоб нею користувалися доведеться ще декілька інших фіч змінити щоб в країні користувачів це було адекватним рішенням.

Чому класно розуміти аналітику чи UX. Бо інженер має додаткові інструменти в своїй роботі. Бо він може проаналізувати чи його реліз працює так як він задумував в архітектурі. Бо більша кількість ролей це більші витрати на комунікацію.

Ну є і зворотня сторона ролі продуктового інженера. Оскільки на продумування і декомпозицію фічі не витратили час то продуктовий інженер буде набагато повільніше деліверити адже він має все це проробити самотужки.
Та й естімейти зазвичай не працюють бо задачі широкі і невизначені, а отже часто не ясно що саме треба зробити щоб їх запровадити. Взагалі скрам в таких умовах не ефективний і краще застосовувати agile.

Цікаво чи вдалося топікстартеру знайти свого продукт інженера.

Так, в нас майже всі саме такі. Але по бекенду (Java) поки ще недостатньо людей.

Так а нащо це інженеру — виконувати роботу ВА/РО?
При тому що ринок здебільшого сервісний (був). Ви завтра його заільните а він витратив свій час не на технічний зріст а на якісь бізнес-нюанси та збір вимог. Або 100500 мітингів.

На наступному місці роботи, на співбесіді йому скажуть — поверни бінарне дерево або особливість фреймворку Х при ситуації У, а він — «ну я розбирався в користувацькому досвіді».

Я думаю навпаки досвід аналітичний це рівень вище чим йти на проект де основою інтервʼю є якась задачка на бінарне дерево. Коли ти solution architect чи tech lead то добре мати скіли у бізнес штуках.

З мого досвіду — за це не платять. А за програмерські скіли можуть заплатити — якщо пощастить.

Підтримую — вміння в ’ де композицію бізнес процесів’ це рівень трохи вище чим знати бінарні дерева. Але це залежить від проекту та компаній. Бачив компанії де розробники займались чисто ’манкі кодінгом if else’ та бачив проекти де розробники майже брали роль PO/BA

Сподіваюсь у вашій компанії і винагорода значно вища за ринкову? І мабуть ділитесь акціями?

ЗП — ринкова (не сказав би що прям значно вища за ринкову, але точно не нижча). Акціями ділимося, так.

На основі цих кейсів ми розробили анкету-тест на «продуктовий майндсет» і валідували на десятках розробників

а під це вже завели окремий стартап?

Майже півтора роки ми змінювали бекенд-розробників, і я не міг зрозуміти, в чому проблема, — я ж до того побудував вже не один продуктовий бізнес, а тепер як на ручник встали. Уявіть: бекенд-розробники просили чіткі ТЗ :)

Привіт, Радомире!

Як завжди — кадр вирішують все, і тут питання до кадрів, а точніше до HR-відділу, який спочатку не зміг правильно позиціонувати бренд Saldo.

Як він позиціонувався бренд: Saldo Apps — українська продуктова компанія. Ми створюємо фінтех-екосистему для самозайнятих людей, малого бізнесу та фінансово підкованих людей.

Як треба було позиціонувати — ми стартап, підняли грошей, але у нас дупа в коді (або навпаки — не важливо) і ми не можемо скейлінг/фічінг/чогось там ще, потрібен чарівник (солюшин-архітект-розробник-дивопес) щоб знайти рішення і його ж здійснити.

Ну позиціонування стартапу то відповідальність фаундера а не HR-відділу, тому приймаю ці зауваження на свій рахунок :) Дякую за рекомендації, будемо покращувати

Я б швидше розділив інженерів на ініціативних і ні.
Ініціативні і стартап запиляють, і банківський ентерпрайз покращать.

А без ініціативи всюди віддача буде менша, просто сталі великі проекти можуть собі дозволити мати працівників які приносять менше користі

Ніфіга, проблема насправді набагато складніша.
Я б її сформулював як конфлікт інтересів: бізнес хоче коротко описати бізнес проблему і щоб її інженери вирішили самі не задаючи занадто багато запитань, а інженери хочуть щоб їм розжували всі бізнес вимоги до найменших дрібниць, причому кожного разу для кожної бізнес проблеми.

якщо інжерени хочуть щоб їм розжували всі бізнес-вимоги, то класно. Гірше коли не хочуть щоб розжували і роблять не розуміючи бізнес-вимог :)

а інженери хочуть щоб їм розжували всі бізнес вимоги до найменших дрібниць

Це в загальному неможливо, тому завжди йдуть уточнення по ходу роботи. В більшості же випадків маємо справу коли бізнес не може взалалі сформулювати — що їм треба, з цілої купи причин. Від автоматизації хаосу або створення бізнес процесів разом із софтом і польотом фантазії і бажанням усе переробити за пару днів до релізу звісно без змін строків та бюджетів (тобто безкоштовними овертаймами), до взаємно виключних вимог від різних стекхолдерів великої корпорації з політичних причин, коли вище керівництво задумало уніфікацію бізнес процесів і софту, що його автоматизує — а різні департаменти бізнесу мають принципово різних клієнтів і бізнес моделі тому уніфікація насправді йде в рівень кастомізацій в софті так, що простіше би і дешевше було написати три чотири окремих системи, бо для різних брендів ніби то однієї організації виходять повністю протилежні бізнес процеси.

Ініціативність буває не обовʼязково продуктова. Є розробники яким наприклад цікаво вирішувати технологічні а не продуктові виклики. Це гарні розробники, просто для інших організацій.

Комусь важливо ’кодити код’, а кому то бізнес солюшн.

З подивом прочитав статтю.
Завжди думав, що інженери саме такими і мають бути. )
Інакше — це просто профнепридатність. ))

Я теж не зрозуміла, те що описано це «нормальний інженер» а не якийсь там продуктовий.
Описана людина якій не пофіг що саме він/вона робить.

Я все ж не погоджусь з цим :) Є розробники яким цікаво наприклад вирішувати технологічні челенджі (типу як зробити цей код в 2 рази швидшим) а не продуктові (тобто думати про те як цією фічею будуть користуватися енд-юзери) — просто такі розробники більш корисні в умовних гуглі та фейсбуці, а не в стартапі ранньої стадії

Ну якщо ви не маєте грошей на продакт овнера — то будете наймати більше «продуктових розробників». Вони ж дешевші.

продуктові (тобто думати про те як цією фічею будуть користуватися енд-юзери)

Сюрпрайз)) продукти бувають геть інші, які ніякого відношення до енд-юзера не мють. І таких суттєво більше. Чи не на порядок. Сповна розуму інженер, певен на 99.99%, віддасть перевагу якраз таким «продуктам», чим трах@тись з енд-юзерами.
Ви трохи перекрутили те що нагуглили, на мій погляд. В тому розумінні, що «продуктовий інженер», це певно людина, якій описують проблему на високому рівні, а вона її вирішуює від ідеї до commissioning and post-production support.

Сповна розуму інженер, певен на 99.99%, віддасть перевагу якраз таким «продуктам», чим трах@тись з енд-юзерами.

ІМХО таких треба гнати в шию, ти його питаєш про вимоги віно лізе : проектувати софт, пограмувати, перевіряти покриття кода тестами, налаштовувати кафку, дивитсь логи на сервері тощо. Звісно є добрі продукти з технічним бакграундом, та вони в меншості.

але хіба повинен інженер працювати над UX, ініціювати A/B тестування, копатись в аналітиці і тд, щоб

думати про те як цією фічею будуть користуватися енд-юзери

здається ці обовʼязки вже трохи вийшли за рамки написання коду інженером

Абсолютно погоджуюсь. Як на мене автор вимагає від розробників бути ще одночасно проджект менеджерами-бізнес аналітиками-маркетологами-UX спеціалістом

так і я погоджуюсь :) Це дійсно не звичайні обовʼязки розробника, і саме тому ми створили нову вакансію з новою назвою, в яку такі обовʼязки включили. Бо очевидно, що від звичайної вакансії розробника такого не очікують. Про це і топік.

ЗП — ринкова (не сказав би що прям значно вища за ринкову, але точно не нижча). Акціями ділимося, так.

За посередню винагороду і акції (які ще не факт що вистрелять) навіщо я маю обирати саме вашу компанію, а не на сусідній галері мувати тасочки, які для мене заповнив бізнес аналітик за ті самі гроші? І ще можу міняти проект\технології хоч кожних півроку (добре, в старі хороші часи міг)

Є люди яким саме це і цікаво — мати вплив на продукт саме з точки зору фічей та самого продукту, а не внутряка. І це нормально що це для всіх. До того ж деякі розробники вважають ринкову ставку + акції не посередньою винагородою.

Є люди яким саме це і цікаво

Зазвичай це джуніори, а так ви по суті хочете найняти людей з бізнес майдсетом, в яких сюрприз ще не має бізнес майндсету. Так робота в наймі це такий самий бізнес як власна справа. Тобто коли людина думає про бізнес — вона думає про прибутки та вкладення на сам перед, тобто про персональний ROI, так чому це вона має думати зокрема не про власні прибутки ? Працювати над продуктом, при чому над чужим це що велика честь ? Особливо коли в долю в бізнесі тебе не беруть. А за великим рахунком «таскати тасточки» це абсолютно точно така сама робота як і в стартапі, зовсім ніякої різниці нема. Просто це замовник з закордону через посередника винайняв тут, лише з тієї причини — що так дешевше виходе.

Мова ж іде про стартап на ранніх етапах. Людей мало, «всі роблять усе». Комусь це справді цікаво, комусь ні, а назви посад формально однакові. От автор і знайшов для себе спосіб чітко фільтрувати тих, кому підходить саме робота в стартапі.

здається ці обовʼязки вже трохи вийшли за рамки написання коду інженером

Якщо людині в радість, то чому б і ні?(:

хм. якщо людині розжовувати ТЗ і роботу розжовувати ТЗ... то може нафіг тих людей? наймемо більше аналітиків )))

Проблема в тому, що зазвичай нема чого розжовувати — бо немає ТЗ.

але хіба повинен інженер працювати над UX, ініціювати A/B тестування, копатись в аналітиці і тд, щоб

Але коли знається на цьому принаймні з гори то добре. Власне як і бізнес аналіст, чи PM який знається на розробці і є спеціалістом з бізнес аналізу або керуванні це краще ніж люди без такого досвіду.

Підписатись на коментарі