Это сообщение изначально появилось на моем веб-сайте.
Где-то в прошлом году у меня появилась идея для приложения: клон Google Docs, в котором документы будут сохраняться в виде простых текстовых файлов организационного режима. Взволнованный, я сразу же бросился в глушь, написав сложный API, который будет анализировать файлы организационного режима и использовать операционное преобразование для поддержки редактирования в реальном времени несколькими пользователями.
В начале у меня был большой прогресс, но через несколько месяцев я уже почти не думал об этом. У меня не было какого-то важного события в жизни, я не наткнулся на техническую стену и не изменил свое мнение об этой идее (я все еще думаю, что она хорошая). Проект просто… умер.
Эта история определенно не является исключением для меня; Я забросил так много побочных проектов, что заслуживаю степени в отказе от побочных проектов. Опираясь на этот богатый опыт, я заметил общую закономерность, которая почти всегда заканчивается неудачей:
1. Начните с бесспорно отличной идеи: Hacker News для астрологов!
2. Определите техническую архитектуру поддержки: Мне понадобится REST API, поддерживающий ссылки, комментарии, пользователей, карму и т. д.
3. Реализуйте базовую логику: Невозможно начать работу над SPA, пока API не будет завершен!
4. Недолго поработать, а затем потерять интерес: Я занимаюсь этим уже две недели, и все, что у меня есть, — это API без интерфейса…
Понятно, что причина гибели этих проектов — отсутствие мотивации. Но мы можем копнуть глубже. Почему именно я потерял мотивацию, работая над этим приложением для документов?
Как я уже сказал, я в некотором роде эксперт по отказу от сторонних проектов. И я могу вам сказать, что проекты, которые живут дольше всего, — это те, которые знают, куда они направляются. Пока что в примерах мы видели проекты, которые начинаются с неясной или амбициозной цели и без каких-либо ступенек на пути к цели. путь. Вместо этого начните с небольшой части функциональности, которую можно реализовать за две недели или меньше. Успешные проекты следуют следующему шаблону:
- Начните с насущной проблемы: астрологам нужно специальное место для обмена астрологическими новостями.
- Придумайте самый быстрый способ решить хотя бы часть проблемы: Для начала достаточно анонимного сайта обмена ссылками. Мы можем обрабатывать голосование, ранжирование, комментарии, учетные записи пользователей и т. д. позже.
- Выберите техническую архитектуру, которая напрямую поддерживает эту функциональность: приложение CRUD на основе форм подтвердит концепцию.
- Реализуйте эту крошечную функциональность одним махом.
- Наслаждайтесь славой доставки продукта.
Видите, насколько это более сфокусировано? Даже учетные записи пользователей удаляются и оставляются на потом. На создание полнофункционального клона Reddit или Hacker News уйдет несколько недель работы, но это можно сделать за полдня.
Чтобы работать таким образом, нужно думать как пользователь. Пользователям не важна архитектура. Пока они не начнут пользоваться вашим приложением, их не будут волновать отсутствующие функции. Пользователей волнует только то, решает ли ваше приложение их проблему или облегчает ли им жизнь. Тщательный взгляд с их точки зрения — отличный способ разбить ваш проект на крошечные достижимые кусочки, значительно увеличивая его шансы на выживание.
Спасибо за чтение! Если вас привлекает такое мышление как пользователь, возможно, вас заинтересует моя будущая электронная книга Building Tech in the Wilderness, которая научит вас, как использовать ориентированную на пользователя перспективу в качестве карты, чтобы не сбиться с пути, получить выйти из трудных ситуаций и сделать свой проект максимально
возможным.
И если вам понравилась эта статья, пожалуйста, подпишитесь на мою рассылку!
