Victor Ronin's IT blog

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

В отличии от первой и второй части, где я рассказывал о 6-9 месяцах, тут я опишу весь 2005. В целом, при старте/бурном развитии бизнеса событий происходит гораздо больше, чем в тот момент, когда бизнес добирается до определенного плато.

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

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

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

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

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

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

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

За этот год фирма успела где-то дорасти до человек 20. Как я и писал был самый большой заказчик, который генерировал нереальную часть прибыли (я все продолжал работать team lead’ом у него на проекте (то есть руки были по локоть в коде)). Было несколько средних заказчиков и куча мелких заказчиков.

Итак, начнем проходиться по ошибкам.

Я бы сказал, что было три серьезных ошибки.

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

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

Вторая ошибка была в том, что мы пытались всех «вырастить». Имеется в виду, что если нам нужен менеджер — мы берем программиста с задатками лидерских способностей и даем ему в руки менеджерский флаг, если нам нужен lead в каком-то направлении мы берем хорошего программиста и ставим на это направление. Тут есть несколько проблематичных мест:
— выращивание людей занимает много времени и денег. Это хорошо вписывается в «фирма — семья», когда люди потенциально будут работать с нами следующие 10 лет, но плохо вписывается в ситуацию, когда идет дикая конкурентная борьба за кадры и все меняется на ходу.
— естественно люди без опыта делают ошибки. Особенно, если учесть, то что мы в этот момент заняты перекраиванием иерархии и общением с клиентом, мы даже зачастую не успеваем толком проанализировать ошибки и объяснить людям, как нужно. И вот тут, естественно начинаются заваленные проекты и недовольные заказчики

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

Третья ошибка — это было то, что я слишком много времени проводил программируя. Если в фирме из 3-4 человек — это вполне нормально, тогда каждая копейка на счету и мой переход из программиста в директора тогда серьезно снизил бы прибыль (если не сделал бы ее равной нулю вообще).
Но, когда в фирме 20 человек, то директор, который педалит код… хм… мягко говоря не правильное решение. Единственное, в чем была сложность, что работал я над кодом самого большого клиента (то есть не так просто было перестать это делать не увеличивая риски).

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

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

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

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

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

Продолжаю мою прошлую статью, дальше идем по истории фирмы и разгребаем, что было сделано хорошо и плохо.

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

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

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

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

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

Я помню даже, что некоторые проекты мы тестировали не показывая эти часы заказчику.

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

К концу этого периода у нас прибыль, все продолжала расти, но наметились уже проблемы.

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

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

Эта ошибка заключалась в том, что по росту фирмы мы не ввели нормальное разделение обязанностей и должностей.  Я например вполне занимался и sales (поиск новых заказчиков) и project management и developement и support. Хотя мы начали выделять людей с менеджерскими правами, но опять же на них ложилось и немножко sales работы и project management и development. Естественно люди не могут быть во всем хорошо и что-то по ходу терялось, делалось не на должном уровне.

Подошибок тут пожалуй было две: мы не выделил поиск заказов в отдельную функцию. Мы не разделили project management и development.

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

В данный момент я бы сделал две вещи:

— нанял бы sales, которые искали бы проекты

— нанял бы project manager’а, для управления проектами

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

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

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

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

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

Примерно такие были результаты за 2004 год.

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