Траты в бережливой разработке ПО

Mura, Muri, Muda

На самом общем уровне все траты могут быть трех типов.

Mura — «неравномерность»

Под mura понимается нестабильность в методах работы или в результатах процесса. Для процесса это плохо тем, что оборудование и люди должны быть готовы к работе в условиях предельных нагрузок (аврал, новый заказ и иже). Эта «готовность» выливается в дополнительные сопутствующие затраты, которые даже не появились бы при стабильном и равномерном процессе. Одним из способов организации стабильного процесса является использование Канбан. При этом производящий сотрудник сам берет новые задания по мере выполнения предыдущих, запрещается работа более чем с одним-двумя (если двумя, то небольшими) заданиями одновременно и не допускается наличие дефектов в работе, идущей на следующий этап.

Muri — «перегрузка»

Под muri понимается исполнение человеком большего количества работы, чем следовало бы, в единицу времени. Перегрузка сотрудника сейчас несомненно выльется в какие-то проблемы потом, пускай даже в данный краткосрочный период польза от человека и выросла. Овертаймы — ходящий по краю muri принцип. Человек, месяц проработавший по 12 часов, следующий месяц будет просто отходить, и в итоге общая производительность за два месяца будет ниже, чем если бы он спокойно работал эти два месяца по 8 часов.

Muda — собственно «траты»

Под muda понимается то, что не приносит итоговой ценности — собственно «траты». Muda можно классифицировать как минимум двумя способами: классическими семью типами трат и по уровню осознания этих трат. Про семь типов трат поговорим чуть ниже, а пока рассмотрим деление muda по уровню осознания этих трат. К первой категории muda относятся те траты, о которых мы знаем, но которые пока еще не считаем тратами, а думаем о них лишь как о суровой необходимости. Типичный пример: тайм трекинг. В случае, когда заказчик требует отчета по каждому отработанному дню, тайм трекинг необходим. Когда же в конце месяца все спешно садятся и по памяти заполняют необходимое количество часов — это уже ближе к muda. Если осознать, что в данном случае тайм трекинг — это muda, можно предпринять какие-то действия и постараться избавиться от ненужного. Ко второй категории muda относятся те траты, о которых мы тоже знаем, но в отношении которых мы уже достигли просветления. Такие траты — самые очевидные кандидаты на устранение.

Семь принципов трат

В оригинальном подходе Toyota выделялись семь классических трат. При переводе бережливого производства на разработку ПО Мери и Томом Поппендиками эти принципы были наложены на новый контекст, как следствие — появились 7 типов трат разработки ПО.

Частично сделанная работа

Любая часть работы, которая не достигла своего логического завершения, является тратой. Недописанная документация, назакоммитанный код, непротестированный код — все это уже потребовало вложения ресурсов, но еще не предоставило отдачи и более того — потребует ресурсов для завершения.

Дополнительная функциональность

Уже упомянутый выше Таити Оно самой серьезной тратой считал избыточное производство. В контексте разработки ПО этой тратой является дополнительная функциональность. В прошлой статье я уже приводил пример компании Syncplicity, которая проиграла битву сервису Dropbox именно из-за наличия и поддержки дополнительной функциональности, которые на самом деле никому не были нужны. Не стоит делать то, в необходимости и экономической обоснованности чего вы сомневаетесь.

Повторное создание знания

Этот тип трат проявляется в двух подтипах: Знания, которые забываются и создаются заново. Например, вы потратили 2 дня на отлавливание причины необычного дефекта, а когда нашли — быстро устранили проблему. И вот, через год вы снова сталкиваетесь с таким же дефектом, и самое неприятное — вы забыли, в чем была проблема, и вам придется снова тратить два дня на поиск первопричины. Знания, которые создаются сотрудниками, но пропадают в процессе разработки. Это может быть классная идея для пользовательского интерфейса, про которую забыли, или вспомогательная утилита для перенастройки базы данных, которой не пользуются, делая работу ее создателя тратой и попутно затрачивая время на ручное выполнение уже давно автоматизированных действий.

Передача знаний

Сложно описать умение езды на велосипеде в документации: мы просто знаем, как ехать, но это очень сложно сформулировать. Когда мы учим кого-то ездить на велосипеде, мы можем только рассказать базовые принципы, дальше человек должен учиться сам. Передача знаний по какому-то артефакту или модулю в разработке ПО сродни обучению езды на велосипеде в том смысле, что что-то всегда остается лишь в голове первоначального разработчика. Так получивший знания получит лишь некоторую их часть. Если же этому человеку придется передавать знания дальше — они так же будут теряться дальше. Уже на третьем или четвертом шаге знания по артефакту или модулю значительно ниже, чем они были изначально. Такой тип потери знаний можно попытаться закрыть документацией, но ее часто не читают, соответственно помимо потери знаний формируя muda в виде этой самой документации. Вариантами решения проблемы являются:

1. Сокращение количества передач знаний.
2. Обеспечение широкого канала передачи знаний: не через документацию, а лично и очень подробно.
3. Формирование команд по принципу наличия хотя бы одного человека с полным знанием по каждой функциональности.

Переключение между заданиями

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

Задержки

Любые необоснованные задержки в разработке ПО — серьезная трата. Пока разработчик ждет чего-то (ответа от клиента, совета старшего товарища, инструкции «сверху»), он вынужден либо просто просиживать свое время, либо переключаться на другое задание, что, как указано выше, также является тратой. Обычно задержки происходят из-за разнесенности объектов в каком-то измерении, например, из-за наличия в команде сотрудника из Минска и сотрудника из Нью-Йорка или разницей в 8 часов между вами и клиентом. Подобные разнесенности либо подконтрольны вам, либо нет. Если подконтрольны — собирайте разнесенные объекты вместе, например, держите команду в одном городе. Если нет — старайтесь минимизировать задержки, например, возьмите на себя обязанность напоминать клиенту о неотвеченных вопросах.

Дефекты

Все знают прописную истину о том, что позднее обнаружение дефекта несет больше затрат, чем его раннее обнаружение. Сфокусируйтесь на бездефектной разработке, повысьте планку приема качества работы от каждого отдельного разработчика. Сделайте акцент на предотвращение появления дефектов, нежели чем на их исправление после нахождения. Используйте юнит тестирование, где это разумно.

Итого

Мы рассмотрели типы трат, которые чаще всего возникают при разработке ПО. Устранение этих трат позволит вам сфокусироваться на формировании ценности продукта, а не его muda. Стабильная, предсказуемая, спокойная разработка — также залог успеха. Не перегружайте сотрудников: итоговая польза будет меньше, чем при размеренной работе.

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.