Деньги и конец компаний.

Февраль 13th, 2008

 

Еще одна банальность, но которую нельзя забывать, на тему моего предыдущего поста.

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

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

Что важнее для компании деньги или драйв?

Февраль 11th, 2008

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

Здесь есть два мнения:

Если вы будете вести свой бизнес только ради денег — вы никогда не добьетесь большого успеха.

Если вести свой бизнес без учета денег или не ориентируясь на них, то бизнес вылетит в трубу.

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

И если вы в это не верите, то просто оцените два примера крайних ситуаций.

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

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

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

Серебряная пуля в разрезе.

Февраль 10th, 2008

В далеком 1986 году, мистер Брукс написал статью «No silver bullet”. Эта статья в последствие стала классикой жанра. И хотя многие не читали оригинальную статью, тем не менее термин «серебряная пуля» очень прижился.

После этого статья вошла в книгу Брукса «мифический человеко-месяц». Тут эта книга есть на русском (похоже издание 95 года).

Для тех, кому лень читать много букв, там говорится о том, что в программировании не будет изобретено никаких методов или технологий, которые позволят существенно (скажем в 10 раз) улучшить эффективность разработки. Идея обосновывается тем, что вся разработка состоит из двух частей – сущности и побочных сложностей. И что сущность нельзя сделать проще, а основные побочные сложности (такие как, например, написание программ на assembler’е) уже упрощены.

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

Просто, хочу внести свою небольшую лепту в обсуждение статьи Брукса.

Взглянем, что же произошло за последние 20+ лет, с тех пор пока была написана его статья. Я специально не хочу давать оценку каждому пункту, насколько он убыстрил программирование, чтобы не возникли споры именно вокруг этих цифр. Но, я хочу показать то, что ускорило написание программ.

Итак, к фактам:

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

Б) Компьютеры стали быстрее, что позволяет вести быстрее разработку (более быстрая компиляция и т.п. вещи)

В) Языке стали еще более высокоуровневыми (например, C# vs C).

Г) Операционные системы предоставляют API с функциональностью, которая гораздо богаче, чем в 86 году.

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

Е) Ну и естественно, появился доступ к дичайшему количеству документации, обсуждений в интернете особенностей написания кода и т.п..

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

Однако, я напоследок оставил то, что действительно является «серебряной пулей».

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

Приведу пример. Возьмем автоматизацию склада в 1986 и в 2008 году.

1986 год: Небольшая программка в текстовом режиме написанная на С (не на C++). Возможности – ввод пришедших товаров, удаление ушедших и показ текущих. База данных хранится в текстовом файлике.

2008 год: RFID ворота на складе, подключенные к машинам на которых установлен Ubuntu с программой, которая выгребает данных с RFID считыватели и по сети закатывает в БД. На сервере крутится программа, которая выгребает данные из БД и через SOAP загружает их в Sales Force Automation (я правда не уверен, что они работаю с складскими данными).

Итого, в первом случае мы имеем программку и человека, считающий ящики на входе и выходе, вводящий постоянно это в программу. Фактически полное отсутствие report’ов и невозможность получения данных на другом компьютере (интернета еще нет)

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

Дай бог 0.01% второй системы написано программистом, а остальные (сайт sales force, библиотеки по работе с RFID, база данных, tcp/ip, xml, soap, графический интерфейс, броузер и т.п.) досталось ему фактически забесплатно. Если бы он пытался написать все сам (даже «срезая углы») у него это заняло бы всю жизнь.

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

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

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

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

P.S. Только дописав статью я понял, за что собственно говоря борется opensource  communit. Ведь собственно во многом именно благодаря им мы получили улучшение в эффективности.

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

Я – меркантильная сволочь.

Февраль 8th, 2008

Да, я меркантилен и не считаю это зазорным фактом. Попытаюсь расставить все по полочкам.

Давай-те заглянем «под капот» трудовой деятельности IT народа. Я уже это упоминал следующую классификацию в пару статьях. И работа/бизнес состоит из несколько составляющих, которые мы пытаемся оптимизировать:

— Деньги

— Интересность — скучность

— Потраченное время — свободное время

— Спокойствие — нервность

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

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

Теперь, совершаем разворот.

Я хочу описать, почему я ушел/ухожу из программирования в бизнес. В определенный момент, когда я был молодым программистом я получал $50/месяц, и знал, что как только стану чуть более опытным, то начну получать $100. Потом было $200, а потом было $400. С каждым днем я становился все более опытным программистом – решающим все более сложные проблемы, все с улучшающемся качеством и за более короткие сроки. И вот когда я достиг магической цифры $500, я обнаружил, что нахожусь на тогдашнем потолке зарплат . И например, даже если бы стал я стал в 10 раз эффективнее и мог бы заменить весь отдел, то может быть моя зарплата стала бы в полтора-два раза больше и это был бы уже абсолютный потолок. Таким образом я уперся в пресловутый «стеклянный потолок».

Из разговора, который с D.Mikhantiev в этой статье: «Если уперся в потолок, то у тебя есть два выхода — остаться в деле и ограничить потребности (”дауншифтинг”, по-моему, как одно из средств), либо подняться по лестнице на другой этаж».

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

Проблема состояла в том, что я могу так идти с этажа на этаж десяток лет, причем мои старые знания бы отмирали, давая место новым. И в конечном итоге я бы уперся в потолок фирмы (каждая фирма – это здание, где есть последний этаж). Как я понимаю, дальше мне ответят, что надо двигаться в новое здание и в конце-концов стать главой IBM и получать З/П в $20M в год.

Есть вещи, которые мне в этой схеме не нравиться:

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

Как пример, представим себе, что босс хочет, чтобы вы работали вдвое больше (что-бы получать вдвое больше результат). Согласны ли вы будете делать это получая всего на 20-30% больше? Кстати, результат будет вряд ли вдвое больше (из-за усталости), но это другой вопрос.

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

Возникает вопрос, почему единственный недооплачиваемый метод – это когда специалист становится в два раза эффективнее?

На эту тему я писал о программистском синхрофазотроне.

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

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

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

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

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

Ну тут, все ясно. Можно конечно рассуждать о том, чтобы стать наемный CEO в IBM (как я писал чуть выше). Однако, вероятнее всего верхняя граница ЗП (в случае если не переезжать в другой город) окажется CTO какой-нибудь крупной локальной фирмы. И потолок зарплаты окажется в раза два выше чем у программиста, но не более того.

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

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

ok. Спросите вы… А что же с остальными параметрами (деньги, интересность, спокойность, потраченное время)? Да, если заниматься бизнесом, то вероятнее всего спокойствие и потраченное время оптимизации (по крайней мере в начале не поддаются). Но с таким же успехом они могут страдать и при наемной работе.

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

Вот так вот борьба за зеленые бумажки привела меня в бизнес. Кстати, базируясь на прошлой статье «Цель vs Путь«

хочу сказать, что именно как целевика меня просто плющило, то что цель может быть очень близка (увличение ЗП на 20%), но абсолютно недостижима.

P.S. Не относящееся к статье. Хочу сказать большое спасибо Славе Панкратову, который ведет сайт IT и бизнес. Его сайт гордо вышел уже на 5 строчку по приведенным на мой блог пользователям.