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

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

Сразу скажу, нету у меня никаких данных, как «открыть глаза» лидерам таких команд и превратить маленькие конторы в IBM.

Начнем с начала:

1. Маржа прибыли

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

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

Безусловно, вы можете еще вкладывать время. Но опять же, если вы уже что-то делаете full time, то вам тяжело будет уделить больше чем дополнительные час-два в день (да и то они будут уже не слишком эффективные, так как вы будете откровенно уставшие).

Так вот, ситуация следующая. Для того, чтобы расти, ваша маржа должна быть достаточно большая. Поэтому поводу попытайтесь или поднять свой рейт или опустить растраты. Условно говоря, гораздо лучше иметь 2 наемных сотрудника и маржу прибыли 50%, чем 5 наемных сотрудников и маржу прибыли 10%.

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

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

Единственное, что могу сказать, что сидеть на низком рейте и убивать на него все свое время и энергию – путь в никуда.

2. Нишевость

Для того, чтобы продавать свои услуги дорого, вам нужно быть в нише, где конкуренция не так велика. Условно говоря, из существующих 100 фирм небольших фирм, которые бьются за заказы – 20 будут заниматься PHP, 15 будут заниматься RoR, 10 будут заниматься мобильными разработками и т.п. Будучи в первой группе, вы конкурируете с 20 фирмами разбросанными по миру и в результате вас прижимают к рейту $10/час, находясь в третьей группе, вы уже конкурируете только с 10 фирмами и вас прижмут к рейту $15/час. Находясь в какой-нибудь седьмой группе, где есть всего 2-3 фирмы, вы сможете получать $25/час. Естественно, я упрощаю, так как есть еще и спрос, кроме предложения. Но в целом, в небольших нишах соотношение спроса к предложению, лучше чем в mainstream.

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

Кстати, еще одна вещь по поводу большая и малая команда (при одинаковых прибылях). Если у вас команда меньше, то вам проще перебраться в другую нишу.

3. Новые заказчики

Конечная цель множества небольших компаний программирующих под заказ – это «хорошие и толстые заказы». Знаю-знаю, сам там был. Единственное, почему-то во время поиска таких заказов нахватываешся мелких и тощих заказов. Так как цель из «хорошие и толстые заказы» быстро переходит в цель «заказы».

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

Я бы сказал, что поиск заказов можно разбить на три уровня активности:

- Пассивный

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

- Слегка активный

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

Выжить тут можно, но если повезет и рост будет ну ооочень не спешный.

- Активный

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

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

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

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

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

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

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

Так вот, идея, которая мне пришла в голову, что нужно вывести формулу зависимости количества строк от объема продаж. А-ля, в год продается продукт на $1000, в нем может быть 3000 строк, продается на $100000 – в нем может быть 10000 строк. Продается на миллион, в нем может быть 50000 строк.

Моя формула примерно такова.

Максимально кол-во строк = (((Продажи за год) / (Средняя зарплата программиста за год)) ^ 3/4) * 10000

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

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

Принимаю критику и предложения по улучшению

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

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

Слава богу, за свой опыт я не слишком часто с такими сталкивался

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

Подведем простой математический расчет. Естественно все цифры взятые с потолка, если вам они не нравятся, подставьте свои.

а) Не ходить на работу и пользовать это время на программирование. (+10% дополнительного времени).

б) не писать документации (+5% дополнительного времени).

в) не обучать других программистов (+10% дополнительного времени)

г) не менеджить других программистов (+15% дополнительного времени)

д) отсутствие отчетности отчетности (+5% времени)

е) отсутствие необходимости согласовывать решения (+5% времени)

е) не присутствовать на всех митингах (+10% дополнительного времени)

д) отсутствие переключения между задачи (+30% эффективности).

е) отсутствие прерываний работы другими людьми (+30% эффективности)

Итого уже накапало 50% дополнительного времени и 60% увеличение эффективности. То бишь, продуктивность возросла в 2.4 раза. Думаю, если покопаться и выписать более полный список того, что НЕ делает гениальный программист, то вполне разность продуктивности может получаться и в 3-4 раза (отсюда и выходит, что хороший программист делает 3 месяца, а гениальный вадает за 4 недели).

