У меня за последние даже не полгода, а год (не менял часовую ставку в этот период), поступления на счёт стабильные ± 10-15%.
Я постоянно работаю с хорошими фрилансерами, программистами, дизайнерами, верстальщиком, и у них то же самое (выборка 11 человек). Потому что в день у них выделено Х часов на работу, и они всегда заняты. Всегда. Отсюда и постоянный доход.
Я вообще не понимаю, причём тут постоянный доход, почему он закладывается в определение фрилансера. Вот мой друг работает менеджером по продажам по найму. Сколько продал, столько получил. Другой работает в отделении банка. Там премии за выполнение плана, и они мало зависят от друга. Он без премии имеет 30 000 рублей, а с премией 60 000. И это через раз. А подруга работает в конторе с гибкой системой штрафов и бонусов и, с окладом 20 000, может получить на руки от 10 000 до 40 000. И что? Они всё работают по найму.
У хороших фрилансеров он постоянный, то есть постоянно поступающий плюс-минус 20%, просто выражен не в конкретной сумме и выплачивается не два раза в месяц. Я лично считаю свой доход постоянным. Знакомые «стабильные» фрилансеры тоже.
Честно? Никогда не думал, что подушка нужна. Она просто есть.
Это не пункты методики :) Если хотите побольше узнать про методику, рекомендую ссылку в конце статьи.
Т.е. когда предполагается четкое разделение функций и полномочий «заказчик»-«исполнитель» и исполнитель только спрашивает — чего же хочет заказчик.
Нигде ни одним словом я не сказал, что мы только слушаем хотелки клиента. Боже упаси, почитайте остальные мои статьи и посмотрите видео (ссылка в конце статьи). Мы делаем детальный план сбора информации и дальше работаем. В моей методике на этапе сбора информации занимается не пассивная, а суперактивная позиция. Мы проводим качественные интервью, делаем контент-анализ, анализируем метрики, проводим опросы, если требуется, изучаем тонны материалов, среду, форумы, говорим с экспертами и так далее.
Про разделение ответственности — это да, это вы верно подметили. Проектировщик сайта не может и не должен определять ключевые моменты в бизнесе и маркетинге клиента. Это делают другие специалисты, которым клиент заказывает бизнес-концепцию и маркетинговую политику. Но это совсем другой продукт и совсем другие методики. Об этом здесь речи и близко нет и не будет. Про «возложите ответственность» — это, скорее, про мотивацию. Мы всё равно достаём значительную часть информации из других источников.
Считаю что это начальный уровень консалтера, который нужно проходить за 1-2 года освоения предметной области.
Статья не про бизнес-консалтинг, а про методику проектирования сайтов и других интерактивных продуктов. Бизнес-консалтинг — это отдельная вещь, рекомендую её сюда не примешивать. Это всё равно, что прийти в обсуждение статьи про java-скрипты и написать: «Писать java-скрипты — это надо проходить за первый год, а вот проектирование архитектуры системы — это дааа, новый уровень понимания, творческий полёт, другая энергетика.»
Извините, либо утро ещё, либо я не догадлив. Вы не могли бы пояснить (не знаю вашего имени), к чему относится ваш комментарий, а особенно его первая часть до пунктов (4 абзаца)?
Хороший пост в правильном направлении. Я тоже думал написать такой. Единственное, что у меня вызывает серьёзное возражение — это поиск. На мой взгляд, на многих сайтах, особенно корпоративных, наличие поиска — это признание поражения навигации.
Да, речь именно о ключевых моментах. Если момент ключевой, то его разрешения надо ждать при любом подходе, иначе может случиться фейл. А если не ключевой, то его можно при любом подходе отложить.
Понимаю, но смотрю на это под несколько иным углом. Я вижу и считаю, что есть такой метод подхода к разработке сайта: разработчики садятся и начинают делать сайт кусками и по ходу смотрят, что получится. Вы можете забросать меня цитатами из Википедии или scrum-сайтов, говорить о философии, феноменологическом подходе, спорить по терминологии, но это не меняет сути дела. Я написал не о теоретической трактовке, а о реальном практическом применении.
Давайте посмотрим на сайт шире. Сайт — не только и не столько программный продукт. В проекте описывается не только и не столько функционал, сколько решение задач через коммуникацию, дизайн, функционал, услуги.
Не уверен, что правильно понял вопрос, но попробую ответить. Участие заказчика — это предоставление необходимой информации — требований, бизнес-задач, о себе, своих продуктах/услугах и т.п. — и потом утверждение проекта. Если он не хочет делать первое, то с ним нельзя работать, а вот если он не хочет делать второе… Это вопрос, конечно, интересный. Не встречался ещё с таким, кто сказал бы: Вот вам миллион, на выходе хочу сайт классный. Как правило, заказчик хочет и способен утвердить ключевые моменты в проекте, а за остальное действительно ответственность берёт на себя разработчик.
Бриф — да. Проектирование — это не вещь, направленная на детализацию требований. Проектирование — это вещь, направленная на уточнение идеи, построение модели проекта под задачи, инструмент планирования и прогнозирования. Требования — лишь малая часть проекта.
Я их сравниваю на уровне подхода к разработке, причём учитываю не только теорию, как вы правильно заметили, обвиняя меня в отсутствии должного академизма, а практику. На мой взгляд, это гораздо ценнее чисто научного подхода.
Как делаются на практике сайты:
1. Начинают с глубокого водопадного проектирования и дальше чётко без всякого agile следуют проекту.
2. Начинают с краткого брифа и дальше каким-то образом по нему идут, чаще всего, водопадно, собирая сайт по структуре разделов и кое-как описанным модулям.
3. Делают вводную — иногда это короткое проектирование, а иногда просто сбор требований — по методике agile и дальше разрабатывают по этой же методике.
Спасибо за комментарий. Я в статье говорю о подходе к разработке сайтов, а не о создании чего бы то ни было вообще в IT. Это узко-направленная оценка, а вы мне привели пример с ноутбуками и планшетами.
К сожалению, в практике разработки сайтов ни разу не сталкивался с тем, о чём вы говорите. Красивая теория, а на самом деле получается «делаем, как получится, получаем, что получится».
Вы сами хоть раз делали сайт, используя Agile и его метрики? Что получилось? Сравнивали с водопадной моделью?
Я писал об этом в статье Что такое проектирование сайта и почему его нужно делать (от лица коллеги, потому что не было тогда своего аккаунта на Хабре) и по частям в других постах, но потом остановился, потому что понял, что методика существенно меняется с каждым новым проектом, надеюсь, в лучшую сторону. Общий подход сохранился, но детализация сильно поменялась. Планирую описать её заново с реальным кейсом в ближайшие пару месяцев.
Не, не кажется. Даже ущипнул себя для верности.
У меня за последние даже не полгода, а год (не менял часовую ставку в этот период), поступления на счёт стабильные ± 10-15%.
Я постоянно работаю с хорошими фрилансерами, программистами, дизайнерами, верстальщиком, и у них то же самое (выборка 11 человек). Потому что в день у них выделено Х часов на работу, и они всегда заняты. Всегда. Отсюда и постоянный доход.
Я вообще не понимаю, причём тут постоянный доход, почему он закладывается в определение фрилансера. Вот мой друг работает менеджером по продажам по найму. Сколько продал, столько получил. Другой работает в отделении банка. Там премии за выполнение плана, и они мало зависят от друга. Он без премии имеет 30 000 рублей, а с премией 60 000. И это через раз. А подруга работает в конторе с гибкой системой штрафов и бонусов и, с окладом 20 000, может получить на руки от 10 000 до 40 000. И что? Они всё работают по найму.
У хороших фрилансеров он постоянный, то есть постоянно поступающий плюс-минус 20%, просто выражен не в конкретной сумме и выплачивается не два раза в месяц. Я лично считаю свой доход постоянным. Знакомые «стабильные» фрилансеры тоже.
Честно? Никогда не думал, что подушка нужна. Она просто есть.
Это не пункты методики :) Если хотите побольше узнать про методику, рекомендую ссылку в конце статьи.
Нигде ни одним словом я не сказал, что мы только слушаем хотелки клиента. Боже упаси, почитайте остальные мои статьи и посмотрите видео (ссылка в конце статьи). Мы делаем детальный план сбора информации и дальше работаем. В моей методике на этапе сбора информации занимается не пассивная, а суперактивная позиция. Мы проводим качественные интервью, делаем контент-анализ, анализируем метрики, проводим опросы, если требуется, изучаем тонны материалов, среду, форумы, говорим с экспертами и так далее.
Про разделение ответственности — это да, это вы верно подметили. Проектировщик сайта не может и не должен определять ключевые моменты в бизнесе и маркетинге клиента. Это делают другие специалисты, которым клиент заказывает бизнес-концепцию и маркетинговую политику. Но это совсем другой продукт и совсем другие методики. Об этом здесь речи и близко нет и не будет. Про «возложите ответственность» — это, скорее, про мотивацию. Мы всё равно достаём значительную часть информации из других источников.
Статья не про бизнес-консалтинг, а про методику проектирования сайтов и других интерактивных продуктов. Бизнес-консалтинг — это отдельная вещь, рекомендую её сюда не примешивать. Это всё равно, что прийти в обсуждение статьи про java-скрипты и написать: «Писать java-скрипты — это надо проходить за первый год, а вот проектирование архитектуры системы — это дааа, новый уровень понимания, творческий полёт, другая энергетика.»
Как делаются на практике сайты:
1. Начинают с глубокого водопадного проектирования и дальше чётко без всякого agile следуют проекту.
2. Начинают с краткого брифа и дальше каким-то образом по нему идут, чаще всего, водопадно, собирая сайт по структуре разделов и кое-как описанным модулям.
3. Делают вводную — иногда это короткое проектирование, а иногда просто сбор требований — по методике agile и дальше разрабатывают по этой же методике.
К сожалению, в практике разработки сайтов ни разу не сталкивался с тем, о чём вы говорите. Красивая теория, а на самом деле получается «делаем, как получится, получаем, что получится».
Вы сами хоть раз делали сайт, используя Agile и его метрики? Что получилось? Сравнивали с водопадной моделью?