Закулисье разработки MVP - минимального жизниспособного продукта

Как происходит разработка MVP. Как я пришел к этому и какую роль выполняю в разработке.

Закулисье разработки MVP - минимального жизниспособного продукта

Предисловие

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

С чего я мог начать не умея делать верстку, не зная javascript  и имея лишь устаревшие знания php.  Конечно же с поиска инструментов для быстрого создания сайтов, поиска исполнителей и с наращивания клиентской базы. Благо, клиентская база у меня уже была и я мог найти хоть 100 заказов за день благодаря моему некоторому лайф хакингу + моей бывшей профессии 1с программиста.  Оставалось только научиться делать сайты.

Я сразу же записался на онлайн курсы по созданию Landing Page на adobe muse и параллельно изучать науку написания продающих текстов. Вступил в копирайтерскую лигу Павла Берестнева и начал получать ценнейшие знания, оттачивая их на практике.

Поняв, что дизайн — это не мое, я углубился в поиск подходящей cms для быстрого разворачивания сайтов. Мой выбор пал на MODX REVO — милая CMS с удобной админкой, которая в те года подавала надежды на лидерство мирового масштаба среди CMS. Как же я ошибался…

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

Года два-три я этим занимался, когда однажды мне заказали совсем другой сайт — сайт с кабинетами. Я понял, что обычной cms тут не хватит и мой выбор пал на Laravel + vuejs.

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

Дальше ко мне обратились с просьбой сделать кабинеты для обменников. Я легко справился с этой задачей и пошел дальше. Мне заказали написать калькулятор для расчета банковских гарантий. Два года я пробыл на этом проекте. Очень сильно вырос профессионально и потом с легкостью нашел работу, где тоже с нуля планировали делать MVP. Меня охотно взяли, я поделился с ними своими заготовками и мы начали пилить крутой онлайн сервис опять же с кабинетами и морем аналитики. Немного погодя мой напарник полностью взял на себя весь фронтэнд, а я начал заниматься чисто бэкэндом на Laravel и приобрел полное счастье и гармонию.

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

Сейчас у нас есть отточенная схема по разработке минимальных жизнеспособных продуктов для стартапов и мы планируем идти очень далеко.

Роль в разработке Бэкэнд программиста

 

Мнения могут разделяться, но я считаю, что наиболее большая ответственность все же ложится на бэкэнд разработчика. Бэкэнд программист не виден пользователю, но он выполняет очень непростую работу. Если фронтэнд разработчик — это как актер, который работает по написанному сценарию и приносит удовольствие зрителям, то бэкэнд разработчик остается в тени, но именно он должен быть готовым к росту проекта и к большим нагрузкам. Если его знаний не хватит на то, чтобы вырулить highload проект, то он потерпит крах в своей карьере. В связи с этим он вынужден постоянно совершенствоваться и готовиться к непредвиденному. Изучать другие языки программирования и технологии, которые ему помогут закрыть узкие места в проекте, например, делать вставки кода других языков более быстрых или делегировать выполнения некоторых ресурсоемких задач на сторонние высокомощные сервера. Так же он должен обеспечить защиту проекта от взломов — не допускать ошибок и даже уметь настраивать сервер. Я вот все это изучаю в непрерывном режиме. А картинку на сайте можно менять раз в год и пользователям конечно будет приятно, но опять же — это не такая сложная и ответственная работа. Весь интерфейс могут продумать дизайнеры в команде с маркетологами. А на реализацию его уйдет не так уж много времени. А работа у бэкэнд программиста будет всегда и чем больше становится проект, тем тяжелее будет им управлять. Но я люблю свою работу и я очень рад, что у меня есть напарники, которые берутся за такую работу, которую мне делать не хочется.

 

Как же проходит процесс разработки MVP у нас?

 

Расскажу на примере разработки торговой площадки. У нас есть технический писатель — он пишет тех задания постоянно контактируя с самим заказчиком. Изучает предметную область и старается переложить ее на язык понятный программисту. И рисует интерфейсы, что тоже очень важно. Его можно назвать IT аналитиком.

 

Есть фронт энд разработчик с хорошими скиллами. Он умеет оптимизировать код фронтэнда, писать сложные компоненты на javascript и прекрасно разбирается в бэкэнде.

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

 

От 3 до 5 раз в неделю проходят онлайн планерки через skype или zoom и мы обсуждаем вопросы, создаем мозговой штурм. Поскольку каждый из нас является опытным человеком в своем направлении и не только, то наши знания складываются в единую базу и принимается решения учитывая мнение каждого из нас. Далее определяются приорететы задач и каждый в трелло создает списки подзадач, которые он должен выполнить и так же делегирует задачи для других. В этой ситуации как раз я являюсь исполнителем, потому что фронтэнд разработчикам необходимо получать данные с бэкэнда и они мне пишут названия функций, список параметров, которые они мне передают и список параметров, которые я им должен вернуть. А я одну за другой выполняю эти подзадачи. Но это лишь верхушка айсберга. Для того чтобы мне написать функцию, которая вернет им то что они должны отрендерить на фронтэнде мне необходимо создать нужные таблицы с полями в базе данных, установить связи между таблицами и написать хороший качественный легко читаемый код, который бы отрабатывал быстро и возвращал те данные, которые меня попросили. Но я еще должен писать код так, чтобы мой напарник легко разобрался в моем коде если меня не будет на месте и я частенько даже не использую сложные конструкции языка именно по этой причине — код должен быть легко читаемым. Ну и нужно писать так код, чтобы проект можно было масштабировать и легко поддерживать. А для этого необходимо читать книги про проектирование, про правильную архитектуру веб-приложений. Нужно знать наизусть основные алгоритмы, а не изобретать велосипеды, нужно знать Паттерны проектирования и стараться следовать им. Иначе проект превратится со временем в помойку и его будет очень тяжело дорабатывать и поддерживать. Как говорится «В одном месте подкрутишь, из другого места говно выльется».

коммент.

Написать комментарий

Ваш email не будет опубликован. Обязательные поля отмечени символом *