Предприниматель должен быть выборочно ленивым

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

Так было и со мной. Не так давно я открыл книгу про финансовую грамотность, которую читал давненько. Так как я люблю делать пометки в книге я нашел много интересного из прошлых моих фантазий. Одна из них была - уволиться и стать тренером, зарабатывать на рынке именно этим. Писать тренинговый контент каждый день и продавать его. Стояла дата. Сумма прибыли. Мое имя. Цель из точки А казалось яркой, полной и осмысленной. Сейчас с легкостью могу сказать где я сейчас и чем это отличается от того, как виделось тогда, в точке А. 

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

Если выбрать тренинги, как это сделал я, то окажется что их надо продавать, а продавать тренер не факт, что умеет. Но перед тем как кому-то что-то продать надо этого кого-то найти. Привет маркетинг-скилз, а его у тренера нет. Будешь заниматься всем подряд - а как же тогда сам тренинг? Как же "генерация контента каждый день"? Ну ладно, можно сделать "лонч" к определенной дате, собрать ребят по всем возможным каналам, потом лично обзвонить каждого оставившего заявку, потом уже провести с ребятами тренинг. Супер. Сделаешь это ты скорее всего как сумеешь, но результат будет. И скорее всего может оказаться, что денег это сгенерирует недостаточно (несоизмеримо ожиданиям от вложенных усилий) - в общем, не так, как тренер привык в одной большой и щедрой компании. Грубо говоря, зарабатывал 2000$, а на тренинге напродавал всего на 700$. А сил затратил в три раза больше чем до увольнения. И что теперь бросать идею? Нетушки... 

Подумалось, а что если я буду набирать на тренинг постоянно. А свои оффлайн тренинги перенесу в онлайн, оцифрую так сказать себя как тренера и буду продавать хорошо организованный self-study тренинг. Цена будет чуток меньше, но и меня в этом процессе не будет. В голове все красиво, а на деле? На оцифровку уйдут месяцы работы. А когда месяцы пройдут, окажется что большую часть контента надобно переписать. А ой как не хочется.  Ведь все это время рассматривал это как инвестицию, с которой еще не получил свои дивиденды. Грубо говоря, записал 400 часов видео, чтобы рефрешнуть его надо перезаписать 100. Обновить - 200, а лучше все переделать под новые стандарты. Ты ведь подрос, знаешь уже как надо было. И происходит борьба между внутренним инженером и подрастающим продавцом: Продавай как есть! Нет, перепиши! Нет продавай! Нет перепиши. Стоит делать и то и другое.

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

И будешь прав, если захочешь сдаться. Ведь это не то, что рисовало тебе воображение глядя на картинку. Ты хотел просто заработать на хобби. А от хобби-то и следа не осталось. Да и денег как-то не много. Но секундочку! Если посмотреть на многие успешные компании, что их объединяет? А посмотрим на некоторые графики акций известных компаний. 

Они есть! Это во-первых. Тех, кого уже нет обычно не обсуждают. Второе - они есть давно. Больше чем год. Больше чем 5 лет. Больше чем 10 лет. Они не закрываются, потому что что-то пошло не по изначальной задумке. Быть может идею стоит поменять. Быть может научиться любить "бухгалтерию". Или нанять тех самых ключевых людей, которые все сделают и и полюбить служение команде. 

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

Какой выход я вижу сейчас? Извлекать себя из всех процессов. Четко описать в job descrition какие роли ты выполняешь прямо сейчас и предлагать другим специалистом сделать эту работу лучше чем ты, full time и за определенную часть от прибыли (фиксированная ставка или процент, все зависит). Сложнее всего попрощаться с той ролью в которой ты силен, из чего все началось. В моем случае это тренерство. Ты просто видишь, что другие ребята не сделают так как ты. А тот кто сделает и сам уже самозанят. И держишься до последнего за нее. А не стоит.

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

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

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

