В прошлой статье я остановился на мае 2007 года.

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

Почему ушел заказчик? Хороший вопрос. Там много чего намешано было – то, что я был и сотрудником и владельцем provider’а и часовой пояс, и консолидация offshore активности и не слишком удачные с технической стороны последние несколько месяцев. Но, ключевым пунктом я бы сказал являлось то, что мы просто загнали себя в угол предоставляя им только Palm разработку(которая к тому времени была уже откровенно не актуальной).

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

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

Где-то в сентябре 2007 я приезжал в Украину и все еще давал речь о том, что хоть сеячас тяжко, но мы все еще движемся в светлое будущее. Хотя, мягко говоря, я сильно в этом сомневался.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А вот теперь к самому интересному. Что же все таки мы могли сделать?

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

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

На данный момент я вижу три наиболее перспективных на тот момент пути

а)  Постепенный слив фирмы

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

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

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

Ясно, что с такой стратегией много с фирмы не получишь, но все равно больше чем в случае полного вылета.

б) Реорганизация

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

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

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

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

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

Кстати,  именно он подкинул мне идею (был ее автором) самой моей любимой серии статей про программистский синхрофазатрон.

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

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

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

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

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

Итак начнемс…

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

С точки зрения хорошего программиста Пети. Работа выглядит так
- Васе дали задачу, которую Петя мог сделать за 5 часа
- Вася поморочил Пети голову 2.5 часа, чтобы понять как ее сделать
- Вася проработал над задачей 20 часов пока не сделал
- Пете еще 2.5 потом пытается привести в порядок, то что натворил Вася

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

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

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

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

Менеджер мыслит примерно так (естественно не с такими детальными выкладками)

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

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

Кстати, входные деньги – это не только деньги на зарплату программисту, но и на например покупку книг, или оплату другому программисту время консультаций и т.п.

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

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

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

Небольшое замечание по измерению оценки. Программист оценивает других программистах в терминах «на» – Вася сделает туже задачу _на_ X долларов дороже чем я, поэтому Вася не нужен. Менеджер измеряет в терминах «в». Вася сделает туже задачу _в_ Y раза дороже.

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

Возвращаясь к Васе. Пусть Вася по этой формуле оказался в 4 раза менее эффективным. Тем не менее, с решенной задачи мы все еще имеем $10k – $4k = $6k прибыли.
Хотя безусловно, если Васю уволить, то получится $9k прибыли.

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

То есть, если у него эффективность жуткая (в 7 раз хуже, чем у Пети), но работает он автономно и Петю не трогает вообще, то тогда, получается, что они вдвоем могут приносить $10k-$1k (Петя) + $10k-$7k (Вася) = $12k. А если Васю уволить, то прибыль падает до $9k.

Ну и теперь с точки зрения предпринимателя.

Базируем ее на точки зрения точке зрения менеджера. Только введем некоторые дополнительные параметры.

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

Итого, когда у нас диапазон качества, в абсолютно условных цифрах от 3 до 5. То вполне возможно, Вася сделал бы задачу с качеством 3 с той же эффективность, которое Петя делает задачу с качеством 8 (с одной стороны такое качество просто и не нужно, с другой стороны Петю ругать за дополнительное качество тоже было бы странно, да и плюс именно из-за Пети в целом программа не выпадает из диапазона).

Заметьте, как мыслит программист

а) Берется факт о случившейся ситуации где эффективность другого программиста была низкая

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

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

На самом же деле расход и доход динамичен. Он происходит в разные моменты времени.

Вернемся к примеру, который привел программист. Если плохой программист тратит в одной точки времени 5 часов хорошего, 20 часов своих и после этого в какой-то момент получается прибыль $10k, то действительно второй программист паразитирует в прямом смысле слова.

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

Для того, чтобы все стало на свои места, возьмем фирму из 30 плохих и 3 хороших программистов. Если мы слушаем 3 хороших, то мы увольняем всех плохих и ждем пока хорошие сделают всю работу которые делали бы плохие. Проблема заключается в том, что плохие хоть и были менее эффективны, но делали ее параллельно. Хорошие более эффективны, но делают ее последовательно. Итого, вместо выпуска через месяц и получения дохода, выпуск происходит через два месяца.

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

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

