Продуктивність чи хаос? Реальність таск-менеджерів — хочу почути вашу думку
Люди, чого так важко розібратися з таск-менеджерах? 😐
Замість «спростити життя» — купа кнопок і налаштувань.
Це інколи тільки додає хаосу.
Привіт! Я Настя. Починаю свій шлях у UX/UI дизайні й зараз шукаю людей для глибинного інтервʼю про таск-менеджери (Trello, Asana, Jira, ClickUp, Notion та інші).
Якщо ви користуєтесь такими інструментами та розумієте, що це можна було зробити простіше, чи взагалі вам приходиться використовувати декілька додатків. І це все біль.
Або навпаки — ви не можете без них жити і всім задоволені. Тоді пишіть!
Мені дуже важлива ваша думка 💛
Інтервʼю триватиме
Формат — зручний для вас.
Це навчальний проєкт, відповіді не підуть далі моєї Google-таблиці ✌️
Актуально до 4 лютого включно.
Хочете допомогти зробити таск-менеджери кращими?
👉 Напишіть у приват, Telegram (@AnastasiTokar) або на пошту ([email protected]).
8 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівTasque, EssentialPIM pro (мені подобається версія 6.02), AbstractSppon ToDoList.
Щоб таск менеджери виправдовували очікування, хоча би пара з них мають бути сіньор таск менеджерами
Еммм... може тому, що ви перелічили 5 продуктів, ні один з яких не є персональним таск-менеджером, а їх складність обумовлена саме нішею, для якої вони призначені, а в одному з них таски це взагалі вторинна фіча? Чому б вам не взяти як приклади Things, Google Tasks, Microsoft ToDo? Може тоді все стане свої місця? Це, звісно, спекуляції, але якщо ви дійшли висновків, що у світі таск-менеджерів щось «не так», у результаті бесід з LLM, то це скоріше тому, що LLM схильні розповідати вам те, що ви хочете почути, а не те, що є насправді. Загалом я згоден, що з таск-менеджерами щось «не так», але гадаю, що це полягає у площині психології, а не UI/UX.
так і є... не користуйтеся )
А що тут досліджувати ? Ціль таких інструментів — software версія інструментарію для керівницьких фреймверків, таких як Kanban uk.wikipedia.org/wiki/Канбан для прикладу.
Від початку японці в Тойота просто вішали доску і на ній таскали папірці різного кольору на яких було написане те чи інше робоче завдання, колір означав його пріорітет. Тоді менеджер або будь хто інший міг дуже швидко розібратись в стані проекта і роботи. Software інструменти дозволяють ще автоматизувати аналізи, вести статистику виявляти структурні показники типу velocity і т.д. Будувати Road Map (схоже не діаграму Ганта) miro.com/agile/agile-roadmap і т.д. і т.п. Гнучкі методології Agile та Scum є найпоширенішими в IT станом на зараз, і базуються вони на менеджменті японського типу. В перше адапотовані ці методології для ІТ були при цьому в Британії.
Тобто це усе інструменти потрібні менеджерам управлінцям, для управління проектами, коли задіяно більше одної людини. Якщо цікаво про що йдеться в контесті ІТ, для початківців для ІТ менеджменту є книга Тома Демарко Deadline. Задача в кінцевому, проект як тимчасове мироприємство потрібне для досягнення запланованого результату за PMI, має потрапляти в строки реалізації та виделіний бюджет. Задля цього потрібно зебеспечити : керуванн цілями та планування, координацію виконавців та зацікавлених сторін, контроль виконання, керування потрібними ресурсами та обладнанням і керування ризиками.
Ви абсолютно праві щодо походження таск-менеджерів як digital-версії менеджерських фреймворків (Kanban, Agile, Scrum) і їх ролі в командній роботі. Але саме тут і виникає ключова проблема, яку я досліджую. Сьогодні більшість популярних інструментів створювались передусім для команд та менеджерів, а не для людей без проєктного бекграунду. В результаті вони часто містять зайвий функціонал. Для досвідчених команд це плюс, але для користувачів із низькою технічною грамотністю або для індивідуального планування — це забагато.
Моя ціль — не зробити ще один таск-менеджер схожий на інші, а дослідити які функції використовуються шодня, а які не використовують зовсім, дослідити який мінімальний набір інструментів дає максимальну користь для користувача. Питання не в тому чи потрібні вони взагалі, а скоріше не стали вони занадто складними для користувача, що хоче використовувати його не тільки в роботі а ї в житті.
Якщо маєте власну думку з цього приводу — буду рада обговорити її на інтерв’ю та почути ваші інсайти.
І дякую за пораду.😊
Все відносно просто — будь-який таск менеджер підлаштовується під поточні бізнес-процеси в команді. Так як в кожній команді воні різні — потрібно багато налаштувань, але багато налаштувань переускладнює інтерфейс та роботу з ним. З іншого боку, якщо цих налаштувань не буде, ви не зможете підлаштувати менеджер під поточні бізнес процеси. І він стає беззмістовним для команди.
Тому важливо зробити простий «початковий» інтерфейс + дуже докладний посібник як підлаштувати під свої процеси. Бажано при цьому, щоб ті можливості, що не використовуються не перевантажували інтерфейс, тобто були прихованими.
Зазвичай роблять 2 помилки — або дуже простий інтерфейс для простих бізнес-процесів — але його тупо недостатньо при подальшому розвитку, і інструмент не використовують великі команди/бізнеси. Або переускладнений інтерфейс, коли можна підлаштувати під будь-який бізнес, але складно почати, бо високий поріг входу, і високі системні вимоги (і ціна) що відштовхує малі команди або початківців.
Виходячи з цього, мабуть ідеальним був-би деякий модульний застосунок, який мав-би базу і мінімальні системні вимоги, а все інше додавалося плагінами — причому ціна також зростала відповідно до кількості плагінів (наприклад, за кожен плагін окремо) та завантажених даних.
Повністю погоджуюсь, що базовий інтерфейс має бути легким для старту, а складні можливості — підключатися лише за потреби, без перевантаження UI. Модульна логіка дозволяє масштабувати інструмент разом із ростом команди чи задач, не втрачаючи зручності для новачків.