А можете поделиться вводной, которая ставилась перед студиями и частными специалистами? Я занимаюсь мобильной разработкой и часто бывает, когда на вход ставится огромная задача (чеки в 2,8 - 8млн только за сайт это отчасти подтверждают) и явно или косвенно указывается, что весь функционал важен и необходим.
Чаще всего это приводит к ощущению, что заказчик для себя не видит планомерного подхода к развитию, и задачи будут постоянно меняться местами и приводить к большим административным расходам на постоянную актуализацию проекта.
Обычно, такое крупное задание мы разделяем на логически сформированные этапы разработки с выпуском качественной первой версии не более, чем в 15-20 экранов, а далее, по принципу agile, работаем со стеком оставшихся задач.
Это позволяет и идею проверить за небольшие деньги, и Вам сработаться с командой. Ведь и команда, и частный дизайнер/программист хочет получить понятную атомарную задачу, которую быстро выполнит и поймёт, что он молодец, а его работа не прошла в пустую. По опыту управления собственной командой пришёл к выводу, что залог успешного запуска больших проектов - это дробление крупной задачи на короткие спринты с однозначно понятным результатом.
События описанные в данной статье были ~ 2 года назад. Для оценки сложности и масштабности проекта Вы можете перейти по ссылке: https://beeb.ru Желательно с ПК, так как мобильная версия оптимизирована для скорости загрузки и удобства пользования.
ТЗ содержало 28 страниц, где подробно была описана архитектура, бизнес механики, алгоритмы и логика поведения пользователей. Именно это сейчас реализовано в Beta версии, естественно с учетом доработок в процессе реализации. Но канва осталась неизменной ~ 90%, что говорит о структурности первоначального подхода.
При всём уважении к студиям и к тем услугам, которые они оказывают, я сразу знал, что это не мой вариант. Я обратился к ним для понимания ценообразования на "свободном" рынке, уровня сложности реализации, методов работы и взаимодействия. Вывод был сделан следующий: готовы сделать mvp, обрезав всё лишнее по их мнению, как потом саппортить и развивать продукт не понятно, "Давайте начинать, остальное будем решать в процессе".
На мой взгляд, подобные проекты можно реализовать только в режиме основной занятости. Собрав свою собственную команду, которая точно также будет работать по 8-14 часов в день. Сурово, но это правда, без прикрас.
После детально проработанной концепции, мы разделили всю разработку на итерации и первая итерация как раз подразумевала выпуск качественной beta-версии (полноценного MVP). Собственно, эту версию Вы и видите сейчас на портале. Мы понимали, что разработка таких разделов как сообщество, блоги, виртуальный помощник и еще с десяток разных механик нужно однозначно переносить в следующую итерацию. Поэтому мы перенесли весь функционал, который не затрагивал основную бизнес-механику на вторую итерацию.
Здравствуйте.
А можете поделиться вводной, которая ставилась перед студиями и частными специалистами? Я занимаюсь мобильной разработкой и часто бывает, когда на вход ставится огромная задача (чеки в 2,8 - 8млн только за сайт это отчасти подтверждают) и явно или косвенно указывается, что весь функционал важен и необходим.
Чаще всего это приводит к ощущению, что заказчик для себя не видит планомерного подхода к развитию, и задачи будут постоянно меняться местами и приводить к большим административным расходам на постоянную актуализацию проекта.
Обычно, такое крупное задание мы разделяем на логически сформированные этапы разработки с выпуском качественной первой версии не более, чем в 15-20 экранов, а далее, по принципу agile, работаем со стеком оставшихся задач.
Это позволяет и идею проверить за небольшие деньги, и Вам сработаться с командой. Ведь и команда, и частный дизайнер/программист хочет получить понятную атомарную задачу, которую быстро выполнит и поймёт, что он молодец, а его работа не прошла в пустую. По опыту управления собственной командой пришёл к выводу, что залог успешного запуска больших проектов - это дробление крупной задачи на короткие спринты с однозначно понятным результатом.
Денис, добрый день.
Постараюсь дать Вам развёрнутый ответ.
События описанные в данной статье были ~ 2 года назад.
Для оценки сложности и масштабности проекта Вы можете перейти по ссылке: https://beeb.ru
Желательно с ПК, так как мобильная версия оптимизирована для скорости загрузки и удобства пользования.
ТЗ содержало 28 страниц, где подробно была описана архитектура, бизнес механики, алгоритмы и логика поведения пользователей.
Именно это сейчас реализовано в Beta версии, естественно с учетом доработок в процессе реализации. Но канва осталась неизменной ~ 90%, что говорит о структурности первоначального подхода.
При всём уважении к студиям и к тем услугам, которые они оказывают, я сразу знал, что это не мой вариант. Я обратился к ним для понимания ценообразования на "свободном" рынке, уровня сложности реализации, методов работы и взаимодействия.
Вывод был сделан следующий: готовы сделать mvp, обрезав всё лишнее по их мнению, как потом саппортить и развивать продукт не понятно, "Давайте начинать, остальное будем решать в процессе".
На мой взгляд, подобные проекты можно реализовать только в режиме основной занятости. Собрав свою собственную команду, которая точно также будет работать по 8-14 часов в день.
Сурово, но это правда, без прикрас.
Как мы работаем:
Как мы реализовывали текущую версию проекта:
После детально проработанной концепции, мы разделили всю разработку на итерации и первая итерация как раз подразумевала выпуск качественной beta-версии (полноценного MVP). Собственно, эту версию Вы и видите сейчас на портале.
Мы понимали, что разработка таких разделов как сообщество, блоги, виртуальный помощник и еще с десяток разных механик нужно однозначно переносить в следующую итерацию.
Поэтому мы перенесли весь функционал, который не затрагивал основную бизнес-механику на вторую итерацию.