Недавно я дочитала роман Оли Голдратт «Та же цель» .
Из-за привычки извлекать из всего пользу, мне захотелось применить свои знания Теории ограничений в контексте нашей компании по разработке программного обеспечения на заказ.
В этой статье я попытаюсь обобщить основные идеи книги, а затем сделать выводы в контексте моей предметной области.
Буду рад, если роман кого-то заинтересует, потому что оно того стоит. Указание на ошибки в моих объективных и логически безупречных рассуждениях также приветствуется.
Определение цели
Первая мысль, с которой начинается сюжетная линия, — это определение целей компании.Как утверждает Голдратт, есть только одна «одна и та же цель», и главный герой проводит несколько глав, мучительно пытаясь понять ее.
«От чего зависит успех предприятияЭ» его терзают сомнения, «может быть, минимизация затрат или 100% загрузка производственных мощностейЭ» Поначалу эти муки показались мне фальшивыми - выгода , это главная цель любой компании и идея, к которой через некоторое время приходит главный герой.
Но почему Голдратт хотел показать, что это не очевидно? Через пару дней после того, как я прочитал первые несколько глав, директор компании-конкурента пригласил меня поговорить с их руководителем проекта и специалистом по маркетингу на тему повышения эффективности производства.
Поскольку мне всегда нравится помогать своим конкурентам, я принял приглашение.
Мой первый вопрос был: «Каковы основные цели вашей компанииЭ» Менеджер ответил: «Эффективное управление разработчиками, оптимальное распределение задач».
Маркетолог сказал: «Ищу перспективных клиентов».
Их директор, заподозрив подвох, прищурился и стал пристально смотреть, ожидая ответа.
Я говорил о «той самой цели».
Казалось бы, фраза «главная цель предприятия — получение прибыли» — это аксиома, которую усвоили все люди, изучавшие экономику.
Качественный программный продукт сам по себе не превратится в деньги, если его не продать, так же как и клиент не станет источником прибыли, пока его потребности не будут удовлетворены.
Практика показала, что сотрудники компании считают своей целью хорошее выполнение своих обязанностей.
Поскольку статистическая выборка была небольшой, я спросил нашего технического директора: «Какова цель нашей компанииЭ» Он ответил: «Чтобы сделать крутой софт и оставить след во вселенной», — потом подумал и добавил, — чтобы наши программы нравились людям.
А также сделать мир лучше».
После этого я начал сомневаться в своих моральных качествах, но философией не занимался.
Поэтому волевым решением примем максимизацию прибыли в качестве основной цели компании и выберем метрики, необходимые для ее измерения: * Чистая прибыль * Возврат инвестиций = (доходность инвестиций - стоимость инвестиций) / стоимость инвестиций.
* Денежный поток Любители точного перевода и здравого смысла могут возразить: цель — это нечто четко определенное, чего можно достичь.
Поэтому мы, скорее, поговорим о процесс постоянного улучшения , результатом чего является постоянное увеличение трех указанных выше параметров.
Важно понимать, что только одновременное их улучшение можно назвать положительным эффектом.
Например, миллион прибыли в месяц — это хорошо, если инвестиции были 5 миллионов, но плохо, если инвестиции были миллиарды.
То же самое и с денежным потоком.
Прибыль может быть большой в конце квартала, когда деньги поступят на несколько проектов, но если в первые два месяца денежного потока не хватит на выплату зарплат программистам, то компания прекратит свое существование.
Все это звучит просто и разумно, но возникает вопрос – что нужно сделать, чтобы начать процесс постоянного совершенствования?
Показатели Олияху Голдратта
Предлагается рассмотреть альтернативные показатели:- Скорость получения дохода
- Связанный капитал
- Уровень операционных расходов
Связанный капитал — это все деньги, вложенные системой в приобретенные товары, которые можно продать.
Операционные расходы — это все деньги, которые система тратит на превращение связанного капитала в источник дохода.
Эти определения оставляют некоторый простор для применения.
Главное в них то, что они взаимосвязаны и могут быть использованы для изучения процессов на любом производстве.
Давайте посмотрим на несколько примеров.
Аренда офиса, зарплата сотрудников, расходные материалы – это все эксплуатационные расходы (если мы не собираемся перепродавать маркеры или бумагу).
Приобретаемое оборудование и программное обеспечение связано с капиталом.
Немного сложнее ситуация с деньгами, потраченными на развитие персонала и временем, вложенным в разработку различных полезных библиотек и компонентов.
В силу специфики ИТ-отрасли мы будем считать интеллектуальную собственность «вещью», которую можно продать.
Теоретически основная идея состоит в том, чтобы максимизировать скорость получения дохода при минимизации связанного капитала и уровня операционных расходов.
С операционными расходами все понятно – чем меньше мы платим за офис, тем больше прибыль.
То же самое и с получением дохода – доллар, полученный сегодня, лучше, чем доллар завтра, а еще лучше получить два доллара сегодня.
Менее очевидно то, что связанный капитал увеличивает эксплуатационные расходы.
Пример: Чем больше компьютеров используется для создания программного обеспечения, тем больше электроэнергии они потребляют. Полуфабрикаты на мебельной фабрике нужно хранить на складе, перевозить, учитывать и т. д. Программист, в образование которого вложено много денег, имеет высокую квалификацию и, соответственно, требует большую зарплату.
С этой точки зрения кажется рациональным, что разработка собственных продуктов более прибыльна, чем разработка по индивидуальному заказу, поскольку вы можете достичь более высоких темпов получения дохода с меньшими затратами капитала.
Зависимые события и статистические отклонения
Прежде чем мы попытаемся применить изложенную теорию к практике ИТ-компании и разработать практические советы по реализации процесса непрерывного совершенствования, давайте рассмотрим еще две важные концепции:- Зависимые события
- Статистические отклонения
Например, чтобы дизайнер мог создать пользовательский интерфейс, ему необходимо получить от аналитика требования к этому функционалу.
Чтобы программист выполнил соответствующий компонент, ему нужна графика от дизайнера.
Тестировщику необходимо дождаться окончания работы программиста, чтобы проверить стабильность и соответствие компонента требованиям.
Добавьте сюда возможные взаимодействия с серверной командой, представителями клиентов и отделом продаж, и вы получите набор довольно длинных цепочек, связывающих нашу компанию по рукам и ногам.
Но для получения дохода необходимо успешное завершение всех событий от первого до последнего, причем порядок чаще всего фиксированный.
Основной принцип теории ограничений заключается в том, что прочность цепи зависит от ее самого слабого звена.
Это означает, что скорость получения дохода определяется эффективностью самого слабого звена в цепочке.
Если дизайнер поставляет материалы быстрее, чем программист успевает их обработать, то скорость дизайнера не окажет положительного влияния на скорость всей системы.
Аналогично, если программист быстро добавляет функционал, но низкий уровень автоматизации тестирования увеличивает время, необходимое для контроля качества, то этот функционал не будет поставлен, пока тестировщики не закончат свою работу.
Чтобы представить постулат более наглядно, Голдратт приводит пример школьников, отправляющихся в поход. Группа должна полностью добраться из точки А в точку Б, причем время, затраченное на решение этой задачи, будет не меньше, чем время, которое потратил бы самый медленный ее участник.
Теперь поговорим о статистических отклонениях.
Измерить скорость дизайнера, программиста или тестировщика довольно сложно.
Наша профессия слишком творческая.
Допустим, мы построили команду так, чтобы средние показатели соответствовали общей пропускной способности системы.
То есть аналитик в среднем ставит столько задач, сколько необходимо за итерацию; программисты, исходя из средней скорости, выполняют их вовремя и передают группе тестировщиков.
Самым глупым в такой ситуации было бы предположить, что скорость системы в конечном итоге будет равна средней скорости, с которой мы выровняли наши события — этапы разработки.
Проблема в статистических отклонениях.
У дизайнеров иногда болит голова, а иногда, наоборот, их посещает муза.
Программисты могут выпустить больше кода, чем ожидалось, или внезапно уйти в отпуск и т. д. Что произойдет потом? Возьмем 4 блюдца – это будут этапы производства, связка монет и игральная кость.
Монеты должны перемещаться из одной кучки в другую, поочередно посещая блюдца 1, 2, 3 и 4. На первом этапе мы бросаем игральную кость и перекладываем из кучки в первое блюдце столько монет, сколько у нас получилось.
Затем снова бросаем игральную кость и перекладываем из первого блюдца во второе столько монет, сколько выпало на этот раз, но не больше, чем у нас есть в первом блюдце.
И так до тех пор, пока монеты не будут «обработаны».
Поскольку средняя скорость движения монет между блюдцами равна (1+2+3+4+5+6)/6=3,5, то можно предположить, что за 20 итераций мы получим 20*3,5 — примерно 70 монет. Эксперимент показал реальную «скорость получения дохода»: 59 монет были обработаны и еще 10 застряли в связанном капитале (хотя у них были все шансы пройти от начала до конца).
Таким образом, система работала всего на 84% от ожидаемой средней мощности: 
Отсюда один из выводов: не стоит полагаться только на скорость разработки при оценке проекта.
Хотя это звено чаще всего является наиболее трудоемким, а значит и узким, скорость работы системы может быть еще ниже в результате статистических отклонений.
Кроме того, мы не учли, что связанный капитал, появляющийся из-за статистических отклонений, увеличивал норму операционных расходов по мере работы системы, а значит, реальная ситуация еще хуже.
выводы
В заключение сформулирую несколько предположений, которые я для себя сделал и хотел бы вынести на обсуждение.Желательно не начинать задание, если оно зависит от завершения другого события и не может быть выполнено в ближайшее время.
Выжидая узкого места и пытаясь выполнить часть задачи заранее, мы создаем связанный капитал.
Например, если серверный код еще не готов, мы можем написать код взаимодействия с сервером на клиенте, выводя параметры в журнал.
Когда сервер будет написан, разработчику все равно придется вернуться к модулю взаимодействия, заново вспомнить, как он работает, и исправить неучтенные различия.
Большое количество незавершенных задач отнимает дополнительное время, поскольку мы постоянно думаем о них и просматриваем их в поисках возможностей для их завершения.
Допустим, мы знаем, что не сможем завершить начатое, пока наши коллеги не закончат свою работу.
В этом случае проблему нужно решать на уровне управления проектом, стараясь повысить продуктивность узких мест, а не работать на перспективу.
При поиске новых проектов обрабатывается достаточно большое количество потенциальных клиентов.
Со многими из них мы вступаем в стадию активных переговоров.
Иногда возникают ситуации, когда все производственные мощности уже загружены, а переговоры с новыми заказчиками еще продолжаются.
В этом случае нужно сказать отделу продаж – «не варите горшок».
В противном случае мы получаем портфель заказов, которые не были начаты и, возможно, никогда не будут начаты, но теряют время на взаимодействие с клиентами: ответы на их технические вопросы, просьбы что-то изучить или оценить и т. д. Аргумент «жалко избавиться от потенциального проекта» имеет больший психологический фактор, чем рациональный.
Поиск заказов — это всего лишь один из этапов производства в заказной разработке, и если он имеет более высокую пропускную способность, чем другие этапы, то создание сопутствующего капитала следует прекратить, особенно если существует вероятность того, что он не будет конвертирован в получение дохода.
Время от времени случается и обратная ситуация, когда проект для клиента закончен и разработчику нужно что-то сделать.
Мы, как компания, желающая перейти от аутсорсинга к разработке продукта, в таких случаях придумывали для программиста «свой» проект. Более того, таких проектов было запущено много, потому что разработчики сильны в разных областях и упор был сделан на их навыки.
Также считалось, что проект будет не самого лучшего качества, если над ним будут работать поодиночке 10 человек.
В результате у нас накопилось очень много «продуктов», ни один из которых не дошёл до конечного потребителя, т.е.
не повлиял на скорость получения дохода.
Большинство из них просто незакончены.
Казалось бы, ничего страшного — но мы избежали простоя программистов, но тем самым был создан огромный объем связанного капитала.
Мы тратим много времени на эти проекты, периодически пытаясь продолжить разработку, но в основном вспоминаем «что здесь происходит» или решаем «переписать эту часть, потому что вышли новые библиотеки» или «мы научились делать лучше».
Теперь при разработке собственных продуктов мы в первую очередь проводим планирование, выделяем все необходимые ресурсы и следуем плану до завершения проекта.
А если у разработчиков случаются простои, они могут за это время прочитать книгу.
Всем, кто дошел до этих строк, я хочу сказать спасибо за проделанную интеллектуальную работу и желаю держать свой ум широко открытым для новых идей.
Мир устроен логично, нам остаётся только правильно понять предпосылки и, как неизбежное следствие, добиться желаемого результата.
Теги: #Управление проектами #Теория ограничений #связанный капитал #статистические отклонения #генерация дохода #зависимые события #Управление проектами
-
История Apple От Начала До Наших Дней
19 Oct, 24 -
Я Поместил Pdo_Mysql В Php В Mac Os X 10.5.
19 Oct, 24 -
Spider — Новая Платформа Amd
19 Oct, 24 -
Pwn2Own 2015: Первые Итоги
19 Oct, 24