А что касается ожиданий по компенсации времени, то тут все по другому считается, не так как тебе хочется. Ты как предприниматель имеешь другой рейт, нежели как специалист. Как специалист ты Senior, как предприниматель Junior. Рейт будет расти относительно твоего опыта. Чем больше шишек, тем больше кешфлоу. Потому основная работа - это хорошо. Я бы наверное поступал так (собственно так со мной и случилось) - работаешь на основной работе и накапливаешь жирок. Это как? Тратишь меньше чем зарабатываешь. Откладываешь подушку безопасности. Потом заканчиваешь проект и увольняешься на пол года, чтобы запустить проект (именно тут надо всего тебя, даже 250% тебя). Не поиск новой работы, а попытка запустить новое. Деньги со счета беспощадно утекают, но ты знаешь что времени у тебя 6 месяцев. Потом, по мере делегирования возвращаешься на основную работу, чтобы снова "поднакопить жирок". Тут же и к новой работе уже относишься не как инженер, а как партнер, предприниматель. Если вдруг понадобиться запустить новый проект - я бы запускал по подобной прошлому схеме, ведь тогда сил это заберет меньше - ты знаешь что делать надо, а что нет. Посмотрим. Третий быть может по иной бизнес модели. 

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

Записано на правах капиталовложения. Да да, блог это тоже актив. Раз написал, работает много. 

Синхронизация потоков дорогого стоит

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

Самое главное правило - правило пустого инбокса. О нем многие говорят и я сам о нем говорил часто. Пустой инбокс значит вот что. Ты выбираешь время удобное для тебя и интервал, периодичность, с которой будешь опустошать свой инбокс. Опустошить инбокс - значит ответить всем, чтобы во всех твоих системах было по нулям. Это вкратце. А если подробнее, то и тут есть свои советы. Опустошать инбокс лучше вечером после работы - во-первых так ты "экономишь мыслетопливо" (с) by Максим Дорофеев во вторых так ты ограничиваешь время уделенное каждому сообщению - ведь домой хочется по-раньше. Что касается периодичности - рекомендуют раз в сутки, но иногда у меня бывало комфртно раз в двое суток, иногда бывается дважды в сутки. Тут зависит от ожидания окружения. Чем оно требовательнее, тем чаще на первых порах) придется отвечать. После того как окружающие привыкнут к новому интервалу - его можно чуть увеличить: каждый час, каждые два часа, каждые четыре часа, раз в день. На соблазн - а что там может что-то появилось интересненького не ведемся! Если раз в 4 часа, значит каждый 4 часа - не раньше! 

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

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

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

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

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

Дальше что касается тех сообщений, которые адресованы к тебе лично. На них тоже можно по разному отвечать. Тут основные ошибки - не превращать почту в чат (спасает подробной ответ с твоей стороны не чаще чем ___ раз в день), если надо оперативнее пообщаться - созвонитесь, если надо при этом иметь время на обдумывание - початитесь, если ждет около сутки-двух - почта. Если же на той стороне "болтун" (ничего личного, я сам люблю поболтать обо всем и ни о чем), а надо удовлетворить много запросов, то поможет ответ в то время, когда он не онлайн. А если он даже и онлайн, то отвечаем так как в почте. Преимущество чатов в том, что можно параллельно ответить многим ребятам при условии что быстро печатаешь и/или есть заготовки текста. Преимущество личного звонка, в том, что решается все очень быстро, но вместе с тем времени на подумать остается меньше. Не стоит идти на поводу и всегда соглашаться на тот канал связи, котоорый удобен собеседнику.

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

Отдельно хочу сказать про мобильный телефон. Я лично на него не отвечаю, если мы не договорились о звонке заранее. Мобильный телефон, это как звонок по скайпу. Вот сидишь ты за компьютером, смотришь допустим фильм, а тут звонок по скайпу. Твоя реакция? Положить трубку конечно же и написать в чате - что случилось? Чем же отличается спонтанный звонок на мобильный? Я обычно на него отвечаю так же. Сам себя приучаю к тому, что на том проводе может быть неудобно принимать мое входящее, потому перед тем пишу смс и спрашиваю, удобно ли чтобы я позвонил? Нет у нас культуры использования мобильной связи. Большую часть звонков вообще начинаются с "извините"... Ну куда это годится. 

