«Та самая цель» в разработке на заказ

Не так давно я прочитал роман Эли Голдрата «Та самая цель». В силу привычки извлекать из всего пользу, мне захотелось применить познания его Теории Ограничений
в критериях нашей компании, занимающейся разработкой программного обеспечения на заказ. В этой статье я попробую коротко выложить главные идеи из книжки, а потом сделать выводы в критериях собственной предметной области. Буду рад если кто-то заинтересуется романом, ибо он того стоит. Указания на ошибки в моих беспристрастных и логически идеальных рассуждениях тоже приветствуются.

Определение цели

1-ая идея, с которой и начинается сюжетная линия, — это определение целей компании. Как утверждает Эли Голдрат, «та самая цель» только одна и главный герой проводит несколько глав, мучительно пытаясь её уяснить. «Что же определяет удачливость предприятия?», — терзают его сомнения, — «может быть минимизация издержек либо стопроцентное внедрение производственных мощностей?». Поначалу мне эти мучения показались наигранными — прибыль, вот основная цель хоть какой компании и та мысль, до которой главный герой доходит спустя некое время. Но почему Голдрат желал показать что это неочевидно?

Через пару дней после того как я прочел несколько первых глав, директор компании соперников позвал меня пообщаться с их менеджером проектов и маркетологом на тему роста эффективности производства. Так как я всегда с наслаждением помогаю соперникам, то принял приглашение. 1-ый мой вопрос был: «Какие главные цели стоят перед вашей компанией?». Менеджер ответил: «эффективное управление разработчиками, среднее рассредотачивание задач». Рекламщик произнесла: «поиск многообещающих заказчиков». Их директор, заподозря подкол, прищурился и стал внимательно глядеть, ждя ответа. Я поведал про «ту самую цель».

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

После чего я начал колебаться в собственных морально-нравственных качествах, но разводить философию не стал. Потому волевым решением примем максимизацию прибыли за основную цель компании и выберем метрики, нужные для её измерения:


* Незапятнанная прибыль
* Return Of Investment = (отдача от инвестиции — цена инвестиции) / цена инвестиции
* Валютный поток

Любители четкого перевода и здравого смысла могут сделать возражение: цель — это что-то чётко определённое, что может быть достигнуто. Потому мы будем гласить быстрее о процессе непрерывных улучшений, результатом которого является неизменное роста трёх обозначенных выше характеристик. Принципиально осознавать, что положительным эффектом можно именовать только одновременное их улучшение. К примеру миллион прибыли в месяц — это отлично, если вложения составили 5 миллионов, но плохо если вложен был млрд. Аналогично с валютным потоком. Прибыль может быть большой к концу квартала, когда получены средства за несколько проектов, но если в 1-ые два месяца валютного потока не хватит чтоб выплатить заработной платы программерам, то компания не станет существовать.

Всё это звучит просто и уместно, но встаёт вопрос — что все-таки необходимо делать, чтоб начать процесс непрерывных улучшений?

Характеристики Элияху Голдрата

Предлагается рассматривать другие характеристики:

  • Скорость генерации дохода
  • Связанный капитал
  • Скорость операционных расходов


Определения:


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

Данные определения оставляют некий простор для внедрения. Главное в их то, что они взаимосвязаны и могут быть применены при исследовании процессов на любом производстве. Разглядим несколько примеров. Арендная плата за кабинет, заработной платы сотрудникам, расходные материалы — это всё операционные издержки (если мы не собираемся перепродать маркеры либо бумагу). Приобретенное оборудование и программное обеспечение — это связанный капитал.

Малость труднее дело обстоит с средствами, потраченными на увеличение квалификации служащих и временем, вложенным в разработку разных нужных библиотек и компонент. В силу специфичности IT отрасли, будем считать умственную собственность «вещью», которая может быть продана.

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

Зависимые действия и статистические отличия

До того как мы попытаемся применить обозначенную выше теорию к практике работы IT компании и выработать практические советы по осуществлению процесса непрерывных улучшений, давайте разглядим ещё два принципиальных понятия:

  • Зависимые действия
  • Статистические отличия

