Сапожник с сапогами. Такими простенькими.

Вот уже года три как мной зарегистрирован домен digited.ru. И только в течение последнего месяца-двух я созревал наконец для создания сайта о наших услугах. Так сказать делаем сайты, а сами не имеем. Но теперь сапожник с сапогами, правда так как времени и усилий на собственный сайт как-то не сильно остается, пришлось сделать быстросайт на Zend Framework и бесплатном дизайн-макете. Вот он: digited.ru

Точка выхода

Я обратил внимание, что вся моя фрилансерская деятельность состоит из двух основных фаз, которые условно назвал как "плоская фаза" и "точка выхода". Плоская фаза - это довольно стабильный и наиболее продолжительный этап деятельности, когда основные проекты получены, работы распределены и потихоньку выполняются. При этом горизонты чисты и новые проекты не так велики, либо легко "перевариваемы". Но бывает такое состояние, когда с проектами начинаешь не справляться, и ко всему этому появляются новые большие и небольшие предложения. Другими словами, наступает кризис.
В обычной ситуации приходится увеличивать количество рабочих часов для себя и своих коллег и ко всему прочему полностью отказываться от новых проектов. Это помогает выровнять ситуацию, но убивает перспективу. Говоря другими словами, команда несёт альтернативные издержки, которые равны упущенным деньгам за "отказные" проекты плюс сумму от всех упущенных клиентов, которые потом могли бы прийти по "сарафанному радио". Как второй вариант - брать новые проекты и откладывать те старые, которые можно затянуть. Этот вариант, вероятно, наихудший, так как новые проекты могут не прижиться, а старые будт утеряны. Тогда убитой будет не только перспектива, но и текущие завоевания.
Наиболее правильным ходом будет расширение команды под новые проекты. Действительно, почему бы не взять ещё человека, чтобы он потянул на себе новые задачи? Таким образом, мы дадим работу ещё одному программисту и получим в свой актив новых клиентов. Но в реальности, конечно, не всё так просто.
Во-первых, закон, гласящий, что каждый новый человек, взятый в проект после его старта, является фактором ухудшающим общую ситуацию, никто не отменял. Пусть в нашем случае программиста берём на новые проекты, но всё равно человек потребует дополнительного внимания, дополнительных действий по его интеграции, как в коллектив, так и в рабочую инфраструктуру (svn, проектные системы, стандарты программирования...).
Во-вторых, новому человеку нужно платить деньги. Для этого должны быть либо финансовые резервы в размере как минимум одной-двух зарплат привлекаемого программиста либо равная им сумма предоплаты за проект. Т.е. мы должны быть готовы хотя бы к двум вещам: оплате труда нового программиста и выделению собственного времени на его интеграцию в рабочий процесс. Тут я уже и не говорю о рисках, ведь за нового человека невозможно ручаться, и нет гарантий, что он не завалит новые проекты, ведь вы не знаете ни его планов, ни его реальной мотивации.
Но в любом случае, «точка выхода» является возможностью выйти на новый уровень, увеличить команду и финансовые обороты. А уж как оседлать эту точку, я напишу гораздо позже, когда проведу пару экспериментов.

Офис в рюкзаке

Начался сезон плановых отключений горячей воды в городских квартирах и я с семьёй на несколько дней переехал в деревню, что в нескольких километрах от моего города. Двухэтажный домик, луга и река Ока в сотне метров - красота.  График я спланировал так, чтобы не выезжать в Москву и заниматься исключительно программированием иной компьютерной работой, а в перерывах, устраивать "рекреационные" прогулки по деревне, к реке и в сторону леса.
Купил для ноутбука скайлинковский мобильный модем, прихватил телефон и аллес - офис мигрировал со мной в рюкзаке. Почта и текущие проекты расположены в сети, по остальным данным ноутбук синхронизирован с компьютером, поэтому трудностей в отрыве от основного места работы никаких не испытываю. Занял комнатку на втором этаже дома (с видом на липы да яблони), накинул на стол покрывало, чтобы помягче локтям и ладоням было и начал работать.
Сегодня уже успел прогулятся вдоль деревни и насмотреться на змейки просёлочных дорог, вытоптанных в траве, поглазеть на мирных овец и эмоционально напряжённых гусей, пару раз пересечь быструю речку Желёму, которую можно перепрыгнуть с разбега, и успел покидать в неё камешки. Пока кидал камешки, думал как бы мне лучше осуществить вывод нескольких словарей таксономии в одном из проектов на Друпале, а так же подсчитывал, сколько запросить денег у клиента за постановку его сайта на техническое сопровождение и контент-менеджмент.
В следующий раз решил сходить посидеть в ивах на берегу Оки. Кррасота :)

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

