Дальнейшие этапы в создании Приложения после создания прототипа?

Здравствуйте.

Помогите разобраться. Делаю Приложение. Есть полное понимание и описание связей, что куда, как и для чего. Нарисовала прототип со связями-ссылками. И уперлась в стену.
Так как штука получилась большая, разделила её на части. Есть скелет, скелет разделен на сценарии, сценарии на блоки, типа сценарий входа, блок информации и т.д. Так как дальше самой уже сложно, вопрос - что делать дальше, к кому обращаться?
1. Дизайнер (человек красиво оформляющий всё нарисованное)
2. Программист (что за программист*).
* прочитала про бэкэнд разработчиков и … не совсем поняла – это узкая специализация программистов, они прям необходимы или достаточно одного грамотного программера?
3. Специалист по БД. Это один и тот же человек, что и код пишет?
4. Безопасность. Кто этим занимается, кто прописывает, кто разбирается. Это отдельный человек или навыков программиста достаточно.

Бюджет очень ограничен, поэтому студии однозначно мимо; советов ищу конкретно по заданным вопросам:

- последовательность дальнейших этапов, после полностью готового рабочего прототипа.

- самый-самый минимальный набор специалистов на эти последующие этапы, вплоть до полностью рабочего релиза (т.е. например, дизайнер, программист: ява/питон/С, ???).

Заранее благодарю всех откликнувшихся)

UPD. Благодарю всех за ответы, отметить лучший сложно - почти все по теме и пригодятся. Михаилу Р. и Oleg - отдельное спасибо за самые подробные развернутые ответы.

Дополнительно:

Ответы:

1. Дизайнер (человек красиво оформляющий всё нарисованное)

Дизайнер интерфейсов или дизайнер landing page (если речь про продающую страницу).

2. Программист (что за программист*).
* прочитала про бэкэнд разработчиков и … не совсем поняла – это узкая специализация программистов, они прям необходимы или достаточно одного грамотного программера?

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

3. Специалист по БД. Это один и тот же человек, что и код пишет?

Backend без отдельной специализации в проектирование БД, вполне потянет малый/средний проект.

4. Безопасность. Кто этим занимается, кто прописывает, кто разбирается. Это отдельный человек или навыков программиста достаточно.

Backend, но! Зависит от того, что Вы понимаете под "безопасностью". Если это безопасность приложения, то либо back, либо front (в зависимости, чья "территория"), если же это сетевая безопасность, то нужен сисадмин.

Бюджет очень ограничен, поэтому студии однозначно мимо

Рекомендую оплатить ТЗ от Software Architect, чтобы он расписал, что должен написать back и front.

- самый-самый минимальный набор специалистов на эти последующие этапы, вплоть до полностью рабочего релиза (т.е. например, дизайнер, программист: ява/питон/С, ???).

Если рассматривается MVP вариант, то:
- Сайт/лендинг: WordPress/WooCommerce (PHP, JavaScript).
- Нестандартное веб-приложение: Back (Python/PHP), Front (JavaScript/TypeScript).
- Мобильное приложение: Back (Python/PHP), Front (React Native/Flutter).

• Спасибо за ответ.
  Т.е. я правильно понимаю, что минимум это дизайнер, бэкэнд и фронтенд разработчики, 3 человека? А что первично: бэкэнд и фронтенд? И кого сначала искать дизайнера или разработчиков? Знание каких языков первичны?