Теперь что касается собеседников и того, куда они тебя идут. У них свои цели и проекты. Тебе может быть с ними как по пути так и в разные стороны. Если по пути - стоит обратить внимание на то, ваш союз обоюдовыгодный или только ты вкладываешь а взамен получаешь недостаточно? Помни, что всегда есть другие проекты, где ты сможешь получить столько сколько отдаешь и если у тебя нет времени на установки связей с этими проектами, значит пора от чего-то отказаться сейчас. Как отказываемся? Самый простой инструмент - мороз. Обычно если просто не ответить сразу, то через пару дней уже будет неактуально. Автора часто закидывают удочки сразу в несколько мест и если ответа нет, не сильно огорчаются - не там, так в другом месте. Если же не напоминают - значит не так надо было. Если не готовы платить за услугу - значит не так надо было. Если не готовы сделать что-то предвариетльно - значит не так и надо было. Если решил ответить, помни что на условия так же влияешь и ты. Ты можешь сказать "нет, сейчас это не интересно" и это будет более честно по отношению к автору. Если же ты хочешь отписаться от рассылки - попроси об этом.  Это будет экологичнее, чуть потом когда захочешь опять подписаться - так же сообщи. 

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

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

Варкрафт инсайт

Решил чуть отвлечься и нашел себе Warcraft II. Всю ночь в него играл.

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

Может для кого-то это будет банальным, но меня торкнуло во время игры. Для нормальной полноценной игры, когда ресурсы добываются, оборона держится, контролы атакующих пробивают защиту, заводы работают на апгрейды надо около 50 юнитов. Если юнитов меньше 10, то тут только о первичном сборе материлов можно говорить и волноваться, а не вынесут ли. А теперь во всем этом какая моя роль? Я же не бегаю сам по карте на белом коне, сам добывю золото, сам рублю лес, сам воюю и строю здания? Никак нет. Я даже по полю не бегаю - а сижу наполовину укутанный в одеяло и нажимаю кнопавки клавиатуры. Руковожу в общем. Да переживаю. Да провтыкиваю иногда. Но юниты мне верят и идет в бой. Я выкладываюсь по полной, но не бегаю по полю с языком за плечами. 

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

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

Менеджер-снежинка from Slava Pankratov

Спасибо Салава, спасибо WarCraft II.

Кстати пару рекомендаций из своей копилки по делегированию:
- Если что-то становится рутиной и кушает много времени, а автоматизировать не получается (а так ли это на самом деле?) напиши job description, распечатай его и положи на стол - кандидат найдется. Может он и автоматизирует? Обычно таски, которые уже приелись лучше делаются новичками - у них там чаще прорыв случается.
- Предлагай поработать за опыт. Волонтерство в наше время в айти очень даже ничего работает. Ребята устроены, имею неплохие зарплаты, а дополнительные опции рядом с твоим делом у них нет, а у тебя пока денег нет :) Вот и договоритесь.
- Если к тебе кто-то обращается с советом что-то исправить, улучшить или дополнить - смело предлагай ему эту задачу. Скорее всего он согласится, потому как идея-то его.
- Делегируй не таску, а ответственность за какое-то целое направление, чтобы человек себя там чувствовал боссом и придумавыл сам себе задачи. А микроменеджмент выкинь на помойку. За всеми не проследишь, только за мотивируешь ребят не работать с тобой.
- О факапах сообщай как о фактах, которые есть в системе, а не о том, что кто-то налажал. А может даже не стоит их озвучивать - момент, когда случился факап не самое подходящее время чтобы проводить ретроспективу. Может быть как-нибудь в будущем, или никогда.
- И вообще рисуй чаще у ребят в голове успех. Каждый хочет сделать свою работу как можно лучше!
- Не лезь с советом, погоди, пока не спросят тебя "а как лучше?" вот тогда и говори, если знаешь. Лидеры выжидают подходящего момента тогда, когда к ним обращаются.

