Представьте себе, что вы придумали бизнес идею, которая требует год разработки командой из 10 человек (старт начала роста дохода - через 3 месяца) и затем поддержания 3мя. Какой должна быть рентабельность проекта, что бы он вышел на самоокупаемость за 3 года и приносил хорошую ренту (выгоднее ОФЗ) через 5? Реальна ли такая бизнес-идея?
Упустил по мере повествования: началось с того, что локальные KPI тормозили общий прогресс, а в конце что с этими KPI сделали? Они остались те же, но уже не тормозят, или как?
Ну, аналогия с поездом тут натянутая. У начальника поезда и у проводника вагона есть свои полномочия и ответственность. У машиниста - свои. У дежурной по станции и поездного диспетчера - свои. У путевых рабочих и инженеров - другие. Точки их взаимодействия описаны в толстенных инструкциях, и да, там иногда возникают накладки, как в том случае, когда дежурная приказала срочно отправляться, а проводники дёрнули стоп-кран и в поезд влетел потерявший управление состав.
Но у них у всех есть общее начальство. Если оно пожелает изменить проблемные места, то изменит, и никаких ДМ тут не нужно. А если нет, то будь там десять ДМ (если учитывать поездную аналогию, - это некий “заместитель по улучшению процессов/по научной организации труда” некоего наименьшего общего начальника), ничего не сдвинется - как раз потому что у каждого есть свои чётко прописанные обязанности, в т.ч. не только перед инструкцией, но и перед законом.
… А ещё можно в ТЗ просто поставить требование минимизации влияния на водителей (либо прямо так, либо расписать, “оцифровав” с помощью соответствующих метрик).
Если у РП только “свои бригады и задачи”, то это по определению не РП. Основная задача РП - довести конкретный проект до завершения. И у него должна быть возможность, в частности, заменить бригаду “пьющих” на нормальную, иначе, опять же, он никакой не РП.
А Delivery Manager отвечает за то, чтобы стройка в целом не остановилась.
Т.е когда видишь какой-то долгострой с “обманутыми дольщиками”, то это виноват DM, а не тот, кто направил средства “куда-то не туда”, либо начал строительство без надежды на завершение. Здорово, что дома строят пока ещё не по Agile
А если серьёзно, то кейсы интересные, но ещё раз подчёркивают мысль, что необходимость в DM - это следствие провала в каком-то отдельном месте процесса.
По поводу зависимых досок: Да, - это определённый "костыль", который нужен, что бы негибкие системы приспособить для Kanban-метода. Собственно KM идеален (и был создан) для вариативных непонятных процессов, и подразумевается, что у вас могут быть самые необычные средства представления этих процессов. И, самое главное, должно быть легко менять эти процессы, т.к. KM - это про управление изменениями. Поэтому, если бы мы не жили в мире удалёнки, удобнее всего была бы физическая доска.
Непонятно из статьи: откладываем, и заменяем на что?
И по формулировке проблемы вопросы (я так понимаю, про шкафы - это не про материальное производство для которого есть отдельные MES системы, а некоторая метафора для нематериального процесса, отслеживаемого с помощью Канбан Метода):
Чем мешает вариативность процессов? Совсем необязательно проходить по всем колонкам на канбан-доске. И доски для разных видов процессов вполне себе могут быть разными. Часто это при накладывании на популярные IT системы для визуализации кодируется системой зависимых досок. На верхнем уровне у вас доска с эпиками, элементы которых находятся на соответствующих досках.
Подитоживая реплики ряда комментаторов: В вашем описанном кейсе:
Компактный срок в 4 месяца и чётко поставленная цель.
Команда, подобранная без существенных ограничений.
Неудивительно, что Скрам тут бесполезен. Он придуман для больших задач с не конкретной целью (слишком амбициозной или заказчик сам не до конца знает). Для этого проект бъется на спринты, каждый из которых согласуется с заказчиком. Такой компромисс между Time&material и проектами с фиксированной оплатой за результат.
А кроме таких задач, которым подходит Скрам, есть и другие. Например, когда целей много (различные сервисные команды). Для них есть другие системы.
Я лет 10 назад ходил пользовался Pentium 4 с помощью xpra (аналог удаленного доступа) - вполне юзабельно было. Кажется, что это минимальный комп, с которого можно ходить по сайтам web 2.0+
А как при капитализме называется наемный работник, который работает на капиталистов и его погонщиков? Батрак.
С одной стороны, в вашей оценке есть что-то разумное. Но с другой стороны, это кажется существенным передёргиванием. Наподобие как у марксистов: "раз при капитализме эксплуатируют пролетариат, то давайте этот капитализм свергнем до основанья. Так, что в конце останется одна организация. Понадеемся, что она не будет пользоваться своим монопольным положением и не станет капиталистом-суперэксплуататором".
Батраками можно назвать таких работников, которые не имеют высокой квалификации (из-за чего они легко заменяемы другими) и которые, фактически, не имеют выбора: работать на этого работодателя, или нет. Сомневаюсь что IT-шники обладают такими свойствами. Даже джун, выгнанный на мороз из-за некомпетентности и неспособности учиться может пойти на завод, в общепит или в курьеры и получать сравнимую зарплату.
Но за спиной айтишников, которые являются конечными исполнителями, почти всегда стоят люди с плеткой, таймтрекерами, средствами слежения и прочими орудиями
Сложно себе представить более-менее толкового разработчика или девопса, который не сможет уйти из места, где эти механизмы воспринимаются как "плётки". Разумеется, во многих местах есть склонность принимающих решение людей к контролю ради контроля, к соблюдению ритуалов "потому что так принято" и т.д. Но вы же не думаете, что совсем без механизмов контроля (адекватных) более-менее большая организация сможет обойтись?
Когда требуют творческий подход и результат, но за спиной стоит погонщик с плеткой, если это не работа батрака, что тогда?
Это называется "капитализм"
Кстати, не часто такое увидишь, что за спиной сварщика стоит менеджер и каждые 20 минут долбит вопросами "назови процент готовности", пока тот пытается заварить трубу из которой льется дерьмо.
Вот именно в моменты, когда происходит авария, такой микроменеджмент, как раз, часто и случается. А "на заводе" - нет, т.к. производительность сварщика понятна и относительно неизменна во времени и в пространстве, да и "за забором", обычно, есть понятное число сварщиков, которые могут подменить имеющегося, в случае если с тем что-то случится.
А в творческих профессиях производительность неочевидна. "Можно привести лошадь к водопою" (обеспечить печеньки, ДМС и прочее), "но нельзя заставить лошадь пить" (заставить творческого специалиста выдавать результат с понятной и прогнозируемой скоростью)...
К тому же, кто сказал, что возможность влиять на процесс должна быть? Её не было даже у именитых режиссеров. Какие перспективы у главбухов или главинженеров?
Кажется, что у вас неправильные критерии " батрачества". Самое главное - возможность влиять на результат. Если результат не зависит от конкретных ФИО исполнителей, то их можно назвать "батраками".
Небольшие заповедники, разумеется, еще есть (как и табуляторы, насколько я знаю, до недавних пор использовались). Более того, есть вакансии "имитаторов программистов", когда программист должен числиться, и иногда даже имитировать деятельность, а реальный прогресс достигают немногочисленные мастера.
Я как раз пытался развернуть мысль, что в IT больше нет батраков. Максимум, из похожего - подмастерья, но не батраки.
Кроме "главных" всегда были, например, менеджеры по работе с ключевыми клиентами, "рядовые" архитекторы, врачи и т.п. Совершенно не обязательно, что бы была руководящая роль.
Так вот современные сеньоры+ в IT - это такие же "менеджеры по работе с жестянками", от которых в существенной доле зависит успех предприятия.
Представьте себе, что вы придумали бизнес идею, которая требует год разработки командой из 10 человек (старт начала роста дохода - через 3 месяца) и затем поддержания 3мя. Какой должна быть рентабельность проекта, что бы он вышел на самоокупаемость за 3 года и приносил хорошую ренту (выгоднее ОФЗ) через 5? Реальна ли такая бизнес-идея?
Думаю, эти подсчёты дадут ответ на ваш вопрос…
Упустил по мере повествования: началось с того, что локальные KPI тормозили общий прогресс, а в конце что с этими KPI сделали? Они остались те же, но уже не тормозят, или как?
Ну, это не самое плохое решение. Зависит от фирмы и её размеров…
Ну, аналогия с поездом тут натянутая. У начальника поезда и у проводника вагона есть свои полномочия и ответственность. У машиниста - свои. У дежурной по станции и поездного диспетчера - свои. У путевых рабочих и инженеров - другие. Точки их взаимодействия описаны в толстенных инструкциях, и да, там иногда возникают накладки, как в том случае, когда дежурная приказала срочно отправляться, а проводники дёрнули стоп-кран и в поезд влетел потерявший управление состав.
Но у них у всех есть общее начальство. Если оно пожелает изменить проблемные места, то изменит, и никаких ДМ тут не нужно. А если нет, то будь там десять ДМ (если учитывать поездную аналогию, - это некий “заместитель по улучшению процессов/по научной организации труда” некоего наименьшего общего начальника), ничего не сдвинется - как раз потому что у каждого есть свои чётко прописанные обязанности, в т.ч. не только перед инструкцией, но и перед законом.
… А ещё можно в ТЗ просто поставить требование минимизации влияния на водителей (либо прямо так, либо расписать, “оцифровав” с помощью соответствующих метрик).
Если у РП только “свои бригады и задачи”, то это по определению не РП. Основная задача РП - довести конкретный проект до завершения. И у него должна быть возможность, в частности, заменить бригаду “пьющих” на нормальную, иначе, опять же, он никакой не РП.
Т.е когда видишь какой-то долгострой с “обманутыми дольщиками”, то это виноват DM, а не тот, кто направил средства “куда-то не туда”, либо начал строительство без надежды на завершение. Здорово, что дома строят пока ещё не по Agile
А если серьёзно, то кейсы интересные, но ещё раз подчёркивают мысль, что необходимость в DM - это следствие провала в каком-то отдельном месте процесса.
Давным давно придуманы механизмы подтверждения значимых действий несколькими разными сотрудниками.
Было бы желание эти меры внедрять
А ФСП - это что за организация? Это же не про ФССП?
Можно ли с использованием 152-фз привлечь обзвонщиков? Считается ли набор номера использованием ПДн? Кто в этом случае оператор, как его найти?
По поводу зависимых досок: Да, - это определённый "костыль", который нужен, что бы негибкие системы приспособить для Kanban-метода. Собственно KM идеален (и был создан) для вариативных непонятных процессов, и подразумевается, что у вас могут быть самые необычные средства представления этих процессов. И, самое главное, должно быть легко менять эти процессы, т.к. KM - это про управление изменениями. Поэтому, если бы мы не жили в мире удалёнки, удобнее всего была бы физическая доска.
Непонятно из статьи: откладываем, и заменяем на что?
И по формулировке проблемы вопросы (я так понимаю, про шкафы - это не про материальное производство для которого есть отдельные MES системы, а некоторая метафора для нематериального процесса, отслеживаемого с помощью Канбан Метода):
Чем мешает вариативность процессов? Совсем необязательно проходить по всем колонкам на канбан-доске.
И доски для разных видов процессов вполне себе могут быть разными. Часто это при накладывании на популярные IT системы для визуализации кодируется системой зависимых досок. На верхнем уровне у вас доска с эпиками, элементы которых находятся на соответствующих досках.
При отсутствии знании физики мир кажется основанным на магии. Изучать на предмет "расстояние между атомами", опыт Резерфорда и т.п.
Обычный дозиметр на Бета1-1 ловит в среднем 2-3 всплеска в месяц.
Но вы же не можете пользоваться ЦР без банка. Тогда в чем же разница?
Отличная статья. Ещё бы статью "что такое цифровой рубль и как, вообще, им можно пользоваться?", а то непонятен смысл этой чуть менее, чем совсем.
Подитоживая реплики ряда комментаторов: В вашем описанном кейсе:
Компактный срок в 4 месяца и чётко поставленная цель.
Команда, подобранная без существенных ограничений.
Неудивительно, что Скрам тут бесполезен. Он придуман для больших задач с не конкретной целью (слишком амбициозной или заказчик сам не до конца знает). Для этого проект бъется на спринты, каждый из которых согласуется с заказчиком. Такой компромисс между Time&material и проектами с фиксированной оплатой за результат.
А кроме таких задач, которым подходит Скрам, есть и другие. Например, когда целей много (различные сервисные команды). Для них есть другие системы.
Я лет 10 назад ходил пользовался Pentium 4 с помощью xpra (аналог удаленного доступа) - вполне юзабельно было. Кажется, что это минимальный комп, с которого можно ходить по сайтам web 2.0+
С одной стороны, в вашей оценке есть что-то разумное. Но с другой стороны, это кажется существенным передёргиванием. Наподобие как у марксистов: "раз при капитализме эксплуатируют пролетариат, то давайте этот капитализм свергнем до основанья. Так, что в конце останется одна организация. Понадеемся, что она не будет пользоваться своим монопольным положением и не станет капиталистом-суперэксплуататором".
Батраками можно назвать таких работников, которые не имеют высокой квалификации (из-за чего они легко заменяемы другими) и которые, фактически, не имеют выбора: работать на этого работодателя, или нет. Сомневаюсь что IT-шники обладают такими свойствами. Даже джун, выгнанный на мороз из-за некомпетентности и неспособности учиться может пойти на завод, в общепит или в курьеры и получать сравнимую зарплату.
Сложно себе представить более-менее толкового разработчика или девопса, который не сможет уйти из места, где эти механизмы воспринимаются как "плётки". Разумеется, во многих местах есть склонность принимающих решение людей к контролю ради контроля, к соблюдению ритуалов "потому что так принято" и т.д. Но вы же не думаете, что совсем без механизмов контроля (адекватных) более-менее большая организация сможет обойтись?
Это называется "капитализм"
Вот именно в моменты, когда происходит авария, такой микроменеджмент, как раз, часто и случается. А "на заводе" - нет, т.к. производительность сварщика понятна и относительно неизменна во времени и в пространстве, да и "за забором", обычно, есть понятное число сварщиков, которые могут подменить имеющегося, в случае если с тем что-то случится.
А в творческих профессиях производительность неочевидна. "Можно привести лошадь к водопою" (обеспечить печеньки, ДМС и прочее), "но нельзя заставить лошадь пить" (заставить творческого специалиста выдавать результат с понятной и прогнозируемой скоростью)...
Может, с прошлой работы вы "выросли"?
К тому же, кто сказал, что возможность влиять на процесс должна быть? Её не было даже у именитых режиссеров. Какие перспективы у главбухов или главинженеров?
Кажется, что у вас неправильные критерии " батрачества". Самое главное - возможность влиять на результат. Если результат не зависит от конкретных ФИО исполнителей, то их можно назвать "батраками".
Небольшие заповедники, разумеется, еще есть (как и табуляторы, насколько я знаю, до недавних пор использовались). Более того, есть вакансии "имитаторов программистов", когда программист должен числиться, и иногда даже имитировать деятельность, а реальный прогресс достигают немногочисленные мастера.
Я как раз пытался развернуть мысль, что в IT больше нет батраков. Максимум, из похожего - подмастерья, но не батраки.
Кроме "главных" всегда были, например, менеджеры по работе с ключевыми клиентами, "рядовые" архитекторы, врачи и т.п. Совершенно не обязательно, что бы была руководящая роль.
Так вот современные сеньоры+ в IT - это такие же "менеджеры по работе с жестянками", от которых в существенной доле зависит успех предприятия.