Приниматель решений

Будучи фрилансером, да ещё работающим в команде, мне приходится не только писать код (код это лишь часть работы). Мне приходится делать ещё очень много вещей, но все они сводятся практически к одному: принимать решения.

Этот пост не будет освещать какие либо методики или философские подходы. Я просто приведу перечень типов решений, над которыми пришлось в последнее время подумать. Некоторые из решений давались легко, некоторые сложно. Считайте этот пост моим желанием посетовать на нелёгкую судьбу фрилансера, пока не ставшего руководителем чистой воды. Итак:

• С помощью какой технологии реализовать приложение? CMS, фреймворк, CMF и какие из них? На чём будет проще создать? а развивать? а придётся ли развивать? а не уйдёт ли заказчик посчитав что медленно стартанули при этом не задумавшись, что основа закладывается именно сейчас? а не завязнем ли мы потом в полной переделке готовой CMS, хоть старт и был быстрым за счёт использования этой CMS?
• Как распределить задачи среди ребят из команды? У каждого есть свои особенности, это понятно, но дело усложняется тем, что сотрудники бывают итак нагруженными и им сейчас нельзя поручить работу, пусть в ней они наиболее компетентны чем другие.
• Каким задачам/проектам отдать приоритет в данной ситуации?  Ведь ситуации не всегда линейны чтобы подошёл ответ "самым денежным и долгоиграющим". Проект может быть большим, с солидными оплатами за этап работ, но деньги нужны прямо сейчас! Рисковать и откладывать большой проект в угоду разовым "визиткам", но за которые платят уже после обеда? Или наброситься всеми силами на большой этап чтобы получить за него деньги? А если не успеем в срок, в который нужны деньги? В качестве расплаты может быть на выбор: банковский штраф за просрочку кредита, снижение лояльности сотрудника за задержку зарплаты или что угодно ещё.  Но ведь и проблема может быть другой: скажем двум заказчикам понадобились работающие версии их проектов не в пятницу, как договаривались, а раньше - в среду (у одного перенесли презентацию проекта внутри его холдинга, а другой срочно в четверг улетает в Ханты-Мансийск). Обоим одновременно! Сделать обоим хорошо не выйдет, значит что выбирать - кому-то всё, а другому ничего? Или всем пополовинке? Или искать способ сделать всё всем? Или всех послать? Но ведь оба - надёжные заказчики...
• На что потратить своё рабочее время? Вариантов много: программировать в проекте А (потому что горит!), программировать в проекте Б (если сейчас не сделать - завтра будет гореть!), назначить встречу партнёру по стартапу для прояснения ближайших совместных действий (иначе потратим силы не в ту сторону), заняться размещением рекламы в СМИ и мониторингу фрилансовых бирж с рассылкой коммерческих предложений (а то текущие работы кончатся, а заказов-то новых ещё нет!),  проверить выполненные сотрудниками работы (как же рапортовать заказчику не посмотрев?), подумать над тем как оптимизировать рабочие процессы (до этого никогда руки не доходят, но ведь теряем время из-за непродуманности) и так далее и тому подобное.

И это только то, что я вспомнил сейчас. Конечно крупным планом. Сюда я не включил решения, которые приходится принимать именно как программисту касательно кода. Но ведь что самое сложное во всём этом деле - жизнь не всегда говорит какие есть варианты! Как говаривал Ф.М. Достоевский (цитирую по памяти): "дважды два не всегда равно четырём, иногда равно пяти, а порой и стеориновой свечке". 

P.S. Небольшая иллюстрация к тексту выше. Я, как сообщал в предыдущем сообщении, должен был поехать на Веборуб. Давно планировал, регистрировался, списывался с коллегами etc. Но в пятницу вечером (а само мероприятие наутро в субботу) сложилась такая ситуация - в понедельник нужно сдавать проект, а мы подзастряли. Если я уеду (это как минимум суббота, а может ещё и часть воскресенья), то к понедельнику работу мы не сделаем.  Веборуб - очень важное мероприятие. Проект тоже важен и не факт что мы его не успели бы, поедь я на Веборуб. Но риск был. И я не поехал.

Веборуб осенний десант 2008

Я се десант.