А теперь на секунду остановитесь и задумайтесь. Хорошо ли для компании такое увеличение продуктивности в 4 раза? Если вы ответили «Да», то вам двойка в четверти по бизнесоведению

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

Есть такая штука «technical debt». Это когда написал код на скорую руку и решил, что потом его приведешь в божеский вид, но потом как-то не наступило и код продолжает пользоваться/изменяться/дополняться. С каждым днем его становится все сложнее поменять и все больше времени уходит на его поддержание. То есть мы сделали что-то быстрее взяв в долг, но долг не выплатили и него начали расти проценты.

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

В целом, Гениальных программистов в Бабруйск, даешь хороших программистов.

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

P.P.S. В еще нескольких комментариях началось обсуждение, как называют этих программистов. Предложенные варианты «Гики», «Хакеры». В целом, пусть хоть горшками (не чайниками) называют. Важно то, что с точки зрения множество людей в компании эти гении/гики/хакеры более (или по крайней мере не менее) полезны чем хорошие программисты выполняющие гораздо больший спектр задач.

Пойду доказательством от противного. Пусть мы работаем в Agile и у нас нету автоматизированного тестирования. У нас есть пять user story, которые мы делаем. Внутри каждой из них у нас есть какие-то разумные критерии по которой мы определяем, что user story сделана – они обычно включают ручное тестирование измененной/новой функциональности.

По окончанию скажем 6 Sprint’ов, мы решает, что пора выпустить новую версию и тут мы обнаруживаем, что оттестированная каждая user story не значит оттестированный весь продукт. Соответственно, мы стартуем большое регрессионное тестирование всего продукта. Исправляем баги (для них можно даже сделать отдельные user story), потом опять проходимся и делаем регрессионное тестирование (так как исправленные баги могли внести другие). Надеюсь это знакомо? Итого, нам понадобилось еще 3 Sprint’а, чтобы привести все к виду, в котором можно выпускать.

Итого, на самом деле мы похерили пару принципов из Agile
а) То что продукт постоянно близок по качеству к выпускаемому.
На самом деле, чем дольше мы работаем без release тем общее качество у него будет хуже и хуже
б) То, что заранее НЕ нужно планировать отдельные фазы (разработка/тестирование).
Теперь нам заранее надо таки планировать, что на каждые 6 sprint’ов разработки – 3 sprint’а тестирования и стабилизации.
Ой… А это случайно мы не в waterfall возвращаемся, когда мы делаем сначала разработку, а потом тестирование?
в) То, что по ходу, можно и нужно улучшать код рефакторингом.
Рефакторинг кода, становится делать опасно, так как зачастую только через месяца (во время большего тестирования) становится видно какие проблемы он добавил.

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

P.S. Да, основная идея – автоматизировать регрессию или большую ее часть. Это позволит, во первых раньше поймать баги, которые внесены внутри user story, но которые лежат в функциональности вне ее. Во вторых – это резко сокращает период на ретестирование продукта и его стабилизацию.

Ну и по ходу у нас вышло вот такое обсуждение:

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

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

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

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

Так вот, как-то так уже сложилось, что в среде программистов какое-то уж совсем нездоровое равенство. Все имеет право использовать весь набор инструментов.

Так вот, я выступаю за то, чтобы разграничить права на использование инструментов, как разграничены права пользования в Linux. Условно говоря, главный программист может делать любые действия. Средний программист не имеет права изменения критических существующих интерфейсов и ядра системы. Младший программист не имеет правда добавления новых файлов, copypaste и т.п. Еще раз… Это всего лишь пример. У меня сейчас нет в кармане полного списка прав и как все разделить и разграничивать.

Естественно задача проблемного кода решается даже без введения ограничения на инструментарий путем review кода до сommit’а его в SVN. Но даже на этом уровне, получается, что доступ к более опасным tool’ам будет съедать время главного программиста, так как ему придется объяснять, что Вася, не бери бензопилу, не меняй интерфейсы в классах.

Но, все таки гораздо удобнее было бы таки, по мере роста программиста позволять пользоваться более широким инструментарием. Опять же, это упростило бы работу самого программиста тоже. Когда у него есть всего 10 методов работы с кодом, а не 100, их будет гораздо легче освоить и использовать корректно.

Да, кстати, localstorm пишет в своем ЖЖ о управление проектами, программировании и других IT радостях жизни. Рекомендую почитать – хорошие и взвешенные мысли.

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

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

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

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

