Разом з Іваном Тригубом, співзасновником та СЕО компанії SPLIT Development, обговорили становлення його компанії та особливості проєктів, переваги Worksection порівняно з Jira, а також проблеми фікс-прайсу.
Розкажіть про вашу компанію
Компанія SPLIT Development заснована у 2019 році. Я – CEO агенції. Наша команда займається дизайном і електронною комерцією. Зараз це більше Shopify і Wordpress, але поступово виходимо ще й на Node.js. Клієнтів в Україні в нас майже немає, тому працюємо із західним ринком.
Скріншоти проєктів із сайту SPLIT Development
Спочатку ми почали працювали вдвох із співзасновником компанії, Дмитром Карповим, і зрозуміли, що на початку не хочемо наймати дорогих спеціалістів, оскільки на самому старті це трохи “вбиває” бізнес.
Взагалі я був фронтенд-розробником, тому ми навчали своїх знайомих, друзів фронтенду і так почали працювати з першими клієнтами. Я займався продажами, вів проєкти і допомагав хлопцям, перевіряючи їхній код.
Але ми досить швидко масштабувались, почали з’являтися проєкти, найняли проджект-менеджера. Такими кроками приблизно через рік-півтора ми дійшли до Shopify. І зараз команда Shopify-розробників виросла до 11 – 12 людей.
З якими системами ви працювали до Worksection?
Спочатку працювали з Trello, на безкоштовній версії, в якій доступно 12 проєктів. Але там досить урізаний функціонал, тому ми хотіли прийти до чогось більш стабільного. Потім ми працювали з Jira. Але Jira, оскільки команда почала масштабуватися, стала “кусатися” по ціні й також мала обмежений функціонал.
Наприклад, у нас всі працюють з трекером, а там трекера немає. Тож якось один знайомий (також власник агенції) порекомендував Worksection. Ми пішли на інтрокол, все послухали і нам сподобалося.
Дашборд проєкту в Worksection
Чому ви обрали Worksection?
Тому що у Worksection є дуже класні фічі. Наприклад, трекінг часу. Коли ми тільки почали працювати з системою, я став аналізувати, скільки часу на проєкти витрачає дизайн-відділ, Shopify-відділ, Node.js. І коли я це все конвертував в те, скільки ми маємо отримати, то цифри в мене було більші, ніж ми отримували по факту. Тому, скажімо так, з’явився аналіз.
Також дуже зручно, що у Worksection можна назначити одразу на цілу секцію відповідальну людину, яка відповідатиме не за конкретне завдання в цілому, а за певний етап.
Призначення відповідального за статус на Канбані
До прикладу: девелопери перенесли задачу з одного етапу на етап “Ready for QA”, але тестувальника назначити забули. Тестувальник потім не може затрекати туди час, тому що задача не на ньому. Але коли завдання переноситься між етапами і відповідальний змінюється автоматично – це класно.
І якщо порівняти наш роботу зараз з тим, як ми працювали з Jira, то я можу сказати, що Worksection більш зручний: зручний аналіз часу, репорти. Для нас – це найкраще, що є. Тому що ми цього не отримували, а це допомогло нам рости і зрозуміти, де ми втрачаємо в бізнесі.
Проблеми фікс-прайсу
Якийсь час ми працювали з фікс-прайсом, але з таким підходом виникає дуже багато складнощів. Наприклад, ми можемо взяти в роботу проєкт і розбити його на етапи. Ми завершуємо перший етап і починаємо роботу над другим. Потім клієнт надсилає правки до першого етапу і ми їх вносимо, дороблюючи другий етап. Але ми не можемо отримати платіж, поки не доведемо до ідеалу перший.
Зараз ми працюємо більше на погодинці. На початку роботи ми завжди надаємо клієнтові estimate, зазначаючи, що сума витрат може бути більшою або меншою. Тому що ми не можемо порахувати ідеально, скільки годин ми витратимо в підсумку.
Девелопери і дизайнери в нас працюють з трекером, менеджери час не трекають. Тому що час девелопера і тестувальника ти можеш порахувати, але час, наприклад, бухгалтера – вже ні.
Таймер у Worksection
Де команда веде комунікацію про проєктах?
Більше ми ведемо комунікацію в Slack. Але якщо є якісь питання щодо завдань, то ми краще напишемо це в коментарях у Worksection, щоб потім воно не загубилося в чаті в Slack.
Наприклад: щось змінилося в дизайні. Клієнт бачив дизайн, йому все сподобалося, але він подивився на сайті і вирішив, що якась кнопка повинна бути іншого кольору. Такі моменти, де клієнт вносить зміни, фіксуються у Worksection, тобто в коментарях або в описі завдання щоб тестувальник міг бачити це при перевірці і розуміти, чому на сайті відрізняється від макету.
Коли командам варто впроваджувати таку систему як Worksection?
Система управління має бути з самого початку. Вона і в нас була з самого початку, просто ми не знали про Worksection.
Деякі команди просто користуються, наприклад, Trello. Але коли команда зростає, ти шукаєш якісь інші рішення. Worksection для нас – це “ціна-якість”, тобто незавищена ціна, як у Jira, і навіть більше функціоналу саме для нас.
Повне відео-інтерв’ю з Іваном дивіться на нашому YouTube-каналі.