Наверное есть еще 100500 других ркомендаций, но это первое, что пришло в голову, что уже удалось попробовать и что работает.

А как делегируешь ты?
В какие игры играешь, чтобы расслабиться?

ПриЁм

Технарь с Self made Soft skills

Вот так вот недавно меня обозвали. Не скажу, что не приятно. Приятно. Даже очень. Только я вот чем дальше в лес тем больше думаю, а не было ли ошибкой природы то, что я изначально в точные науки подался. Сейчас все больше понимаю, что технарьство - это подача Папки моего, он привил любовь ко всему точному. А душа лежит в области Soft skills. Но не об этом пост :) Я рад, что сейчас все происходит именно так как происходит.

Меня спросили, какие основные темы для технарей я бы рекомендовал развивать в сфере soft skills? Легко! 

Нетворкинг 

Айти, по моему, это про обмен информацией. Да есть всякие инструменты решения вопросов, всякие технологиии, языки программирования, гуглы, интернеты... Но есть еще то, что появилось много тысяч лет назад - живое общение. Это самый главный источник передачи информации. Самый налаженный. Самый естественный.  Это работает еще круче чем гугл. "Не имей 100 рублей, а имей 100 друзей". Раньше я не понимал этой пословицы. Теперь понимаю. Когда у тебя на связи 1000+ контактов, с которыми ты поддерживаешь связь. Когда большая их часть знает как у тебя дела. Когда ты знаешь как дела у них. Когда одни друзья решают свои вопросы с помощью других твоих друзей, а потом оба говорят тебе спасибо. Все получается как бы по щелчку пальцем. Вот ты захотел собрать ребят, поиграть в какую-то любимую игру - чик и готово. Вот ты хотел бы получить новый опыт в какой-то области - чик, и у тебя есть ментор/напарник. Вот ты хотел бы поделиться опытом - чик, и у тебя есть группа из трейни, по любому вопросу. Соцсети не только для постинга кошечек - соцсети, это новый способ коммуникации друзей на расстоянии. Это инструмент для решения не только хобби но и бизнес задач. Мы разберемся с тем, как справляться с огромным потоком информации. Мы разберемся с тем, как поддерживать живыми (и главное зачем это делать) все твои контакты. Ты удивишься, как приятен мир в котором у тебя 10х знакомств. Подключайся. 

 

Блоггинг

Мое личное убеждение - айтишник должен публиковаться. Скорее нет. Айтишник должен обмениваться информацией. Иначе он не айтишник. Айти - про обмен информацией. Один из инструментов - общение с живыми людьми из уст в уста, но он имеет ряд ограничений. Во первых каждое такое общение - отнимает у тебя время. И как следствие ты не сможешь просто передать свой мессадж аудитории в 10, в 100, в 1000 раз больше твоей привычно-комфортной. Во вторых - тема рано или поздно выгорает или переходит в зону неосознанной компетенции и там живет себе всю оставшуюся жизнь. Достать ее оттуда уже не так просто. И эти вопросы решает личный/технический блог. Завести его не сложно. Постить туда не долго (как это делать максимально быстро - разберем). Времени он приносит океан! Посуди сам - один пост, минут 15 времени. Каждый раз, когда кто-то читает твой пост - тебе в копилку +15 минут. Ты их не потратил на то, чтобы донести мысль - ты просто поделился линком. А если в этих 15 минутах изложена мудрость, экономящая 10 часов неудачных экспериментов? Итак в твоих часах с блогом больше чем 24 часа. С каждым своим постом ты нарабатываешь свой капитал. Чуть позже ты почувствуешь, как он работает на тебя. Но конечно же правила. Правила эффективного блоггинга. О чем постить. Как постить. Куда постить. О них и поговорим.

