Створення дизайн-макетів і візуалізація рішень чомусь завжди викликає величезний інтерес у всіх учасників команди, будь то менеджер, який бажає освоїти Sketch, або розробник, який багато чого побачив і тепер хоче робити круті інтерфейси сам, а не просити про це дизайнерів. І це нормально, коли все це просто на стадії обговорення. А ось коли доходить до реальної роботи…
У цій темі я розповім яким має бути пошук ідей та як проводити брейншторми з командою так, щоб генерувати не найбільш очевидні, а найбільш ефективні рішення. Які при цьому ще і дуже прості в реалізації. І, що головне, як не витратити на це багато часу і не загрузнути в узгодженнях.
Вибір завдання
Щоб правильно провести брейншторм, для нього треба вибрати правильну тему. Задача, яку ви вносите на обговорення, не повинна бути занадто простий, але при цьому не повинна бути занадто складною. Якщо ви хочете сформувати roadmap на найближчі півроку, то краще думайте про це самі, інакше брейншторм триватиме приблизно стільки ж. Та й питання, які свідомо доведеться довго і клопітно погоджувати зі стейкхолдерами, теж піднімати не варто. Інакше тим самим брейнштормом і хоч якимось результатом пройде стільки часу, що всі вже забудуть, що там взагалі справа було.
В ідеалі — вибирати те, що можна реалізувати найближчим часом. І під найближчим часом я тут маю на увазі пару тижнів. Від сили 3 тижні.
Підготуйте аналітику
Ваша головна зброя — факти. Тому що на питання виду “Навіщо саме цією проблемою зараз займатися?” у вас повинна бути готова ґрунтовна відповідь з цифрами, інакше у свідомості колег питання перетвориться просто у дивний список бажань або взагалі побажання на кшталт “Зробіть мені красиво”. У вас є цифри, дані, аналітика є — використовуйте їх під час брейншторму.
Звичайно, корисно розповісти, скільки грошей принесе нове розв’язання поточної проблеми, якщо ви можете це хоча б приблизно прикинути. Це досить відчутна сутність — вимірювати успіх в грошах. Ще хороший варіант — клієнтів. Говоріть з командою про біль користувачів, які ви виявили на інтерв’ю. Перевірено особисто — на команду реально справляє враження відеозвернення клієнта, який повідомляє, що сервісом в нинішньому вигляді користуватися незручно.
Two pizza team
Не намагайтеся запросити на брейншторм всіх, до кого дотягнетеся — людей повинно бути небагато, але достатньо, щоб з’їсти 2 цілих піци (це приблизно 5-7 осіб). Звичайно, це може бути один дуже голодний розроблення дизайн, так. В ідеалі — запрошуйте найбільш зацікавлених учасників команди.
Ну і якщо ви вирішили діяти саме за таким принципом, то не забудьте і самі піци. Краще з запасом.
Time is money
Розділіть зустріч на дві частини.
Ми у Telegram: Анонси нових статей та бонусні матеріали
Перша половина — це обговорення способів розв’язання поточної проблеми, постарайтеся придумати штук 10-12. Дайте висловитися кожному, хто вже прожував свою піцу. Будьте ввічливі, не перебивайте колег і дайте висловитися кожному, навіть якщо його ідея вам не дуже близька. При цьому пам’ятайте, що ви тут не тільки як людина, яка притягнула піцу, але і модератор — слідкуйте за дискусією, якщо хтось починає сильно офтопити, повертайте розмову в правильне русло.
Друга половина — вибір 3-5 кращих ідей та їх обговорення. Щоб переконатися, що всі один одного зрозуміли, ці ідеї можна спробувати відразу сценарно промальовувати.
Візуалізація
Записуйте і замальовуйте всі ідеї. Фліпчарт, стікери – і вперед.
А що робити, якщо команда розподілена?
Тут на допомогу приходить безліч софту для командної роботи, тому що проблема комунікації в розподілених командах, прямо скажемо, є не тільки у вас.
Пошук ідей: Після всього
Коли всі рішення, які ви вирішили втілювати в життя, перейдуть на етап реалізації, тримайте своїх хлопців в курсі, озвучуйте їм поточний статус — що узгоджується, що вже в роботі, та інше, щоб у них не з’являлося відчуття, що з ними просто поговорили та пішли робити свою справу. Їм насправді буде цікаво бачити, як їх ідеї, висловлені на брейнштормі, поступово відгукуються в тих чи інших функціях продукту, що впливає і на зручність для користувачів, і на цифри для бізнесу.
Велика користь, яку я помічаю в результаті таких зустрічей:
- Залученість і інтерес/
Ясна річ, що ті, хто причетні до створення ідеї або рішення, набагато сильніше зацікавлені в реалізації задуманого. А особиста зацікавленість учасників команди — це дуже і дуже гостра мотивація, яка ще й грає на руку бізнесу. Вона витісняє собою колишню інертність, тому що команда починає бачити простий і прозорий шлях створення рішення — від брейншторму до реалізації. Від зусиль — до результату.
- Дізнаюся про всі підводні камені раніше звичайного.
З допомогою брейншторму ви зможете заздалегідь дізнатися про всі корнер-кейсах. Ідеї будуть пропонувати хлопці з вашої команди, які знаються на legacy і бек-системах краще, ніж ви. А ще буде менше троллінгу, тому що ніхто не захоче міркувати про абсурдність рішень, якщо ці рішення були згенеровані безпосередньо учасниками команди.
- Згуртована команда.
Загальна прозора мета об’єднує команду. По-перше, це ще одна можливість поспілкуватися з колегами наживо, а по-друге…
- T2M знижується!
Всі перераховані вище пункти впливають на те, що завдання вирішується швидше звичайного. А якщо ви добре підготовлені і правильно презентуєте результати спільної роботи в команді, то успіх можна буде повторювати знову і знову.
Дуже ймовірно, що деяким із запрошених зустріч здасться нудною і безглуздою, все-таки «розробники хочуть писати код». Тому завжди робіть брейншторми добровільними. А якщо якийсь із запропонованих пунктів не підходить саме вашій команді, то сміливо приберіть його або замініть на щось інше. Щоб зробити ваші процеси самими класними, постійно збирати зворотний зв’язок від усіх учасників команди.