Ложка мёда

+1. Поставить этот инкремент мне было нужно ещё, пожалуй в начале марта. Ещё один проект сдали, запустили, но продолжаем его активно развивать и выводить из стадии бета-версии.
Суть проекта проста - хотите подобрать для выступления артиста (танцора, певца, стрип-группу, факиров и т.п.) то просто заходите на сайт, выбирайте нужные жанры, города, суммы и вперёд - заказывайте звезду на свой корпоратив или другое мероприятие.
Основные особенности проекта - большая доля функционала зашита на работу с картинками, плюс присутствуют платёжные системы и биллинг, а так же равноправие показов анкет обеспечивается случайными выборками при поиске. В остальном, с технической точки зрения - обычный каталог.
Этот проект собирался на фоне относительно нестабильной финансовой ситуации в компании. Причиной стало то, что мы успели "подсесть" на одного основного заказчика и прекратили активно развивать работу по привлечению клиентов, отвлекаясь только на редкие небольшие проекты, которые приходили к нам сами. Соответственно, когда заказчик в течение месяца стал сворачивать свои инвестиции (точнее переливать их в бизнес немного с другим профилем), то быстро перестроиться и наладить поток проектов оказалось сложно. Как всегда бывает, проблемы не приходят по одной и на этом фоне в другом нашем "большом" проекте на пару недель по причине болезни "выключилась" из работы наш куратор от заказчика. Работ это конечно не остановило, но вот выплаты отсрочились на месяц, так как к расчётной дате некому было оценить количество работ и подать в бухгалтерию документ на оплату, что усугубило ситуацию в целом. Прошло уже более двух месяцев, а мы только начинаем пожинать плоды своих маркетинговых усилий, стартовавших в конце января. На восстановление равновесия уйдёт ещё не меньше месяца. Будет хорошим уроком.

Заказные услуги VS Коробочное ПО

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

• Временное отсутствие заказчиков, простой команды.
• Массовый наплыв заказчиков, потеря клиентов (в следствие невозможности получения услуг, они уходят к конкурентам) и потеря денег, которые не смогли заработать. Резко расширить команду на несколько человек и наладить их работу - не получится почти наверняка.
  
• Если приходят в основном заказчики с малым уровнем наукоёмкости проектов, то снижается возможность повышать иновационность свих решений и технологий, так как не остаётся времени на собственное развитие в свободное время.

Чтобы обеспечить успех своей независимой деятельности, я вижу только один рецепт: формирование команды разработчиков вокруг себя, получение средних и крупных заказов и выход на построение собственной компании.
Работать же с коробочным ПО можно двумя путями - разрабатывать некий продукт самостоятельно или заняться освоением и поставками продуктов третьих сторон. В изготовлении продукта самостоятельно я вижу в основном минусы с точки зрения фрилансера:

• Невозможность создать "большое" полноценное коммерческое приложение. На это уйдут годы, либо нужно очень хорошо вложиться в разработчиков-компаньонов и самому долгое время работать "за еду". Выход по сути только один - найти инвестора, который поверит вашим обещаниям :) либо продавать небольшое, но очень нужное рынку приложение, что сложно представить.
• Необходимость нанимать дополнительных специалистов по "непрофильным" моментам - дизайн, юзабилити, разработка клиентских интерфейсов, техническое писательство, маркетинг, продажи.
  
• Возможность появления на рынке "killer application" для вашего продукта. Если появится более мощная, надёжная и более дешёвая система - всё вылетит в трубу. Соответственно, необходимо постоянно вкладываться в хороший маркетинг.

Т.е. основная проблема здесь - это необходимость хорошенько "вложиться" в создаваемый продукт и быть готовым не получать дивидендов первое время, что для фрилансера очень сложно.
Теперь вот хочу исследовать возможность продавать/внедрять/сопровождать готовые продукты третьих сторон. Как исследую - обязательно напишу отчёт.

Пишем коммерческое предложение на разработку сайта

