Comments 8
Ну вот, я не просто лайкнул, а ещё и хвалю.
Сочная статья, молодцы! :)
P.S. Автозапуск десктопной версии — правильно ли я понял, каждое утро при включении компьютера после загрузки у сотрудника запускается указанное приложение по задачам?
Отличная статья, особенно хорошо расписан пункт 5. У нас в компании и близко нет прозрачности между отделами.
Я бы дополнил 5 пункт — стоит нормально разграничить визуально и логически, в больших компаниях даже на 3-4 группы:
— задачи моего отдела
— задачи смежных отделов; возможно разделить по направлениям на 2-3 пункта.
— все остальное
+ должна быть возможность у каждого сотрудника индивиудально скрыть по фильтрам (автор/отдел/ключевые слова) в своих лентах (кроме отдельной ленты «вообще все задачи»).
— задачи моего отдела
— задачи смежных отделов; возможно разделить по направлениям на 2-3 пункта.
— все остальное
+ должна быть возможность у каждого сотрудника индивиудально скрыть по фильтрам (автор/отдел/ключевые слова) в своих лентах (кроме отдельной ленты «вообще все задачи»).
А какие задачи в итоге решил «завод по добычи золота»?
(и наверно всё-таки по переработке, заводов по добыче не существует).
(и наверно всё-таки по переработке, заводов по добыче не существует).
У них реализация стратегии развития:
1. Фиксация итогов собрания Топ-руководителей. Необходимо зафиксировать некоторые задачи (указать срок выполнения и ответственное лицо или подразделение). Задача не декомпозируется.
2. Зафиксированные задачи необходимо декомпозировать до конкретных действий на отдельных досках в конкретном подразделении (или ответственного лица). На доске руководителей обновлять статусы по задачам перед собраниями.
1. Фиксация итогов собрания Топ-руководителей. Необходимо зафиксировать некоторые задачи (указать срок выполнения и ответственное лицо или подразделение). Задача не декомпозируется.
2. Зафиксированные задачи необходимо декомпозировать до конкретных действий на отдельных досках в конкретном подразделении (или ответственного лица). На доске руководителей обновлять статусы по задачам перед собраниями.
Давно и регулярно ищу новые системы управления проектами и вот внезапно напоролся на YouGile. Выглядит очень интересно… первая мысль была — «ОМГ! Кто-то наконец сделал YouTrack для людей?!»
Первый вопрос — а на чем у вас система написана, если не секрет? Я вижу на сайте коробочную версию, но в краткой инструкции к установке на Linux нет никаких требований — что ей требуется то? Java? Python? Вебсервер у нее я так понимаю встроенный?
Второй вопрос — у YouTrack есть такая проблема, из-за чего мне очень не нравится им пользоваться. Когда спринт подходит к концу, и есть незакрытые (по разным причинам) таски, есть два варианта:
У вас в YouGile уже реализованы зеркала колонок… А есть ли зеркала тасков или что-то подобное? Как-то настроить, чтобы можно было вытащить таск из колонки «не закончено» предыдущего спринта в «из предыдущего спринта» в текущий спринт — и чтобы он в предыдущем тоже сохранился в колонке «не закончено»?
Третий вопрос — есть ли/планируется ли печатный отчет или хотя бы экспорт данных о тасках в спринте? Чтобы можно было инфу о тасках вытащить по отдельным спринтам, и/или по отдельным сотрудникам?
Четвертый вопрос — планируете ли вы дополнить YouGile инструментарием для собственно планирования проекта?
Итеративное планирование это прекрасно и многим подходит, но мы например у себя все чаще используем собственную наработку — обратное планирование. Когда ты жестче завязан на сроки реализации, приходится подходить к дедлайнам ответственно — искать баланс между «успеть вовремя» и «не угробить команду».
Вместе с ТЗ мы пишем концепцию системы и, утвержденная заказчиком, она является конечным ориентиром проекта (на стадии разработки, о развитии проекта и саппорте — отдельный разговор). То есть концепция — это финальное рабочее состояние разрабатываемой системы. И от этого финального состояния мы проектируем назад — отдельные состояния готовности системы, пока не декомпозируем на приемлимого размера компоненты. Получившееся дерево разбивается на временные этапы исходя из общей грубой оценки, а этапы — на спринты. И уже в спринтах идут таски.
Логика работает ровно наоборот, каждую неделю мы не двигаем тасками задачу вперед, а ликвидируем несоответствие текущей сборки — запланированному на этот этап состоянию системы. И когда мы ликвидируем все несоответствия — система сходится с конечным концептом и мы идем сдавать проект.
На мой взгляд это намного выгоднее, поскольку сокращает совещания минимум вполовину. Плюс — люди всегда знают что им нужно делать, а не бегают к тебе и не ждут приказов или осуждений. Люди всегда видят свое участие в общем деле и у них перед глазами общая картина происходящего и непосредственно их вклад в нее.
Однако, пока что мне не удалось ни в одной популярной системе управления поддерживать такой процесс, не сломав себе мозги. Бэклог превращается в кашу и РоадМап не везде есть, а где есть он реализован через жопу. Отчетность в любом случае приходится вести руками параллельно. Даже банально возможности нарисовать блок-схему проекта и связать ее элементы с этапами и спринтами нет — а Диаграмма Ганта, скажем прямо, далеко не всем нужна и удобна.
Давно мучает желание психануть и написать свою систему управления проектами, в которой бы все это было. Но пока что у нас не получается найти на это время и ресурсы. Но возможно раз у вас получилось создать такую, вы тоже думали об этом?
Первый вопрос — а на чем у вас система написана, если не секрет? Я вижу на сайте коробочную версию, но в краткой инструкции к установке на Linux нет никаких требований — что ей требуется то? Java? Python? Вебсервер у нее я так понимаю встроенный?
Второй вопрос — у YouTrack есть такая проблема, из-за чего мне очень не нравится им пользоваться. Когда спринт подходит к концу, и есть незакрытые (по разным причинам) таски, есть два варианта:
- либо переносить таск в следующий спринт… но тогда он исчезает из предыдущего спринта, и вести отчетность по работе подразделения приходится в еще какой-то системе… это дичь.
- либо закрывать таск в текущем спринте и создавать дубликат в следующем, и линковать их (в JIRA такая же дичь)… это тоже идиотизм, потому что часто время таска выползает за спринт по не зависящим от разработчика причинам (например заказчик затянул согласование). И нафига в этой ситуации хранить так со статусом «не сделан»? И получается, что нужно при построении отчетности держать в голове все эти таски. Хотя система управления могла бы и сама показывать что таск перешел в следующий спринт — и это тот же самый таск, что был в предыдущем.
У вас в YouGile уже реализованы зеркала колонок… А есть ли зеркала тасков или что-то подобное? Как-то настроить, чтобы можно было вытащить таск из колонки «не закончено» предыдущего спринта в «из предыдущего спринта» в текущий спринт — и чтобы он в предыдущем тоже сохранился в колонке «не закончено»?
Третий вопрос — есть ли/планируется ли печатный отчет или хотя бы экспорт данных о тасках в спринте? Чтобы можно было инфу о тасках вытащить по отдельным спринтам, и/или по отдельным сотрудникам?
Четвертый вопрос — планируете ли вы дополнить YouGile инструментарием для собственно планирования проекта?
Итеративное планирование это прекрасно и многим подходит, но мы например у себя все чаще используем собственную наработку — обратное планирование. Когда ты жестче завязан на сроки реализации, приходится подходить к дедлайнам ответственно — искать баланс между «успеть вовремя» и «не угробить команду».
Вместе с ТЗ мы пишем концепцию системы и, утвержденная заказчиком, она является конечным ориентиром проекта (на стадии разработки, о развитии проекта и саппорте — отдельный разговор). То есть концепция — это финальное рабочее состояние разрабатываемой системы. И от этого финального состояния мы проектируем назад — отдельные состояния готовности системы, пока не декомпозируем на приемлимого размера компоненты. Получившееся дерево разбивается на временные этапы исходя из общей грубой оценки, а этапы — на спринты. И уже в спринтах идут таски.
Логика работает ровно наоборот, каждую неделю мы не двигаем тасками задачу вперед, а ликвидируем несоответствие текущей сборки — запланированному на этот этап состоянию системы. И когда мы ликвидируем все несоответствия — система сходится с конечным концептом и мы идем сдавать проект.
На мой взгляд это намного выгоднее, поскольку сокращает совещания минимум вполовину. Плюс — люди всегда знают что им нужно делать, а не бегают к тебе и не ждут приказов или осуждений. Люди всегда видят свое участие в общем деле и у них перед глазами общая картина происходящего и непосредственно их вклад в нее.
Однако, пока что мне не удалось ни в одной популярной системе управления поддерживать такой процесс, не сломав себе мозги. Бэклог превращается в кашу и РоадМап не везде есть, а где есть он реализован через жопу. Отчетность в любом случае приходится вести руками параллельно. Даже банально возможности нарисовать блок-схему проекта и связать ее элементы с этапами и спринтами нет — а Диаграмма Ганта, скажем прямо, далеко не всем нужна и удобна.
Давно мучает желание психануть и написать свою систему управления проектами, в которой бы все это было. Но пока что у нас не получается найти на это время и ресурсы. Но возможно раз у вас получилось создать такую, вы тоже думали об этом?
Sign up to leave a comment.
Что нужно, чтобы вся команда работала? Как затянуть всех в систему управления проектами?