В своем заключительном отчете по курсу Управление инновациями в Западном университете я хотел задокументировать процесс создания чего-то, что люди, надеюсь, будут использовать. Я собираюсь попытаться создать идею продукта всего за несколько дней, используя некоторые методологии, которые я изучил на нашем курсе за последние четыре месяца.
Проблема
Как разработчик, я использую Git для управления своим рабочим процессом, версии моего кода и совместной работы с моей командой. Несмотря на то, что я быстро печатаю, единственное, что ограничивает мою производительность, — это необходимость открывать терминал и вводить те же три команды Git, чтобы поделиться своим кодом с моей командой. Обычно это:
git add . git commit -m "made these changes: etc etc" git push
Хотя открыть терминал и быстро выполнить эти команды, как ниндзя, кажется крутым, в конце дня это отвлекает меня от работы и становится препятствием.
Проверка
Чтобы убедиться, что я не сумасшедший, ставший единственной жертвой этой проблемы, я решил найти людей, которые согласны со мной, и узнать, каковы их решения. Я сделал следующий пост в группе Hackathon Hackers в Facebook, в которой насчитывается более 44 тысяч разработчиков-миллениалов; мой потенциальный целевой рынок. Я также сделал идентичный пост в сабреддите Git.
Прежде чем я перейду к обсуждению ответов, давайте обсудим некоторые концепции из ДНК инноватора: овладение пятью навыками прорывных инноваторов.
Анализ
На этом этапе особенно важны два навыка: задавать вопросы и наблюдать. В культуре разработки GUI (графические пользовательские интерфейсы) обычно не нравятся. Разработчики, как правило, предпочитают вводить команды в терминал, а не щелкать по графическому интерфейсу, который выполняет ту же задачу. Два важных вопроса привели меня к решению этой проблемы и проверке моего решения:
Почему разработчики предпочитают интерфейс командной строки Git графическому интерфейсу?
Я виновен в этом, и помимо того, что задал этот вопрос через общественное достояние, я также наблюдал, как разработчики используют интерфейсы командной строки по сравнению с графическими интерфейсами. Снова и снова я был свидетелем того, как разработчики возились, перемещая руку всего на несколько дюймов, чтобы дотянуться до мыши или трекпада. Они всегда казались разочарованными, когда им приходилось переходить от использования клавиатуры к мыши. Я легко это понимаю. Когда вы пишете код, вы работаете с клавиатурой, поэтому вы более склонны использовать сочетания клавиш и горячие клавиши, которые быстрее используются и более доступны, несмотря на то, сколько оперативной памяти требуется, чтобы запомнить все комбинации кнопок.
Одна из самых неприятных вещей во время утренней пробежки — это необходимость останавливаться на красный сигнал светофора, чтобы дождаться, пока пешеходный переход станет белым.
Необходимость прекратить быстрое кодирование и интенсивный набор текста, чтобы дотянуться до мыши, чрезвычайно разочаровывает. В результате разработчики склонны отказываться от красивых и интуитивно понятных графических интерфейсов в пользу интерфейсов командной строки. Легче нажать CMD + Tab, чтобы переключиться на терминал и ввести там свои команды.
В результате этого предпочтения интерфейсов командной строки, поскольку они быстрее и требуют меньшего количества переключений периферийных устройств, я решил задать этот вопрос:
Что, если бы для Git существовал графический интерфейс, который был бы быстрее и требовал меньшего переключения контекста, чем использование аргументов командной строки?
Что ж. Оно делает. Множество IDE и текстовых редакторов имеют интеграцию с Git, которая позволяет использовать горячие клавиши в средах разработки и автоматически выполнять команды Git.
Это фантастика, за исключением одной серьезной проблемы: только две или три команды обычно сопоставляются с горячими клавишами, что сильно ограничивает функциональность Git как системы контроля версий. Таким образом, использование этих интегрированных инструментов Git не обеспечивает полной функциональности Git и лишает некоторых функций, которые делают Git предпочтительным инструментом, когда разработчики в первую очередь хотят версионировать свой код. Какой смысл использовать Git, если вы не собираетесь использовать функции, которые дают ему преимущество?
Результаты моих постов также подтверждают эту гипотезу. Было получено более 30 ответов от инженеров-программистов в Google до программистов-любителей из средней школы и университета. Ответы были разными. Главный вывод, однако, заключался в том, что командная строка работает быстрее, но интегрированные среды разработки великолепны, потому что они еще быстрее и требуют меньшего переключения контекста. Кроме того, интегрированные среды разработки также предоставляют некоторые преимущества графического пользовательского интерфейса, показывая визуальные изменения в самом текстовом редакторе.
Разработчики также склонны привязываться к экосистеме, которую создает их IDE. Все большее число текстовых редакторов и сред разработки имеют возможность включать подключаемые модули и дополнения к программному обеспечению, которые позволяют сторонним разработчикам добавлять в редактор полезные функции.
Возможность создать экосистему с вашим продуктом имеет решающее значение для успеха не только этого продукта, но и всей вашей будущей линейки продуктов. Apple славится мастерством в этом. Возможность интеграции iMessage во все ваши продукты Apple, чтобы вы могли продолжать одни и те же разговоры на любом устройстве, возможность совершать покупки с использованием одних и тех же методов Apple Pay и совместная работа всех ваших устройств, как часовой механизм, и значительно повышает ценность продукты. Один продукт конкурента, который не соответствует другим вашим продуктам, заставляет его торчать, как больной палец, и не вяжется с вашим типичным вариантом использования продукта.
Классическая головоломка Microsoft Office и Google Drive также является примером того, насколько мощными могут быть экосистемы в программном обеспечении. У каждого студента Западного университета был один профессор, который настаивал на использовании только формата .docx для всех своих документов. Несмотря на то, что хранение и редактирование в Dropbox или Google Drive было огромной проблемой, как вы можете винить этого профессора? Вероятно, они используют полноценный пакет Microsoft Office, в котором используется их собственный тип документов. Microsoft One Drive без проблем работает с файлами .docx. Устойчивость к выходу из этой экосистемы настолько сильна, что профессора настаивают на том, чтобы заставить сотни студентов и коллег приспосабливаться к их рабочему процессу, а не просто загружать PDF-файлы, как все остальные.
Теперь это мощно.
Не интуитивно переключаться на другую программу или окно только для того, чтобы использовать один инструмент разработки, Git, который отделен от всех других инструментов разработки. Было бы полезно использовать API, предоставляемые IDE и текстовыми редакторами, поскольку это позволило бы интегрировать мой продукт в экосистему других плагинов и дополнений, которые разработчики уже могут использовать.
Решение
В связи с этим я решил создать продукт, который приносит следующие преимущества:
- Предоставляет все функции, которые предоставляет Git.
- Требует минимальных усилий/контекстного переключения
- Работает быстрее, чем команды терминала
Используя эти знания, стало очевидно, почему разработчики используют среды разработки или текстовые редакторы с большой поддержкой плагинов. Разработчики предпочли бы, чтобы служба Git была встроена в их среду, а не переключалась в новое окно только для того, чтобы использовать Git.
Здесь в игру вступает сенсорная панель Apple. Новейшее дополнение Apple к линейке MacBook Pro — Touch Bar; контекстно-зависимая сенсорная полоса, заменяющая исходную функциональную полосу в MacBook предыдущего поколения. Благодаря этому у разработчиков появилось множество возможностей для создания новых функций для настольных приложений на macOS.
Я планирую создать интеграцию для Touch Bat в текстовом редакторе или IDE, которая упростит использование Git разработчиками. Поскольку дисплей сможет отображать интуитивно понятные значки всех функций, которые есть в Git, мне не нужно полагаться на то, что потребители запомнят большое количество сочетаний клавиш только для того, чтобы получить полную функциональность. Кроме того, сенсорная панель будет намного быстрее в использовании, чем открытие терминала и ввод команд. Команды доступны всего одной кнопкой с помощью сенсорной панели.
Прогнозы
Сенсорная панель — это новый продукт, а это означает, что сам инструмент в настоящее время приобретается ранними пользователями. Это может быть узким местом для потенциальных клиентов инструмента Git для сенсорной панели. Я могу использовать модель распределения Bass, чтобы предсказать успех такого инструмента разработки. Поскольку Apple не опубликовала данные о продажах своего нового продукта, я могу либо использовать данные о продажах старых ноутбуков, либо дождаться публикации информации в конце их финансового периода.
С помощью этой информации в сочетании с оценкой количества пользователей MacBook, которые также являются разработчиками программного обеспечения, и числа разработчиков программного обеспечения, использующих Git, я могу приблизительно определить размер рынка. Отсюда я могу установить коэффициент инновации, сравнив его с моделью распространения Bass для аналогичных продуктов, таких как принятие Touch ID и считывателей отпечатков пальцев с принятием Git в качестве системы контроля версий. Наконец, я могу использовать коэффициент имитации, полученный из моделей распространения Bass, в других инструментах разработки, таких как некоторые популярные плагины Sublime Text, чтобы увидеть, как большая часть рынка отреагирует на продукт, используемый ранними пользователями.
Приложение
