Привіт друзі. Часто, особливо в аутсорсі, я бачу ту саму картину. Відсутність чіткого робочого процесу в командах різних проектах.
Найголовніше — це те, що програмісти не розуміють, як потрібно спілкуватися із замовником та один з одним. Як побудувати безперервний процес розробки якісного продукту Як спланувати свій робочий день та спринти.
І все це в результаті виливається в зірвані дедлайни, овертайми, постійні розбирання, хто винен, і незадоволеність замовників — куди і як усе рухається. Досить часто це призводить до зміни програмістів, а то й цілих команд. Втрата замовника, погіршення репутації і так далі.
Свого часу я якраз і потрапив на такий проект, де були всі ці принади.
Ніхто не хотів брати на себе відповідальність за проект (великий сервісний маркетплейс), плинність була страшна, замовник просто рвав і метал. СЕО якось підійшов до мене і сказав, що ти маєш потрібний досвід так тобі й карти в руки. Забирай собі проект. Облагоджуєшся, проект закриємо і всіх виженемо. Вийде, буде круто, тоді веди його і розвивай, як вважаєш за потрібне. У результаті я став тимлідом на проекті і все лягло на мої плечі.
Перше, що я зробив, — це розробив робочий процес з нуля, який відповідав на той момент моєму баченню, і написав посадову інструкцію для команди. Впроваджувати його було непросто. Але десь на протязі місяця все устаканилося, розробники та клієнт звикли, і все пішло вже тихо та комфортно. Для того щоб показати команді, що це не просто буря в склянці, а реальний вихід із ситуації, я взяв на себе максимальний обсяг обов'язків, знявши неприємну рутину з команди.
Вже минуло півтора роки, і проект розвивається без овертаймів, без «щурів» і всіляких стресів. Хтось у старій команді не захотів так працювати та пішов, комусь навпаки дуже зайшло, що з'явилися прозорі правила. Але за підсумками всі хто в команді, ті дуже вмотивовані і знають величезний проект повністю, причому і фронтенд і бекенд. Включно з кодовою базою і всією бізнес-логікою. Дійшло вже навіть до того, що ми не просто «гребці», а самі вигадуємо багато бізнес-процесів і нові фічі, які бізнесу виявилися до вподоби.
Завдяки такому підходу з нашого боку замовник вирішив замовити в нашій компанії ще один маркетплейс, що не може не тішити.
Оскільки на моєму проекті це працює, то, можливо, комусь це також зможе допомогти. Отже, сам процес, який допоміг нам урятувати проект:
Процес роботи команди на проекті "Мій улюблений проект"
a) Всередині командний процес (між розробниками)
- Усі завдання створюються в системі Jira
- Кожне завдання має бути максимально описане, і виконувати строго одну дію
- Будь-яка фіча, якщо вона досить складна, розбивається багато дрібних тасок
- Команда працює над фічами, як єдиною тягою. Спочатку робимо разом одну фічу, віддаємо її на тестування, потім беремо наступну.
- Кожне завдання маркується, для бекенда чи фронтенда воно
- Є типи тасок та багів. Потрібно правильно їх вказувати.
- Після виконання завдання вона перетворюється на статус ревью коду (при цьому створюється пулл реквест на свого колегу)
- Той, хто виконував завдання, відразу ж трекає свій час для цього завдання.
- Після перевірки коду, ПР апрується і після цього, той, хто виконував це завдання, самостійно мержить її в майстер гілку, після чого змінює її статус у готова для деплою на дев сервер.
- Усі завдання, готові до деплою на дев сервер, деплояться тимлідом (його зона відповідальності), іноді членом команди, якщо щось термінове. Після деплою всі таски готові до деплою на дів переводяться в статус — готові до тестування на діві.
- Усі завдання тестує замовник
- Коли замовник протестував завдання на діві, він переводить її у статус готова для деплою на прод
- Для деплою на прод ми маємо окрему гілку, куди мержим майстер тільки перед деплоєм
- Якщо під час тестування замовник знаходить баги, він повертає завдання доопрацювання, встановлюючи їй статус повернуто на доопрацювання. Таким чином ми відокремлюємо нові завдання від тих, що не пройшли тестування.
- У результаті всі завдання проходять шлях від створення до завершення: To Do → In Development → Code Review → Ready deploy to dev → QA on dev → (Return to dev) → Ready deploy to prod → QA on prod → Done
- Кожен розробник тестує свій код самостійно, у тому числі як користувач сайту. Не допускається злиття гілки з основної, якщо точно не відомо, що код працює.
- Кожне завдання має пріоритети. Пріоритети розставляє або замовник, або тимлід.
- Розробники насамперед виконують пріоритетні завдання.
- Розробники можуть призначати завдання один на одного, якщо були знайдені різні баги в системі або одне завдання складається з кількох фахівців.
- Усі завдання, які створює замовник, потрапляють до тимлід, який їх оцінює, і або просить замовника доопрацювати або призначає на одного з членів команди.
- Всі завдання, які готові до деплою на дів чи прод, потрапляють також до тимлід, який самостійно визначає, коли і як проводити деплой. Після кожного деплою тимлід (або член команди) повинен повідомити замовника про це. А також змінити статуси для завдань, готових до тестування на дев/прод.
- Щодня в той самий час (у нас це о 12.00) ми проводимо мітинг між усіма членами команди
- Кожен на мітингу звітує, включно з тимлідом, що він зробив учора, що планує робити сьогодні. Що не виходить і чому. Таким чином, вся команда в курсі того, хто чим займається і на якому етапі знаходиться проект. Це дає нам можливість спрогнозувати та відкоригувати, якщо потрібно, наші естімети та дедлайни.
- На мітингу тимлід також озвучує про всі зміни в проекті та рівень поточних багів, які були знайдені не замовником. Усі баги розбираються і призначаються кожного члена команди їхнього решения.
- На мітингу тимлід призначає на кожного завдання, враховуючи поточну завантаженість розробників, рівень їхньої професійної підготовки, а також з урахуванням близькості того чи іншого завдання до того, чим розробник займається в даний момент.
- На мітингу тимлід виробляє спільну стратегію з архітектури та бізнес-логіки. Після чого вся команда це обговорює та приймає рішення про внесення корективів чи ухвалення даної стратегії.
- Кожен розробник пише код і будує алгоритми самостійно в рамках єдиної архітектури та бізнес-логіки. Кожен може висловити своє бачення реалізації, але насильно ніхто не змушує робити тільки так, а не інакше. Кожне рішення аргументується. Якщо є найкраще рішення, але зараз на нього немає часу, то створюється тяга в жирі, на майбутній рефакторинг певної частини коду.
- Коли розробник взяв у роботу завдання, він переводить її у статус розробки. Вся комунікація щодо уточнення завдання у замовника лягає на плечі розробника. Питання технічного плану можна ставити тимлід або колегам.
- Якщо розробнику не зрозуміла суть завдання, а замовник не зміг розумно її роз'яснити, то він починає наступне завдання. А поточну забирає тимлід і сам обговорює її із замовником.
- Щодня розробник повинен у чаті клієнта писати про те, над якими завданнями він працював учора і над якими завданнями працюватиме сьогодні
- Робочий процес відбувається по скраму. Все розбите на спринти. Кожен спринт триває два тижні.
- Спринти створює, наповнює та закриває тимлід.
- Якщо проект має суворі дедлайни, то намагаємося приблизно заестімейтіть всі таски. І збираємо із них спринт. Якщо замовник намагається до спринта додати ще завдання, ми тоді виставляємо пріоритети, і якісь інші завдання переносимо на наступний спринт.
б) Процес роботи із замовником
- Кожен розробник може і повинен спілкуватися із замовником
- Не можна замовнику дозволяти нав'язувати свої правила гри. Потрібно у ввічливій та доброзичливій манері дати зрозуміти замовнику, що ми спеціалісти у своїй справі, і тільки ми повинні вибудовувати процеси роботи та залучати до них замовника
- Необхідно в ідеалі, перш ніж приступати до реалізації будь-якого функціоналу, створити блок-схему всього логічного процесу для фічі (воркфлоу). І надіслати її на підтвердження замовнику. Це стосується лише складного та не очевидного функціоналу, наприклад, платіжна система, система повідомлень тощо. Це дозволить більш точно зрозуміти, що потрібно замовнику, зберегти документацію до фічі, і навіть застрахувати себе від цього, що замовник може у майбутньому сказати, що ми зробили те, що він просив.
- Усі діаграми/блок-схеми/логіку тощо. ми зберігаємо у Конфлюенсі/Жирі, де просимо замовника у коментарях підтвердити правильність майбутньої реалізації.
- Ми намагаємося не вантажити замовника технічними подробицями. Якщо нам потрібне розуміння того, як замовник хоче, то малюємо примітивні алгоритми у вигляді блок-схеми, які замовник може зрозуміти і сам все виправити/допрацювати.
- Якщо замовник знаходить баг у проекті, ми просимо дуже докладно розписати його у Жирі. За яких обставин він стався, коли яку послідовність дій здійснював замовник при тестуванні. Просимо прикріплювати скріншоти.
- Ми намагаємося щодня, максимум через день робити деплою на дев сервер. Замовник тоді починає тестувати функціонал та проект не простоює. При цьому це маркер для замовника, що проект знаходиться в повній розробці і ніхто не розповідає йому казки.
- Дуже часто буває так, що замовник не до кінця розуміє, що йому взагалі потрібне. Так як створює новий для себе бізнес із ще не налагодженими процесами. Тому дуже часто буває ситуація, коли ми викидаємо в смітник цілі шматки коду і перекроюємо логіку програми. З цього випливає, що не варто все покривати тестами. Є сенс покривати тестами лише критично важливий функціонал і з застереженнями.
- Бувають ситуації, коли команда розуміє, що ми не вписуємось у дедлайни. Тоді ми проводимо швидкий аудит із завдань, і одразу повідомляємо про це замовника. Як вихід із ситуації ми пропонуємо запускати в термін важливий і критичний функціонал, а решту залишити на постріліз.
- Якщо замовник починає вигадувати різні завдання з голови, починає фантазувати та пояснювати на пальцях, то ми просимо його надати нам макет сторінки та флоу з логікою, яка має повністю описати поведінку всього макета та його елементів.
- Перед тим, як взяти в роботу будь-яке завдання, ми повинні переконатися, що ця фіча входила до умов нашого договору/контракту. Якщо це нова фіча, яка виходить за межі наших початкових домовленостей, то ми обов'язково маємо заестімейтити цю фічу ((приблизний час виконання + 30%) х 2) і вказати замовнику, що у нас піде стільки часу на неї, плюс дедлайн зміщується на час естімейту помножений на два. Зробимо завдання швидшим — чудово, все від цього тільки виграють. Якщо ні, то ми підстрахувалися.
в) Що ми не приймаємо у команді:
- Необов'язковість, незібраність, забудькуватість
- „Годування сніданками“. Якщо не можеш виконати завдання, не знаєш як, то про це потрібно відразу повідомляти тимліда, а не чекати до останнього.
- Бровади та похвальби від людини, яка ще не довів справою свої можливості та професіоналізм. Якщо довів, то можна в рамках пристойності 🙂
- Обман у будь-яких його проявах. Якщо завдання не виконано, то не варто змінювати її статус на виконану та писати в чаті клієнта, що вона готова. Зламався комп'ютер, злетіла система, собака погриз ноутбук - все це неприпустимо. Якщо відбувається реальний форс-мажор, то тимлід відразу повинен бути повідомлений.
- Коли фахівець постійно в офлайні і до нього складно достукатися у робочий час.
- Токсичність у команді не допускається! Якщо хтось із чимось не згоден, то всі разом збираються на мітинг і це обговорюють та вирішують.
І ще низка питань/тез, які я іноді задаю своєму замовнику, щоб зняти всі непорозуміння:
- Які у вас критерії якості?
- Як ви визначаєте чи є у проекті проблеми чи ні?
- Порушуючи всі наші рекомендації та поради щодо зміни/покращення системи, всі ризики несете тільки ви
- Будь-які мажорні зміни проекту (наприклад, всілякі екста флоу) призводитимуть до можливої появи багів (які ми, звичайно, фіксуватимемо)
- Неможливо протягом кількох хвилин зрозуміти, що за проблема сталася на проекті, а тим більше відразу її пофіксувати
- Ми працюємо за конкретним продуктом флоу (Таски в Жира - Розробка - Тестування - Деплой). Отже ми не можемо реагувати на весь потік прохань і скарг у чаті.
- Програмісти є саме програмістами, а не професійними тестувальниками, і не можуть забезпечити належної якості тестування проекту
- Відповідальність за кінцеве тестування та прийом завдань на проді лежить повністю на вас
- Якщо ми вже взяли в роботу завдання, то не можемо відразу ж перемикатися на інші, поки не доробимо поточне (інакше це призводить до ще більших баг і збільшення часу розробки)
- Людей у команді стало менше (через відпустки чи хвороби), а роботи стало більше і ми фізично не встигнемо реагувати на все, що ви хочете
- Прохання з вашого боку зробити деплою на прод без протестованих завдань на діві — це лише ваші ризики, а не розробників
- Коли ви ставите нечіткі завдання, без коректного флоу, без макетів дизайну, це вимагає від нас набагато більших зусиль і термінів реалізації, тому що нам замість вас доводиться робити додатковий обсяг роботи
- Будь-які таски по багах, без детального опису їх виникнення та скріншотів, не дають нам можливості зрозуміти, що пішло не так, і як нам семітувати цей баг.
- Проект вимагає постійного доопрацювання та покращень для підвищення продуктивності та безпеки. Тому команда витрачає частину свого часу на ці покращення.
- Через те, що у нас бувають переробки по годинниках (термінові фікси), ми повинні їх компенсувати в інші дні.
Як правило, замовник відразу розуміє, що не так просто в розробці софту, і одного бажання тут явно недостатньо.
Загалом, це все. За кадром залишаю безліч переговорів та початкове налагодження всіх процесів, але в результаті все налагодилося. Можу сказати, що цей процес став для нас якоюсь «Срібною кулею». Нові люди, які приходили в проект, могли вже відразу впрягатися в роботу з першого дня, тому що всі процеси описані, а документація та архітектура у вигляді діаграм одразу давала уявлення про те, чим ми тут займаємося.
PS Хочу уточнити, що на нашому боці менеджер менеджера немає. Він є за замовника. Зовсім не технар. Європейський проект. Вся комунікація тільки англійською.
Всім удачі на проектах. Не вигоряйте та постарайтеся покращувати свої процеси.
Вихідник у моєму .
Джерело: habr.com