И в целом, если объектоориентированное программирование крутится вокруг идеи выделения объекта и методов, чего можно делать с объектом. То аспектноориентированое программирование крутиться вокруг выделения идеи аспекта и собирания его из размазанного вида в одно место. Так, что вместо бегания по 100 функциям разных объектов и copy/paste одного  того же куска, мы можем сказать – делать то-то при входе в функции таких-то классов.

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

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

Да, поясню слово вклиниваться. Я имею в виду, то, что мы не пишем никакого кода в определенном месте программы, но тем не менее есть код (на самом деле компилятор), который «знает», что в этом месте надо выполниться.

Похожим образом дело обстоит с полиморфизмом.Хотя код и есть, но тем не менее, в отличие от процедурного программирования, когда мы говорим – исполни функцию A (и четко известно, что это за функция A и с чем ее едят), то тут мы вполне можем говорить – исполни метод A, объекта. И на момент исполнения неизвестно, какой будет объект и соответственно какой код вызовется.  Сразу соглашусь, да это чуть другое чем с деструктором. Там мы не видим кода, но знаем что он сработает. Тут мы код видим, но не знаем что сработает конкретно.

Но, это все так, отклонения от общей темы.

Дальше моя мысль прыгнула в следующем направление. Если вдуматься, все это развитие языков от низкоуровневых к процедурным, от процедурных к объектным, от объектным к аспектным двигалась в достаточно простом направление -  упростить работу программиста и свести воедино то, что было раньше разбросано по разным местам.Сначала копии кода сводились в процедуры, потом куча процедур работающих с похожими данным сводились в объекты. Объекты которые работают похожим образом сводились в иерархию объектов. Объекты работающие похожим образом, но с разными типами – в templat’ы. Естественно – это не единственная особенность развития языков программирования, но по крайне мере оно четко прослеживаемая.

Так, вот, возвращаясь к планному программированию. Моя идея следующая – херим все сущности, которые были введены раньше (функции, объекты, аспекты, модули, namespac’ы, templat’ы и т.п.) и вместо всего оставляем совмещая все это получаем коцепцию плана.

Итак, что такое план?

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

Основная идея, это построить их так, чтобы сделать код гораздо более податливым. Если сейчас код находится в классе X, похожий код в классе Y и Z, то начинается целая свистопляска, чтобы его объединить, или хотя бы свести в одно место (как с логированием).

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

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

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

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

- Мы обнаружили, что наш MainWindow план стал слишком жирным, выделяем Storage план, переносим туда весь код по работе с файлом (чтение, запись, временное сохранение измененных записей).

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

- Мы решаем, что нам надо добавить 5 полей. Начинаем их добавлять, и обнаруживаем, что мы нам нужно будет тупо copy-paste работу с полями для того, чтобы их отрисовывать в  MainWindow и сохранять, считывать в Storage. И вот тут наступает самое интересное, мы вводим новый план ContactField в который составляем из куска Storage по работе с полем и куска MainWindow по работе с полем.

Замечу, что ContactFiled содежит не копию кода, а зеркало кода. То есть, редактируя в ContactFiled оно редактируется в MainWindow или Storage. Итак, это первая выгода, что мы теперь можем просматривать код в том виде, который нас действительно интересует – либо с точки зрения UI (смотрим в MainWindow) или Storage или с точки зрения Field. На самом деле, теперь мы можем в этот план включать любые другие места где наше поле используется, передается, храниться и обрабатывается. То есть, всегда есть место где централизованно можно  видеть сущность.

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

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

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

Самое важное, что я осознал, во время написания статьи, фактически планное программирование – это две вещи:

а) Мощная среда разработки, которая умеет делать много разных отображений кода и работы с этими отображениями.

б) Уменьшение количество сущностей (класс, процедуры, шаблоны, интерфейсы) и сведения их к минимальному количеству.

Надеюсь, кого-нибудь зацепила эта писанина. Жду, комментариев, критики и горячих споров.

P.S. Насчет Mix-in и Closure. И то и другое продолжает решать проблему дублирования кода, но все таки не так радикально как предложено у меня

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

Пришло таки время написать о чем же я писал все это время.