В своих предыдущих постах я уже наверное отмечал, что у заказчика зачастую бывает отличное видение бизнес-задачи, под которую создаётся сайт, но не всегда оказывается чёткое понимание того, каким сайт должен быть. В этом собственно ничего страшного нет, ведь знать всё о сайтах - это прежде всего наша работа. Фрилансеру приходится быть не только программистом, но и аналитиком, умеющим переварить специфику отрасли заказчика в ТЗ для написания конкретного кода.
Составлять полное ТЗ сразу тоже не всегда может оказаться возможным. Не далее чем вчера у меня состоялась встреча с потенциальным клиентом. Он мне говорит - вот мы занимаемся тем-то и тем-то, имеем возможность пополнять сайт тематическими статьями и фотоотчётами, а в результате нам нужно привлечь новых клиентов. Каков будет конечный функционал сайта - для заказчика было не так важно и он предлагал эту задачу решить мне - посмотреть сайты конкурентов и иные материалы, чтобы на основании этого сделать предложение.
Ещё парой недель ранее, другой мой заказчик, с которым мы уже работали, решил делать новую небольшую интра-систему. У них было понимание бизнес-задачи, а также набор экселевских файлов, которыми раньше обходились менеджеры. На основании интервью и анализа этих утилит передо мной встала задача написать коммерческое предложение с описанием функционала для реализации в виде веб-приложения.
Это я клоню к тому, что два документа - коммерческое предложение (КП) и ТЗ нужно чётко различать между собой. Они оба важны и практически всегда взаимо НЕ заменяемы. КП призвано продемонстрировать что и зачем мы будем делать, а в ТЗ уже будут подробности реализации.
Итак, когда я составляю КП оно состоит как минимум из двух основных частей:

1. Общая информация. Здесь нужно определить для чего делается сайт, какая у него планируется целевая аудитория и каким образом ресурс будет ей соответствовать. Описать основные принципы деятельности компании-заказчика, которые сайт должен реализовывать. Задача этого раздела состоит в том, чтобы показать заказчику, что вы правильно поняли его устремления и готовы их реализовать.
2. Описание функционала. Тут можно просто перечислить разделы сайта (или меню приложения, если это не сайт а прикладная система) с кратким описанием их представления, а также, с описанием их предназначения. Т.е. если мы предлагаем на сайте ввести фотогалерею, то нужно обосновать её необходимость исходя из целей работы сайта, определённых выше в "общей информации". К примеру, если компания продаёт услуги по организации дайв-туров, то фотоотчёты о ранее проведённых экспедициях помогут привлечь клиента красотой природы подводного мира и продемонстрировать возможности компании более ярко, чем только текстовая информация.

Конечно, если заказчику уже хорошо известно что он хочет видеть на сайте и как это должно быть реализовано, то КП теряет свой смысл, а часть описаний мигрирует в общие разделы ТЗ. Но если заказчик не до конца определился что и как, то КП станет незаменимым помощником и позволит избежать траты времени на написание технических подробностей функционала, который может быть ещё отменён.
Основные принципы КП на разработку сайта для меня таковы:

• Краткость. Задача КП не съесть мозг заказчика, а на одной-двух страницах рассказать, как вы собираетесь реализовать его мечту.
• Доступность понимания. Снова к вопросу о мозге. Важно понимать, что термины "домен", "хостинг", "объектный подход", "URL", "Аякс" и прочее - для заказчика могут оказаться тёмным лесом. И посетителей/пользователей сайта в КП лучше называть клиентами компании, а администраторов сайта - сотрудниками компании. Т.е. необходимо войти в роль заказчика и излагать предложение в его категориях мышления. Я говорил своему заказчику - "такая структура подачи информации будет лучше с точки зрения поисковой оптимизации" на что он мне ответил: "А что я буду от этого иметь?". Тогда пришлось переформулировать и сказать что-то вроде: "Больше потенциальных клиентов смогут найти ваш сайт, зайти на него и позвонить вашим менеджерам". Это он понял прекрасно.
• Базирование на пожеланиях заказчика. Всё, что будете писать в КП должно быть не результатом ваших личных измышлений, а плодом анализа пожеланий заказчика и существующих на рынке решений (сайтов конкурентов к примеру).
  
• Информативность. КП может стать не только "открыткой" заказчику, но и хорошей базой для написания ТЗ. Соответственно, нужно составлять КП так, чтобы потом ориентируясь на прописанные в нём принципы можно было легко начать писать ТЗ (а не придумывать его с нуля), ведь по сути, предложенная мной структура КП это и есть техническое задание, только в более общем выражении и терминологии заказчика.

Вот собственно и всё что я хотел написать в этот раз.