Первый прототип должен хорошо работать. Ничего страшного, если на стороне есть какие-то ошибки, но основные функции должны быть в рабочем состоянии. Он должен выглядеть как минимум нормально, иначе вы просто оттолкнете людей. Минимум должен быть минимум хорошим.
В своей предыдущей статье я писал о том, что моей команде нужен простой инструмент, позволяющий членам команды уведомлять своих коллег, когда их нет в офисе. Кроме того, потребность в таком инструменте возникла как раз в то время, когда была выпущена makebook Питера Левела, открывшая путь для запуска самонастраиваемых продуктов. Эта серия посвящена подробному описанию пути решения потребностей моей команды с соблюдением шагов, изложенных в makebook.
Потратив последний месяц на работу над этим продуктом, я теперь нахожусь в таком месте, где могу вспомнить процесс сборки. Я подробно расскажу, почему я разработал его сам, следуя совету Питера, что я создал (и что я решил не создавать) и, наконец, инструменты / фреймворки, которые я использовал.
BIY
Создайте сам - в Makebook сделан сильный акцент на создании продукта самостоятельно. Главное преимущество в этом - ваша скорость.
Для меня небольшая настройка или исправление ошибки займет всего несколько минут, потому что я могу сделать это сам. Но для [кого-то, кто выбрал аутсорсинг] каждая настройка доставляет сообщение вашему разработчику, который затем должен работать в этот день (и проснуться!), Чтобы исправить это. Возможно, ему придется встретиться по этому поводу со своей командой. Так что это может занять несколько часов, дней или недель. - Питер Левелс
В качестве самостоятельного загрузчика цикл между отзывами клиентов, командой разработчиков (вами) и новой функцией / исправлением настолько тесен, что вы быстро реагируете на внешние события. Эта маневренность - самое большое преимущество соло-бутстраперов. Как внештатный разработчик по профессии, было предрешено, что я буду создавать продукт сам. Примечание. Существуют также отличные ресурсы для создания MVP без написания кода самостоятельно или привлечения внешних разработчиков.
Holibobs
Я создал продукт Holibobs: бот Slack, который взаимодействует с написанным мной API или серверной частью. Когда пользователь в Slack нажимает кнопку, он отправляет сообщение моему внутреннему API, который, в свою очередь, отправляет ответ API Slack, который затем отправляет сообщение пользователю. Именно с помощью этого (концептуально) простого потока можно построить целый рабочий процесс, ценный для команд.
В текущей форме MVP команды и пользователи могут делать следующее:
- Отпуск, удаленная работа или болезнь
- Измените указанные выше типы отпусков
- Просмотр, когда другие члены команды не будут в офисе
Есть много-много дополнительных функций, которые можно добавить, но цель здесь заключалась в том, чтобы выпустить что-то как можно быстрее - а это все равно заняло у меня месяц! Возможно, более важным, чем то, что я построил, является то, что я не строил. Я не строил:
- Утверждения - любой член команды может добавить свой отпуск без одобрения. Хотя это нормально для небольших команд, это не отражает более широкий рабочий процесс того, как обрабатываются праздничные запросы в средних и крупных командах. Текущая сборка идеальна только для команд, где обсуждение для утверждения ведется за пределами рабочего процесса Holibobs, а затем пользователь сам входит, чтобы указать это.
- Уведомления - в настоящее время нет уведомления, когда пользователь вводит свой отпуск, или уведомления в определенный день, если член команды отсутствует. Это можно относительно быстро реализовать, но не требуется для MVP.
- Инструменты администратора - в настоящее время нет высокоуровневой информации, которую могли бы использовать руководители групп, чтобы понять, сколько отпусков пользователи берут. Кроме того, нет концепции ограничения отпуска (в настоящее время пользователь может взять отпуск на целый год 🤐)
Все вышеперечисленное сделает приложение более ценным для команд. Однако перед тем, как начать создавать эти вещи, мне нужно проверить гипотезу о том, что люди предпочтут трекер праздников на основе Slack.
Инструменты
Я твердо верю, что прямо сейчас вам следует использовать тот инструмент, который вам больше всего подходит. Какой инструмент вы уже знаете? Вы когда-то уже работали с Руби? Это было весело? Используйте это. Вы уже работали с PHP? Тогда используйте это. - Питер Левелс
В моей повседневной работе я в первую очередь разработчик JavaScript, так что это язык, который я использовал для всего.
Мой API: Serverless NodeJS на AWS Lambda. Написание функций AWS Lambda избавляет меня от необходимости выполнять непрерывную работу по DevOps, что должно позволить мне продолжать работать над продвижением вперед, а не поддерживать то, что уже было написано.
Моя домашняя страница: приложение для реагирования, построенное на NextJS для использования преимуществ рендеринга на стороне сервера (любая страница администратора будет построена в React, поэтому я решил начать здесь, а не мигрировать в будущем. Я использовал NextJS специально, потому что мне может понадобиться хорошее SEO в будущем. Я признаю, что здесь, возможно, было немного переборщить. Я мог бы использовать что-то вроде Squarespace для создания целевой страницы, но, учитывая, что я глубоко разбираюсь в React, это было не слишком Возможно, вы могли бы возразить, что любой вид объезда - это слишком большой объезд, но, по иронии судьбы, я отвлекся).
Прочие инструменты:
- Gitlab - Бесплатные частные репозитории
- Namecheap - Простая регистрация доменного имени
- Google Analytics - не требует пояснений, чтобы понять трафик.
- Mailchimp - Чтобы начать создание списка рассылки - вы можете зарегистрироваться здесь 👍
- Mockuphone - Классный проект по подготовке скриншотов для лендингов.
Поразмыслив, я уже знал JavaScript и React, но и AWS Lambda, и Slacks API были для меня совершенно новыми, что замедлило мое время до завершения MVP. Уже существуют некоторые фреймворки для создания ботов (SlackDevKit и BotKit, чтобы назвать пару), однако с помощью некоторых ранних экспериментов я обнаружил, что при входе в новый домен и построении бизнеса на нем вы действительно не делаете этого. Не хочу слишком отвлекаться от гаек и болтов. Я потратил 10 минут на внедрение SlackDevKit, а затем (буквально) дни, пытаясь отладить его, когда он не работал так, как я надеялся.