В самом простом виде, я бы сказал, что когда ты прочищаешь мозги на одну и ту же тему три раза Васе, два раза Пети. А потом тебе  надоедает прочищать мозги всем им по отдельности и ты пишешь документ, рассылаешь всем и говоришь: «Делать надо так как написано в этому документе и теперь не отнекивайтесь, что вам об этом никто не говорил и нету четкого описания как делать». Так вот, записанная последовательность, того чего делать и чего не делать и есть процессы.

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

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

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

Вот такие вот пироги с котятами.

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

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

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

В общем, веселая проблемка. Но, я собственно говоря не о том. Я вообще хотел написать о самообразовании.

Опять же, большинству понятно – надо самообразовываться, иначе отстать от прогресса в IT можно буквально за 2-3 года, а через 5-7 лет уже только и останется ворушить говно какого-то мамонтного проекта.

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

Вроде звучит логично, план есть, аккуратненько его исполняем и все будет чики-пуки. А вот фига с два. Проблема очень похоже на проблему backup’а. Это вам кажется, что все чики-пуки, а на самом деле определить все хорошо или все плохо можно будет только тогда когда основная копия (ваши активно используемые знания) вдруг по какой-то причине лягут.

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

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

P.S. Видео которое подкинул Sergey Perepechin (в другой статье) смотреть ОБЯЗАТЕЛЬНО!!!! Там как раз много сказано по поводу того, с какой скоростью все меняется.

Он писал:

классический win-win это просто красивая сказка. просто если преподносить ситуацию как win-lose, то сторона, которая lose может начать действовать неадекватно (от банальных обид, саботажа до приноса УЗИ в оффис), поэтому все разрешения конфликтов каг-бе надо маскировать в обоюдовыгодное решение… кто может это делать лучше – тот более правильный лидер, т.к. при его win сторона lose не испытывает дискомфорта и даже верит, что так лучше.

Как раз на этом пункте и разошлись в мнениях.

Начну с моего понимания терминологии.

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

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

Условно говоря, вы купили спички за 1 кп., продали за 5 кп. В выигрыше вы или в проигрыше? Где-то внутри головы есть сотни факторов – знание о окружающих цена, цена вашего времени, минимальная прибыль которая вас интересует, количество потраченных моральных сил на покупку и т.п. В конце они складываются у одного скажем в то, что 4 кп. он считает продажей, которая минимально выигрышная, а у другого это 6 кп. Соответственно, одна и та же сделка с продажей за 5 кп. для одного продавца будет казаться слегка проигрышной, а для другого слегка выигрышной.

Итого, имеем, что «win» для человека – это превышение какого-то нулевого порога, который установлен у него в голове.

Теперь пройдемся по ситуациям:

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

Естественно, что если после этого покупатель обнаруживает, что везде вещь продавалась по 8 и его таки «нагрели», то он переоценивает свой нулевой уровень в 7.50 и мгновенно начинает чувствовать себя lose. Однако это происходит, только в том случае, если вокруг продавали по 8 и если для него психологически важнее купить по средней цене, а не по тому, сколько он был готов заплатить изначально.

Следующая ситуация.
а) Покупатель хочет купить вещь, нулевой уровень в его голове равен 8 рублям.
б) Продавец хочет продать вещь, нулевой уровень в его голове равен 10 рублям.
Соответственно, здесь win-win не возможен изначально. Либо сделки (наиболее вероятно) не будет, либо одна сторона будет ее считать lose.

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

А вот, теперь, переходим к более интересной части. Как вообще добиваться win-win’а из этого второго типа сделок?

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

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

Предположим, компания A имеет права на сериал «Богатых тоже пучит» и хочет за прокат больше $5M (та самая нулевая отметка). TV студия в свою очередь хочет взять в прокат и в их голове цифра $4.5M. Добавлю чуть больше информации, она понадобиться чуть ниже, в прокат сериал компания A сделает минимально за $5M, потому, что при этой цене они получат минимальную прибыль $0.5M, TV студия хочет взять за $4.5M максимум, потому что они при этому тоже получат $0.5M.