• LiuY, дополнил ответ.
  
  

  Т.е. я правильно понимаю, что минимум это дизайнер, бэкэнд и фронтенд разработчики, 3 человека?

  Учитывая, что бюджет ограничен, то я бы вначале попробовал найти fullstack разработчика, с большей вероятностью - хуже одно/оба из направлений и дольше, но задача будет решена в "рамках одного разработчика" и вероятнее всего, дешевле (за счет разового объема работы).

  А что первично: бэкэнд и фронтенд?

  Бэк как минимум должен определить эндпоинты api и данные, которые будут пересылаться, после этого фронт, в целом, может писать клиент без оглядки на бэка (и наоборот).

  И кого сначала искать дизайнера или разработчиков?

  1. Менеджера проекта (это можете быть Вы), который определит, что вообще необходимо делать в общих чертах, и напишет под это тз так же в общих чертах.
  2. Дизайнера веб/интерфейсов, который по тз нарисует прототипы. Обычно, на этом этапе тз из п1. сильно изменяется.
  3. Back/Front.

  Ну и самое главное, в тз все предусмотреть не получится и всегда будет вероятность того, что разработчику поступит более интересный заказ, а доделывать "за кого то" обычно никто не любит, соответственно ценник начнет расти как на дрожжах. Заложите это в расходы.

• Спасибо, всё по делу без ненужных "кусаний" и критики)
  Прототип я сделала, в Бальзамике - этого будет достаточно? Те ТЗ, что я смотрела, на 60-70% мне понятны, сама напишу наверное. И фактически всё прописано у меня - я ж написала, что есть полное понимание (очень упрощенное), что "если А, то Б" и "записать в БД"). У меня затык именно к какому программеру со всем этим обращаться. Или сначала к дизайнеру.
• О вижу, Вы там по программистам дописали.
  Спасибо, ещё раз!
• LiuY, про общее вам пишут, добавлю как дизайнер: для качественного результата, чтобы выглядело всё в итоге как нарисовано в макетах, хорошо бы чтобы вся команда оставалась доступной до финала. Может быть так, что нарисованное дизайнером не получится реализовать разработчикам или возникнут необходимости доработки.

  И про прототипы/ТЗ вам верно пишут. Если вы не UI/UX специалист, не разработчик и т.п., то можете описать ТЗ/сделать прототипы некорректно. У исполнителей возникнут вопросы и либо они предложат корректировки ТЗ/прототипов, либо придётся искать ответы самостоятельно. Просто помните об этом и будьте готовы к тому, что может потребоваться доработка уже на этом этапе)

• LiuY,
  
  

  Прототип я сделала, в Бальзамике - этого будет достаточно?

  Это надо спрашивать у конкретных исполнителей, но выглядит нормально.

  Те ТЗ, что я смотрела, на 60-70% мне понятны, сама напишу наверное. И фактически всё прописано у меня - я ж написала, что есть полное понимание (очень упрощенное), что "если А, то Б" и "записать в БД").

  Бюджет начнет расти в момент обсуждения деталей. Не очень порядочные разработчики заранее закладывают от нескольких десятков процентов, которые попытаются снять с клиента, которому будет некуда деваться (коней же на переправе не меняют), да и доделывать никто дешевле не станет. Нормальный разработчик сразу сможет спрогнозировать, где возможно будет удорожание проекта, "если мы сделаем так, а не так".

  У меня затык именно к какому программеру со всем этим обращаться. Или сначала к дизайнеру.

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

  О вижу, Вы там по программистам дописали.

  Мысля не сразу вся загрузилась ;)

• LiuY, кстати лучше сразу договаривайся с разрабом, что он пишет и бэк и фронт + деплоит это всё и поддерживает, просто тех кто может написать фронт и бэк - куча народу, а вот кто поддерживать будет это, их не так уж и много)

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

• szQocks,
  
  

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

  Если MVP не выстрелит, то проект в любом случае закроют (не важно какой там код), а вот если выстрелит, то там можно выделить процент от прибыли с запасом на поддержку проекта. А на счет говно-кода, не опытный человек в любом случае не сможет определить самостоятельно, что там хорошо, а что не очень.

• Михаил Р.,
  

  а вот если выстрелит, то там можно выделить процен

  ну как аргумент)

  А на счет говно-кода, не опытный человек в любом случае не сможет определить самостоятельно

  - ну да, тут чёт я не подумал)

