Comments 7
Я так понимаю это система управления задачами, из аналогов вспомнил рекламируемый monday.com. Панели с задачами смотряться здорово, интерфейс в целом понравился.
Вопросы по стикерам:
1) Чем отличаются пункты в стикерах от названий колонок? Например, можно ли по заданному стикеру показать все его пункты в виде колонок на новой доске (стикер: состояние => доска: колонка)?
2) И вопрос, который отсюда вытекает: можно ли дублировать одну задачу на несколько колонок — и переходить по ним из задачи? Насколько я понимаю, и то и другое похоже на множественную группировку по тегам, как в Evernote.
3) И еще один вопрос — у стикеров только один уровень вложенности, или можно строить древовидные стикеры?
Вопросы по планированию:
1) Как происходит управление сложностью описания контекста для задач? Понятно, что можно определить кучу стикеров (параметров) для каждой задачи, но это займет много времени: место, время, отдел, подотдел, важность, отношение к другим задачам и т.д. Есть какие-то скрипты автоматического добавления стикеров при определенных условиях?
2) Как происходит планирование и контроль длинных проектов, которые длятся и улучшаются годами? Допустим, есть некоторый проект, есть колонки, посвященные отдельным его частям, есть протяжение этих частей во времени, есть только текущие задачи — можно ли на каком-то очередном этапе посмотреть ретроспективу, что было сделано по некоторой части проекта за последние 3 года (чтобы определить, чем надо заниматься дальше)? Как все это вести, чтобы архив проекта не превращался в «помойку»?
1) Чем отличаются пункты в стикерах от названий колонок? Например, можно ли по заданному стикеру показать все его пункты в виде колонок на новой доске (стикер: состояние => доска: колонка)?
2) И вопрос, который отсюда вытекает: можно ли дублировать одну задачу на несколько колонок — и переходить по ним из задачи? Насколько я понимаю, и то и другое похоже на множественную группировку по тегам, как в Evernote.
3) И еще один вопрос — у стикеров только один уровень вложенности, или можно строить древовидные стикеры?
Вопросы по планированию:
1) Как происходит управление сложностью описания контекста для задач? Понятно, что можно определить кучу стикеров (параметров) для каждой задачи, но это займет много времени: место, время, отдел, подотдел, важность, отношение к другим задачам и т.д. Есть какие-то скрипты автоматического добавления стикеров при определенных условиях?
2) Как происходит планирование и контроль длинных проектов, которые длятся и улучшаются годами? Допустим, есть некоторый проект, есть колонки, посвященные отдельным его частям, есть протяжение этих частей во времени, есть только текущие задачи — можно ли на каком-то очередном этапе посмотреть ретроспективу, что было сделано по некоторой части проекта за последние 3 года (чтобы определить, чем надо заниматься дальше)? Как все это вести, чтобы архив проекта не превращался в «помойку»?
По стикерам.
1. В YouGile cтикеры — это модификаторы задач. Названия колонок — статус выполнения задачи.
То есть «по классике» колонки называются, скажем, "Backlog" / "В работе" / "Готово", а задачи в этих колонках могут содержать, например, стикер "Приоритет" с состояниями "Не важно" / "Важно" / "Критично".
Или может быть стикер "Вид" с состояниями "Разработка" / "UI" / "Копирайтинг".
Подробнее об этом можно посмотреть в наших обучающих видео, вот ссылка на плейлист — www.youtube.com/watch?v=1S7rzC349cw&list=PLHpAc006UaLxriRzlGWFNS2EAO8zdQ5JR. Есть еще видео про функции системы, вот ссылка на конкретную секунду про стикеры — www.youtube.com/watch?v=9NWNvlcV9VA&t=323s
2. Задачи в YouGile можно продублировать и связать (функция «Связь задач»), но это будут разные задачи, у них будут разные описания, чеклисты и чаты.
3. У стикеров только один уровень вложенности. Как правило, если нужно дерево, лучше вместо этого создать другой стикер. Так меньше шансов запутаться и лучше видна структура проекта.
По планированию.
1. В YouGile есть «Конфигуратор». Если есть базовые знания JS, можно написать скрипт, который будет при создании задачи сразу накидывать на неё стикеры. Останется только распределять. Можно написать скрипт, который будет «видеть» определенные символы или слова, когда вы создаёте задачу и сразу по этим условиям накидывать конкретные состояния стикеров. Например для себя я написал короткий скрипт — если название задачи начинается с восклицательного знака, то на неё накидывается стикер «Приоритет» со статусом «Важно».
Кстати.
2. Лучше не создавать колонки, посвященные частям проекта.
В системе есть стикер с интервалами дат "Спринт" — отрезки времени, за которую команда создаёт часть продукта (работы). Это классика скрама, которую можно применить к разным сферам деятельности.
При заходе на доску, в которой есть такой стикер спринта, происходит автоматическая фильтрация по стикеру и на доске видны только актуальные задачи текущего периода (периоды задаются заранее).
Также выполненные задачи можно либо переносить в колонку «Выполненные задачи», либо архивировать внутри колонки (любой колонки), оставляя только актуальные задачи. Также можно завести дополнительный стикер этапов и пользоваться фильтрациями по стикеру. Фильтрация — это действенный способ превращать «помойку» в структуру.
1. В YouGile cтикеры — это модификаторы задач. Названия колонок — статус выполнения задачи.
То есть «по классике» колонки называются, скажем, "Backlog" / "В работе" / "Готово", а задачи в этих колонках могут содержать, например, стикер "Приоритет" с состояниями "Не важно" / "Важно" / "Критично".
Или может быть стикер "Вид" с состояниями "Разработка" / "UI" / "Копирайтинг".
Подробнее об этом можно посмотреть в наших обучающих видео, вот ссылка на плейлист — www.youtube.com/watch?v=1S7rzC349cw&list=PLHpAc006UaLxriRzlGWFNS2EAO8zdQ5JR. Есть еще видео про функции системы, вот ссылка на конкретную секунду про стикеры — www.youtube.com/watch?v=9NWNvlcV9VA&t=323s
2. Задачи в YouGile можно продублировать и связать (функция «Связь задач»), но это будут разные задачи, у них будут разные описания, чеклисты и чаты.
3. У стикеров только один уровень вложенности. Как правило, если нужно дерево, лучше вместо этого создать другой стикер. Так меньше шансов запутаться и лучше видна структура проекта.
По планированию.
1. В YouGile есть «Конфигуратор». Если есть базовые знания JS, можно написать скрипт, который будет при создании задачи сразу накидывать на неё стикеры. Останется только распределять. Можно написать скрипт, который будет «видеть» определенные символы или слова, когда вы создаёте задачу и сразу по этим условиям накидывать конкретные состояния стикеров. Например для себя я написал короткий скрипт — если название задачи начинается с восклицательного знака, то на неё накидывается стикер «Приоритет» со статусом «Важно».
Кстати.
- Время создания задачи видно в шапке задачи.
- Для отделов обычно создаются проекты (а для подотделов — доски внутри проекта) и тогда не надо плодить лишние стикеры.
- Отношение к другим задачам — это функция «связь задач», то есть тоже не нужны стикеры.
- Остаётся упомянутое вами «место» (это, вероятно, специфика вашего бизнеса) и важность (стикер «приоритет»). А это уже не так много стикеров.
2. Лучше не создавать колонки, посвященные частям проекта.
В системе есть стикер с интервалами дат "Спринт" — отрезки времени, за которую команда создаёт часть продукта (работы). Это классика скрама, которую можно применить к разным сферам деятельности.
При заходе на доску, в которой есть такой стикер спринта, происходит автоматическая фильтрация по стикеру и на доске видны только актуальные задачи текущего периода (периоды задаются заранее).
Также выполненные задачи можно либо переносить в колонку «Выполненные задачи», либо архивировать внутри колонки (любой колонки), оставляя только актуальные задачи. Также можно завести дополнительный стикер этапов и пользоваться фильтрациями по стикеру. Фильтрация — это действенный способ превращать «помойку» в структуру.
Спасибо за подробный ответ!
Мне кажется, что стикеры – это просто разные сценарии использования одного и того же функционала – множественного тегирования. Ваше отличие в том, что есть множество разных шаблонов использования, а не просто невнятная куча тегов. Подобная несуразность была в Evernote, где есть дерево тегов и отдельно дерево блокнотов, несмотря на то, что блокноты — это те же теги, только другого типа, и почему-то нельзя превратить тег в отдельный блокнот.
Если колонка — это этап выполнения, тогда имеет смысл связывать колонки в некий рабочий процесс, чтобы задачи автоматически перетекали из одной колонки в другую (кстати, задачи перетекают, или создаются новые задачи, например: прототип X -> реализация X -> тестирование X?). Но мне кажется, что колонки = этап выполнения только тогда, когда на экране надо показать последовательность работ слева направо.
А если надо показать хронологию сверху вниз, то потребуется вынести в отдельную колонку все работы по какому-то направлению, и тогда уже одна колонка будет представлять собой целую хронологическую цепочку работ. Или, например, работу конкретного отдела. То есть, доска с колонками — это не более чем развёртка, шаблон отображения.
Согласитесь, для такой задачи полезно было бы объединить функционал колонок и стикеров — это более гибкий вариант. Захотел посмотреть проекцию по этапам — выбрал стикер с этапами работ и развернул этапы в колонки. Захотел проекцию по отделам — выбрал стикер отделов и развернул, захотел колонки по месяцам — выбрал стикер дат (и задачи автоматом разбились по месяцам), захотел колонки по сотрудникам,… ну и т.д. В общем случае, доска — это просмотр многомерного массива вдоль выбранной категориальной или порядковой оси, +фильтрация данных по другим осям.
А когда добавите несколько рядов колонок (=строки) — станет ещё интереснее: можно будет разворачивать многомерный массив по двум осям (отделы x даты, этапы x сотрудники, и т.д.)
Давайте разберем на примере: делаем модуль одной большой системы, внутри модуля есть 3 куска, которые надо реализовать. Каждый кусок бьется на свои задачи по стадиям разработки: набросать прототип, сделать тесты для проверки прототипа, проверить принципиальную работоспособность, получить от клиента обратную связь-1, доделать прототип, обратная связь-2, переписать прототип в систему, добавить тесты в систему, обратная связь-3,… и другие возможные доработки. И еще допустим, что прототип — это одна команда и один язык, модуль системы — это другая команда, тестировщики — третья, команда пользователей — четвертая. Как тогда лучше располагать задачи?
Мне кажется, что руководителю нужно иметь разные режимы показа:
А) По отделам: все (сделанные и не сделанные) работы отдела прототипирования, все работы отдела разработки, тестировщиков и т.д.
Б) По проектам или кускам продукта: как был протянут через все отделы некий кусок N — какие этапы работ он прошел в каждом отделе, через какие ошибки, что было поправлено, какие работы тормозятся, из-за чего, и т.д.
В) Хронологию работ по месяцам или неделям + фильтрацию по сотрудникам или отделам — кто что делал и когда.
Г) Сравнительный вклад каждого сотрудника.
Мне кажется, что стикеры – это просто разные сценарии использования одного и того же функционала – множественного тегирования. Ваше отличие в том, что есть множество разных шаблонов использования, а не просто невнятная куча тегов. Подобная несуразность была в Evernote, где есть дерево тегов и отдельно дерево блокнотов, несмотря на то, что блокноты — это те же теги, только другого типа, и почему-то нельзя превратить тег в отдельный блокнот.
Если колонка — это этап выполнения, тогда имеет смысл связывать колонки в некий рабочий процесс, чтобы задачи автоматически перетекали из одной колонки в другую (кстати, задачи перетекают, или создаются новые задачи, например: прототип X -> реализация X -> тестирование X?). Но мне кажется, что колонки = этап выполнения только тогда, когда на экране надо показать последовательность работ слева направо.
А если надо показать хронологию сверху вниз, то потребуется вынести в отдельную колонку все работы по какому-то направлению, и тогда уже одна колонка будет представлять собой целую хронологическую цепочку работ. Или, например, работу конкретного отдела. То есть, доска с колонками — это не более чем развёртка, шаблон отображения.
Согласитесь, для такой задачи полезно было бы объединить функционал колонок и стикеров — это более гибкий вариант. Захотел посмотреть проекцию по этапам — выбрал стикер с этапами работ и развернул этапы в колонки. Захотел проекцию по отделам — выбрал стикер отделов и развернул, захотел колонки по месяцам — выбрал стикер дат (и задачи автоматом разбились по месяцам), захотел колонки по сотрудникам,… ну и т.д. В общем случае, доска — это просмотр многомерного массива вдоль выбранной категориальной или порядковой оси, +фильтрация данных по другим осям.
А когда добавите несколько рядов колонок (=строки) — станет ещё интереснее: можно будет разворачивать многомерный массив по двум осям (отделы x даты, этапы x сотрудники, и т.д.)
Давайте разберем на примере: делаем модуль одной большой системы, внутри модуля есть 3 куска, которые надо реализовать. Каждый кусок бьется на свои задачи по стадиям разработки: набросать прототип, сделать тесты для проверки прототипа, проверить принципиальную работоспособность, получить от клиента обратную связь-1, доделать прототип, обратная связь-2, переписать прототип в систему, добавить тесты в систему, обратная связь-3,… и другие возможные доработки. И еще допустим, что прототип — это одна команда и один язык, модуль системы — это другая команда, тестировщики — третья, команда пользователей — четвертая. Как тогда лучше располагать задачи?
Мне кажется, что руководителю нужно иметь разные режимы показа:
А) По отделам: все (сделанные и не сделанные) работы отдела прототипирования, все работы отдела разработки, тестировщиков и т.д.
Б) По проектам или кускам продукта: как был протянут через все отделы некий кусок N — какие этапы работ он прошел в каждом отделе, через какие ошибки, что было поправлено, какие работы тормозятся, из-за чего, и т.д.
В) Хронологию работ по месяцам или неделям + фильтрацию по сотрудникам или отделам — кто что делал и когда.
Г) Сравнительный вклад каждого сотрудника.
Спасибо за ваши комментарии!
Почитайте про канбан-доски, agile и «вот про это всё» :)
Вам это поможет понять принцип работы YouGile, ведь система сделана под эту методологию.
Вариант с задачами в многомерном массиве на практике для большинства компаний или сложен или не нужен.
Ваш пример довольно просто можно реализовать в YouGile. В этом могут помочь зеркальные столбики (это копия колонки, которая может находиться в другой доске или проекте) и ещё может быть распределение прав доступа. Ну и, конечно же, стикеры. Вероятно в ближайших выпусках наших обучающих видео мы расскажем как организовывать в YouGile процессы, подобные вашему.
Руководитель сейчас может смотреть статистику по проектам, по людям, по типу действий с задачами, фильтруя это всё по интервалам дат. А при проставлении стикера «таймтрекинг» выдаётся график временных затрат.
По всем вопросам, которые у вас возникнут при использовании системы, пишите внутри YouGile в разделе «Обратная связь» в левом меню, вам оперативно ответят.
Почитайте про канбан-доски, agile и «вот про это всё» :)
Вам это поможет понять принцип работы YouGile, ведь система сделана под эту методологию.
Вариант с задачами в многомерном массиве на практике для большинства компаний или сложен или не нужен.
Ваш пример довольно просто можно реализовать в YouGile. В этом могут помочь зеркальные столбики (это копия колонки, которая может находиться в другой доске или проекте) и ещё может быть распределение прав доступа. Ну и, конечно же, стикеры. Вероятно в ближайших выпусках наших обучающих видео мы расскажем как организовывать в YouGile процессы, подобные вашему.
Руководитель сейчас может смотреть статистику по проектам, по людям, по типу действий с задачами, фильтруя это всё по интервалам дат. А при проставлении стикера «таймтрекинг» выдаётся график временных затрат.
По всем вопросам, которые у вас возникнут при использовании системы, пишите внутри YouGile в разделе «Обратная связь» в левом меню, вам оперативно ответят.
Спасибо, ознакомлюсь!
Еще одно уточнение:
К тому же, если вы сделаете хорошую систему для множественных тегов с разными шаблонами тегов и развертками по осям и плоскостям, то такой продукт сам по себе ценен как костяк для knowledge base и аналитической работы. Не только для задач, но и для решений, кейсов (и других единиц полезной информации) — я видел несколько профессиональных баз знаний, которые организованы именно таким способом, правда там ещё добавляются разные наборы тегов для разных групп пользователей. Условно, работнику нужны одни теги, а консультанту, который анализирует некую область бизнеса, нужны другие теги.
Еще одно уточнение:
Вариант с задачами в многомерном массиве на практике для большинства компаний или сложен или не нужен.Да, но это уже другая задача: это скорее о том, как скрывать избыточный функционал (например, лишние стикеры, которые и так понятны из контекста). Или: как скрыть сложность системы для пользователя, чтобы новичок мог выбрать из небольшого числа простых вариантов, а опытный пользователь мог бы использовать все возможности системы.
К тому же, если вы сделаете хорошую систему для множественных тегов с разными шаблонами тегов и развертками по осям и плоскостям, то такой продукт сам по себе ценен как костяк для knowledge base и аналитической работы. Не только для задач, но и для решений, кейсов (и других единиц полезной информации) — я видел несколько профессиональных баз знаний, которые организованы именно таким способом, правда там ещё добавляются разные наборы тегов для разных групп пользователей. Условно, работнику нужны одни теги, а консультанту, который анализирует некую область бизнеса, нужны другие теги.
Sign up to leave a comment.
Как планировать на год. Кейс IT-компании 120 человек и две практики для небольших команд