Новогодний пост

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

Итак прошлые планы: 

•  Отношения со всеми текущими заказчиками по крайней мере не будут хуже, а только улучшатся. Каждый текущий заказчик будет рекомендовать меня своим знакомым и коллегам. Из тех заказчиков по разным причинам осталось около половины.
• Моё юридическое лицо (ООО) получило бы существенно более обильные (как минимум х10) и регулярные финансовые поступления. Улучшения незначительны.
• Будет официально создан и запущен в эксплуатацию мой ресурс, посвящённый туристической тематике в стиле веб 2.5. Не случилось. Не нашлось денег и появился уже действующий конкурент.
• Мой англоязычный блог (да, я начал делать это) попадёт в рсс-каналы phpdeveloper и planetphp. Так и не запустил я его толком.
• Я запущу в эксплуатацию не менее 15 проектов. Это похоже на реальность.
• Как минимум 6 раз выйдет PHP Inside и я наконец засяду за написание своей второй книги о РНР. Это вобще из разряда фантастики. Совсем не продвинулся.

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

Теперь о конкретных планах на 2009:

• Выйти на схему команды: 1 программист на фулл-тайм (удалённо, как и все - это концепция такая), и 2 программиста на полставки (чтобы могли вести несколько проектов одновременно, пусть и не так быстро как на полный рабочий день), + дизайнер на сдельной работе.
• Запустить (или хотя бы попытаться дойти до момента поиска инвесторов с альфа-версией) свой стартап совместно с партнёром. Работа уже начата.
• Стабилизировать рабочий процесс - освоить 2-3 CMS (сейчас пока на одной), улучшить компетенцию по фреймворку Kohana. Создать по всему этому делу базу знаний, определиться наконец с системой ведения проектов и SVN-хостингом (в прошлом году это уже было - но скакали от одного к другому).
• Реализовать опять же не менее 15 проектов, но уже более качественно и за большие деньги. 

Думаю этого хватит. В любом случае - ориентиры меняются как минимум раз в квартал.

Экспресс-курс изучения ряда CMS

За несколько дней до новогодних праздников (кстати с прошедшими!)  попалась мне задачка - написать один несложный модуль по импорту и выводу данных в формате XML.  Интересность задачи состояла в том, что модуль этот, должен быть реализован для нескольких популярных CMS - т.е. одна бизнес логика, но в нескольких обёртках. К тому времени, из популярных, я работал только с Drupal, поэтому пришлось быстрыми темпами изучать модулестроение в некоторых других системах.

На текущий момент уже сделаны компоненты к Drupal, Joomlа, WordPress и DLE.  Казалось бы - от них нужно одно, но так по разному получилось :)  В частности, к Drupal и Joomla вопросов нет - документированы, система модулей отработана и сложностей не возникло. У Вордпресса тоже хорошая расширяемость и документация, но она вертится прежде всего вокруг публикаций как таковых. Когда брался за DLE, мне казалось, что она является довольно популярной на отечественных просторах  системой (так оно в принципе и есть), но с удивлением обнаружил, что модули устанавливаются не через админку, а прописываются строчкой в РНР-коде.

Зато, раньше я не брался за выполнение заказов на WordPress, а тут заглянул внутрь, более-менее разобрался и как раз под руку подвернулся мини-проект по этой CMS. Раньше - отказался бы, а тут вот ещё немного заработал. Резюме: технологии нужно знать шире, ибо заказчик, зачастую, ещё до контакта с исполнителем выбирает себе систему под проект (иногда это просто "слышал про неё", а иногда действительно по веским причинам). Пойду изучать подробнее WordPress и Jooml'у.

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

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

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

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

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

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

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

Я се десант.

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

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

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

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

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

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

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

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

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

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