понедельник, 17 марта 2008 г.

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

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

среда, 6 февраля 2008 г.

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

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

среда, 30 января 2008 г.

Мои "Нет"

На сайте журнала PHP Inside недавно опубликовал перевод заметки "10 нет для фрилансера". Я не со всем согласен, но в целом считаю, что автор вполне удачно рассмотрел проблему. Хоть и не с российской спецификой. Вот и я решил составить свои "Нет" и "Вынужден".
Итак, НЕТ:
  • Не буду заниматься вёрсткой. Максимум - проставить классы элементам или подготовить вёрстку для работы с движком (разбить на подшаблоны, проставить синтаксис если задействован шаблонизатор). Иначе очень много времени съедят требования "подвинуть столбик".
  • Не браться за низкооплачиваемые проекты. Только если там и правда три минуты программинга. Иначе, заказчик хоть и платит мало, но всегда требует по полной! Причём, замечено, если заказчик платит хорошо, то он обычно может входить в положение и искать компромиссы при возникающих трудностях, лишь бы не утопить проект, а заказчик платящий мало - пытается получить всё прямо здесь и сейчас и если что случись, ему легче не попытаться решить вопрос, а просто начать сваливать вину на исполнителя. Поэтому с такими заказчиками дело иметь не хочется. Моя позиция такова - у меня и заказчика есть общая цель, к которой нужно прийти.
  • Не браться за работу для своих знакомых. Заказчик по своей сути это всё же антогонист, хотя и в разумных пределах. Где-то приходится требовать доплат, или правок исходных материалов, или бодаться по тому или иному вопросу (хоть и конструктивно, но противостоять). Из знакомых сложнее выбивать средства и время, что приводит к неэффективности работы. Либо нужно быть цинником. Либо американцем.
  • Не встревать в прожекты. Если у кого-то есть мысль, пусть он её и реализует. Или платит за её реализацию. Иначе можно просто потерять время и в итоге деньги, причём с вероятностью 99.9999%.
  • Если встречаешься с заказчиком и он выплачивает все деньги за проект/этап, под твоё обещание что оставшиеся "мелочи" будут доделаны в ближайшее время, то можно ожидать двух проблем как минимум: "мелочи" могут оказаться серьёзной работой (не всегда можно точно спрогнозировать) или заказчик будет оперировать утверждением "я же заплатил деньги" и начнёт приписывать дополнительный функционал, якобы "ну это же подразумевалось" или "это тут должно быть по всей логике вещей, это же очевидно". И тут придётся конфликтовать. Либо выполнять все условия. В любом случае, в такой ситуации - вы должник и должны доказывать что брали деньги не за такой объём.
Основная мысль всего этого - лучше я откажусь от проекта, чем получу большой геморрой и трату времени.
Теперь о том, на что я вынужденно ещё могу пойти:
  • "Скопируйте мне вон тот сайт". Автор приведённой выше заметки говорит, что исполнителей в таких проектах не ценят и они превращаются в тупо копирующих обезъян. Тут я не согласен, ведь копируется только функционал, но не технологические решения. Здесь уже можно развернуться. Конечно, хочется участвовать в оригинальных проектах, но это пока не критично для меня.
  • Браться за хостинг. Опять же, автор упомянутой заметки отсылает заказчиков к хостеру. Если я отошлю заказчика к хостеру, то заказчик в 90% случаев или заблудится или уйдёт безвозвратно. Бывает и так - "поправьте нам сайт, только мы не знаем где он хостится и потеряли данные по доступу к управлению доменом". Важно решать этот вопрос финансово - брать деньги за техподдержку, иначе предупреждать заказчика, что за почту и доступность сервера я не отвечаю и не в курсе чего там и как.
  • Вынужден встречаться лично. У нас не принято платить деньги виртуальному персонажу, если конечно сумма превышает энную. Ситуация уже исправляется, но в основном полностью "онлайновые" отношения пока допустимы только между айтишниками. Например когда я плачу дизайнеру за макет к заказанному мне сайту, то не еду в Новосибирск или Ростов. Но с клиентами вынужденно встречаюсь хотя бы один раз лично. В Москве.
Вот такие получились списки.

понедельник, 28 января 2008 г.

Zavet

Есть такой хороший режиссёр Эмир Кустурица. Хоть убей - близки мне его фильмы, в том числе и последний шедевр "Завет" образца 2007 года. Не буду делиться общими впечатлениями о произведении - тематика блога не та, но скажу только об одной фразе, которая близка мне как фрилансеру. Водитель бандитов, во время одной из поездок задушевно так говорит - "Да, мне нужны деньги и я готов делать любую работу, только не заставляйте меня трахаться с кабаном". Вот-вот господа. Будьте добры...

пятница, 25 января 2008 г.

Полезен ли программер стране?

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

суббота, 19 января 2008 г.

Ура сдал проект!

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

среда, 2 января 2008 г.

Программирование себя

Новогодние праздники - отличное время для программирования себя. В жизни очень важно иметь чёткие цели, чтобы знать куда идти и как оценивать свою успешность. Важно составить себе список целей - программу, которая выполнится успешно или, в итоге, вылетит с матерным эксепшеном. Проблема заключается в том, чтобы не поставить себе чересчур высокую планку, которую заведомо не взять (а значит быть неуспешным), но и не занизить свои возможности (тогда успех будет мнимым, а упущенные возможности невосполнимыми).
Вот я и попробую публично потренироваться в деле самопрограммирования. Итак, что я хотел бы видеть свершённым в конце нового 2008 года:
1. Отношения со всеми текущими заказчиками по крайней мере не будут хуже, а только улучшатся. Каждый текущий заказчик будет рекомендовать меня своим знакомым и коллегам.
2. Моё юридическое лицо (ООО) получило бы существенно более обильные (как минимум х10) и регулярные финансовые поступления. Буду стараться.
3. Будет официально создан и запущен в эксплуатацию мой ресурс, посвящённый туристической тематике в стиле веб 2.5. Под него было бы хорошо найти инвестора, так как собственных затрат времени и финансов боюсь может не хватить для полноценного старта.
4. Мой англоязычный блог (да, я начал делать это) попадёт в рсс-каналы phpdeveloper и planetphp.
5. Я запущу в эксплуатацию не менее 15 проектов. Проектом буду считать одно обращение заказчика по созданию веб-сайта или любой другой веб-системы. Создание одного сайта и пары сопутствующих для его информационно-тематической поддержки - считать за один проект.
6. Как минимум 6 раз выйдет PHP Inside и я наконец засяду за написание своей второй книги о РНР, на этот раз с более узкой тематикой (уже есть план по главам!).
Думаю, это программа-минимум. Если у кого-то будет желание совместить выполнение своих профессиональных целей с моими - мой email: nw AT phpinside DOT ru.