Всім привіт! Так, ще раз трошки про мене. Понад 10 років у веб-розробці. З них 6 років у компанії Work.ua на позиції Software Engineer Team Lead. Work.ua, може, хтось не в курсі, сайт пошуку роботи №1 в Україні. Компанія вже 17 років на ринку, і ми успішно використовуємо методологію ShapeUp понад 3 роки. Що таке цей ShapeUp? Це методологія розробки проєктів, яка була сформована у компанії Basecamp під час роботи над їхнім одноіменним продуктом – системою управління проєктами Basecamp.

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

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

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

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

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

До речі, тут трошки історії. На той час ми використовували Jira. А до цього ми використовували Basecamp, але другої версії. Так от, ключова людина у компанії Basecamp, Райан Сінгер, він написав книгу про те, як вони розробляють у себе проєкти. І саме ця книга була про методологію ShapeUp. До речі, разом з книгою вийшла третя версія Basecamp, яка є прямо на нить під цю методологію. Як бачимо, прямо у назві книги написано рішення нашої проблеми, яка була на малюнку на тому, де ми ходили по колу. Просто перестаньте ходити по колу і робіть тільки те, що потрібно.

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

Коротше кажучи, поспілкувались і вирішили – треба. Після цього ми перенесли проєкти з джерелами. І Google Docs, все, що там накопичено, у Basecamp 3. І потім туди зареєстрували людей. І після цього просто почали працювати за методологією. І вже за два місяці ми зрозуміли, що це у нас працює. І працює круто, і це життєздатна історія. З цим можна працювати. А тепер почнемо трошки поглиблюватись в методологію і термінологію. Так. Спочатку ви бачите якісь незрозумілі точки. Терміни. Я коротко зараз про них скажу. А далі, звісно ж, розшифрую кожний з них.

ShapeUp – це про shape, формувати проєкт. Вважайте створити технічне завдання. Fat Marker – це загальний нарис або кордони проєкту. Appetite – це ціна або ресурси, які ми готові витратити на цей проєкт. Scopes – це цілісні частини проєкту. Scope Hammering – це збивання шматки. Відсікання чогось від шматків,. Six Weeks Cycle – шеститижневі цикли. Вважайте те щось схоже на спринт. Поки що так. І Кулдаун – ми його так і називаємо Кулдаун. Це перерва між проєктами.

Зараз я покажу ShapeUp Flow, який в оригіналі, який у нас. Я їх отак от зобразив, щоб була видна відмінність. Як бачите, майже те ж саме, окрім булочки, яка називається Bed. Ми це не використовуємо. І я обов'язково розкажу, чому ми не використовуємо Bed і що це таке. Але це буде трошки в кінці. Почнемо. І так, вся ця магія починається з процесу, який називається Shape. Що це таке Shape? У нас збираються керівники відділів, топ-менеджери, стейкхолдери. Також це можуть бути якісь залучені спеціалісти вузконаправлені. Вони придумують. Ідеї та обговорюють тезе на високому рівні абстракції. До речі, це дуже важливий момент. Є проблема і є абстрактне рішення. Ніяких деталей. Потім вибирають Appetite, який дозволено витратити на проєкт. Appetite – це ціна фічі або ресурси, скільки ми готові витратити на цей проєкт. Формують Fat Marker. Fat Marker – це загальний нарис або кордони проєкту. І ми знаємо, що точно робимо, а що точно не робимо. Також обов'язково позбавляється пасток.

Через які можна вийти за рамки Appetite. Це пастки маються на увазі якісь частини проєкту, які неможливо накреслити настільки, щоб потім під час проєкту не повернутися аж до формування. І з урахування всього сказаного створюється формувальний документ. Вважайте технічне завдання. І після цього під цей формувальний документ збирається команда виконавців проєкту. Хто це може бути? Наприклад, я, Team Lead, два бекенд-розробники, фронтенд-розробник, дизайнер, PM. Також це може бути, наприклад, дата-аналітик або хтось з мобільної розробки, але це виключно залежить від специфіки певного проєкту.

