?

Log in

No account? Create an account

Entries by category: технологии

Мои профили в соцсетях



Краткое резюме есть здесь


А еще я написал книгу


Если у вас есть вопрос, то его можно обсудить в форуме

Ссылки на все мои слайдкасты перехали сюда


Еще одна очень хорошая книга очень хорошего автора: Джеффри Лайкер, "Система разработки продукции в Toyota. Люди, процессы, технология"

Не скрою, эта книга определила ход моего доклада на SoftwarePeople'11. Книга очень интересна и рассказывает как создаются новые автомобили в Тойота. Изучая бережливое производство я пытаюсь найти новые эффективные пути работы в нашей индустрии - разработке программного обеспечения. Скептически настроенный человек может аргументированно заметить, что система производства Тойоты (TPS) придумывалась для управления "конвеером", где вариабельность задачи от раза к разу минимальна. Это так. С одной стороны, этот факт не мешает использовать определенные элементы TPS в разработке ПО. С другой стороны, в разработке ПО неопределенности и вариабельности на много больше, что заставляет усомниться в применимости ДАО Тойоты в этой области.

На самом деле вариабельность и неопределенность не помеха ДАО Тойоты. Задача разработки нового автомобиля на много ближе (если вообще не то же самое) к разработке ИТ-системы. И там и там есть неопределенность, нечеткость требований в самом начале проекта, много рисков и всякого непонятного. И Тойота с этим справляется...

В книге подробно и с примерами разбираются 13 основных принципов разработки продукции в Тойота (эти принципы отличаются от рассмотренных в 14 принципов ДАО Тойота). 13 основных принципов объединены в 3 группы:

Процесс
  1. Определить, в чем ценность продукта для потребителя, что бы отличать добавление ценности от потерь. В нашей индустрии имеет смысл добавить еще и принцип 0 - определить, кто является нашим потребителем. Команда по разработке может считать своим потребителем того, кто платит деньги; владельца продукта или customer proxy; команду аналитиков/тестировщиков (если оргструктура в компании выделяет аналитиков/тестировщиков в отдельные единицы); ген. директора фирмы (той, которая платит деньги за разработку или зарплату) и т.п. В зависимости от этого понятие ценность будет иметь различные значения.
  2. Обеспечить правильный старт процесса разработки, чтобы на ранней стадии проектирования досконально изучить все альтернативные варианты. При разработке продукции в Тойота используются практики параллельного проектирования на базе альтернатив. В качестве примера, Лайкер дает ссылку на историю разработки силовой установки Приуса, когда с самого начала команда рассматривала 80 различных вариантов. Этот же принцип уходит корнями в основную практику Lean - "Deffer Commitment", подразумевающую, что всякое необратимое решение мы принимаем на столько поздно, на сколько это возможно, что бы не было потом мучительно больно, за "поторопились и получилось как всегда".
  3. Обеспечить выровненный поток процесса производства продукции. Это достаточно важно. Очереди - зло. Теория очередей гласит, что как только загрузка команды превышает определенный порог, время выполнения "заказа" начинает экспоненциально расти вместе с ростом загрузки. Еще раз, очереди - зло. Что бы избежать очередей в высоковариабельной среде, нужно либо иметь избыточную пропускную способность (чем выше вариабельность - тем выше избыток. А в разработке вариабельность ой как высока...) либо... не создавать очередей. Дробить все на кусочки и пропускать через систему кусочками. Если мы передаем ИТ-систему в поддержку, то не обязательно приходить к команде поддержки только когда все на 100% готово (и функционал и документация). Если выдавать все маленькими порциями, то перевариваться оно будет на много быстрее. Тут же используются принципы вытягивания для обеспечения "точно вовремя" и принципы синхронизации параллельных потоков. В общем, очень похоже на TPS.
  4. Применять жесткую стандартизацию, что бы снизить вариацию, повысить гибкость и обеспечить предсказуемость. Стандартизация - отдельная тема системы разработки продукции в Тойота. До недавнего времени стандарты у меня ассоциировались с чем-то неизменным, тяжелым, неэффективным и ненужным. Признаюсь, сейчас я радикальным образом изменил свое мнение. Мало того, начал замечать, сколько возможностей упускается из-за отсутствия стандартизации. Например, есть 4 команды и в каждой из них свой собственный скрам (специально для скептиков - скрам эволюционирует и это нормально. В разных командах по-разному...) Если бы скрам был бы менее "разный", то результаты ретроспектив можно было бы шарить между командами, в результате чего быстрее эволюционировать.