Позитивная формулировка

Как повысить свою прибыль в 100 раз? Бред? Ну с точки зрения текущего тебя - это бред. Но посмотри в прошлое - ты уже это проделывал и может быть не раз. Вспомни хорошенько свой первый студенческий приработок. О чем ты тогда мечтал? А сейчас что? Получилось? Реально, значит. Вопрос в том, как ты тогда сформулировал свою цель. В годы молодые было больше мечт и меньше знаний того, как мир не работает. Тогда цели ставились позитивно естественным образом. Чем больше опыта ты получаешь, чем больше граблей на пути - тем больше соблазна сказать "нет! у тебя/меня/вамс/нас/них это не получится". И ты будешь прав. У тебя не получится. Но получится у кого-то другого, кто не закрыл себе двери возможностей таким вот негативным утверждением. Хочешь так? Получай! Хочешь на 180 градусов в другом направлении? Так же получай! Вопрос только в том, как ты назовешь свой проект. От игры слов сильно зависит результат. Не даром ведь пословица "как корабль назовешь - так он и поплывет". И это самый первый шаг - позитивная формулировка. А есть ведь еще... В этом и начнем разбираться. Все получится. Я уверен!

Делегирование 

Инструмент спасение. Спасение, которое особенно нужно тогда, когда все только-толкьо начало получаться. Вот все получается, но тут бабамц реальностью по башке! В сутках-то 24 часа. А надо 48, 96, 192... Больше времени! Аааа... Не успеваю.... Но погоди -  у тебя времени в сутках столько же, сколько их было и у Стива Джобса, и у Била Гейтса, и у Линуа Торвальдса и у многих многих успешных ребят творящих прям сейчас или когда либо на Земле. 24 часа. Но как так? Ответ прост. Надо уметь делиться. Делиться ответственностью. Делиться задачами. Делиться плюшками. Делиться всем, что раньше делал ты сам. И уж поверь, лучше начинать это делать сегодня, пока этого ничего не требует, чтобы потом, когда от этого будет зависеть успех твоей компании/проекта/команды. Точи лыжи в сани, или как там пословица гласит? :) Хороший доклад на эту тему у Славы Панкратова - Менеджер Снежинка называется. Посмотри, это убеждает... Обещаю, мы разберемся в этом. Делиться будет комфортно, легко и естественно. Как в детстве в одной песочнице делили песок, так же легко будет делиться задачами. Да, "они все сделают не так классно как ты". Все так и будет! Да, "придется за ними доделывать". Несомненно! Но доделывать - это не писать с нуля. Доделывать обычно приходится %10-15. А это значит, что у тебя вдруг появилось из ниоткуда (те 85%-90%) свободного времени. Но не спеши, не "из ниоткуда" - эту работу выполняли не роботы, а люди. А люди будут требовать твое внимание, твое время. Время на менеджмент. И это целая наука. Хорошо бы, если ты начал ее изучать уже сегодня. По чуть-чуть. Пригодится, поверь.

Психология

Наконец там, где работают люди - там царствует психология и ее инструменты. Не надо все учить и сразу, просто стоит любопытствовать в этом направлении. Хоть чуть чуть. Делишься фидбеком? Сделай это приятно для получателя. Не мониторил настроение команды - попробуй начни. Не знал, что есть разные психотипы - а что если пронаблюдать за особенностями восприятия информации у ребят в команде? Ну а как на счет себя самого? Ты являешься обладателем суперкомпьютера, который аккуратно размещен у тебя между ушами. Как он работает? На каком языке пишутся программы? Почему ты нервничаешь в одних случаях, а в других переполнен драйвом? Почему другие люди работают иначе? Как это поменять? В них? Может в себе? Ответы на все эти вопросы в виде всевозможных инструментов я черпаю в трудах психологов. Очень много инсайтов. Когда говорят, что мозг работает не на 100% а на 5-10 - немного обманывают, он всегда работает на 100%, но правда в том, что потенциал у него куда больший, чем то как ты им пользуешься сейчас. Пару простых инструментов, которые использую я сам - вероятно они заинспайрят тебя на поиски своих собственных лайфхаков. Разберемся и в этом.

