Процес дизайну: більше метушні vs менше метушні
Якщо ви хочете створити щось видатне, потрібно не витрачати більше часу й ресурсів на розв’язання проблеми, а менше займатися дурницями
Я думав, що технічний прогрес допоможе нам працювати менше, краще й розумніше. Але вийшло навпаки: ми проводимо безліч нарад, збираємо величезні команди, витрачаємо більше часу й ресурсів. Зрештою багато роботи виконується марно.
Є спосіб спростити процес і зробити його ефективнішим. Нещодавно я прочитав книжку авторів із Basecamp «It doesn’t Have to Be Crazy at Work», у якій вони діляться практичними порадами з управління компанією, продуктом і командами. Я виокремив із неї чотири принципи, які допоможуть створити якісний продукт.
- Знайдіть час спокійно обміркувати ідею
Зазвичай, коли люди приходять із новими ідеями, вони призначають нараду, запрошують тих, хто ухвалює рішення, і презентують свої думки. Якщо ніхто не перебив працівника в перші дві хвилини й усі загорілися ідеєю, компанія починає над нею працювати.
Так буває не завжди. Зазвичай хтось швидко схоплюється з місця й каже, чому ідея ніколи не спрацює. Це неправильно.
Краще організувати процес інакше. Перед нарадою доповідач має записати ідею на папері — це допоможе впорядкувати думки. Потім він передає свої напрацювання команді, щоб усі з ними ознайомилися. Жодного зворотного зв’язку — нехай просто прочитають написане колегою. Так у людей з’явиться час і вони зможуть усе спокійно обміркувати.
На самій нараді ніхто не перебиває доповідача. Коли вона закінчується, люди висловлюються й дають зворотний зв’язок. Він має ґрунтуватися на сказаному й бути конструктивним, а не вбивати ідею. Після наради всі беруть кілька днів або тижнів на обмірковування — це допоможе не поспішаючи осмислити все почуте.
Чому б не заощадити час і не вирішити все на місці?
Коли ви збираєтеся разом і обговорюєте ідею, люди не мають змоги подумати самостійно. Такі зустрічі найчастіше закінчуються суперечками, у яких кожен тягне ковдру на себе й намагається відстояти власну думку. Тому найкращий варіант — приділити час і обміркувати все наодинці.
Те, про що я писав вище, дуже схоже на метод Braintrust.
Його використовують у компанії Pixar під час роботи над новими фільмами. Це нарада, де всі мають забути про посади й дати щирий відгук людині, яка представляє ідею.
У Braintrust немає керівників і підлеглих. Це важливо, бо людина, відповідальна за проєкт, не зобов’язана підкорятися думці начальства. Після Braintrust вона сама має вирішити, що робити далі.
На таких нарадах можна говорити відверто й глибоко аналізувати ідеї. Зустріч Braintrust проходить у доброзичливій атмосфері, її мета — допомогти. Усі забувають про посади й особисті інтереси — у цьому й різниця між Braintrust і звичайною нарадою: на нарадах панує конкурентне середовище, там люди порівнюють свої ідеї з чужими й сперечаються.
QKOMP, [24.06.19 07:12]
- Трьох людей достатньо, щоб створити продукт
Менша команда — кращий продукт
У Basecamp застосовують чудовий підхід — над продуктом працює команда з трьох людей.
Зазвичай це двоє програмістів і один дизайнер. У такій команді люди більше залучені до роботи, витрачають менше ресурсів, а рішення їм ухвалювати легше: троє швидше дійдуть згоди, ніж тридцятеро.
Цей підхід можна застосовувати в компаніях будь-якого масштабу — від стартапів до багатомільярдних корпорацій. Так працюють не лише автори з Basecamp, а й працівники Nike: один із найкращих продуктів Nike створили троє людей. Зараз я розповім про нього.
HTM
HTM — назва експериментального дизайнерського проєкту Nike, запущеного у 2002 році. Вона складається з перших літер імен його авторів: Хіросі Фудзівари, Тінкера Гетфілда й Марка Паркера (генерального директора та дизайнера Nike).
У чому особливість HTM?
Двоє дизайнерів і один керівник вирішили переосмислити дизайн наявних продуктів, щоб створити новий. Це чудовий приклад того, як дизайнери можуть працювати разом із генеральним директором, а не просто отримувати від нього вказівки.
У команді було лише троє людей, тому їм вдалося пришвидшити виробничий процес. Команда швидко переходила від розроблення продукту до його випуску — раніше в компаніях такого масштабу це здавалося неможливим.
А що, як зібрати команду з чотирьох-п’яти людей?
Що більше людей, то більше метушні. Якщо хочете спростити процес, зайві люди заважатимуть — великим командам потрібен керівник, інакше їм важко самостійно організувати свою роботу.
Утрьох зручніше домовлятися й обговорювати, а маленька команда може швидко створити грандіозний проєкт. Їй не доведеться перериватися на наради й чекати на схвалення керівництва. Якби в команді було більше людей, це ускладнило б процес.
Маленька команда може створити щось видатне, а великій зробити це до біса складно. Працюючи втрьох, доведеться бути відвертими одне з одним і знаходити компроміси. І найголовніше — між трьома людьми менше непорозумінь, тож їм легше координувати роботу.
Утрьох складніше створити новий продукт чи розробити функцію, ніж у великій команді, але в цьому й принадність обмежень.
Кажуть, щоб намалювати хорошу картину, потрібно взяти полотно побільше. Творчі люди знають, що це не так. Надто велика свобода може призвести до посередності, адже без меж немає стимулу вийти за них. Якщо надати творчій людині обмежені ресурси, вона легко впровадить інновації й створить щось видатне.
QKOMP, [24.06.19 07:13]
- «Нічого не робити» може бути правильним рішенням
Не обов’язково змушувати всіх оновлюватися. Нехай люди користуються тією версією продукту, яка їм більше подобається
Люди не люблять змін, зокрема в продуктах. Їм неприємно, коли ми змушуємо їх користуватися новою версією, якої вони не хотіли.
Припустімо, ви працюєте над V2 (новою версією) свого продукту й збираєтеся її випустити. Що робити з тими, кому зручно користуватися V1 і хто не хоче оновлення? Більшість компаній цього не враховують і думають: «V2 краща, невже вони не хочуть на неї перейти?»
Коли в Basecamp працювали над редизайном застосунку, вони зупинилися посеред процесу й запитали себе: «А що, як люди звикли до поточної версії й не хочуть переходити на нову?» У їхньому випадку перехід із V1 на V2 означав перенесення даних, конвертування форматів і роботу з цілком новим інтерфейсом.
У Basecamp вирішили не змушувати користувачів переходити на іншу версію. Оновлення було необов’язковим, і користувач міг залишитися з V1, якщо вона подобалася йому більше. Так компанія заощадила ресурси й потішила клієнтів.
Іноді доводиться боротися з очевидним. Доводиться визнавати, що «поліпшити» — не завжди означає «принести користь». Вирішити нічого не робити дуже складно, але це може бути найкращим варіантом.
Не лише в Basecamp це зрозуміли. Ще один чудовий приклад — Freshbooks, сервіс автоматизації виставлення рахунків. Я давно ним користуюся й на власному досвіді переконався, чому не форсувати зміни — хороше рішення.
Коли вони випустили нову версію продукту, перехід на неї був необов’язковим — на V2 можна було перейти будь-коли. Ба більше, можна було переходити на вищу й нижчу версії, щоб зрозуміти, яка підходить краще. Давши людині погратися з програмою, Freshbooks позбавили її стресу й заощадили її час, тож користувач залишився задоволений.
Через два тижні я перейшов на нову версію застосунку. Принадність у тому, що це було моє рішення, а не рішення компанії: я мав час погратися з V2, звикнути й переконатися, що вона мені підходить.
QKOMP, [24.06.19 07:13]
- Щоб дізнатися, чи хороший продукт, випустіть його на ринок
Не витрачайте час на безліч досліджень і обговорень. Створіть продукт, випустіть його на ринок і подивіться, як його сприймуть
Якщо хочете дізнатися правду про те, чи хороший продукт, його потрібно випустити на ринок. Можна тестувати, проводити мозкові штурми, сперечатися й опитувати людей, але лише вихід на ринок покаже, потонете ви чи випливете.
Працюючи над продуктом, легко втратити контроль і приділити проблемам більше уваги, ніж планували: провести додаткові тести, ще раз усе обговорити, вкласти більше грошей. Часто бракує дисципліни, щоб випустити продукт у межах бюджету й у строк.
Щоб заощадити ресурси, краще запустити продукт і подивитися, як ним користуватимуться.
Ми багато сперечаємося, які функції потрібно впровадити, щоб дати клієнтові те, чого він хоче. Але дізнатися це вдасться, лише коли продукт пройде перевірку ринком: жодні опитування, тестування користувачів і дослідження не скажуть заздалегідь, чи хороший він.
Визначтеся з ідеєю. Створіть продукт у невеликій команді за короткий час. Випустіть його на ринок і подивіться, як його сприйняли.
Цей принцип працює з фільмами, іграми, музикою й навіть архітектурою. Ви не дізнаєтеся, чи сподобається ваша робота людям, чи купуватимуть і використовуватимуть її, доки не випустите її у світ. Можна намагатися передбачити це, сидячи з командою в офісі, але так дуже легко помилитися.
Правильні відповіді ви отримаєте, лише коли люди купуватимуть або використовуватимуть ваш продукт у звичному для них середовищі й із власною мотивацією. Усе інше — симуляція.
У Basecamp повною мірою користуються цією ідеєю. До запуску продукту вони нічого не показують клієнтам, не проводять бета-тестів, не запитують людей, скільки ті готові заплатити й що думають про продукт. Вони запускають продукт, і ринок скаже їм правду.
Ви можете щось упустити, помилитися у важливих речах, але це не головне. Ризик буде в будь-якому разі. То навіщо обговорювати, якщо можна створити продукт, запустити його й дізнатися все від користувачів?
Я говорив про це з другом-геймдизайнером. Ми обговорювали людей, які розробили легендарні ігри: вони теж діяли навпомацки й не були певні, що проєкт удасться. Звісно, є технології, знання з психології поведінки, попередні релізи, засвоєні помилки й інші речі, які допомагають не вскочити в халепу. Але, доки ви не ризикнете випустити продукт, не дізнаєтеся, чи буде він успішним.
Висновки
Не доводьте себе до божевілля, працюючи над продуктом або функцією. Процес буде простішим та ефективнішим, якщо дотримуватися цих принципів:
- Продумайте ідею;
- Працюйте в команді з трьох людей;
- Пам’ятайте, що іноді «нічого не робити» — найкращий варіант;
- Дослідження не дадуть точних відповідей. Випустіть продукт на ринок, подивіться, як його сприйняли, і зробіть висновки.