Пол Грэм: Иная сторона «шедевров в срок»

Автор оригинала: Paul Graham
  • Перевод
«Хорошие художники создают, великие художники крадут, а настоящие художники – выполняют заказ вовремя.»

The Other Half of «Artists Ship»

Пол Грэм, Ноябрь 2008

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

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



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

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

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

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

Если компании займутся этим, их ждут сюрпризы. Джоэль Спольски недавно рассказывал на «Y Combinator» о продаже программного обеспечения корпоративным клиентам. Он сказал, что в большинстве компаний решение о покупке софта стоимостью около 1000 долл. принимают менеджеры без каких-либо дополнительных одобрений. Приобретение более дорогого софта обычно должно одобряться комиссиями. И тогда «высиживание» ими решений о покупке становится настолько дорогим для продавцов, что они вынуждены брать за свои продукты 50 тыс. долл. вместо 5 тыс. долл.

По-видимому, цель всех этих комиссий — не допустить бесполезных трат денег компании. А в результате компания платит в десять раз больше.

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

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

В менее далекие времена закон Сарбейнза-Оксли практически уничтожил рынок первичных размещений ценных бумаг (IPO) в США. Совсем не этого хотели авторы этого законопроекта. Они просто хотели добавить немного проверок публичных компаний. Но они забыли подумать об их стоимости. Они забыли, что компании, прибегающие к IPO, в массе своей довольно стеснены в средствах и что дополнительная нагрузка проверками, которую не заметит, например, Дженерал Электрик, может просто лишить их возможности привлечь финансирование на рынке ценных бумаг.

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

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

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

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

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

В больших компаниях, программные продукты должны пройти несколько одобрений прежде их запустят. И стоимость этого может достигать огромных размеров, предела нет. Я недавно разговаривал с группой из трех программистов, стартап которых был куплен несколько лет назад большой компанией. Когда они были независимые, они могли вносить изменения мгновенно. Теперь, по их словам, две недели это минимальный срок за который они могут запустить новый код в работу.

Однако это не сделало их менее продуктивными. Они просто стали ненавидеть работу по найму.
Вот что наглядно демонстрирует желание программистов усердно работать: эти ребята заплатили бы за немедленный запуск кодов в работу, как они привыкли это делать. Когда я спросил их, поменяли бы они 10% от суммы, заплаченной при приобретении, на возможность мгновенного запуска новых кодов в работу, все трое сразу согласились. Тогда я спросил, а сколько бы максимально процентов от суммы они готовы за это отдать. Они сказали, что не хотят об этом даже думать, боясь зайти слишком далеко, но я чувствую, что они бы отдали до 50 процентов.

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

Также как и комиссии по одобрению приобретения программного обеспечения.

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

Известная максима Стива Джобса «даешь шедевры в срок» (artists ship) работает в обе стороны. Разработчики не только могут закончить работу в срок. Они настаивают на этом. Будешь препятствовать им — останешься вообще без шедевров.

Спасибо за помощь с переводом Сергею Даньшину и компании Edison (которая делала технический аудит экономической игры и систему централизованного управления видеосъемкой).

«Шедевры точно в срок» – переводить короткие и емкие афоризмы Стива Джобса – задача, мягко говоря, не из легких. На языке оригинала «шедевры точно в срок» укладываются буквально в три слова – «Real artists ship», причем смысл этой фразы слегка варьируется в зависимости от контекста. Например, «Jobs also reminds his employees that „real artists ship,“ by which he means that delivering working products on time is as important as innovation and killer design» («выполнение планов точно в срок не менее важно, чем инновации и уникальный дизайн»). В какой-то момент в качестве рабочей версии перевода «Real artists ship» было принято брутальное «шедевр, суки, и чтобы во время», пока мы не наткнулись на продолжение известного афоризма про художников: «Good artists create, great artists steal, and real artists ship» – «хорошие художники создают, великие художники крадут, а настоящие художники – выполняют заказ вовремя». В итоге остановились на «шедеврах точно в срок».

[источник]
Edison
96,00
Изобретаем успех: софт и стартапы
Поддержать автора
Поделиться публикацией