Дать возможность отступить

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

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

Так как сейчас занимаюсь в основном проектами, которые for fun, где этого самого for fun хочется в процессе получения результата, то и с ребятами очень хочется работать в режиме for fun. Вот допустим, есть у меня 1 задача. Хорошо бы ее сделать, но я сам не успеваю. И вот я выкладываю таску в паблик. Может быть даже предлагаю ее кому-то из друзей, кто заинтересовался. И он согласился. И даже начал ее делать...

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

- неудобно сказать НЕТ (а стоило бы, но не об этом сейчас)

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

- в детстве учили, что надо заканчивать если взялся (такое...)

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

Как проверить, получает ли он драйв и дальше или нет? Не сложно. 

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

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

Рефакторинг: Замена рекурсии делегированием. Часть 2

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

package com.binarytree.oop;

import com.binarytree.Node;

public class OOPTree implements Node {
    
    private int value;
    private Node left;
    private Node right;

    public OOPTree(int value) {
        this.value = value;
        left = null;
        right = null;
    }
        
    @Override
    public int getMaxLeafDepth() {
        int depth = 0;
        
        if (left != null) {
            depth = left.getMaxLeafDepth();
        } 
        
        if (right != null) {
            depth = Math.max(depth, right.getMaxLeafDepth());
        } 
                    
        return 1 + depth;            
    }    
    
    @Override
    public void addValue(int newValue) {
        if (newValue < value) {
            if (left == null) {
                left = new OOPTree(newValue);
            } else {
                left.addValue(newValue);
            } 
        } else if (newValue > value) {
            if (right == null) {
                right = new OOPTree(newValue);
            } else {
                right.addValue(newValue);
            } 
        }
    }
    
    @Override
    public String toString() {
        return String.format("(%s, %s, %s)", value, left, right); 
    }    
}

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

Рефакторинг: Замена рекурсии делегированием. Часть 1

Часто сталкиваюсь с проблемой, когда процедурный стиль программирования тянется в OOP код. Вот интерфейс бинарного дерева: добавили ноды, померяли глубину самого глубокого листика, напечатали на экране - все просто.

package com.binarytree;

public interface Node {

    int getMaxLeafDepth();

    void addValue(int value);

    String toString();

}

Вот пример кода класса, в котором используется рекурсия.

package com.binarytree.procedure;

import com.binarytree.Node;

public class ProcedureRecursionTree implements Node {

    private NodeElement root;

    public ProcedureRecursionTree(int rootValue) {
        root = new NodeElement(rootValue);
    }

    @Override
    public void addValue(int newValue) {
        addValue(root, newValue);
    }

    private void addValue(NodeElement node, int newValue) {
        if (newValue < node.value) {
            node.left = addTo(node.left, newValue);
        } else if (node.value < newValue) {
            node.right = addTo(node.right, newValue);
        }
    }

    private NodeElement addTo(NodeElement node, int newValue) {
        if (node != null) {
            addValue(node, newValue);
            return node;
        } else {
            return new NodeElement(newValue);
        }
    }

    @Override
    public int getMaxLeafDepth() {
        return getMaxLeafDepthFrom(0, root);
    }

    private int getMaxLeafDepthFrom(int depth, NodeElement node) {
        if (node == null) {
            return depth;
        }

        return 1 + Math.max(getMaxLeafDepthFrom(depth, node.left), 
                getMaxLeafDepthFrom(depth, node.right));
    }

    @Override
    public String toString() {
        return toString(root);
    }

    private String toStringSubnode(NodeElement node) {
        if (node != null) {
            return toString(node);
        }
        return null;
    }