Також про ці Appetite розкажу. Так, мабуть, з чим їх їдять. Ми наші Appetite, тобто ціна проєкта і ресурси, які готує витратити, ми розбили на такі прості і зрозумілі величини. L, M і S, як розміри одягу. L – це 4 тижні білд і 2 тижні кулдаун. L – для великого проєкту, а M – для середнього, 2 тижні розробка і 1 тиждень кулдаун. І S – це для якогось не величкого проєкту. 1 тиждень білд і 2-3 робочі дні кулдаун. Також зауважу, що цикл 6 тижнів. Тобто можна за ці 6 тижнів зробити 1 проєкт з Appetite L, якийсь великий проєкт. 2 проєкти M або 4 S. Або, наприклад, 1 проєкт M і 2 проєкти S. Відчуваєте, як цеглинки проєкти зі сточно зрозумілим терміном вкладаються в цей 6-ти тижневий цикл.

Також на практиці у нас кулдаун враховується вAppetite. І так, що у нас є? У нас є формувальний документ, в якому описан проєкт, її абстрактне рішення, обраний Appetite, сформована команда. І тепер приступаємо до білду, розробки проєкту. Вона починається з презентації формувального документа команді, яка зібрана під проєкт. Команді формувальники розказують, от такий от проєкт, от така проблема, треба дещо зробити. Також команда задає якісь питання, формувальники на щось відповідають. Щось таке. Також у нас команда може скоригувати Appetite. Тобто, наприклад, команда ознайомилась з формувальним документом і бачить, що не вкладеться вона. Оцінила роботи і вже видно, що буде більше робіт, ніж заплановано. У нас команди можуть скоригувати Appetite. Зазвичай в більшу сторону. Але все ж таки, дуже часто буває, що на етапі формування все ж таки Appetite обрано правильно. Але у нас така опція. Також дуже важливий момент. Команда не відволікається на інші проєкти. Навіть на попередні, які були зроблені в минулих циклах. Тобто, команда повністю сфокусована і в потоці всі члени команди роблять певний проєкт. Вирішують одну загальну проблему. Зазвичай в реальності можуть бути відволікання по якимось сусіднім проєктам. Це можуть бути якісь баги і так далі. Але команда не відволікається, нічого не фіксує. Вона може відповісти. В форматі питання-відповідь. Але якісь речі по минулим проєктам вона не робить. У нас, наприклад, для цього є чергова команда. Або команда пожежників, яка робить щось термінове з інших минулих проєктів.

Також трошки розкрию про шеститижневий цикл. За шеститижневий цикл розробки можна зробити, наприклад, один проєкт з Appetite L, або декілька проєктів з Appetite М. Я на картинках розшифрував деталі. Що це означає? Що там взагалі коїться у цей час? Вперше, чотири тижні на прикладі великого проєкту з апетитом L. Це обговорення, дизайн, розробка, тестування і реліз фінального проєкту на продакшн. Тобто якийсь кінець проєкту згідно формувального документу. І після цього два тижні кулдаун. І справа, приклад двох проєктів з Appetite L за ці шість тижнів. Як бачите, те ж саме, але по два рази. Також цікавого. Наш цикл проходить з вівторка по вівторок. Не включно. Шість тижнів. Тобто вівторок і через шість тижнів вівторок. Починається там вже новий цикл.

Це зроблено для того, щоб не завершувати всі справи в п'ятницю, а зробити це в понеділок, вже спокійно і без всякого поспіху . До речі, нам це дуже допомагає. Проєкт коли починається? Команда б'є всі свої роботи на scopes. Шматки. Кожен scope це незалежна частина робіт, яку можна тестувати, показувати замовнику і в ідеалі навіть реалізити. Також всі члени команди намагаються працювати над шматками одночасно, а не послідовно. Тобто головна мета ці незалежні шматки якнайшвидше кожен з них зробити повністю. І дизайн, і верстка, і розробка. Зробити і його протестувати, показати формувальникам, умовно замовнику.