Тут кроется одна проблема, это хорошо масштабируется от 1 до 5 хороших программистов, плохо от 5 до 50 и не масштабируется фактически вообще от 50 до 500 программистов. Поэтому для увеличения прибыли и сокращения сроков, компании проще нанимать 50 хороших программистов и 500 плохих, чем 100 хороших.

И последняя особенность.  В формуле прибыль = доход – расход, и доход и расход на самом деле являются не константами, а функциями.

Во первых, если фирма имеет большие продажи, то тогда доход от одной и той же функциональности может быть разный. И вот возникает интересный эффект. Если доход $10k, при расходах $1k и $7k – то отличие хороших и плохих программистов очень чувствительно (так как это изменяет прибыли от 90% дохода до 30% дохода). А вот если доход составит $100k, то разница между хороших и плохим программистов фактически не чувствуется (99% или 93%).

Важное замечание, которые мне написали: Это естественно более актуально для продуктов, где прибыль зависит от объема продаж. Для попроектной работы, прибыль заранее фиксирован. Более того, чаще всего они сильно прижат конкуренцией за исполнение проекта.

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

Фух… Подводя к итогам всю эту фигню, которую я написал.

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

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

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

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

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

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

Так вот, по поводу этого, у меня пару «за» и пару «против».

Начну очень издалека.

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

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

Теперь прыгаем к примеру с продавшицой. Пусть есть магазин в котором объем продаж $5k-$10k и в нем сидит продавщица, которая «отрываясь» на клиентах отбивает их от магазина и приближает продажи ближе к $5, а не отрываясь она приближает их к $10k. У нее же самой ЗП, может быть вполне $200. Стоит ли ей платить больше (есть на рынки именно такие цены). Я бы сказал, стоит если она старается, если же она требует это пытаясь держать вас в заложниках того, что ваша прибыль упадет на $5k, то ее надо гнать в шею, как того работника который просил повысить ЗП, чтобы он не работал плохо.

Смотрим дальше, предположим из-за ново нанятой продавщины, просто отбоя в магазине нету, вероятнее всего ей можно и $500k и $1k поставить зарплату (гораздо выше средней по рынке), если продажи зашкалили за $15k.

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

А теперь, какое это к черту имеет все отношению к лидерам?

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

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

Еще дальше возвращаясь, к статье Макса. Так вот, с чем я НЕ согласен, что роль лидера преувеличена. Да, CEO не решает все в компании (как Макс писал, статистически 10% успехов компании может быть отнесены к действиям CEO). С другой стороны, если 10% успехов увеличивают в 10 раз прибыль, то можно и в раза два зарплату им выше держать.

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

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

Тоже самое в компаниях. Да, лидерство не так важно, когда все идет хорошо. Но когда все идет плохо, то лидерство – это единственное, что может спасти компанию. Поэтому, как по мне роль лидерства не преувеличена, а просто не правильно акцентировано внимание, когда же его роль действительно важна.

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

Так вот, это ошибка звучит в бизнес плане примерно так: «… и вот тут мы пообщаемся с крупными фирмами…».

Проблема заключается в том, что крупные фирмы ежедневно получают десятки, а то и сотни разных email’ов и звонков с разнообразными идеями и предложениями. И дай бог 1% из них доходит до стадии серьезного планирования, до стадии исполнения доходят 0.1%, а до стадии денег 0.01%.

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

Соответственно, для этого,  нужно:

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

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

Исходя из пункта а) + б) – в этих sales нужно будет вкладываться. Причем, не $100/месяц наняв девочку где-нибудь черт знает где, которая умеет слегка говорить, а вполне придется вкладывать взрослые цифры в взрослый sales.

Учитывая, что под крупными фирмами вероятнее всего подразумевается, что-то зарубежное и серьезное. То в добавок, sales должен иметь опыт работы с такими фирмами и иметь возможность подъехать и лично пообщаться в эти фирмы.

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

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

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

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

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

Что вы скажете человеку, который будет вскапывать огород размером в 500 гектар с помощью лопаты?

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

И что нужно:

а) Добавить новые и более мощные инструменты

б) Добавить новые и более мощные знания как управляться с инструментами

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

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

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

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

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

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

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

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

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

P.S. Кстати, небольшая рекламная пауза, про которую я забыл. Эти два сайта публикуют мои статьи, за что им большое человеческое спасибо.

