Названия и домены

Создание сайтов

Контакты

Последние комментарии

Страница с информацией о мастере


Изображение пользователя Макс К..
  


Рубрика:

Здесь обсуждаются предложения о том, как подать информацию о мастере

..........................
Макс Кириленко, подбор названий и доменов


Изображение пользователя Александр из Москвы.
  

Макс, если

Макс, если предполагается показывать какую-то информацию заказчику, надобно не просто фотомордочки, а реализованные проекты и сильные стороны расписать.

Примерно так: Пупа Васькин, в ПХП с 1917-го года, в Друпале с 1937-го. Основное направление деятельности: программирование, дизайн, копирайтинг... Проекты: ссылка раз, ссылка два... и море других.

Вы ж заказчиков охмурять собрались - так? Ну так и надо делать все правильно, чтобы было куда послать почитать про команду.

..........................
http://cwll.biz - Персональный блог на Друпале


Изображение пользователя Макс К..
  

Варианты персональной страницы

Проще всего перевалить это на самих мастеров, воспользовавшись штатными средствами Друпала.

Вариант 1. Самый простой.

Каждый создает сообщение в своем дневнике, в котором рассказывает о себе все, что считает нужным и дает всевозможные ссылки. В конце сообщения указывает короткий адрес, по которому он хочет видеть эту страницу, например, http://www.razgonka.ru/чтототам . Я назначу сообщению указанный короткий адрес.

Практически это будет персональная страница мастера на сайте Razgonka.ru. В будущем мастер самостоятельно поддерживает указанную страницу в актуальном состоянии.

Решение "зеленое".


Вариант 2. Посложнее

Сейчас на сайте Razgonka.ru стоит версия Друпала 5.1. Могу создать новый тип материала "about". На него повесить таксономию, где расписать все профессии, имеющие отношение к сайтостроению на базе Друпала. Со множественным выбором.

Каждый мастер один раз создает себе персональную страницу вида "about" и указывает те профессии, с которыми к нему можно обращаться за заказом.

В меню слева делается блок, где расписываются основные рубрики профессий:

  • установка сайта на Друпале
  • дизайн
  • программирование модулей
  • SEO
  • ...
Решение "зеленое".

Вариант 3, сложный.

Поставить модуль Bio, http://drupal.org/project/bio . Он позволяет встраивать информацию страницы Bio прямо в профиль.

Решение "желтое". Если создатели модуля когда-то прекратят его поддержку, придется вручную откатываться на предыдущее решение.


Есть какие-то мысли?

Нужно учитывать, что решение будет забито в Стандарт со всеми вытекающими последствиями.

..........................
Макс Кириленко, подбор названий и доменов


Изображение пользователя Александр из Москвы.
  

Про стандарт

Я так понимаю, стандарт формирует старший по команде. Потому как и я, и многие с "цветами" пока еще не очень.

Далее: не понятно, собственно, сколько народа планируется и как часто будет ротация. Соответственно от этого и плясать.

Есть еще одно решение: у всех тут есть что-то типа персонального сайта. Или возможность сделать страничку на каком-нибудь сайте, специально заточенную под информацию для потенциального клиента. Где он, не связанный стандартами и пр., может разместить что душе угодно. А тут только пара слов, и "подробности на личном сайте URL".

Плюс такого подхода: человек сам заморачивается поддержанием и актуализацией. Это решение мне больше нравится.

..........................
http://cwll.biz - Персональный блог на Друпале


Изображение пользователя Макс К..
  

Сводная страница с портретами маст

cwll says:
Я так понимаю, стандарт формирует старший по команде.

Нет, стандарт формируют долгосрочные интересы клиента. Любой накапливаемый на сайте материал должен легко выдерживать смену версий Друпала и смену API. Иначе клиент заплатит за возможность создания какого-то типа материала, 3 года будет набивать его, а на 4-ый год вдруг выяснится, что больше этот тип материала поддерживать невозможно.

Решения, в которых заложена "вечная" жизнь материалов считается зеленым. Использование возможностей ядра Друпала и встроенных модулей - зеленое решение.

Если судьба материалов зависит от какой-то одной персоны, которая сегодня есть а завтра нет, то это "красное" решение. Например, ставить сторонний модуль, создающий новый тип материала это "красное" решение. Или ставить дополнительный движок и самостоятельно интегрировать его в Друпал будет тоже красным решением. Следующий веб-мастер может просто не захотеть продолжать поддерживать такую интеграцию. Модуль CCK, который плодит новые типы как кролик, это несомненно красный модуль.

"Желтые" решения создают новые типы материалов, которые могут тоже исчезнуть из-за отсутствия поддержки каким-то человеком. Но, в отличие от "красных" решений, "желтые" решения допускают преобразования накопленного материала в какой-то стандартный вид ноды. Например, материалы созданные модулем ссылок в случае необходимости могут быть преобразованы в стандартный тип - страница, заметка, запись в дневнике,...

