Как выявить компании, которые недовольны текущими разработчиками

Dmytro Rodenko explains how to spot companies frustrated with their developers. Look for signs like missed deadlines, slow feature releases, and public complaints on LinkedIn. He covers where to find these signals and how to approach them as a potential client.
Здравствуйте. Меня зовут Дмитрий Роденко. Я основатель сообщества SaaS Founders. Помогаю фаундерам моей компании находить новых крупных клиентов на разработку с помощью линкдейна. Сегодня мы обсудим блок вопросов, которые касаются выявления компаний, которые недовольны текущими разработчиками. Основные вопросы такие. Какие признаки публичной активности компании указывают на проблемы с разработкой? Какие источники информации лучше всего помогают выявить недовольство клиентов текущими исполнителями? Какие отрасли чаще всего испытывают проблемы с качеством разработки? На каких этапах развития компании чаще всего меняют разработчиков? И так далее. Порядка 36 вопросов. Я выберу из них самые интересные. И, собственно говоря, по ним будем отвечать. Так, ну давайте начнем, собственно, с первого. Значит... Так. Какие признаки публичной активности компании указывают на проблемы с разработкой? Смотрите, в социальных сетях на профилях компании, либо на профилях сотрудников компании, которые отвечают за разработку или в целом достижение результата, либо где разработка является значимой частью жизни компании, люди начинают задавать вопросы. То есть они говорят, помогите найти разработчиков. Раз. Они начинают обсуждать различные проблемные вопросы. Например, почему мы там меняем третью команду, ничего не получается и так далее. Поэтому для того, чтобы находить такие компании, находить таких людей, вам нужно использовать либо поисковые запросы в сетях а-ля LinkedIn, Facebook, Reddit в том числе, кстати, Вы можете регулярно использовать поиски в LinkedIn, то есть составить по сути семантическое ядро, то есть набор фраз, которые говорят, прямое включение которых говорит о том, что у людей есть проблема. Я хочу разработчиков, не могу сделать интеграцию и так далее. Часть этих объявлений будут вакансиями. Кто-то подойдет, кто не подойдет. Часть будет вопросами небольшими техническими, но часть будет очень интересной с точки зрения того, что они будут говорить о том, что человек столкнулся с проблемой, которую не может решить сам. И вы можете этому человеку написать, сказать, я видел твой пост. Лучше всего прокомментировать этот пост, сказать, смотри, я сталкивался с какими-то проблемами, знаю, как решить, давай с тобой свяжемся, я тебе расскажу, покажу вот конкретные примеры, как это работает. Поэтому первое – это регулярный ежедневный поиск по LinkedIn, по Facebook и по Reddit для того, чтобы находить таких людей. и там мы с ними, соответственно, выстраивать отношения. По сути, это запросы, где встречаются необходимые ключевые слова, и вы дальше просто квалифицируете этот запрос, тот, не тот, и дальше начинаете с ними уже дальше общаться. Значит, второй хороший признак – это вакансии, которые они не могут закрыть больше 60 дней. Значит, на сервисе Indeed Есть такая опция отобрать вакансии, которые как бы существуют больше 60 дней. Если она существует больше 60 дней, значит, она не была закрыта за это время. Там больше 60, 90, 120 и так далее. Соответственно, выбираете вакансии с удаленной работой. Значит, выбираете по ключевым словам те вакансии, которые вас интересуют. Там стокситек, технологии, набор компетенции и так далее. И смотрите, выбираете вакансии, которые не закрываются. Дальше анализируете, почему они не закрываются. Может быть, вариант такой. Либо люди хотят какого-то единорога, не знаю, трех... там, не знаю, какого-то осьминога, у которого 48 часов, который за небольшие деньги должен взять все. Это, наверное, не сильно рабочая история. Либо вы видите, что там есть какая-то специфика или специализация, которой на локальном рынке недостаточно. Можете туда податься, можете пообщаться. Это один момент. Второй момент. Здесь узкое место, потому что если вы прямо подаетесь на вакансию, у вас должен быть процесс, когда вы трудоустраиваете самого квалифицированного, а работу распределяете на всех остальных. Это такой метод, который я называю индусский метод по стране, где он был изобретен. Как делают индусы? Есть индусская семья разработчиков, или группа, компания, неважно как она называется. Их там условно 10 человек. У каждого есть свой опыт, у каждого есть своя специализация и так далее. Самый квалифицированный ходит на собеседование, устраивается в одну компанию, во вторую компанию, в третью компанию и обеспечивает работу и собственно является таким фронтменом, который фронтирует всю эту работу, ходит на встречи, на отчеты, его готовят к этим встречам, то есть он такое ключевое лицо. И в итоге он обеспечивает работой 3, 5, 10, до 20 человек, которые делают за него, пишут код, документацию делают и так далее. Так делают не только индусы. У нас есть клиент, который переехал 2 года назад в Канаду. Он к нам пришел, потому что он устал от такой схемы. Он действительно очень квалифицированный инженер, но единственный способ, как он умел продавать, это вот подобная схема. То есть он устраивался в компанию, его брали, потому что он проходил все собеседования великолепно, а дальше он перераскидывал эту работу на других сотрудников, ну и, соответственно, занимался тем, что по сути управлял этим процессом и как бы ходил на встречи, совещания и так далее. Но это очень утомительно. Он очень устал от этой работы, поэтому пришел в Лиды Генерации и сказал, что я хочу продавать не себя как голову с помощником, я хочу продавать себя как компанию. В такой ситуации, если вы не хотите работать по подобной схеме, она очень утомительна по своей, так сказать, рутине. Человек нормально зарабатывал, он зарабатывал очень неплохо, но на разнице потенциалов, потому что он правильно умел построить работу, по сути мини-проекты делал. на регулярной основе, но это его сильно выматывало, потому что совещание, потому что планерки, стендапы, все это каждый день, все надо быть в курсе, все надо быть в строю, а если они накладываются, это вообще скандал, ну в общем, и так далее. Есть другой вариант, смотрите, если вы видите, что вакансии закрываются больше 60 дней, если вы идете к рекрутеру и пытаетесь продать услуги компании, обычно это не работает, потому что у рекрутера КПИ в головах. То есть рекрутер, у него есть задача или у нее взять человека на работу, значит задача выполнена. Если человека на работу не взяли, значит задача не выполнена. А когда вы приходите и говорите, здравствуйте, у меня есть компания, которая может выполнить это в два раза дешевле, для рекрутера это вне системы координат. То есть это не закрытая задача, это что-то Не моя задача, что называется. Не мой цирк, не моя задача. Поэтому в этом смысле надо выходить на того, кто эту задачу ставил. Не могут они найти такого супер разработчика, на которого повесят все функции. Пойдите к тому в компании, кто эту задачу ставил. То есть к фаундеру. к CTO, к еще кому-то, кто отвечает за подобное направление. Скажите, видел вакансию, у меня есть опыт такой работы, но смотрите, я предлагаю эту вакансию разбить на три должности, и стоить это будет столько. Такие, ну окей, если им действительно это важно, они не могут это закрыть, для них это может быть решением. Поэтому используйте подобные методы. Люди обычно не молчат. Когда эта проблема действительно актуальна и больна, они про это много говорят. И эти признаки можно отловить в социальных сетях. Следующий вопрос. Какие источники информации лучше всего помогают выявить недовольство клиентов текущими исполнителями? Смотрите, если эта информация вышла наружу, это значит, что все уже произошло. Это значит, что текущих исполнителей уже уволили, принято решение, и уже есть какая-то конфликтная ситуация, которая уже решена чаще всего. В процессе она решается внутри, и более того, она чаще всего выходит наружу уже постфактум. Когда поставщика поменяли, это отболело, и это выходит как некая рефлексия, переживание прошлого опыта. Поэтому это поздно. Используйте те источники, о которых я говорил. Смотрите, где идет обсуждение проблем. Это первое. Второе. Где не закрываются вакансии достаточно давно. Это самое важное, что вы можете использовать. Так, это не надо. Давайте вот этот попробуем. Это интересный вопрос. Так, какие отрасли чаще всего испытывают проблемы с качеством разработки? Смотрите, по отраслям сложно выделить. Это обычно определенные типы компаний. Ну вот смотрите, например, либо когда компания переходит с одного уровня на второй. Представьте себе стартап, который сделал MVP, отработал product market fit, делал это с командой аутсорсеров, да? И у него пошли объемы, у него пошли клиенты, появились деньги, и дальше ему нужно развиваться дальше. Обычно стартапы, если они сами финансируются, мало зависят от инвестиционных денег, их обычно все устраивает, если они видят, что команда, которую поддерживают, помогает развиваться, их все устраивает. Но если команда получила финансирование миллион, два, три, пять и так далее, инвестора могут потребовать, чтобы бизнес был более устойчивый, и эта команда была in-house. чтобы она была на борту. И в этом смысле работа с аутсорсинговой компанией становится более рисковой. И это одна из тех точек, когда компании говорят, все, мы прощаемся, теперь будем заниматься нами. Теперь будем заниматься наймом людей in-house. Их устраивает качество, их не устраивает надежность работы подобная схема. Как эту историю можно обойти? Эту историю можно обойти следующим путем. Я встречал у своих клиентов такой трюк. Фаундер компании по разработке приходит к стартапу и говорит, ребята, давайте я стану вашим миноритарным акционером, то есть я у вас за условные 50 тысяч долларов выкуплю определенную долю. Вы ее будете выплачивать определенное время, то есть я буду выплачивать ее определенное время и буду выплачивать ее работой, например. И таким образом получается ситуация, что это уже меняется роль. Их же роль не устраивает они работу, меняется роль. Был внешний поставщик, стал со-инвестор, который частично, относительно небольшой суммы, относительно всего проекта, вложился в данный проект. И дальше это его сотрудники, или условно это теперь официальные сотрудники данного стартапа. Некая команда, которая теперь формально работает in-house. Часть вклада, часть контроля и так далее. Их официально трудоустраивают в данный стартап. Хорошая история. Спасла ни один проект, ни одно долгосрочное сотрудничество. Это я ответил про этапы развития бизнеса, когда чаще всего меняются разработчики. Это как раз про эту историю. И был вопрос. Так, дальше. Что делать, когда компания открыто критикует своих разработчиков? Бежать. Бежать от такой компании. Потому что это значит, что компания не может договориться с этими людьми. Раз. И если вы замените разработчиков, то через месяц, два или три открыто критиковать будут вас. То есть проблема тут чаще всего не в разработчиках, а не только в разработчиках, а в своей компании. Ну то есть, если ты набрал этих людей, если ты выстраиваешь с ними договорные какие-то доверительные отношения, да, и открыто их критикуешь, это значит, что у тебя закончились все остальные способы с ними общения. Просто любые. Те же договорные, юридические, коммуникационные. Бывают вообще скандальные ребята сами по себе, да, у них просто такой имидж и такой подход к бизнесу. Вот. Оно вам надо, что называется. Поэтому если вы видите, что компания открыто критикует своих текущих разработчиков, оно вам не надо. Оно вам не надо. Так, смотрим дальше. Где моя мышь? Ага. Так, вот мои курсоры. Хороший вопрос на самом деле, он периодически встречается в нашей работе с клиентами. Стоит ли прямо спрашивать о проблемах с текущими разработчиками? У нас в рамках первой квалификационной встречи, которую мы рекомендуем нашим клиентам проводить следами, есть вопрос такого плана, есть ли у вас опыт работы с удаленными командами разработки. И если человек говорит «да», мы рекомендуем спросить, а что получалось, что не получалось и так далее. То есть это не напрямую вопрос о проблемах, это скорее о существующем опыте. Вы знаете, чаще всего эти проблемы решаются очень просто. Потому что, например, они говорят «да, была большая команда, она была неквалифицирована». А в чем это проявлялось, да? И вы сразу уже можете понимать, даже на этапе квалификации, а вообще это ваш клиент или не ваш? Вам комфортно с ним будет работать или нет? И в этом смысле это важный вопрос, поэтому напрямую о проблемах с текущими разработчиками спрашивать не надо, а вот спрашивать о опыте, что получалось, что не получалось, это вот самое оно. Так, вот хороший вопрос. Так, нужно ли менять подход к продажам для компании с негативным опытом разработки? Это почти продолжение прошлого вопроса. Есть компании, у которых есть негативный опыт разработки, внешний, у кого-то внутренний. И тут зависит от самой компании. У кого-то был негативный опыт, и они ищут другого подрядчика, а компании, у которых есть негативный опыт, и они не хотят работать дальше с внешними подрядчиками, их будет достаточно сложно перевести. То есть меняется ли подход к продажам для компаний с негативным опытом? Я думаю, что не нужно продавать компаниям, у которых есть негативный опыт и которые не хотят дальше работать с аутсорсерами. Те, которые готовы, надо разобраться, что их не устраивало. То есть нужно, как в любой продаже, задавать правильные вопросы. Какие были команды, что в них не устраивало, о чем был разговор, почему не смогли устранить данные изменения. Если вы видите, что и в вашем случае будут те же самые проблемы, то проще за эту работу не браться для того, чтобы не увеличивать свой, так сказать, свой негативный опыт и так далее. Вот. Но обычно такие компании, в принципе, даже навстречу с разработчиками не приходят. Ну, а вот хороший вопрос, кстати, про... Так, как мотивировать команду на работу с сложными клиентами после неудачного опыта? Ну, смотрите, сейчас такой рынок, что клиентов особо не выбираешь, хотя, с другой стороны, выбирать надо всегда, да? Вот. Я думаю, что здесь, во-первых, Самое важное в мотивации это сделать так, чтобы цели сотрудников соответствовали целям команды. Потому что изначально цели сотрудников, они где-то противоречат с целями компании. Ну смотрите, что такое сотрудники для компании? Это расходы. Чем меньше расходы, тем лучше для компании. Но для сотрудников, чем меньше зарплата, тем это хуже. Правильно? Соответственно, здесь есть прямой конфликт интересов. То есть при одинаковом доходе либо больше зарабатывают сотрудники, либо больше зарабатывает компания и надо где-то договариваться. У команды должно быть четкое понимание, во-первых, что у них есть право отказаться от работы с данным клиентом, раз. Но конструктивно отказаться, не просто я не хочу, не просто у меня этот человек раздражает и так далее, а вот потому что раз, два, три, четыре, пять. По факту у нас были, конечно, такие ситуации, и по факту оказывалось, что проблемы во многом являются надуманными. Кто-то не так на этого посмотрел, кто-то что-то сказал, что другие не так поняли. То есть это обычные проблемы. Проблемы в кооперации начинаются с проблем в коммуникации. И очень часто, когда вы с более верхнего уровня изучаете всю эту историю, слушаете эти истории переговоров, вам становится просто и понятно вообще, а почему эта проблема возникла, вы можете разрулить ее внутри команды и обычно это работает хорошо. То есть это если все как бы окей, все на одной волне, но просто друг друга не поняли и возник какой-то камень преткновения. Бывают более сложные ситуации, когда клиент плохо относится к сотрудникам, обижает их, причем делает это вербально. То есть, например, при переговорах со мной все ласково, все хорошо и так далее. А при переговорах с сотрудниками они ноги вытирают и так далее. Причем жестко используют фабулировки. И это касается не только условно Украины или других постславянских стран. Нет, у нас были такие кейсы с швейцарцами. с бельгийцами и так далее. Ну то есть как-то вот у них есть четкая иерархия, они говорят, что ты босс, мы тебя любим, а твои сотрудники мы их там, так сказать, ни в что не вставим, не уважаем и так далее, что в принципе достаточно удивительно. Аналогично. Это решается либо выравниванием коммуникации, то есть, что вас обидело, что не так, где-то ограничением возможности данных клиентов влиять на сотрудников. То есть, смотрите, вот есть такой процесс, коммуницируем мы вот-вот по таким правилам. Все, что выше, не обсуждается, либо обсуждается по отдельной тарификации. Это тоже хорошо работает и обычно дает результаты. Ой, какой хороший вопрос. Сейчас отвечу на него. У меня буквально пару минут. Сейчас отвечу на ваши вопросы. Первое. Модерация внутри. Обсудить с командой, что их стопорит. Провести с ними переговоры, разграничить сферы влияния и обсудить это с клиентами. Второе, дать им честную возможность отказаться от данного клиента. Сказать, ребята, если действительно они не совпадают, дать им других менеджеров, других разработчиков. Вот, все переговорами, то есть все решается только так. Вот хороший был вопрос от Apply.ai. Спасибо за лекции. Это не совсем лекции, это вопросы на ответы, но все равно, пожалуйста. В каких IT-нижних сейчас рынок кандидата или хотя бы поровну? Знаю, что почти все красное, но, может быть, где-то есть свет в тьме. Спасибо. Вот вы знаете, в вашем вопросе есть ответ. Вот у вас написано Apply.ai. Вот, на самом деле сейчас большой спрос вот с того, что мы видим на рынки разработчиков AI ML решений различных, да, возникает и на уровень ниже есть целый такой рынок промпт-инженеров, то есть тех людей, которые генерируют промпты. Почему? У нас даже недавно пробегало, я видел такую вакансию, что Нам нужен промпт-инженер. Они называли это не так, они называли это как-то креативный директор. Какой там креативный директор в производстве, это большой вопрос. Но по сути, это звучало... Не креативный, боюсь, не точно скажу, но смысл был именно такой. А, и директор по инновациям. И смысл директора по инновациям был в том, чтобы, по сути, после того, как мы там встретились, пообщались, обсудили, кто это, что это, зачем он нужен директор по инновациям в рамках другого проекта, Нам сказали, у нашего топ-менеджмента есть видение того, как и что нужно делать, и нам нужен человек, который переложит мечты, идеи и пожелания нашего руководства на язык искусственного интеллекта. И с помощью искусственного интеллекта сможет это помочь реализовать. Я говорю, так вам промпт-инженер нужен? Они говорят, ну, наверное, да. Наверное, это вот промпт-инженер, то есть это часть функции, которая вам нужна. Поэтому, если у вас есть не просто опыт, мы работали с AI и можем применить его везде, это сейчас у всех есть, это неинтересно. А вот если вы можете сказать, смотрите, в производственной компании мы сделали решение, которое на базе видеокамер сканирует брак, И автоматически на основании паттернов и определенных датасетов проверяет качественность изделия. И процент брака снизился на 80%. Уж раньше это делалось либо руками, либо вообще не делалось. то это конкретный результат. Вы можете пойти к таким же компаниям и сказать, ребята, в других регионах, в других странах и так далее, смотрите, у меня есть такой опыт, могу сделать такое для вас. Решения почти всегда будут уникальные, потому что кто-то выпускает бутылки, кто-то выпускает игрушки, кто-то выпускает запчасти какие-то металлические. Критерии все равно, проекты будут все уникальные, но наличие такого опыта будет большим-большим плюсом. Если вы хотите устроиться, то вы можете посмотреть, какие компании из разработчиков работают в тех сегментах, с которыми вы говорили. Вы можете показать этот опыт и дальше уже с ним двигаться дальше. Если у вас такого опыта нет, попробуйте такой опыт получить. Это конкретная задача, причем у Nikon надо гигантские деньги. Потому что, вот смотрите, что такое выпуск брака для компании? Компания купила компания оплатила работу персонала. Компания оплатила логистику, доставку, гарантию. Компания получила недовольного клиента, который недоволен изделием, и оплатила доставку обратно и утилизацию брака, либо переработку. То есть брак это очень дорого физически. Это очень дорого в деньгах, это дорого репутационно. Снижение процента брака в 4 раза, в 3 раза, что помогает делать AI, Это значимый плюс, это большой, хороший, серьезный системный результат. Соответственно, это можно посчитать в конкретных деньгах, сколько стоит единица брака и на сколько единица брака бракованной продукции, сколько она стоит предприятию. Поэтому внедрение системы стоимостью от 50 до 100 тысяч долларов, в принципе, окупается даже на отечественном рынке достаточно резво. Вот. Поэтому ищите такие проекты, участвуйте в таких проектах. Можете участвовать на пробу на основе. Получайте этот опыт, а потом с этим опытом максимально туда устраивайтесь. Потому что это реально опыт. относительно свежие, хотя такие системы уже существуют года три, но они пока все еще не массово внедряются, потому что люди не знают как, люди не знают зачем, почему. Вот конкретный пример, и если у вас есть такой опыт, вы, конечно, будете востребованным кандидатом. И все это будет важно, интересно, вас с удовольствием. будут воспринимать. Мне пора бежать на следующую встречу с клиентами. Спасибо вам за вопросы, спасибо за участие. Если у вас есть вопросы по тому, как находить крупных клиентов с помощью лиды генерации в LinkedIn, вот ссылочка. Сейчас я ее забросил. Она появится и на YouTube, уже появилась и на Facebook. в LinkedIn и другие каналы Facebook тоже сейчас запощу вручную. Задавайте вопросы, поможем, подскажем. Либо сделайте сами по итогу, либо мы поможем вам это сделать с финансовой гарантией результата. Желаю всем новых крупных контрактов. До скорой встречи.
More from Dmytro

Лайфхак "Какие ошибки в лидгене убивают ваши шансы на сделку по IT разработке"









