Це працює трішки по іншому. Допустимо, що рейт у бека і фронта 40$ за год. На проект потрібно витратити 20 годин на фронт и 20 на бек, то фулл стек забере всі 1600$. До того ж, фулл стека будут розглядати в приоритетному порядку. І так — він буде отрімувати 2 сеньйорські зп

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

Зараз в тренді взяти чиїсь успішні ідеї і називати це потім новим проєктом. Ніхто не хоче створювати свій унікальний Всесвіт.

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

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

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

Дуже часто, бачучи що людина НЕ вивозить задачу (не може зробити її півтора тижні, а естимейт був 2-3 дні), починаю робити роботу за цю людину (код пишу, який треба написати, чи замість людини йду в логи дебажити проблему, з якою він не може тиждень розібратися). Це виглядає як «Знов ти, невдаха, не можеш зробити, — дивись, як треба»

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

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

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