Разработчиков всегда будет не хватать. И можно нанимать их пока есть бюджеты, но вы никуда не денетесь от того, что при найме каждого следующего - вы будете терять в производительности из-за перестроения социальных связей. И по мере разрастания команды у вас будет множиться хаос. Гораздо разумней выстроить уже систему работы и дальше расшивать узкие звенья. А они в системе будут всегда и чаще всего это как раз производственные подразделения - разработка.
А еще держите в голове, что если у вас технология/язык программирования такой, что таких людей 3% в рынке, то у вас шансы нанимать сильно сокращаются. Конкретно в данном кейсе нанимают с привлечением разных агенств по 1 разработчику в год. И так происходит не из-за ограничений, просто в рынке мало таких компетенций.
Бизнесу всегда надо искать варианты максимизации своей ценности и в данной ситуации сработал такой подход.
Упоминается конечно же он, и на его основе принимается дальше решение о понятности задачи. Но не было цели разбирать именно киневин, так бы пришлось делать целую вставку. Скорее важно отразить подход к задачам. Убрав часть про Киневин принципиально подход сильно не пострадает
Приветствую. Конечно вы абсолютно правы, что в жизни задачи появляются по мере того как ты двигаешься. Тут скорее для примера приведены графики и возможны в ситуации "Идеального проекта", когда задачи четко продуманы наперед.
Мы живем в kaiten.io - российский продукт. С точки зрения визуализации процессов в разы лучше Jira. Очень круто поддерживает Канбан метод и его практики. Недавно они запилили свой инструменты работы с документами внутри, пока конечно слабовато, но уже хоть какая-то замена confluence.
это вопрос именно конкретного дизайна Канбан доски. И тут можно делать по разному. Не существует единственно верного ответа. Но есть несколько хороших практик.
1. Нужно стремиться к небольшому количеству колонок. Из-за того, что при их увеличении будет вырастать время производство. Одна и та же задача при 5 колонках будет делаться дольше, чем при 3х. Это связано с тем, что может увеличить количество незавершенной работы и с тем что фокус внимания команды размываться будет.
2. Текущий дизайн доски не статичен, он всегда должен решать какую-то проблему процесса. Чтобы подойдя к доске вы видели, где есть проблема.
Исходя из этого можно делать и отдельной колонкой и ставить на нее лимит, когда борода задач начнет расти. А можно вешать блокировку, которая порождает зависимость с задачей другой команды. Это и есть этим аттрибутом.
Можете пояснить получен ли ответ? или стоит еще что-то разобрать?
Добрый день! А им не нужно верить. Это же модель. Тут самое главное, это логика расчета. Берете ее и пытаетесь применять своей компании/проекту/отделу. И у вас вырисовываются свои цифры. А дальше смотрите уже на них и думаете на сколько они красивы.
Можно я вначале уточню, а потом дам комментарий. Расскажите пожалуйста процедуру как у вас оооп и Scrum? Какая последовательность действий. Например я руководитель отдела разработки в небольшой компании (100 человек) и руковожу всей разработкой.
Абсолютно согласен, в том что контекст проекта имеет очень большое значение.
В вашей ситуации когда вы разработчик и совмещаете PO уже очень не простая ситуация. Тут не про подходы даже речь. А про то что, удивительно как вам сейчас хватает времени кодить и выполнять непростые задачи PO.
Канбан метод, это совсем не про Agile. И это очень частое заблуждение. Канбан не требует введения новых ролей (таких как Scrum master, Product Owner, RTE ....). Чем больше компания, тем больше управленцев и координирующих деятельность ролей — те, которые занимаются стыковкой между подразделениями и людьми. Пруфа нет, но давайте посчитаем на пальцах. Если мы используем Scrum, то у нас на 9 человек команды разработки нужно как минимум 2 дополнительные роли. Допустим что на 2 команды 2 человека совмещают эти роли. У нас например 50 команд. Значит что 25 новых человек, которых чаще всего в компании нет нужно нанять. С ростом количества команд так же возникают директора по направлениями, тимлиды, руководители технологий определенных и так далее. Вот и происходит рост менеджмента.
Используя Канбан, вам не требуется нанимать людей в новые роли — вы прокачиваете менеджерские скилы у имеющихся руководителей. Так же вы не ограничены ограничением в 9 человек, потому что вы управляете потоком рабочих элементов, для упрощения назовем их задачами. Через применения инструментов и практик вы получаете короткие каденции для синхронихации, предсказуемую поставку этих задач и увеличение количества выпускаемых задач в единицу времени. Это вполне конкретные цифры, которые можно считать. Каждая задача несет некоторый доход.
Давайте будем сравнивать подходы тогда. Хотя этого хотелось бы избежать.
Например Scrum, LeSS, SAFE нельзя у себя запустить без перестроения орг структуры компании. Обычно запуски этих подходов всегда характеризуются так называемым «Flip», когда вы после некоторых активностей в понедельник начинаете жить по другому. У вас появляются новые роли, новые активности, новые системы координат. По большому счету вы должны забыть о том что было вчера и начать жить с нового листа веря в светлое будующее.
Очень часто за такими событиями начинается волна сопротивления людей и куча статей и материалов описывает как надо бороться и переживать это сопротивление.
Канбан идет эволюционным путем. Что качественно отличается. Он не требует «Flip» и ярко показывает — не меняйте текущую систему ролей и не вводите новые активности.
Для начала стоит сказать, что это лишь первая статья серии. Попробую выжимку сухую из статьи дать в нескольких предложениях. Ответ есть, но может быть немного размазан по тексту.
Экономический плюс в том, что вы экономите на менеджменте и количестве координационных затрат. И чем больше у вас компания, тем больше эти суммы. Второй пласт доходов заключается в более быстрой скорости возврата инвестиций — выгода начинает накапливаться и расти быстрее.
Обычно при применении любых подходов, такое сравнение компаний не корректно. Потому что они могут расти вопреки применения каких либо методов. Яркое отличие Канбан от трансформационных моделей, как раз в том, что не возникает пропасть потери производительности и всегда можно откатиться назад.
Разработчиков всегда будет не хватать. И можно нанимать их пока есть бюджеты, но вы никуда не денетесь от того, что при найме каждого следующего - вы будете терять в производительности из-за перестроения социальных связей. И по мере разрастания команды у вас будет множиться хаос. Гораздо разумней выстроить уже систему работы и дальше расшивать узкие звенья. А они в системе будут всегда и чаще всего это как раз производственные подразделения - разработка.
А еще держите в голове, что если у вас технология/язык программирования такой, что таких людей 3% в рынке, то у вас шансы нанимать сильно сокращаются. Конкретно в данном кейсе нанимают с привлечением разных агенств по 1 разработчику в год. И так происходит не из-за ограничений, просто в рынке мало таких компетенций.
Бизнесу всегда надо искать варианты максимизации своей ценности и в данной ситуации сработал такой подход.
Упоминается конечно же он, и на его основе принимается дальше решение о понятности задачи. Но не было цели разбирать именно киневин, так бы пришлось делать целую вставку. Скорее важно отразить подход к задачам. Убрав часть про Киневин принципиально подход сильно не пострадает
Приветствую. Конечно вы абсолютно правы, что в жизни задачи появляются по мере того как ты двигаешься. Тут скорее для примера приведены графики и возможны в ситуации "Идеального проекта", когда задачи четко продуманы наперед.
Мы живем в kaiten.io - российский продукт. С точки зрения визуализации процессов в разы лучше Jira. Очень круто поддерживает Канбан метод и его практики. Недавно они запилили свой инструменты работы с документами внутри, пока конечно слабовато, но уже хоть какая-то замена confluence.
1. Нужно стремиться к небольшому количеству колонок. Из-за того, что при их увеличении будет вырастать время производство. Одна и та же задача при 5 колонках будет делаться дольше, чем при 3х. Это связано с тем, что может увеличить количество незавершенной работы и с тем что фокус внимания команды размываться будет.
2. Текущий дизайн доски не статичен, он всегда должен решать какую-то проблему процесса. Чтобы подойдя к доске вы видели, где есть проблема.
Исходя из этого можно делать и отдельной колонкой и ставить на нее лимит, когда борода задач начнет расти. А можно вешать блокировку, которая порождает зависимость с задачей другой команды. Это и есть этим аттрибутом.
Можете пояснить получен ли ответ? или стоит еще что-то разобрать?
А Канбан метод я наблюдал как дает очень хороший результат на группе из 40 человек. Тем самым не возникает необходимости вводить новые роли.
В вашей ситуации когда вы разработчик и совмещаете PO уже очень не простая ситуация. Тут не про подходы даже речь. А про то что, удивительно как вам сейчас хватает времени кодить и выполнять непростые задачи PO.
Используя Канбан, вам не требуется нанимать людей в новые роли — вы прокачиваете менеджерские скилы у имеющихся руководителей. Так же вы не ограничены ограничением в 9 человек, потому что вы управляете потоком рабочих элементов, для упрощения назовем их задачами. Через применения инструментов и практик вы получаете короткие каденции для синхронихации, предсказуемую поставку этих задач и увеличение количества выпускаемых задач в единицу времени. Это вполне конкретные цифры, которые можно считать. Каждая задача несет некоторый доход.
Например Scrum, LeSS, SAFE нельзя у себя запустить без перестроения орг структуры компании. Обычно запуски этих подходов всегда характеризуются так называемым «Flip», когда вы после некоторых активностей в понедельник начинаете жить по другому. У вас появляются новые роли, новые активности, новые системы координат. По большому счету вы должны забыть о том что было вчера и начать жить с нового листа веря в светлое будующее.
Очень часто за такими событиями начинается волна сопротивления людей и куча статей и материалов описывает как надо бороться и переживать это сопротивление.
Канбан идет эволюционным путем. Что качественно отличается. Он не требует «Flip» и ярко показывает — не меняйте текущую систему ролей и не вводите новые активности.
В этом самое главное отличие.
Экономический плюс в том, что вы экономите на менеджменте и количестве координационных затрат. И чем больше у вас компания, тем больше эти суммы. Второй пласт доходов заключается в более быстрой скорости возврата инвестиций — выгода начинает накапливаться и расти быстрее.