Тут у меня может (еще не уверен) образоваться на руках проект от заказчика и мне могут понадобиться люди.
Люди нужны будут по нескольким направлениям:
— Symbian
— Windows Mobile (очень хорошо если есть хоть какой-то опыт с новых Windows Phone 7)
— люди, которые работали с софтом достаточно близким к USB hardware (увы более внятно пока описать не могу).
Если вы подходите под одну из этих категорий, черкните мне письмо (vronin at consultant.com) с тремя вещами
— резюме
— предпочтительным форматом сотрудничества (freelancer или через компанию или что-то еще)
— рейты
Обнаружил, что множество людей полагают, что если рынок вырос в X раз, то само собой и ваши прибыли (если вы связанны с этим рынком) вырастут за ним (может меньше, чем в X раз, но вырасти должны обязательно).
В основном эту мысль я слышал насчет iPhone’ов. Мол… Вон Apple миллиарды загребает на iPhone, кучи программ пишутся. Рынок вырос неимоверно, и поэтому если бы я разрабатывал под iPhone, то уже давно ездил бы на Буггати.
Пункт N1: Не помню, точную статистику, ну что-то типа верхних 1% от iPhone приложений приносят какие-то разумные деньги. (Это если самому продукт делать)
Пункт N2: Стоимость услуги зависит не только от спроса (скольким компаниям нужны iPhone программисты), но и от предложения (сколько программистов есть на рынке). И если 2 года назад, когда iPhone только взлетал, может быть в течении полгода и была нехватка (можно было снять сливки), то сейчас (по крайней мере в штатах) количество программистов под iPhone серьезно превысило спрос. (это насчет того, чтобы работать под заказ).
На самом деле у меня есть всего две вещи, которые хочется сказать, но которые меня (как русскоговорящего заказчика) просто выводят из себя. Причем это не то, что произошло один раз
или с одним человека, а вполне таки систематическое действие большинства freelancer’ов.
а) «Исчезания».
Работал уже с приличными количеством freelancer’ов (количество подбирается к десятку) и фактически все считают нормальной ситуацией исчезнуть на недельку, без предупреждения и отвечания на любые внешние прерывания (а-ля телефоны и почта). После чего, появиться, причем зачастую делая вид, что собственно говоря ничего и не произошло.
Дорогие товарищи freelancer’ы, обращаюсь к вам как представитель класса заказчиков. Это самый лучший метод потерять нас, даже если в остальное время вы супер-пупер потрясающе
исполнительные.
Одна мысль заказчика, что эта неделя исчезания могла произойти в какой-то важный момент автоматически ставит крест на всех остальных положительных пунктах.
Кстати, проблема само собой не само исчезание, а то что о нем не оповещается. Таким образом заказчик остается без возможности принимать решения на основе полной информации о ситуации.
б) Не делание того, что говорилось раньше.
Одна из идей длительной и плодотворной работы freelancer’а с заказчиком — это «притирание» с обоих сторон. Когда заказчик вам говорит — после того как вы исправили баг — пишите мне об этом, то лучше всего это и делать, так как он это делает редко просто так. Зачастую же выходит, что freelancer делает только то, что он считает полезным или нужным делать. Мы даже не говорим о каких-то технических решениях, где freelancer может быть прав, а заказчик не прав. Мы говорим о том, чтобы заказчику было удобно и хотелось с вами дальше работать. Как вы считаете, если он вам дал 5-10 простых правил — после каждого бага мне письмо, исходники присылать раз в неделю и т.п, то нормально ли забывать это в 80% случаев после несколько разового упоминания?
И снова дорогие товарищи freelancer’ы. Это второй по порядку самый лучший метод поставить крест на остальных ваших плюсах. Действительно, нефиг заказчику выпендриваться, пусть сам беспокоится о том, что я должен делать и постоянно мне об этом напоминает. Это правильный подход к жизни.
Повидал несколько компаний, который абсолютно по разному относятся к тому, нанимать внешние компании для выполнения каких-то работ или пытаться все делать внутренними силами.
Одна компания фактически сто процентов разработки, настройки и т.п. делала внутри. Точнее даже так, поработала с несколькими внешними компаниями, получила отрицательный опыт и теперь все делает сама.
Вторая компания, наоборот, выносит постоянно какие-то проекты, задачи, направления во внешние фирмы.
Естественно, за наем внешних компаний говорит то, что обычно нанимают компанию обладающую большим опытом в том, что она будет делать, плюс это экономит время сотрудников на какие-то более важные задачи и в случае если компания в оффшоре, то еще и деньги экономит.
А против, то что не всегда результат выходит желаемого качества, опыт не накапливается в компании и плюс дополнительные затраты.
Мои 2 цента по этому поводу. Как по мне, наймом со стороны пользоваться таки нужно, но делать это с умом.
Самое главное — это то, что никакая ключевая функция фирмы не должна выноситься из фирмы. Это правда очень стандартное и тривиальное замечание. Но капу чуть глубже, так как обычно проводят черту так — либо разработка ключевая (не выносим), либо не ключевая (выносим). Я бы проводил бы черту скорее по проектам/задачам. Например разработка следующей версии, которую ожидают самые ключевые заказчики — вещь ключевая и доверить это сторонней фирме как-то нехорошо. А вот например медленная и планомерная поддержка старых версий — вполне таки вещь, которая не так критична.
Второе замечание — это то, что нельзя выносить ту активность, которую никто не может проверить. Условно говоря, если нанять мощного архитектора со стороны, а в компании одни только средненькие программисты, то они никак не смогут проверить качество предоставляемой архитектуры. Безусловно, архитектора и будучи он сотрудником проверять будет некому, но вот если позже что-то пойдет не так и окажется что он явную фигню делал, то гораздо больше рычагов влияния на него (увольнение, не давание ему хороших отзывов).
Третье — это то, что выносить нужно только тогда, когда вынос приносит выигрыш по критическому ресурс. Обычно он приносит или уменьшение затрат или времени, редко оба пункта. И если для компании критично время, а она выносит для сокращения затрат — ни к чему хорошему это не приведет.
И четвертое — нельзя выносить то, что понадобиться завтра. Возвращаясь к тем самым багам в старой версии. В целом, знания связанные с исправлением этих ошибок будут дальше цениться все меньше и меньше. С другой стороны, если например компания собирается переходить с одной технологии на другую, то перенос проекта на новую технологию (даже если это не критичный сейчас проект), лучше таки делать внутри, так как ценность этих знаний как раз будет дальше возрастать.Что безусловно можно сделать, привлечь снаружи эксперта, который будет консультировать по особенностям технологии, но не более того.
