Блог

Почему каждый второй из наших прототипов для новых проектов уходит в стол, а не в продакшен?

Короткий ответ: потому что когда заказчики по прототипу получают оценку у разработчиков, они понимают, что не потянут разработку по деньгам.

Речь идёт исключительно о новых проектах, а не доработках в существующие. Самый распространённый сценарий выглядит так. Человек придумывает идею для своего продукта и решает его разработать. Он ищет по знакомым контакты программиста. Находит и в двух словах объясняет ему задачу. Программист тыкает пальцем в небо и называет стоимость разработки. Допустим, два миллиона. И намекает, что оценка примерная и было бы неплохо посмотреть на техническое задание.

Кто пишет технические задания? Заказчики. Кто умеет писать технические задания? Проектировщики. Некоторые заказчики отказываются сами писать технические задания и приходят к проектировщикам. Некоторые приходят к нам в Проекторат. Мы объясняем, что наши технические задания называются «функциональными спецификациями» и что мы готовим эти документы сразу после создания интерактивного прототипа.

Зачем нужен интерактивный прототип? Чтобы заказчики, не являющиеся специалистами в разработке, могли посмотреть и пощупать проект ещё даже до этапа дизайна. И подтвердить, что это именно то, что им нужно. Обычно заказчикам не нужно долго объяснять, что это такое и какую это несёт пользу для общего дела, и они покупают у нас проектирование.

Допустим, прототип обошёлся в 150 000 рублей. Функциональная спецификация ещё в 150 000 рублей. Итого 300 000 рублей. С этой документацией заказчик идёт к своему программисту и тот делает уже точную оценку. И оказывается, что все хотелки клиента стоят не два миллиона, о которых раньше шла речь, а десять-пятнадцать. И разрабатывать это придётся не меньше года-двух.

Клиент вздыхает и решает пока не делать проект. Проектная документация уходит в стол. Так за 300 000 рублей можно предотвратить потерю двух миллионов рублей и вернуться к этому вопросу позже, когда появятся деньги. Либо пересмотреть свой подход к проекту. Например, избавиться от 90% функций для того, чтобы создать mvp и проверить жизнеспособность бизнес-гипотезы. Но это уже совсем другая история.

Я лично столкнулся с десятком случаев, когда клиенты ввязываются в разработку без проектной документации и в какой-то момент у них заканчиваются деньги, а у разработчика силы. Обычно речь идёт о небольших индивидуальных проектах ценой до миллиона, но суть та же. Проектирование, которое можно вместить в 100-тысячный бюджет, в разы повышает шанс на доведение дела до конца.

Раньше мы расстраивались, когда очередной прототип уходил «в стол» и разработка по нему не велась. А сейчас понимаем, что это нормально. Что мы спасли клиента от затяжной тупиковой разработки, где в какой-то момент закончатся деньги, и проект умрёт.

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

Тултипы (tooltips). Что это такое и как их проектировать

Тултип, от английского tooltip. Это такая короткая всплывающая подсказка, появляющаяся при наведении курсора на элемент. Или при фокусировании на элементе с помощью клавиатуры. Или при длительном разглядывании элемента, если вы в шлеме виртуальной реальности с трекингом глаз.

Привет, меня зовут Егор Камелев. Я занимаюсь проектированием интерфейсов с 2006 года. Сегодня хочу поделиться чек-листом вопросов, связанных с проектированием тултипов.

Читать далее Тултипы (tooltips). Что это такое и как их проектировать

Видеообзор бета-версии Axure 10

28 января появилась бета-версия Axure 10. Она доступна всем пользователям 9 версии программы. Разработчики поработали над множеством улучшений, связанных с созданием всё более сложных динамических взаимодействий в интерактивных прототипах. Теперь создавать динамику стало ещё проще.

Изменения затронули динамические панели, репитеры, текстовые поля, конструктор действий и условий, работу с группами.

Программа стала работать быстрее, немного обновился интерфейс.

Дата релиза ещё не анонсирована, однако мы уже точно знаем, что Axure 10 будет доступна исключительно по подписке.

Ознакомиться более подробно с новыми функциями и мнением проектировщика Егор Камелева насчёт будущего программы можно в этом видео:

Видеообзор бета-версии Axure 9

Axure 9 beta наконец-то стала доступна для скачивания владельцами лицензионных восьмёрок. Хотя обещали нам это событие до конца лета. Ну да ладно, пять дней погоды не делают.