• Pavel Designer, подскажите, пожалуйста, что может быть такого, что будет в прототипе и не смогут сделать программисты? Программы прототипирования (а Бальзамик одна из них) навряд ли в своих инструментах содержат то, что не возможно реализовать программистам. Мне действительно интересно, что сложно реализовывается? У меня стандартно всё - кнопки, списки, закладки и т.д. Или Вы имеете ввиду именно внешнюю красоту, что будет наводить дизайнер? Мобильное приложение, должно быть прежде всего функционально, удобно. Изыски дизайнеров и красота здесь заменяется словом "приятный интерфейс, не вызывающий отторжения", кмк)
• Михаил Р.,
  
  

  Бюджет начнет расти в момент обсуждения деталей.

  У меня было время продумать все детали. Ну на 95-97% точно.

  Не очень порядочные разработчики заранее закладывают от нескольких десятков процентов, которые попытаются снять с клиента, которому будет некуда деваться

  От этого никуда не деться - просто живем с мыслью, что каждый хороший человек может оказаться нехорошим)
  За остальные советы спасибо. Тут ниже написали, что если т.к. у Мобильного приложения (а я его имею ввиду) есть ньюансы, в частности в приоритете разработчиков, но общий смысл мне ясен (процентов на 80))

• LiuY, обратите внимание, что моё сообщение состояло из двух частей и вы ошибочно смешали их воедино)

  Про сложности была первая часть, которая касалась ситуаций когда нарисовал дизайнер, а использовать сложно т. к. материалы требуют доработки для использования (например, какие-то эффекты или графика в растре вместо необходимого вектора) — вот тут могут возникать сложности. Я не говорю, что они обязательно будут. Разработчик может сам справиться, а может запросить доработки, если не умеет или не хочет выполнять работу дизайнера. Потому была рекомендация сохранить команду до релиза из-за возможных доработок, только и всего. Плюс другие вам тоже пишут про "сделал и попрощался", а дорабатывать некому.

  А о прототипах была вторая часть. Вы можете быть специалистом по интерфейсам или необходимым технологиям для разработки, а можете не быть. Сделанные прототипы могут быть идеальными для планируемого функционала, а могут не быть. Например, переключатели удобнее сделать не чекбоксами, а радио-кнопками, блок размещать не на этом экране, а на отдельном и тому подобное. Если специалисты по этим вещам скажут, что требуется доработка, то это нормально и обычное дело.

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

• Например, переключатели удобнее сделать не чекбоксами, а радио-кнопками

  Ну они всё же для разного предназначены (хотя я загуглила радио-кнопки, не знала, что они так называются). В моем случае чек-боксы стоят.
  В остальном - спасибо большое за ответы.

Оказывается я все же подвержен синдрому поля From :)
Вы можете мечтать сделать приложение. Долго писать ТЗ. Делать даже живые прототипы.
Но первое, что нужно оценить. Оно себя окупит или нет ?
Пробывать идеи через запуск MVP можно или когда денег много и шансы менее 1% вас устраивают или когда можешь сам сделать целиком.

• Но первое, что нужно оценить. Оно себя окупит или нет ?

  LiuY,

  советов ищу конкретно по заданным вопросам....

Для начала нужно определиться с платформой. Есть 3 варианта:
1. Сделать на Android. Нужен Android-разработчик (пишет на Java)
2. Сделать на iOS. Нужен iOS-разработчик (пишет на Swift).
3. Сделать кроссплатформенно. Нужен разработчики на Flutter (пишет на Dart) или React Native (пишет на JavaScript)

В тексте написано про бд и бекэнд. Значит нужен вебсервер с бд (Mysql, MariaDB, PostgreSQL , Firebase), к которому по api будет обращаться приложение. Тут нужен разработчик (Python или PHP ), который напишет обвязку к апи и спроектирует бд.

По дизайну: если у приложения есть уникальный дизайн - нужен дизайнер, знакомый со стайлгайдами каждой из платформ. При этом теоретически можно обойтись без дизайнера. Разработчик может собрать приложение из стандартных UI-элементов. Нужен дизайнер или нет - зависит от приложения. По вашему описанию непонятно.

