19.03.2012

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

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

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

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

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

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

После этого я начал сомневаться в своих морально-нравственных качествах, но разводить философию не стал.

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

* Чистая прибыль
* Return Of Investment = (отдача от инвестиции — стоимость инвестиции) / стоимость инвестиции
* Денежный поток

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

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

Показатели Элияху Голдрата

Предлагается рассматривать альтернативные показатели:

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

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

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

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

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

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

Зависимые события и статистические отклонения

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

Зависимые события
Статистические отклонения

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

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

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

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

Павел Сумароков — директор «Al Digit» г. Омск

https://www.lobanov-logist.ru/library/352/58595/

https://ekspertov.ru/

дата: 00.00.0000 00:00:00 просмотров: 1143

рейтинг:

(Нет голосов)