• Как коронакризис повлиял на фрилансеров
    0

    Не, не кажется. Даже ущипнул себя для верности.


    У меня за последние даже не полгода, а год (не менял часовую ставку в этот период), поступления на счёт стабильные ± 10-15%.


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


    Я вообще не понимаю, причём тут постоянный доход, почему он закладывается в определение фрилансера. Вот мой друг работает менеджером по продажам по найму. Сколько продал, столько получил. Другой работает в отделении банка. Там премии за выполнение плана, и они мало зависят от друга. Он без премии имеет 30 000 рублей, а с премией 60 000. И это через раз. А подруга работает в конторе с гибкой системой штрафов и бонусов и, с окладом 20 000, может получить на руки от 10 000 до 40 000. И что? Они всё работают по найму.

  • Как коронакризис повлиял на фрилансеров
    0
    Возможно.

    У хороших фрилансеров он постоянный, то есть постоянно поступающий плюс-минус 20%, просто выражен не в конкретной сумме и выплачивается не два раза в месяц. Я лично считаю свой доход постоянным. Знакомые «стабильные» фрилансеры тоже.

    Честно? Никогда не думал, что подушка нужна. Она просто есть.
  • Анализ методики проектирования: ошибки, ситуации и полезные выводы из них
    0
    К пунктам методики обследования


    Это не пункты методики :) Если хотите побольше узнать про методику, рекомендую ссылку в конце статьи.

    Т.е. когда предполагается четкое разделение функций и полномочий «заказчик»-«исполнитель» и исполнитель только спрашивает — чего же хочет заказчик.


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

    Про разделение ответственности — это да, это вы верно подметили. Проектировщик сайта не может и не должен определять ключевые моменты в бизнесе и маркетинге клиента. Это делают другие специалисты, которым клиент заказывает бизнес-концепцию и маркетинговую политику. Но это совсем другой продукт и совсем другие методики. Об этом здесь речи и близко нет и не будет. Про «возложите ответственность» — это, скорее, про мотивацию. Мы всё равно достаём значительную часть информации из других источников.

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


    Статья не про бизнес-консалтинг, а про методику проектирования сайтов и других интерактивных продуктов. Бизнес-консалтинг — это отдельная вещь, рекомендую её сюда не примешивать. Это всё равно, что прийти в обсуждение статьи про java-скрипты и написать: «Писать java-скрипты — это надо проходить за первый год, а вот проектирование архитектуры системы — это дааа, новый уровень понимания, творческий полёт, другая энергетика.»
  • Анализ методики проектирования: ошибки, ситуации и полезные выводы из них
    +1
    Извините, либо утро ещё, либо я не догадлив. Вы не могли бы пояснить (не знаю вашего имени), к чему относится ваш комментарий, а особенно его первая часть до пунктов (4 абзаца)?
  • Анализ методики проектирования: ошибки, ситуации и полезные выводы из них
    0
    Тут случай другой :) Зависит от интенсивности проекта тогда. Если брать вялотекущие проекты, то можно и больше двух без потери качества делать.
  • Анализ методики проектирования: ошибки, ситуации и полезные выводы из них
    0
    Я имел в виду не количество заказов для студии в целом, а в расчёте на одного проектировщика.
  • Usability чеклист
    0
    Хороший пост в правильном направлении. Я тоже думал написать такой. Единственное, что у меня вызывает серьёзное возражение — это поиск. На мой взгляд, на многих сайтах, особенно корпоративных, наличие поиска — это признание поражения навигации.
  • Анализ методики проектирования: ошибки, ситуации и полезные выводы из них
    0
    А не за что. Хорошо, когда находишь подтверждение своего опыта у других.
  • Полное видео-руководство о сборе информации для проектирования
    0
    Выстрадан — это правильное слово.
  • Полное видео-руководство о сборе информации для проектирования
    0
    Спасибо, старался именно на примерах, а не на теории, сделать акцент.
  • Сравнение подходов к созданию сайта: проектирование, бриф и agile
    0
    Да, речь именно о ключевых моментах. Если момент ключевой, то его разрешения надо ждать при любом подходе, иначе может случиться фейл. А если не ключевой, то его можно при любом подходе отложить.
  • Сравнение подходов к созданию сайта: проектирование, бриф и agile
    –2
    Понимаю, но смотрю на это под несколько иным углом. Я вижу и считаю, что есть такой метод подхода к разработке сайта: разработчики садятся и начинают делать сайт кусками и по ходу смотрят, что получится. Вы можете забросать меня цитатами из Википедии или scrum-сайтов, говорить о философии, феноменологическом подходе, спорить по терминологии, но это не меняет сути дела. Я написал не о теоретической трактовке, а о реальном практическом применении.
  • Сравнение подходов к созданию сайта: проектирование, бриф и agile
    0
    Давайте посмотрим на сайт шире. Сайт — не только и не столько программный продукт. В проекте описывается не только и не столько функционал, сколько решение задач через коммуникацию, дизайн, функционал, услуги.
  • Сравнение подходов к созданию сайта: проектирование, бриф и agile
    0
    Не уверен, что правильно понял вопрос, но попробую ответить. Участие заказчика — это предоставление необходимой информации — требований, бизнес-задач, о себе, своих продуктах/услугах и т.п. — и потом утверждение проекта. Если он не хочет делать первое, то с ним нельзя работать, а вот если он не хочет делать второе… Это вопрос, конечно, интересный. Не встречался ещё с таким, кто сказал бы: Вот вам миллион, на выходе хочу сайт классный. Как правило, заказчик хочет и способен утвердить ключевые моменты в проекте, а за остальное действительно ответственность берёт на себя разработчик.
  • Сравнение подходов к созданию сайта: проектирование, бриф и agile
    –3
    На уровне теории это сравнение действительно несколько спорно, понимаю. Но на уровне практического подхода очень даже.
  • Сравнение подходов к созданию сайта: проектирование, бриф и agile
    0
    Бриф — да. Проектирование — это не вещь, направленная на детализацию требований. Проектирование — это вещь, направленная на уточнение идеи, построение модели проекта под задачи, инструмент планирования и прогнозирования. Требования — лишь малая часть проекта.
  • Сравнение подходов к созданию сайта: проектирование, бриф и agile
    –3
    Я их сравниваю на уровне подхода к разработке, причём учитываю не только теорию, как вы правильно заметили, обвиняя меня в отсутствии должного академизма, а практику. На мой взгляд, это гораздо ценнее чисто научного подхода.

    Как делаются на практике сайты:
    1. Начинают с глубокого водопадного проектирования и дальше чётко без всякого agile следуют проекту.
    2. Начинают с краткого брифа и дальше каким-то образом по нему идут, чаще всего, водопадно, собирая сайт по структуре разделов и кое-как описанным модулям.
    3. Делают вводную — иногда это короткое проектирование, а иногда просто сбор требований — по методике agile и дальше разрабатывают по этой же методике.
  • Сравнение подходов к созданию сайта: проектирование, бриф и agile
    –2
    Спасибо за комментарий. Я в статье говорю о подходе к разработке сайтов, а не о создании чего бы то ни было вообще в IT. Это узко-направленная оценка, а вы мне привели пример с ноутбуками и планшетами.

    К сожалению, в практике разработки сайтов ни разу не сталкивался с тем, о чём вы говорите. Красивая теория, а на самом деле получается «делаем, как получится, получаем, что получится».

    Вы сами хоть раз делали сайт, используя Agile и его метрики? Что получилось? Сравнивали с водопадной моделью?
  • Сравнение подходов к созданию сайта: проектирование, бриф и agile
    +1
    Я писал об этом в статье Что такое проектирование сайта и почему его нужно делать (от лица коллеги, потому что не было тогда своего аккаунта на Хабре) и по частям в других постах, но потом остановился, потому что понял, что методика существенно меняется с каждым новым проектом, надеюсь, в лучшую сторону. Общий подход сохранился, но детализация сильно поменялась. Планирую описать её заново с реальным кейсом в ближайшие пару месяцев.
  • Сравнение подходов к созданию сайта: проектирование, бриф и agile
    0
    Спасибо. Кое-что не читал, кстати.
  • Сравнение подходов к созданию сайта: проектирование, бриф и agile
    0
    Сократил запись в хабе. Это имели в виду?
  • Сравнение подходов к созданию сайта: проектирование, бриф и agile
    0
    Наверняка забыл. А что с ним сделать надо и зачем?
  • Эволюция веб-проекта — что не забыть предусмотреть в ТЗ
    +1
    Присоединяюсь к предыдущему докладчику.
  • Эволюция веб-проекта — что не забыть предусмотреть в ТЗ
    +1
    5 баллов! «Вы погружаетесь в детали :)» Не надо, товарищ, погружаться в детали. Это пустое…
  • Эволюция веб-проекта — что не забыть предусмотреть в ТЗ
    0
    Веб-проект с хорошей идеей, реализующей потребности пользователей, ни-ко-гда не умрёт из-за «не так» работающей CMS или использования Agile.

    Посмотрите, например, на сайт www.couchsurfing.org/ — это вообще глухие 90-е. Понятия не имею, на какой CMS они там сидят, но я знаю, что его собрали быстро и ловко, и явно на чём-то диком и старом. Сайт периодически лежит, юзабилити на нуле. И что? Таких примеров — море.
  • Эволюция веб-проекта — что не забыть предусмотреть в ТЗ
    0
    Слушайте, на меня капает что-то с потолка. Водичка?
  • Эволюция веб-проекта — что не забыть предусмотреть в ТЗ
    +1
    Ничего-ничего, мы вас потихоньку выгоним с рынка с вашим «чтобы сделать грамотное ТЗ, посмотри на функционал Битрикс». Ущербный подход из 90-х — начала 2000-х, когда никто ещё слыхом не слыхивал про нормальное проектирование и ориентацию на бизнес-задачи клиента, а не функционал «коробки».
  • Эволюция веб-проекта — что не забыть предусмотреть в ТЗ
    +2
    Простите, но в вашей статье нет ни слова о грамотном составлении ТЗ. Ни-еди-но-го-сло-ва.
  • Как поставить задачу для простого (шаблонного) сайта
    0
    Не за что!
  • Как поставить задачу для простого (шаблонного) сайта
    0
    Опросник плохо помогает оценить проект, потому что он даёт мало полезной информации, мучает потенциального клиента и формирует отношение «как к китайцам». Это вообще вечный спор у нас: откуда взялось это отношение? Всё не так однозначно, но в частности потому что «напишите мне ТЗ», «заполните опросник“» и т.д. Начинать всё таки лучше с себя, чем с просмотра идиотских запросов от клиентов на weblancer.

    2 сайта + 2 логотипа, на все 3 дня, 3000р. и никакой предоплаты.

    Надеюсь, что это всё-таки крайние случаи. Такое есть везде)

    И тема оценки проекта — уж очень отдельная.
  • Как поставить задачу для простого (шаблонного) сайта
    0
    Skype — это прекрасный вариант!

    российское отношение к фрилансерам как к «китайцам»

    Если фрилансер работает как китаец, то какое ещё к нему должно быть отношение?

    Данная методика описана для случая, когда вы уже договорились с клиентом, примерно понимая, что нужно сделать, и осталось уточнить детали. Это не методика продажи сайта, если только вы ТЗ не делаете за отдельную плату.
  • Как поставить задачу для простого (шаблонного) сайта
    0
    А разве в таком случае речь идёт о шаблонном сайте?
  • Как поставить задачу для простого (шаблонного) сайта
    0
    Да, мы так работаем со сложными сайтами обычно: проектирование — оценка — разработка.

    А как ваши клиенты реагируют на просьбу оплатить ТЗ? Интересно.
  • Как поставить задачу для простого (шаблонного) сайта
    0
    Мы-то тут, по ходу, все это понимаем. Вашу статью — да распечатать бы крупным шрифтом и развесить в студиях для ознакомления. )

    Я был бы счастлив)
  • Как поставить задачу для простого (шаблонного) сайта
    0
    А при встрече с клиентом, у меня жена конспектирует наш разговор и уже потом, дома, САМА заполняет анкету, на основании которой я делаю сайт.

    Ещё хороший вариант — писать на диктофон. Не отвлекает от разговора.
  • Как поставить задачу для простого (шаблонного) сайта
    0
    Тем, что для кастомного сайта процесс проектирования куда сложнее, а для шаблонного 99% задач уже известны и решения под них тоже на рынке/в голове есть.
  • Как поставить задачу для простого (шаблонного) сайта
    0
    4-5 часов максимум на интервью, уточнение, ТЗ, согласования.
  • Как поставить задачу для простого (шаблонного) сайта
    0
    Речь о них зашла, потому что о более серьёзных я уже писал статьи про проектирование. А тут меня прямо вскрыло, когда я столкнулся с сегментом шаблонных сайтов поближе.
  • Как поставить задачу для простого (шаблонного) сайта
    0
    Так, послушайте:

    1. Надо менять психологию фрилансеров. Зачем и написал статью, собственно.
    2. Заказчик действительно должен знать, чего он хочет, но не в терминах «новости справа, в меню 4 пункта:..., услуги двухуровневым каталогом», а в терминах «мне нужно интернет-представительство для рекламы своих услуг для такой-то ЦА и вот этого нового сегмента ЦА».
    3. Это практически ничего не стоит! Выше я написал, что на всё про всё выходит после тренировки 4-5 часов. Вы гораздо больше времени потратите на препирательства с заказчиком, когда сайт получится плохим, не соответствующим ожиданиям, не решающим задачи. На пару математических порядков больше. И в портфолио будет стыдно положить.
  • Как поставить задачу для простого (шаблонного) сайта
    0
    Да, в шаблонных сайтах это важно — порог исправлений, заранее поставить в известность об ограничениях.