Таким образом, если все делать по уму, нужно 2 разработчика: 1 пишет само приложение под выбранную платформу, 1 пишет апи и делает базу данных. Опционально - добавить сюда 1 дизайнера.

Можно попробовать найти 1 разработчика, который возьмет на себя как написание приложения, так и бэкенд. Это сложно + увеличиваются сроки разработки.

Крайне важно иметь бюджет. Без как минимум 200 тысяч рублей (если повезет найти студентов, готовых писать код за еду и обладающих мозгами) начинать не стоит. У вас нет никакого понимания того, что и как сделать. Значит неизбежно с вашей стороны будут доптребования по функционалу. За это придется доплачивать. Очень важно найдя разработчика/разработчиков максимально подробно объяснить им суть приложения и послушать их мнение по реализации функционала в рамках вашего бюджета. Во всех спорных вопросах лучше делать так, как скажет разработчик, так как у него есть опыт, который поможет вам избежать кучи подводных камней. После этого разработчики должны написать ТЗ, утвердить его с вами вместе со сроками, рассмотреть варианты оплаты с привязкой к выполнению пунктов ТЗ и можете начинать делать приложение согласно ТЗ.

По важности шагов:
1. Выбрать платформу
2. Поискать разработчика под эту платформу, описать ему приложение, послушать его мнение по реализации
3. С учетом пункта 2 найти разработчика для апи.
4. Если нужно - найти дизайнера
5. Составить тз со всеми выше перечисленными, договориться об оплате и сроках. С разработчиками обязательно оговорить то, что они будут готовы оперативно поправить недостатки, если приложение завернут на ревью в аппстор/гугл-плей. Или оговорить то, что финальная часть оплаты после поступит того, как приложения одобрят в сторах.
6. Иметь план вывода приложения в гугл-плей или аппстор (от чьего имени выкладывается приложение, кто оплачивает аккаунты и прочее).

• Продублирую (случайно ответила в общей ветке).
  

  Для начала нужно определиться с платформой

  Да, это уже понятно. Если нормально - то нужно отдельно.

  Тут нужен разработчик (Python или PHP ), который напишет обвязку к апи и спроектирует бд

  Кто сначала: Ява-Свифт или Питон?

  Таким образом, если все делать по уму, нужно 2 разработчика: 1 пишет само приложение под выбранную платформу, 1 пишет апи и делает базу данных. Опционально - добавить сюда 1 дизайнера.

  Ок, спасибо. Понятно.

  По важности шагов... Или оговорить то, что финальная часть оплаты после поступит того, как приложения одобрят в сторах.

  Вот за это прям Спасибище! - сама я об этом не подумала.

У вас нет готового рабочего прототипа. У вас нет команды разработки. У вас нет технического задания. Есть только "наброски", так называемое функционально-техническое предложение. Первым делом ищите специалиста, которые напишет вам грамотное ТЗ по вашим хотелкам. Специалист должен обладать широкими познаниями в архитектуре ПО. По ходу составления ТЗ и уточнению критических нюансов приложения и выяснится, кто вам нужен и в каком количестве.

• У меня есть готовый рабочий прототип. Я ж это написала в исходном сообщении.
• LiuY,
  

  У меня есть готовый рабочий прототип.

  Прям работающее приложение?

  Нарисовала прототип со связями-ссылками. И уперлась в стену.

  Это не прототип, прототип это что-то, что можно использовать как рабочий образец для дальнейшего улучшения. То что у вас "нарисовала" - это называется use cases, хорошее начало, но к ТЗ имеет мало отношения.

1) Неплохо было бы описать что за приложение, так как варианты слишком широки для описания. Судя по тегу
МОБИЛЬНАЯ РАЗРАБОТКА приложение на телефон. В зависимости от функционала и требований, это может быть как веб приложение, по простому - сайт, так и наоборот - нативное решение под андроид/айос, вообще не требующее например сервера и соответственно бэекенд разработчика. Общее описание Михаил Р. в целом может подойти, но больше описывает именно веб разработку.

