Чего точно не нужно делать
Начну со списка того, чего делать точно не надо. Он короткий, простой и убережет вас от явного выстрела в колено. Точнее, пользоваться только этими способами выбора партнера.
❌ 1. Смотреть в публичные рейтинги. Нахождение компании в рейтинге совершенно не значит, что вам попадется именно тот человек, который обеспечил попадание в рейтинг. Данные для них берут из открытых источников — прибыль, годовой оборот, количество сотрудников и тд. Кроме того, участники большинства рейтингов платят за участие. Алгоритм простой — чем больше заплатил, тем выше место в рейтинге.
Есть ресурсы, на которые люди выкладывают свои работы. Лично мне это нравится больше, чем рейтинги. Например, behance.ru. Он больше про дизайн — можно внешне посмотреть проект. Но при желании можно удачно провалиться на сайты компаний и познакомиться с другими аспектами работ команды.
❌ 2. Выбирать подрядчика только по цене. Если перед вами три предложения от схожих по размерам компаний с ощутимым разбросом цен — нужно выяснить, почему такой разброс вообще есть. Не нужно сразу бросаться к самым дешевым. Эта информация поможет вам обратить внимание на глубину проработки требований командой и может указать на несостыковки в ваших требованиях.
❌ 3. Следовать концепции — “кто платит, тот и прав”. Прав оказывается тот, кто сможет достичь ваших бизнес-целей. Да, клиент платит деньги. Но он так же обращается за помощью к подрядчику, к его опыту и профессионализму. У клиента болит, а подрядчик делает все, чтобы болеть перестало. И за это он получает деньги. И тут возникает разговор о взаимном доверии. Уже на начальном этапе две стороны договариваются о том, что будут развивать партнерские отношения и на этом фундаменте строят отношения дальше.
❌ 4. Слепо верить рекомендациям знакомых. Если вам кого-то посоветовали — не опирайтесь исключительно на рекомендацию. Всегда сами принимайте решение и проверяйте. Вам работать с выбранной командой, а не тому, кто рекомендует.
Что полезно делать
✅ 1. Искать и запрашивать описания кейсов у профильных компаний. Это рабочая стратегия, но есть пара моментов, о которых следует знать.
Во-первых, наличие кейса на сайте не значит, что для вас проект будут делать те же люди, которые делали проект из кейса на сайте. Важно проводить скоринг команды с нуля и делать выводы на основании личного общения. Если будете общаться с компанией, которую выбрали по кейсам на сайте, обязательно поинтересуйтесь — кто именно будет делать проект и как знания о предыдущем опыте попадут к новой команде (если кейс делали другие специалисты).
Совет. Если у вас нет вообще никого с компетенцией в разработке, тогда ваш ключевой запрос в поисковике может выглядеть так: "мобильное приложение компании “…”" Сферы на рынке разработки прояснены и запрос можно сформулировать точно. Люди заботятся о том, чтобы их кейсы искались. Как правило, к поисковой контекстной рекламе и публикациям о себе компании приходят, когда уже есть накопленный опыт и есть, что показать. Часто бизнес в заказной разработке начинается с того, что какая-то команда получает какой-то заказ и просто начинает его делать. Первое время ребята работают за счет существующей сети знакомых. Я не знаю ни одной компании, которая в первый же день работы пошла в поисковый трафик. Скорее всего, у них хватает проектов, если уж они решили создать компанию. Не бывает так, что собрались несколько программистов и решили — давайте-ка запустим рекламу, придет заказ и тогда уже будем суетиться. Так это не работает. У себя, в itMegastar, мы пришли к продвижению только на шестой год работы. Команда и сейчас покрыта контрактами, однако мы готовы расти быстрее и поэтому выделили отдельный департамент, который будет заниматься продвижением. Компания растет, ресурсов и профессионалов в команде становится все больше.
Во-вторых, аутсорсинговые и аутстафинговые компании не про все могут рассказать. Это подтверждается и личным опытом. Значительную часть наших проектов, особенно в первые годы работы, мы делали на субподряде крупных компаний. Кроме того, есть клиенты, которые явным образом не разрешают публиковать в общий доступ информацию о проделанной работе.
✅ 2. Спросить про личный опыт знакомых или партнеров. Если раньше бизнес одной сферы между собой не особо пересекался, то сейчас бизнес-сообщество довольно дружное. Условно, если я делаю упаковку и ты делаешь упаковку — скорее всего, мы контактируем на каких-то площадках, форумах, чатах и тд. И совершенно нормально в таких сообществах запросить рекомендации. Но помните, что основываться только на них нельзя. Выбор делать вам. Используйте эту рекомендацию, как источник контактов и возможность заранее узнать потенциальные сложности в работе.
✅ 3. Смотреть на опыт компаний, которые нравятся, и обращаться к ним. Свяжитесь с теми, кто уже покупал такое решение. Если это не ноу-хау — бизнес спокойно делится контактами разработки.
Выполнение одного пункта уже станет источником 5-7 контактов. Выполнение всех трёх вооружит вас отличным набором информации для принятия взвешенного решения. Но прежде, чем фильтровать список соискателей, нужно подготовиться к предметному разговору.
С чем идти на разговор с подрядчиком
Обычно разработчики ожидают на входе документ с подробными и четкими требованиями. Чаще всего его называют Техническое задание, однако все понимают под этим совсем разное.
Мы советуем готовить два документа:
- Описание желаемого результата в бизнесовом формате. У себя мы называем это видением или vision. Это житейское описание того, что должно будет происходить с помощью продукта и в каком процессе он будет существовать. Опишите, кто будет им пользоваться, что конкретно будет делать и зачем, с какими внешними сервисами продукт должен взаимодействовать, какая нужна последовательность операций внутри. Не пытайтесь в документе копнуть в техническую реализацию или выбор фреймворка. Компетентные инженеры предложат всё сами. Им важно понять бизнес-цели и ваш бизнес.
- Нефункциональные требования. Это требования, не относящиеся к тому, что именно делает данное решение. Они описывают окружение, нагрузку на продукт, доступное техническое оснащение и тд. Например:
- каталог данных от партнеров нельзя забирать чаще, чем раз в день;
- в местах использования продукта нестабильная связь;
- пользователи оснащены только смартфонами на Android и не имеют возможности отсматривать графики на больших экранах и тд.
Этих двух документов на старте достаточно для того, чтобы вести предметный разговор, делать подступы к специфицированию проекта и двигаться в сторону оценки и плана работ.
Продвигаемся дальше — как фильтровать список дальше.
Как выбрать того единственного и списка кандидатов
1. Позвоните и проведите интервью
Когда мне нужно разобраться в какой-то сфере, я беру три-четыре компании и звоню им, как потенциальный клиент. К третьему созвону я уже сам могу отвечать на многие вопросы, как подрядчик. Все рассказывают по-разному и, комбинируя информацию, можно составить видение того, что действительно вам подходит. Не стесняйтесь показаться профаном. Я не знаю случаев, когда команда видит, что к ним пришел новичок в теме разработки и ребята думают "вот щас-то мы его и разденем". Интернет помнит все. И те компании, которые занимались таким обманом, на рынке не остаются. Не бойтесь показаться новичком в теме — важно четко сформулировать бизнес-цели и слушать, что говорят по ту сторону провода.
Уже после первого созвона у вас появятся факторы, по которым точно нужно пройтись со следующим кандидатом. Например:
Контакты (сайт, телефон, менеджер)
Релевантный опыт (ссылка на портфолио/страницу на сайте)
Общий бюджет проекта
Срок исполнения проекта
Срок гарантийного обслуживания
Идеи по реализации
Система налогообложения
И другие на ваше усмотрение
2. Назначьте личную или онлайн-встречу
В скоринге обязательно должен принимать участие сотрудник, который будет бизнес-заказчиком и тот, кто будет принимать работу у исполнителей. Повторю, не надо разделять ответственность в выборе подрядчика и последующей работе с ним. Пусть решение принимается совместно, но обязательно при участии основного специалиста, ответственного за проект. Если у вас есть отдел закупок, отвечающий за подбор подрядчиков, не отпускайте их на встречу одних. У них совсем не такие цели, как у бизнес-заказчика проекта. Оптимальный вариант — пригласить на встречу представителей всех команд, которые будут пользоваться разработанным решением. Однако не надо превращать выбор в балаган и ожидать согласия всех участников, оставьте финальное слово за тем, кто будет отвечать за реализацию.
Важно, чтобы у вас возник контакт с командой на уровне внутренних ощущений. В разработке нет незаменимых людей — всегда можно найти кого-то, кто не менее профессионально выполнит работу. Но терпеть в такой долгой проектной работе людей, с которыми вам некомфортно — не стоит. Если вам не нравится команда с точки зрений человеческих отношений, но вы все равно выбираете с ней работать — вы автоматически встаете в позицию зависимой жертвы. Мол, ребята, конечно, не самые приятные люди, но посмотрите, какие проекты творят! И вам придется терпеть неприятное поведение на протяжении всего проекта. Ничем хорошим это не закончится.
В личном разговоре советую обратить внимание на такие вещи, как:
- Доступность команды. У подрядчика должно быть достаточно специалистов, чтобы выполнить работу. Не менее важный момент — все они должны быть доступны в процессе производства. Если даже в момент старта ресурсов не хватает, вы должны получить план — как и откуда они появятся. Убедитесь, что подрядчик готов обеспечить проект необходимой командой и сообщить источники ее пополнения, если потребуется сократить сроки реализации или кто-то из команды не сможет выполнять работу.
- Компетентность менеджмента. Менеджеры и аккаунты должны четко понимать фронт работ и иметь навыки, позволяющие управлять проектом и вести ясную коммуникацию. В разговоре обращайте внимание на их бизнес-ориентированность, а не слепое выполнение задач. Разработка не самоцель, цель — достижение вашей компанией выбранных показателей.
- Умение команды планировать то, что возможно планировать. Сложно что-то производить, если инженеры не могут сформулировать последовательность действий.
- Ясность и открытость. Большинство проблем возникает из-за низкого качества синхронизации, недосказанности, желания скрыть что-то. Если вы чувствуете, что от вас пытаются что-то скрыть — лучше высказать сомнения “на берегу” и, если ситуация не разрешится, прекратить работу.
- Готовность к большим скидкам просто так. Если вам просто так делают скидку, скорее всего, подрядчик:
- планирует дотянуть проект за счет специалистов низкого качества. Это гарантирует срыв сроков и риски получить адовое наследие в будущем;
- рассчитывает оптимизировать проект в процессе. Шанс, что получится — мал. Риски — см. предыдущий пункт.
Встречи и разговоры полезны не только для выбора подрядчика. Но и для расширения собственного кругозора. Даже простой получасовой разговор с экспертом может подсветить, что вам нужно на самом деле.
Приносите подрядчикам не формализованные задачи, а свои цели. Настоящие инженеры работают именно с такими вводными.
Как вести диалог
Ни одна Спецификация или ТЗ не помогут создать качественное ПО, если вы не определили цели разработки продукта и не придумали способ замерить их достижение. У одной задачи «хотим сделать интернет-магазин» могут быть разные цели — увеличение выручки/маржи, повышение конверсии входящих лидов в продажи, снижение издержек на оформление заказов, сбор данных о пользователях для более эффективного планирования производства и тд. Целей может быть несколько и у каждой должен быть численный показатель.
Хорошо, если вы, как бизнес-заказчик, перед встречей с командой разработки точно знаете цель мероприятия. Команда, которая настроена на лучший результат, обязательно спросит о ней. Если же у вас есть только задача — назначьте встречу с разработчиком лично и обсудите детали проекта. Но начать нужно с правильных вопросов. Приведу пример из практики нашей команды. Действующие лица — Заказчик (З) и команда itMegastar (itMS).
З: Наша компания занимается производством мебели для премиум-сегмента. Нам нужен интернет-магазин. Вы уже седьмая компания, с которой мы обсуждаем этот проект. Сколько решение будет стоить у вас?
itMS: Давайте начнем с задачи — создать интернет-магазин. Чтобы набрать чуть больше информации и не ограничивать себя одним инструментом, расскажите о ваших целях. Для чего именно нужен интернет-магазин?
З (недоуменно вскинув бровь): Ну очевидно, чтобы продавать через него мебель. Вы уверены, что разбираетесь в своем деле?
itMS: Разбираемся в своем, поэтому хотим разобраться и в вашем проекте. С какой целью вы хотите его разработать? Повысить доверие к бренду, увеличить выручку, оптимизировать затраты на продажу? Или у вас есть конкретная цель от акционеров?
З: Конечно, есть — акционеры поставили нам задачу «прокачать дилеров».
itMS: А как вы сейчас продаете?
З: Мы производим мебель на собственной фабрике и выпускаем каталоги. У нас три салона в Москве и несколько дилеров, которые выкупают экспозицию и продают нашу мебель по всей стране.
itMS: Мы правильно понимаем, что через сайт вы собираетесь продавать мебель напрямую?
З: Конечно, это же наш интернет-магазин.
itMS: Продавать планируете по дилерской цене?
З: Да, это же наша мебель.
itMS: Какая доля выручки идет через дилеров?
З: Почти 90%
itMS: Получается, вы хотите продавать свою мебель потенциальным клиентам дилеров по всей России дешевле, чем продают они? Фактически дилеры превратятся в ваши выставочные залы и не будут иметь выгоды с продаж — клиенты будут покупать у вас через сайт по цене ниже, чем у дилера. Верно?
З: Получается, верно…
Так в процессе диалога мы выяснили, что точка роста клиента на самом деле — не привычный интернет-магазин, а новое решение, которое должно упростить продажи дилерам:
- личный кабинет дилера, включающий: складские остатки, информацию о сроках производства и поставки каждого предмета мебели, информацию об акциях, распродажах и спец. условиях для каждого дилера, включая мотивационные программы;
- онлайн-каталог для клиента, который позволяет собирать виш-листы и отправлять их на почту. Это оказалось совершенно новым решением — раньше клиенты приходили смотреть мебель в салон и листали толстенный дорогой каталог, обновление которого стоило очень дорого. Теперь клиенты получали вместо бумажного каталога iPad, на котором можно посмотреть весь объём доступной мебели, а не только то что представлено в экспозиции;
- отправка клиенту всех необходимых сведений. Вместо бумажных визиток салона, судьба которых после получения остается неизвестной, необходимости делать фото страниц каталога и тд, клиент будет получать контакты дилера и список ссылок на любые интересующие его модели из онлайн-каталога письмом на электронную почту;
- вишлист для онлайн-клиентов. Пользователь сайта получает возможность собрать все, что понравилось, в один список, распечатать его и отправиться к дилеру.
В результате внедрения решения заказчик сократил средний цикл продажи в два раза — с 60 до 30 дней. Дилеры стали лучше понимать склад производителя, начали пользоваться программой мотивации. Как следствие значительно сократились затраты на управление складскими остатками. Клиентская база стала пополняться новыми контактами, а сделка перестала обрываться после первого взаимодействия.
Резюме
Выбрать надежного подрядчика не так сложно. Если вы подготовитесь и подойдете к процессу ответственно — хорошая команда обязательно найдется. Главное:
- Сформулируйте первичные цели. Если это не получается сделать самим — пригласите специалиста или приходите к нам. Наши аналитики и бизнес-партнёры помогут выявить конечную цель с помощью правильных вопросов и предложат релевантное решение.
- Определите наиболее эффективный способ синхронизации с инженерами. Например, при разработке приложения это могут быть прототипы с комментариями и пользовательскими сценариями + описание сущностей с которыми работает приложение. Выбираемый способ, конечно, зависит и от уровня компетенций команды и от количества участников в процессе.
- Определите последовательность реализации функционала. Тут удобно думать инкрементами — ограниченным объёмом функционала, который добавляет пользу бизнесу и пользователям. Таким образом появится последовательный план разработки и наращивания функционала.
- Охраняйте этап работы от изменений, пока он не закончен или не бойтесь прекратить его и спланировать следующий.
- Проговорите с командой разработки, когда и какие документы и материалы появятся, как будет проходить демонстрация результатов — это и вам и им поможет оставаться в графике.