1-ое значит, что одна операция в производстве не может начаться пока не закончена другая. К примеру чтоб дизайнер мог сделать пользовательский интерфейс, ему необходимо получить от аналитика требования по данному функционалу. Чтоб программер мог окончить соответственный компонент, ему нужна графика от дизайнера. Тестировщику требуется дождаться окончания работы программера, чтоб проверить стабильность и соответствие компонента требованиям. Добавьте сюда вероятные взаимодействия с серверной командой, представителями заказчика, отделом продаж и получится набор достаточно длинноватых цепочек, связывающих нашу компанию по рукам и ногам. А ведь для генерации дохода нужно успешное окончание всех событий от первого до последнего, причём порядок в большинстве случаев фиксирован.

Основной постулат теории ограничений говорит: цепь не посильнее, чем слабейшее её звено.

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

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

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

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

Что все-таки при всем этом происходит? Давайте возьмём Четыре блюдца — они будут шагами производства, кучу монет и игральную кость. Монеты должны перекочевать из одной кучи в другую, поочерёдно побывав в блюдцах 1, 2, Три и 4. В первом шаге мы кидаем кость и перекладываем из кучи в 1-ое блюдце столько монет, сколько у нас выпало. Потом кидаем кость ещё раз и перекладываем из первого блюдца во 2-ое столько монет, сколько выпало в сей раз, но не больше чем у нас есть в первом блюдце. И т.д., пока монеты не окажутся «обработанными».

Так как средняя скорость движения монет меж блюдцами равна (1 + Два + Три + Четыре + 5 + 6) / 6 = 3.5, то можно представить, что за 20 итераций мы получим 20 * 3.5 — приблизительно 70 монет.

Опыт показал реальную «скорость генерации дохода»: 50 девять монет обработано и ещё 10 застряло в связанном капитале (хотя у их были все шансы пройти от начала до конца). Таким макаром, система работала лишь на 84% от ожидаемой средней мощности:

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

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

Выводы

В заключение сформулирую несколько догадок, которые я сделал себе и желал бы вынести на обсуждение.

Лучше не начинать задачку, если она находится в зависимости от окончания другого действия и не может быть закончена в последнее время. Ждя узенькое звено и пытаясь сделать часть задачки заблаговременно, мы создаём связанный капитал. К примеру, если серверный код ещё не готов, мы можем написать код взаимодействия с сервером на клиенте, выводящий характеристики в лог. Когда сервер будет написан, разработчику всё-равно придётся возвратиться к модулю взаимодействия, поновой вспомнить как он работает и поправить неучтённые отличия. Огромное количество незавершённых задач расходует дополнительное время, так как мы повсевременно думаем о их и перебираем в поисках способности окончить. Допустим, мы знаем что не можем окончить ничего из начатого, пока коллеги не доделают свою работу. В таком случае делему необходимо решать на уровне управления проектом, пытаясь прирастить производительность узеньких звеньев, а не работая впрок.

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

Временами случается и оборотная ситуация, когда проект для клиента закончен и необходимо занять разработчика чем-нибудь. Мы, как компания желающая перейти от аутсорсинга на продуктовую разработку, в таких случаях придумывали программеру «свой» проект. Причём проектов таких начинали много, так как разработчики сильны в различных областях и ориентация была конкретно на их навык. Также числилось что проект будет не наилучшего свойства, если на нём поочерёдно поработают 10 человек. В конечном итоге у нас накопилось сильно много «продуктов», ни один из которых не дошёл до конечного потребителя, т.е. не воздействовал на скорость генерации дохода. Большая часть из их просто незакончены. Казалось бы, ничего ужасного — зато мы избежали простоя программистов, но тем был сотворен большой объём связанного капитала. Мы тратим на эти проекты уйму времени временами пытаясь продолжить разработку, но в главном вспоминая «что же тут происходит» либо решая «переписать эту часть, так как вышли новые библиотеки» либо «мы научились делать лучше». Сейчас при разработке собственных товаров мы сначала проводим планирование, выделяем все нужные ресурсы и следуем плану пока проект не будет закончен. А если у разработчиков случаются простои, то они могут почитать книгу в это время.

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