Разработка веб-сервиса: зачем на проекте тимлид, ПМ и тестировщик?

При заказе веб-разработки у многих клиентов возникают вопросы — правда ли кроме программистов для реализации проекта нужны проджект-менеджеры, тимлиды, тестировщики.

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

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

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

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

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

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

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

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

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

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

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

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

Но каждое приложение все равно проходит QA-тестирование. Тесты бывают двух типов:

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

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

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

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

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

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