Як зробити, щоб у розробників очі загорілися і стало цікавіше працювати

Перейти у продуктову компанію → працювати в кросфункціональних командах.

За 8+ років у розробці я встиг попрацювати в різних компаніях: стартапі, аутсорсі й останні чотири роки — в продуктовій компанії.

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

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

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

Причому обов’язкових з’явилося 1-2 додаткових мітинга, а всі решта (типу брейншторм) за бажанням. Ніхто не напрягає тебе — ти можеш ходити, можеш не ходити.

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

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

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

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

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

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

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

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

Бо розробники до чого звикли? Їм приходять задачі, вони між собою обговорили яка ця фігня. А зараз вони приходять на ці мітінги, їм цікаво — якісь нові процеси. Ти робиш технічні задачі, пишеш код, а потім приходиш і в креативне щось включаєшся.

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