Archive for the ‘Менеджмент’ Category

История предыдущей фирмы (часть 4).

Четверг, Май 14th, 2009

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

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

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

В тот момент для меня поездка и жизнь в США казалась (и сейчас кажется) гораздо более перспективным методом увеличения инвестиций, чем продолжения работы по накатанной колее в Украине.

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

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

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

Теперь к ошибкам.

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

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

Нынешнее решение: Решения тут не вижу.

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

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

Я бы сказал, что это ошибка в конечном итоге и оказалась для нас самой критической.

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

Нынешнее решение: Даже если это займет гораздо дольше — поиск опытных sales (точнее директора продаж), идеально с серьезным опытом работы за рубежом. Собственно нужен хотя бы один очень опытный человек, который смог бы построить вокруг себя отделение. Возможно имел смысл искать его как раз за рубежом (США или Европа).

В целом этот год, был точкой бифукации и увы от этого момента фирма начала идти вниз.

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

История предыдущей фирмы (часть 3).

Суббота, Март 21st, 2009

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

История предыдущей фирмы (часть 2).

Среда, Март 18th, 2009

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

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

По пунктам:
— В 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 год.

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

Скруммное (часть 2).

Пятница, Март 6th, 2009

Эдак с месяца 3-4 уже сижу на Скруме. Маленькие записки по поводу него я уже писал, но постепенно набрались новые мысли и ощущения.

Из новых ощущений
— Очень понравилось то, что не пытаешься планировать в какие-то бесконечные дали, а решаешь текущие проблемы, оставляя будущие проблемы на будущее (причем это относится как к product managment’у, так и к программированию).
— Понравились burnchart’ы — гораздо более объективная и простая методика видеть, как движется проект (по сравнению с нереально тяжким и неточным MS Project).

А вот теперь то, что НЕ понравилось

— Узаконенное не планирование архитектуры.

Молодые/плохие разработчики с удовольствием работают в пределах user story. Приемочные критерии пройдены, а остальное их не сильно волнует. Проблема возникает в том, что они могут писать код, который является полным говном. И когда, даже внутри того же спринта сталкиваешься с другой user story в которой нужно использовать их код, приходится — разобраться в нем, отрефакторить, проверить, что старая US не поломана и что новая сделана. И это в результате выходит дольше, чем сделать хорошо сраз.

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

Впрочем проблема тут не только в Скруме, но просто в Скруме она узаконена.

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