Захлопнуть рот и слушать.

Февраль 20th, 2008

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

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

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

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

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

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

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

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

И еще одна важная вещь, нужно слушать КАК зарабатывать, перенимая методики. Пытаться скопировать ГДЕ и НА ЧЕМ заработать не имеет смысла, так как бизнес ниши появляются и исчезают. А вот метод ведения бизнеса меняется гораздо медленнее и чаще всего остается актуальным.

Честный бизнесмен?

Февраль 19th, 2008

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

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

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

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

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

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

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

По ходу обсуждения сформировал идею о трех уровнях лжи:

— Самая малая ложь: Преувеличение
— Средняя ложь: Укрытие информации
— Большая ложь: Фабриковка информации

P.S. Кстати, если вам нравиться мой блог и вы ведете свой, поставьте пожалуйста на меня ссылочку, а?

Проверка жизнью.

Февраль 17th, 2008

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

Если теория, расходится с практикой/реальной ситуацией, то грошь цена такой теории.

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

 Или, например мы недавно спорили с одним другом, где выше качество жизни в Москве или Саратове. Скажу честно, я был в Москве 2 раза, а в Саратове не был вообще. Тем не менее, я не поверил в его теорию, что в Саратове качество жизни выше, чем в Москве. Если бы так было, то люди бы ехали в Саратов, а не в Москву (на практике же все происходит наоборот). Замечу, правда, копнувшись глубже мы обнаружили, что под качеством жизни люди понимают разные вещи и для него теория вполне актуальна. Но,  я бы все равно сказал, что в наиболее популярном в России понимании слова «качество жизни», Москва предоставляет возможность жить лучше, чем в Саратове (иначе бы в нее не ехали).

Для горячих умов: Примеры — это примеры. Если вам они не слишком нравятся, не спешите их критиковать, если вам кажется что меинфреймы популярнее или Саратов лучше. Лучше обдумайте в целом идею.

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

Ремонт нельзя закончить, его можно только остановить.

Февраль 15th, 2008

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

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

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

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

С бизнес точки зрения проблема состоит в том, что:

— существенно увеличивается время на внесение изменений и написание новой функциональности

— соотношение поддержка старого кода / инновации, очень сильно начинает крениться в сторону поддержки

— увеличивается время «въезжания» новых программистов в проект

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

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

— сделать кучу маленьких рефакторингов

— переписать все заново

— сделать большой рефакторинг

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

Бывают такие ситуации, когда малые рефакторинги — не выход. Например, если постепенное улучшение кода может занять 5 лет.

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

Плохой код состоит из нескольких частей

— плохая и непродуманная архитектура (написание проекта без продумывания архитектуры наперед)

— плохой код на уровне использования языка (обычно это код написанный слабыми или неопытными программистами)

— кучу заплаток поверх архитектуры

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

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

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

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

И тут кроется одна большая проблема, качество кода, достаточно сложно измеримая величина. Поэтому рефакторить проект можно до бесконечности полируя заново какие-то кусочки. Поэтому, еще до того, как начинается рефакторинг нужно определиться с несколькими вещами:

— что конкретно улучшается

— поставить жесткие временные рамки

— точно определить как будет измеряться достижения целей

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

Очень важно избежать двух тенденций.

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

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

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

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