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