🤝 Как Agile может усилить бережливое производство
Если вам близки идеи Agile, то вам может быть интересна концепция бережливого производства (Lean Production). Они идут рука об руку, но у них немного разный компас.
Обе эти философии отлично дополняют друг друга и преследуют несколько общих целей: снижение издержек, ускорение принятия решений и повышение конкурентоспособности компании на рынке.
Но каждая из них делает это по-своему
🔸 Lean помогает избежать ненужного, а Agile — создавать нужное.
🔸 Lean — совершенствует существующие процессы, а Agile — помогает управлять ими в быстро меняющихся условиях.
🔸 Lean хорошо работает при стабильном спросе, а Agile, — когда рынок пересатёт быть предсказуемым.
🔸 Lean ориентирован на производство, Agile — на людей.
На одном из недавних тренингов участники разбирали задание, связанное с моделью Кеневин для анализа проблем. И во время обсуждения один из них, руководитель высшего звена на производстве, поделился своим мнением:
Это интересная мысль. У Agile есть преимущество, которое хорошо дополняет Lean Production, — гибкость в условиях перемен.
Когда рыночная ситуация меняется, именно Agile-практики, например Scrum, позволяют быстро адаптироваться за счет коротких итераций с частыми релизами и регулярному вовлечению руководства в проект.
Кроме того, Agile дает командам больше самостоятельности. В гибких организациях сотрудники самим принимают решения, расставляют приоритеты и организуют свою работу, опираясь на задачи в бэклоге.
Если вам близки идеи Agile, то вам может быть интересна концепция бережливого производства (Lean Production). Они идут рука об руку, но у них немного разный компас.
Обе эти философии отлично дополняют друг друга и преследуют несколько общих целей: снижение издержек, ускорение принятия решений и повышение конкурентоспособности компании на рынке.
Но каждая из них делает это по-своему
🔸 Lean помогает избежать ненужного, а Agile — создавать нужное.
🔸 Lean — совершенствует существующие процессы, а Agile — помогает управлять ими в быстро меняющихся условиях.
🔸 Lean хорошо работает при стабильном спросе, а Agile, — когда рынок пересатёт быть предсказуемым.
🔸 Lean ориентирован на производство, Agile — на людей.
На одном из недавних тренингов участники разбирали задание, связанное с моделью Кеневин для анализа проблем. И во время обсуждения один из них, руководитель высшего звена на производстве, поделился своим мнением:
Пока чёткие процедуры не будут отработнаны, компания всегда будет попадать в хаотичную среду. Это во многом перекликается с тем, что мы уже внедрили в рамках бережливого производства, только в контексте бизнес-процессов.
Это интересная мысль. У Agile есть преимущество, которое хорошо дополняет Lean Production, — гибкость в условиях перемен.
Когда рыночная ситуация меняется, именно Agile-практики, например Scrum, позволяют быстро адаптироваться за счет коротких итераций с частыми релизами и регулярному вовлечению руководства в проект.
Кроме того, Agile дает командам больше самостоятельности. В гибких организациях сотрудники самим принимают решения, расставляют приоритеты и организуют свою работу, опираясь на задачи в бэклоге.
🔥5👍2😁2
На прошедшем вебинаре мы говорили об основных ошибках при внедрении фреймворков SAFe, LeSS и Flight Levels. Один из участников задал нам интересный вопрос:
Прежде чем выбрать один фреймворк, хочется как бы повертеть его в руках, будто это деталь, и посмотреть, как она соединится с ситуацией. Но стоит применить его — и что-то не стыкуется. Ведь у каждой компании своя специфика и контексты.
Вначале было бы полезно разобраться в механике — как именно тот или иной подход повлияет на организацию или на отдельные подразделения. Понять, к чему приведут эти изменения и соответствуют ли они ожиданиям. А уже после этого переходить к характеристикам и тонкостям каждого фреймворка.
На карточках мы разобрали, какие изменения происходят в организации при внедрении разных масштабируемых фреймворков. А ещё недавно у нас в блоге вышла статья, где мы детально разобрали каждый из них.
— Я поймал себя на мысли, что, возможно, не до конца понимаю разницу между SAFe, LeSS и Flight Levels. Мы обсуждаем ошибки, связанные с фреймворками, но мне кажется, что сначала нужно чётко понимать различия между ними.
В моей практике я работаю с четырьмя командами и уже адаптировал процессы так, что у нас нет серьёзных сложностей. Есть синхронизация, оптимизированные затраты на встречи, ритуалы занимают не более 10 часов за двухнедельный спринт — считаю это оптимальным.
Но было бы гораздо проще обсуждать ошибки и улучшения, если бы существовал некий наглядный материал, который помог бы чётко понять разницу между этими фреймворками. Тогда логично было бы двигаться дальше — к разбору ошибок и их влиянию на работу команд.
Прежде чем выбрать один фреймворк, хочется как бы повертеть его в руках, будто это деталь, и посмотреть, как она соединится с ситуацией. Но стоит применить его — и что-то не стыкуется. Ведь у каждой компании своя специфика и контексты.
Вначале было бы полезно разобраться в механике — как именно тот или иной подход повлияет на организацию или на отдельные подразделения. Понять, к чему приведут эти изменения и соответствуют ли они ожиданиям. А уже после этого переходить к характеристикам и тонкостям каждого фреймворка.
На карточках мы разобрали, какие изменения происходят в организации при внедрении разных масштабируемых фреймворков. А ещё недавно у нас в блоге вышла статья, где мы детально разобрали каждый из них.
👍3🔥1
🗣 История нашего клиента
Недавно мы поделились кейсом применения Scrum в аппаратной разработке, где в том числе организовали открытый спринт-ревью для всех сотрудников. Другой наш клиент, прочитав кейс, вспомнил свой опыт и решил поделиться:
Давайте разберёмся
Показать итог работы за короткий промежуток времени на широкую аудиторию — это довольно ответственный шаг. Многим, кто привык к традиционному управлению проектами, может казаться, что частые встречи только мешают работе и тормозят процессы.
Но такая ситуация рано или поздно может произойти с теми, кто решился на перемены. Любые изменения переживают фазу сопротивлений, поэтому важно, чтобы в них участвовали только те, кому это искренне интересно, без принуждений.
Можно постараться вовлечь всех участников. Например, добавить больше вопросов к аудитории, обсуждений и живого диалога. Но главное — подготовить получившийся инкремент продукта и результаты гипотез, а не слайды в PowerPoint. Так встреча станет продуктивней и пройдёт с опорой на результат.
Обсудив это с клиентом, мы получили ответ:
Недавно мы поделились кейсом применения Scrum в аппаратной разработке, где в том числе организовали открытый спринт-ревью для всех сотрудников. Другой наш клиент, прочитав кейс, вспомнил свой опыт и решил поделиться:
Мы тоже недавно провели открытый спринт-ревью — результат неоднозначный. Не всем зашло, не все готовы тратить на это время.
Давайте разберёмся
Показать итог работы за короткий промежуток времени на широкую аудиторию — это довольно ответственный шаг. Многим, кто привык к традиционному управлению проектами, может казаться, что частые встречи только мешают работе и тормозят процессы.
Но такая ситуация рано или поздно может произойти с теми, кто решился на перемены. Любые изменения переживают фазу сопротивлений, поэтому важно, чтобы в них участвовали только те, кому это искренне интересно, без принуждений.
Можно постараться вовлечь всех участников. Например, добавить больше вопросов к аудитории, обсуждений и живого диалога. Но главное — подготовить получившийся инкремент продукта и результаты гипотез, а не слайды в PowerPoint. Так встреча станет продуктивней и пройдёт с опорой на результат.
Обсудив это с клиентом, мы получили ответ:
Мы решили продолжить проводить открытые спринт-ревью — нужно время, чтобы осознать ценность. Сворачивать с этого пути не планируем!
👍3🔥1
💭 Тупик в груминге
Представьте, что команда разработчиков собралась на еженедельный груминг и видит на экране список новых задач.
Владелец продукта открывает первую:
Если описания задач будут сформулированы в общих чертах и лишены деталей, то время, отведенное на груминг уйдет не на оценку задач, а на попытки выяснить, что же они значат.
Если в этот момент ни один участник встречи не выскажется, то обсуждение первой задачи может затянуться на 30-40 минут. И только ближе к концу окажется, что её вообще не планировали брать в ближайший спринт.
Может случиться так, что кто-то уткнется в телефон, а фасилитатор не сможет вернуть фокус, и команда окончательно выпадет из процесса. По окончанию груминга у всех останется лишь ощущение впустую потраченного времени, а это может и вовсе демотивировать команду ходить на встречи.
Ответа нет.
Как не потратить время на груминге впустую и решить перечисленные проблемы? Ответили на карточках.
Бывали ли у вас такие ситуации, и как вы с ними справились? Поделитесь в комментариях.
Представьте, что команда разработчиков собралась на еженедельный груминг и видит на экране список новых задач.
Владелец продукта открывает первую:
— «Реализовать улучшение UI перевода между счетами».
— А что конкретно нужно улучшить?
— Ну, чтобы было удобнее. Заказчики говорят, что интерфесн не понятный.
Если описания задач будут сформулированы в общих чертах и лишены деталей, то время, отведенное на груминг уйдет не на оценку задач, а на попытки выяснить, что же они значат.
— Какие у нас приоритетные задачи?
Если в этот момент ни один участник встречи не выскажется, то обсуждение первой задачи может затянуться на 30-40 минут. И только ближе к концу окажется, что её вообще не планировали брать в ближайший спринт.
Может случиться так, что кто-то уткнется в телефон, а фасилитатор не сможет вернуть фокус, и команда окончательно выпадет из процесса. По окончанию груминга у всех останется лишь ощущение впустую потраченного времени, а это может и вовсе демотивировать команду ходить на встречи.
— Что в итоге решили?
Ответа нет.
Как не потратить время на груминге впустую и решить перечисленные проблемы? Ответили на карточках.
Бывали ли у вас такие ситуации, и как вы с ними справились? Поделитесь в комментариях.
👍4🔥1
Недавно с клиентом мы обсуждали, сколько должно длиться планирование спринта. В какой-то момент нам задали вопрос:
Планирование — это встреча, которую обычно проводят в первый день нового спринта. Согласно Scrum Guide, максимальное время, которое можно выделить на неё, составляет 4 часа для двухнедельного спринта, но не больше.
Если планирование регулярно отнимает у команды много времени, хотя она собралась не вчера — значит, что-то идет не так. Причин может быть несколько, вот на что стоит обратить внимание:
• Задачи недостаточно детализированы
• Команда впервые видит задачи
• Нет критериев, когда задача считается готовой к работе
• Сильно углубились в технические детали
В таких ситуациях бывает достаточно качественно описать задачи, чтобы они соответствовали Definition of Ready, и уделить больше внимания грумингу бэклога, чтобы определиться что делать. На планировании команда решает только, какие задачи берёт в спринт и как будет их выполнять. И если все хорошо подготовлено, то двухнедельный спринт можно спланировать за 1,5–2 часа.
— У нас планирование двухнедельного спринта стабильно тянется от 4 часов, хотя команда уже давно работает вместе. Что мы делаем не так, если в нашем случае это должно занимать всего 1,5-2 часа?
Планирование — это встреча, которую обычно проводят в первый день нового спринта. Согласно Scrum Guide, максимальное время, которое можно выделить на неё, составляет 4 часа для двухнедельного спринта, но не больше.
Если планирование регулярно отнимает у команды много времени, хотя она собралась не вчера — значит, что-то идет не так. Причин может быть несколько, вот на что стоит обратить внимание:
• Задачи недостаточно детализированы
• Команда впервые видит задачи
• Нет критериев, когда задача считается готовой к работе
• Сильно углубились в технические детали
В таких ситуациях бывает достаточно качественно описать задачи, чтобы они соответствовали Definition of Ready, и уделить больше внимания грумингу бэклога, чтобы определиться что делать. На планировании команда решает только, какие задачи берёт в спринт и как будет их выполнять. И если все хорошо подготовлено, то двухнедельный спринт можно спланировать за 1,5–2 часа.
👍3🔥1
Крайне интересный факт, если это правда. Похоже, самый длинный контракт на разработку ПО в истории.
Конечно, его необходимо отменить, но интересно то, что его точно не следует заменять на модель оплаты по результатам (пожалуйста!).
Как мы все знаем, такие контракты не работают хорошо и, независимо от стиля управления, 100% приводят к низкому качеству продукта, продлению сроков и перерасходу бюджета.
Базовая причина в том, что никто не может написать настолько исчерпывающие бизнес-требования, чтобы внешние разработчики могли просто преобразовать их в программный продукт, соответствующий ожиданиям.
Всегда есть место для изменений в требованиях, но оплата по результатам — это по сути контракт с фиксированной ценой и фиксированным объёмом работ.
Вот почему Agile подход здесь необходим и должен использоваться в любом случае.
Исходный текст со скриншота:
“Существует закономерность во всех государственных учреждениях, где контракты на "модернизацию" ИТ не оплачивают результаты/производительность; вместо этого они платят за время.
Следовательно, у подрядчиков есть стимул "никогда не заканчивать", что приводит к невероятным растратам.
Например, модернизация Налоговой службы США (IRS) началась в 1990 году с планируемым завершением в 1996 году. Сегодня работа не завершена, и подрядчики говорят, что до завершения ещё 5 лет. 29 лет отставания от графика и примерно 15 млрд долларов перерасхода бюджета.
Проигрывают все, кроме государственных подрядчиков. Это должно измениться.
На этой неделе IRS заморозила контракты на модернизацию на сумму около 1,5 млрд долларов, ни один из которых не влияет на подачу налоговых деклараций. Все эти контракты будут либо отменены, либо условия контрактов будут изменены на оплату по результатам.”
Как вам такое? 🙂
Конечно, его необходимо отменить, но интересно то, что его точно не следует заменять на модель оплаты по результатам (пожалуйста!).
Как мы все знаем, такие контракты не работают хорошо и, независимо от стиля управления, 100% приводят к низкому качеству продукта, продлению сроков и перерасходу бюджета.
Базовая причина в том, что никто не может написать настолько исчерпывающие бизнес-требования, чтобы внешние разработчики могли просто преобразовать их в программный продукт, соответствующий ожиданиям.
Всегда есть место для изменений в требованиях, но оплата по результатам — это по сути контракт с фиксированной ценой и фиксированным объёмом работ.
Вот почему Agile подход здесь необходим и должен использоваться в любом случае.
Исходный текст со скриншота:
“Существует закономерность во всех государственных учреждениях, где контракты на "модернизацию" ИТ не оплачивают результаты/производительность; вместо этого они платят за время.
Следовательно, у подрядчиков есть стимул "никогда не заканчивать", что приводит к невероятным растратам.
Например, модернизация Налоговой службы США (IRS) началась в 1990 году с планируемым завершением в 1996 году. Сегодня работа не завершена, и подрядчики говорят, что до завершения ещё 5 лет. 29 лет отставания от графика и примерно 15 млрд долларов перерасхода бюджета.
Проигрывают все, кроме государственных подрядчиков. Это должно измениться.
На этой неделе IRS заморозила контракты на модернизацию на сумму около 1,5 млрд долларов, ни один из которых не влияет на подачу налоговых деклараций. Все эти контракты будут либо отменены, либо условия контрактов будут изменены на оплату по результатам.”
Как вам такое? 🙂
👍4🤔1
Это фреймворк или методология? В чем разница на примере Scrum
Многие люди путают эти понятия. Давайте разберемся, почему так происходит.
📌Методология — это система практик, правил и процессов, описывающая как именно нужно работать. Она сочетает в себе шаблоны документов, сроки согласований и инструкции, и используется как своего рода план по достижению поставленной цели.
📌Фреймворк — это гибкая структура или каркас, который задаёт рамки для работы, оставляя пространство для адаптации. В отличие от методологии, он не навязывает жёсткие правила, а предлагает набор инструментов, ролей и артефактов, которые можно приспособить под особенности проекта.
Фреймворк в чём-то похож на стратегию развития — он помогает достичь поставленных целей, но конкретные решения принимаются, исходя из от того, что происходит здесь и сейчас.
❤️ Почему Scrum — это именно фреймворк, а не методология?
Если вы применяете Scrum в работе, то уже наверняка догадались, в чём дело.
• Во-первых, Scrum даёт понимание, ЧТО именно нужно делать — например, проводить спринты, дейли и ретроспективы, и ЗАЧЕМ это нужно делать. Но при этом не диктует, КАК всё это делать.
• Во-вторых, в Scrum появляются новые роли и артефакты, но при этом у команды остаётся возможность адаптировать практики под свою специфику.
• В-третьих, в отличие от методологии, Scrum не даёт готовых ответов на все случаи жизни и предполагает постоянные эксперименты.
• В-четвёртых, методология подразумевает, что мы должны следовать конкретным шагам, чтобы получить нужный результат. А Scrum, наоборот, предлагает базовую структуру и принципы, а уже как именно их применять в конкретной ситуации — решайте сами.
❤️ Разница между этими двумя понятиями — это не просто терминологический вопрос. Это про то, как вообще работать с разными методологиями и фреймворками. Если считать Scrum методологией, где всё расписано по шагам, то можно быстро разочароваться — ответов там просто нет.
Возможно, вы сталкивались с ситуацией, когда Scrum не сработал, потому что команда ожидала именно готовых ответов. Scrum только подсвечивает проблемы, но не может предложить решение.
В следующем посте сравним Scrum с другим популярным Agile-подходом, и посмотрим, какой из них ближе к фреймворку, а какой к методологии. Как думаете, о чём пойдёт речь?
Многие люди путают эти понятия. Давайте разберемся, почему так происходит.
📌Методология — это система практик, правил и процессов, описывающая как именно нужно работать. Она сочетает в себе шаблоны документов, сроки согласований и инструкции, и используется как своего рода план по достижению поставленной цели.
📌Фреймворк — это гибкая структура или каркас, который задаёт рамки для работы, оставляя пространство для адаптации. В отличие от методологии, он не навязывает жёсткие правила, а предлагает набор инструментов, ролей и артефактов, которые можно приспособить под особенности проекта.
Фреймворк в чём-то похож на стратегию развития — он помогает достичь поставленных целей, но конкретные решения принимаются, исходя из от того, что происходит здесь и сейчас.
Если вы применяете Scrum в работе, то уже наверняка догадались, в чём дело.
• Во-первых, Scrum даёт понимание, ЧТО именно нужно делать — например, проводить спринты, дейли и ретроспективы, и ЗАЧЕМ это нужно делать. Но при этом не диктует, КАК всё это делать.
• Во-вторых, в Scrum появляются новые роли и артефакты, но при этом у команды остаётся возможность адаптировать практики под свою специфику.
• В-третьих, в отличие от методологии, Scrum не даёт готовых ответов на все случаи жизни и предполагает постоянные эксперименты.
• В-четвёртых, методология подразумевает, что мы должны следовать конкретным шагам, чтобы получить нужный результат. А Scrum, наоборот, предлагает базовую структуру и принципы, а уже как именно их применять в конкретной ситуации — решайте сами.
Возможно, вы сталкивались с ситуацией, когда Scrum не сработал, потому что команда ожидала именно готовых ответов. Scrum только подсвечивает проблемы, но не может предложить решение.
Гораздо полезнее смотреть на Scrum как на гибкий каркас, который задаёт общую структуру. Его смысл в том, чтобы пробовать новое и постоянно улучшать то, что делает команда.
В следующем посте сравним Scrum с другим популярным Agile-подходом, и посмотрим, какой из них ближе к фреймворку, а какой к методологии. Как думаете, о чём пойдёт речь?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
Продолжаем разбираться, чем фреймворки отличаются от методологий
В прошлый раз мы обсудили, в чём разница между этими двумя понятиями, определились с тем, что же такое Scrum и как его воспринимать, чтобы он приносил результат. А сегодня сравним уже знакомый вам Scrum с другим популярным подходом — SAFe.
⚙️ Как мы уже выяснили, Scrum — это классический фреймворк:
• 3 роли
• 5 событий
• 3 артефакта
• Умещается в руководство на 19 страниц
• Минимум правил, а как их применять — решайте сами
⚙️ SAFe (Scaled Agile Framework) начинался как фреймворк для масштабирования, но со временем эволюционировал в нечто близкое к методологии:
• Десятки ролей и должностей
• Многоуровневая структура (Essential, Large Solution, Portfolio, Full)
• Подробные руководства по внедрению
• Сотни страниц документации с детальными описаниями практик, метрик и процессов
• Готовые решения для большинства типовых ситуаций
❤️ Как это выглядит на практике
Scrum даёт основу, на которой можно построить рабочий процесс, а благодаря высокой адаптивности команда сама определяет, как именно это сделать. SAFe же, напротив, предлагает готовые решения на любой случай жизни — в нём их больше, чем в обычном фреймворке.
Небольшим командам, как правило, хватает простоты и гибкости Scrum. А вот в больших компаниях нужна конкретика и продуманная структура.
❤️ А что говорит опыт других компаний
С одной стороны, наличие готовых решений — это удобно. Но важно помнить, что все они появились из чужого опыта, из других продуктов и у других команд. И то, что сработало у одних, может оказаться бесполезным для других или даже навредить им.
Вспомните Rational Unified Process (RUP) и Microsoft Solution Framework (MSF). Многие пробовали идти по пути универсальных методологий, которые оказались слишком сложным для внедрения. Это привело к тому, что их часто неправильно применяли, и в итоге от них отказались ещё в 2005 году.
Всё циклично, и история любит повторяться.
Как вы считаете — стоит ли использовать детализированные методологии или лучше придерживаться простых и гибких фреймворков, не перегружая процесс лишними правилами?
В прошлый раз мы обсудили, в чём разница между этими двумя понятиями, определились с тем, что же такое Scrum и как его воспринимать, чтобы он приносил результат. А сегодня сравним уже знакомый вам Scrum с другим популярным подходом — SAFe.
• 3 роли
• 5 событий
• 3 артефакта
• Умещается в руководство на 19 страниц
• Минимум правил, а как их применять — решайте сами
• Десятки ролей и должностей
• Многоуровневая структура (Essential, Large Solution, Portfolio, Full)
• Подробные руководства по внедрению
• Сотни страниц документации с детальными описаниями практик, метрик и процессов
• Готовые решения для большинства типовых ситуаций
Scrum даёт основу, на которой можно построить рабочий процесс, а благодаря высокой адаптивности команда сама определяет, как именно это сделать. SAFe же, напротив, предлагает готовые решения на любой случай жизни — в нём их больше, чем в обычном фреймворке.
Небольшим командам, как правило, хватает простоты и гибкости Scrum. А вот в больших компаниях нужна конкретика и продуманная структура.
С одной стороны, наличие готовых решений — это удобно. Но важно помнить, что все они появились из чужого опыта, из других продуктов и у других команд. И то, что сработало у одних, может оказаться бесполезным для других или даже навредить им.
Суть Agile как раз в том, чтобы искать свои, оригинальные подходы, а не копировать чужие.
Вспомните Rational Unified Process (RUP) и Microsoft Solution Framework (MSF). Многие пробовали идти по пути универсальных методологий, которые оказались слишком сложным для внедрения. Это привело к тому, что их часто неправильно применяли, и в итоге от них отказались ещё в 2005 году.
Всё циклично, и история любит повторяться.
Как вы считаете — стоит ли использовать детализированные методологии или лучше придерживаться простых и гибких фреймворков, не перегружая процесс лишними правилами?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤2
• 28 - 30 апреля
• 19 - 21 мая
🔹 Профессиональный сертификационный тренинг по Agile и Scrum
Я хочу понять, как начать внедрять гибкие подходы Agile, Scrum и Kanban в своей компании и научиться планировать в условиях неопределенности.
• 26 - 28 мая
🔹 Cертифицированный Скрам-мастер и фасилитатор
Я хочу научиться проводить командные встречи, организовывать ретроспективы даже в сложных ситуациях и создавать атмосферу доверия и тесного сотрудничества внутри своей команды.
• 09 - 11 апреля
• 25 - 27 июня
🔹Сертифицированный Владелец продукта в Agile
Я хочу научиться создавать востребованные продукты, которые действительно решают задачи клиентов, и привить себе навык продуктового мышления.
• 18 - 20 июня
🔹 Сертифицированный Delivery и Project менеджер в Agile
Я хочу ощутить ценность применения Agile и Scrum для своих проектов и овладеть самыми актуальными инструментами управления.
После прохождения каждого курса вы получите именной сертификат от международного консорциума ICAgile.
• 23 - 25 июля
🔹 Масштабирование Agile на основе SAFe, LeSS и Fligth Levels
Я хочу научиться управлять несколькими кросс-функциональными командами и синхронизировать их работу.
📍Сейчас самое время успеть воспользоваться выгодными условиями для тех, кто регистрируется заранее.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2🔥2🥰1
Это подход к организации работы, когда департаменты формируются не по функциям — например, маркетинг, продажи и разработка — а вокруг конкретного бизнес-направления или линейки продуктов.
То есть внутри каждой такой вертикали есть все специалисты, которые нужны для запуска и развития продукта — свои разработчики, аналитики, маркетологи и прочие. И все они работают, как одна команда.
Например, после перехода на Agile в Сбере выделились несколько value streams — потоков ценности, внутри которых сформировались кросс-функциональные трайбы, скводы и центры компетенций. У каждой из таких «вертикалей» есть ресурсы и сотрудники, которые ведут продукты от начала и до конца.
Модель бизнес-вертикалей действительно чаще всего встречается в крупных компаниях — там, где есть много разных продуктов. Но на самом деле этот подход может быть полезен компаниям среднего размера, особенно если у них уже есть несколько продуктов, или если они планируют активно расти.
Допустим, у вас компания, которая выпускает бытовую химию. В этом случае вертикалями могут быть хозтовары, косметика или другие направления в зависимости от ассортимента, каналов сбыта и целевой аудитории. Каждая из вертикалей будет работать как мини-компаниия внутри одной большой со своей командой, продуктами, прибылью и задачами.
Это перекликается с Agile-подходом и идеей кросс-функциональных команд.
Внутри геосервисов «Яндекс.Карт» и «Яндекс.Навигатора» работают отдельные продуктовые команды, которые полностью отвечают, например, за поиск заведений или алгоритмы маршрутизации. Аналогично устроены и другие сервисы Яндекса — будь то облако, поисковая система или другие направления.
Каждая вертикаль самостоятельно отвечает за свои метрики — за доход, рост и долю рынка.
Что вы думаете о модели бизнес-вертикалей?
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4👍2
Продолжая тему прошлого поста — пример того, как устроена бизнес-вертикаль в компании Avito.
— У нас пять вертикальных команд. Они разрабатывают основные направления бизнеса, вы можете знать их как категории на Авито: товары, авто, работа, недвижимость и услуги.
Вертикали в Avito различаются друг от друга по типу объявлений и по способам монетизации. Соответственно, у каждой из них есть свои отдельные инструменты, заточенные под задачи конкретного продуктового направления.
Каждая вертикаль отвечает за свой поток ценности
Кросс-функциональные продуктовые команды устроены так, что в них есть свои разработчики, аналитики, продуктовые менеджеры, дизайнеры, маркетологи и другие специалисты. Они глубоко погружены и хорошо понимают специфику именно этой категории объявлений — как люди выбирают и покупают машину, квартиру, или как ищут работу. И за счёт этого могут самостоятельно влиять на их пользовательский опыт.
Когда мы помогаем клиентам в переходе на Agile-модель работы, разделение на продуктовые вертикали или value streams — это из этапов преобразования организационной структуры, которая будет способствовать более быстрой поставке результата.
С его помощью мы стараемся упростить иерархию и сделать процесс взаимодействия и принятия решений максимально быстрым.
Посмотрите интересную статью про Роли и Оргструктуру в LeSS.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3
На одном из тренингов участник задал нам вопрос:
Стоит ненадолго остановиться и подумать, а как вообще составлять требования, если сами заказчики не понимают, чего хотят? Давайте порассуждаем, как это устроено в гибких организациях.
Требования не должны быть высечены в камне
Во-первых, они не должны быть слишком объёмными. Подход, в котором всё до мелочей расписано и собрано в один большой документ, чтобы потом ему строго следовать — не самый удачный.
Во-вторых, в результате такого подхода появляется огромный, неподъёмный документ, с которым потом приходится разбираться разработчикам и тестировщикам. Они остаются один на один с этими требованиями, без возможности уточнить что-либо у заказчика и получить фидбэк по ходу работы. Их задача — на основе этих правил создать работающий продукт.
Такая модель разработки усложняет весь процесс
Большие требования долго реализуются, тестируются и также долго исправляются. Можно потратить много времени и ресурсов, но получить совсем не то, что действительно нужно пользователю.
Конечно, и в Agile можно ошибиться и сделать что-то не то. Но ошибка в этом случае будет менее критичной, потому что на неё тратится гораздо меньше времени. И остаются ресурсы, чтобы быстро её исправить — и время, и бюджет.
Поэтому, отвечая на этот вопрос, можно сказать следующее:
Да, большинство из нас привыкли, что требования должны быть полными, ясными и исчерпывающими — и это действительно важный фундамент, с точки зрения понимания, как работают каскадные процессы разработки. Но когда мы переходим к продуктовой разработке, где важно быстро выводить решения на рынок, конкурировать и привлекать новых пользователей — этот фундаментальный подход перестаёт быть эффективным.
В таких условиях нужен другой, более гибкий подход к формулировке требований и работе с ними.
— Если в процессе обсуждения выясняется, что заказчики сами не до конца понимают, чего именно они хотят? Означает ли это, что требования вообще не нужны? Или они не должны быть полными, исчерпывающими и ясными — как нас обычно учат?
Стоит ненадолго остановиться и подумать, а как вообще составлять требования, если сами заказчики не понимают, чего хотят? Давайте порассуждаем, как это устроено в гибких организациях.
Требования не должны быть высечены в камне
Во-первых, они не должны быть слишком объёмными. Подход, в котором всё до мелочей расписано и собрано в один большой документ, чтобы потом ему строго следовать — не самый удачный.
Во-вторых, в результате такого подхода появляется огромный, неподъёмный документ, с которым потом приходится разбираться разработчикам и тестировщикам. Они остаются один на один с этими требованиями, без возможности уточнить что-либо у заказчика и получить фидбэк по ходу работы. Их задача — на основе этих правил создать работающий продукт.
Такая модель разработки усложняет весь процесс
Большие требования долго реализуются, тестируются и также долго исправляются. Можно потратить много времени и ресурсов, но получить совсем не то, что действительно нужно пользователю.
Конечно, и в Agile можно ошибиться и сделать что-то не то. Но ошибка в этом случае будет менее критичной, потому что на неё тратится гораздо меньше времени. И остаются ресурсы, чтобы быстро её исправить — и время, и бюджет.
Поэтому, отвечая на этот вопрос, можно сказать следующее:
Да, большинство из нас привыкли, что требования должны быть полными, ясными и исчерпывающими — и это действительно важный фундамент, с точки зрения понимания, как работают каскадные процессы разработки. Но когда мы переходим к продуктовой разработке, где важно быстро выводить решения на рынок, конкурировать и привлекать новых пользователей — этот фундаментальный подход перестаёт быть эффективным.
В таких условиях нужен другой, более гибкий подход к формулировке требований и работе с ними.
👍4
В апреле 1970 года космический корабль «Аполлон-13» отправился к Луне — это должна была стать третья в истории пилотируемая посадка на её поверхность. Внутри были трое астронавтов.
Но всё пошло не по плану, когда прямо во время полёта в одном из кислородных баллонов произошёл взрыв
Это привело к серьёзной утечке кислорода и отключению важного оборудования. Наземному центру управления в Хьюстоне пришлось немедленно изменить свой курс, и вместо высадки на Луну срочно придумывать, как спасти экипаж в условиях крайне ограниченных ресурсов и времени.
Сегодня «Аполлон-13» — это классический пример того, что даже при самом тщательном планировании и проработке требований, невозможно предусмотреть всё заранее. Что-то всё равно придётся дорабатывать и начинать сначала, чтобы всё-таки высадиться на Луну.
Вся подготовка к запуску была расписана по шагам в чек-листах, основанных на опыте предыдущих полётов — как заправить ракету, как проводить проверки систем и как организовать быт астронавтов на борту. Тестирование скафандров, ремней и оборудования проводилось также строго, как все остальные проверки.
Это была та часть миссии, где всё оставалось предсказуемо
Что касается планирования самого полёта, то здесь нужно было заранее учитывать массу факторов и привлекать к работе опытных специалистов, ведь каждый полёт уникален — когда именно стартовать, как рассчитать траекторию до Луны и обратно, и какие манёвры предстоит выполнить. Всё это ещё предстояло определить.
То же самое касается проектирования систем жизнеобеспечения и двигателей — это огромный пласт инженерной работы, в которой необходимы экспертные знания и точные расчёты. Нельзя было просто взять и скопировать готовые решение — нужны были адаптации.
Тем не менее, эта часть миссии тоже оставалась предсказуемой, пусть для неё и не сущестовало стандартных решений. В следующем посте мы расскажем, что же произошло в момент самой аварии.
Но всё пошло не по плану, когда прямо во время полёта в одном из кислородных баллонов произошёл взрыв
Это привело к серьёзной утечке кислорода и отключению важного оборудования. Наземному центру управления в Хьюстоне пришлось немедленно изменить свой курс, и вместо высадки на Луну срочно придумывать, как спасти экипаж в условиях крайне ограниченных ресурсов и времени.
Сегодня «Аполлон-13» — это классический пример того, что даже при самом тщательном планировании и проработке требований, невозможно предусмотреть всё заранее. Что-то всё равно придётся дорабатывать и начинать сначала, чтобы всё-таки высадиться на Луну.
Вся подготовка к запуску была расписана по шагам в чек-листах, основанных на опыте предыдущих полётов — как заправить ракету, как проводить проверки систем и как организовать быт астронавтов на борту. Тестирование скафандров, ремней и оборудования проводилось также строго, как все остальные проверки.
Это была та часть миссии, где всё оставалось предсказуемо
Что касается планирования самого полёта, то здесь нужно было заранее учитывать массу факторов и привлекать к работе опытных специалистов, ведь каждый полёт уникален — когда именно стартовать, как рассчитать траекторию до Луны и обратно, и какие манёвры предстоит выполнить. Всё это ещё предстояло определить.
То же самое касается проектирования систем жизнеобеспечения и двигателей — это огромный пласт инженерной работы, в которой необходимы экспертные знания и точные расчёты. Нельзя было просто взять и скопировать готовые решение — нужны были адаптации.
Тем не менее, эта часть миссии тоже оставалась предсказуемой, пусть для неё и не сущестовало стандартных решений. В следующем посте мы расскажем, что же произошло в момент самой аварии.
🔥4❤2👍2
Продолжаем рассказывать о миссии «Аполлон-13»
Ещё до аварии команде на борту и в Центре управления приходилось иметь в виду, что некоторые риски невозможно просчитать заранее — например, как скажется космическая радиация, как поведёт себя оборудование в невесомости, и какие технические сбои могут произойти в ходе полёта.
Другим важным моментом были сами астронавты — им предстояло провести много времени в замкнутом пространстве.
В момент взрыва на борту «Аполлона-13» оборудование частично вышло из строя, кислород резко начал заканчиваться, и узнать обо всех повреждениях было практически невозможно.
Именно тогда прозвучала легендарная фраза:
Когда астронавты сообщили о проблемах, дежурные в Центре управления полётами в Хьюстоне не понимали какой именно резервуар повреждён.
Все расчёты и графики полёта пришлось отложить. Основная задача была — не дойти до Луны, а просто выжить. Не было времени на долгие обсуждения, инженеры на Земле и астронавты на борту из подручных материалов собрали фильтр для углекислого газа, который буквально спас экипаж.
В NASA существовал план на случай аварийных ситуаций — сначала стабилизировать обстановку, чтобы экипаж мог дышать, а уже потом думать, как вернуть корабль домой.
Команда тоже была очень хорошо натренирована на нештатные случаи — одни параллельно собирали данные и пытались понять, что случилось, а другие выполняли действия на случай сбоя в электропитании, поскольку топливные элементы «Аполлона» получали энергию, используя кислород из этих же баков.
Проблема была в том, что штатные инструкции не покрывали весь масштаб повреждения. Как только стало понятно, что целый резервуар кислорода утерян, было принято решение перевести экипаж в лунный модуль и использовать его как спасательную шлюпку.
Инженеры из NASA нашли способ подключить квадратные фильтры от командного модуля к круглым отверстиям лунного модуля — с помощью пластиковых пакетов, скотча и шлангов. Этот момент вошёл в историю в качестве примера того, как «соединить квадратное с круглым».
ЦУП рассчитал манёвр, который позволил использовать гравитацию Луны, чтобы развернуть корабль и вернуться на Землю. В итоге астронавты благополучно приземлились 17 апреля 1970 года в Тихом океане.
Предлагаем вам по случаю прошедшего Дня Космонавтики прочитать полную историю миссии «Аполлон-13». А в следующем посте мы разберём, чему она может нас научить с точки зрения подходов к принятию решений.
Ещё до аварии команде на борту и в Центре управления приходилось иметь в виду, что некоторые риски невозможно просчитать заранее — например, как скажется космическая радиация, как поведёт себя оборудование в невесомости, и какие технические сбои могут произойти в ходе полёта.
Другим важным моментом были сами астронавты — им предстояло провести много времени в замкнутом пространстве.
В момент взрыва на борту «Аполлона-13» оборудование частично вышло из строя, кислород резко начал заканчиваться, и узнать обо всех повреждениях было практически невозможно.
Именно тогда прозвучала легендарная фраза:
— Houston, we have a problem.
Когда астронавты сообщили о проблемах, дежурные в Центре управления полётами в Хьюстоне не понимали какой именно резервуар повреждён.
Все расчёты и графики полёта пришлось отложить. Основная задача была — не дойти до Луны, а просто выжить. Не было времени на долгие обсуждения, инженеры на Земле и астронавты на борту из подручных материалов собрали фильтр для углекислого газа, который буквально спас экипаж.
В NASA существовал план на случай аварийных ситуаций — сначала стабилизировать обстановку, чтобы экипаж мог дышать, а уже потом думать, как вернуть корабль домой.
Команда тоже была очень хорошо натренирована на нештатные случаи — одни параллельно собирали данные и пытались понять, что случилось, а другие выполняли действия на случай сбоя в электропитании, поскольку топливные элементы «Аполлона» получали энергию, используя кислород из этих же баков.
Проблема была в том, что штатные инструкции не покрывали весь масштаб повреждения. Как только стало понятно, что целый резервуар кислорода утерян, было принято решение перевести экипаж в лунный модуль и использовать его как спасательную шлюпку.
Инженеры из NASA нашли способ подключить квадратные фильтры от командного модуля к круглым отверстиям лунного модуля — с помощью пластиковых пакетов, скотча и шлангов. Этот момент вошёл в историю в качестве примера того, как «соединить квадратное с круглым».
ЦУП рассчитал манёвр, который позволил использовать гравитацию Луны, чтобы развернуть корабль и вернуться на Землю. В итоге астронавты благополучно приземлились 17 апреля 1970 года в Тихом океане.
Предлагаем вам по случаю прошедшего Дня Космонавтики прочитать полную историю миссии «Аполлон-13». А в следующем посте мы разберём, чему она может нас научить с точки зрения подходов к принятию решений.
🔥6❤2