Примерно год я работал совместно с коллегой-программистом, но к этому времени он закончил институт и решил искать фуллтайм в столице. Он работал фактически полный рабочий день (хоть и удалённо), поэтому вопрос его замены встал очень остро - мне было бы сложно тянуть дополнительно те проекты, которые теперь стремительно сваливались на меня (эффективность решившего уволиться сотрудника обычно резко падает). Дизайнер и верстальщик у нас сдельщики, поэтому с ними было бы проще, а тут - 40 часов в неделю прибавилось к моему итак нагруженному графику.
Уходящий сотрудник предупредил меня относительно заблаговременно, поэтому я для начала дал объявления только среди коллег - на форумах PHPClub и php.com.ua. Зарплату мы в компании особо заоблачную не платим, но предлагаем свободный график и удалёнку (главное - результат), поэтому я пока не знал - насколько быстро сможем найти специалиста и какой уровень у него будет. На приятное удивление, я получил с десяток резюме и несколько "стуков" в аську от знакомых. Уровень соискателей варьировался от откровенно новичков до вполне сильных программистов.
В итоге, мы сделали выбор и вот сегодня закончилась первая рабочая неделя нового человека. Я вполне доволен нашим сотрудничеством, хотя это только начало и на больших нагрузках, авралах, срочных работах он пока не проверен.
пятница, 25 июля 2008 г.
суббота, 14 июня 2008 г.
Сапожник с сапогами. Такими простенькими.
Вот уже года три как мной зарегистрирован домен digited.ru. И только в течение последнего месяца-двух я созревал наконец для создания сайта о наших услугах. Так сказать делаем сайты, а сами не имеем. Но теперь сапожник с сапогами, правда так как времени и усилий на собственный сайт как-то не сильно остается, пришлось сделать быстросайт на Zend Framework и бесплатном дизайн-макете. Вот он: digited.ru
понедельник, 19 мая 2008 г.
Точка выхода
Я обратил внимание, что вся моя фрилансерская деятельность состоит из двух основных фаз, которые условно назвал как "плоская фаза" и "точка выхода". Плоская фаза - это довольно стабильный и наиболее продолжительный этап деятельности, когда основные проекты получены, работы распределены и потихоньку выполняются. При этом горизонты чисты и новые проекты не так велики, либо легко "перевариваемы". Но бывает такое состояние, когда с проектами начинаешь не справляться, и ко всему этому появляются новые большие и небольшие предложения. Другими словами, наступает кризис.
В обычной ситуации приходится увеличивать количество рабочих часов для себя и своих коллег и ко всему прочему полностью отказываться от новых проектов. Это помогает выровнять ситуацию, но убивает перспективу. Говоря другими словами, команда несёт альтернативные издержки, которые равны упущенным деньгам за "отказные" проекты плюс сумму от всех упущенных клиентов, которые потом могли бы прийти по "сарафанному радио". Как второй вариант - брать новые проекты и откладывать те старые, которые можно затянуть. Этот вариант, вероятно, наихудший, так как новые проекты могут не прижиться, а старые будт утеряны. Тогда убитой будет не только перспектива, но и текущие завоевания.
Наиболее правильным ходом будет расширение команды под новые проекты. Действительно, почему бы не взять ещё человека, чтобы он потянул на себе новые задачи? Таким образом, мы дадим работу ещё одному программисту и получим в свой актив новых клиентов. Но в реальности, конечно, не всё так просто.
Во-первых, закон, гласящий, что каждый новый человек, взятый в проект после его старта, является фактором ухудшающим общую ситуацию, никто не отменял. Пусть в нашем случае программиста берём на новые проекты, но всё равно человек потребует дополнительного внимания, дополнительных действий по его интеграции, как в коллектив, так и в рабочую инфраструктуру (svn, проектные системы, стандарты программирования...).
Во-вторых, новому человеку нужно платить деньги. Для этого должны быть либо финансовые резервы в размере как минимум одной-двух зарплат привлекаемого программиста либо равная им сумма предоплаты за проект. Т.е. мы должны быть готовы хотя бы к двум вещам: оплате труда нового программиста и выделению собственного времени на его интеграцию в рабочий процесс. Тут я уже и не говорю о рисках, ведь за нового человека невозможно ручаться, и нет гарантий, что он не завалит новые проекты, ведь вы не знаете ни его планов, ни его реальной мотивации.
Но в любом случае, «точка выхода» является возможностью выйти на новый уровень, увеличить команду и финансовые обороты. А уж как оседлать эту точку, я напишу гораздо позже, когда проведу пару экспериментов.
В обычной ситуации приходится увеличивать количество рабочих часов для себя и своих коллег и ко всему прочему полностью отказываться от новых проектов. Это помогает выровнять ситуацию, но убивает перспективу. Говоря другими словами, команда несёт альтернативные издержки, которые равны упущенным деньгам за "отказные" проекты плюс сумму от всех упущенных клиентов, которые потом могли бы прийти по "сарафанному радио". Как второй вариант - брать новые проекты и откладывать те старые, которые можно затянуть. Этот вариант, вероятно, наихудший, так как новые проекты могут не прижиться, а старые будт утеряны. Тогда убитой будет не только перспектива, но и текущие завоевания.
Наиболее правильным ходом будет расширение команды под новые проекты. Действительно, почему бы не взять ещё человека, чтобы он потянул на себе новые задачи? Таким образом, мы дадим работу ещё одному программисту и получим в свой актив новых клиентов. Но в реальности, конечно, не всё так просто.
Во-первых, закон, гласящий, что каждый новый человек, взятый в проект после его старта, является фактором ухудшающим общую ситуацию, никто не отменял. Пусть в нашем случае программиста берём на новые проекты, но всё равно человек потребует дополнительного внимания, дополнительных действий по его интеграции, как в коллектив, так и в рабочую инфраструктуру (svn, проектные системы, стандарты программирования...).
Во-вторых, новому человеку нужно платить деньги. Для этого должны быть либо финансовые резервы в размере как минимум одной-двух зарплат привлекаемого программиста либо равная им сумма предоплаты за проект. Т.е. мы должны быть готовы хотя бы к двум вещам: оплате труда нового программиста и выделению собственного времени на его интеграцию в рабочий процесс. Тут я уже и не говорю о рисках, ведь за нового человека невозможно ручаться, и нет гарантий, что он не завалит новые проекты, ведь вы не знаете ни его планов, ни его реальной мотивации.
Но в любом случае, «точка выхода» является возможностью выйти на новый уровень, увеличить команду и финансовые обороты. А уж как оседлать эту точку, я напишу гораздо позже, когда проведу пару экспериментов.
среда, 14 мая 2008 г.
Офис в рюкзаке
Начался сезон плановых отключений горячей воды в городских квартирах и я с семьёй на несколько дней переехал в деревню, что в нескольких километрах от моего города. Двухэтажный домик, луга и река Ока в сотне метров - красота. График я спланировал так, чтобы не выезжать в Москву и заниматься исключительно программированием иной компьютерной работой, а в перерывах, устраивать "рекреационные" прогулки по деревне, к реке и в сторону леса.
Купил для ноутбука скайлинковский мобильный модем, прихватил телефон и аллес - офис мигрировал со мной в рюкзаке. Почта и текущие проекты расположены в сети, по остальным данным ноутбук синхронизирован с компьютером, поэтому трудностей в отрыве от основного места работы никаких не испытываю. Занял комнатку на втором этаже дома (с видом на липы да яблони), накинул на стол покрывало, чтобы помягче локтям и ладоням было и начал работать.
Сегодня уже успел прогулятся вдоль деревни и насмотреться на змейки просёлочных дорог, вытоптанных в траве, поглазеть на мирных овец и эмоционально напряжённых гусей, пару раз пересечь быструю речку Желёму, которую можно перепрыгнуть с разбега, и успел покидать в неё камешки. Пока кидал камешки, думал как бы мне лучше осуществить вывод нескольких словарей таксономии в одном из проектов на Друпале, а так же подсчитывал, сколько запросить денег у клиента за постановку его сайта на техническое сопровождение и контент-менеджмент.
В следующий раз решил сходить посидеть в ивах на берегу Оки. Кррасота :)
Купил для ноутбука скайлинковский мобильный модем, прихватил телефон и аллес - офис мигрировал со мной в рюкзаке. Почта и текущие проекты расположены в сети, по остальным данным ноутбук синхронизирован с компьютером, поэтому трудностей в отрыве от основного места работы никаких не испытываю. Занял комнатку на втором этаже дома (с видом на липы да яблони), накинул на стол покрывало, чтобы помягче локтям и ладоням было и начал работать.
Сегодня уже успел прогулятся вдоль деревни и насмотреться на змейки просёлочных дорог, вытоптанных в траве, поглазеть на мирных овец и эмоционально напряжённых гусей, пару раз пересечь быструю речку Желёму, которую можно перепрыгнуть с разбега, и успел покидать в неё камешки. Пока кидал камешки, думал как бы мне лучше осуществить вывод нескольких словарей таксономии в одном из проектов на Друпале, а так же подсчитывал, сколько запросить денег у клиента за постановку его сайта на техническое сопровождение и контент-менеджмент.
В следующий раз решил сходить посидеть в ивах на берегу Оки. Кррасота :)
четверг, 24 апреля 2008 г.
Ruby dooby doo
Так получилось, что начал сотрудничать с одной из компаний, которая свои разработки ведёт на Ruby'On'Rails. Специалистов по ROR сейчас на рынке труда не так много (как впрочем и спрос невелик), поэтому в компании решили - PHP-программисты являются вполне годным материалом для изучения ROR и применения
этой технологии в коммерческих разработках.
В целом, мы всегда используем PHP-фреймворк CodeIgniter, который очень схож по структуре с ROR. Я когда взглянул первый раз на структуру руби-приложения, то даже немного удивился - насколько всё похоже. Те же папки app/application, реализация того же паттерна MVC, соответственно папки Models, Views, Controllers. Конечно, ROR в сотню раз более развит и функционален, чем CI. Однако есть моменты, которые мне, как ньюби в этой технологии не очень понравились. К примеру - строгость наименований, включая "человекоплнятную" схему образования объектов на базе таблиц в БД в основе которой лежит правило множественного числа в английском языке (Products=>Product). Когда всё это изучишь - ничего сложного, но приходится запоминать много таких условностей, которые не всегда понятны напрямую из кода. Есть и очень удобные вещи - можно прописать связь объектов (т.е. фактически связать таблицы БД на уровне приложения) и все операции по вставке/правке данных делаются за пять минут, включая не совсем тривиальные вещи вроде загрузки изображения. Есть ещё и такие понятия как Observers, т.е. триггеры на уровне приложения, а не БД. К примеру, на объект Order можно прописать такой вот триггер и при вставке в базу нового заказа (Order) выполнится код триггера, например отправка уведомлений по почте заказчику и администрации. Таких вот деталей много.
Впечатление у меня осталось такое - если хорошо владеть PHP и CI (или каким-то другим развитым РНР-фреймворком), то ROR будет просто обычной альтернативой, нисколько не лучшей и не худшей по своей сути.
Ну и в процессе этого, сделан ещё небольшой проектик. Так что ещё +1
этой технологии в коммерческих разработках.
В целом, мы всегда используем PHP-фреймворк CodeIgniter, который очень схож по структуре с ROR. Я когда взглянул первый раз на структуру руби-приложения, то даже немного удивился - насколько всё похоже. Те же папки app/application, реализация того же паттерна MVC, соответственно папки Models, Views, Controllers. Конечно, ROR в сотню раз более развит и функционален, чем CI. Однако есть моменты, которые мне, как ньюби в этой технологии не очень понравились. К примеру - строгость наименований, включая "человекоплнятную" схему образования объектов на базе таблиц в БД в основе которой лежит правило множественного числа в английском языке (Products=>Product). Когда всё это изучишь - ничего сложного, но приходится запоминать много таких условностей, которые не всегда понятны напрямую из кода. Есть и очень удобные вещи - можно прописать связь объектов (т.е. фактически связать таблицы БД на уровне приложения) и все операции по вставке/правке данных делаются за пять минут, включая не совсем тривиальные вещи вроде загрузки изображения. Есть ещё и такие понятия как Observers, т.е. триггеры на уровне приложения, а не БД. К примеру, на объект Order можно прописать такой вот триггер и при вставке в базу нового заказа (Order) выполнится код триггера, например отправка уведомлений по почте заказчику и администрации. Таких вот деталей много.
Впечатление у меня осталось такое - если хорошо владеть PHP и CI (или каким-то другим развитым РНР-фреймворком), то ROR будет просто обычной альтернативой, нисколько не лучшей и не худшей по своей сути.
Ну и в процессе этого, сделан ещё небольшой проектик. Так что ещё +1
пятница, 28 марта 2008 г.
Ложка мёда
+1. Поставить этот инкремент мне было нужно ещё, пожалуй в начале марта. Ещё один проект сдали, запустили, но продолжаем его активно развивать и выводить из стадии бета-версии.
Суть проекта проста - хотите подобрать для выступления артиста (танцора, певца, стрип-группу, факиров и т.п.) то просто заходите на сайт, выбирайте нужные жанры, города, суммы и вперёд - заказывайте звезду на свой корпоратив или другое мероприятие.
Основные особенности проекта - большая доля функционала зашита на работу с картинками, плюс присутствуют платёжные системы и биллинг, а так же равноправие показов анкет обеспечивается случайными выборками при поиске. В остальном, с технической точки зрения - обычный каталог.
Этот проект собирался на фоне относительно нестабильной финансовой ситуации в компании. Причиной стало то, что мы успели "подсесть" на одного основного заказчика и прекратили активно развивать работу по привлечению клиентов, отвлекаясь только на редкие небольшие проекты, которые приходили к нам сами. Соответственно, когда заказчик в течение месяца стал сворачивать свои инвестиции (точнее переливать их в бизнес немного с другим профилем), то быстро перестроиться и наладить поток проектов оказалось сложно. Как всегда бывает, проблемы не приходят по одной и на этом фоне в другом нашем "большом" проекте на пару недель по причине болезни "выключилась" из работы наш куратор от заказчика. Работ это конечно не остановило, но вот выплаты отсрочились на месяц, так как к расчётной дате некому было оценить количество работ и подать в бухгалтерию документ на оплату, что усугубило ситуацию в целом. Прошло уже более двух месяцев, а мы только начинаем пожинать плоды своих маркетинговых усилий, стартовавших в конце января. На восстановление равновесия уйдёт ещё не меньше месяца. Будет хорошим уроком.
Суть проекта проста - хотите подобрать для выступления артиста (танцора, певца, стрип-группу, факиров и т.п.) то просто заходите на сайт, выбирайте нужные жанры, города, суммы и вперёд - заказывайте звезду на свой корпоратив или другое мероприятие.
Основные особенности проекта - большая доля функционала зашита на работу с картинками, плюс присутствуют платёжные системы и биллинг, а так же равноправие показов анкет обеспечивается случайными выборками при поиске. В остальном, с технической точки зрения - обычный каталог.
Этот проект собирался на фоне относительно нестабильной финансовой ситуации в компании. Причиной стало то, что мы успели "подсесть" на одного основного заказчика и прекратили активно развивать работу по привлечению клиентов, отвлекаясь только на редкие небольшие проекты, которые приходили к нам сами. Соответственно, когда заказчик в течение месяца стал сворачивать свои инвестиции (точнее переливать их в бизнес немного с другим профилем), то быстро перестроиться и наладить поток проектов оказалось сложно. Как всегда бывает, проблемы не приходят по одной и на этом фоне в другом нашем "большом" проекте на пару недель по причине болезни "выключилась" из работы наш куратор от заказчика. Работ это конечно не остановило, но вот выплаты отсрочились на месяц, так как к расчётной дате некому было оценить количество работ и подать в бухгалтерию документ на оплату, что усугубило ситуацию в целом. Прошло уже более двух месяцев, а мы только начинаем пожинать плоды своих маркетинговых усилий, стартовавших в конце января. На восстановление равновесия уйдёт ещё не меньше месяца. Будет хорошим уроком.
понедельник, 17 марта 2008 г.
Заказные услуги VS Коробочное ПО
Всё чаще стал задумываться о выходе на рынок коробочного ПО. Услуги имеют свойство быть заказанными один раз, а это прежде всего ведёт к нестабильности и неустойчивости бизнеса. Конечно, поток заказов на услуги может быть постоянным, однако сама суть услуги подразумевает, что каждый раз всё необходимо начинать почти с самого начала (даже не взирая на все имеющиеся наработки, фреймворки и прочие компоненты и методики). Готовое ПО, в свою очередь, может быть разработано/освоено один раз и в дальнейшем его остаётся только продавать и модифицировать.
Итак, какие я вижу риски в бизнес-модели, построенной исключительно на "штучных" услугах:
Работать же с коробочным ПО можно двумя путями - разрабатывать некий продукт самостоятельно или заняться освоением и поставками продуктов третьих сторон. В изготовлении продукта самостоятельно я вижу в основном минусы с точки зрения фрилансера:
Теперь вот хочу исследовать возможность продавать/внедрять/сопровождать готовые продукты третьих сторон. Как исследую - обязательно напишу отчёт.
Итак, какие я вижу риски в бизнес-модели, построенной исключительно на "штучных" услугах:
- Временное отсутствие заказчиков, простой команды.
- Массовый наплыв заказчиков, потеря клиентов (в следствие невозможности получения услуг, они уходят к конкурентам) и потеря денег, которые не смогли заработать. Резко расширить команду на несколько человек и наладить их работу - не получится почти наверняка.
- Если приходят в основном заказчики с малым уровнем наукоёмкости проектов, то снижается возможность повышать иновационность свих решений и технологий, так как не остаётся времени на собственное развитие в свободное время.
Работать же с коробочным ПО можно двумя путями - разрабатывать некий продукт самостоятельно или заняться освоением и поставками продуктов третьих сторон. В изготовлении продукта самостоятельно я вижу в основном минусы с точки зрения фрилансера:
- Невозможность создать "большое" полноценное коммерческое приложение. На это уйдут годы, либо нужно очень хорошо вложиться в разработчиков-компаньонов и самому долгое время работать "за еду". Выход по сути только один - найти инвестора, который поверит вашим обещаниям :) либо продавать небольшое, но очень нужное рынку приложение, что сложно представить.
- Необходимость нанимать дополнительных специалистов по "непрофильным" моментам - дизайн, юзабилити, разработка клиентских интерфейсов, техническое писательство, маркетинг, продажи.
- Возможность появления на рынке "killer application" для вашего продукта. Если появится более мощная, надёжная и более дешёвая система - всё вылетит в трубу. Соответственно, необходимо постоянно вкладываться в хороший маркетинг.
Теперь вот хочу исследовать возможность продавать/внедрять/сопровождать готовые продукты третьих сторон. Как исследую - обязательно напишу отчёт.
Подписаться на:
Сообщения (Atom)