Завтра с утра еду на вторую неконференцию Веборуб 2008 "Осенний десант". Состоится оная в Бекасово на ЮЗ МО. При необходимости, планирую выступить с небольшим докладом по моему опыту управления территориально распределённой командой программистов, а в качестве груза знаний хочется увезти информацию по выживанию в стартапах (есть на уме кой чего) и, возможно, подыскать для своей команды дополнительных интересных проектов.

Главная цель, конечно - пообщаться с давно знакомыми коллегами. Давно что-то я не видел Кузьму Феськова, RVK, Дена, kdk и Сашу Смирнова (на самом деле список людей кого хочется снова увидеть - более широк). 

Единственная проблема, еду я общественным транспортом из Коломны (ЮВ МО) и путь мой составит добрых полтыщи километров в сутки если считать туда-обратно. Хотя там будут участники из дальших далей нежели я, но они с ночёвкой. А я нет. По возвращению отпишусь.

Грабли. Рецидив

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

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

Идёт гудёт зелёный шум

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

Лекция по конфликтологии

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

Записывайтесь в армию США чтобы посмотреть мир

Конечно же, я не призываю вас к сабжу. Просто мои путешествия в роли фрилансера не хочу оставить незамеченными. У некоторых фрилансеров, правда, масштабы куда серьёзнее в плане географической привязки клиентов и встреч, но моё начало мне тоже нравится.
Поводом к написанию данной заметки стала моя сегодняшняя поездка в Раменское, что в часе от Москвы по юго-восточному направлению. Местное печатное издание решило стать моим клиентом и, несколько недель спустя, я ездил сдавать проект с полной демонстрацией в стиле коммивояжеров, продающих "чудо-устройства". Надо признать, модификация и настройка Drupal удалась. Вот пара фотографий города.

Провинциальный программинг

Начну с того, что под словом "провинциальный" в данной заметке я понимаю "региональный" или "в городе не центральном в своём регионе". Ни в коем разе не "плохой" или "примитивный". Это вступление. А в качестве самой истории я расскажу об опыте продвижения своих услуг в одном из городов Подмосковья. 
Так как я живу в области, то для встреч с клиентами мне приходится ездить в Москву. Это не то что бы очень долго, но дорога отнимает драгоценное время и, конечно, силы.  В нашем городе (150-200 тысяч человек) в начале двухтысячных годов была ситуация, когда спроса на разработку сайтов не было практически совсем, либо он был только не очень-то уж платёжеспособный. За последние несколько лет ситуация стала меняться и я решил провести разведку боем. Моей задачей было определение спроса на местном рынке, выявление конкурентной среды и попытка нахождения клиентов, хотя бы чуть-чуть для закрепления позиций.
Что я предпринял. Прежде всего разместил рекламу в одном из местных таблоидов (газета исключительно с рекламой), который распространяется среди юридических лиц по большей части. Газеты "для людей" пока решил не использовать - бюджет не хотелось раздувать для первого раза. Затем, купил немного слов в Яндекс.Директ, где упоминал название моего города и тип оказываемых услуг. Следующий шаг - сделал прямую рассылку по предприятиям города (не путать со спамом, каждому писал лично).
Прошёл месяц. Расходы я свои окупил, клиенты нашлись и, надеюсь, будут приходить и дальше. НО. Людей отреагировавших на рекламу было совсем не столько, сколько я ожидал. Говорю не про клиентов, а именно про тех кто хотя бы отреагировал. При этом, звонили так же и окружающие города.  И вот какие выводы я сделал.
1. Заказчик не всегда старается заказать работу у себя в городе, особенно если рядом есть более крупный центр. Так, люди из соседних небольших городов звонили к нам в город, а наши, по большей части, предпочитают заказывать сайты в Москве. Уж не знаю что их мотивирует, но могу предположить два момента: прежде всего это налаженные контакты с Москвой (многие работали когда-то в МСК или имеют там коллег, друзей...), а так же, вероятно, ощущение того что провинциальные компании оказывают услуги на провинциальном же уровне, но только здесь слово "провинциальный" имеет как раз негативный оттенок. Особенно это характерно для крупных местных компаний - они все делали себе сайты в Москве, либо собираются работать только с ней.
2. Реклама "частичная" даст частичный же результат. В условиях, что газетау нас не одна, а в городе их как минимум 5-10, то получается, что накрываем не всех.
3. Конечно, нам нужно поправить собственный сайт. Он сделан на скорую руку. Мы фиксировали крохотное повышение посещаемости (прямые переходы и с яндекса), но с сайта не пришло ни одного местного клиента за всю кампанию. Все находили нас через газету или откликались на прямые письма.
Т.е. в итоге получается, что те, для кого наш город является центром притяжения - идут к нам, а для нашего города центр притяжения - Москва. Вот и идут туда. Кстати, с год назад был интересный момент, когда я через московского заказчика вышел на предприятие в своём городе. Руководитель предприятия имел знакомого бизнесмена в Москве и сначала обратился к его опыту, а не стал искать местных исполнителей.