Люди
  1. Развивать систему главных инженеров для интеграции всего процесса разработки. Система главных инженеров в Тойота - отдельный разговор. Идея такого человека мне очень понравилась. Во-первых, главный инженер отвечает за новый продукт от и до. От разработки концепции нового автомобиля, до послепродажного обслуживания проданных тачек. И он единственный, кто отвечает за все это. Есть еще и другое приключение в должности главного инженера - группы разработки формально не подчиняются ему. И руководство производится исключительно за счет годами заработанного авторитета и доверия (что бы стать главным инженером в Тойота, зарабатывать доверие нужно 10-15 лет!!! Это явно не спроста). 
  2. Создать организационную структуру, которая позволяет сочетать функциональную компетентность и межфункциональную интеграцию. В Тойота используют матричную структуру! Я был удивлен. Настоящая матричная структура, в том виде, как оно описывается в классических книжках. Каждый центр разработки состоит из "функциональных шахт" - групп, специализирующихся на определенной функции. Есть мнение, что такая структура может эффективно работать только благодаря опытному и уважаемому главному инженеру.
  3. Повышать уровень технических знаний всех инженеров. Здесь стоит акцент на слове "технический". Тойота делает ставку на углубление, а не расширение знаний своих инженеров. В итоге в Тойота есть множество людей, знающий практически все, про практически ничто. Кто-то посвящает свою жизнь разработке ручек стеклоподьемников... Или кнопок аварийки... Для западных компаний (где принято инженерам через курсы МВА уходить в менеджеры) это кажется дикостью. Но в совокупности с предыдущими двумя принципами этот подход Тойоты реально работает.
  4. Сделать поставщиков составной частью системы разработки продукции. Про это читал у Вуммека... В какой-то момент Lean-компания обнаруживает, что большая часть ценности добавляется уже за пределами компании. Что бы продолжить борьбу с потерями, необходимо сделать поставщиков своим собственным продолжением, включить их "в семью". Ровно это и происходит в Тойота.
  5. Создать систему обучения и непрерывного совершенствования. Способность учиться позволяет Тойоте без опаски обучать принципам своей работы даже прямых конкурентов: "пока они освоят то, о чем мы им рассказали, мы уже будем далеко впереди". Кстати, а сколько в вашей команде прочитано книг по специальности за последний месяц? ;)
  6. Сформировать культуру постоянного стремления к совершенству. Это немного ассоциировалось у меня с самобичеванием. Культура Тойоты - это постоянный акцент на собственных недостатках. Именно это заставляет их все двигаться и двигаться вперед. Именно по этой причине TPDS нельзя внедрить, это можно только выращивать.
Технологии
  1. Адаптировать технологию к потребностям людей и процесса. Тойота достаточно консервативная организация, и не торопится внедрять очередное красивое ИТ-решение, о котором совсем недавно только услышали на конференции. Технологии не относятся к конкурентному преимуществу ни разу - их легко копировать. В отличии от ДАО.
  2. Координировать работу организации с помощью простых средств визуальной коммуникации. Здесь возникают мои любимые канбаны, и отчет формата А3. Отчет формата А3 - такой же просто инструмент как и метод "5 почему". Просто напишите отчет на листе А3. Не хватает листа А3, тогда используйте А4. ("5 почему" - тоже достаточно простой метод. Видите нежелательное явление? Спросите себя "почему?" 5 раз и с очень хорошей вероятностью вы доберетесь до корневой причины. Правда!)
  3. Использовать эффективные инструменты стандартизации и организационного обучения. Опять стандарты. Если у вас нет стандартов - у вас не будет кайдзен. И это правда. Если какое-то дело вы каждый раз выполняете будто впервые, то как можно это улучшить? В качестве стандартов в Тойота очень любят чек-листы, за которые отвечают те, кто их использует (а не служба качества или еще кто бы то ни было)
Книга дала очень много поводов подумать и оставила после себя ряд идей, которые скоро пойдут во внедрение...

Рекомендую.

Tags: