Как предприниматель может сорвать разработку собственного продукта

Недооценить важность участия в процессе

Слишком часто передача разработки на аутсорс означает лишь то, что несколько программистов пишут код где-то в другом месте. Такие понятия, как владелец продукта (product owner) и контроль качества, либо игнорируются из-за строгой финансовой политики, либо просто забываются до тех пор, пока не станет слишком поздно.

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

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

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

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

Мало общаться с разработчиками

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

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

Ответ — никто. Но есть ли у вас на это время?

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

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

Не было бы здорово иметь на такой случай человека, ответственного за коммуникацию с разработчиками? Кого-то, кто может координировать их действия. Кого-то, кому вы действительно доверяете.

Я видел это сотни раз. Рано или поздно возникнет ситуация, в которой понадобится такой сотрудник на фултайме. У успешных основателей стартапов никогда не бывает достаточно времени для этого, так как они заняты сотней других дел. А стоимость задержки при решении какого-либо технического вопроса может быстро превысить экономию на найме представителя компании.

Фото: Unsplash

Отказываться принимать факты

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

Что можно сделать в такой ситуации?

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

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

Есть как минимум два варианта поведения в такой ситуации: поступиться качеством или объемом работы. Программисты настаивают на последнем. К сожалению, слишком многие владельцы бизнеса просто отказываются принять это трудное решение в надежде, что «разберутся со всем потом». Иногда так происходит, но чаще всего нет. Признать, что план был слишком амбициозным, сложно, но цена промедления окажется слишком велика.

Хорошее практическое правило — предполагайте, что 40% задач еще не обнаружены, и оставляйте для них немного свободного времени.

Неправильно создавать MVP

Мы живем в эпоху agile- и lean- разработки программного обеспечения, времена традиционного управления проектами давно прошли. Термин MVP (minimum viable product — минимально жизнеспособный продукт) известен многим, но далеко не все на самом деле понимают, что значит создавать MVP.

Задумайтесь об этом.

• Будет ли продукт использоваться реальными клиентами? Вероятно.
• Будете ли вы добавлять новые функции в будущем? Определенно.
• Хотите показать покупателям сырое решение? Ни за что.
• Должно ли это быть красиво? Абсолютно точно.
• А высококачественно? Да.

Хм... Вы действительно так считаете?

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

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

Определение правильных бизнес-целей на каждом этапе разработки имеет решающее значение.

Фото: Unsplash

Следить за каждым шагом разработчиков

В своей знаменитой книге «Драйв: что на самом деле нас мотивирует» Дэниел Пинк выделяет три основных фактора мотивации: автономность, мастерство и цель. Всем известно, что контроль за каждым шагом людей убивает в них желание превзойти ожидания. В итоге разработка замедляется, потому что все теряют из виду цель. Так почему мы это делаем?

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

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

Обращать недостаточно внимания на маркетинг и PR

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

Распространено мнение, что MVP необходим для получения финансирования, проведения маркетинговой кампании и привлечения первых пользователей. Однако большинство успешных предпринимателей доказали, что это не так. Я призываю вас прочитать историю Mint, которая использовала посты в блоге, чтобы получить 20 тысяч клиентов перед запуском, или Robinhood, которая создала список ожидания из более чем миллиона людей (всю статью можно найти здесь). Вместо того чтобы чрезмерно оптимистично относиться к своему MVP, эти компании создали напряжение и преданную аудиторию, что дало разработчикам достаточно времени на завершение продукта.

Заключение

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

Источник.