Мы в Проекторате считаем, что важно заранее предупреждать клиента о любых грядущих участках работ, требующих денег. Например, если к нам приходят за интерактивным прототипом за 200 000 ₽, мы обязаны сказать, что скорее всего понадобится заплатить ещё столько же за функциональную спецификацию. А потом ещё 200 000 ₽ за дизайн в Фигме. И ещё 100 000 ₽ за адаптацию этого дизайна под разные разрешения устройств. А ещё можно напомнить, что всю эту пачку денег клиент платит за то, чтобы можно было точно оценить стоимость разработки и отправить будущий проект в реализацию. Так мы будем уверены, что не будем работать с человеком, которому не по карману решение его финальной задачи.
При этом мы не можем называть конкретных цифр для каждого последующего этапа, т.к. они будут зависеть от результатов предыдущего и могут сильно варьироваться. Зато можем давать примерные вилки в процентах. Главное — не создавать ситуацию, когда заказчик покупает часть работ, не зная, сколько денег ему понадобится для всего в комплексе.
Разница между интерактивным прототипом за 200 000 ₽ и всем пулом по UX/UI и технической документации за плюс-минус 700 000 ₽ — колоссальна. И лучше потерять клиента, который был готов работать с нами за 200 000 ₽, чем получить грустного человека, вышедшего из бюджета и неспособного доплатить до результата, необходимого для оценки разработки.
Это как когда покупаешь в магазине классную электронную игрушку для ребёнка, а в комплекте нет батареек. А продавец тебя об этом не предупредил. И ты чувствуешь себя обманутым, снова тратишь время на поход в магазин, покупаешь комплект батареек, а через три дня, когда он разрядится, узнаёшь, что нужно было купить десять комплектов, если ты хочешь, чтобы ребёнок поиграл с игрушкой хотя бы месяц. Особенно когда игрушка стоила 500 ₽, а десять комплектов батареек — 1 500 ₽. Если бы продавец сразу сориентировал нас на 2 000 ₽, возможно, мы не покупали бы того, что нам не по карману или не нужно, больше бы доверяли продавцу и в целом были бы более довольными и возвращались чаще. За подобными примерами далеко ходить не надо.
При этом мы не можем называть конкретных цифр для каждого последующего этапа, т.к. они будут зависеть от результатов предыдущего и могут сильно варьироваться. Зато можем давать примерные вилки в процентах. Главное — не создавать ситуацию, когда заказчик покупает часть работ, не зная, сколько денег ему понадобится для всего в комплексе.
Разница между интерактивным прототипом за 200 000 ₽ и всем пулом по UX/UI и технической документации за плюс-минус 700 000 ₽ — колоссальна. И лучше потерять клиента, который был готов работать с нами за 200 000 ₽, чем получить грустного человека, вышедшего из бюджета и неспособного доплатить до результата, необходимого для оценки разработки.
Это как когда покупаешь в магазине классную электронную игрушку для ребёнка, а в комплекте нет батареек. А продавец тебя об этом не предупредил. И ты чувствуешь себя обманутым, снова тратишь время на поход в магазин, покупаешь комплект батареек, а через три дня, когда он разрядится, узнаёшь, что нужно было купить десять комплектов, если ты хочешь, чтобы ребёнок поиграл с игрушкой хотя бы месяц. Особенно когда игрушка стоила 500 ₽, а десять комплектов батареек — 1 500 ₽. Если бы продавец сразу сориентировал нас на 2 000 ₽, возможно, мы не покупали бы того, что нам не по карману или не нужно, больше бы доверяли продавцу и в целом были бы более довольными и возвращались чаще. За подобными примерами далеко ходить не надо.
Между делом написал статью про проектирование тултипов. https://projectorat.ru/designing-tooltips/
Почему каждый второй из наших прототипов для новых проектов уходит в стол, а не в продакшен?
Короткий ответ: потому что когда заказчики по прототипу получают оценку у разработчиков, они понимают, что не потянут разработку по деньгам.
Речь идёт исключительно о новых проектах, а не доработках в существующие. Самый распространённый сценарий выглядит так. Человек придумывает идею для своего продукта и решает его разработать. Он ищет по знакомым контакты программиста. Находит и в двух словах объясняет ему задачу. Программист тыкает пальцем в небо и называет стоимость разработки. Допустим, два миллиона. И намекает, что оценка примерная и было бы неплохо посмотреть на техническое задание.
Кто пишет технические задания? Заказчики. Кто умеет писать технические задания? Проектировщики. Некоторые заказчики отказываются сами писать технические задания и приходят к проектировщикам. Некоторые приходят к нам в Проекторат. Мы объясняем, что наши технические задания называются «функциональными спецификациями» и что мы готовим эти документы сразу после создания интерактивного прототипа.
Зачем нужен интерактивный прототип? Чтобы заказчики, не являющиеся специалистами в разработке, могли посмотреть и пощупать проект ещё даже до этапа дизайна. И подтвердить, что это именно то, что им нужно. Обычно заказчикам не нужно долго объяснять, что это такое и какую это несёт пользу для общего дела, и они покупают у нас проектирование.
Допустим, прототип обошёлся в 150 000 рублей. Функциональная спецификация ещё в 150 000 рублей. Итого 300 000 рублей. С этой документацией заказчик идёт к своему программисту и тот делает уже точную оценку. И оказывается, что все хотелки клиента стоят не два миллиона, о которых раньше шла речь, а десять-пятнадцать. И разрабатывать это придётся не меньше года-двух.
Клиент вздыхает и решает пока не делать проект. Проектная документация уходит в стол. Так за 300 000 рублей можно предотвратить потерю двух миллионов рублей и вернуться к этому вопросу позже, когда появятся деньги. Либо пересмотреть свой подход к проекту. Например, избавиться от 90% функций для того, чтобы создать mvp и проверить жизнеспособность бизнес-гипотезы. Но это уже совсем другая история.
Я лично столкнулся с десятком случаев, когда клиенты ввязываются в разработку без проектной документации и в какой-то момент у них заканчиваются деньги, а у разработчика силы. Обычно речь идёт о небольших индивидуальных проектах ценой до миллиона, но суть та же. Проектирование, которое можно вместить в 100-тысячный бюджет, в разы повышает шанс на доведение дела до конца.
Раньше мы расстраивались, когда очередной прототип уходил «в стол» и разработка по нему не велась. А сейчас понимаем, что это нормально. Что мы спасли клиента от затяжной тупиковой разработки, где в какой-то момент закончатся деньги, и проект умрёт.
Напоследок, справедливости ради, хочется отметить, что иногда проекты уходят в стол и по другим причинам. Например, все участники посмотрели на то, что получилось, и поняли, что идея оказалась какой-то шляпой и не стоит её разрабатывать. Бывало и такое, что идея норм, прототип норм, ресурсов выше крыши, а руки просто не доходят до запуска этого дела в разработку. Или нет человека, которого можно зарядить деньгами и отправить курировать проект, а у самого клиента уже нет на это личных ресурсов.
Короткий ответ: потому что когда заказчики по прототипу получают оценку у разработчиков, они понимают, что не потянут разработку по деньгам.
Речь идёт исключительно о новых проектах, а не доработках в существующие. Самый распространённый сценарий выглядит так. Человек придумывает идею для своего продукта и решает его разработать. Он ищет по знакомым контакты программиста. Находит и в двух словах объясняет ему задачу. Программист тыкает пальцем в небо и называет стоимость разработки. Допустим, два миллиона. И намекает, что оценка примерная и было бы неплохо посмотреть на техническое задание.
Кто пишет технические задания? Заказчики. Кто умеет писать технические задания? Проектировщики. Некоторые заказчики отказываются сами писать технические задания и приходят к проектировщикам. Некоторые приходят к нам в Проекторат. Мы объясняем, что наши технические задания называются «функциональными спецификациями» и что мы готовим эти документы сразу после создания интерактивного прототипа.
Зачем нужен интерактивный прототип? Чтобы заказчики, не являющиеся специалистами в разработке, могли посмотреть и пощупать проект ещё даже до этапа дизайна. И подтвердить, что это именно то, что им нужно. Обычно заказчикам не нужно долго объяснять, что это такое и какую это несёт пользу для общего дела, и они покупают у нас проектирование.
Допустим, прототип обошёлся в 150 000 рублей. Функциональная спецификация ещё в 150 000 рублей. Итого 300 000 рублей. С этой документацией заказчик идёт к своему программисту и тот делает уже точную оценку. И оказывается, что все хотелки клиента стоят не два миллиона, о которых раньше шла речь, а десять-пятнадцать. И разрабатывать это придётся не меньше года-двух.
Клиент вздыхает и решает пока не делать проект. Проектная документация уходит в стол. Так за 300 000 рублей можно предотвратить потерю двух миллионов рублей и вернуться к этому вопросу позже, когда появятся деньги. Либо пересмотреть свой подход к проекту. Например, избавиться от 90% функций для того, чтобы создать mvp и проверить жизнеспособность бизнес-гипотезы. Но это уже совсем другая история.
Я лично столкнулся с десятком случаев, когда клиенты ввязываются в разработку без проектной документации и в какой-то момент у них заканчиваются деньги, а у разработчика силы. Обычно речь идёт о небольших индивидуальных проектах ценой до миллиона, но суть та же. Проектирование, которое можно вместить в 100-тысячный бюджет, в разы повышает шанс на доведение дела до конца.
Раньше мы расстраивались, когда очередной прототип уходил «в стол» и разработка по нему не велась. А сейчас понимаем, что это нормально. Что мы спасли клиента от затяжной тупиковой разработки, где в какой-то момент закончатся деньги, и проект умрёт.
Напоследок, справедливости ради, хочется отметить, что иногда проекты уходят в стол и по другим причинам. Например, все участники посмотрели на то, что получилось, и поняли, что идея оказалась какой-то шляпой и не стоит её разрабатывать. Бывало и такое, что идея норм, прототип норм, ресурсов выше крыши, а руки просто не доходят до запуска этого дела в разработку. Или нет человека, которого можно зарядить деньгами и отправить курировать проект, а у самого клиента уже нет на это личных ресурсов.
Заметка по моей фрилансерской деятельности
У меня сейчас два потенциальных входящих клиента на проектирование интерфейсов. Оба — от студий, с которыми я уже лет десять как поддерживаю отношения. Одна — питерская, другая — московская. Стоимости в тексте ниже я взял из головы после первичной оценки, без какой-либо детализации.
Первый проект — веб-сервис + мобильное приложение, тысяч на 100-150 рублей. По срокам — до месяца на всё (когда я говорю «всё», то имею в виду и создание интерактивного прототипа в Axure, и написание технической документации). Вероятность того, что он пойдёт в работу — 30%.
На подготовку функциональных требований (это что-то типа ТЗ) и точную оценку работ мне нужно около двух часов переговоров и около часа работы. Смотря на эти цифры, я готов рискнуть этим своим временем и поработать на подготовительном этапе бесплатно. Эти часы я возьму из своих прогулок и развлечений.
Второй проект — CRM для узкой аудитории. 20-30% функций — уникальны даже для меня. Предметная область мне мало знакома, поэтому большую часть работы займёт именно погружение и обучение, а не разработка прототипов. Вероятность того, что он пойдёт в работу — до 5% (по опыту взаимодействия с этой студией за последние пять лет). Времени на подготовку функциональных требований и оценку понадобится от семи до десяти часов. Здесь, скорее всего, будет работы на 400-700 тысяч рублей и до трёх месяцев. Оценку проектирования этого проекта я сделаю бесплатно, только если сработают два фактора:
1. В моём графике будет достаточно свободного времени в ближайшую неделю, чтобы своровать оттуда эти часы;
2. Не будет возникать никаких организационных помех моей работе. А работа будет заключаться в четырёх-пяти часах общения с финальным клиентом, а затем в согласовании с ним документа с функциональными требованиями к проекту.
Если эти два фактора не сработают, то придётся делать коммерческое предложение на составление коммерческого предложения, как бы странно это ни звучало. Эти свои семь-десять часов я оценю в 10-15 тысяч рублей. Вероятность того, что мне согласятся за них заплатить — 20%.
Кстати, если бы это был прямой клиент, а не студия, вероятность была бы ближе к 100%. У студий свои механизмы продаж и клиенты приходят к ним за готовым продуктом, я же продаю лишь часть производственного процесса — проектирование — и могу точно и без недомолвок объяснить клиенту выгоду каждого из своих действий для общего дела.
Поэтому студия мне платит либо из своих денег, либо из денег клиента, который уже готов приступать к сотрудничеству по проекту целиком (а там речь идёт о многомиллионных чеках) и внёс предоплату. В первом случае студиям жалко платить даже 15 тысяч, т.к. высок риск их не вернуть. А во втором случае… такого почти не бывает, потому что оценка разработки всего проекта как раз и делается на основе проектирования :)
В начале пути я мог позволить себе назвать вот эти предварительные интуитивные цены и приступить к работе без детальной оценки. При этом шанс ошибиться у меня тогда был в десятки раз выше из-за отсутствия опыта. Сегодня же, после того, как я стал довольно хорошо понимать объёмы работ и ценообразование, я так не рискую, понимая что рано или поздно столкнусь с проектом, в котором ошибусь в цене и сроках в несколько раз.
Предвосхищаю один из ваших вопросов: параллельно я могу делать до трёх таких проектов. Четвёртый уже уходил бы в очередь. Раньше, когда у меня не было семьи, ребёнка и своих проектов, я мог вести до шести проектов сразу.
У меня сейчас два потенциальных входящих клиента на проектирование интерфейсов. Оба — от студий, с которыми я уже лет десять как поддерживаю отношения. Одна — питерская, другая — московская. Стоимости в тексте ниже я взял из головы после первичной оценки, без какой-либо детализации.
Первый проект — веб-сервис + мобильное приложение, тысяч на 100-150 рублей. По срокам — до месяца на всё (когда я говорю «всё», то имею в виду и создание интерактивного прототипа в Axure, и написание технической документации). Вероятность того, что он пойдёт в работу — 30%.
На подготовку функциональных требований (это что-то типа ТЗ) и точную оценку работ мне нужно около двух часов переговоров и около часа работы. Смотря на эти цифры, я готов рискнуть этим своим временем и поработать на подготовительном этапе бесплатно. Эти часы я возьму из своих прогулок и развлечений.
Второй проект — CRM для узкой аудитории. 20-30% функций — уникальны даже для меня. Предметная область мне мало знакома, поэтому большую часть работы займёт именно погружение и обучение, а не разработка прототипов. Вероятность того, что он пойдёт в работу — до 5% (по опыту взаимодействия с этой студией за последние пять лет). Времени на подготовку функциональных требований и оценку понадобится от семи до десяти часов. Здесь, скорее всего, будет работы на 400-700 тысяч рублей и до трёх месяцев. Оценку проектирования этого проекта я сделаю бесплатно, только если сработают два фактора:
1. В моём графике будет достаточно свободного времени в ближайшую неделю, чтобы своровать оттуда эти часы;
2. Не будет возникать никаких организационных помех моей работе. А работа будет заключаться в четырёх-пяти часах общения с финальным клиентом, а затем в согласовании с ним документа с функциональными требованиями к проекту.
Если эти два фактора не сработают, то придётся делать коммерческое предложение на составление коммерческого предложения, как бы странно это ни звучало. Эти свои семь-десять часов я оценю в 10-15 тысяч рублей. Вероятность того, что мне согласятся за них заплатить — 20%.
Кстати, если бы это был прямой клиент, а не студия, вероятность была бы ближе к 100%. У студий свои механизмы продаж и клиенты приходят к ним за готовым продуктом, я же продаю лишь часть производственного процесса — проектирование — и могу точно и без недомолвок объяснить клиенту выгоду каждого из своих действий для общего дела.
Поэтому студия мне платит либо из своих денег, либо из денег клиента, который уже готов приступать к сотрудничеству по проекту целиком (а там речь идёт о многомиллионных чеках) и внёс предоплату. В первом случае студиям жалко платить даже 15 тысяч, т.к. высок риск их не вернуть. А во втором случае… такого почти не бывает, потому что оценка разработки всего проекта как раз и делается на основе проектирования :)
В начале пути я мог позволить себе назвать вот эти предварительные интуитивные цены и приступить к работе без детальной оценки. При этом шанс ошибиться у меня тогда был в десятки раз выше из-за отсутствия опыта. Сегодня же, после того, как я стал довольно хорошо понимать объёмы работ и ценообразование, я так не рискую, понимая что рано или поздно столкнусь с проектом, в котором ошибусь в цене и сроках в несколько раз.
Предвосхищаю один из ваших вопросов: параллельно я могу делать до трёх таких проектов. Четвёртый уже уходил бы в очередь. Раньше, когда у меня не было семьи, ребёнка и своих проектов, я мог вести до шести проектов сразу.
Как документ назовёшь…
…так его потом и найдёшь!
Один из этапов моей работы — составление документа с функциональными требованиями к проекту. И поначалу я их называл примерно так: «Функциональные требования к приложению Нэмо». Храню я их в гугл.доках и в отдельных папках на своём компе.
Через какое-то время я понял, что функциональные требования в заголовке можно сократить до «ФТ». Более короткие названия лучше умещались во вьюпортах и в них было проще ориентироваться: «ФТ к приложению Нэмо».
Ещё через какое-то время документов поднакопилось и я стал всё чаще по ним искать, когда нужно было продемонстрировать новому клиенту что-то из своего портфолио. Я не держал в голове все названия проектов, поэтому мне было проще всего отфильтровать список по слову ФТ — и пробежаться по нему глазами.
Но с моим подходом все названия начинались на «ФТ». От этого было мало толку. Я сделал правильные выводы и с того момента называю документы так: «Нэмо, ФТ». Здесь не осталось ничего лишнего, название проекта на первом месте, а также есть атрибут, по которому можно отфильтровать список. Например, у функциональных спецификаций атрибут «ФС».
…так его потом и найдёшь!
Один из этапов моей работы — составление документа с функциональными требованиями к проекту. И поначалу я их называл примерно так: «Функциональные требования к приложению Нэмо». Храню я их в гугл.доках и в отдельных папках на своём компе.
Через какое-то время я понял, что функциональные требования в заголовке можно сократить до «ФТ». Более короткие названия лучше умещались во вьюпортах и в них было проще ориентироваться: «ФТ к приложению Нэмо».
Ещё через какое-то время документов поднакопилось и я стал всё чаще по ним искать, когда нужно было продемонстрировать новому клиенту что-то из своего портфолио. Я не держал в голове все названия проектов, поэтому мне было проще всего отфильтровать список по слову ФТ — и пробежаться по нему глазами.
Но с моим подходом все названия начинались на «ФТ». От этого было мало толку. Я сделал правильные выводы и с того момента называю документы так: «Нэмо, ФТ». Здесь не осталось ничего лишнего, название проекта на первом месте, а также есть атрибут, по которому можно отфильтровать список. Например, у функциональных спецификаций атрибут «ФС».
«Готов поставить на это свои деньги»
Сегодня общался с потенциальным клиентом в гугл.мит. На встрече были три представителя заказчика и ваш покорный слуга. Обсуждали проектирование небольшого модуля бронирования, тиражируемого в качестве saas (это когда клиенты платят за доступ к какому-либо онлайн-сервису, например Кинопоиск или Тильда).
«На лету» обозначил «пальцем в небо» сроки своего этапа: два месяца и одна неделя (категорически не рекомендую называть сроки «на лету», но вот иногда позволяю себе такое). За прототип и функциональную спецификацию. Разумеется, с оговоркой, что точная оценка будет только после составления функциональных требований. Участники встречи посчитали, что это довольно большой срок и заявили, что рассчитывают потратить на разработку (после проектирования) два с половиной месяца.
И тогда я сказал примерно следующее: «Готов поставить свои деньги, что раньше, чем за восемь месяцев, вы не управитесь. С учётом того, что я предоставлю вам высокодетализированный прототип и проектную документацию».
Разумеется, я назвал восемь месяцев в связке с «поставлю деньги», потому что если бы не последний нюанс, я бы, скорее ориентировался на год-полтора.
И тут впервые произошло то, чего не происходило ни разу до этого. Клиент такой: «А сколько готовы поставить?»
Я задумался и ответил: «Тридцать тысяч». Клиент: «О, круто, у нас теперь будет дополнительная мотивация сделать всё побыстрее!»
Разумеется, мы всё это свели к шутке. Я объяснил заказчику, что был бы очень рад, если бы они сумели справиться в столь сжатые сроки, просто за свою карьеру ни разу не встречал таких производительных команд. А вот заявлений о том, что проект будет сделан к определённой дате, слышал очень много. И буду только счастлив, если эта статистика, наконец, нарушится.
Был ли я полностью уверен в нереальности сроков, ставя свои деньги? Да! Заплатил бы я 30к, если бы у клиента получилось? Да без вопросов! Я считаю, что контакт с командой, которая способна на такое, стоит гораздо больше.
Сегодня общался с потенциальным клиентом в гугл.мит. На встрече были три представителя заказчика и ваш покорный слуга. Обсуждали проектирование небольшого модуля бронирования, тиражируемого в качестве saas (это когда клиенты платят за доступ к какому-либо онлайн-сервису, например Кинопоиск или Тильда).
«На лету» обозначил «пальцем в небо» сроки своего этапа: два месяца и одна неделя (категорически не рекомендую называть сроки «на лету», но вот иногда позволяю себе такое). За прототип и функциональную спецификацию. Разумеется, с оговоркой, что точная оценка будет только после составления функциональных требований. Участники встречи посчитали, что это довольно большой срок и заявили, что рассчитывают потратить на разработку (после проектирования) два с половиной месяца.
И тогда я сказал примерно следующее: «Готов поставить свои деньги, что раньше, чем за восемь месяцев, вы не управитесь. С учётом того, что я предоставлю вам высокодетализированный прототип и проектную документацию».
Разумеется, я назвал восемь месяцев в связке с «поставлю деньги», потому что если бы не последний нюанс, я бы, скорее ориентировался на год-полтора.
И тут впервые произошло то, чего не происходило ни разу до этого. Клиент такой: «А сколько готовы поставить?»
Я задумался и ответил: «Тридцать тысяч». Клиент: «О, круто, у нас теперь будет дополнительная мотивация сделать всё побыстрее!»
Разумеется, мы всё это свели к шутке. Я объяснил заказчику, что был бы очень рад, если бы они сумели справиться в столь сжатые сроки, просто за свою карьеру ни разу не встречал таких производительных команд. А вот заявлений о том, что проект будет сделан к определённой дате, слышал очень много. И буду только счастлив, если эта статистика, наконец, нарушится.
Был ли я полностью уверен в нереальности сроков, ставя свои деньги? Да! Заплатил бы я 30к, если бы у клиента получилось? Да без вопросов! Я считаю, что контакт с командой, которая способна на такое, стоит гораздо больше.
Портфолио проектировщика интерфейсов
Когда я задумался над созданием своего портфолио проектировщика интерфейсов, у меня в нём уже было несколько десятков работ. И решил, что круче всего будет брать количеством, а не качеством.
Я не стал заморачиваться с описанием каждого кейса: что там было сделано, сколько стоило, чем всё закончилось. А просто сформировал список ссылок на прототипы, который со временем должен был расти вниз.
Что самое смешное: в какой-то момент сверстал я этот список, опубликовал, а потом забил на него. И за все эти годы я сделал всего два подхода к обновлению своего портфолио. И там, где могло быть показано три сотни работ, до сих пор висят жалкие 32 проекта.
Но сегодня великий день! Я опубликовал в портфолио самый настоящий кейс! Правда, ещё не придумал, как теперь организовать ссылки по-новому, чтобы сделать акцент не на количестве, а на качестве.
Плюс наплодил себе задач на будущее. Сделать страницы с карточками участников проектов и ссылаться на них из каждого проекта. А на самих страницах уже ссылаться на все проекты, в которых участвовал специалист.
А то что это такое? Уже 70 лет проектирую интерфейсы — а портфолио так и не сделал! Будем исправляться.
Когда я задумался над созданием своего портфолио проектировщика интерфейсов, у меня в нём уже было несколько десятков работ. И решил, что круче всего будет брать количеством, а не качеством.
Я не стал заморачиваться с описанием каждого кейса: что там было сделано, сколько стоило, чем всё закончилось. А просто сформировал список ссылок на прототипы, который со временем должен был расти вниз.
Что самое смешное: в какой-то момент сверстал я этот список, опубликовал, а потом забил на него. И за все эти годы я сделал всего два подхода к обновлению своего портфолио. И там, где могло быть показано три сотни работ, до сих пор висят жалкие 32 проекта.
Но сегодня великий день! Я опубликовал в портфолио самый настоящий кейс! Правда, ещё не придумал, как теперь организовать ссылки по-новому, чтобы сделать акцент не на количестве, а на качестве.
Плюс наплодил себе задач на будущее. Сделать страницы с карточками участников проектов и ссылаться на них из каждого проекта. А на самих страницах уже ссылаться на все проекты, в которых участвовал специалист.
А то что это такое? Уже 70 лет проектирую интерфейсы — а портфолио так и не сделал! Будем исправляться.
Экономическое обоснование работы
Можно озвучить две крайности при проектировании интерфейсов.
1. Вообще ничего не проектировать. В двух словах описать задачу, набросать на салфетке эскизы и отдать программистам, чтобы что-нибудь поскорее сделали. Предоставить разработчикам максимальную самостоятельность — лишь бы выполнялась основная функция проекта.
Такой подход хорошо сработает, когда нужно быстро проверить простую гипотезу и заранее знаешь, что даже в случае успеха всё нужно будет неоднократно переделать. Когда проект настолько маленький, что работа по проектированию скорее замедлит движение к результату, чем поможет избежать правок на этапе разработки.
2. Досконально всё спроектировать. Согласовать интерфейсы и документацию со всеми участниками проекта, составить точный календарный план работы. Давать разработчикам минимум свободы выбора решений.
Этот подход хорош в уже существующих проектах, которые нужно доработать. Или в новых проектах, которые нужно выполнить строго в соответствии с запросом, а не проверять гипотезы, будет оно работать или нет (например, когда нужно автоматизировать производственные процессы на каком-нибудь предприятии).
Между этими двумя подходами существует множество промежуточных вариантов. В зависимости от обстоятельств необходимо определиться, какой из них больше подойдёт с экономической точки зрения:
1. Не тратить много ресурсов на проектирование, потому что правки на этапе разработки стоят недорого (небольшой проект, мало разработчиков, тестирование гипотез), а подробное проектирование только замедлит процесс.
2. Тратить много ресурсов на проектирование, потому что на этапе разработки каждая правка может стоить значительно дороже, чем месяц работы проектировщика (большой растянутый во времени проект, команда разработчиков с большим ежемесячным фондом оплаты труда, нужен конкретный результат, а не перебор гипотез).
Я предлагаю клиентам ту методологию и детализацию проектирования, которая лучше всего подойдёт в каждом конкретном случае с точки зрения экономики проекта, а не топлю за что-то конкретное, к чему привык в процессе работы над первыми задачами.
В остальных профессиях примерно та же история. Выбор способа решения задачи должен быть экономически обоснован. И грустно, когда специалисты предлагают привычный способ ведения дел клиентам, для которых это будет необоснованной тратой ресурсов. Ведь клиенты зачастую не могут самостоятельно сделать правильный выбор.
Можно озвучить две крайности при проектировании интерфейсов.
1. Вообще ничего не проектировать. В двух словах описать задачу, набросать на салфетке эскизы и отдать программистам, чтобы что-нибудь поскорее сделали. Предоставить разработчикам максимальную самостоятельность — лишь бы выполнялась основная функция проекта.
Такой подход хорошо сработает, когда нужно быстро проверить простую гипотезу и заранее знаешь, что даже в случае успеха всё нужно будет неоднократно переделать. Когда проект настолько маленький, что работа по проектированию скорее замедлит движение к результату, чем поможет избежать правок на этапе разработки.
2. Досконально всё спроектировать. Согласовать интерфейсы и документацию со всеми участниками проекта, составить точный календарный план работы. Давать разработчикам минимум свободы выбора решений.
Этот подход хорош в уже существующих проектах, которые нужно доработать. Или в новых проектах, которые нужно выполнить строго в соответствии с запросом, а не проверять гипотезы, будет оно работать или нет (например, когда нужно автоматизировать производственные процессы на каком-нибудь предприятии).
Между этими двумя подходами существует множество промежуточных вариантов. В зависимости от обстоятельств необходимо определиться, какой из них больше подойдёт с экономической точки зрения:
1. Не тратить много ресурсов на проектирование, потому что правки на этапе разработки стоят недорого (небольшой проект, мало разработчиков, тестирование гипотез), а подробное проектирование только замедлит процесс.
2. Тратить много ресурсов на проектирование, потому что на этапе разработки каждая правка может стоить значительно дороже, чем месяц работы проектировщика (большой растянутый во времени проект, команда разработчиков с большим ежемесячным фондом оплаты труда, нужен конкретный результат, а не перебор гипотез).
Я предлагаю клиентам ту методологию и детализацию проектирования, которая лучше всего подойдёт в каждом конкретном случае с точки зрения экономики проекта, а не топлю за что-то конкретное, к чему привык в процессе работы над первыми задачами.
В остальных профессиях примерно та же история. Выбор способа решения задачи должен быть экономически обоснован. И грустно, когда специалисты предлагают привычный способ ведения дел клиентам, для которых это будет необоснованной тратой ресурсов. Ведь клиенты зачастую не могут самостоятельно сделать правильный выбор.
Самый длинный email
Самый длинный email может включать в себя 319 символов. 64 — это количество символов до собаки, плюс считаем саму собаку, а после собаки — ещё 254 символа (это уже максимальная длина для доменного имени).
Визуально это выглядит как-то так:
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO@OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO.com
Программисты и системные аналитики это обычно знают. А вы теперь тоже знаете, если не знали раньше.
UPD
А затем приходит RFC 2821 и ограничивает емейл приёмом только 254 символов…
Самый длинный email может включать в себя 319 символов. 64 — это количество символов до собаки, плюс считаем саму собаку, а после собаки — ещё 254 символа (это уже максимальная длина для доменного имени).
Визуально это выглядит как-то так:
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO@OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO.com
Программисты и системные аналитики это обычно знают. А вы теперь тоже знаете, если не знали раньше.
UPD
А затем приходит RFC 2821 и ограничивает емейл приёмом только 254 символов…
Ошибся со сроками
Сделал длинную паузу в проектировании на заказ. Заржавел. При оценке нового проекта неправильно оценил ситуацию и назвал срок в 10 календарных дней, хотя следовало назвать побольше.
Проект — интернет-магазин стеклоочистителей. Процесс работы был выстроен как обычно: в течение 48 часов после начала работ показал первый промежуточный результат, а затем короткими итерациями двигались к цели. В какой-то момент возникла пауза в общении в несколько дней (у клиента были дела). И за два дня до окончания срока я понял, что, двигаясь в таком же темпе, мы не успеем.
Как только я это понял — тут же предупредил об этом всех участников проекта. Формулировка была такая: «Мы не успеваем в сроки, указанные в договоре. Я могу сделать рывок и формально доделать задачу к сроку без дополнительных промежуточных переговоров. А можем двигаться, как двигались, но тогда проект будет сдан позже».
Клиент с этих слов посмеялся и сказал: «Нам нужно ехать, а не шашечки, поэтому ничего страшного, продолжаем работать, как работали».
И вот примерно так и срываются сроки, когда работа прозрачная, все знают о том, в какой стадии проект и что ждёт впереди. Спокойно, мирно и комфортно для всех.
Что я мог сделать, чтобы ситуация стала неприятной:
— Вообще не говорить о срыве сроков. Просто продолжать действовать так же, как и раньше. Сдать проект с задержкой и вести себя так, будто так и было задумано. Уверен, что клиент мне бы и слова не сказал. Но он бы точно отметил, что я формально не выдержал своих обязательств и что в будущем от меня можно ожидать какой-нибудь подставы;
— Не предупреждать о срыве сроков заранее. Написать за час до сдачи проекта, что, мол, сорян, не укладываемся. Это было бы довольно глупо. Вроде и предупредил, а вроде кому нужно это предупреждение в самый последний момент, когда уже ничего не успеешь с ним сделать?
Сделал длинную паузу в проектировании на заказ. Заржавел. При оценке нового проекта неправильно оценил ситуацию и назвал срок в 10 календарных дней, хотя следовало назвать побольше.
Проект — интернет-магазин стеклоочистителей. Процесс работы был выстроен как обычно: в течение 48 часов после начала работ показал первый промежуточный результат, а затем короткими итерациями двигались к цели. В какой-то момент возникла пауза в общении в несколько дней (у клиента были дела). И за два дня до окончания срока я понял, что, двигаясь в таком же темпе, мы не успеем.
Как только я это понял — тут же предупредил об этом всех участников проекта. Формулировка была такая: «Мы не успеваем в сроки, указанные в договоре. Я могу сделать рывок и формально доделать задачу к сроку без дополнительных промежуточных переговоров. А можем двигаться, как двигались, но тогда проект будет сдан позже».
Клиент с этих слов посмеялся и сказал: «Нам нужно ехать, а не шашечки, поэтому ничего страшного, продолжаем работать, как работали».
И вот примерно так и срываются сроки, когда работа прозрачная, все знают о том, в какой стадии проект и что ждёт впереди. Спокойно, мирно и комфортно для всех.
Что я мог сделать, чтобы ситуация стала неприятной:
— Вообще не говорить о срыве сроков. Просто продолжать действовать так же, как и раньше. Сдать проект с задержкой и вести себя так, будто так и было задумано. Уверен, что клиент мне бы и слова не сказал. Но он бы точно отметил, что я формально не выдержал своих обязательств и что в будущем от меня можно ожидать какой-нибудь подставы;
— Не предупреждать о срыве сроков заранее. Написать за час до сдачи проекта, что, мол, сорян, не укладываемся. Это было бы довольно глупо. Вроде и предупредил, а вроде кому нужно это предупреждение в самый последний момент, когда уже ничего не успеешь с ним сделать?
Сезонность в работе
В моей профессии (проектировщик интерфейсов, UX-дизайнер) я наблюдаю такую сезонность:
Июнь, июль — самое глухое время. Кто-то в отпусках, кто-то не хочет работать из-за хорошей погоды. Обычно в этот период я начинаю нервничать, тратить финансовую подушку безопасности и искать побольше новых заказов. Пока начальники в отпусках, переговоры ведутся с менеджерами разных звеньев, готовимся к сделкам в конце лета.
Август, сентябрь — увеличение количества заказов. Народ возвращается к работе, вечера становятся длиннее и темнее, уходит жара. Появляются проекты, которые надо «сделать до Нового года» (что почти всегда нереально). Именно в эти месяцы начинает проявляться эффект от июньского поиска заказов.
Октябрь, ноябрь — пик по количеству работы. Все те клиенты, которых так активно искал летом, внезапно приходят целой гурьбой и хотят срочно что-то запустить. Причём, чем ближе Новый год, тем выше срочность.
Декабрь — много входящих проектов, но если они не пойдут в работу до середины месяца, то за пару недель перед Новым годом, они все могут исчезнуть до февраля. В октябре, ноябре и декабре компании, у которых остались неосвоенные бюджеты, стараются их освоить. Часто это вложения в рекламу и подготовка к предновогоднему ажиотажному времени, но и IT-сектору перепадает.
Январь. Тут либо взял несколько проектов ещё в начале декабря, получил по ним предоплату перед НГ и спокойненько их делаешь, либо сидишь и тратишь финансовую подушку безопасности. Причём народ просыпается не в десятых числах января. Вот уже и конец месяца, а всем не до проектов. В этот момент снова начинаешь паниковать и искать новые заказы.
Февраль. Начало нового активного сезона. Народ оправился от новогодних каникул и готов приступать к работе. Просыпаются проекты, которые исчезли в начале декабря.
Март, апрель, май. Сезон! Приходят в работу заказы, которые формировал в январе. В мае все уже потихоньку начинают расслабляться. Кажется, что проектов в работе много, поэтому к глухому июньскому времени особо не готовишься.
Что помогает спокойно переносить сезоны?
На второй-третий год работы в нише начинаешь хорошо понимать эту сезонность и готовиться к ней заранее: ищешь заказы не в июне или январе, когда всё плохо, а постоянно, даже когда завален работой. Обеспечиваешь спрос, превышающий предложение.
Работаешь с финансовой подушкой безопасности и рассчитываешь траты в соответствии с сезонами. Например, не входишь в раж и не тратишь все деньги перед Новым годом, а готовишься к тому, чтобы протянуть на этот объём в течение следующих двух месяцев, не рассчитывая на входящие заказы (хотя при этом и постоянно работая над тем, чтобы они были).
В моей профессии (проектировщик интерфейсов, UX-дизайнер) я наблюдаю такую сезонность:
Июнь, июль — самое глухое время. Кто-то в отпусках, кто-то не хочет работать из-за хорошей погоды. Обычно в этот период я начинаю нервничать, тратить финансовую подушку безопасности и искать побольше новых заказов. Пока начальники в отпусках, переговоры ведутся с менеджерами разных звеньев, готовимся к сделкам в конце лета.
Август, сентябрь — увеличение количества заказов. Народ возвращается к работе, вечера становятся длиннее и темнее, уходит жара. Появляются проекты, которые надо «сделать до Нового года» (что почти всегда нереально). Именно в эти месяцы начинает проявляться эффект от июньского поиска заказов.
Октябрь, ноябрь — пик по количеству работы. Все те клиенты, которых так активно искал летом, внезапно приходят целой гурьбой и хотят срочно что-то запустить. Причём, чем ближе Новый год, тем выше срочность.
Декабрь — много входящих проектов, но если они не пойдут в работу до середины месяца, то за пару недель перед Новым годом, они все могут исчезнуть до февраля. В октябре, ноябре и декабре компании, у которых остались неосвоенные бюджеты, стараются их освоить. Часто это вложения в рекламу и подготовка к предновогоднему ажиотажному времени, но и IT-сектору перепадает.
Январь. Тут либо взял несколько проектов ещё в начале декабря, получил по ним предоплату перед НГ и спокойненько их делаешь, либо сидишь и тратишь финансовую подушку безопасности. Причём народ просыпается не в десятых числах января. Вот уже и конец месяца, а всем не до проектов. В этот момент снова начинаешь паниковать и искать новые заказы.
Февраль. Начало нового активного сезона. Народ оправился от новогодних каникул и готов приступать к работе. Просыпаются проекты, которые исчезли в начале декабря.
Март, апрель, май. Сезон! Приходят в работу заказы, которые формировал в январе. В мае все уже потихоньку начинают расслабляться. Кажется, что проектов в работе много, поэтому к глухому июньскому времени особо не готовишься.
Что помогает спокойно переносить сезоны?
На второй-третий год работы в нише начинаешь хорошо понимать эту сезонность и готовиться к ней заранее: ищешь заказы не в июне или январе, когда всё плохо, а постоянно, даже когда завален работой. Обеспечиваешь спрос, превышающий предложение.
Работаешь с финансовой подушкой безопасности и рассчитываешь траты в соответствии с сезонами. Например, не входишь в раж и не тратишь все деньги перед Новым годом, а готовишься к тому, чтобы протянуть на этот объём в течение следующих двух месяцев, не рассчитывая на входящие заказы (хотя при этом и постоянно работая над тем, чтобы они были).
С одного из моих онлайн-занятий по проектированию интерфейсов. Третий поток…
— Сейчас будем учиться декомпозиции.
Открываю первый попавшийся сайт в Интернете.
— Смотрите: почти любой сайт в Интернете состоит из трёх основных частей: шапки, контентной области и подвала. Иногда этот состав может чем-то дополняться, например, вертикальным меню навигации, не являющимся частью шапки. Поняли? Давайте поупражняемся.
Открываю новый случайный сайт.
— Из чего состоит этот сайт, Олеся?
— Этот сайт состоит из логотипа, переключалки языков, пунктов меню…
— Постой, постой! Давай вспомним, что я объяснял, и попробуем всё упростить. Сайт состоит из шапки, контентной области и подвала. Давай ещё раз: из чего состоит этот сайт?
— Этот сайт состоит из шапки, контентной области и подвала.
— Молодец!
Открываю очередной сайт.
— Из чего состоит этот сайт, Максим?
— Этот сайт состоит из…
— Погоди, Максим. Друзья, представьте себе, что встретили на улице знакомого с прозрачным пакетом помидоров. И спрашиваете у него: «Что у тебя в пакете?». Будет немного странно, если он ответит: «У меня в пакете помидоры». Гораздо проще и быстрее ответить: «Помидоры. Ты что, слепой?».
Студенты захихикали.
— Итак, из чего состоит этот сайт, Максим?
— Этот сайт состоит из… Эээ, прошу прощения.
Снова доброжелательный смех.
— Из логотипа, выбора региона, меню навигации, заголовка…
— …
——
На том занятии я глубоко осознал, что в рамках своей профессии воспринимаю мир не так, как окружающие. Я на автомате всё систематизирую для того, чтобы в случае нужды было легче анализировать происходящее и быстрее добираться до нужной информации.
Каждый сайт действительно состоит из шапки, контентной области и подвала. Шапка состоит из логотипа, основного меню навигации, пользовательского меню навигации и, например, блока с контактной информацией. Основное меню навигации состоит из пунктов таких-то, обладающих такими-то свойствами.
Когда есть такая иерархия и вложенность, гораздо проще удерживать её в уме. Описывать составные части сайта так же, как мои студенты — это всё равно что на вопрос «из чего состоит человек» начать перечислять атомы и молекулы.
Из чего состоит человек? Из головы, туловища, ручек и ножек. Когда эта информация уложилась в голове, добавляем, что есть ещё шея, с помощью которой голова соединяется с туловищем. Разобравшись с тем, на сколько градусов можно вертеть головой и в какую сторону сгибаются ручки и ножки, можно продолжать углубляться в суть вопроса. Но не наоборот. Не стоит начинать с зубов.
Попробуйте сами.
Из чего состоит автомобиль?Из колёс и кузова.
Из чего состоит дерево? Из ствола, ветвей и корней. Легко забыть про корни. И легко назвать ветви кроной. Но не у всех деревьев и не всегда есть листья.
Из чего состоит пост в Телеграме? Из заголовка и тела поста.
Такой системный образ мышления позволяет также более легко ответить, например, на вопросы в какой срок будет выполнена та или иная работа, из чего будут состоять переговоры или какую информацию необходимо запросить у клиента, чтобы выполнить задачу.
— Сейчас будем учиться декомпозиции.
Открываю первый попавшийся сайт в Интернете.
— Смотрите: почти любой сайт в Интернете состоит из трёх основных частей: шапки, контентной области и подвала. Иногда этот состав может чем-то дополняться, например, вертикальным меню навигации, не являющимся частью шапки. Поняли? Давайте поупражняемся.
Открываю новый случайный сайт.
— Из чего состоит этот сайт, Олеся?
— Этот сайт состоит из логотипа, переключалки языков, пунктов меню…
— Постой, постой! Давай вспомним, что я объяснял, и попробуем всё упростить. Сайт состоит из шапки, контентной области и подвала. Давай ещё раз: из чего состоит этот сайт?
— Этот сайт состоит из шапки, контентной области и подвала.
— Молодец!
Открываю очередной сайт.
— Из чего состоит этот сайт, Максим?
— Этот сайт состоит из…
— Погоди, Максим. Друзья, представьте себе, что встретили на улице знакомого с прозрачным пакетом помидоров. И спрашиваете у него: «Что у тебя в пакете?». Будет немного странно, если он ответит: «У меня в пакете помидоры». Гораздо проще и быстрее ответить: «Помидоры. Ты что, слепой?».
Студенты захихикали.
— Итак, из чего состоит этот сайт, Максим?
— Этот сайт состоит из… Эээ, прошу прощения.
Снова доброжелательный смех.
— Из логотипа, выбора региона, меню навигации, заголовка…
— …
——
На том занятии я глубоко осознал, что в рамках своей профессии воспринимаю мир не так, как окружающие. Я на автомате всё систематизирую для того, чтобы в случае нужды было легче анализировать происходящее и быстрее добираться до нужной информации.
Каждый сайт действительно состоит из шапки, контентной области и подвала. Шапка состоит из логотипа, основного меню навигации, пользовательского меню навигации и, например, блока с контактной информацией. Основное меню навигации состоит из пунктов таких-то, обладающих такими-то свойствами.
Когда есть такая иерархия и вложенность, гораздо проще удерживать её в уме. Описывать составные части сайта так же, как мои студенты — это всё равно что на вопрос «из чего состоит человек» начать перечислять атомы и молекулы.
Из чего состоит человек? Из головы, туловища, ручек и ножек. Когда эта информация уложилась в голове, добавляем, что есть ещё шея, с помощью которой голова соединяется с туловищем. Разобравшись с тем, на сколько градусов можно вертеть головой и в какую сторону сгибаются ручки и ножки, можно продолжать углубляться в суть вопроса. Но не наоборот. Не стоит начинать с зубов.
Попробуйте сами.
Из чего состоит автомобиль?
Я стал зарабатывать вдвое больше, когда начал писать техническую документацию
Речь идёт о функциональных спецификациях к сайтам, приложениям и прочим информационным системам.
В начале карьеры я просто делал интерактивные прототипы, а документацию предпочитал не писать. Почему так:
— Это было сложно. Этому навыку никто не обучал, а написать 100 и более страниц текста по проекту — это как диссертацию накатать. Поэтому я говорил клиентам, что, мол, и так справитесь :)
— У меня не было опыта в роли заказчика. И только после того, как я на собственном проекте увидел, сколько денег экономит этот документ, стал предлагать его каждому новому клиенту.
Продавать это было легко. Достаточно было рассказать о том, как я, заплатив несколько десятков тысяч за документ, экономил несколько сотен тысяч на разработке. И подкрепить рассказ конкретными цифрами и примерами.
Также со временем я научился писать документацию так, что это перестало казаться сложным. Не осталось непонятных моментов, формат устаканился.
В итоге обе причины, почему я предпочитал не писать функциональные спецификации, были устранены.
Стоимость документа примерно равна стоимости создания интерактивного прототипа. Поэтому теперь там, где я раньше зарабатывал 200 000 рублей, я начал зарабатывать 400 000. Так что технически это удвоило мой доход за счёт повышения среднего чека с одного клиента в два раза. Если до этого я не был загружен на 100%, то теперь был. Плюс средний проект растягивался во времени, и мне не приходилось слишком часто переключаться между разными направлениями.
Пример функциональной спецификации показываю в ролике и рассказываю о куче нюансов, которые позволяют мне экономить время на её создание.
Если информация окажется для вас ценной — буду рад лайкам, комментариям и прочей поддержке на Ютубе. В этом году она мне понадобится.
Речь идёт о функциональных спецификациях к сайтам, приложениям и прочим информационным системам.
В начале карьеры я просто делал интерактивные прототипы, а документацию предпочитал не писать. Почему так:
— Это было сложно. Этому навыку никто не обучал, а написать 100 и более страниц текста по проекту — это как диссертацию накатать. Поэтому я говорил клиентам, что, мол, и так справитесь :)
— У меня не было опыта в роли заказчика. И только после того, как я на собственном проекте увидел, сколько денег экономит этот документ, стал предлагать его каждому новому клиенту.
Продавать это было легко. Достаточно было рассказать о том, как я, заплатив несколько десятков тысяч за документ, экономил несколько сотен тысяч на разработке. И подкрепить рассказ конкретными цифрами и примерами.
Также со временем я научился писать документацию так, что это перестало казаться сложным. Не осталось непонятных моментов, формат устаканился.
В итоге обе причины, почему я предпочитал не писать функциональные спецификации, были устранены.
Стоимость документа примерно равна стоимости создания интерактивного прототипа. Поэтому теперь там, где я раньше зарабатывал 200 000 рублей, я начал зарабатывать 400 000. Так что технически это удвоило мой доход за счёт повышения среднего чека с одного клиента в два раза. Если до этого я не был загружен на 100%, то теперь был. Плюс средний проект растягивался во времени, и мне не приходилось слишком часто переключаться между разными направлениями.
Пример функциональной спецификации показываю в ролике и рассказываю о куче нюансов, которые позволяют мне экономить время на её создание.
Если информация окажется для вас ценной — буду рад лайкам, комментариям и прочей поддержке на Ютубе. В этом году она мне понадобится.
YouTube
Живой пример документации к сайту
Демонстрация примера функциональной спецификации для интернет-магазина.
Мой Телеграм-канал: https://t.me/+RqCkc9l68eNmNGNi
Читайте мою Книгу нормального фрилансера: https://normfreelancer.ru/
--
Егор Камелев — собственник компании «Проекторат» http:…
Мой Телеграм-канал: https://t.me/+RqCkc9l68eNmNGNi
Читайте мою Книгу нормального фрилансера: https://normfreelancer.ru/
--
Егор Камелев — собственник компании «Проекторат» http:…
Приходит потенциальный клиент к разработчику…
— Мне бы сайт разработать! Можете сказать, сколько это будет стоить?
— А проектная документация у вас есть?
— Не-а.
— Она нужна для оценки. Попробуйте сходить к проектировщику интерфейсов. Возвращайтесь с проектной документацией — и я оценю разработку.
И клиент идёт к проектировщику интерфейсов. Например, ко мне.
— Мне бы сайт спроектировать! Может сказать, сколько это будет стоить?
— А задание на проектирование у вас есть?
— Не-а. Только не говорите, что опять надо к кому-то идти?!
— Нет. Давайте с вами созвонимся такого-то числа во столько-то — и я за час соберу у вас все необходимые сведения для составления этого задания. Дальше вы проверите, нигде ли я не ошибся — и если всё ок, то я смогу оценить проектирование.
Вот примерно так я обычно и создаю документы под названием «Функциональные требования» (ФТ). По ним я могу оценить объём работ по проектированию. Сегодня я записал для вас видео, в котором показываю пример такого документа и рассказываю о некоторых нюансах его подготовки.
— Мне бы сайт разработать! Можете сказать, сколько это будет стоить?
— А проектная документация у вас есть?
— Не-а.
— Она нужна для оценки. Попробуйте сходить к проектировщику интерфейсов. Возвращайтесь с проектной документацией — и я оценю разработку.
И клиент идёт к проектировщику интерфейсов. Например, ко мне.
— Мне бы сайт спроектировать! Может сказать, сколько это будет стоить?
— А задание на проектирование у вас есть?
— Не-а. Только не говорите, что опять надо к кому-то идти?!
— Нет. Давайте с вами созвонимся такого-то числа во столько-то — и я за час соберу у вас все необходимые сведения для составления этого задания. Дальше вы проверите, нигде ли я не ошибся — и если всё ок, то я смогу оценить проектирование.
Вот примерно так я обычно и создаю документы под названием «Функциональные требования» (ФТ). По ним я могу оценить объём работ по проектированию. Сегодня я записал для вас видео, в котором показываю пример такого документа и рассказываю о некоторых нюансах его подготовки.
YouTube
Живой пример требований на проектирование сайта
Обзор функциональных требований и рассказ о том, зачем они нужны, как делаются и сколько это занимает по времени.
Вебинар про вопросы для сбора ФТ: https://youtube.com/live/H4GWIbe4RoI?feature=share
Шпаргалка по составлению ФТ: https://docs.google.com/…
Вебинар про вопросы для сбора ФТ: https://youtube.com/live/H4GWIbe4RoI?feature=share
Шпаргалка по составлению ФТ: https://docs.google.com/…
У каждого додика своя методика!
За последние двадцать лет я поработал в качестве проектировщика с огромным количеством команд:
— Агентств: 10+
— Самостоятельных IT-продуктов: 50+
— Прямых клиентов сайтов, приложений и прочих информационных систем: 250+
И ни разу не встречал двух одинаковых подходов к работе. В каждой команде — свои предпочтения к методологиям. В каждой команде — свои названия должностей. А если должности и одинаковые — у каждой свои наборы компетенций и требований.
И у большинства из них дела в порядке. В конечном итоге они достигают результатов. И не важно, как называется та или иная должность, не важно, что делает тот или иной сотрудник, не важно, какие артефакты создаются на том или ином этапе работ. Если это ведёт к результату.
При этом каждая из команд считает, что их подход — самый верный и эффективный. И многие транслируют эту уверенность окружающим.
И я рад, что мне удалось посмотреть на такое большое количество команд. Это оказывает большое влияние на моё понимание рынка в целом.
Мой новый ролик — он как раз об этом. И не только.
За последние двадцать лет я поработал в качестве проектировщика с огромным количеством команд:
— Агентств: 10+
— Самостоятельных IT-продуктов: 50+
— Прямых клиентов сайтов, приложений и прочих информационных систем: 250+
И ни разу не встречал двух одинаковых подходов к работе. В каждой команде — свои предпочтения к методологиям. В каждой команде — свои названия должностей. А если должности и одинаковые — у каждой свои наборы компетенций и требований.
И у большинства из них дела в порядке. В конечном итоге они достигают результатов. И не важно, как называется та или иная должность, не важно, что делает тот или иной сотрудник, не важно, какие артефакты создаются на том или ином этапе работ. Если это ведёт к результату.
При этом каждая из команд считает, что их подход — самый верный и эффективный. И многие транслируют эту уверенность окружающим.
И я рад, что мне удалось посмотреть на такое большое количество команд. Это оказывает большое влияние на моё понимание рынка в целом.
Мой новый ролик — он как раз об этом. И не только.
YouTube
Нет единства среди айтишников
Полезные ссылки
Мой Телеграм-канал: https://t.me/+RqCkc9l68eNmNGNi
Книга нормального фрилансера: https://normfreelancer.ru/
Курс по рекламе авторского канала в Телеграме: https://telegacourse.lp151.com/
Сервис по созданию лендингов (одностраничных сайтов):…
Мой Телеграм-канал: https://t.me/+RqCkc9l68eNmNGNi
Книга нормального фрилансера: https://normfreelancer.ru/
Курс по рекламе авторского канала в Телеграме: https://telegacourse.lp151.com/
Сервис по созданию лендингов (одностраничных сайтов):…
Ох, и косячил же я поначалу с коммерческими предложениями!
Ленился и не оценивал работу сразу после того, как пообщался с клиентом. Проходило несколько дней, я отправлял заказчику коммерческое предложение, а он уже передумал делать заказ. Интересно, почему?
Оценивал «на глазок». Видел, что похожие проекты уже делал в прошлом, и называл примерно такие же цены и сроки. Ошибался почти всегда. А иногда вызывал подозрительные вопросы: «Как вы так быстро определились с ценой? Вы вообще изучали наш проект?». Интересно, почему?
Отправлял КП и ждал реакции от клиента. Предполагал, что клиент ознакомится с предложением, а потом напишет мне что-то вроде: «Замечательное предложение! Давайте готовить и подписывать договор!». Но частенько клиент не спешил писать. И не особо стремился организовывать начало сотрудничества. Интересно, почему?
Я могу довольно долго продолжать этот список. Но давайте лучше покажу вам видео, в котором рассказываю, как можно избежать всех этих неприятностей.
Ленился и не оценивал работу сразу после того, как пообщался с клиентом. Проходило несколько дней, я отправлял заказчику коммерческое предложение, а он уже передумал делать заказ. Интересно, почему?
Оценивал «на глазок». Видел, что похожие проекты уже делал в прошлом, и называл примерно такие же цены и сроки. Ошибался почти всегда. А иногда вызывал подозрительные вопросы: «Как вы так быстро определились с ценой? Вы вообще изучали наш проект?». Интересно, почему?
Отправлял КП и ждал реакции от клиента. Предполагал, что клиент ознакомится с предложением, а потом напишет мне что-то вроде: «Замечательное предложение! Давайте готовить и подписывать договор!». Но частенько клиент не спешил писать. И не особо стремился организовывать начало сотрудничества. Интересно, почему?
Я могу довольно долго продолжать этот список. Но давайте лучше покажу вам видео, в котором рассказываю, как можно избежать всех этих неприятностей.
YouTube
Как писать эффективные коммерческие предложения (КП) на сложные услуги
Полезные ссылки
Мой Телеграм-канал: https://t.me/+RqCkc9l68eNmNGNi
Книга нормального фрилансера: https://normfreelancer.ru/
Курс по рекламе авторского канала в Телеграме: https://telegacourse.lp151.com/
Сервис по созданию лендингов (одностраничных сайтов):…
Мой Телеграм-канал: https://t.me/+RqCkc9l68eNmNGNi
Книга нормального фрилансера: https://normfreelancer.ru/
Курс по рекламе авторского канала в Телеграме: https://telegacourse.lp151.com/
Сервис по созданию лендингов (одностраничных сайтов):…
Записал небольшой видеоролик с рассказом о том, как я провожу аудиты интерфейсов
Вкратце опишу схему:
— Аудит не может быть беспредметным. Предмет моих аудитов — это то, насколько эффективно интерфейс достигает поставленных перед ним целей. Поэтому первый шаг — выявить и озвучить эту самую цель (или несколько целей).
— Цели достигаются благодаря набору функций в интерфейсе. Например, если цель — продажа, а в интерфейсе нет функции оплаты заказа в рамках некой оферты — то она недостижима. И, возможно, ошибка крылась в терминологии. Например, истинная цель была не продажа, а формирование лида. Из цели можно вывести набор функциональных требований, на который и ориентироваться.
— Но даже если есть цель и все необходимые функции для её достижения, то проблема может крыться в информационных ожиданиях. Когда у пользователей интерфейса банально не хватает ответов на вопросы, которые хотелось бы получить перед принятием решения.
— И как ни парадоксально это звучит, самая маловажная составляющая моих аудитов — это как раз юзабилити, UX. Эргономика, доступность, эстетика, вот это всё. Точнее, не так. Она, конечно, важна. Но только после того, как решены предыдущие три вопроса.
В результате аудита я всегда выделяю какую-то одну рекомендацию, которая, по моему мнению, повлияет на результат больше всего. Можно перекрасить пятьдесят кнопок и расставить элементы в нужные места, а можно дать пользователю ответ на волнующий его вопрос. Например, есть ли доставка в его регион.
Приятного просмотра! #аудит
Вкратце опишу схему:
— Аудит не может быть беспредметным. Предмет моих аудитов — это то, насколько эффективно интерфейс достигает поставленных перед ним целей. Поэтому первый шаг — выявить и озвучить эту самую цель (или несколько целей).
— Цели достигаются благодаря набору функций в интерфейсе. Например, если цель — продажа, а в интерфейсе нет функции оплаты заказа в рамках некой оферты — то она недостижима. И, возможно, ошибка крылась в терминологии. Например, истинная цель была не продажа, а формирование лида. Из цели можно вывести набор функциональных требований, на который и ориентироваться.
— Но даже если есть цель и все необходимые функции для её достижения, то проблема может крыться в информационных ожиданиях. Когда у пользователей интерфейса банально не хватает ответов на вопросы, которые хотелось бы получить перед принятием решения.
— И как ни парадоксально это звучит, самая маловажная составляющая моих аудитов — это как раз юзабилити, UX. Эргономика, доступность, эстетика, вот это всё. Точнее, не так. Она, конечно, важна. Но только после того, как решены предыдущие три вопроса.
В результате аудита я всегда выделяю какую-то одну рекомендацию, которая, по моему мнению, повлияет на результат больше всего. Можно перекрасить пятьдесят кнопок и расставить элементы в нужные места, а можно дать пользователю ответ на волнующий его вопрос. Например, есть ли доставка в его регион.
Приятного просмотра! #аудит
YouTube
Аудит интерфейса / №1
Демонстрация экспресс-аудита интерфейса сайта, занимающегося продажами ландшафтных опор.
Ссылка на результат аудита: https://docs.google.com/document/d/1AGYrvaHrJpiyM2CYxjDeHx6Eigc267uAwMiD3qsZgYM/edit
Здесь можно заказать бесплатный аудит своего интерфейса:…
Ссылка на результат аудита: https://docs.google.com/document/d/1AGYrvaHrJpiyM2CYxjDeHx6Eigc267uAwMiD3qsZgYM/edit
Здесь можно заказать бесплатный аудит своего интерфейса:…
О целях интерфейсов
Как можно проводить аудит интерфейса, не зная его целей? Да никак. Даже если цели не озвучены, всё равно они будут как-то сформированы в голове у аудитора. Одному ему понятным образом.
Фишка в том, что во многих случаях цели владельца интерфейса будут отличаться от целей пользователей. Да, когда речь идёт, например, о посадочных страницах, у всех одна цель — чтобы сделка совершилась. Ну или, на худой конец, целевое действие было совершено.
Сегодня же у меня на аудите интерфейс мобильного приложения производственного календаря. И цель его создателя (помимо прочего) — заработать на рекламе. А цель пользователей — … ну, их несколько. И чьи же цели учитывать аудитору и как?
Об этом рассказываю в новом ролике. Вот ссылка: https://youtu.be/2rCchsj1DZk #аудит
Как можно проводить аудит интерфейса, не зная его целей? Да никак. Даже если цели не озвучены, всё равно они будут как-то сформированы в голове у аудитора. Одному ему понятным образом.
Фишка в том, что во многих случаях цели владельца интерфейса будут отличаться от целей пользователей. Да, когда речь идёт, например, о посадочных страницах, у всех одна цель — чтобы сделка совершилась. Ну или, на худой конец, целевое действие было совершено.
Сегодня же у меня на аудите интерфейс мобильного приложения производственного календаря. И цель его создателя (помимо прочего) — заработать на рекламе. А цель пользователей — … ну, их несколько. И чьи же цели учитывать аудитору и как?
Об этом рассказываю в новом ролике. Вот ссылка: https://youtu.be/2rCchsj1DZk #аудит
YouTube
Аудит интерфейса / №2
Демонстрация экспресс-аудита интерфейса мобильного приложения «Производственный календарь».
Ссылка на результат аудита: https://docs.google.com/document/d/1yNn4l2D-yw8vbv7YFIke3S049ZNnd60Czz6Hr6V_9ng/edit
Здесь можно заказать бесплатный аудит своего интерфейса:…
Ссылка на результат аудита: https://docs.google.com/document/d/1yNn4l2D-yw8vbv7YFIke3S049ZNnd60Czz6Hr6V_9ng/edit
Здесь можно заказать бесплатный аудит своего интерфейса:…
О чём хотят узнать люди, прежде чем купить обучающий курс?
Сегодня провожу аудит сайта, на котором продают курсы по ретуши с помощью нейросетей.
Это было весело: к интерфейсу всего пара-тройка замечаний. А вот к ответам на потенциальные вопросы посетителей…
В общем, смотрите сами. И если у вас тоже есть интерфейс, на который я мог бы взглянуть свежим взглядом и подсказать, что там поправить, чтобы он лучше достигал своих целей — пишите. В описании к видео есть вся необходимая информация.
Так как это уже третий подобный видеоролик, я решил завести для него хештег: #аудит. Теперь вы сможете легко посмотреть их все.
Приятного просмотра! https://youtu.be/N6C-4In-y-g
Сегодня провожу аудит сайта, на котором продают курсы по ретуши с помощью нейросетей.
Это было весело: к интерфейсу всего пара-тройка замечаний. А вот к ответам на потенциальные вопросы посетителей…
В общем, смотрите сами. И если у вас тоже есть интерфейс, на который я мог бы взглянуть свежим взглядом и подсказать, что там поправить, чтобы он лучше достигал своих целей — пишите. В описании к видео есть вся необходимая информация.
Так как это уже третий подобный видеоролик, я решил завести для него хештег: #аудит. Теперь вы сможете легко посмотреть их все.
Приятного просмотра! https://youtu.be/N6C-4In-y-g
YouTube
Аудит интерфейса / №3
Демонстрация экспресс-аудита интерфейса сайта, занимающегося продажей курсов по ретуши с помощью нейросетей.
Ссылка на результат аудита: https://docs.google.com/document/d/1JK-izP_6DasePtkVpnihG3vpxiB2tOAk3h0tfU4W5Fc/edit#heading=h.oystnhgoxgl4
Здесь можно…
Ссылка на результат аудита: https://docs.google.com/document/d/1JK-izP_6DasePtkVpnihG3vpxiB2tOAk3h0tfU4W5Fc/edit#heading=h.oystnhgoxgl4
Здесь можно…