Один день программиста, или как создаются мобильные приложения

Обычные пользователи редко задумываются над тем, какая работа предшествует выходу готового приложения. Между тем его разработка зачастую длится не один год. И в этом процессе задействована целая команда программистов, каждый из которых вносит свой вклад в создание инновационного продукта. По мнению самих специалистов, написать код с первого раза без единой ошибки сродни фантастике. Чтобы узнать, как создаются программы, мы побеседовали с ведущим iOS-разработчиком, проект-менеджером SFERA Дмитрием Нгуеном.

— Дмитрий, скажите, какие специалисты обязательно должны присутствовать в команде разработчиков?

— Если рассмотреть на примере разработки простого приложения, то потребуется 2 iOS-, 2 Android-, 2 backend- и 2 frontend-разработчика. Также нужны 2 дизайнера, архитектор, тестировщик и системный аналитик. Можно обойтись и без системного аналитика, но увеличивается время на разработку.

— Чем конкретно занимаются эти специалисты?

— Backend-программисты специализируются на серверной части. Frontend пишут код для видимой части приложения или сайта. Разработчики ядра приложения создают универсальное ядро, которое можно будет внедрять в разные платформы: на Android, iOS или web-сайт.

Архитектор разрабатывает данные, которые нужно передавать, просчитывает архитектуру всего приложения, как работает back и frontend, ставит задачу программистам. Он обладает знаниями по этим направлениям, в курсе возможных нюансов.

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

— В чем состоят ваши обязанности как проект-менеджера?

— Совместно с тимлидом мы распределяем задачи между командами программистов и обозначаем сроки выполнения. Предварительно всё согласовывается с руководителем проекта. Также на мне ответственность по контролю за действиями подрядчиков.

— Как вы выстраиваете работу в команде?

— Например, за 2 недели мы должны подготовиться к одному релизу. Мы обдумываем, что нам нужно для этого сделать. Далее распределяем задачи и проводим ежедневные митапы, чтобы оценить успеваемость команды и понять, на какой стадии находится разработка. Именно анализ задач и их распределение занимает большую часть моего времени как проект-менеджера. (В остальное время я пишу код для iOS.)

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

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

— Как оцениваются результаты работы?

— Разработка продукта ведется по методологии Agile. Для более точной организации рабочих процессов и отслеживания результатов мы используем SCRUM и Kanban.

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

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

— С какими проблемами в своей работе вы сталкиваетесь систематически?

— Основная проблема у нас — неточное ТЗ от отдела дизайна. При написании кода мы должны учитывать любое состояние окон, которое может быть в приложении. Все эти окна должны быть отрисованы. Все возможные недочеты должны закрываться еще на этапе проектирования приложения. И такие проблемы в основном возникают из-за недостаточности знаний и неопытности тех, кто разрабатывал и дизайн, и ТЗ.

— Что поможет избежать ошибок и переписывания кода?

— Большое значение имеет правильно составленное ТЗ. Этим также занимается системный аналитик. При этом нужно максимально декомпозировать все задачи для написания кода. Требования следует формулировать как можно конкретнее. Нам, программистам, при разработке очень нужна и важна точность. Идеального ТЗ в своей жизни я еще не видел. Но если что-то непонятно, всегда можно обратиться к знающему человеку и спросить. Самое важное в любой работе — это общение. Без взаимопонимания ничего не получится.

— Какие проблемы возникают при работе с программистами?

— Зачастую это непонимание того, что требует бизнес. Неумение работать в команде. Бывает, программист говорит: «Вот мой кусок кода — его не трогайте». А иногда появляется необходимость посмотреть этот код. И проект-менеджер «лезет» в этот код. А в дальнейшем могут возникнуть разногласия. Поэтому разработчикам очень важно научиться работать сообща. Проект-менеджер должен так выстраивать рабочий процесс, чтобы была достигнута задача заказчика в обозначенные сроки.

— Как избежать неприятных моментов в работе?

— HR должен правильно подбирать персонал. На собеседовании обязательно задать ряд вопросов, по которым можно определить, есть ли у кандидата soft skills. Это первый фильтр. Далее HR советуется с командой и принимает решение, сможет ли специалист взаимодействовать с коллегами. Такой подход уменьшит вероятность конфликтов в будущем.

— Дмитрий, расскажите, какие навыки необходимы для того, чтобы стать тимлидом или проект-менеджером?

— Чтобы стать тимлидом или проект-менеджером, помимо специальных знаний по разработке, необходимы хорошие soft skills. Самодисциплина, тайм-менеджмент, умение выстраивать личную и командную работу. Hard skills можно наработать, это сложно, но можно. Но наличие гибких навыков — на первом месте. Даже высококлассному разработчику будет тяжело работать в проекте без умения налаживать контакты с другими людьми. И самое главное — решать задачу бизнеса.

— Как сформировать команду из квалифицированных специалистов и где их найти?

— Основная масса таких программистов идут работать в известные компании. При этом хороший разработчик пойдет в стартап, если проект ему покажется интересным. В начале придется нанимать джунов и сформировать из них команду. Мидл не пойдет в проект, если там никого нет. Тенденция на рынке труда такова, что средних и старших разработчиков (middle и senior) привлечь очень сложно. Они соглашаются работать за достойную зарплату. Поэтому на их оплате труда сэкономить не получится.

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

При наличии высококлассных специалистов разработка отвечающего всем запросам пользователей приложения — лишь дело времени. А полноценному релизу такого продукта предшествует длительная и кропотливая работа его создателей — программистов. Необходимо согласовать множество рабочих моментов как со своими программистами, так и с подрядчиками. А иногда и полностью переписать тысячи строк кода. И при его написании учитывать все возможные действия пользователей.

0
9 комментариев
Написать комментарий...
Бабка в засаде

Не знаю что это было. Типа азбука для капитана очевидность? 

Ответить
Развернуть ветку
Artem Petrenkov

Что ещё напишет копирайтер?

Ответить
Развернуть ветку
Artem Petrenkov

Архитектор, разрабатывающий данные, — это сильно.

Ответить
Развернуть ветку
Roman Nenznaskiy

Как бы я хотел посмотреть в глаза тому лоху, которому продают эту мертвую кошку под названием проект "Сфера". Сколько лет они тянут бабки из этого бедолаги.. аж до слёз))

На сколько я понимаю - 4-й год они его разводят! Вы лучше про этот опыт напишите - вот будет занимательная и очень поучительная история.

Ответить
Развернуть ветку
Дмитрий Гребенюк

Вообще все так и есть - от правильного ТЗ со стороны UX/UI дизайнеров зависит напрямую скорость разработки, однако часто бывает что дизайнеры не знают как правильно общаться с разработчиками.
Думаю для начинающих будет полезно, если автор статьи разовьёт эту тему в следующих выпусках - «как правильно составить ТЗ для разработчика».

Ответить
Развернуть ветку
Д Хб

Ммм, у нас дизайнеры уже ТЗ занимаются. До чего пандемия довела!

Ответить
Развернуть ветку
Артурас Лапинскас

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

Ответить
Развернуть ветку
No Good

На картинке, какой-то лютый говнокод с построением запроса

Ответить
Развернуть ветку
Иван Дубышкин

HR: Скажите, у вас есть soft-skills?
Программист: да, есть.
HR: Вы приняты.

Ответить
Развернуть ветку
6 комментариев
Раскрывать всегда