Преамбула
В данный момент я являюсь менеджером проекта в небольшой команде разработчиков, собранной из коллег на моей основной работе. Мы занимаемся созданием игр под мобильные телефоны. С того момента, как только начала формироваться наша команда, и мы стали более-менее регулярно собираться, обмениваться идеями и делать наши первые шаги в мобильной разработке, прошло около года.
Сейчас у нас уже есть небольшой опыт работы в данном направлении, первая игра проходит бетта-тестирование, к тому же накопился какой-то пласт мыслей и выводов по ходу процесса, и не только.
Если будет находиться время, постараюсь вести мини-блог наших успехов и неудач, высказывать идеи, которые посещали наш коллектив за время работы. Многие из них покажутся спорными, и я был бы рад появлению конструктивной дискуссии в комментариях.
В следующий раз я расскажу о том, как мы выбирали движок для игры, чем хорош Unity, и почему следующий проект будет сделан с помощью LibGDX. А сегодня я опишу вкратце то, как формировалась команда, и рождалось в дискуссиях видение того, чем стоит заниматься.
Почему мобильная разработка?
На основном месте работы мы с коллегами занимаемся системами автоматизации в достаточно крупной и успешной фирме. И, как и у многих, в какой-то момент, у нас возникло желание попробовать какую-то новую область, построить может что-то и небольшое, но свое.
Первый опыт мобильной разработки, эдакий “выстрел наугад” представлял собой создание пары простеньких справочников для ОС Android. Была выбрана не самая конкурентная категория — Медицина. Несмотря на то, что справочников с подобным содержанием в Маркете было уже несколько штук, ставка на более привлекательный дизайн интерфейса и качественную иконку приложения оправдалась. Эта пара простеньких приложений принесла несколько десятков тысяч рублей чистой прибыли, множество положительных отзывов пользователей и ощущение, что на этом рынке в целом можно зарабатывать.
Выбор конкретного направления работы
Дальше стал вопрос: что же делать конкретно? Для себя я ввел следующую простенькую иерархию ПО:
- заказное
- продуктовое
- “полезное” ПО
- игры
Конечно, наиболее заманчиво было взяться за продуктовое ПО. Там и простор для творчества шире, и смутно маячил шанс вытащить свой золотой билет, и купить наконец себе Ferrari/Lamborghini/<свой вариант>.
Полезное ПО, как мне кажется, делать уже бессмысленно — если не считать разные сервисы, а считать именно ПО, которое в чем-то помогает пользователю и не является чистым развлечением, то здесь уже, кажется, сделано все и для всех. Таким образом, решено было заняться разработкой игр.
ПО vs сервисы
Сделаю небольшую ремарку. Мне кажется, рынок продуктового ПО уже исчерпан. Конечно, писать на заказ, удовлетворяя специфичные потребности текущего заказчика, можно будет еще не одну тысячу лет. Но попробуйте сделать новый текстовый процессор или файловый менеджер — и без колоссальных инвестиций, вы скорее всего потерпите крах.
Другое дело сервисы. Тут тоже есть простор для программирования, но все эти web-сайты, базы данных и мобильные клиенты — не более чем интерфейс контактирования с сервисом. Ядро сервиса — это база людей и хорошо продуманные способы их взаимодействия. Ну и правильная схема монетизации!
В общем, мне кажется, нам нужно больше сервисов, хороших и разных, с удобными мобильными интерфейсами, с высокой степенью интеграции. Сдается мне, это большой рынок, и там еще есть где разгуляться. Я лично начинаю все пристальнее к нему приглядываться.
Формирование команды
Скажу честно: работа в команде, собранной из коллег по основной работе — не лучшая идея для создания бизнеса. С одной стороны, ты уже знаешь, кто на что способен, и чувствуешь определенную поддержку с их стороны.
С другой — в таком тесном кругу реже появляются действительно свежие идеи. К тому же, слишком строго требуя от коллег выполнения их обязанностей по проекту, можно осложнить себе взаимодействие с ними в рамках основной работы.
Хотя конечно, как еще собрать команду из хороших программистов, не платить им зарплату и при этом получать нужный результат??
Для того, чтобы организовать командную работу, нужно увлечь людей. Вроде это всем известно. Но как это сделать? На самом деле, все просто, вот три основных фактора:
Фактор 1. Многие из нас лелеят в душе планы по созданию своих собственных продуктов
Фактор 2. Для многих сильной мотивацией является работа с новыми технологиями и средами. Ведь программист не мыслим без постоянного образования: не уследил за последними веяниями — и все, ты динозавр. Многие это очень хорошо понимают
Фактор 3. Как по мне, лучший способ что-то рассказывать и увлечь людей — это презентация. Да, банальная мысль. Но это именно то, что нужно. Не стоит полагаться на свое красноречие и умение красиво рисовать схемы на бумажке. Открывайте PowerPoint, пишите текст, вставляйте красочные иллюстрации, репетируйте свою речь.
Как готовить презентации, очень хорошо написано в книге Гая Кавасаки “Стартап”. Кстати, я понял, что главный фактор, определяющий качество вашего выступления — это количество времени, потраченного на репетиции. Хотите произвести максимальное впечатление на слушателей? Ставьте ноутбук на стол дома, расправляйте плечи, представляйте своих слушателей и рассказывайте то, что готовили. Потом еще раз, и еще. Представляйте, какие вопросы возникнут у аудитории. Придумывайте локаничные ответы на них. Рассказывайте свою презентацию коту, подруге, друзьям, которые имели неосторожность зайти к вам домой. В конце концов, вы научитесь доносить свои идеи, как Madonna поет песни на сцене, и с тем же изяществом ответите на любые вопросы из зала
Фактор 4. Еще одна банальная мысль. Чтобы увлечь людей идеей, нужно самому быть ею увлеченным. На свете много людей, умнее нас с вами, и очень грандиозных планов, но ничто не производит такого сильного впечатления, как чьи-то горящие глаза
Командная работа
Здесь я просто перечислю свои небольшой опыт и выводы, которые я из него сделал:
Вывод 1. Перед началом разработки нового проекта, обязательно прочтите Джоэла Спольски “Джоэл о программировании”, все части
Вывод 2. Удаленная работа, когда каждый кодит с дома, в удобное время, и мало общается вживую с другими участниками проекта — это зло. Когда начинается новый проект, изучается новая технология, так работать нельзя. Собирайте всю команду вместе, и как можно чаще. Пусть даже у себя дома по выходным и в коридорах на работе в будни. Люди должны общаться, обмениваться мыслями, эмоциями, опытом. Так работа идет значительно лучше и быстрее
Вывод 3. Не ставьте крест на коллегах, которые поначалу приносят малый вклад в проект. Но и не позволяйте бездельничать. Если человек говорит, что настроен серьезно участвовать в проекте, но у него конкретно сейчас нет времени много работать/что-то не получается/он не понял до конца задачу — просто устройте небольшую проверку. Дайте ему самому выбрать задачу и срок (разумный, конечно). Если выбранная задача за поставленный срок решится — продолжайте с ним работать. Если нет — сокращайте команду на одного участника
Вывод 4. Нанимайте дизайнера! Никогда не полагайтесь на свое знание юзабилити интерфейсов/знание 2D- 3D-редакторов. Даже если в итоге силами пяти программистов вы создадите вменяемый дизайн, временные затраты на это будут непозволительно высокими
Вывод 5. Следите за тем, чтобы каждый мог выбрать работу себе по душе. Обращайте внимание на то, кому какие участки работы интересны. Все люди разные, кому-то хочется закодить новый визуальный эффект, кто-то не против покопаться в глубинах технологии, кому-то не терпится сделать сайт-визитку. Это очень важно. Будете распределять задачи без учета личных предпочтений — получите крайне низкую эффективность.
Выяснять предпочтения можно разными способами. Например, так. Затроньте на общем собрании команды идею сделать тот или иной участок работы. Тот, кто с большим рвением начнет обсуждать задачу, предлагая свои идеи, как сделать это лучше — скорее всего, самый очевидный кандидат на исполнение
Послесловие
На данный момент все члены команды работают почти каждый день. По часу-два в будни, и все воскресенье у меня дома, превращенного в мини-офис с кучей удлинителей, бумажками A4 и ручками на всех подоконниках и вазой с печеньками. Работа сейчас движется в разы быстрее, чем в начале, бетта-тестирование игрушки мы завершаем, наводим последний лоск. Скоро выпуск на всех основных мобильных платформах. И, надеюсь, успех!
В следующий раз я расскажу о том, как мы выбирали движок для игры, чем хорош Unity, и почему следующий проект будет сделан с помощью LibGDX. [прошу прощения за копипаст из первого абзаца] На сегодня все. Всем удачи в Ваших начинаниях!
Автор: EugeneDM
