Кейсы вместо портфолио на GitHub: превращаем проекты в статьи и посты, понятные заказчику-бизнесу
У большинства разработчиков портфолио выглядит так: список проектов, стек через запятую, пара скриншотов и ссылка на репозиторий. Иногда добавлено «highload» или «сложная интеграция». Всё честно, всё правда — и всё бесполезно для человека, который собирается заплатить полтора миллиона.
Проверить легко. Откройте свой раздел «Наши работы» и попробуйте прочитать его глазами директора производственной компании, который в жизни не открывал GitHub. Что он оттуда узнает? Что вы что-то делали. Похоже ли это на его задачу — неизвестно. Хорошо ли вы её решили — тем более.
Кейс отличается от портфолио одним: он рассказывает не про вас, а про заказчика, который был до вас в такой же ситуации.
Что вы узнаете из статьи
- Почему список проектов и ссылка на репозиторий ничего не доказывают
- Из каких пяти частей собирается кейс, который дочитывают
- Что писать, если результат не измеряется в деньгах
- Как обойти NDA и не потерять убедительность
- Как из одного проекта получить несколько материалов
Почему список проектов не убеждает
Заказчик приходит в портфолио с одним вопросом: делали ли вы что-то похожее на то, что нужно мне. Не «умеете ли вы программировать» — в этом он и так не сомневается, иначе бы не писал. Ему нужно узнать свою ситуацию в чужой истории.
Список технологий эту работу не выполняет, потому что технология — не ситуация. Директор оптовой базы не ищет подрядчика по Vue. Он ищет того, кто уже разбирался с ценами для разных категорий клиентов, с остатками на нескольких складах и с менеджерами, которые всё равно продолжают вести заказы в мессенджере.
Дальше — второй слой. Даже если проект похож, из портфолио неясно, что там было сложного. А заказчика тревожит именно сложность: он подозревает, что в его случае обязательно вылезет что-то, чего никто не предвидел, и это съест бюджет. Кейс, в котором честно описана вылезшая проблема и то, как вы её разрулили, снимает это подозрение сильнее любых заверений.
И третье. Скриншот показывает результат, но не показывает, каково с вами работать. А человек нанимает не код, а команду на три-шесть месяцев своей жизни. Так что кейс — это ещё и способ говорить с заказчиком на языке выгод, не переходя на самопохвалу.
Из чего собрать кейс, который дочитают
Пять блоков, дальше можно варьировать.
Кто и с чем пришёл. Отрасль, масштаб, симптом. Не «клиент обратился за автоматизацией», а «компания продаёт стройматериалы, четыре точки, заявки приходили в общую почту и терялись — примерно каждая десятая». Симптом должен быть таким, чтобы читатель поморщился от узнавания.
Ограничения. Тот блок, который почти все пропускают, а он самый ценный. Бюджет, сроки, работающий склад, который нельзя останавливать, чужая учётная система с кривым API, единственный сотрудник, знающий, как всё устроено, и уходящий в отпуск. Ограничения показывают, что задача была настоящей, а не лабораторной.
Что решили и от чего отказались. Здесь можно быть техническим — коротко. Особенно ценен отказ: «думали писать своё приложение, посчитали и отговорили клиента, обошлись ботом и веб-интерфейсом за треть бюджета». Отговорить заказчика от лишних трат — самый сильный аргумент в пользу вашей честности, который вообще существует.
Как проходила работа. Пара абзацев о процессе: как согласовывали, как принимали, что делали, когда клиент посреди проекта передумал. Это тот самый блок, который помогает снять страх «а вдруг пропадёте» заранее, до первого созвона.
Что стало. Цифры, пусть приблизительные. «Заявки перестали теряться, обработка одной — вместо двадцати минут около трёх, за первый квартал приняли на 18% больше заказов тем же составом». Если денег в результате нет, годятся часы, ошибки, обращения в поддержку, время операции.
Про NDA отдельно: чаще всего запрещено имя, а не суть. «Производственная компания на двести сотрудников» работает почти так же, как логотип. Написать клиенту письмо с просьбой согласовать обезличенное описание — дело пятнадцати минут, и отказывают редко.
Один проект — несколько материалов
Здесь начинается арифметика, которая обычно всех удивляет. Один законченный проект — это не один кейс. Это минимум шесть-семь материалов.
Развёрнутая статья-кейс на сайт, под ключевые фразы вроде «автоматизация обработки заявок» или «интеграция сайта с 1С». Короткий пост в канал с одним симптомом и одной цифрой. Отдельный пост про то ограничение, которое чуть не сорвало проект. Пост-мнение о том, почему вы отговорили клиента от мобильного приложения, — такие собирают больше всего комментариев. Минутный ролик с экрана: было так, стало так. Ответ на типовое возражение, которое всплыло на этом проекте. И карточка результата для мессенджеров, которую менеджер отправляет в переписке.
Всё это делается из одного набора фактов, собранного во время работы. Вот с этим сбором и проблема: через месяц после сдачи никто не помнит, сколько заявок терялось на старте. Поэтому три вещи стоит фиксировать сразу, прямо в задачах: цифры на входе, момент спорного решения, замер после запуска.
Дальше вопрос ритма. Один кейс раз в полгода не создаёт ощущения живой практики. Если сложно придумывать, о чём писать между проектами, посмотрите список тем на квартал вперёд — там разобраны форматы, которые не требуют свежего проекта.
Как понять, что ваше портфолио не приводит заявки
Первое: на созвонах заказчики просят «показать что-то похожее на нашу задачу», хотя раздел с работами они уже открывали. Значит, узнать себя там не получилось.
Второе: вас регулярно сравнивают по цене с исполнителями заметно другого уровня. Разницу в подходе человек не увидел, остались только цифры в смете.
Третье: в кейсах нет ни одной проблемы. Всё прошло гладко, все довольны. Такие тексты читаются как реклама и вызывают ровно то доверие, которое вызывает реклама.
Два пункта из трёх — повод переписать не сайт, а сами описания проектов.
Часто задаваемые вопросы
Чем кейс отличается от описания проекта в портфолио?
Портфолио отвечает «что мы делали», кейс — «что изменилось у клиента и почему выбран такой путь». Разница в ограничениях, отвергнутых вариантах и цифрах.
Что если результат не измеряется в деньгах?
Берите часы, ошибки, время операции, обращения в поддержку. Годится и снятый риск: раньше сбой замечали к утру, теперь сразу.
Клиент под NDA, кейс писать нельзя?
Обычно нельзя называть имя, а не рассказывать суть. Обезличенное описание согласуется письмом за пятнадцать минут.
Сколько нужно кейсов?
Важнее охват типовых ситуаций ниши, чем количество. Один точно попавший кейс сильнее десяти похожих интернет-магазинов.
Как не забывать собирать материал?
Фиксируйте прямо в задачах три вещи: цифры на старте, спорное решение, замер после запуска. Остальное соберётся из них.
Заключение
Ссылка на репозиторий и список технологий убеждают коллегу, а не человека с бюджетом. Заказчику нужно узнать свою ситуацию в чужой истории: тот же симптом, те же ограничения, тот же страх перед неожиданными расходами. Кейс это даёт, портфолио — нет.
Собирается он из пяти частей: кто пришёл и с чем, что мешало, что решили и от чего отказались, как шла работа, что стало в цифрах. Ограничения и отвергнутые варианты работают сильнее, чем аккуратный результат, потому что показывают, как вы думаете. NDA почти никогда не мешает: запрещено имя, а не суть.
И главное — один проект тянет за собой шесть-семь материалов для сайта и каналов. Руками их между задачами не соберёшь. В кабинете вы описываете проект в анкете, платформа подбирает ключевые фразы, собирает контент-план и готовит материалы, наш контроль качества проверяет длину и лимиты площадок, а вы согласовываете перед выходом. Посмотреть, как это устроено: dobro-code.ru.
Читайте также
Ещё из блога
Как выпускать контент регулярно, когда вы один: минимальный рабочий ритм
Почему регулярность рушится не из-за лени, что такое минимальный ритм и как его посчитать, работа партиями, запас материалов на две недели и что делать, когда всё сорвалось.
ОбщееСогласование материалов с клиентом: как сократить круги правок
Почему правки идут по третьему кругу, как договориться о критериях до начала работы, чем отличается правка от переделки, регламент согласования и что делать с бесконечными доработками.
ОбщееАнкета проекта: почему без неё контент получается «ни о чём»
Что такое анкета проекта, какие семь блоков в ней должны быть, чем она отличается от описания компании, как её заполнить за час и почему без неё материалы получаются одинаковыми у всех.