Комментарии 11

    +2
    Одна ошибка, которая может стоить корпорации миллионы, скорее всего корпорацию не убьёт. Такая же ошибка, стоящая жалкие тысячи, скорее всего убьёт стартап.
    Корпорации потому и корпорации, что платят больше за собственную безопасность. Не задумывающийся об этом стартап корпорацией не станет. Свою ошибку найдёт.
      –1
      Набор слов, если честно :)
      +1
      Причём, эти дорогущие проверки могут оказаться бесполезными. На данный момент мой Хром разучился запоминать место прокрутки страницы, и мне приходится каждый раз вручную прокручивать. И так уже неделю -_-
        0

        Скорее всего, дело не в хроме, а в вёрстке какого-то из вебсайтов. Недавно только встретил такой косяк в своём же проекте. Тоже подумал про Хром сначала — потом оказалось, что проблема с тем, что в стилях было прописано body { overflow-x: hidden }, что и ломало нормальную прокрутку.

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

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

          Что за детский сад написан в этой статье?


          Если утром тебя вдруг посетила идея о чем-то новом, ты можешь написать ее и протолкнуть на рабочие серверы уже к обеду.

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


          Когда они были независимые, они могли вносить изменения мгновенно. Теперь, по их словам, две недели это минимальный срок за который они могут запустить новый код в работу… Когда я спросил их, поменяли бы они 10% от суммы, заплаченной при приобретении, на возможность мгновенного запуска новых кодов в работу, все трое сразу согласились… Они сказали, что не хотят об этом даже думать, боясь зайти слишком далеко, но я чувствую, что они бы отдали до 50 процентов.

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

            0
            Вы вырвали первый пункт из контекста и спорите с самим собой. Речь именно о стартапе.

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

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


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

            В статье мне очень понравились эти два предложения. Простая, очевидная и замечательная мысль.
              0
              Real artists ship — настоящие художники доставляют.
              Дословный перевод тоже не плохой, пусть и теряет смысл про сроки)
                0
                Вроде бы всё правильно написано. Но в этом нет никакой новизны. Просто красиво расписан банальнейший принцип, на котором строится любой бизнес: прибыль берётся из риска. Чем больше рисков компания на себя берёт, тем выше может быть её прибыль в случае успеха. Понятно, что проверки снижают прибыльность множеством способов. Но они же снижают и риски. И не существует способа снизить риски, не снизив при этом прибыльность. Во всём виновата проклятая конкуренция. Если гипотетически предположить, что существует магический способ снизить какой-то риск без дорогостоящей проверки, то тогда и конкуренты будут успешно его применять, и конкуренция вынудит снизить цену. Прибыльность всё равно уменьшится. Пусть не из-за проверок, повышающих себестоимость, а из-за снижения отпускной цены в условиях конкуренции. Проблема больших компаний состоит в том, что они не могут позволить себе большие риски. У них жестко задан потолок риска, который в принципе может считаться приемлемым. Но и никто не ждёт от них высоких прибылей. Пусть прибыль будет всего 4% годовых. Но зато это 4% от 10 миллиардов. А у стартапа прибыль может составить 300%, но от вложения объёмом всего в 100 тыс. Понятно, что когда у тебя есть всего 100 тыс., ты вынужден брать на себя любые риски, чтобы иметь возможность надеяться на эти 300%. Но если у тебя есть 10 миллиардов, то тебе проще вложить их в компанию, которая гарантированно будет приносить 4% в год.
                  0
                  В статье проводится две линии:
                  «закупки» и «поставка нового кода/функций в уже существующий продукт».

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

                  Про поставку новых функций
                  Для меня вопрос доверять или не доверять разработчикам это вопрос используемых ими технологий и метрик.
                  Если уровень профессионализма высокий, количество дефектов выявляемых Клиентами равно 0 или близко к этому, количество ошибок выявляемых при тестировании минимально, то в этом случае я склонен сокращать количество проверок на выходе при доставке функционала клиенту.
                  Второй момент, который тут необходим это качество выполненной постановки Бизнес-аналитиком, если функционал проработан с пониманием бизнес-задачи/проблемы клиента и производимые решения практически на 100% попадают в ожидания клиентов, то я также склонен уменьшать количество выходных проверок.
                  Если процент попадания далек от 100%, то ещё не факт, что то что сделано/разработано должно появится на продуктиве, можно считать это созданным рабочим прототипом, с которым нужно дать поработать Пользователю-Клиенту на тестовом стенде, чтобы он уточнил своё представления и требования к ИТ-решению.
                  И третий момент уровень контроля должен быть соразмерен масштабу бизнеса. Представьте что через вашу систему проходит транзакций в день на 1-2 млрд.рублей, в ней работает несколько тысяч партнеров компании, компания имеет 0,5% с этого объема, представьте что вы кладете систему очередным обновлением на 1-2 дня…
                  Это про управление рисками.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое