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

Вот что писал Young и Vitali.

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

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

Начну с несколько побочных вопросов, а дальше уже перейдем к делу. В той самой книге RTFM (которую я упоминал), был описан один забавный случай: Человек видит на обложке журнала фразу “Как стартовать свой бизнес без проблем?”, купил журнал, открывает и видит большую надпись на весь разворот “НИКАК”.

Так вот, относительно “который может работать без тебя”.  Малый бизнес НЕ может работать без владельца. Максимально, на что можно надеяться, настроить его так, чтобы он мог проработать некоторое время (неделя, месяц, пол года). А все эти штучки-дрючку Киосакиевского разлива (а-ля создать себе пассивный источник дохода), можете выкинуть из головы прямо сейчас. (Кстати, вот мое мнение по поводу Киосаки).

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

Теперь возвращаясь к проблеме.

Думаю, очень многие думают примерно такие мысли “Я – эту задачу могу сделать быстрее, лучше чем любой кому я ее дам. Причем, если я кому-то ее  выдам, то мне придется за это еще заплатить, потом контролировать, чтобы все вышло как надо, объяснять как и что переделать, а зачастую по окончанию переделывать самом. Таким образом я больше времени потрачу на объяснения, контроль и переделки чем если сделаю это сам… Ура-ура… Я таки сам буду делать эту задачу.”

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

1. Я сделаю это задачу лучше чем другие (читай – выше качество и быстрее по времени, в целом эффективнее и дешевле)

2.  Мне придется платить за выполнение задачи (жаба давит).

3. Мне придется контролировать исполнение, давать задачи и просить отчеты ( выполнять нетипичную, плохо понятную и неприятную работу).

4.Я потрачу больше времени на объяснение, контроль и исправления чем сделать задачу самому (опять же – эффективнее).

Идем по пунктам. Сначала разберемся кто виноват, а потом, что делать.

1. Я сделаю это задачу лучше чем другие (читай – выше качество и быстрее по времени, в целом эффективнее)

Скажем у нас есть директор компании в 100 человек.  И он просто нереально крутой программист и может пофиксить баги быстрее всех.  Стоит ли ему НЕ ехать на подписание 10 миллионного контракта, а вместо этого очень эффективно пофиксить баги?

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

Слышу уже голос из зала “Но, блин, я же не директор компании на 100 человек и подписание контракта в 10M у меня сегодня нету. У меня нет стоимости потерянных возможностей”. Так, вот, если все время фиксить баги и педалить код – стоимость ваших потерянных возможностей – это то, что вы никогда не найдете новых контрактов, не продадите ваш продукт, не станете директором этой самой компании из 100 человек. Вы же пишите код, а не разбираетесь в том, как продавать продукт/работаете с людьми, которые дадут отзывы на ваши услуги, ездите на встречи на которых может завязаться знакомство принесущее новый контракт. Вообще, усердное программирование один из самых потрясающих методов убить все потенциальные возможности.

Вообще, положа руку на область желудка, программирование в IT бизнесе имеет примерно такую же важность, как вождение грузовика в доставочном бизнесе. Да, без программистов (водителей) не обойдешься, но в результате sales и marketing рулят и бибикают.

Так что, может быть дать задачу человеку, который сделает ее чуть медленее, а в этот момент, доделать web site, написать документацию и попытаться найти покупателей, на ту байду, которая пишется?

4.Я потрачу больше времени на объяснение, контроль и исправления чем сделать задачу самому (опять же – эффективне).

Вот с этим все обстоит сложнее.  И так и так вы считаете, что вам придется тратить время.

Однако, тут важно остановится, положить руку на область желудка и признаться себе в двух вещах

- задачи с которыми знаком и которые нравятся обычно недооцениваются по времени

- задачи с которыми плохо знаком и которые не нравятся оцениваются слишком высоко.

Именно из этого и выходит, что-нибудь в виде: ” … да я этот графический редактор я сам напишу за 2 дня, а вот если мне придется объяснять и контролировать, то у меня на это уйдет 2 недели”.

Так, что тут желательно таки честно взглянуть и оценить, сколько может уйти времени на исполнение, а сколько на контроль. Относительно “придется все доделать и исправлять” – чуть позже напишу. Кстати, если на контроль выполнения у вас уходит больше чем несколько процентов (ну скажем 5) от времени исполнения, то это значит, что контроль вероятней всего тоже надо делегировать и контролировать того, кто занимается контролем.

3. Мне придется контролировать исполнение, давать задачи и просить отчеты ( выполнять нетипичную и неприятную работу).

Да – придется.  И к этому надо привыкнуть.

Бизнес – это не сладкая река в которой можно делать только то что хочется (педать сверхмощную архитектуру для никому не нужного проекта).

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

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

Такс… Много уже текста написал, а толком ничего не сказал.  Так, что перейду таки к пункту что делать.

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

б) Нужно начать делегировать и учиться на ошибках. Делегирование состоит из 3 частей – подготовка задачи (цель, требования, сроки, отчетность),  контроль в ключевых точках и корректировка, принятие задачи.

Замечу, что фактически все руководители (включая меня) страдают тем, что один из этих пунктов выпадает.

Первая классическая ситуация (плохая подготовка задачи) – “Вася, пойди выкопай яму”, потом обнаруживаем, что он выкопал ее не в том месте и не той глубины и не в те сроки.

Вторая классическая ситуация(плохой контроль в ключевых точках) – “Вася, яму надо выкопать метр, на метр, на метр, к следующему понедельнику (через неделю)”.  Через неделю привозим цемент заливать в яму, а ямы-то и нету, так как Вася забухал. А мы не удосужились потратить 5 минут выглянуть из окна, как движется яма.

Третяя классическая ситуация: “Вася, яму надо выкопать метр, на метр, на метр, к следующему понедельнику (через неделю)”. Пришли поглядели в четверг и в пятницу, что яма продвигается. В понедельник обо всем забыли, во вторник тоже и через где-то месяц навернувшись ночью в эту яму начали возмущаться… какого фига тут выкопана яма.

Есть еще четвертый пункт, но он относится не впрямую к делегированию, а вообще к стилю ведения дел. Обязательно иметь полный список все дел, которые нужно сделать самому и которые были выданы окружающим (можно в электронном, но я рекомендую в бумажном виде – об этом в отдельной статье). Если у вас нету полного списка дел, вы не можете контролировать, так как вы просто не будете помнить, кто и что должен делать.

в) Собственно говоря, дальше вам нужна практика.

Начинайте давать, сначала небольшие задачи и четко приходитесь по пунктам – подготовка задачи, промежуточный контроль, финальный контроль. Собственно говоря, на этом этапе просто нужно выявить свои слабые места. Кому-то хочется побыстрее послать задачу (толком ее не сформулировав), кому-то не хочется держать руку на пульсе или проверять насколько хорошо сделано в конце. Боритесь с своими слабостями. Ваша сегодняшняя слабость превратиться в слабость вашего бизнеса завтра (можете почитать историю моей фирмы, там я расписал, как это произошло)

в) А как же вера в кадры?

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

В общем, как говорится в пословице “доверяй, но проверяй”.  Во первых, доверие должно вырастать из фактов, а не из желания верить. Только, если человек, сделал X раз все четко, качественно и выверено, то это значит, что в X+1 раз ему можно таки доверять. Все дипломы, регалии, хорошие отзывы и т.п. – вторичный признак и должны быть подтверждены фактами.

Тем ни менее, даже доверяя, нельзя пропускать какие-то пункты из нашего списка. Задача все еще должна быть четко сформулирована, так как без формулировки даже самый лучший исполнитель не сможет ее выполнить. В конце нужно настолько же тщательно все проверять, для оценки окончания задачи. Что можно серьезно уменьшить – это промежуточный контроль в случае долгого и успешного сотрудничества.

г) Делегирование больших задач

В какой-то момент от прямого делегирования а-ля “Вася – пойди выкопай яму”, приходится переходить к “Петя – твоя задача организовать пяти Вась, чтобы они засадили двор яблонями”.

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

По этому поводу несколько советов

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

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

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

- Четвертое, это то, что при делегирование больших задач, нужно проходить те же самые пункты, как при обычном делегировании.  Так как задача большая –  то важно поставить цели, объяснить, как эта  задача ложится в больший план (чтобы человек мог сам “доточить” задачу), разбить на этапы.  Дальше, поэтапно контролировать и в конце принять задачу.

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

Фух… Ну вот вроде и все, что хотел сказать. Как писал в начале. Вышла длинная колбаса.

С удовольствием отвечу на какие-то конкретные вопросы и приму замечания.

Знакомо?

Пока я крапаю длинную статью на тему как научиться НЕ делать все самому, решил набросать коротенькую статейку/задачку. Задачка аналогично такой, которая дается на олимпиадах по программированию.

Слегка формализированные правила считалочки.

1) Пусть у нас есть N человек

2) И у нас есть считалка длинной в M слов.

3) Начинаем считать с первого человека, по одному слову на человека.

4) Человек на котором считалка закончилась выбывает.

5) Считалка продолжает считаться с следующего после выбывшего, повторяя пункт 4 и 5.

6) Оставшийся последним человек – выигрывает.

Задача:

Написать программу, которая считает порядковый номер человека который выигрывает. Входные данные N и M.

5 баллов – программа может рассчитать выигрывающего при N и M < 20.

10 баллов – программа может рассчитать при N < 20, а M порядка 1 триллиона (не фига себе считалочка), за разумное время.

25 баллов – программа может рассчитать при N порядка 1 миллиарда, M < 20, за разумное время.

50 баллов – программа может рассчитать при N и M порядка триллиона.

Если вы знаете/придумали решение на 50 баллов, прошу сразу его не бросать в комментарии, а просто написать что вы его знаете (чтобы дать остальным подумать).

Остальные решения вполне welcome в комментариях

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

P.S.  Как оказалось, задача классическая (просто я с ней не сталкивался). На момент написания статьи, я знал решение на 5 и 10 баллов, примерно имел идею на 25 баллов и не знал, как решить на 50 баллов.

Есть какая-то тема по поводу IT, программирования, бизнеса, персональных финансов и иже с ними, которая задевает вашу нежную душу и о которой мне просто необходимо написать?

Жду с нетерпением идей и предложений

Есть одна  особенность “потоков” информации в такой компании. Обычно тех самых владельцев кормят из ложечки говном информацией, которая ну скажем имеет очень слабое отношение к реальности. Кормят их те самые 4+ слоев, которые находятся под ними.

Происходит это по той простой причине, что в своем уме, очень небольшое количество менеджеров хотят признавать свои ошибки (особенно, если это может сказаться на их ЗП, бонусах, должности). Ну и логично, что на верх подается несколько искаженная информация и пройдя через N слоев искажения – она уже содержит истину в гомеопатических объемах.

Например классика такой ситуации – это когда в  корпорации делается большой IT проект и собираются его выкатить через два года и что проект будет нереально крутым. Весь топ менеджмент (включая совладельцев) продолжают верить в это и инвестировать деньги, до тех пор пока 2 года спустя оказывается, что деньги просраны, а проект не просто далек от выпуска, а за это время стал жутким монстром, который проще выбросить, чем довести до ума. При этом достаточно большее количество рядового состава из опоков (QA, программисты и иже с ними) вполне таки подозревали чем это все закончится еще год, до того, как это дойдет до менеджмента.

Так вот, появилась у меня забавная идея. Удивлен, что ее не слишком практикуют. Позволять впрямую контактировать через несколько слоев менеджмента. Чаще всего люди, максимум знают (и общаются) с боссом своего босса. Редко кто общается через 2, а тем более через 3+ уровня.

Так вот – идея, позволить это делать раз в некоторое время.  Например, раз в неделю можно пообщаться через 1 уровень, раз в месяц – через 3, раз в квартал – через 5, раз в пол года – через 7 уровней.  Не думаю, что будет так много людей, которые захотят этот делать, так что беспокоиться о том, что CEO вдруг засыплют письмами.

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

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

Тем не менее, еще раз рекомендую прочитать книгу. Кстати, а вот и блог автора – блог.

Второе, хочу дать ссылочку на статью (теперь уж на английском) – Avoiding Development Disasters. Очень точно описываются почему большие и слишком хорошо финансированные проекты чаще всего заканчиваются полным крахом.

И третья, мысль, которая вышла из вчерашнего спора с другом. Очень многие (особенно хорошие) разработчики говорят, что код должен является единственной и главной документацией (самоописывающий код). Что если нужно создавать отдельную документацию – это плохо, так как появляется второе “отображение” кода, которое может не обновляться и устаревать и расходится с кодом, что только усложняет понимание.

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

О… Пока писал, еще одна мысль всплыла. Опять же, у программистов зачастую есть проблема ownership’а. То есть, они чувствуют, что владеют/отвечают за какой-то кусок работы. И постепенно в этом куске работы, они начинают делать все так, чтобы ИМ было удобно (не думаю о остальных, учитывая что они сами работают над этим участком). Мысль, которую я некоторое время назад сформулировал – владеть нужно проблемой и за нее отвечать, а код должен таки оставаться общий. Именно поэтому код должен комментироваться, документироваться и придерживаться другими методами доступным для остальных разработчиков.

В общем, преамбула совмещается с фабулой и будет многа букаф. Это скорее просто жалобы на тяжелую жизнь, но возможно тебе это знакомо. Короче говоря, у меня нас есть несколько тимов, каждый из которых пишет свой продукт и OEM тим, которые все эти продукты собирает, кастомизируют и раздают оем клиентам. Рулит этим тимом Configuration manager.

На прошлой неделе наш Configuration manager поднял плач Ярославны “как у нас все хуево с качеством, всем пиздец”. Ну ок. В целом, я с ним согласен, но почему так получилось – вопрос интересный. Получилось так, что по целому ряду стратегических решений топ менеджмента, принятых год-полтора назад, стандартный подход – нахуй качество, надо рынок завоевывать, а остальное потом исправим. Ну, рынок завоевали, тока теперь на поддержание этой кучи говна в жизнеспособном состоянии тратятся огромные ресурсы, кастомизации под каждого клиента приходится приделывать болтами и сварочным аппаратом где-то сбоку.

Так вот, прошлонедельный плач был по поводу того, что тестеры из оем находят много багов, относящихся к самому продукту. И мы мол не знаем, что именно получает команда оем от команд продуктовых. Наш Configuration менеджер поднял дискуссию на высоком уровне и в итоге наш VP engineering’а произнес сакраментальную фразу: “А давайте померяем качество!”

Ну давайте. Встречный вопрос – а как мы будем мерять качество? Он грит, а хуй его знает. Вот пойдите, мои верные слуги, простите, менеджеры, и придумайте, как мы будем мерять качество. Мол, похоже QA хуево работают, но хер его знает. Мне изначально было все это похую, потому как я за qa не отвечаю и вообще это проблемы project manager’а.

В общем, как тут принято начинать работу над любым вопросом (хоть формы зеркала в сортире)? Правильно – соберем митинг. Пригласим всех ну или не всех. В общем, собрались мы митинговать – я, мой начальник, Configuration менеджер, директор инжениринг и прочая братия.

Project manager говорит – тебе нужно сказать, что ты как product manager хочешь сделать для измерения качества? Я говорю, охуенные заявочки. А ниче, шо инжениринг – это вы, а не я? Я вам как product manager могу тока сказать, что качество наверное хуевое, а как его мерять – это уже ваши дела. Померяйте и принесите. Они грят -а мы не знаем, как мерять качество. Вот если нам скажут, как мерять, мы померяем, и отчитаемся о проделанной работе.

Тут вступает Ленский, в смысле Configuration менеджер. Мне, сообщает, все равно, как и кто будет мерять, но мне надо, чтобы когда моему тиму сдают в релиз продукт, сообщали, какое у него качество. и так, чтобы было четко и понятно. а еще лучше говорит, чтобы ты сам там со своими пацанами разбирался, задерживал релизы, а мне приносили тока когда все готово.

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

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

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

Началось все уже привычно: А как нам померять качество? Я грю, ну самое простое, что приходит в голову – отсортировать тест кейсы по группам и собрать статистику по pass & fail. Все радостно закивали головами. Но тут вступил мой босс. Не, говорит, это все хорошо, но не люблю я эти тест кейс статистики. Вот когда я пишу acceptance criteria, я знаю, что это я написал и знаю, сколько они покрывают. а кто там писал ваши тест кейсы я не знаю, и как они написаны я тоже не знаю. Может они там покрывают 20% возможных use cases (надо заметить, у него есть основания так говорить). Давайте, говорит, лучше определим 10-20 основных функциональных областей (типа как epics), отдадим каждому члену команды на тестинг и послушаем выводы.

Тут вступает project manager: не, если программистов послушать, так у них все работает идеально, а если не работает, то это исключение и дурацкий юз кейс (что впрочем, тоже логично).

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

Я говорю, а как мы до этого релизили? На что следует ответ: ну так это же было неправильно! Мы же растем, мы должны знать, что мы релизим. Ок, отвечаю я, а как на счет того, чтобы мы сейчас неправильно отрелизили по старинке, не страдали хуйней, а по ходу следующих несколько недель я почитаю, подумаю, да и вообще что-то придумаем. Он на меня посмотрел так, как будто я лично признался в массовых убийствах христианских младенцев и сообщил: ТЫ ЧТО, ХОЧЕШЬ РЕЛИЗИТЬ, НЕ ЗНАЯ, ЧТО ТЫ РЕЛИЗИШЬ??? И ЭТО НЕ СГНАЛ ТРЕВОГИ ДЛЯ ТЕБЯ???

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

И теперь финишная прямая

Я написал письмо, отправил тимам с их инженерным менеджментом, а он – менеджмент тот – пришел ко мне и сказал: а мы че-то не поняли, в каком виде вы это хотите получить? @#$@#$@#$…. В виде процента по тест кейсам бля и личным соображениям бля. Хотя я думал, вы там что-то с QA придумаете. Ответ последовал ожидаемый: так а шо QA, они качество мерять не умеют. Как скажете, так и померяем.

Я устало махнул рукой, и сказал – ну вот пусть и меряют по своим тест кейсам.

Собственно, вот то, что он написал.

В чем действительно для меня загадка современной экономики – так это в том, откуда в ней берутся деньги… Даже не так. Не деньги – а адекватное товару количество другого товара, с помощью которого можно через деньги обменяться всем со всеми. Мудрено?

Попытаюсь попроще. Я думаю все в курсе что главный вопрос современной экономики это не произвести какую-то вещь, а найти того, кто ее согласен купить за те деньги что ты хочешь ее продать. Скажем, сейчас в развитых странах не проблема произвести продуктов питания в десять раз больше того количества что есть сейчас. Проблема что это просто не купят и не сьедят. И машин можно не сделать, так привезти вдесятеро больше – опять же, не купят. То есть получается, что нужно во первых обнаружить и опылить все мыслимые ОПЛАЧИВАЕМЫЕ потребности, но с другой стороны – считаться с обьемом рынка. Вот у меня собственно и вопрос – а откуда берется этот обьем рынка. Ну, в определенных вещах он достаточно ясен – человек не сможет сьесть больше пяти килограммов бананов, как его не мучай, или, скажем, человеку обычно не нужны пять машин чтоб ездить.

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

Собственно, вопрос меня заинтересовал тем, что я сам давно хотел написать “симулятор” экономики (что-нибудь на базе цепей Маркова, если я не пумаю название).  И с помощью этого симулятора, можно было бы глядеть, куда, как и почему ползут деньги. Но, само собой, времени как обычно нет. Так что, приходится все моделирование проводить в голове.

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

Зарисовка 1.

Представим себе, что у нас есть рынок из одной компании (которой владеют инопланетяне и не вмешиваются в нее) и одного работника (само собой весом 1 кг и ростом 1 м). Условно говоря, у компании есть $100. Работник делает 1 unit в год. За это ему платят $100. Но беда рабочего состоит в том, что для проживания ему надо потреблять 1 unit в год. Соответственно, он покупает его назад (цена которую поставили инопланетяне – $100 за unit).  Итого, все крутится по кругу, он работает, производит, получает деньги, покупает произведенное и потребляет. Общий размер рынка $100.

Тут возникает первый прикол. Если, бы инопланетяне обладали $1000, платили зарплату $1000 и поставили цену $1000, то точно также происходит круговорот, только размер рынка был бы $1000.  Это я так, намек на то, что сами деньги на самом деле относительная, а не абсолютная единица. Так что, нужно быть аккуратным с оценкой рынка в относительных единицах.

Так что, уж лучше я скажу, что рынок составляет 1 unit.  Хотя секундочку. Ведь, если бы рабочий производил и потреблял 10 unit’ов – опять же был бы тот же круговорот. Вывод, и unit’ы оценка относительная.

Тут мысль перескакивает, но она еще вернется.

Как этому бедолаге жить лучше? В обычной ситуации ответ – если он получает больше денег, то жить будет лучше, но тут у нас закавыка. Во первых больше денег нет (всего в системе $100), а во вторых больше за них покупать и нечего (всего в системе 1 unit). Само собой, единственный метод – это чтобы он производил больше чем потреблял.

Представим себе, что он может производить 10 unit’ов, а минимальные потребности у него 1 unit. Соответственно, теперь инопланетяне ему могут платить $100 и поставить цену $20 за unit (вопросы о монополии труда и рабочей силы оставим пока за рамками). Итого, получается, что инопланетяне теперь могут увозить к себе на Сатурн по 5 unit’ов в год, а товарищ стал жить лучше (вместо минимального потребления в 1 unit, он потребляет теперь в 5 раз больше).

А теперь возвращаемся к оценке рынка. Я бы сказал, что его нужно оценивать в количестве минимального потребления. Соответственно, в изначальной ситуации рынок был равен 1 (1 unit производства/1 unit – минимальное потребление), в тот момент, когда человек начал производить 10, то рынок стал бы 10 (10 unit производства/1 unit – минимальное потребление) .

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

Кстати, этот ответ большинство людей приводят быстро и не хотят двигаться дальше него.

Зарисовка 2.

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

Итого, мы теперь имеем компанию N1 (которой владеют инопланетяне с Сатурна) и компанию N2 (которой владеют инопланетяне с Юпитера). На одну работает работник N1, на вторую работник N2.  У одной компании есть по $200, а у другой $100. Зарплаты $100. Выпускается 1 unit бесконечно дуплицирующегося товара. Причем компании выпускают такой товар, который безумно нужен другой компании и которые те купили бы в бесконечном количестве экземпляров.

Происходит следующее. Работник 1 и работник 2 делают по одному unit’у и получают свои $100. Одна компания осталась при $100 у второй денег нет. Обе компании имеют по этому продукту, которые они хотят продавать.

Теперь, компания без денег продает свой продукт другой, получает за него $100. Те в ответ продают свой продукт и получают назад $100. Первая снова продает продукт и получает опять $100 и т.п. до бесконечности.

Чему у нас равен рынок? Вроде он равен бесконечности (так как они могут перепродавать друг другу до бесконечности эти unit’ы). Но на самом деле он зависит от скорости продаж. Чем выше скорость, тем больше рынок. Чем скорость ниже, тем рынок меньше.

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

Дальше пойдем без зарисовок.

Из первой сценария было понятно, что рынок зависит от эффективности. Но на самом деле эту эффективность надо разбить на несколько разделов:

- персональная эффективность (умения, знания, настрой на работу и т.п.)

- эффективность средств производства (на трактаре пахать легче, чем на лошаде).

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

- маркетинговая эффективность