Первые впечатления смешанные, но пока что никаких выводов не делаем. Нужно сначала поработать в ней немного. Смотрим экспресс-обзор от Егора Камелева, где он освещает около 40% перечисленных разработчиками возможностей, которые он посчитал действительно важными.

Заработок на фрилансе: зачем повышать уровень сервиса?

Рассказ о моих грядущих обучающих роликах, о том, зачем я буду брать интервью у фрилансеров и о том, как и зачем повышать уровень сервиса при самозанятости. Те, кто спрашивали у меня, можно ли зарабатывать проектировщиком на фрилансе, — не проходите мимо.

Рабочие дни против календарных

Как-то раз мне задали вопрос, почему в коммерческих предложениях (КП) я называю сроки выполнения работ в календарных, а не рабочих днях. Сейчас как раз подходящее время для ответа. Представьте себе: ко мне пришёл клиент 20 декабря. И получает КП, в котором сказано, что окончательный результат, удовлетворяющий всем функциональным требованиям, он увидит через 27 рабочих дней после начала работ. Допустим, мы планируем начать и начинаем 23 декабря. Вопрос: когда он получит этот результат? Ответы можете оставить в комментариях.
 
А пока вы, открыв календарь, считаете даты с учётом выходных и праздничных дней, вы можете прочувствовать на себе то, что будет чувствовать клиент, получивший такое КП.
 
Так как то, что я заявляю, является личным опытом, основанным на определённых жизненных обстоятельствах, также предлагаю поискать примеры ситуаций, когда клиенту действительно будет важно знать, сколько дней я работал в течение названного календарного срока. Потому что у моих заказчиков таких ситуаций не возникало. Всем поголовно на этапе КП было важно две цифры: когда они получат результат и сколько этот результат стоит.
 
Напоминаю, что в КП Проектората финальная дата — это дата релиза, удовлетворяющего всем обозначенным перед началом работ функциональным требованиям. В количестве комментариев после этой даты клиент не ограничен. А значит и сроки могут растянуться на любое время. Но т.к. процесс проектирования выстроен таким образом, что мы вместе с клиентом короткими итерациями движемся к одной цели, то в 6 проектах из 10 финальная дата из КП совпадает с реальным завершением работ, в 2 проектах этап комментариев занимает ещё до плюс 30% затраченного времени, а в оставшихся 2 работа принимается до финальной даты. По статистике за 2016-2017 гг.
 
Спасибо за внимание. Приятно видеть, что многие вещи, которыми я делился в течение этого года, коллеги внедряют в свои процессы.

Когда не хватает времени на новые входящие проекты

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

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

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

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

Если кто-то из клиентов «отвалится» из-за дороговизны вашей услуги, это будет лучше, чем если вы откажете ему, даже не пообщавшись. Ведь есть шанс того, что вы очаруете его своим обаянием, и он вернётся позже, поднакопив ресурсов или дождавшись очереди. Каждый не «отвалившийся» и вернувшийся клиент влияет на ваше ценообразование, повышая стоимость часа на основную работу.

Проект на 100 часов, каждый час из которого будет стоить на 10% дороже старого ценника, принесёт вам 10 часов профита. Стоимость этих 10 часов и будет равняться стоимости тех пары «бесплатных» часов, которые вы потратите на общение и первичную оценку клиента. То же касается и делегирования излишков проектов. А если цена возрастёт не на 10%, а на 100%?

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

И, как всегда: воспринимайте этот текст, как мои личные мысли, основанные на специфическом опыте. Надеюсь, они послужат вам пищей для размышлений. На экспертность не претендую. Ваш Егор Камелев.

Задатки к проектированию

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

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

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

С опытом количество вопросов уменьшится, потому что, например, зная регион и время года, можно не спрашивать про насекомых. А с ещё более богатым опытом они сведутся к чему-то вроде: «А почему вы спрашиваете?»

Мысли вслух, сужу по себе, на экспертность не претендую, ваш Егор Камелев.

Каким проектом вы гордитесь?

Если вы проектировщик или дизайнер и вам нечего ответить на вопрос «Каким проектом вы гордитесь?», то не нужно этого стыдиться.

Если вы работали наёмным сотрудником в рамках разделения труда, это совершенно нормально, что такого проекта у вас не будет. Вы делали то, что вас просили делать. То, за что вам платили деньги.

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

Ответ «Я горжусь не конкретными проектами, а тем, что любую работу сдаю в срок и в том качестве, которое делает клиента довольным» удовлетворит любого здравомыслящего работодателя.

Secured By miniOrange