    private String toString(NodeElement node) {
        return String.format("(%s, %s, %s)", 
            node.value, 
            toStringSubnode(node.left), 
            toStringSubnode(node.right));
    }

}

Это класс, в котором хранятся данные

package com.binarytree.procedure;

public class NodeElement {

    int value;
    int parentNodeValue;
    NodeElement left;
    NodeElement right;

    public NodeElement(int value) {
        this.value = value; 
    }

}

Ну и? Все нормально на первый взгляд. Методы маленькие, дублирования нет, все вполне читабельно. Да, но тут код пахнет другим - класс ProcedureRecursionTree инкапсулируя NodeElement root рекурсивно проходится по всем дочерним узлам/листьям root ноды. Это удобно - все ноды одного типа. Но это не по OOP. Правило простое.

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

Вот этой задачкой я и предлагаю заняться. Рефакторинг, как оказалось недавно, в более широком виде, Фаулеровский и называется "Преобразования процедурного проекта в объекты (Convert Procedural Design to Objects)", я же его раньше называл "замена рекурсии делегированием".

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

Вот кстати тест:

package com.binarytree;

import static org.junit.Assert.assertEquals;
import org.junit.Test;
import com.binarytree.Node;

public  class TreeTest {
    
    Node createNode(int rootValue) {
        return new ProcedureRecursionTree(rootValue);
 }
    
    @Test
    public void testAddLeftToRoot() {
        Node node = createNode(5);
        node.addValue(4);
        
        assertEquals("(5, (4, null, null), null)", node.toString());
    }
    
    @Test
    public void testAddRightToRoot() {
        Node node = createNode(5);
        node.addValue(6);
        node.addValue(4);
        
        assertEquals("(5, (4, null, null), (6, null, null))", node.toString());
    }
    
    @Test
    public void testStartSecondLevel() {
        Node node = createNode(5);
        node.addValue(6);
        node.addValue(12);
        node.addValue(3);
        
        assertEquals("(5, (3, null, null), " +
                          "(6, null, (12, null, null)))", node.toString());
    }
    
    @Test
    public void testGetDepthFrom3LevelOnlyRightTree() {
        Node node = createNode(5);
        node.addValue(6);
        node.addValue(12);
        
        assertEquals(3, node.getMaxLeafDepth());
        assertEquals("(5, null, (6, null, (12, null, null)))", 
                node.toString());        
    }
    
    @Test
    public void testGetDepthFrom3LevelLeftRightTree() {
        Node node = createNode(5);
        node.addValue(1);
        node.addValue(2);
        
        assertEquals(3, node.getMaxLeafDepth());
        assertEquals("(5, (1, null, (2, null, null)), null)", 
                node.toString());        
    }
    
    @Test
    public void testGetDepthFrom4LevelleftRightTree() {
        Node node = createNode(5);
        node.addValue(6);
        node.addValue(12);
        node.addValue(16);
        node.addValue(3);
        node.addValue(1);
        node.addValue(0);    
        
        assertEquals(4, node.getMaxLeafDepth());
        assertEquals("(5, (3, (1, (0, null, null), null), null), " +
                         "(6, null, (12, null, (16, null, null))))", 
                node.toString());        
    }
    
    @Test
    public void testGetDepthFrom5LevelTree() {
        Node node = createNode(5);
        node.addValue(4);
        node.addValue(6);
        node.addValue(3);
        node.addValue(7);
        node.addValue(2);
        node.addValue(8);
        node.addValue(1);    
        node.addValue(9);
        
        assertEquals(5, node.getMaxLeafDepth());
        assertEquals("(5, (4, (3, (2, (1, null, null), null), null), null), " +
                         "(6, null, (7, null, (8, null, (9, null, null)))))", 
                node.toString());        
    }

}

Приятного аппетита. Продолжение следует.

Подборка #49

Вот какими должны быть презентации

Death By PowerPoint Rus

View more presentations from www.kapterev.com