При выборе решений всегда нужно стараться найти "зеленые" решения. На крайний случай желтые.


cwll says:
Далее: не понятно, собственно, сколько народа планируется и как часто будет ротация.

Для старта достаточно несколько установщиков Друпала и хотя бы по одному дизайнеру и программисту модулей. Под такую команду уже можно сформулировать более-менее полноценное предложение для клиентов и начать закупать рекламу, продвигать команду, меняться ссылками.

Сколько будет народа в будущем я не знаю. Но ожидаю, что много. Сейчас народ присматривается, выльется ли из проекта "команда Razgonka.ru" что-то интересное или нет. Когда команда сделает свои первые первые публичные заказы, там пойдет следующая волна мастеров.

Ротация неизбежна. Отсев мастера может произойти 3 причинам:

  • мнение самих мастеров, которые успели поработать с данным мастером
  • мнение клиентов, недовольных работой мастера
  • ремесленничество мастера, когда он хорошо делает заказы, но в работе команды не участвует

cwll says:
"Есть еще одно решение: у всех тут есть что-то типа персонального сайта."

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

Вся информация, необходимая для выбора мастера, должна быть сосредоточена на сайте команды.

cwll says:
"Или возможность сделать страничку на каком-нибудь сайте, специально заточенную под информацию для потенциального клиента. Где он, не связанный стандартами и пр., может разместить что душе угодно. А тут только пара слов, и "подробности на личном сайте URL".

Плюс такого подхода: человек сам заморачивается поддержанием и актуализацией. Это решение мне больше нравится."

Ты смотришь на это с точки зрения мастера. Указать ссылку на свой сайт проще всего.

Для клиента же все наоборот. Клиенту не хочется бродить по десяткам разных сайтов и выбирать мастера. Личные сайты мастеров устроены по разному, и искать нужную информацию часто бывает затруднительно.

Клиенту проще иметь дело с мастерами, когда они все свои предложения сконцентрировали на одном сайте. На одном сайте проще поддерживать общий формат представления информации о мастере. Для этого можно, например, использовать стандартный модуль Друпала "профиль" или дать всем мастерам список вопросов, которые они должны отразить на своей персональной странице на сайте команды.

В идеале для клиента вообще не должен стоять вопрос выбора мастера. Пришел, опубликовал свой заказ и свой бюджет. Мастера сами между собой решили, какая пара будет делать заказ и будет ли делать его вообще. Многие заказы могут потребовать совместных усилий от нескольких мастеров.

Каждый лишний выбор, которым мы нагружаем клиента, увеличивает риск, что он уйдет с сайта и не вернется.

Промежуточное решение

Пока мастеров не очень много, будем вручную поддерживать сводную страницу, на которой разместим портреты мастеров и их краткие резюме вместе с ссылками на их персональные страницы, расположенные на сайте Razgonka.ru.

..........................
Макс Кириленко, подбор названий и доменов


Изображение пользователя Александр из Москвы.
  

Я так понимаю:

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

Подготовительная работа проделана, народ набран. Основные принципы определены. Есть программисты, есть кто может дизайнить и есть кто умеет контент писать. Дело за малым: нет клиентов. Я бы на этом сейчас сосредоточился.



Если я буду вести в команде свой проект, то делать я хотел бы примерно так:

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

Работы я бы не начинал без предоплаты: сие дисциплинирует.

Менеджер забирает, допустим, 20-25%, дизайнер, предположим, 10-15%, программер 35-40%, а 25-30% идут в фонд развития: на раскрутку, в случае возможных непредвиденных трат и пр.

Просто и логично, на мой взгляд. Можно ввести сущность "консультанта" - человек, который расписывает в общих чертах наиболее "кошерный" путь решения задачи с точки зрения дальшейшей поддержки, апгрейда и пр.. Типа модули такие-то, хаки такие-то... И, как я сказал, все в единую БД: кто, что, когда, зачем... Таким образом создасться база решений, По кр. мере в своих проектах я так буду делать обязательно, если у команды нет возражений. В итоге сайты пекутся как пирожки и все в шоколаде, при условии достаточного количества заказчиков.

..........................
http://cwll.biz - Персональный блог на Друпале


Изображение пользователя Макс К..
  

Инкубаторы

Приятно читать твои предложения. Чувствуется, что тебе заказы нужны. Улыбка

Вариантов построения команды может быть много. Они будут сменять друг друга. Жизнь сама подскажет когда старый вариант становится тесным и пора переходить на новый.


На начальном этапе, мне представляется, не стоит строить жесткую административную структуру. Каждая структура требует сил для своей поддержки. Если роли в структуре распределены неправильно, то структура будет тормозить.

Друпал это язык сверхвысокого уровня. Он достаточно мощный, чтобы один мастер-друпальщик мог вести проект на Друпале от начала до конца. Если мастеру потребуется помощь специалистов (дизайнера, программиста или переводчика модулей,...) он всегда сможет обратиться за помощью к нужным специалистам из команды.

