Тематические исследования, дайджесты, открытый исходный код? Как ИТ-компании должны продвигать себя?

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

Чтобы узнать ответы на эти вопросы, а также другие аспекты позиционирования ИТ-компании, я взял интервью у Даниэля Ласко, директора по продажам команды Singula, специально для Hackernoon.< /p>

Интервью

Дэниел: мы специализируемся на разработке веб-сайтов и приложений, дизайне и техническом консультировании. Теперь Singula сосредоточена на таких областях, как финтех, электронное обучение, автоматизация бизнеса, блокчейн, электронная коммерция и медицина. Нашими типичными клиентами являются CTO (если это крупная компания) и CEO (если это стартап). Первые часто сосредоточены на управлении ИТ-разработкой, а вторые могут вообще в этом не разбираться, поэтому ищут команду, «говорящую с ними на одном языке».

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

Мы нашли золотую середину — нужно создавать контент, который будет понятен потенциальным клиентам, но в то же время покажет уровень вашей нишевой экспертизы.

Ваши редакторы должны собрать информацию от команды проекта, написать текст и согласовать его внутри, а затем с клиентом (с помощью менеджера проекта).

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

Это можно продемонстрировать с помощью технических дайджестов и статей о ваших проектах с открытым исходным кодом.

Элизабет: А как вы представляете нишевую экспертизу, чтобы клиент вас понял? п

Дэниел: давайте рассмотрим структуру, которая может помочь предоставить клиентам необходимую им информацию.

Не замыкайтесь в схеме «задача-решение-результат».

Если вы посмотрите руководства по созданию контента, то, скорее всего, вы увидите там такой совет: «Пишите небольшие рассказы в формате задача — решение — результат и показывайте цифры».

Но я бы посоветовал не стесняться писать длинные тематические исследования. Если им нужно 13 свитков, ничего страшного. Но чтобы управлять вниманием читателя, нужно разделить контент четкими заголовками.

Клиентов интересует, что вы сделали, как быстро и какие результаты это принесло.

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

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

Напишите тематические исследования на языке, понятном обычным людям.

Например: «Разработали CRM-систему для компании N. Сотрудники не могли быстро выполнять свои задачи, потому что не было единого дизайна внутренних систем, а технологическая база была в беспорядке».

Не бойтесь писать о неудачах.

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

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

Часто такой опыт приходит не в результате ошибочных решений, а в результате экспериментов.

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

Опишите стек технологий, но не вдавайтесь в подробности.

Если вы много разрабатываете на Ruby, Go и Rust, всегда указывайте это в своих кейсах. Почему? Есть три причины.

Лучший способ рассказать о результатах — показать их.

Чтобы показать результаты своей работы, вы можете описать основные модули разработанной вами CRM-системы.

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

Если тематическое исследование написано либо во время завершения проекта, либо во время значительного выпуска, для добавления перспективы стоит добавить «Что дальше?» раздел. В нем вы можете рассказать о своих планах развития (если вы будете продолжать сотрудничество) или о планах развития вашего клиента (если клиент будет действовать самостоятельно).

На самом деле работать дольше и продуктивнее интересно. Естественно, публиковать кейсы, заканчивающиеся фразой «а потом стартап закрылся», не очень круто.

Сделайте процесс утверждения обращения максимально простым.

Одно дело написать кейс, а другое дело получить одобрение от клиента. Именно поэтому следует писать 15-20 кейсов параллельно, чтобы публиковать хотя бы по одному каждый месяц. Крупные международные компании любят нанимать юристов, чтобы максимально очистить материал.

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

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

Элизабет: Так как же продемонстрировать экспертность, если среди вашей целевой аудитории есть эксперты?

Дэниел: написав о своих проектах с открытым исходным кодом.

Развитие — это всегда процесс изобретения вещей. Если какого-то инструмента не хватает, его можно создать самостоятельно. А затем расскажите об этом на своем веб-сайте.

Статьи об open-source — это тексты, которые обычные люди не поймут. Они для разработчиков. А публикуя их, вы делитесь своим опытом, что очень важно в сообществе разработчиков.

Собирайте новости из мира разработки в дайджесте.

Еще один формат исключительно для разработчиков — технические дайджесты. Каждый месяц вы можете писать краткий обзор технологий, с которыми работаете: Ruby, Rust, Python, Go, Frontend, DevOps. Дайджест можно разместить в виде списка рассылки, а также отдельно на сайте, где будет больше подробностей и ценных пояснений.

Неспециалисту будет сложно найти такие проекты. Интернет пестрит всевозможными рейтингами и топовыми открытыми проектами с GitHub. Но вы можете попытаться рассказать о вещах, которые вы действительно используете в своей работе.

Вообще у каждого разработчика есть папка с сохраненными ссылками на интересные репозитории, которые он планирует реализовать.

Что мы читаем, чтобы быть в курсе и быть в теме? Список не окончательный, но начинать копать стоит отсюда:

* InfoWorld< /сильный> * Briebug * Еженедельник Python * Go.dev * Getrevue.co * Реддит * Внешний интерфейс