2024-06-13 10:26:02
Про продуктовий майндсет та $5000 за рекомендацію JAVA-Lead DeveloperМій партнер та засновник фінтех-екосистеми Saldo Apps (частина Netpeak Group) Радомир Новкович нещодавно написав на DOU колонку про продуктовий майндсет розробника, раджу почитати. 60+ коментарів у треді доводять, що тема актуальна.
Якщо коротко, то в Saldo Apps 1,5 року змінювали бекенд-розробників, і Радомир не міг зрозуміти, в чому проблема, – він же до того побудував вже не один продуктовий бізнес, а тепер як на ручник встали. Уявіть: бекенд-розробники просили чіткі ТЗ.
Радомир почав копати та зрозумів, що йому потрібні розробники з особливим майндсетом – продуктоорієнтовані розробники, або англійською Product-Minded Software Engineer.
Які якості об’єднують цих людей? Мені прям хочеться це розписати, увічнити це, тому що я повністю згоден з Радом щодо важливості продакт майндсету у розробників.
Отже, що відрізняє розробника з продуктовим майндсетом від звичайного:1. Чітке розуміння цілей того, що робить розробникТобто спеціаліст відповідає на питання: чому я це роблю? Як моє завдання вплине на користувача/систему/тощо? Він має відповіді на ці питання до початку роботи над завданням.
2. Верифікація результатів роботиРозробник переконується, що все працює так, як він це розуміє, перш ніж передавати результати на тестування або реліз. Верифікація і тестування – це різні речі. Тестування на різних пристроях, регресія – це відповідальність QA. Запуск успішних сценаріїв з реальними даними й перевірка того, чи працює все, що ми зробили, – це верифікація, і за неї відповідає розробник.
3. Проактивність під час роботиЯкщо у розробника є ідеї/думки/занепокоєння щодо поточної реалізації, він ділиться ними з командою. Якщо спеціаліст передбачає потенційний вплив поточного процесу/реалізації на інші компоненти, він проактивно повідомляє про це для покращення або ставить питання до розгляду.
4. Активна участь після релізуРозробнику має бути не байдуже життя його продукту – збої, відгуки користувачів тощо. Незалежно від ролі, він аналізує, як може покращити ситуацію.
5. Системний підхід та постійне вдосконалення процесівБудь-яка проблема або помилка повинна призводити до появи двох завдань:
5.1. Виправлення помилок.
5.2. Аналізу та впровадження механізмів для запобігання або зменшення ймовірності виникнення подібних проблем/помилок у майбутньому. Пропозиції щодо покращення процесів – це обов'язок кожного, незалежно від ролі в компанії.
6. Чесність і прозорістьЯкщо є особисті проблеми / проблеми в команді, спеціаліст повідомляє про них. Якщо він не розуміє завдання/процес/документацію тощо, каже про це. Якщо відстає від графіка, повідомляє про це, і так далі.
7. Бекапи та підстраховка колегМи всі професіонали й перевіряємо свою роботу. Але ми також люди, а отже робимо помилки. Тому, коли розробник береться за чиєсь завдання, він вірить, що воно буде виконано правильно, але не на 100%, а на 90%, тобто припускає, що людина могла помилитися, і має перевіряти та підстраховувати колег (подібно до того, як підстраховують один одного в спортзалі).
8. Чиста архітектура та непримиримість з роботою «на трієчку»В архітектурі та коді не повинно бути чорних скриньок. Архітектура та код повинні бути прозорими та зрозумілими для будь-кого. Незграбні, неефективні рішення в архітектурі чи коді є неприйнятними. Будь-які подібні рішення повинні мати суттєве обґрунтування та бути схваленими на найвищому рівні. «Я зробив помилку, бо хтось мене підштовхнув», – це не виправдання.
Чому я про це пишу?По-перше, я повністю підтримую цю точку зору. Сам довго до цього йшов, але Радомир зміг краще це сформулювати.
По-друге, якщо ви прочитали опис вище та просто зараз візуалізували когось, хто ідеально підходить під всі пункти, та ще й має великий досвід у JAVA розробці, пишіть в телегу рекрутерці Катерині.
За успішну рекомендацію JAVA-Lead Developer (якщо людина пройде випробувальний термін), команда Saldo Apps заплатить вам $5000.III > I
@artemborodatiuk
Facebook | Instagram | YouTube | Linkedin | Threads | Twitter
Мої інші канали: | |
5.2K views07:26