методология lean что это
Знакомимся с Lean: как создать ценность без потерь
Рассказываем, с какого вопроса началась история Lean и как с ним работать.
Что такое Lean
Lean ― это философия бережливого мышления. Подход, который позволяет экономить ресурсы и получать лучший результат.
Цель Lean ― создавать ценность, сокращая расходы на ее производство.
Это не методология, поэтому в ней нет набора готовых практик. Конкретных правил тоже нет, но есть приемы, которые помогают извлекать пользу. Но как разобраться, что значит Lean, если нет методологии и правил? И как придерживаться философии, в которой не на что опереться?
Придерживаться Lean ― значит всегда использовать системный подход, искать и устранять потери, создавать поток. Поток ― это непрерывный процесс создания ценности — не любого продукта, а именно того, который нужен потребителю.
Lean ― это часть философии Agile. Если говорить о разработке ПО, то бережливое мышление ― основа для любой гибкой методологии, например, Scrum, где есть набор принципов и практик, которые пересекаются с ценностями Lean.
Agile, Scrum, Kanban, Lean ― в области управления digital-проектами есть много систем и методологий, в которых легко запутаться. Где-то есть набор практик, как в Scrum, где-то ― только несколько ценностей и никаких правил, как в Lean. Kanban, например, — не методология, а метод ее улучшения. Lean ― вообще философия, кстати, как и Agile. Осталось только понять, как во всем этом разобраться и не сойти с ума.
Digital-индустрия развивается постоянно, поэтому применить себя в этой области, используя вчерашние знания, будет нелегко. Чтобы стать профессионалом, нужно непрерывно совершенствовать уровень мастерства. Можно использовать статьи и кейсы, а можно записаться на офлайн- или онлайн-курсы, чтобы закреплять теоретическую базу на практике.
Чтобы лучше понять, что значит Lean, вернемся к истории и посмотрим, как появились ее основные ценности.
Как создавали Lean
Итак, мы остановились на том, что Toyota никак не могла продать свои автомобили из-за сложной экономической ситуации в стране. Но, как оказалось, дело было не только в этом. Слишком много денег компании уходило на закупку и хранение деталей, исправление дефектов. В результате больших трат на производство получались дорогие машины, которые в Японии были не нужны, а другие рынки уже давно осваивала компания Ford.
Стандартные методы решения проблем не помогали исправить ситуацию, поэтому Toyota ничего не оставалось, как полностью изменить подход к производству.
Системный подход показал, что нужно не увеличивать количество производимых автомобилей, а улучшать их качество и сроки поставки, при этом заметно сократив расходы на производство. Этого можно было добиться, полностью ликвидировав потери. Тогда появился другой вопрос: как это сделать?
Основные проблемы, с которыми борется бережливое мышление: муда ― потери, мура ― неравномерность, мури ― перегрузка. Еще есть кайдзен ― постоянное совершенствование.
Ответом стала новая система работы производства ― Toyota Production System. С ее помощью компания улучшила качество продукции, сократила расходы и сроки на ее создание. Но для этого пришлось полностью изменить подход не только к процессу работы, но и к мышлению сотрудников.
14 принципов производственной системы Toyota
Не бояться идти на жертвы ради будущей выгоды.
2. Непрерывность производственного потока
Создать единый и непрерывный поток производства.
Потребители должны получить товар точно в срок.
4. Равномерность в распределении нагрузки
Все участки производства должны работать одновременно и с одинаковой нагрузкой.
5. Остановка производства при сбоях
Любой рабочий имеет право остановить процесс производства, если на его участке произошел сбой.
6. Превращение опыта в стандарт
Опыт и знания, полученные в процессе работы, должны стать стандартом компании.
7. Визуальный контроль
Все участники процесса производства должны наблюдать за работой всей системы целиком, иметь общую картину происходящего.
8. Внедрение только проверенных технологий
Любая технология должна быть несколько раз проверена перед тем, как стать частью производственного процесса.
9. Воспитание лидеров внутри компании
Важно замечать и поддерживать стремления заинтересованных в прогрессе сотрудников и давать им возможность развиваться.
10. Формирование и поддержка рабочих команд
Необходимо объединять людей в небольшие группы, чтобы улучшить их результаты.
11. Уважение и помощь в развитии коллег
Компания должна помогать в развитии поставщикам и командам, с которыми взаимодействует. Это идет на пользу общему делу.
12. Контроль руководителя
Перед принятием важного решения руководитель должен увидеть ситуацию целиком.
13. Принятие решений согласием большинства
Решение считается верным, если большая часть сотрудников считает его таковым.
14. Непрерывный анализ и совершенствование процесса
Не важно, насколько хорошо идут дела, всегда можно сделать лучше. Поэтому команда должна постоянно анализировать, оценивать и улучшать процесс и результат своей работы.
Когда работа согласно этим 14 принципам была налажена, Toyota смогла занять лидирующую позицию в автомобильной промышленности. Цель была достигнута, а технологию lean-производства теперь используют в разных областях по всему миру.
Как использовать Lean при разработке программного обеспечения
В начале XXI века разработчики Том и Мэри Поппендик поняли, что систему Toyota можно применить в мире программного обеспечения. Они впервые использовали принципы бережливого мышления, чтобы помочь разработчикам. Так как Lean ориентирована на клиента и его потребности, при работе над программным обеспечением нужно создать полезный продукт, но сократить ресурсы, необходимые для его производства.
Lean-разработчики не используют все 14 принципов системы Toyota, но ориентируются на основные ценности бережливого мышления.
Если действие не улучшает качество продукта, не приносит прибыли заказчику и не экономит время разработчика, то его нужно исключить.
Чтобы создавать качественный продукт, команда должна постоянно совершенствовать свои знания и навыки. А руководитель ― обеспечивать команду временем и ресурсами.
Принимать важные решения в последний момент
Иногда запоздало принятое решение может испортить всю проделанную работу, но для Lean откладывать принятие решения до последнего ― это способ собрать как можно больше информации о вопросе. А значит, быть уверенным в его правильности и избежать ошибок.
Доставлять ценность как можно раньше
Чем раньше команда покажет свои наработки заказчику, тем быстрее получит от него обратную связь. Разработчики будут уверены, что все делают так, как хочет клиент, и смогут все изменить при необходимости.
Когда команда работает сообща и понимает свою ценность, процесс идет быстрее и эффективнее. Поэтому важно доверять сотрудникам и ценить то, что они делают.
Создавать целостный продукт
Команда должна сфокусироваться на качестве, не допускать дефектов и всегда ставить в приоритет потребности заказчика.
Следить за общим процессом
Чтобы работа шла хорошо, каждый в команде должен понимать задачи и иметь возможность постоянно видеть весь процесс. Вся информация по проекту должна быть доступна в любое время. Для этих целей в гибких методологиях (Scrum, Kanban) используют доску, где отмечены цели, задачи и процесс их выполнения.
Виды потерь при разработке ПО
Это может быть написанный, но неиспользованный код. Лишний код — зря потраченное время.
Возможности, которые добавили в ПО, но которые не используются потребителем, не приносят пользы. Клиенту нужны только полезные функции.
Если разработчик приступил к одному проекту, а потом его перекинули на другой, придется заново вникать и собирать информацию. То же самое происходит, если в команде проекта появляется новый разработчик. Весь процесс начнется сначала.
Проект или его части передают из одних рук в другие. Так происходит передача не только проекта, но и ответственности за него. В результате команды теряют контроль над ситуацией.
Переключение между задачами
Когда один разработчик выполняет два проекта одновременно и постоянно должен переключаться с одних задач на другие, он теряет больше времени, чем мог бы, работая над одним проектом.
Если команда постоянно занимается согласованием документов с заказчиком, то тратит много времени и в результате срывает сроки проекта.
Команда должна следить за качеством кода еще на начальных этапах. Если по окончании работы будут найдены критические ошибки, то придется начинать проект сначала.
Как правильно создавать ценности
Любой бизнес создает ценности: продукты или услуги, которые компания продает. Ценность продукта определяют пожелания потребителя, а задача Lean ― оптимизировать процесс производства таким образом, чтобы создавать ценности, уменьшая издержки.
Бережливое производство ― это системный подход, поэтому создание и продажа продукта рассматриваются как единый путь ценности от поставщика до потребителя. Всесторонняя оптимизация пути создания продукта называется lean-менеджмент.
Создание продукта состоит из разных процессов. Идея Lean в том, чтобы работать только с полезными, а лишние исключить.
Процессы, которые создают ценность
Это все, что ведет к нужному результату. Любой процесс, который помогает сделать продукт быстрее и лучше, должен постоянно совершенствоваться.
Процессы, которые не создают ценность
Все, что не приносит пользы: тормозит работу или плохо отражается на качестве продукта, не несет ценности для потребителя. Такие процессы нужно сократить до минимума или исключить полностью.
Для lean-мышления потери недопустимы, поэтому их нужно исключить.
Lean-менеджер устраняет организационные и технические проблемы при создании и распространении продукта, быстро реагирует на изменения спроса и ситуации на рынке. Параллельно учит и развивает свою команду, используя lean-ценности.
Вы узнали, что такое Lean, поняли, что такое lean-менеджмент и lean-философия. Теперь можно начинать внедрять полученные знания, но лучше сначала посмотреть, как работают практики. Учиться хирургии лучше у практикующего хирурга, одной теории мало. Так же — и с управлением.
Пишет про управление в Skillbox. Работала координатором проектов в Русском музее, писала для блога агентства CRM-маркетинга Out of Cloud.
Кратко о методологиях разработки ПО: Waterfall, Lean и Feature Driven Development
В нашем прошлом материале мы писали о методологиях разработки программного обеспечения, которые помогают оптимизировать рабочие процессы. Тогда речь шла о Scrum, канбан и экстремальном программировании. Сегодня мы расскажем о Waterfall, FDD и Lean — оценим плюсы и минусы подходов и взглянем на опыт организаций, которые их используют, чтобы помочь вашим компаниям оптимизировать процессы.
Waterfall
Waterfall, или каскадная модель, — традиционная методология, которая существует с 1970 года. В ней разработку проекта разбивают на этапы: от анализа системных требований до выпуска продукта.
Каждый шаг — отдельная фаза разработки ПО, и команда должна завершить одну фазу, прежде чем переходить к следующей. В «чистой» реализации Waterfall возвращаться на предыдущий этап запрещено — можно «плыть только по течению», чтобы пройти полный цикл разработки. Пользователи Quora сравнивают эту модель с поездом, который движется от станции к станции и не может повернуть назад.
Изначально автор Waterfall Винстон Ройс (Winston Royce) привел каскадную модель как пример неэффективного способа разработки программного обеспечения, который ведет к ошибкам и выпуску некачественных продуктов. Однако потом в своей статье он довел методологию «до ума», отметив обратные связи и переходы от тестирования к написанию кода и др.
По данным исследования PMI, 12% компаний используют методологию Waterfall на постоянной основе, а 40% респондентов утверждают, что часто к ней обращаются. А по данным LiquidPlanner, каскадную модель используют 25% организаций.
Количество этапов в Waterfall варьируется от компании к компании, но общий подход выглядит следующим образом:
Кроме того, модель подразумевает документирование каждого этапа. Это помогает создавать базу для последующих проектов. Также большое количество отчетности позволяет в любой момент показать заказчику или руководству, на какой стадии находится продукт.
Однако есть и недостатки. Клиенты часто не знают, чего они действительно хотят, пока не взглянут на прототип. А по Waterfall нужно определять все требования заранее, поэтому есть риск что-то упустить. Исследование процесса разработки сайта компании Ericsson AB показало, что каскадная модель привела к путанице, и 26% изначальных требований оказались бесполезными.
Однако главный недостаток Waterfall — внесение изменений. Продукт тестируют в конце жизненного цикла, и может быть слишком поздно, чтобы что-то править. Именно стоимость внесения изменений побудила компанию Toyota задуматься о переходе на другую методологию разработки.
По словам Сатоси Исии (Satoshi Ishii), главного руководителя проектов компании, исправление дефектов, обнаруженных после производства, обходится в 1000–10000 раз дороже. Поэтому в Toyota решили отказаться от Waterfall и перейти к Lean, который мы рассмотрим далее.
Термин означает «бережливая разработка». Его корни уходят глубоко в историю компании Toyota и её подходов к решению задач. В компании вносят только те изменения, которые приносят пользу, требуют минимум затрат и отнимают не более 30% запланированного времени. Это помогло японской компании научиться переключать конвейеры на производство другой модели за считаные часы, в то время как другим автопроизводителям требовались недели.
Применили методологию Lean для разработки Мэри (Mary Poppendieck) и Том Поппендик (Tom Poppendieck). Они написали книгу «Lean Software Development». Дополнительную информацию также можно найти на их сайте, посвящённом Lean.
По данным исследования PMI, 8% компаний постоянно используют принципы Lean, а 26% часто к ним обращаются. Принципы Lean:
При этом, когда команда следует принципам бережливой разработки, она не просто выполняет задачи, а стремится сделать продукт с наименьшим количеством ошибок. В своём исследовании компания ВВС обнаружила, Lean повышает скорость разработки ПО на 37% и снижает количество багов на 24%.
Также, согласно исследованию Lean Business Report, в числе десяти преимуществ подхода указано снижение стоимости проектов — 27% IT-компаний уменьшили затраты за счет внедрения принципов Lean.
Однако они подходят не всем. Команда GlobalLuxSoft отмечает, что бережливую разработку стоит применять, только если к проекту подключены опытные разработчики, так как обучение на ходу оказывается невозможным и ставит создание продукта под угрозу.
Все принимаемые решения должны подкрепляться аналитическими данными и результатами мониторинга процессов, иначе команда рискует погрузиться в слишком большое количество изменений и забыть о главной цели проекта. Здесь можно обратиться к опыту Toyota: жесткий контроль со стороны не позволяет разработчикам отклоняться от приоритетных задач.
/ Flickr / Sebastian Sikora / CC
Feature Driven Development
Feature driven development (FDD) — методология, которая объединяет лучшие практики и сосредотачивает внимание разработчиков на функциональных элементах (features), полезных с точки зрения клиента. По этой ссылке можно найти примерную схему алгоритма разработки по FDD. Согласно исследованиям, 11% компаний постоянно используют Feature Driven Development, а 31% прибегает к использованию этой методологии время от времени.
Создатель FDD — Джефф де Лука (Jeff De Luca), впервые предложил методологию в 1997 году, когда искал оптимальное решение по разработке программного обеспечения для банка в Сингапуре. Тогда он предоставил комбинацию из 5 процессов:
Однако есть и плюсы. Постоянное составление отчетов о проделанной работе на всех уровнях помогает отслеживать прогресс и результаты. Это позволяет регулярно обновлять проект, выявлять ошибки и предоставлять клиенту информацию в любое время. А один из резидентов Stack Overflow утверждает, что главный плюс FDD — возможность в любой момент оценить отстаёт ли проект от графика или продвигается быстрее.
Как уже было отмечено, FDD используется в масштабных проектах, поскольку на первом этапе ведётся разработка общей модели, позволяющей разобраться в продукте. Это же свойство помогает привлекать к работе новых разработчиков. При этом более глубокое понимание проектных требований и ожиданий клиента снижает риск нежелательных «сюрпризов».
Lean IT: советы по бережливому производству для управления ИТ-услугами
Lean – это бережливое производство. Насколько его философия и рекомендации применимы в сфере управления ИТ-услугами? Может ли управление интеллектуальным и высокотехнологичным производством быть бережливым и как на практике применять принципы Lean для ИТ?
Что такое Lean IТ
Основная идея Lean, или бережливого производства, – максимальная польза для потребителей с использованием минимальных ресурсов компании-производителя. Цель Lean – это организация работы, при которой можно избежать финансовых, временных, репутационных и иных потерь. Чтобы ее достигнуть, нужно создать культуру производства, в которой главный критерий – это ценность продукта для бизнеса и вовлеченность в создание этой ценности всех сотрудников.
Концепция Lean пришла из промышленности. Впервые ее внедрил концерн Toyota, чтобы уменьшить потери и приблизить продукт к ожиданиям потребителей. Принципы бережливого производства активно применяли промышленные компании, затем идею подхватили сферы здравоохранения и страхования. Философию успешно масштабировали для управления в ИТ-сфере, и появился термин Lean IТ. Одними из первых ее внедрили Motorola, TransUnion, Fujitsu Services.
Концепция бережливого производства создавалась для промышленных задач концерна Toyota, но быстро выяснилось, что принципы работают не только для автоконцерна
Основная задача Lean в контексте IT – это устранение потерь. Потери здесь – это деятельность, приводящая к потреблению ресурсов, но не создающая или не добавляющая ценности итоговому продукту. Например, если при работе над CRM команда потратила время на перекрашивание кнопок, хотя для пользователей важнее было добавить нотификацию по новым заявкам, то это – пример потерь, которых можно избежать.
Что из Lean пригодилось в ИТ
Для разработки ПО Lean-методологию адаптировали программисты Мэри и Том Поппендик в книге «Бережливое производство программного обеспечения». Семь принципов из этой книги легко адаптировать и под требования ИТ-услуг:
Анализируйте процессы, находите и ликвидируйте узкие места с неоправданными потерями ресурсов. Например, если изучать запросы, поступающие в службу поддержки, то можно выявить самые востребованные, выработать процесс единого предоставления ответов на них и избежать потерь времени и ресурсов при поставке этих услуг пользователям.
Проверяйте работу системы в процессе внесения изменений, задавайте вопрос – «а что будет, если. ». В результате вы получите представление о качестве всей системы. Например, вы оптимизируете работу службы поддержки. Если вы будете задавать вопрос – «а что будет, если…», то сможете предотвратить маленькие ошибки на каждом из этапов, что сэкономит время. Если этого не делать, то на исправление всех недочетов после оптимизации уйдет намного больше времени.
Создавайте базу знаний по проекту или отдельной службе, системе. Так клиенты и сотрудники смогут быстро получить необходимую им информацию – это позволит сэкономить время на переговоры. Работайте над задачей вместе со своим клиентом. Таким образом вы оптимизируете работу под самые актуальные требования, а сотрудники смогут лучше понимать потребности заказчика.
Прежде чем принять решение, которое нельзя «откатить», изучите все сферы и процессы, которые оно затронет, и действуйте, если промедление чревато потерями или убытками.
Один из принципов бережливого производства – ускорение операций по доставке услуги. Изучайте цепочки поставки и сокращайте задержки отклика всегда, когда это возможно. Например, оптимизируйте избыточный процесс согласований или утверждений.
Прислушивайтесь к сотрудникам и берите на вооружение полезные идеи. Это эффективно, потому что они погружены в рабочие процессы, видят их изнутри и могут предложить выгодное решение. Если ценить и внедрять идеи сотрудников, давать им свободу в решении задач, то это создаст дополнительную мотивацию, а проект только выиграет.
Какой конечной цели вы хотите достичь? Держите ее в поле зрения на каждом этапе, чтобы локальные улучшения работали на глобальную задачу.
Бережливое производство – это не только материальные ресурсы, но еще и люди, которые работают в проекте. Потерями могут быть как финансы или время, так и нереализованный потенциал сотрудников. В рамках Lean IT участники процесса решают задачи удобными и безопасными методами, создают цепочки ценностей, а также раскрывают собственный потенциал, вовлекаясь в процессы оптимизации, управления, технической экспертизы и так далее.
Подход бережливого производства в мире ИТ начинается со способности организации адаптироваться и меняться. Только из этой начальной точки возможно сделать первый шаг по пути Lean ИТ. Этот путь может занять годы, прежде чем принципы Lean станут неотъемлемой частью культуры организации. Но он покажет свою эффективность в будущем, когда услуги станут ценностью для клиента, а на их оказание потребуется минимум затрат.
Как совместить Lean и ИТ на практике
Разберем на примере. В компании есть ИТ-отдел для обслуживания внутренних потребностей. К нему регулярно возникали претензии, потому что он медленно реагировал на инциденты. При анализе работы отдела стало ясно, что его сотрудники вынуждены постоянно оперативно решать возникающие проблемы. Их работа напоминала тушение пожаров.
Но эффективнее не тушить, а предотвращать «пожароопасные ситуации». Поэтому было решено проводить регулярные встречи ИТ-отдела с потребителями. В результате выяснилось, что пользователи долго оформляют заявки из-за неявной системы согласования. Второй точкой роста стало разделение техподдержки по направлениям и внедрение системы общего информирования. Затем была создана база знаний и впоследствии реализована система автоматического управления заявками.
После того как отправлять заявки стало проще, управление ими стало автоматическим, а пользователи получили доступ к базе знаний, количество претензий к IT-отделу уменьшилось. Загрузка его сотрудников снизилась, и они смогли сконцентрироваться на том, чтобы предупреждать запросы своих коллег.
Совместить Lean и IT помогут:
С чего начать внедрение принципов бережливого IT?
Joe The IT Guy, блогер и сотрудник SysAid Technologies, советует взять на вооружение
те самые базовые принципы, которые впервые применил менеджмент японской компании Toyota:
В японской культуре Andon – лампа, которую включали, потянув за шнурок. Принцип основан на том, что нужно «осветить» проблему, которая отрицательно влияет на качество продукта или процесса. В ITIL 4 с этим может быть сопоставлена практика управления событиями и инцидентами, в рамках которой процесс останавливается и проблема устраняется. Например, если при внедрении нового ПО несколько раз происходит одна и та же ошибка, то необходимо остановить весь процесс и устранить проблему один раз, чтобы не сталкиваться с ней постоянно. Инструмент трактуют и в более общем смысле, например для организации сквозных встреч или общих сессий.
Зажечь светильник в терминах бережливого производства означает «осветить» проблему, которая влияет на качество результата
Молодых инженеров приводили в цех, ставили в нарисованный на полу мелом круг и просили наблюдать за процессом из него. Предполагалось, что когда инженеры «пойдут и начнут работать» (Генчи Генбуцу), то при возникновении проблемы они самостоятельно изучат и/или изменят процесс или место проведения работ (Гемба), чтобы найти истоки проблемы. В практиках ITIL 4 этот принцип тоже нашел отражение. Если есть трудно диагностируемый инцидент, то посмотрите, как выполняется работа, на каком этапе возникает проблема.
«Немаваси» переводится как «подготовить почву для посадки». Согласно этому принципу, перед большим и важным собранием нужно провести индивидуальные встречи со всеми участниками. Так они придут подготовленными, со своим мнением, аргументами и идеями. В практиках ITIL 4 серьезные изменения возможны только тогда, когда все поддержат предложенную идею. До этого момента необходимо работать с каждой заинтересованной стороной, пока вы не придете к согласию.
Совместимы ли Lean и ITIL?
В версии ITIL 4 появились серьезные изменения в позиционировании ценности и инструментов, основанных на ней.
Теперь центральным элементом ITIL-4 является система ценностей услуг (SVS). Для нее необходима цепочка создания стоимости услуг, каждое из звеньев которой должно приводить к повышению ценности продукта без потерь. Знакомая концепция бережливого производства, не правда ли?
Ключевое понятие ITIL 4 – система ценностей услуг, на формирование которой направлены все процессы
От участников процесса требуется не только вносить посильный вклад, но и получать единый и прогнозируемый результат. ITIL 4 называет это совместным созданием ценности. Бережливое управление гарантирует, что все участники этого процесса будут вознаграждены. Таким образом, в выигрыше окажутся команды, которые смогут быстро преодолеть разрозненность и достигнут общих целей.
Слишком хорошо звучит, чтобы быть правдой
Некоторые инициативы могут быстро приносить результаты, но внедрение Lean IT – это непрерывный и долгосрочный процесс. Концепция бережливого производства для сферы ИТ-услуг может оказаться тем самым рычагом, который поможет если не перевернуть мир, то уж точно свернуть горы работы: устранение мелких повторяющихся ошибок, исключение задач, которые не принесут клиенту пользы, и многое другое. Да, придется приложить немало сил, потому что сложнее всего изменять базовые принципы организации, но результат того стоит. Эффективные услуги, востребованные продукты, вовлеченные сотрудники, минимизация издержек – думаете, это слишком хорошо звучит, чтобы быть правдой? Но почему бы не пойти по этому пути, чтобы узнать, куда он приведет.