Archive for the ‘Эффективность’ Category

Как развивать свою фирму?

Четверг, Июль 15th, 2010

С пару недель назад, мне позвонил мой давний знакомый с которым мы уже добрых лет 7-8 не слышались и зашла у нас речь о freelance/небольших фирмочках.

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

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

Сразу скажу, нету у меня никаких данных, как «открыть глаза» лидерам таких команд и превратить маленькие конторы в IBM.

Начнем с начала:

1. Маржа прибыли

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

Если вы получаете X долларов и отдаете X долларов (включая вашу зарплату), то внезапно оказывается, что ваша прибыль равна нулю. И получается, что вы хотите получить что-то (рост) вкладывая ничего (0 долларов).

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

Так вот, ситуация следующая. Для того, чтобы расти, ваша маржа должна быть достаточно большая. Поэтому поводу попытайтесь или поднять свой рейт или опустить растраты. Условно говоря, гораздо лучше иметь 2 наемных сотрудника и маржу прибыли 50%, чем 5 наемных сотрудников и маржу прибыли 10%.

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

Как я уже говорил, у меня нет Единственного_И_Правильного ответа, на то как поднять свой рейт. Само собой разумеющиеся вещи — поговорите о повышении оплаты с текущим заказчиком, попытайтесь пойти на oDesk и выставить цену часа выше текущей.

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

2. Нишевость

Для того, чтобы продавать свои услуги дорого, вам нужно быть в нише, где конкуренция не так велика. Условно говоря, из существующих 100 фирм небольших фирм, которые бьются за заказы — 20 будут заниматься PHP, 15 будут заниматься RoR, 10 будут заниматься мобильными разработками и т.п. Будучи в первой группе, вы конкурируете с 20 фирмами разбросанными по миру и в результате вас прижимают к рейту $10/час, находясь в третьей группе, вы уже конкурируете только с 10 фирмами и вас прижмут к рейту $15/час. Находясь в какой-нибудь седьмой группе, где есть всего 2-3 фирмы, вы сможете получать $25/час. Естественно, я упрощаю, так как есть еще и спрос, кроме предложения. Но в целом, в небольших нишах соотношение спроса к предложению, лучше чем в mainstream.

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

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

3. Новые заказчики

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

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

Я бы сказал, что поиск заказов можно разбить на три уровня активности:

— Пассивный

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

— Слегка активный

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

Выжить тут можно, но если повезет и рост будет ну ооочень не спешный.

— Активный

Кто-то от фирмы ездит на конференции, выставки, активно «трется» с кучей разных фирм. А потом сидит на email’е и телефоне и пытается из них выбить заказы, договаривается о сотрудничестве и т.п. Плюс фирма участвует в закрытых или полузакрытых тендерах (до которых они опять же добрались через наработанные связи).

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

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

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

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

Максимальное количество строк кода.

Среда, Май 26th, 2010

После прочтения двух книг от 37signals, появилась у меня забавная мысль для блога (Да, кстати, вторую их книгу (Reworks) я НЕ рекомендую, если вы читали первую. Те же байты только в профиль. Взята первая книга и залита сладким сиропом).

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

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

Так вот, идея, которая мне пришла в голову, что нужно вывести формулу зависимости количества строк от объема продаж. А-ля, в год продается продукт на $1000, в нем может быть 3000 строк, продается на $100000 — в нем может быть 10000 строк. Продается на миллион, в нем может быть 50000 строк.

Моя формула примерно такова.

Максимально кол-во строк = (((Продажи за год) / (Средняя зарплата программиста за год)) ^ 3/4) * 10000

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

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

Принимаю критику и предложения по улучшению 🙂

Хороший или Гениальный программист.

Вторник, Январь 19th, 2010

Мысль из сегодня обсуждения… Плюс навеяно обсуждением книги Good to Great.

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

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

Слава богу, за свой опыт я не слишком часто с такими сталкивался 🙂

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

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

а) Не ходить на работу и пользовать это время на программирование. (+10% дополнительного времени).

б) не писать документации (+5% дополнительного времени).

в) не обучать других программистов (+10% дополнительного времени)