Кадровый вопрос

Примерно год я работал совместно с коллегой-программистом, но к этому времени он закончил институт и решил искать фуллтайм в столице. Он работал фактически полный рабочий день (хоть и удалённо), поэтому вопрос его замены встал очень остро - мне было бы сложно тянуть дополнительно те проекты, которые теперь стремительно сваливались на меня (эффективность решившего уволиться сотрудника обычно резко падает). Дизайнер и верстальщик у нас сдельщики, поэтому с ними было бы проще, а тут - 40 часов в неделю прибавилось к моему итак нагруженному графику.
Уходящий сотрудник предупредил меня относительно заблаговременно, поэтому я для начала дал объявления только среди коллег - на форумах PHPClub и php.com.ua. Зарплату мы в компании особо заоблачную не платим, но предлагаем свободный график и удалёнку (главное - результат), поэтому я пока не знал - насколько быстро сможем найти специалиста и какой уровень у него будет.  На приятное удивление, я получил с десяток резюме и несколько "стуков" в аську от знакомых. Уровень соискателей варьировался от откровенно новичков до вполне сильных программистов. 
В итоге, мы сделали выбор и вот сегодня закончилась первая рабочая неделя нового человека. Я вполне доволен нашим сотрудничеством, хотя это только начало и на больших нагрузках, авралах, срочных работах он пока не проверен.

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

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

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

Мои "Нет"

На сайте журнала PHP Inside недавно опубликовал перевод заметки "10 нет для фрилансера". Я не со всем согласен, но в целом считаю, что автор вполне удачно рассмотрел проблему. Хоть и не с российской спецификой. Вот и я решил составить свои "Нет" и "Вынужден".
Итак, НЕТ:

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

Основная мысль всего этого - лучше я откажусь от проекта, чем получу большой геморрой и трату времени.
Теперь о том, на что я вынужденно ещё могу пойти:

• "Скопируйте мне вон тот сайт". Автор приведённой выше заметки говорит, что исполнителей в таких проектах не ценят и они превращаются в тупо копирующих обезъян. Тут я не согласен, ведь копируется только функционал, но не технологические решения. Здесь уже можно развернуться. Конечно, хочется участвовать в оригинальных проектах, но это пока не критично для меня.
• Браться за хостинг. Опять же, автор упомянутой заметки отсылает заказчиков к хостеру. Если я отошлю заказчика к хостеру, то заказчик в 90% случаев или заблудится или уйдёт безвозвратно. Бывает и так - "поправьте нам сайт, только мы не знаем где он хостится и потеряли данные по доступу к управлению доменом". Важно решать этот вопрос финансово - брать деньги за техподдержку, иначе предупреждать заказчика, что за почту и доступность сервера я не отвечаю и не в курсе чего там и как.
  
• Вынужден встречаться лично. У нас не принято платить деньги виртуальному персонажу, если конечно сумма превышает энную. Ситуация уже исправляется, но в основном полностью "онлайновые" отношения пока допустимы только между айтишниками. Например когда я плачу дизайнеру за макет к заказанному мне сайту, то не еду в Новосибирск или Ростов. Но с клиентами вынужденно встречаюсь хотя бы один раз лично. В Москве.

Вот такие получились списки.

Zavet

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

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

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

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

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

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

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

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

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