Загляните на сайт KakRabota.com.ua. Он посвящен в первую очередь отзывам сотрудников и соискателей о различных компаниях Украины и России, сбору статистики зарплат в разрезе отделов. В разделе форума есть опубликованные вакансии и резюме с возможностью комментировать их или задавать вопросы а так же просто обсудить темы связанные с работой. А также на сайте есть блог разработчиков, на котором вы можете регулярно читать интересные статьи опять же на околорабочую тематику.

А второй сайт – это, сайт www.webdiktor.ru. Это забавный бесплатный сервис по озвучиванию статей. Они меня тоже посчитали и озвучили уже несколько статей вот тут. Так, что если есть люди, которые любят слушать статьи в стиле podcast’ов – заглядывайте туда почаще. Хотя, стиль начитывания статей слегка своеобразен.

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

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

Проблема с должностями, собственно, состоит из нескольких частей

- люди делают не то, что они должны делать (и мешают этим жить другим)

- люди не делают то, что они должны делать (и из-за этого, что-то идет не гладко)

- люди неправильно распределяют время между несколькими вещами которые они должны делать.

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

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

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

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

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

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

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

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

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

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

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

- третья вещь, которую нужно сделать – это написать для каждой должности, кто за нее отвечает. Не беспокойтесь, в начале это может выглядеть примерно так: “Директор – я, Менеджер – я, Программист – тоже я». Собственно, так реально дела и обстоят, когда вы один в фирме.

Что же теперь делать с этой все фигней, которую вы написали?

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

Вообще, не бойтесь менять эту схему, она не высечена в камне. Как раз основная идея, подстраивать ее под ситуацию.

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

Теперь следующий вопрос, зачем столько пурги, вокруг этого вопроса? Как обычно, можно сказать: «очередное бумагомарательство и так все умные люди и все знают, что делать».

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

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

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

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

P.S. Особенно эта вся фигня помогает преодолеть проблемы 10-20 человековой компании, когда компания становится слишком большой, чтобы директор во всем участвовал, но еще достаточно маленькой для серьезного распределения по отделам, должностям и т.п.

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

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

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

Взглянем «под капот» культуре.

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

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

- чувствование себя частью компании

- хорошие отношения в коллективе

- хорошие отношения с начальством

- знание того, что фирма делает что-то полезное и важное

- знание того, что фирма развивается

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

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

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

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

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

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

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

А вообще, с чего я начинал – это с бескультурья. Подумайте, если вы собираетесь улучшать КК в вашей фирме, это значит, что работники у вас не мотивированы. И, судя по всему, вы будете «лечить» симптоматику, а не корень проблем. Уж лучше поискать, что является корнем их немотивированности (постоянные стрессы из-за сроков,  невозможность продвижения по службе, низкая ЗП и т.п.)

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

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

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

Рождение.

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

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

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

И количество человек  в фирме обычно один или два.

Детство

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

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

Стандартное длительность периода – около года. Количество человек не больше чем десять.

Продолжение следует…

Иллюзия неуязвимости обычно появляется из-за того, что фирма является лидером в какой-то нише, причем абсолютным лидером, до которого просто нереально дотянуться номеру 2. Опять же возвращаясь к крупным затасканным примерам – IBM чувствовала себя неуязвимой до взлета Microsoft, а Microsoft был неуязвим до появления Google. Обычно именно в тот момент, когда компания начинает считать себя номером один, эти иллюзии развенчиваются. Происходит это из-за того, что компания, к тому времени, становится уж очень глупой (в смысле закостеневшей и медленной) и какой-нибудь шустрый и молодой стартап атакует их с абсолютно неожидaнной стороны. Естественно, компании не погибают от одной атаки, а зачастую живут десятки лет, но, тем не менее, история полна таких примеров, когда абсолютный лидер терял громадную долю рынка из-за какой-нибудь молодой и зеленой компании.

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

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

Этому странному феномену есть несколько объяснений:

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

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

в) Также у маленькой компании просто нет налаженных каналов получения проекта и нет хороших references.

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

Несколько идей о преодолении низцих цен.

- Если вы работаете в рынке с большой конкуренцией то, увы, вам прийдется таки смириться с низкими ценами.

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

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

- Если рынок «перегрет» (как например было и есть в Индии относительно IT сферы) даже маленькие компании могли брать большие и дорогие заказы.

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