Приветствую тебя, читатель! Это первая статья в моем блоге, и в ней я хочу поделиться собственным исследованием в области систем управления проектами. В данном посте переплетаются как мои личные наблюдения и идеи, так и практики, заимствованные из мира разработки программного обеспечения. Всё это нашло отражение в моем пилотном проекте — Hotpot Tracker.
Я буду рад, если мои идеи будут полезны и помогут в решениях организации управления проектами или даже при создании своих систем.
Примечание: Hotpot Tracker — пилотный проект, созданный для демонстрации идей, описанных в статье. Он не ориентирован на полноценную замену существующих решений и пока не включает многие стандартные функции, присутствующие в Jira или Linear.
Содержание
- Несколько досок вместо одной универсальной
- Вовлечение команды
- Построение процесса через проверки членов команды
- Комментарии — зло
- Ориентированность на AI
Несколько досок вместо одной универсальной
В моей практике за создание досок чаще отвечает человек, которому нужно управлять процессом. Если для вашей структуры компании или команды это то, что нужно — проблем нет. Но если в вашей организационной структуре поощряется проактивность участников, то становится ясно, что не только начальнику нужно управлять процессом, но и членам команды.
Если в команде вместе с менеджером работают специалисты, чья область не является управленческой (например, дизайнер), — нужно не забывать, что специфика выполнения его задачи от проекта к проекту может отличаться.
Пример: нарисовать логотип — выглядит как задача, которую можно стандартизировать через универсальную доску, но, к примеру, переделать дизайн кнопки, которая используется во всем мобильном приложении, — затрагивает более широкий круг интересантов и требует нестандартного процесса.
В сквозных задачах априори вовлечено больше команд, поэтому настраивать единственную “супер-доску” не оптимально.
В подобных ситуациях заводят некоторую группировку задач (epic, milestone), которая группирует задачи по некоторому контексту. На самом деле сам “эпик” ничего полезного для процесса не дает, потому что это всего лишь инструмент для понижения когнитивной сложности.
Моя идея для улучшения: сделать отдельную доску для данного проекта. Отдельная доска делегирует управление и:
- Открывает возможность построить свою собственную логику статусов, которая может сильно отличаться от стандартной (например, kanban);
- Сохраняется идея epic’ов — проект, выраженный доской, декомпозирован и выполняет полезную функцию для менеджмента и команды.
Иными словами — создавайте больше досок вместе. Разрешите членам команды подстроить инструмент управления под свою специфику.
Ограничение этого подхода состоит в самой организации управления. Данный подход требует доверия и обратной связи для управления — командам разрешено строить процессы, как им виднее, но взамен нужно обосновывать выбор принятых решений.
Вовлечение команды
Зачастую вовлеченность строится вокруг связывания исполнителя с конкретной задачей, но, кроме выполнения своих задач, в командах мы участвуем и в чужих задачах.
На самом деле здесь проглядывается проблема из пункта Комментарии — зло про то, что контекст обсуждения размазан по мессенджерам, личным перепискам и отсутствующей документации.
Вовлечение команды должно строиться вокруг обратной связи с используемой системой. Проще говоря: если вы косвенно участвуете в выполнении задачи — система должна помогать втягивать вас в процесс и принятие решений. К примеру, почти все трекеры рассылают email-сообщения при различных событиях.
В трекерах широко известен подход Watch (отслеживание изменений). В моей реализации я рассматриваю привязку проверяющих к колонке (колонка = этап работы). Стоит отметить, что данный подход работает лучше, если процесс оформлен через множество досок.
Данный подход позволяет заинтересованным коллегам концентрироваться именно на нужных этапах выполнения. Но для более эффективной реализации желательно добиться:
- Присутствия менеджмента на доске задач вместе с командой — их задачи также располагаются на доске;
- Управление и исполнители могут быть друг у друга проверяющими на этапах работы (колонках).
Конечно, это не просто реализовать в больших компаниях. Однако, если перечитать второй пункт выше, то можно увидеть возможности для выстраивания эффективной коммуникации, что зачастую является проблемой.
Построение процесса через проверки
Я занимаюсь разработкой программного обеспечения и считаю, что в нашей среде есть отличные идеи для заимствования. Например, если взглянуть на системы контроля версий GitHub или GitLab — можно увидеть, что есть механика одобрения при запросе на слияние (разработчик отправляет свои правки, и его изменения могут быть приняты, если другие разработчики это проверят и одобрят).
Если сравнить код программы и наши ежедневные тексты задач в трекере, то на самом деле у них много общего. Код программы выражает описание действий, которые совершит компьютер с предопределенным ожидаемым результатом. Текст задачи выражает описание действий, которые совершит человек. В обоих случаях мы видим, что постановка задачи архиважна, и если в GitHub программисты проверяют код друг друга, то в трекере мы можем проверять текст задачи и прилагаемые артефакты.
Если принять за правило, что контент задачи для нас значим и должен отвечать некоторым правилам оформления — то остается только построить проверки вокруг этого.
В Hotpot Tracker проверяющими могут быть любые члены команды, и мы их привязываем к колонкам. Здесь же я реализовал правила одобрения (approves):
- Задачу должен одобрить хотя бы один из проверяющих (one of contributors);
- Все проверяющие должны одобрить задачу (all contributors).
Если на данном этапе проверяющих что-то не устраивает — задача не может перейти в другие этапы.
Комментарии — зло
Вокруг задачи появляются личные сообщения, email’ы, обсуждения на звонках, промежуточные схемы в интерактивных досках. Контекст размывается, и даже если есть комментарии прямо в задаче — это может превратиться в сотни сообщений.
Если мы взяли за правило в задаче отображать наши решения и результаты — то логичнее к ним и привязываться.
Например, в системе GitHub, если проверяющий разработчик нашел неточности — он может выразить свое мнение прямо на нужном участке кода, инициировав обсуждение.
Вместо комментариев мы можем использовать обсуждения, которые привязываются к словам и предложениям текста из задачи.
Ориентированность на AI
На дворе 2025 год. В digital и IT — бум искусственного интеллекта. Для меня как разработчика становится ясно, что привычные системы будут меняться. Качество работы ИИ зачастую зависит от входных данных, и основная тенденция для более эффективного использования GPT и агентов — это постановка задачи. Чем детальнее и точнее опишешь prompt — тем лучше результат.
Если честно посмотреть на большинство задач, которые мы оформляем, то можно догадаться, что AI текущего поколения будет генерировать множество неточностей при анализе, а уж тем более не выполнит сложную работу за человека. Получается, что чем больше мы будем отдавать контекста в трекер задач и лучше обогащать содержимое задачи — тем лучше сможем приспособить AI разных направленностей.
В Hotpot Tracker на данный момент есть простой отчет при помощи AI о состоянии нужной доски, и если вы осмысленно добавите необходимые параметры для доски и задач (сроки, исполнители, блокирующие факторы) — то AI сумеет построить более эффективный отчет.
Заключение
Если перечисленные идеи получится реализовать в ваших системах управления проектами (особенно подручными средствами) — то это прекрасно!
Hotpot Tracker не ориентирован на полноценную замену существующих систем, а лишь демонстрирует их наглядно в одном месте.
Я считаю, что стоит заглядывать в соседние области для заимствования идей и инструментов, потому что всегда где-то рядом люди решают похожие задачи намного эффективнее. Нужно только заметить!
Спасибо за внимание!