Мобилизация. Как создать приложение, которым будут пользоваться

Вадим Файнштейн
100
10
(1 голос)
0 0

Аннотация: Вы все еще думаете, что ваш бизнес может обойтись без мобильного приложения? Считайте, что вы проиграли. Человеческий мозг уже объединился со Всемирной сетью, и посредниками между ними стали мобильные приложения. Если ваш бизнес до сих пор не имеет прямого доступа к мозгу клиента (через приложение), скоро вы этого клиента потеряете.

Книга добавлена:
28-12-2023, 11:16
0
121
22
Мобилизация. Как создать приложение, которым будут пользоваться

Читать книгу "Мобилизация. Как создать приложение, которым будут пользоваться"



Делать самому или выбрать исполнителя?


Это замечательно, если у вас уже есть слаженная техническая команда, обладающая нужными знаниями. Но что делать, если такой команды нет?

Вариантов всего два: набрать свою команду или обратиться к стороннему исполнителю.

Вариант первый. Набираете команду

Для разработки мобильного приложения нам нужны следующие специалисты:

1. Дизайнер UX

2. Графический дизайнер

3. 1 или 2 клиентских программиста (зависит от выбора гибридной или нативной платформы)

4. Программист серверной части

5. QA-менеджер – тот, кто отвечает за качество продукта (quality)

6. Руководитель проекта

7. Технический руководитель (может быть одним из программистов)

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

На первых порах не все специалисты нужны на полную ставку. Так, обычно дизайнер UX и графический дизайнер полностью заняты в начале проекта, но их время освобождается через несколько месяцев. Занятость руководителя проекта и QA-менеджера в небольших проектах не превышает 30 %. Например, проверка качества на первых этапах не нужна. По-разному заняты серверные и клиентские программисты.

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

Часто для создания команды нужен HR-специалист, что еще увеличивает бюджет проекта.

И все же у работы с собственной командой есть плюсы. Вот они:

• вы полностью контролируете разработчиков, а значит, и бюджет проекта;

• команда находится в одном офисе с маркетологами, бизнес-девелоперами, техподдержкой и «чувствует» ваш бизнес;

• команда болеет за свой продукт, что лучшим образом сказывается на качестве. Все члены команды являются амбассадорами приложения. Для них это приложение – их младенец, они спят и видят, как это приложение становится качественным, полезным, удобным. Они живут своим продуктом.

Теперь рассмотрим минусы.

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

• бюджет разработки увеличивается во много раз за счет простоя некоторых сотрудников из команды;

• бюджет разработки увеличивается также из-за неправильного подбора персонала и времени, которое тратится на обучение специалистов.

• Предприниматель, руководитель должен быть на 100 % вовлечен в разработку. Но чаще всего у руководителя несколько разных бизнесов или направлений, и поэтому он не в состоянии тратить все свое время только на работу с набранной командой, на один продукт. Это может сказаться на сроках, бюджете и качестве итогового приложения.

Вариант второй. Обращаетесь к подрядчику

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

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

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

Но не во всех компаниях есть такой специалист. Его иногда называют «адвокатом дьявола». Потребуйте, чтобы в команде был такой человек.

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

Теперь разберем плюсы работы с подрядчиком, их немало.

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

• Подрядчику гораздо легче оценить бюджет и время разработки, чем менеджеру, который только начинает работать с новыми работниками. В моей компании GLobalbit разница между предварительным расчетом бюджета и его окончательным вариантом в стандартных проектах колеблется в пределах 10 %.

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

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

• Чаще всего у хороших подрядчиков работают профессионалы высокого уровня. А также есть наработки модулей, которые можно сразу использовать. Это помогает сэкономить около 30 % времени.

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

Минусы в таком выборе тоже есть.

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

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

Что же делать? Правильнее применять комплексный подход.

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

Как найти «правильного» подрядчика?

В разработке программного обеспечения поговорка «скупой платит дважды» действует с непреодолимой точностью.

Даже если приложение не является важной частью вашего бизнеса, оно часто является лицом вашей компании, интерфейсом между вами и вашим клиентом или сотрудником.

Разница в зарплате отличных программистов и начинающих или плохих достигает порой 500 %. А вред от плохого программного кода можно расхлебывать много лет (если вообще продукт попадет на рынок).

Порой решающим фактором в выборе подрядчика является цена.

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

Хотя правильнее все же смотреть не на бюджета на ROI – возврат инвестиций.

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

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

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

В конечном итоге все зависит от непосредственных исполнителей: от программиста, от дизайнеров, от дизайнера UX. Если они создают хороший продукт раз за разом, а не единожды, – значит, у них есть какой-то рецепт. Рецепты могут быть разными.

Например, у нас есть несколько десятков таких разработок. Более 200 миллионов человек в мире пользуются нашими приложениями.

Количество скачиваний – критерий, к которому апеллируют многие подрядчики. Но он важен в первую очередь для коммерческих продуктов b2c, которые предназначены для конкретного пользователя, таких как Moovit, Instagram, Facebook и так далее.

Для продуктов b2b не столько имеет значение количество пользователей, сколько вовлеченность клиента, финансовые обороты.

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

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

Следующий шаг при выборе подрядчика – найти реальных заказчиков и собрать их рекомендации.

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


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


100
10
Оцени книгу:
0 0
Комментарии
Минимальная длина комментария - 7 знаков.
Книжка.орг » О бизнесе популярно » Мобилизация. Как создать приложение, которым будут пользоваться
Внимание