Продолжаю мою прошлую статью, дальше идем по истории фирмы и разгребаем, что было сделано хорошо и плохо.
В прошлой статье я достаточно сильно налег на то, какие ошибки были допущены. Пару слов все таки о том, что было хорошо (а то не понятно, каким образом компания вообще росла).
По пунктам:
— В 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 год.
Продолжение следует…
Интересная статья — жду продолжения. Вот только ошибок в тексте многовато. Не мешало бы вычитать ;).
Про ошибки тоже согласен
«Ну и теперь к моему перейду к моему любимому пункту. Анализ ошибкой.«
Поправил.
>В тот момент, когда фирма стала расти и у нас не было нормальной структуры, мы фактически потеряли контроль и просто как-то решать проблемы с заказчиками по мере их поступления. * вот эту проблему понимаю прекрасно. Довольно сложно возложить конкретные обязанности на человека, не зная в полной мере его качественных характеристик, сможет ли он выполнять то, что от него требуется. И пока присмотришься — время уходит. Кроме этого, я знаю психологию довольно многих руководителей и топ-менеджеров: если я лично не сделаю или хотя бы не проконтролирую — не сделает никто. Эта позиция вполне понятна, но сильно разконцентрирует усилия, в том числе и по времени, что в общем в абсолютном большинстве дает отрицательный результат.
Вопрос: была ли текучка кадров, и если была, то на сколько большая?
Солидарен со Сепкой и жду продолжения))).
Проблема скорее была не в том, что мы присматривались к людям и им не доверяли. Просто плохо понимали, что с ростом фирмы, нужно делигировать все больше и больше задач и концентрироваться на более высокоуровненых и приоритетных.
>если я лично не сделаю или хотя бы не проконтролирую — не сделает никто.
Да. У меня у самого такое было.
Хотя, тут нужно разделить на две части
>если я лично не сделаю — не сделает никто.
Это неправильная психология, я о ней кстати писал тут:
http://victorronin.com/2008/06/27/standartnaya-oshibka-nachinayushhiyax-programmistov-biznesmenov/
>если я бы не проконтролирую — не сделает никто.
А вот это таки правильная психология. Если не контролировать — то может быть что-то будет исполнено, может быть и нет. Даже если все подчиненные идеальны, то что-то все равно пропуститься. И вот тут возникает вопрос — как определить, что было таки сделано, а что нет, если не контролировать.
Под контролировать я имею в виду — иметь отчетность и ее просматривать.
Я не говорю о недоверии, как таковой. Имел в виду: справится или нет, хватит ли необходимых качеств… Но я Вас понял.
А под контролем, говоря о неправильной психологии, я подразумевал конроль не самих этапов — выполнено или не выполнено (тут согласен с Вами с контролем отчетности, без такого конроля хода выполнения задач никак), а контроль, ну, скажем, с просмотром выполненного. Именно такой конроль расконцентрирует и отнимает кучу времени, тем более если голова занята иными, более важными вопросами, и собраться и вникнуть в отдельный вопрос бывает довольно сложно.
У меня дев. фирма уже 3 года, спасибо за статью. Некоторие ошибки увидел и в себя. Но я начал без опита project managera, перешел с фриланса. Тоесть не все сразу понятно было…и т.д.
Вопрос к Вам, как можн виделить/отделить sales от project manager? я как и ви занимаюсь всем от sales к support. такие же полномочия и обязаности у моего project managera. Но что би виделить sales надо думаю немало понимать в IT/programming что-бі сделать оценку проекта… какие у вас будут коментарии к етому.
сори за русский я со Львова ))
>Но я начал без опита project managera, перешел с фриланса. Тоесть не все сразу понятно >было…и т.д.
У меня тоже самое было. Мой опыт как в менеджменте был тогда порядка пол года. До этого правда достаточно много был team lead’ом, но это чуть другое.
>Вопрос к Вам, как можн виделить/отделить sales от project manager? я как и ви занимаюсь >всем от sales к support.
Sales — это человек, который занимается рассылкой, звонками, отсылает брошуры по компании, отвечает на общие вопросы заказчика и т.п. Идеально, чтобы он брал на себя ВСЮ коммуникацию до получение проекта. Если ему нужны технические детали (и estimat’ы в том числе) — то он шлет вопрос project manager’у или team lead’у. Естественно лучше иметь разумно технически подкованного человека на этой позиции, чтобы он не за каждым вопросом бегал к технарям, а только по важным. В тот момент, когда проект получен, детали обговорены, то проект передается project manager’у.
Project manager уже работает в пределах проектах. Общается с заказчиком о приоритетах, продвижение проекта и т.п. Причем идеально, если project manager не является team lead’ом и/или программистом. То есть, project manager занимается тем, что контролирует, что все идет гладко, помогает решить проблемы внутри компании по проекту и обшаеться с заказчиком по текущим проблемам.
Support в небольшой компании таки будет лежать на project manager’е. В более крупной, уже стоит делать отдельную позицию, чтобы project manager’ам не нужно было постоянно прыгать на прошлые проекты, просто для того, чтобы разобраться с двумя багами, пришедшими от заказчика.
>сори за русский я со Львова ))
No problem. Кстати, можно и на украинском. Ответить на нем не смогу, но прочесть и ответить на русском — вполне.
Заметки для будущей книги — однозначно! 🙂
Та не… спасибо 🙂 Книгу я уже пробовал. Времени съедается тьма, а результата гораздо меньше, чем от блога.
Витя, читаю и себя узнаю.
> Кстати, важный момент, первый год огромное количество работы делалось под моим именем. То
> есть приходил заказчик и говорит, блин, какой ты крутой программист, сделай нам X. Естественно > меня больше чем на определенное количество проектов не хватало, поэтому проекты делали
> другие люди, а я зачастую участвовал только в решении сложных задач и переговорах с
> заказчиком.
У нас проекты непрофильное направление, но происходило именно так. Из-за небольшого объема проектов всопитание кадров, которые могут сами общаться с заказчиком, все время откладывалось. В итоге все общение висело на мне, что тормозило процесс и заставляло отказываться от неплохих в целом проектов.
Ситуация и сейчас не поменялась. От большинства проектов мы отказываемся, делая исключение для старых клиентов и тех ситуаций, когда кастомизация позволяет продать основной продукт.
Идеальным мне видится описанный тобой вариант, когда заказчик достаточно крупен, чтобы потянуть оплату команды разработчиков и персонального менеджера. Тут обе стороны в выигрыше.
>Витя, читаю и себя узнаю.
:))
Та я думаю грабли у множества людей должны быть очень похожи. Особенно если стартовые точки примерно равны (отсутствие большого стартового капитала и опыта управления бизнесом).
>Ситуация и сейчас не поменялась. От большинства проектов мы отказываемся, делая >исключение для старых клиентов и тех ситуаций, когда кастомизация позволяет продать >основной продукт.
Ну, думаю, что теперь это делается осознанно.
>Из-за небольшого объема проектов всопитание кадров, которые могут сами общаться с >заказчиком, все время откладывалось.
Я вот по этому поводу думал. И я все дальше отхожу от идеи воспитания кадров. Не в том смысле, что вообще в обучение не вкладывать, а в смысле, что если у человека опыта в чем-то ноль, а для выполнения работы нужен профессионал — то все таки лучше нанять человека у которого уже есть опыт и вытягивать его.
Просто, в обучение вкладывается много сил/энергии/день, а результат приходит через годы, причем чаще всего человек к тому момент успевает сменить работу.
По этому, уж лучше нанять одного толкового менеджера, который сможет быстро войти в курс дел и взять на себя часть общения.
Интересная информация
Я уже на практике убедился, что каждый должен выполнять строго определенную работу, а если человек и менеджер и программист и сисадмин, то ничего хорошего из этого не получается! Хотя с другой стороны, в большинстве случаев начинать приходится с малого и нанять сразу большой коллектив не удается…
Да, безусловно, для того, чтобы человек хорошо что-то делал, он должен на это уделять достаточно много времени. Если же его время и внимание размазано по десяти вещам, то качество будет страдать.
Ну и как вы точно заметили, когда коллектив маленький, тут уж хочешь не хочешь приходиться несколько функций на одного человека возлагать.
>нанял бы sales, которые искали бы проекты
IMHO, этот совет теоретически правилен, на практически трудноисполним.
По моему опыту, лучше отсутствие выделенного sales, чем плохой sales.
Хороший sales — редок.
Хороший sales, умеющий продавать такой специфичный товар, как разработку — еще более редок.
Хороший sales, умеющий продавать такой специфичный товар, как разработку, который пойдет работать в никому не известную фирму — вообще на грани фантастики.
Cо всем согласен, кроме фразы:
По моему опыту, лучше отсутствие выделенного sales, чем плохой sales.
Да, действительно хорошие sales редки, тем более с узкой специализацией, тем более почему-то готовые идти в незвестную фирму.
Однако, отсутсвие sales — обозначает две вещи
а) Либо бизнес живет на том, что упадет «с неба», что не является нормальной стратегией
б) Либо владельцы исполняют роль sales (что чаще всего и происходит). Хитрость состоит в том, что нету гарантии, что владельцы будут хорошими sales тоже. Например в нашем случае и я и брат — технари, поэтому с sales у нас было откровенно тяжко.
Так, что как по мне, лучше найти одного или несколько средних sales, чем быть самом этим средним sales. Особенно это актуально, когда фирма растет и у директора есть куча всего, кроме того, чтобы искать проекты.
самая интересная из всех частей