Щоб, наприклад, побачивши перший, фінально готовий шматок, можна було якось далі відкорегувати роботи або інші шматки і так далі. Тому що це про гнучкість. Як ми пам'ятаємо, формувальний документ без деталей, він абстрактний. Тому що деталі гнучко формуються вже під час роботи. На повністю виконаних шматочках проєкту. Також можна відсікти scope hammering, який шматок. Без чого буде теж повноцінний реліз. Приклад. Команда розбила проєкт на 5 шматків. Чотири шматки були зроблені, протестовані, показані замовнику, формувальнику. Все круто, все супер. Але от п'ятий шматок, він от не вкладається. Не вкладається. Якщо його доробити, то не вкладаємося в Appetite. Тобто в ціну на проєкт. І можна прийняти рішення п'ятий шматок, або відсікти. Тобто не робити його взагалі і зарелізити проєкт без цього шматка. Або зробити якусь його частину. Якщо це буде, звісно, повноцінний реліз, який вирішує проблему в формувальному документі. Це все тому, що головне не випасти з Appetite. Це найголовніша... Парадигма всієї методології. Це про ту саме очікуваність. Ми точно знаємо, що оцей проєкт, він буде зарелізний в ці рамки. І наступний почнеться вчасно.

І так, що у нас є на зараз? Згадаймо. Команда отримала формувальний документ. Вони задали питання різні. Розбили на scopes шматки. Кожен шматочок вся команда потужно в потоці поступово робила. І кожен шматочок показувала. І так. Все в кінці сподобалось формувальникам або замовнику. Всі шматочки ці були зарелізані. На прикладі проєкту L за перші 4 тижні, коли треба, в кінці 4 тижня зарелізити. Проєкт готовий. І тут починається наша найулюбленіша річ, а саме кулдаун.

Що таке кулдаун? Кулдаун – це можливість відпочити перед початком наступного проєкту. Але це, звісно, про користи відпочинок. От я розкажу, що корисного ми робимо. Також хочу зауважити, що команда повинна зареалізувати проєкт до кулдауну. Щоб відбувся кулдаун правильно, пропорційно до потужно виконаних робіт по проєкту. Також вся команда зацікавлена, щоб кулдаун був. Тобто зазвичай ніхто нікого не тягне вниз. Команда зацікавлена, щоб кулдаун відбувся повноцінний у всіх. І так. Що ж корисного? От ми робимо оцей кулдаун. Тому що ми ж не просто там сидимо і їмо офісне печиво з класичною кавою якоюсь. Ми фіксимо баги з реалізного проєкту. Якщо зареалізували, якісь баги були, щось підчистити треба – кулдаун. Також це можуть бути nice-to-have задачі. Nice-to-have задачі – це прості і зрозумілі покращення. До речі, вони могли бути такі задачі створені навіть під час формування, або під час роботи над проєктом, або вже після релізу. І дуже цікава і важлива річ згідно методології – те, що ці задачки, вони не обов'язкові і ні. Nice-to-have. Тобто, якщо вони будуть зроблені під час кулдауну – окей. Якщо вони не будуть зроблені – взагалі нічого страшного. Також у кулдауні можуть бути ретроспективи, можуть бути написання технічної документації, можуть бути різні цікаві і корисні дослідження, для яких інколи немає часу. Також може бути технічний борг. Ось такі корисні речі ми робимо на кулдауні. Також, що ми не використовуємо в SHIPUP? Як я обіцяв, розкажу про BED.

BED – це необхідність проголосувати за проєкти, які сформовані під час усіх попередніх циклів, і тільки після голосування передати їх в розробку. Голосують формувальники, тобто ті люди, які відповідають за процес SHIP. Якщо проєктів сформовано багато, а в роботу треба менше, то проєкт відкладається на обговорення і голосування аж на наступний SHIPUP, наступний процес SHIP. Натомість у нас відразу формуються проєкти, які треба робити в наступний білд. Тобто є якась стратегія, є певна кількість проєктів, ну нема зайвих. Їх треба сформувати, описати формувальний документ, як я раніше вже казав, і передати їх в роботу. Є ті термінові або трендові проєкти, які треба терміново швидко сформувати і брати, і робити. Без всяких голосувань. Також зазвичай проєкти погоджуються без формальних голосувань. Люди сідають, просто є проєкт, вони спілкуються, кожен свою думку каже, вони з чимось погоджуються в результаті, і цей формувальний документ іде далі на виробку.