Когда изобретение делают в Гарварде, то оно патентуется и через 5 лет приносит кучу денег, а когда оно делается в НИИ Обырвалг в Нижнем Урюпинске (то дай бог, об нем узнают 5 человек).  Изобретение может быть одно и тоже, но важно насколько хороша уже построенная сеть по сбыты товара/изобретения и насколько быстро все продвигается через эту сеть.

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

Теперь слегка о ограничениях.

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

В целом на него накладывается два серьезных ограничения

- потребости

Как писал мой брат, произвести то можно в пять раз больше еды, только вот съесть в пять раз больше нереально.

- конкуренция

В тех зарисовках, которые я привел, все произведенное потреблялось. Естественно в реальных условиях, одни товары будут конкурировать с своими прямыми конкурентами или непрямыми (учитывая ограниченное количества денег у покупателя) и что-то будет не куплено.

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

Ну и возвращаясь к вопросы, почему одна страна богатая, а другая бедная. Тут мне кажется дело в истории. Условно говоря, 200 лет назад две страны могли быть очень похожи. Какие-нибудь небольшие разницы в события (чуть различные по кровожадности диктаторы, чуть разные состав населения) приводит к тому, что несколько из вышеуказанных факторов начинают различаться. И условно говоря достаточно 2-3% разницы, чтобы за 200 лет накопился отрыв в размерах рынков в сотнях раз.

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

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

Например,  имеет смысл страховка жилья или авто. Так как $10k+ (а может и $100k+) – это очень болезненный “удар”. Гораздо легче переживается запланированные $100 в месяц.

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

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

Я такого пушистого зверька еще не видел. У нас на той неделе в пятницу пошел снег. Шел он в течении суток и на секундочку насыпал порядка 70 см (местами до 1м) снега.

Ну, естественно, жизнь встала, учитывая то, что расстояния все большие (все заточено под передвижение на машине).

Где-то дня два была гигантская борьба с снегом – разгребание шапок с машин, отчистка выездов, расчистка дорог. Учитывая нереальное количество снега, отчистительная техника просто начала вылетать из строя. И даже по прошествию этих самых нескольких дней, ситуация все еще продолжает быть аховая. Хоть основной слой (где-то 60см) с дорог убран, но все равно остальные в виде льда и слякоти, равномерно размазаны по остаткам полос (боковые полосы на 2 метра вверх засыпаны отодвинутым в сторону снегом).

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

И вот, обнаружилась приятная новость. К нам придвигается второй шторм,  который должен насыпать еще 70см снета! И прийдет он к нам завтра.

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

В общем, товарищи, надоело бытьАмундсеном и открывать дверь ледорубом. Хочу в теплый Техас.

Пожелайте мне удачи в отчистке 1.5 м снега вокруг машины жены и  70 см с моей машины. А еще лучше пожелайте удачи, тем людям, которые сейчас путешествуют в нашем теплой, уютной Вирджинии.

P.S. Одел лыжи и пошел в лес охотиться на оленей. Все же ближе чем до магазина.

Кстати, в декабре уже был первый снег 50-60 см объема. Так, что итого должно составить больше 2 м (за 2 месяца).

О… Пользуюсь случаем передаю привет всем, кто читает меня из Washington D.C. Area,  желаю оставаться в тепле и безопасности.

Вспомнилось мне, как я учился в институте 1997-2002 год.  Оттрубил я эти пять лет в ХИРЭ/ХТУРЭ/ХНУРЭ (черт его знает как он сейчас называется) на специальности ПОВТАС/ПОАС.

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

Почесав в затылке, я таки набрел в памяти на штук 5-6 предметов, которые были неплохи и по содержанию и по уровню преподавания.  Не буду вдаваться в подробности и перечислять. Но, в целом – это просто смехотворно, просрать 5 лет (причем лет, когда голова работает на полную катушку и поглощяет тьму информации на ура) на то, чтобы получить пользу от 5-6 предметов (которые легко уложились бы в один семестр).

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

Ну и слава богу, что я начал работать на втором курсе и достаточно быстро сократил посещения института до минимума.

А теперь вопрос к студии, вообще, кто-нибудь учился в институте/университете, где соотношение полезного (реально голезного) к пурге, получше?