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

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

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



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



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

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

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

    * Чистая прибыль
    * 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 человек. В итоге у нас накопилось очень много «продуктов», ни один из которых не дошёл до конечного потребителя, т.е. не повлиял на скорость генерации дохода. Большинство из них попросту незакончены. Казалось бы, ничего страшного — зато мы избежали простоя программистов, но тем самым был создан огромный объём связанного капитала. Мы тратим на эти проекты уйму времени периодически пытаясь продолжить разработку, но в основном вспоминая «что же здесь происходит» или решая «переписать эту часть, потому что вышли новые библиотеки» или «мы научились делать лучше». Теперь при разработке собственных продуктов мы в первую очередь проводим планирование, выделяем все необходимые ресурсы и следуем плану пока проект не будет закончен. А если у разработчиков случаются простои, то они могут почитать книжку в это время.

    Всем кто добрался до этих строк, хочу сказать спасибо за проделанный интеллектуальный труд и желаю держать разум широко открытым для новых идей. Мир устроен логично, нам остаётся лишь правильно понять предпосылки и, в качестве неотвратимого следстивия, добиться нужного результата.
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 20

      +5
      Выводы которые сделаны вконце про согласованную работу разработчиков и продажников гораздо проще нагляднее и понятнее чем долгая игра в слова про «цель».

      К тому же придите к любому инвестору или стратегическому партнеру и скажите что цель компании это прибыль тогда ни партнерства ни инвестиций (то биш денег) вам не видать. Потому что прибыль это краткосрочная цель, стратегия же должна опираться на долгосрочное виденье.
        +1
        Давайте будем честными… Что бы инвестор (или стратегический партнер) не говорил, его в конечном счете интересует только прибыль.

        Вы можете затеять десяток стартапов с гениальными стратегиями, но если они не принесут прибыли, то инвесторы в конечном счете откажутся иметь с вами дело.
          +2
          Прибыль конечно важный момент. Но не нужно говорить что это конечная цель.

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

          Вообще верить что все в мире существует ради денег это тоже самое что верить в бога. Очень однобокий подход. С таким подходом в Мире не было бы google и skype и yandex и тысячи других компаний
            +1
            Хм… Прибыль, как подтверждение состоятельности бизнес-идеи и стратегии выбранной для её реализации, это то, что нужно любому кто затевает свой бизнес.

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

            В данном случае ни автор статьи ни Голдрат не говорили, что деньги это главное. Тут о том, что часто оказывается, что всё вроде есть. И стратегия проработана до мелочей, и работники на уровне, и отношения в коллективе выстроены. А конвертации всего этого в прибыль, почему-то не происходит… Формальные признаки выполнены вроде бы, а результата почему-то нет.
              +1
              Ну так цель это и есть главное. И говорить что цель это заработать деньги то значит говориться что главное это заработать деньги.

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

              Хорошим примером того что подход автора не работает явлется Skype. Компания имеет до сих пор отрицательный кешфлоу. Но все мы помним страшную битву между гуглом и микрософтом за скайп. Потому что люди в своей модели берут не неделю а 10 лет.

              Если у компании стратегия проработана до мелочей, а прибыли нет. Значит стратегия не проработана до мелочей. Опять с ног на голову все переворачивается.
            +3
            вообще очень часто после фразы «давайте будем честным» люди произносят очень сомнительное утверждение неоснованное ни на каких точных фактах.
          0
          Отличная статья… Довольно простой (конечно, когда уже знаешь) и поэтому довольно эффективный подход. Есть на чем подумать.
            0
            В свое время тоже прочитал «Цель» и «Цель 2». Руководствуясь этими принципами — оптимизировал производство в одной из компании, где работал. Поднял чистую прибыль в 3 раза.
            Не останавливайтесь на этой книге, почитайте еще Тома Демарко «Deadline» и посмотрите записи лекций Элияху Голдрата по TOC, очень интересно и пригодится в будущем.
              0
              Спасибо за совет! Поставил «Deadline» ДеМарко в список задач.
                0
                Еще будет очень в тему Коллинз «От хорошего к великому» для подкрепления многих известных автору концепций. Однако же и много нового узнаете.
                0
                Если можно, поделитесь основными идеями, по которых вы проводили оптимизацию — очень интересно
                +1
                Цель компании — создание и производство продукта, нужного людям с разумным учетом реалий мира.

                Деньги — это резаная бумага, не стоит забывать об этом. Далеко не все можно купить за деньги, в том числе и в бизнесе.

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

                Также показателен пример Dell, которая в погоне за прибылью отдавала все большую и большую долю реального производства и разработки в ASUS.
                  +1
                  Забываете все про налоги.

                  Человек регистрирует компанию А регистрируется и заключает с компанией Б контракт о какой-то работе, положим за 15340 рублей в месяц (увидите ниже почему я такую сумму использовал в примере).

                  Как только деньги переходят от компании Б компании А, компания Б должна гос-ву 18% НДС, то есть от 15340 рублей остается 13000 рублей.

                  Теперь, компания А начисляет человеку создавшему компанию зарплату в 10,000 рублей. Для этого компания А обязана взять еще 30% от этой 'начисленной' зарплаты и отдать их гос-ву.

                  Значит компания А должна отдать 3,000 гос-ву и теперь считается что зарплата 10,000 рублей.

                  Гос-во говорит человеку: ты платишь только 13% подоходный налог из твоей зарплаты, тебе начислили 10,000, ты получишь из них 87% на руки, или 8849.56

                  Вопрос: какой настоящий подоходный налог? Ответ достаточно прост: подоходный налог это то, что забрали у компании А, до того, как отдали зарплату человеку: 6490,40 или 42.31%.

                  Кроме того существуют еще корпоративные налоги, налоги связанные со всей другой деятельностью (закупкой товара, материалов, и т.д.), реальные налоги, которые система обязует предприятия выплачивать гос-ву легко переваливают планку в 60%, а если брать во внимание еще и распределенные налоги на дивиденды и потом налог на капитальный доход (или как это по Русски называется, capital gains?), то налоги еще выше. Не удивительно что так мало предпринимательства и что люди не занимаются собственным бизнесом и что так мало конкуренции. В то же время, любые инвистиции всегда направляются на самый надежный с точки зрения риска доход — любая добыча и продажа сырья. Тут нечего и говорить — это наименее рискованный бизнес ( с правильными связями конечно), настоящий кредит получить невозможно для нового бизнеса не связанного с сырьем и продажей материалов.

                  Что хуже, это то что система так же глупо пытается уничтожить свои деньги, следуя другим примерам, и печатание приводит к инфляции, которая составляет не меньше 10% в год.

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

                  Не забывайте про налоги, заработать этот рубль это еще не все, вас сразу начинают грабить.
                    0
                    Сурровость Российского налогового законодательства компенсируется необязательстью его выполнения. Особенно для IT.

                    И уж поверьте мне IT находится в гораздо более сладкой ситуации чем сырьевой бизнес. Частные инвестиции в сырьевой бизнес это настолько геморойно, опасно и нерентабельно что инвесторов нужно корврижками туда заманивать. Идут только когда государство им риски компенсирует, то есть по сути не инвестиции уже
                      +1
                      Необязательность выполнения не освобождает от ответственности. Как впрочем и полное выполнение от нее тоже видимо там не освобождает.
                    +2
                    Если не вдаваться в глубокую философскую дискуссию о добре и зле, которая развернулась выше, а вернуться к конкретной теме, поднятой автором, могу рассказать, как мы начали недавно решать озвученную проблему эффективности и простоя разработчиков.

                    Мы решили использовать<a href=«ru.wikipedia.org/wiki/%D0%9A%D0%B0%D0%BD%D0%B1%D0%B0%D0%BD»канбан-доски уровня компании и уровня проекта. Расскажу про первую.

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



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

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

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

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

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

                    Не могу сказать, что мы уже на 100% набили все шишки и придумали наилучший способ применения. Все еще впереди. Думаю, что со временем напишу статью по итогам использования.
                      0
                      Сорри за битую ссылку, не нашла как отредактировать коммент.
                      Канбан
                        0
                        Звучит как хороший способ визуализации цепочки производства. Главное чтобы ресурс на поддержание достоверности и актуальности информации не превышал выгоду от использования такой доски.

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

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

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

                        Другое дело механизмы работы с деньгами. Они могут быть абсолютно разными.

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

                        Only users with full accounts can post comments. Log in, please.