Це все щодо нашого ShapeUp Flow. Давайте згадаємо це, що було. Була ідея. Формувальники сіли, обговорили, обрали Appetite, в який треба все це зробити. Сформували формувальний документ, абстрактний. Сформували команду, яка буде робити цей проєкт. Після цього команді презентували цей проєкт. Команда подивилася, задала якісь питання. І після цього почала розбивати проєкт на шматки, scopes. Потім ці scopes, команда кожен scope, повноцінний об'єм робіт робила, тестувала, показувала замовнику, якщо потрібні якісь деталі щодо наступних шматків, погоджувала. Команда всі ці шматки зареалізувала. В перші чотири тижні. Наприклад, Appetite L. Все круто. І потім команда перейшла до кулдауна, де команда почистила якісь хвости. Команда розфокусувалась, трошки видихнула, поробила якісь прості задачі. І вже з гарним настроєм, без хвостів, без технічного порогу, команда готова до наступного проєкту, який таким самим чином під цей час вже сформувався.

Так, звісно ж це звучить круто. Але на початку, коли ми почали працювати по цій методології, були деякі складності. Я про них обов'язково вирішив розказати. Формувальникам було важко домовитись. На початку. Ну от, у кожного своя думка. Кожен бачить по своєму проєкти. Але формувальники... SHIP теж обмежений 6 тижнями. Тому що за 6 тижнів треба сформувати потрібну кількість проєктів, щоб передати їх наступним командам. Рішення банальне. Навчили їх домовлятись. Суто справа практики, виявилось. Також формувальники не встигали іноді сформувати достатньо проєктів для всіх команд. Так теж бувало. Це життя. В таких випадках, якщо є відчуття, що не встигають, треба починати формувати заздалегідь. Іноді ось так. Також бувало, що розробка виходила за рамки 6-тижного циклу. Зміщалася трошки цикл. Довше 6-ти тижнів робились проєкти в циклі. Так було на початку. Але ми не злякались цього. І з досвідом це зникло теж. Виявилася теж справа практики. Так все пессимістично. Також деяким членам команди, дизайнеру або верстальнику, наприклад, під кінець циклу було нічого робити. Теж така життєва історія. Дизайнер. В перші два тижні щось намалював, перевірив, все круто. Верстальник зверстував. І тиждень залишився, а там бекенд і мобільна розробка все робить.

А дизайнер, верстальник – ну, нічого не роблять. Все перевірено. Це життя, і вони роблять все ж таки якісь інші корисні задачі. Навіть з інших проєктів, які десь є. Також траплялося, що розробка "з'їдала" повноцінні кулдауни. В ідеалі, все мало б виконуватися в області кулдаунів. Але траплялося, що ми, ну, щось не передбачили. Якийсь факап, щось – ну, буває, життя. І команда "з'їдала" час кулдаунів. Бували навіть випадки, коли весь кулдаун з'їдався доробками. Але з досвідом ці речі зникли. Тобто це теж можна виправити. І в результаті стало краще. І тут я хочу розказати. Краще це у нас про що? Це про прогнозованість. Проєкти у нас завершуються вчасно. Завдяки Appetite і ключовій парадигмі. У паузах Appetite. Ми знаємо, що проєкти будуть виконані в певний термін. І після цього ми можемо спокійно планувати наступний проєкт з потрібним Appetite. І цей проєкт теж буде зроблений у цей термін. Це про сфокусованість. Немає перемикання між різними проєктами або контекстами. Бо це перемикання – це дуже бентежить.

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

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

Так, я залишив вам кілька корисних посилань. На Basecamp, систему управління проєктами – ви можете зайти і подивитись, що це таке. Щодо цін – як його підключити. Також залишив посилання на книгу ShapeUp. До речі, я дуже рекомендую вам прочитати цю книгу. По-перше, вона дуже просто описана, з ілюстраціями, дуже класно, як ми любимо. І ця книга невелика, небагато сторінок. Тому бачите, як. Треба взяти і почитати. Також залишив посилання на мій LinkedIn для зворотного зв'язку щодо цієї теми. Так, на цьому все. Дякую всім за увагу. Сподіваюся, вам було цікаво, і ви відкрили щось нове для себе. Переходимо до запитань.