Статті
Як я впорядкував робочі процеси в команді
Без стресу й опору колег
27 березня, 2020
Анатолій Атаманов
UX/UI-дизайнер, Akademia Design House

Коли я прийшов у команду Akademia Design House 5 років тому, у нас не було організованих процесів. Завдання ставились через пошту, дедлайни були абстрактними, а пріоритезація — ситуативною. Якщо ви впізнаєте у цьому свою команду, мій досвід вам знадобиться. Я був звичайним UX/UI-дизайнером, а не менеджером, але мені вдалося все впорядкувати без стресу й опору колег.

Х’юстон, як жити далі?

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

Ускладнювалася ситуація ще й тим, що кожен дизайнер і розробник був підключений до декількох проєктів — від 3 до 6 на різних стадіях. Бардак був знатний. Не кожен зможе працювати в таких умовах, і, на жаль, ми дійсно втратили кількох дуже хороших фахівців.

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

Оскільки найбільше “не все одно” було мені, а залишати компанію я не хотів, то вирішив приміряти цю сорочку на себе.

Курс молодого бійця

Я відразу зрозумів, що ламати через коліно і нав’язувати людям свої ідеї – не найкращий вихід. Та й жодних особливих повноважень для цього у мене не було. Як UX-дизайнер знаю, як люди опираються змінам у своїх звичках. Отримати такий опір в команді на старті я хотів найменше, тому вибрав партизанську стратегію. Для початку став просто спілкуватися, цікавитися що і як, чим хто займається, які є проблеми, навчився співчутливо кивати головою. Це дуже важливий етап. По-перше, проявляючи емпатію і причетність до проблем колеги, ви заслуговуєте їхню довіру (тільки заради бога, нехай це буде щиро), по-друге, ви проводите власне маленьке дослідження. Якщо робочий процес – це продукт, то ваші колеги – його користувачі. Зібравши масив проблем, можна їх впорядкувати за впливом на ефективність роботи. У цьому вам, до речі, допоможе емоційність реакції ваших колег на них: чим більше матів, тим вищий коефіцієнт впливу.

У партизанських методах важливо якомога раніше знайти однодумців, можна навіть одного. Чим сильніший вплив і авторитет такої людини в команді, тим краще. Це має бути людина, готова разом з вами випробувати новий інструмент або процес. На таку роль ідеально підходить той, у кого більше за всіх підгорає від перепрацювань і наїздів менеджерів. Далі, після нетривалого самостійного вивчення інструменту, його можна пропонувати колезі для експерименту. Почати слід з невеликого прес-релізу: “Ой, я тут таку тулзу круту знайшов, Ваня з “XYZ” використовує, каже, бомба, не хочеш спробувати?”. Якщо ви перевірили удвох, що цей процес чи інструмент дійсно непогано працює, можна підключати інших. Але не всіх відразу, лише лояльних – небезпека бунту ще не минула. Після того, як ви зібрали свою невелику армію ренегатів, рішення можна проштовхувати вище. Після підключення до нього власника продукту або засновника компанії воно де-факто стає корпоративним стандартом. Тоді автоматично підключається аудиторія, яку найважче підписати на такі авантюри — бухгалтери. Тепер мету можна вважати досягнутою.

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

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

Довга подорож починається з маленьких кроків

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

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

З часом прийшло усвідомлення, що Скайп і Телеграм теж не підходять для проєктної комунікації. Важливі повідомлення губляться в стрічці, постійно відволікаєшся на листування щодо завдань, до яких ти не маєш стосунку. Альтернатив особливо не було, ми обрали на Slack. Відразу сподобалася можливість вести спілкування в межах контекстів — #design, #front-end, #commerce, #support і так далі. Перш ніж перевести на нього команду, я вивчив усі можливості і підключив найвіддаленіших співробітників, пообіцявши, що буду закріплювати в каналах важливу інформацію. Після нетривалого тестування почав підсаджувати на нього інших членів команди, одного за одним. Був період, коли ми одночасно вели спілкування у двох месенджерах, поки хлопці самі не вирішили зупинитися на одному інструменті, на той момент у Слеку були вже майже всі. Ще одну перемогу можна зарахувати у свою скарбничку.

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

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

Окрема кіллерфіча Слека — інтеграції з різними сервісами. Ми налаштували відправку повідомлень в окремий канал при будь-яких змінах у зовнішніх сервісах. Це допомогло трекати рух проєктом в одному місці.

Канбанізуй це

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

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