PS:

после создания прототипа

Насколько я понял, у вас не прототип, а Use cases схема.

• Вы неправильно поняли. Прототип. В Бальзамике. И Use cases схема тоже есть. В ДрауИо.
• Разве Мобильному Приложению не нужен сервер для хранения БД, например пользователей?
• LiuY,
  

  Разве Мобильному Приложению не нужен сервер для хранения БД, например пользователей?

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

• LiuY,
  

  Вы неправильно поняли. Прототип. В Бальзамике.

  Balsamiq это сервис для создания простых прототипов интерфейсов. К функционалу не имеет отношения, тот же юзкейс, только в картинках. Это норм, но это не прототип приложения и не ТЗ. Не сказал бы что ТЗ прям необходимый шаг, чаще всего юзкейсов хватает для коммуникации заказчика с исполнителем, ТЗ больше страховка в том что функционал будет соответствовать требованиям, ну и является документом с подписями, а не файликом с картинками... В целом это больше рекомендация, нежели какой-то обязательный шаг.

• ThunderCat, Я больше склоняюсь к тому, что в подробном ТЗ заинтересованы в большей степени студии, чтобы за каждый непрописанный чих увеличивать цену. Ну и договор нужен пр работе с ними же дабы хоть немного обезопасить заказчика (ну заказчики так думают).
  Я не их клиент, в ТЗ в интернете ещё покопаюсь, но думаю, что наглядней для моего исполнителя будут всё же сделанный прототип с описанием каждой кнопочки и поля. На истину не претендую.
  Спасибо за рекомендацию)

Для начала нужно определиться с платформой

Да, это уже понятно. Если нормально - то нужно отдельно.

Тут нужен разработчик (Python или PHP ), который напишет обвязку к апи и спроектирует бд

Кто сначала: Ява-Свифт или Питон?

Таким образом, если все делать по уму, нужно 2 разработчика: 1 пишет само приложение под выбранную платформу, 1 пишет апи и делает базу данных. Опционально - добавить сюда 1 дизайнера.

Ок, спасибо. Понятно.

По важности шагов... Или оговорить то, что финальная часть оплаты после поступит того, как приложения одобрят в сторах.

Вот за это прям Спасибище! - сама я об этом не подумала.

• без бэкенда фронт не написать полностью. Грамотный фронтенд разработчик может написать приложение имея спецификацию апи без его реализации, по готовности реализует взаимодействие с апи (неграмотный тоже, но у него это может занять больше времени).
• Спасибо.
  То есть - первым делом ищу бэкэнд. Со знанием Питона, PHP и SQL?

Нужен один более-менее опытный backend разработчик, ему делегируете все вопросы связанные с разработкой и подбором других необходимых специалистов. Что-то типа Team Lead. Еще до старта, показываете ему что у вас есть на текущий момент, что хотите на выходе и на какой бюджет расчитываете. Подписываете договор и работаете.

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

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

• Если бы у меня было 2-3млн. и соответственно возможность сразу делегировать всё студии, с менеджером проекта и командой, ... даже тогда бы я предпочла погружаться и разбирать во всем максимально сама и, по-возможности, подбирать не руководителей-менеджеров проектов, а непосредственно исполнителей. Разница была бы только в том, что имея хороший бюджет, выбор специалистов несравнимо больше и можно пригласить более опытных (хотя не факт, что даже с ними, за большие деньги, всё пройдёт гладко).

  Но это всё лирика) - за комментарий спасибо. По итогу поняла, что нужен бэкэнд-разрабочик.

• Team Lead это не значит что человек исключительно руководит, он также пишет код и является исполнителем. Суть в том, что есть один человек который понимает в разработке и несет полную ответственность за конечный результат. За это и имеет вознаграждение побольше остальных.

1. Макет
2. Разработка