Вроде исходя из этого, если они начинают играть по правилам «win-lose», то сделка явно не состоится (так как студия не хочет предлагать даже минимума). Однако есть второй фактор – количество показов каждой серии. То есть сколько раз имеет право студия прокрутить одну и туже серию. Стандартное количество прокрутов оказывается равно 6 (никогда об этом раньше не знал). Студии интересно получить больше прокрутов – скажем 7 или 8, так как это позволяет больше собрать на рекламе. Компании A, которая дает сериал в прокат наоборот увеличение прокрутов вредит, так как сериал «засматривают» на одном канале и вторая студия уже с меньшей готовностью (за меньшую сумму) возьмет его в прокат. Так вот, студии каждый лишний прокрут приносит $0.75M дохода, а у компании которая сдает в аренду, это вредит $0.25M (уменьшение стоимости следующей сделки по прокату сериала).

И вот тут возникает интересная часть – суммы прибыли у одного и убыли у другой компании НЕ одинаковые. Соответственно, если компании обсуждали бы договор в рамках 8 прокатов, вместо 6, то их границы были бы: для компании сдающей фильм в аренду: $5 + $0.25*2 = $5.5, а для студии $4.5 + 0.75 * 2 = $6M. Вуаля.. Мы получили результат, что они могут договорится в пределах от 5.5 до 6. Пусть скажем, они сошлись на 5.75 (ровно посередине).

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

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

Возвращаясь к тому, что я писал вначале, то что выигрыш величина относительная и она относительно крайнего значения, которые вы считаете нулем. И вот тут важно понимать, что нулевая отметка это не та цифра за которую они готовы были сдать или взять фильма в прокат, а прибыль от которой они отталкивались. Обе компании, отталкивались от прибыли $0.5M. Если посчитать, сколько же прибыли получила каждая компания, то мы обнаружим, что компания A получил – $0.75M и студия получила тоже $0.75. Итого, ОБЕ стороны оказались в выигрыше от того, что они планировали изначально.

Естественно, будет нечестно опустить тот факт, что таки за $0.5M (между $5.5M и $6M) они таки должны были бороться «перетягивая канат», но с другой стороны какой бы счет не был в процессе перетягивания – результат уже лучше, чем то, что они запланировали.

Ну и естественное, если бы они могли добавить еще скажем 3-5 параметров с разной стоимостью для двух сторон (и прибыль от которых больше чем убыли), то они получили бы еще больше и их прибыль могла бы достигнуть скажем $1M. И кстати, не думаю что какая-то сторона будет обиженна таким выходом.

И возвращаясь к самому началу статьи. Хотя речь в целом идет не только о лидерстве, но и вообще о любых сделках. Тоже самое работает и с лидерством. Да, лидер может зачастую «накрутить хвосты» (особенно если он прямой менеджер и обладает еще и официальной властью). Но после 2-3 накручивания хвостов (типичный win-lose), люди вообще перестанут идти на уступки, а то и решат сменить место работы. С другой стороны, если скажем в момент deadline предложить людям поработать в субботу в обмен на 2 выходных по окончанию release, сразу получается чистый win-win. Суббота – является гораздо более дорогим для менеджера чем для людей параметром и он хочет получить его. В ответ, два выходных для людей более дорогой параметр, чем для менеджера – они получают его. В таком виде, каждый сотрудник с радостью будет помогать лидеру.

Вот такие вот дела….

Миф N1:

У оптимистов все происходит хорошее, а у пессимистов – все происходит плохое. Поэтому нужно быть оптимистом и все у вас получиться.

Миф тут в двух пунктах

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

- Впрямую оптимизм на исход события не влияет.

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

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

Тем не менее, в целом – это достаточно косвенный параметр влияющий на успешность.

Миф N2:

Успешные люди всегда уверены в себе. Это вообще полная херня.

Поглядите фильм Пираты Силиконовой Долины о старте Microsoft и Apple. Там очень хорошо показано, что Bill Gates и Steve Jobs может быть в целом и были достаточно самоуверенными людьми, но они не знали и не были уверены, что станут настолько богаты и они не были уверены, что все пойдет удачно.

Миф N3:

Главное ставить высокие цели.

Ню-ню… Поставьте себе цель перепрыгнуть 10 метровую планку в высоту без разбега. Как результаты? Думаю прыгать никто лучше не стал от этого.

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

Вот такие вот мысли. Кстати, частично о том откуда растут ноги у этих мифов я уже писал.

Кстати, для интересующихся альтернативной (обратной) точкой зрения – читать тут.