...Это ценно, а потому повторюсь.
http://www.ivanpirog.com/posts/spontannoe-planirovanie-dlya-tex-kto-nenavidit-tajm-menedzhment/

А вот это было для меня новостью
http://www.ivanpirog.com/posts/formula-uspexa-spontannoe-planirovanie-i-zhizn-v-potoke/
Я сделал все, что там описано и получил облегчение. Буду пробовать месяц эту методику и посмотрим на результаты. Я кажется понял, почему когда заканчивая играться с текущей задачей (когда мне становится нудно или задача завершена) я сразу же лезу в почту или скайп - таким образом я пытаюсь выбрать себе следующую задачу (а там всегда что-то есть). Пару месяцев назад я выписывал каждое утро таски на день и обращался к этому списку, но оказалось что это не то, и, когда я замял со списком, мне ничего не осталось как лезть в почту - ибо там весь пленнинг и все таски. Но, выписав мои Пути и области деятельности на листик А4, я понял, что многие из них не привязаны к почте и компьютеру вообще.

А еще почитайте отзывы к статье.

Блин. В мире 51% иррационалов, которые ломают себя и свои жизни рациональным планированием, придуманным 49% рационалов. Леньтйяство, ветреность, целеустремленность, непоследовательность, разгильдяйство, несерьезность, безответственность и еще много других слов, которые иррационал получает в свой адрес время от времени - чаще всего они высказаны из уст рационалов, пытающихся загнать иррационала в свои метрики. Думаю, что рационалов сосредоточено больше в менеджменте - это их стихия. А вот люди подотчетные им - чаще иррационалы. Интересно, среди менеджеров кто-то берет во внимание принципы высказанные в соционике?...

Кстати эта заметка была записана, когда я уже собирался выходить из офиса и даже одел куртку с шапкой. Так вот одетый и писал заметку. Хотя минуту назад я о ней даже не думал! Знакомо?...

...Хочу летать!


...Статья "Несколько советов для организации успешного вебинара" будет полезна тем, кто хоть раз проводил вебинар...

...Хороший сайт http://www.kodejava.org/
Kodejava website provides beginners to Java programming some examples to use the Java API (Application Programming Interface) to develop applications. Learning from some examples will hopefully decrease the time required to learn Java...

...Как инджектить в private final static field

private static void inject(Class<ServiceLocator> clazz, String fieldName, Object data) throws Exception {
        setFinalStatic(clazz.getDeclaredField(fieldName), data);
    }

    private static void setFinalStatic(Field field, Object newValue) throws Exception {
        field.setAccessible(true);

        Field modifiersField = Field.class.getDeclaredField("modifiers");
        modifiersField.setAccessible(true);
        int oldModifiers = field.getModifiers();
        modifiersField.setInt(field, oldModifiers & ~Modifier.FINAL);

        field.set(null, newValue);
  
        modifiersField.setAccessible(true);
        modifiersField.setInt(field, oldModifiers);
  
        field.setAccessible(false);
    }

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

...К тебе обратились за помощью? Сам решить не можешь? Найди того кто может, а детали реализации сокрой от клиента. Инкапсуляция, блин. А то бывает и так http://www.newsland.ru/news/detail/id/613590/cat/37/ - моя хата скраю....

Time management: Срочно/не срочно/важно/не важно?

Эту табличку думаю видели и не раз.

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

Чтобы ответить на вопрос просто задай его

Когда-то уже упоминал про "исповедь отладки". Хочу написать еще раз...

Работаю программистом в молодой компании. Каждый день много новых знаний. Каждый день купа вопросов. Иногда, когда сам не можешь ответить на какой-то вопрос рука сразу тянется к аське чтобы спросить у какого-то сотрудника, который с больше долей вероятности имеет готовый ответ. Хороший способ, НО!

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

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

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

Помним, если мы кому-то делегируем что-то мы получим минимум знаний и опыта - мы его отдаем тому, кто ищет нам решение.

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