Мне пришлось попотеть, прежде чем я нашёл комментарий, который вы имели в виду. На всякий случай прикладываю его часть в виде картинки, чтобы контекст не потерялся.
Да, я бесплатно оцениваю проекты небольшого объёма, чтобы не разводить бюрократию и поскорее приступить к работе.
И платно оцениваю проекты с большим количеством ролей, процессов и разделов.
А я вот не уверен, насколько Хабр оповещает тех, кто на меня подписан. Как это выглядит с вашей стороны? В своих каналах вне Хабра я специально не анонсирую статьи в первые сутки после выхода, чтобы не смазать реальную картину и понимать, куда дальше развиваться.
Все проекты, которые я разрабатываю руками сам, я предварительно проектирую. Да, с насмотренностью и опытом всё проще делать всё «на лету». Да только всё равно это разные процессы с разными приоритетами. Гораздо меньше шансов ошибиться, когда работаешь по собственной проектной документации. Задача из абстрактной превращается в прикладную.
С проектированием. Спроектировал → посмотрел на результат → внёс правки в прототип. Пошёл кодить финализированный вариант. Это делается быстро.
Без проектирования. Закодил → посмотрел на результат → внёс правки в код. Это делается уже медленнее. Параллельная работа с большим количеством файлов, попытка одновременно думать и об интерфейсе, и о программной архитектуре, отвлекаешься на мелкие трудности, по которым ещё нет опыта.
Думаю, что это сработало бы, если бы я делал очень однотипные проекты. Но тогда зачем вообще проектировать? Упаковал бы во фреймворк или в тиражируемое решение — и продавал бы.
Многое будет зависеть от типа клиента. Если клиент не разбирается в том, что вы ему предоставляете — он вообще может не ориентироваться ни в ценах, ни в сроках. Он может сравнивать вас с кем-то ещё, а может и не сравнивать. У него может быть был когда-то опыт заказа чего-то подобного, а может и не был.
А если клиент хорошо разбирается в том, что заказывает, а также в состоянии оценить скорость и качество, — таких клиентов я называю профессиональными. Там будет очень трезвая оценка. Можно предположить, что такие будут биться за каждый рубль, но опыт показывает, что нет. Они вполне могут оценить, например, уровень самостоятельности или сервиса исполнителя, как раз таки сравнивая его с другими.
Так что я не могу поставить себя на место заказчика. Я сам много раз выступал в роли заказчика и хорошо разбираюсь во всём процессе разработки. А что в голове у другого, абстрактного, заказчика — это загадка.
Была возможность сравнить, как команда справлялась со схожими по размерам задачами. Одни задачи были сопровождены подробной проектной документацией, другие — нет. Разница в скорости составляла 2-3 раза. Это субъективное наблюдение. Объективно произвести измерения невозможно (предыдущая моя статья на Хабре как раз начинается с этого тезиса).
Но на тех разницах в сроках, которые тогда получились, я сформировал довольно устойчивое убеждение.
Да, стабильный миллион на фрилансе — это для меня задача не из лёгких. Но выполнимая. Я только однажды заработал чуть больше миллиона в апреле 2019 :) А потом в следующие полтора месяца — ничего. Но всё равно, тот апрель послужил мне живым примером выполнимости задачи. А миллион тогда и миллион сегодня — это разные миллионы.
Спасибо, вы очень точную иллюстрацию привели — по сути, это ровно та же проблема, с которой я столкнулся на этапе, когда уже по шаблону мог проектировать типовые вещи в разы быстрее, чем раньше.
Почасовая модель, увы, плохо учитывает рост эффективности исполнителя. Когда клиенту важен результат, ему психологически проще оценивать итоговый продукт или проектную работу в целом. А почасовая ставка часто провоцирует либо скрывать рост эффективности (как в вашем примере), либо постоянно объясняться, почему работа занимает слишком мало времени.
Собственно, в этом и родился для меня сдвиг в сторону попроектной, а позже и абонентской модели — чтобы можно было честно вкладываться в эффективность, не создавая при этом парадоксального ощущения, что за быструю работу надо платить меньше.
Понимаю вашу точку зрения — я сам поначалу так рассуждал.
Со временем клиентов стало больше, чем я мог взять в работу один, я создал бренд Проектората, собрал команду, делегировал часть проектной работы. Агентская модель тогда показалась мне слишком сложной для масштабирования (много операционной рутины при неочевидной финансовой разнице), поэтому я вернулся к более дорогим индивидуальным проектам. Если бы продолжил тогда развивать агентство — возможно, история пошла бы иначе.
Позже, в 2018 году я запустил стартап — генератор посадочных страниц. Это уже была попытка выйти в продуктовый бизнес. Стартап не взлетел, инвестор потерял деньги, я получил колоссальный опыт.
Все эти эксперименты помогли мне понять одну простую вещь: у фриланса тоже не такие уж низкие потолки, как принято считать. Стоимость консалтинговых услуг опытного специалиста, работающего с крупными системами, вполне может быть выше, чем зарплата удалённого штатного сотрудника той же квалификации. Тем более в проектах, где важны не только сами рабочие часы, но и глубина экспертизы, проактивность и способность выстроить процессы проектирования "на берегу".
Вообще, я давно воспринимаю фриланс и предпринимательство как две части одного спектра. Многие предприниматели начинают с индивидуальных услуг, потом автоматизируют часть работы, создают продукт — у кого-то получается вырастить полноценный бизнес, у кого-то — нет.
Но в данной статье я сознательно не касался темы масштабируемости, соцпакета, отпусков и т.п. Она не об этом. Это просто мой личный опыт того, как я за 20 лет прошёл три модели оценки проектной работы: почасовую, попроектную и абонентскую. За это время у меня было около 300 клиентов и команд — отсюда и делаю свои выводы.
Поэтому мне, честно говоря, в вашем комментарии даже больше интересен не ваш вывод, а ваш контекст: какой у вас личный опыт в работе по найму, на фрилансе? Как вы сами оцениваете свою работу? Как выбираете модель — почасовую, проектную, абонентскую? Почему?
Это неважно, успешный ли это кейс или что-то рутинное — интересно любое видение. Собственно, благодаря таким разным практическим историям и формируется полезная картина реального рынка.
Тех задание — это довольно абстрактное понятие. В каждом коллективе люди вкладывают в него разное значение.
Я обычно пишу функциональные требования к проекту, которые и становятся тех заданием на проектирование. А результат проектирования — тех заданием на разработку.
Если проект не объёмный и сбор первоначальных функциональных требований можно уместить в 1-3 часа, я действительно делаю эту работу бесплатно.
Если работа по составлению ФТ сама занимает много времени — я оцениваю её под ключ (обычно в диапазоне от 10 до 100к).
И я не сетую, что моя работа стоит больше. Точнее, до вашего комментария, я не думал, что сетую. Но со стороны-то всегда виднее. Спасибо за обратную связь!
Я как раз в статье описываю свой опыт в ситуации, когда проекта ещё нет, ТЗ ещё нет, а задача стоит как раз в том, чтобы этот фундамент для разработки создать.
На стадии подготовки проектной документации у клиента ещё не всегда даже до конца сформулировано, что именно он хочет получить. Поэтому в таких случаях почасовая оплата часто становится для клиента зоной дискомфорта (страх непредсказуемости), а попроектная оценка — наоборот, даёт больше определённости.
Когда же речь идёт о поддержке, постоянных доработках, сопровождении действующего продукта — да, здесь почасовая модель для обеих сторон становится проще и удобнее. Единственная проблема — может отпугнуть ставка часа сильно выше рынка, которая легко скрывается попроектной оценкой. Здесь и приходит на помощь абонентка. Она может быть невысокой за месяц, но тоже вуалирует количество затраченных на работу часов.
Спасибо за комментарий! Есть важная специфика моей работы, которую, возможно, стоит отдельно пояснить.
Обычно на момент, когда я подключаюсь, у клиента как раз ещё нет готового ТЗ — оно появляется в процессе моей работы. Я как раз и занимаюсь тем, чтобы на основе обсуждений, требований бизнеса, технических ограничений и нюансов процессов собрать и оформить рабочую проектную документацию: прототипы, спецификации, схемы взаимодействий. То есть я не столько выполняю работу «по ТЗ», сколько создаю саму основу для будущей разработки.
Поэтому и статья — не о процессе выбора подрядчиков (где действительно можно рассматривать покупку готового продукта, аренду и т.п.), а о процессе расчёта стоимости моей собственной работы, когда тебе самому нужно заранее оценить сложность проекта клиента и понять, за какую сумму брать его в работу.
И в первом, и во втором случаях клиенту по факту не нужны мои часы — ему нужен результат. А вот с абоненткой отдельная история. Там действительно клиент платит за доступность специалиста, но только на более выгодных условиях для двух сторон, чем в традиционном найме.
А дальше возникает рой нюансов. Это новый проект или рефакторинг существующего? Это стартап или попытка повторить что-то, проверенное временем? Это автоматизация или какой-нибудь е-коммерс? Это распределённая большая команда или два человека (фулл-стэк и маркетолог)? В каждом конкретном случае будут свои особенности.
Мой опыт очень специфический, да ещё и пришлось делать сильное усреднение в статье (что понижает системность рассуждений), но я думаю, многим коллегам-фрилансерам и проектировщикам эти мысли могут быть полезны — поэтому и решил поделиться.
Снаружи действительно может выглядеть похоже. Но разница в том, что при абонентской оплате ты не просто «появляешься в офисе 160 часов в месяц». Заказчик платит не за время, а за квалификацию и вовлечённость: быстрое вхождение в сложный контекст, помощь при принятии решений, детализация требований, работа на опережение проблем в разработке.
Это как если бы к штатному сотруднику приставили старшего консультанта, который помогает команде не наломать дров на старте, чтобы потом не пришлось переделывать.
Такой подход редко нужен всем подряд, но оказывается полезен в сложных проектах.
Я тоже об этом размышлял. Но в реальной жизни чаще всего сталкиваюсь с тем, что скорость в головах клиентов не конвертируется в готовность платить больше за те же объёмы.
Большинство хотят «быстро, качественно и недорого». А оценка под ключ позволяет более честно разделить риски: я беру на себя ответственность за конечный результат, а клиент получает предсказуемый бюджет.
Модель «почасовка + повышающие коэффициенты за срочность», наверное, может сработать, когда клиент уже знаком с тобой и твоей скоростью. А вот для новых клиентов «под ключ» продаётся легче.
Заморожен. С 2022 года новых функций не появляется. Это мой стартап, который я начал проектировать в 2017 году. Когда-нибудь напишу об этом опыте большой пост.
Представляете, я дописал и опубликовал книгу в начале 2023 года. И пишу об этом регулярно и здесь, и в Телеграме, и на Проекторатовских ресурсах. И до сих пор не все знают.
Это наглядный пример того, насколько важно постоянно рассказывать о своих делах, а не один-два раза. Не бояться повторяться и не думать, что все всё сами узнают.
С удовольствием послушал бы о вашем проектике в личке.
Мне пришлось попотеть, прежде чем я нашёл комментарий, который вы имели в виду. На всякий случай прикладываю его часть в виде картинки, чтобы контекст не потерялся.
Да, я бесплатно оцениваю проекты небольшого объёма, чтобы не разводить бюрократию и поскорее приступить к работе.
И платно оцениваю проекты с большим количеством ролей, процессов и разделов.
А я вот не уверен, насколько Хабр оповещает тех, кто на меня подписан. Как это выглядит с вашей стороны? В своих каналах вне Хабра я специально не анонсирую статьи в первые сутки после выхода, чтобы не смазать реальную картину и понимать, куда дальше развиваться.
Все проекты, которые я разрабатываю руками сам, я предварительно проектирую. Да, с насмотренностью и опытом всё проще делать всё «на лету». Да только всё равно это разные процессы с разными приоритетами. Гораздо меньше шансов ошибиться, когда работаешь по собственной проектной документации. Задача из абстрактной превращается в прикладную.
С проектированием. Спроектировал → посмотрел на результат → внёс правки в прототип. Пошёл кодить финализированный вариант. Это делается быстро.
Без проектирования. Закодил → посмотрел на результат → внёс правки в код. Это делается уже медленнее. Параллельная работа с большим количеством файлов, попытка одновременно думать и об интерфейсе, и о программной архитектуре, отвлекаешься на мелкие трудности, по которым ещё нет опыта.
Думаю, что это сработало бы, если бы я делал очень однотипные проекты. Но тогда зачем вообще проектировать? Упаковал бы во фреймворк или в тиражируемое решение — и продавал бы.
Многое будет зависеть от типа клиента. Если клиент не разбирается в том, что вы ему предоставляете — он вообще может не ориентироваться ни в ценах, ни в сроках. Он может сравнивать вас с кем-то ещё, а может и не сравнивать. У него может быть был когда-то опыт заказа чего-то подобного, а может и не был.
А если клиент хорошо разбирается в том, что заказывает, а также в состоянии оценить скорость и качество, — таких клиентов я называю профессиональными. Там будет очень трезвая оценка. Можно предположить, что такие будут биться за каждый рубль, но опыт показывает, что нет. Они вполне могут оценить, например, уровень самостоятельности или сервиса исполнителя, как раз таки сравнивая его с другими.
Я об этом писал у себя в книге про фриланс в главе «Профессиональные и непрофессиональные клиенты».
Так что я не могу поставить себя на место заказчика. Я сам много раз выступал в роли заказчика и хорошо разбираюсь во всём процессе разработки. А что в голове у другого, абстрактного, заказчика — это загадка.
Была возможность сравнить, как команда справлялась со схожими по размерам задачами. Одни задачи были сопровождены подробной проектной документацией, другие — нет. Разница в скорости составляла 2-3 раза. Это субъективное наблюдение. Объективно произвести измерения невозможно (предыдущая моя статья на Хабре как раз начинается с этого тезиса).
Но на тех разницах в сроках, которые тогда получились, я сформировал довольно устойчивое убеждение.
Да, стабильный миллион на фрилансе — это для меня задача не из лёгких. Но выполнимая. Я только однажды заработал чуть больше миллиона в апреле 2019 :) А потом в следующие полтора месяца — ничего. Но всё равно, тот апрель послужил мне живым примером выполнимости задачи. А миллион тогда и миллион сегодня — это разные миллионы.
А что за продукт разрабатываете?
Спасибо, вы очень точную иллюстрацию привели — по сути, это ровно та же проблема, с которой я столкнулся на этапе, когда уже по шаблону мог проектировать типовые вещи в разы быстрее, чем раньше.
Почасовая модель, увы, плохо учитывает рост эффективности исполнителя. Когда клиенту важен результат, ему психологически проще оценивать итоговый продукт или проектную работу в целом. А почасовая ставка часто провоцирует либо скрывать рост эффективности (как в вашем примере), либо постоянно объясняться, почему работа занимает слишком мало времени.
Собственно, в этом и родился для меня сдвиг в сторону попроектной, а позже и абонентской модели — чтобы можно было честно вкладываться в эффективность, не создавая при этом парадоксального ощущения, что за быструю работу надо платить меньше.
Понимаю вашу точку зрения — я сам поначалу так рассуждал.
Со временем клиентов стало больше, чем я мог взять в работу один, я создал бренд Проектората, собрал команду, делегировал часть проектной работы. Агентская модель тогда показалась мне слишком сложной для масштабирования (много операционной рутины при неочевидной финансовой разнице), поэтому я вернулся к более дорогим индивидуальным проектам. Если бы продолжил тогда развивать агентство — возможно, история пошла бы иначе.
Позже, в 2018 году я запустил стартап — генератор посадочных страниц. Это уже была попытка выйти в продуктовый бизнес. Стартап не взлетел, инвестор потерял деньги, я получил колоссальный опыт.
Все эти эксперименты помогли мне понять одну простую вещь: у фриланса тоже не такие уж низкие потолки, как принято считать. Стоимость консалтинговых услуг опытного специалиста, работающего с крупными системами, вполне может быть выше, чем зарплата удалённого штатного сотрудника той же квалификации. Тем более в проектах, где важны не только сами рабочие часы, но и глубина экспертизы, проактивность и способность выстроить процессы проектирования "на берегу".
Вообще, я давно воспринимаю фриланс и предпринимательство как две части одного спектра. Многие предприниматели начинают с индивидуальных услуг, потом автоматизируют часть работы, создают продукт — у кого-то получается вырастить полноценный бизнес, у кого-то — нет.
Но в данной статье я сознательно не касался темы масштабируемости, соцпакета, отпусков и т.п. Она не об этом. Это просто мой личный опыт того, как я за 20 лет прошёл три модели оценки проектной работы: почасовую, попроектную и абонентскую. За это время у меня было около 300 клиентов и команд — отсюда и делаю свои выводы.
Поэтому мне, честно говоря, в вашем комментарии даже больше интересен не ваш вывод, а ваш контекст: какой у вас личный опыт в работе по найму, на фрилансе? Как вы сами оцениваете свою работу? Как выбираете модель — почасовую, проектную, абонентскую? Почему?
Это неважно, успешный ли это кейс или что-то рутинное — интересно любое видение. Собственно, благодаря таким разным практическим историям и формируется полезная картина реального рынка.
Тех задание — это довольно абстрактное понятие. В каждом коллективе люди вкладывают в него разное значение.
Я обычно пишу функциональные требования к проекту, которые и становятся тех заданием на проектирование. А результат проектирования — тех заданием на разработку.
Если проект не объёмный и сбор первоначальных функциональных требований можно уместить в 1-3 часа, я действительно делаю эту работу бесплатно.
Если работа по составлению ФТ сама занимает много времени — я оцениваю её под ключ (обычно в диапазоне от 10 до 100к).
И я не сетую, что моя работа стоит больше. Точнее, до вашего комментария, я не думал, что сетую. Но со стороны-то всегда виднее. Спасибо за обратную связь!
Спасибо, вы очень точно сформулировали.
Я как раз в статье описываю свой опыт в ситуации, когда проекта ещё нет, ТЗ ещё нет, а задача стоит как раз в том, чтобы этот фундамент для разработки создать.
На стадии подготовки проектной документации у клиента ещё не всегда даже до конца сформулировано, что именно он хочет получить. Поэтому в таких случаях почасовая оплата часто становится для клиента зоной дискомфорта (страх непредсказуемости), а попроектная оценка — наоборот, даёт больше определённости.
Когда же речь идёт о поддержке, постоянных доработках, сопровождении действующего продукта — да, здесь почасовая модель для обеих сторон становится проще и удобнее. Единственная проблема — может отпугнуть ставка часа сильно выше рынка, которая легко скрывается попроектной оценкой. Здесь и приходит на помощь абонентка. Она может быть невысокой за месяц, но тоже вуалирует количество затраченных на работу часов.
Спасибо за комментарий! Есть важная специфика моей работы, которую, возможно, стоит отдельно пояснить.
Обычно на момент, когда я подключаюсь, у клиента как раз ещё нет готового ТЗ — оно появляется в процессе моей работы. Я как раз и занимаюсь тем, чтобы на основе обсуждений, требований бизнеса, технических ограничений и нюансов процессов собрать и оформить рабочую проектную документацию: прототипы, спецификации, схемы взаимодействий. То есть я не столько выполняю работу «по ТЗ», сколько создаю саму основу для будущей разработки.
Поэтому и статья — не о процессе выбора подрядчиков (где действительно можно рассматривать покупку готового продукта, аренду и т.п.), а о процессе расчёта стоимости моей собственной работы, когда тебе самому нужно заранее оценить сложность проекта клиента и понять, за какую сумму брать его в работу.
И в первом, и во втором случаях клиенту по факту не нужны мои часы — ему нужен результат. А вот с абоненткой отдельная история. Там действительно клиент платит за доступность специалиста, но только на более выгодных условиях для двух сторон, чем в традиционном найме.
А дальше возникает рой нюансов. Это новый проект или рефакторинг существующего? Это стартап или попытка повторить что-то, проверенное временем? Это автоматизация или какой-нибудь е-коммерс? Это распределённая большая команда или два человека (фулл-стэк и маркетолог)? В каждом конкретном случае будут свои особенности.
Мой опыт очень специфический, да ещё и пришлось делать сильное усреднение в статье (что понижает системность рассуждений), но я думаю, многим коллегам-фрилансерам и проектировщикам эти мысли могут быть полезны — поэтому и решил поделиться.
Обещаю, в этот раз обошлось без книги. Если и будет следующая книга — то именно о проектировании интерфейсов, а не чём-то, связанном с карьерой.
Снаружи действительно может выглядеть похоже. Но разница в том, что при абонентской оплате ты не просто «появляешься в офисе 160 часов в месяц». Заказчик платит не за время, а за квалификацию и вовлечённость: быстрое вхождение в сложный контекст, помощь при принятии решений, детализация требований, работа на опережение проблем в разработке.
Это как если бы к штатному сотруднику приставили старшего консультанта, который помогает команде не наломать дров на старте, чтобы потом не пришлось переделывать.
Такой подход редко нужен всем подряд, но оказывается полезен в сложных проектах.
Я тоже об этом размышлял. Но в реальной жизни чаще всего сталкиваюсь с тем, что скорость в головах клиентов не конвертируется в готовность платить больше за те же объёмы.
Большинство хотят «быстро, качественно и недорого». А оценка под ключ позволяет более честно разделить риски: я беру на себя ответственность за конечный результат, а клиент получает предсказуемый бюджет.
Модель «почасовка + повышающие коэффициенты за срочность», наверное, может сработать, когда клиент уже знаком с тобой и твоей скоростью. А вот для новых клиентов «под ключ» продаётся легче.
У жены на телефоне галочки больше нет. До этого была, да.
Антон, согласен, не хватало. Добавил!
Ух ты, прям диаметрально противоположная позиция!
Заморожен. С 2022 года новых функций не появляется. Это мой стартап, который я начал проектировать в 2017 году. Когда-нибудь напишу об этом опыте большой пост.
Спасибо за поддержку!
Представляете, я дописал и опубликовал книгу в начале 2023 года. И пишу об этом регулярно и здесь, и в Телеграме, и на Проекторатовских ресурсах. И до сих пор не все знают.
Это наглядный пример того, насколько важно постоянно рассказывать о своих делах, а не один-два раза. Не бояться повторяться и не думать, что все всё сами узнают.
С удовольствием послушал бы о вашем проектике в личке.
Ой, а что будет с Фигмой после 12 сентября? Я какую-то новость пропустил?