Отчасти согласен, всему всегда должен быть предел. Тут же больше речь про то, что сотрудник не должен тратить время на поиск того, к кому бежать, в кого кидать документ и тд.
Да, тоже верно. Это вообще задача непосредственного руководителя, а также его руководителя по развитию, если это разные роли в компании - развивать сотрудника, искать новые точки мотивации, чтобы он и не выгорал, и больше приносил пользы + получал соответствующие компенсации и признание
На самом деле, если коллеги, сотрудники компании открыты на диалоги и всегда готовы помочь или навести на нужный справочник для самостоятельного изучения - это огромный плюс. Поэтому задавать вопросы, уточнять - это нормально.
В моей компании один из ключевых принципов - это уважение к сотрудникам и постоянное развитие. В такой среде как раз сложные задачи тоже могут выполняться проще ввиду хорошей профессиональной поддержки вокруг.
На самом деле все возможно правильно вы и делали. Может подходили более гибко к процессу и забирали задачи не исходя из установленной последовательности, а на основе приоритета, возможно личного, что тоже неплохо. Для новых задач, особенно с размытой формой конечного результата - можно пробовать какие-то важные контрольные точки лишь определять. Их может быть всего 3-4, а подзадачек потом родится намного больше. Так как практики по таким задачам еще нет, то конечно чек-лист полный составить сложнее.
Полностью безиерархических организаций почти не существует, разве что это стартап какой-нибудь наверно, где все на чистом энтузиазме строится.
Я могу привести пример своей компании.
У сотрудника есть вертикальный руководитель в организационной структуре, при этом есть еще производственная структура, в которой он входит в кросс-функциональную команду с тимлидом, а за его профессиональное развитие и денежную мотивацию отвечает ресурс-менеджер.
То есть поверх классической иерархии появляется отдельный слой производственного и командного взаимодействия. Это позволяет сохранить управляемость компании, но при этом не замыкать все решения исключительно на вертикали власти.
И как раз в таких моделях сильные специалисты обычно чувствуют себя значительно эффективнее, чем в системах с жестким административным контролем. Специалист может развиваться как вертикально по иерархии орг. структуры, а также горизонтально, в рамках своих текущих обязанностей и компетенций в производственной команде.
В статье я как раз пытался показать не столько саму концепцию (она действительно известна), а скорее как её можно применить внутри корпоративной системы управления задачами, чтобы это работало не на уровне личного тайм-менеджмента, а на уровне команд и подразделений.
Согласен, по сути это и есть инструмент личного тайм-менеджмента. В этом и был смысл статьи :)
Проблемы начинаются, когда такую логику пытаются перенести на уровень компании, где важность задач задаёт не исполнитель, а стратегия и приоритеты бизнеса. Кстати, вариант 3×3 со сложностью довольно практичная адаптация: работает отлично при декомпозиции задач
Но суть статьи не в этом. Мы уже заочно предполагаем, что в компании понимают, как оценивать "важность" и какие критерии в нее закладывать. Вопрос же в другом -
В компании сотрудник почти никогда не определяет важность задач. Её формируют стратегия, портфель инициатив и ограниченность в ресурсах и тд.
А до исполнителя обычно доходит только, что это надо сделать срочно, и грубо говоря, кто громче ему об этом крикнет, того и шапка.
Доска в системе визуализирует поток и ограничения (WIP, узкие места, накопления), но не навязывает способ передачи работы. Вообще, вы правы, именно поэтому доски называются Agile, потому что Канбан при разработке не учитывался как догма и что-то обязательное.
При этом pull-логика в системе реализуется не только и не столько структурой колонок, сколько правилами работы, статусами, уведомлениями, ограничениями и ответственностью ролей. Готовность задачи фиксируется явно, следующий этап видит её в контексте своей загрузки и принимает в работу осознанно, а не автоматически. Такой подход позволяет использовать доски и в продуктовой разработке, и в проектной среде, и в корпоративных функциях, например в организации работы подразделения. Приходите к нам, расскажем и покажем разные сценарии использования 😊
Я думаю, что можно, конечно, каждый день героически побеждать себя и бить палкой в грудь. Но обычно дешевле обходится один раз починить вход в задачу.
Представим обычный ПК, который перегружен фоновыми процессами, оперативки не хватает категорически, но мы же не нагружаем его еще новыми задачами и не устанавливаем все больше ПО. Наоборот - стараемся оптимизировать. Подчистить что-то, что уже точно неактуально. Запускать не разом все, а какую-то системность выстроить и тд. Это мое мнение
Да, я тут спорить не буду. Ваш подход просто наиболее зрелый, и это очень хорошо. Моей же задачей было поделиться больше общими практиками, которые используют в знакомых мне компаниях, уровень зрелости в которых самый разный.
То, что человек физически делает одну активную задачу — согласен. Но WIP в канбане управляет потоком, а не только фокусом конкретного человека. Поэтому лимиты вешают и на людей, и на колонки, и на роли — в зависимости от контекста и узких мест системы (об этом прямо пишет Андерсон, на которого я прежде всего и ссылался).
Модель «1 активная + 1 ожидающая» = WIP 2 — это как раз практический компромисс, чтобы поток не умирал на блокерах. «Бассейн с дорожками» — рабочий паттерн, но не универсальный: плохо масштабируется и не всегда подходит командам с общими очередями и зависимостями.
Теперь масштабировать строительство и ремонт дач, брать систему для комплексного планирования и управления проектами и в путь )
Отчасти согласен, всему всегда должен быть предел. Тут же больше речь про то, что сотрудник не должен тратить время на поиск того, к кому бежать, в кого кидать документ и тд.
Да, тоже верно. Это вообще задача непосредственного руководителя, а также его руководителя по развитию, если это разные роли в компании - развивать сотрудника, искать новые точки мотивации, чтобы он и не выгорал, и больше приносил пользы + получал соответствующие компенсации и признание
На самом деле, если коллеги, сотрудники компании открыты на диалоги и всегда готовы помочь или навести на нужный справочник для самостоятельного изучения - это огромный плюс. Поэтому задавать вопросы, уточнять - это нормально.
В моей компании один из ключевых принципов - это уважение к сотрудникам и постоянное развитие. В такой среде как раз сложные задачи тоже могут выполняться проще ввиду хорошей профессиональной поддержки вокруг.
На самом деле все возможно правильно вы и делали. Может подходили более гибко к процессу и забирали задачи не исходя из установленной последовательности, а на основе приоритета, возможно личного, что тоже неплохо. Для новых задач, особенно с размытой формой конечного результата - можно пробовать какие-то важные контрольные точки лишь определять. Их может быть всего 3-4, а подзадачек потом родится намного больше. Так как практики по таким задачам еще нет, то конечно чек-лист полный составить сложнее.
Спасибо, тоже добавлю себе в копилку :)
Полностью безиерархических организаций почти не существует, разве что это стартап какой-нибудь наверно, где все на чистом энтузиазме строится.
Я могу привести пример своей компании.
У сотрудника есть вертикальный руководитель в организационной структуре, при этом есть еще производственная структура, в которой он входит в кросс-функциональную команду с тимлидом, а за его профессиональное развитие и денежную мотивацию отвечает ресурс-менеджер.
То есть поверх классической иерархии появляется отдельный слой производственного и командного взаимодействия. Это позволяет сохранить управляемость компании, но при этом не замыкать все решения исключительно на вертикали власти.
И как раз в таких моделях сильные специалисты обычно чувствуют себя значительно эффективнее, чем в системах с жестким административным контролем. Специалист может развиваться как вертикально по иерархии орг. структуры, а также горизонтально, в рамках своих текущих обязанностей и компетенций в производственной команде.
Если бы всё было так просто, то руководить подразделением или проектом было скучно :)
В статье я как раз пытался показать не столько саму концепцию (она действительно известна), а скорее как её можно применить внутри корпоративной системы управления задачами, чтобы это работало не на уровне личного тайм-менеджмента, а на уровне команд и подразделений.
Согласен, по сути это и есть инструмент личного тайм-менеджмента. В этом и был смысл статьи :)
Проблемы начинаются, когда такую логику пытаются перенести на уровень компании, где важность задач задаёт не исполнитель, а стратегия и приоритеты бизнеса. Кстати, вариант 3×3 со сложностью довольно практичная адаптация: работает отлично при декомпозиции задач
Что земля имеет форму шара - это все понятно)
Но суть статьи не в этом. Мы уже заочно предполагаем, что в компании понимают, как оценивать "важность" и какие критерии в нее закладывать. Вопрос же в другом -
В компании сотрудник почти никогда не определяет важность задач. Её формируют стратегия, портфель инициатив и ограниченность в ресурсах и тд.
А до исполнителя обычно доходит только, что это надо сделать срочно, и грубо говоря, кто громче ему об этом крикнет, того и шапка.
Доска в системе визуализирует поток и ограничения (WIP, узкие места, накопления), но не навязывает способ передачи работы. Вообще, вы правы, именно поэтому доски называются Agile, потому что Канбан при разработке не учитывался как догма и что-то обязательное.
При этом pull-логика в системе реализуется не только и не столько структурой колонок, сколько правилами работы, статусами, уведомлениями, ограничениями и ответственностью ролей. Готовность задачи фиксируется явно, следующий этап видит её в контексте своей загрузки и принимает в работу осознанно, а не автоматически. Такой подход позволяет использовать доски и в продуктовой разработке, и в проектной среде, и в корпоративных функциях, например в организации работы подразделения. Приходите к нам, расскажем и покажем разные сценарии использования 😊
Я думаю, что можно, конечно, каждый день героически побеждать себя и бить палкой в грудь. Но обычно дешевле обходится один раз починить вход в задачу.
Представим обычный ПК, который перегружен фоновыми процессами, оперативки не хватает категорически, но мы же не нагружаем его еще новыми задачами и не устанавливаем все больше ПО. Наоборот - стараемся оптимизировать. Подчистить что-то, что уже точно неактуально. Запускать не разом все, а какую-то системность выстроить и тд. Это мое мнение
😂😂😂
Да, я тут спорить не буду. Ваш подход просто наиболее зрелый, и это очень хорошо. Моей же задачей было поделиться больше общими практиками, которые используют в знакомых мне компаниях, уровень зрелости в которых самый разный.
То, что человек физически делает одну активную задачу — согласен. Но WIP в канбане управляет потоком, а не только фокусом конкретного человека. Поэтому лимиты вешают и на людей, и на колонки, и на роли — в зависимости от контекста и узких мест системы (об этом прямо пишет Андерсон, на которого я прежде всего и ссылался).
Модель «1 активная + 1 ожидающая» = WIP 2 — это как раз практический компромисс, чтобы поток не умирал на блокерах.
«Бассейн с дорожками» — рабочий паттерн, но не универсальный: плохо масштабируется и не всегда подходит командам с общими очередями и зависимостями.