Категории
Самые читаемые
PochitayKnigi » Бизнес » Менеджмент и кадры » Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - Джефф Лоусон

Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - Джефф Лоусон

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

Шрифт:

-
+

Интервал:

-
+

Закладка:

Сделать
1 ... 31 32 33 34 35 36 37 38 39 ... 79
Перейти на страницу:

2. Если вам невероятно повезет, будет ли результат крупным? Задача – вырастить большое дерево, поэтому старайтесь выяснить, есть ли у семени, которое вы сажаете, такой шанс в случае успеха.

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

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

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

Затем определите показатели успеха. Эрик Рис предельно ясно показывает, как сделать это, поэтому прочтите его книги «Бизнес с нуля» и «Метод стартапа»[5], чтобы познакомиться с тем, что он называет «инновационный учет». Короче говоря, небольшой команде нужен набор показателей, чтобы определить, как выглядит успешный результат эксперимента. Учтите, что это не долгосрочные бизнес-показатели, а краткосрочные результаты экспериментов. Эрик называет это проверкой слепых предположений.

Когда команда оценит возможность (пункт 2 выше), она обычно строит модель с горизонтом 5–10 лет, опирающуюся на расчеты: «Если у нас будет 1000 клиентов, которые заплатят нам по $500 000 за пять лет, то это превосходно». Примерно так определяют, заслуживает ли эксперимент финансирования. Но следующий шаг – это не создание бизнеса стоимостью $500 млн, а проверка обоснованности допущений в этой модели, а именно: 1000 клиентов и доход $500 000 от каждого.

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

Но если вы не сможете найти даже одного клиента или если вы найдете клиента, но он согласится платить только $1000 в год вместо $500 000, то это проблема. Или если клиенты платят нужные суммы, но в мире существует лишь 10 компаний, у которых есть потребность в вашей услуге, то это проблема.

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

Другой ключевой момент связан с тем, что ваша гипотеза не является технической или научной. Чтобы понять это, вспомните некоторые известные эксперименты. Томас Эдисон в лаборатории, пытаясь сделать работоспособную лампочку, выдвинул научную гипотезу: свет можно получить, пропуская электричество через нить накала. Он проверил более 3000 материалов, чтобы доказать эту гипотезу. У братьев Райт также была техническая гипотеза: профиль крыла – вот что позволяет летать. У них были предположения о профилях крыла и о том, как они могут влиять на воздушный поток и подъемную силу. Эти предположения нужно было проверить в практических экспериментах.

Это научные гипотезы. В случае ПО ответ на научную или техническую гипотезу – «Компьютерная программа может сделать то-то и то-то» – почти всегда положителен, его можно точно воспроизвести. Гипотеза, которую вы на самом деле пытаетесь проверить, – это бизнес-гипотеза о том, что клиенты будут платить за компьютерную программу, которая делает то-то и то-то, или, еще шире, о том, что компьютерная программа, которая делает то-то и то-то, принесет нам больше денег.

Любая электронная таблица с прогнозом бизнес-перспектив нового продукта или инициативы является гипотезой – буквально заполнена числами, полна предположений. Эти предположения тестируются в небольших масштабах при небольших затратах. В мире, живущем по принципу «Создай или умри», вы на самом деле экспериментируете не с ПО, а с самой компанией: «Как наша компания может расти? Какие продукты мы должны производить?»

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

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

Энтузиазм – это здорово, и великие дела часто начинаются именно с него, но вам не следует двигаться дальше, пока вы не превратите идею в бизнес-гипотезу. Без этого вы не будете знать, для чего проводится эксперимент. Успех или неудача будут неоднозначными, и вы просто останетесь с вопросом: «Это помогает делу?» Ответ на него почти всегда будет отрицательным.

Наличие гипотезы и набора предположений, которые нужно подтвердить или опровергнуть, – это отлично, но вам требуется описание этого, чтобы отслеживать прогресс. В Twilio одна из наших ключевых ценностей выглядит так: «Записывай», и эксперименты являются отличной возможностью для реализации такой практики. Исходная гипотеза нередко забывается, поэтому сохранение ее и результатов тестирования в письменном виде позволяет всем идти в правильном направлении. Возможно, именно по этой причине ученые и изобретатели ведут подробные лабораторные тетради. Я заметил, что, если эксперимент и его ход не документируются должным образом, люди (особенно мы, руководители) забывают контекст и возвращаются к разговорам вроде «Почему дело не двигается

1 ... 31 32 33 34 35 36 37 38 39 ... 79
Перейти на страницу:
Тут вы можете бесплатно читать книгу Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - Джефф Лоусон.
Комментарии