г) не менеджить других программистов (+15% дополнительного времени)

д) отсутствие отчетности отчетности (+5% времени)

е) отсутствие необходимости согласовывать решения (+5% времени)

е) не присутствовать на всех митингах (+10% дополнительного времени)

д) отсутствие переключения между задачи (+30% эффективности).

е) отсутствие прерываний работы другими людьми (+30% эффективности)

Итого уже накапало 50% дополнительного времени и 60% увеличение эффективности. То бишь, продуктивность возросла в 2.4 раза. Думаю, если покопаться и выписать более полный список того, что НЕ делает гениальный программист, то вполне разность продуктивности может получаться и в 3-4 раза (отсюда и выходит, что хороший программист делает 3 месяца, а гениальный вадает за 4 недели).

А теперь на секунду остановитесь и задумайтесь. Хорошо ли для компании такое увеличение продуктивности в 4 раза? Если вы ответили «Да», то вам двойка в четверти по бизнесоведению 🙂

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

Есть такая штука «technical debt». Это когда написал код на скорую руку и решил, что потом его приведешь в божеский вид, но потом как-то не наступило и код продолжает пользоваться/изменяться/дополняться. С каждым днем его становится все сложнее поменять и все больше времени уходит на его поддержание. То есть мы сделали что-то быстрее взяв в долг, но долг не выплатили и него начали расти проценты.

Аналогично,  можно, ввести понятие «process debt», когда что-то делается без учета уже действующих правил (а-ля документирование, обучения людей и т.п.).  Взять такой долг на короткое время вполне можно, но постепенно он накапливается (остальные разработчики не знаю тех частей, которые написаны гениальным программистом, не возможно предсказать даты выпуска продукта, так как нету никакой отчетности, время поддержки кода растет из-за отсутствия документации, обсуждений по ходу разработки и т.п).

В целом, Гениальных программистов в Бабруйск, даешь хороших программистов.

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

P.P.S. В еще нескольких комментариях началось обсуждение, как называют этих программистов. Предложенные варианты «Гики», «Хакеры». В целом, пусть хоть горшками (не чайниками) называют. Важно то, что с точки зрения множество людей в компании эти гении/гики/хакеры более (или по крайней мере не менее) полезны чем хорошие программисты выполняющие гораздо больший спектр задач.

Agile и автоматизированное тестирование

Четверг, Декабрь 3rd, 2009

После года работы в Agile режиме (в нескольких их видоизменениях) осознал, что Agile НЕ может нормально работать для без автоматизированного тестирования.

Пойду доказательством от противного. Пусть мы работаем в Agile и у нас нету автоматизированного тестирования. У нас есть пять user story, которые мы делаем. Внутри каждой из них у нас есть какие-то разумные критерии по которой мы определяем, что user story сделана — они обычно включают ручное тестирование измененной/новой функциональности.

По окончанию скажем 6 Sprint’ов, мы решает, что пора выпустить новую версию и тут мы обнаруживаем, что оттестированная каждая user story не значит оттестированный весь продукт. Соответственно, мы стартуем большое регрессионное тестирование всего продукта. Исправляем баги (для них можно даже сделать отдельные user story), потом опять проходимся и делаем регрессионное тестирование (так как исправленные баги могли внести другие). Надеюсь это знакомо? Итого, нам понадобилось еще 3 Sprint’а, чтобы привести все к виду, в котором можно выпускать.

Итого, на самом деле мы похерили пару принципов из Agile
а) То что продукт постоянно близок по качеству к выпускаемому.
На самом деле, чем дольше мы работаем без release тем общее качество у него будет хуже и хуже
б) То, что заранее НЕ нужно планировать отдельные фазы (разработка/тестирование).
Теперь нам заранее надо таки планировать, что на каждые 6 sprint’ов разработки — 3 sprint’а тестирования и стабилизации.
Ой… А это случайно мы не в waterfall возвращаемся, когда мы делаем сначала разработку, а потом тестирование?
в) То, что по ходу, можно и нужно улучшать код рефакторингом.
Рефакторинг кода, становится делать опасно, так как зачастую только через месяца (во время большего тестирования) становится видно какие проблемы он добавил.

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

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