Як створити інструмент управління проєктами: проєкти, завдання, дошки та дедлайни

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

Почніть із робочого процесу, а не зі списку функцій

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

• Чим для вас є проєкт. Клієнтський проєкт, реліз продукту, будівельний об’єкт, маркетингова кампанія.
• Етапи, через які проходить робота. Наприклад: Бриф → У роботі → Перегляд клієнтом → Готово. Вони стануть вашими статусами та колонками дошки.
• Хто що робить. Хто створює проєкти, хто призначає завдання, хто погоджує.
• На що люди дивляться щодня. Зазвичай це «що моє і що прострочено».
• Що керівникам потрібно щотижня. Проєкти під загрозою, прострочені завдання, навантаження на кожного.

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

Чого потребує інструмент

Дані

Поле позиція у завданнях дозволяє людям перетягувати картки в порядок, який зберігається. Журнал активності відповідає на питання «хто повернув це назад у роботу?» без суперечок.

Сторінки

• Список проєктів зі статусом, відповідальним, датою завершення та кількістю відкритих і прострочених завдань.
• Сторінка проєкту з виглядом дошки (колонки за статусами) і списком (сортування, фільтри).
• Деталі завдання як бічна панель або сторінка: опис, виконавець, дата завершення, коментарі, файли.
• Мої завдання для кожної людини, згруповані за простроченими, сьогоднішніми, цього тижня і пізніше.
• Огляд для керівників: проєкти під загрозою, прострочені завдання, завдання на кожну людину.

Права доступу

Визначтеся заздалегідь:

• Чи можуть усі бачити всі проєкти, чи лише ті, учасниками яких вони є?
• Хто може створювати й архівувати проєкти?
• Чи можна редагувати завдання, призначені іншим?
• Чи матимуть доступ клієнти або підрядники? Якщо так, до яких проєктів і чи бачитимуть внутрішні коментарі?

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

Рішення та компроміси

Фіксовані статуси чи колонки для кожного проєкту

Фіксовані статуси для всіх проєктів спрощують звітність («скільки завдань на перевірці?»). Власні колонки в кожному проєкті гнучкіші, але ускладнюють міжпроєктні огляди. Для однієї команди з одним робочим процесом краще почати з фіксованих статусів.

Дошка, список чи таймлайн

Дошки добре показують потік, списки — сортування й масові зміни, таймлайни — роботу, прив’язану до дат. Спочатку зробіть дошку та список. Вигляд таймлайну або Ганта (смуги на календарі) додає багато складності, особливо із залежностями між завданнями. Додавайте його, лише якщо дедлайни справді визначають вашу роботу.

Сповіщення

Люди очікують дізнаватися, коли їх призначили на завдання або згадали в коментарі. Сповіщення всередині застосунку (дзвіночок зі списком) простіше запустити, ніж email. Для email потрібен провайдер надсилання; див. як надсилати листи з вашого застосунку. Щоденні дайджести прострочених завдань потребують чогось, що працює за розкладом, тож перевірте, як ваш хостинг це підтримує, перш ніж обіцяти.

Оновлення в реальному часі

Два користувачі, які дивляться на одну дошку, рано чи пізно побачать застарілі дані. Для невеликої команди зазвичай достатньо оновлювати дані, коли хтось відкриває сторінку, або час від часу. Живі оновлення — приємно, але для першої версії не обов’язково.

Перший промпт, який працює

Створи інструмент управління проєктами для маркетингового агентства на 10 людей. Проєкти мають назву, клієнта, відповідального, дедлайн і статус (Планування, Активний, На паузі, Завершено). Завдання належать проєкту й мають назву, опис, виконавця, дату завершення, пріоритет (Низький, Звичайний, Високий) і статус (До виконання, У роботі, Перегляд клієнтом, Готово). Сторінки: список проєктів з кількістю відкритих і прострочених завдань; сторінка проєкту з дошкою для перетягування за статусами та сортованим списком; бічна панель завдання з коментарями; сторінка «Мої завдання», згрупована за Простроченими, Сьогодні, Цього тижня і Пізніше; керівницький огляд прострочених завдань за людьми. Зберігай усе в базі даних, веди журнал активності змін статусу та виконавця і запам’ятовуй порядок карток на дошці. Охайний, щільний макет, який працює на ноутбуці й телефоні.

У ньому прописано статуси, сторінки та кілька деталей (журнал активності, порядок карток), які відділяють демо від того, чим команда справді може користуватися.

Кроки побудови

1. Проєкти та завдання у вигляді списків. Створення, редагування, призначення, дедлайни. Перевірте, що дані правильні, перш ніж додавати будь-які вигляди.
2. Вигляд дошки. Колонки за статусами, перетягування для зміни статусу, запам’ятований порядок.
3. Бічна панель завдання та коментарі.
4. Мої завдання. Це сторінка, яку більшість людей відкриватиме щоранку; зробіть її швидкою.
5. Вхід і участь у проєкті. Додайте до того, як у роботу потраплять справжні дані.
6. Журнал активності та сповіщення всередині застосунку про призначення та згадки.
7. Огляд для керівника. Прострочене за людьми, проєкти під загрозою.
8. Імпортуйте поточні проєкти з таблиці або експорту, щоб команда почала з реальними даними.
9. Перевірте з двома людьми одночасно. Перемістіть одну картку, відредагуйте одне й те саме завдання і переконайтеся, що нічого не втрачається.

Типові помилки

• Копіювання кожної функції великого інструменту. Підзавдання, залежності, користувацькі поля, автоматизації та діаграми Ганта кожна додає тижні крайніх випадків. Почніть без них.
• Немає вигляду «мої завдання». Люди не шукатимуть свою роботу на десятках дошок.
• Будь-хто може видаляти проєкти. Архівуйте замість видалення і обмежте, хто це може робити.
• Вільний текст для статусів. Використовуйте фіксований список, інакше звіти зламаються.
• Додавання обліку часу. Якщо потрібні години, створіть або підключіть застосунок обліку часу і прив’язуйте записи до завдань.
• Запуск із порожнім інструментом. Новий інструмент без даних не використовують. Спочатку імпортуйте поточну роботу.

Коли краще Trello, Asana чи Jira

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

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

Побудова з Mythex

У Mythex ви описуєте інструмент у чаті, спостерігаєте, як він з’являється в живому прев’ю, а агент додає окрему базу Postgres, коли завданням потрібно зберігатися (попросіть або введіть /database). Вкладення до завдань використовують сховище файлів проєкту (/storage). Вхід для команди додається за вашим власним підходом до автентифікації; див. рецепт додавання входу.

Тут корисний режим планування: попросіть агента спланувати модель даних і сторінки до написання коду, перегляньте план і лише потім будуйте. Після кожного етапу /test змусить агента пройтися по прев’ю (створити проєкт, додати завдання, перетягнути його через дошку) і повідомити про проблеми. Як відправну точку подивіться шаблони командна канбан-дошка, дошка agile-спринтів або продуктовий роадмап.

Запитання