Для початку я зібрав скелет логічно правильного воркфлоу. Так з’явилися колонки Ideas, Backlog, In Progress, On Review, Complete і Canceled. Пізніше між Backlog і In Progress додалася ще одна колонка — Sprint (разом, власне, із самими спринтами, але про це нижче). В Ideas кожен може зафіксувати свої потоки думок щодо змін у проєкті. Це не обов’язково стає завданням, але обов’язково заслуговує на увагу команди. Так кожен учасник може внести конструктивну ідею, яка згодом впроваджується в продукт. До речі, багато таких ідей ми отримали від нашого тестувальника.

У Backlog я заніс всі завдання, які скупчилися з саммарі наших обговорень, і просто розшарив з усіма. На цьому етапі я навіть не просив вносити зміни у дошку і робив це сам. І, о диво, згодом ця дошка стала єдиним джерелом правди для всіх. Так, без нав’язування, а через демонстрацію цінності мені вдалося пересадити команду на трекінг завдань у Trello.

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

У колонку In Progress виконавець переносить завдання самостійно. Це дуже важливий пойнт – так людина сама обирає, над чим працює, дає підсвідому обіцянку “Ок, я зроблю це спочатку”. Нам подобається, коли нам кажуть, що робити, але з більшою охотою приступаємо до задачі, якщо обрали її самі, навіть якщо фактично пріоритет спущений зверху. Завдання хорошого менеджера якраз у тому, щоб пояснити, чому саме цю задачу тобі слід перенести в In Progress зараз.

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

Якщо на якомусь етапі задача втратила свою актуальність, вона не видаляється, а переноситься в колонку Canceled. Це необхідно, щоб бачити, які завдання вже були в роботі.

Колонка Complete згодом перетворюється в безмежне простирадло задач. Ми придумали після чергового релізу переносити всю колонку цілком на окрему дошку Release archive і підписувати номером релізу. Так рикошетом вбили ще одного зайця: ми показуємо, який функціонал потрапив у реліз, що дає можливість складати changelog або навіть використовувати її як інфопривід для прес-релізів.

Звучить дивно, але раніше у нас не було навіть спринтів. Більшість змін відбувалися 4 роки тому, тоді не так багато компаній могли похвалитися хорошими процесами. Отже, ми домовилися проводити спринти завдовжки в один тиждень. Понеділок і п’ятницю відразу виключили зі списку потенційних днів старту і завершення спринтів. У понеділок всі тільки налаштовуються на роботу, у п’ятницю, навпаки, настрій швидше втекти на вихідні. Ідеально підходить вівторок – всі достатньо мобілізовані на роботу і не дуже втомлені. Так ми жорстко закріпили час у графіку, на який ніхто нічого не планує: об 11:00 у вівторок у нас дзвінок щодо початку спринту.

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

Оце так Zoom!

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

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

На мітингах намагаються бути присутніми майже всі, хто на цей момент працює над проєктом. Щоб не забирати дорогоцінний час колег, не пов’язаних з розробкою, ми домовилися будувати обговорення за принципом від загальних питань до конкретних. Загальні питання – це стратегія, бізнес-цілі проєкту, новини і комерційні успіхи. Конкретні – спосіб їх досягнення. Дзвінки виходять дуже продуктивними: з одного боку, не обтяжують зайвою інформацією тих, кому вона не потрібна, з іншого – вся команда в курсі цілей і динаміки проєкту. Спочатку, як правило, виступають бізнес-менеджери, потім вони відключаються, а ми продовжуємо обговорювати технічні питання. Весь дзвінок займає годину-півтори.

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

Висновки

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

Оптимізація робочих процесів – це довгий шлях, над яким ми працюємо досі. Як вчить нас філософія Кайдзен, не варто намагатися відразу стати кращими удвічі, досить щодня зростати на 1%, тоді за рік ти станеш кращим утричі. Так, наприклад, зараз ми тестуємо перехід з Trello у Notion, які має такі ж канбан-дошки, але об’єднує в собі такі можливості, як корпоративна Вікі, кастомні властивості задач, сніпети і так далі. Також відділ дизайну зробив вольове рішення і пересів зі Скетча на Фігму. Це відразу позбавило від необхідності в декількох додаткових інструментах, наприклад, inVision, Zeplin та Abstract.

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

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

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

Навіть не маючи повноважень можна вносити зміни в робочі процеси без стресу й опору з боку колег.

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

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

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

avatar
Анатолій Атаманов
UX/UI-дизайнер, Akademia Design House
Колонка

У нас є ще дещо для вас