Попозже, когда на каждого мастера придется по несколько сделанных публично заказов, будет видно, кто из них силен в общении с клиентом, а кому нравится больше заниматься установкой. Тогда можно будет подумать о каких-то структурах подобных описанных Вами (менеджер для общения с клиентом и исполнители не видящие клиента).

Работа с клиентом

Но твой подход правильный, спорить с этим сложно. В банках работают именно так. Vip-клиенту дают персонального менеджера, который только из работников банка и имеет дело с клиентом. Но сейчас мы не знаем друг друга и предлагаю некоторое время поработать самостоятельно.

Когда в 2008 будем выходить на импортный рынок, там уже можно и нужно будет работать с клиентами как единая команда. Подозреваю, что не все члены русской команды смогут работать на импортном рынке, многие так и останутся работать только на русскоязычном рынке.

Сайт Razgonka.ru будет выращивать будущих мастеров и оценивать их на пригодность для работы на импортном рынке.

Очень примерная схема

Работа на импортном рынке радикально отличается от работы с русскими клиентами. На русском рынке клиенты дают мало денег за работу, поэтому вынуждены терпеть низкий уровень исполнителей, полностью соответствующий предложенным деньгам.

На импортном рынке деньги другие, но и конкуренция другая. Возможно, подготовка мастеров для импортного рынка будет вестись примерно по такой схеме:

  • Drupal.ru - занимается подготовкой учеников-друпальщиков
  • Razgonka.ru обкатывает подмастерьев на русских клиентах
  • ???.com - место работы мастеров

..........................
Макс Кириленко, подбор названий и доменов


Изображение пользователя Александр из Москвы.
  

Приятно что приятно :)

Заказы нужны - кто бы спорил. :)

Еще момент: меня есть опыт именно организации командной работы. Там в итоге это не пошло, но наработки и идеи остались. Да и самого меня тема тогда заинтересовала.

Выход на внешний рынок: а не надо всем знать буржуинский на хорошем уровне. Менеджер проекта знает, за что и получает %. А еще лучше переводчик.

Если роли в структуре распределены неправильно, то структура будет тормозить. Конечно. Но взлянем на это с другой стороны: каждый, кто делал проект так или иначе выступал во всех ролях. Но к чему-то лежит душа, а от чего-то воротит. Личный пример: да, я могу и дизайн и все остальное, но не нравится мне это. Биться с глюками CSS на разных броузерах... :( Вот в php все понятно и очевидно.

 

Если мастеру потребуется помощь специалистов - неправильный это подход изначально. Разделение труда, чтобы всем было и удобнее и денежнее и сделать можно и нужно. Я бы советовал сразу начинать работать правильно. Если кто-то больше программер, а кто-то больше дизайнер, то в сумме они смогут сделать не в 2, а во много раз больше. Во сколько возрасла производительность при разделении труда в производстве английской булавки? В 480 раз.

Тогда можно будет подумать о каких-то структурах - нет ничего более постоянного, чем временные решения.

Сайт Razgonka.ru будет выращивать будущих мастеров и оценивать их на пригодность для работы на импортном рынке. - Макс, если вы лично заинтересованы - выращивайте кого хотите. Проводите мастер-классы, делайте анкеты и поддерживайте некоммерческие проекты... Лично я заинтересован в стабильных заказах. И готов платить % от заработка, готов писать по принятым правилам и еще много чего делать готов. Только вот не надо все в одну кучу. Мы не цивилизацию спасаем, а на жизнь зарабатываем. Грубовато, наверное, звучит, но ведь это правда.

Работа на импортном рынке радикально отличается от работы с русскими клиентами Угу. Но программирование что для Зимбабве, что для Нигерии одинаковое. Отсюда вполне логичный вывод: г-да АBCD занимаются программизмом и дизайном, г-н Е занимается клиентами на внешнем рынке. Де-факто г-н Е - субподрядчик. Поэтому работать надо по предложенной мной схеме. И даже не подлежит обсуждению, что любая работа должна быть оплачена.

Да, нам мешает факт, что мы не знаем друг-друга. Поэтому я бы предложил прогнать некоторое количество проектов, разобраться "кто есть ху", отсеить раздолбаев и динамщиков и работать по нормальному. В принципе можно начинать работать сразу на проектах без жестких сроков.

Повторюсь, но момент важный: если некоторое количество проектов будет у меня, и я буду знать, что это не последние, то работать я буду именно по своей схеме. Если же новых придется проектов ждать неделями, то конечно я буду все делать сам. Да и любой на моем месте, если не идиот. :)

То есть вопрос в концепции. Не "если не сможешь, то проси помощи клуба", а "если есть желания трахаться с ХХХ - трахайся сам, но лучше все же поручи это специализирующимся на ХХХ людям".

Блин, опять многа букаффф ...

..........................
http://cwll.biz - Персональный блог на Друпале