Последние 7 лет я занимаюсь управлением индивидуальными IT проектами в рамках веб студии, которой я руковожу, и за это время я набрал неплохой опыт по работе с крупными проектами, которым и хочу с Вами поделиться. Мои клиенты, обычно, из США, Франции и Германии, но есть выполненные проекты в Канаде, Швейцарии, Дании, Австралии, Японии и т.д. Я проектировал социальную сеть, онлайн-аукцион, фитнес-конкурс, сервис по подбору автозапчастей, доставку еды, онлайн-кабинеты по приему и обработке заказов, торговые площадки и другие виды сервисов. Как видите, проекты разные, но их объединяет одна отличительная черта: пользователь взаимодействует с сервисом по заданному алгоритму. Моей основной задачей является продумать эти алгоритмы.

А если детальнее, то я должен:

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

Про нюансы своего дела и набитые шишки напишу в отдельной статье. А теперь, собственно, о проектах…

Слона надо есть по кусочкам

Надо сразу сказать, что проекты, с которыми я работал не сразу стоили дороже 100 000$. Разрабатываются такие проекты поэтапно и первый этап, то что называется MVP (Minimum Viable Product), стоит в разы дешевле. Цель первого этапа — запустить полноценный рабочий сервис с ограниченным функционалом и пустить на него первых пользователей на каких-либо льготных условиях. Важно либо следить за их поведением посредством Вебвизора, либо дать им возможность сообщать о найденных ошибках в чат. Тут сразу выявляются все недоработки, которые невозможно было найти путем тестирования, ведь десятки и сотни пользователей могут пользоваться сервисом не так как тестировщик. Чаще всего сразу после тестового запуска первого этапа разработки появляется список доработок, которые входят во 2-й этап. Это позволяет корректировать разработку под требования пользователей “на лету”.

Время — деньги

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

Поговорим “за оптимизацию”

С каждой следующей итерацией разработки код сервиса становится сложнее, количество пользователей и контента увеличивается в разы. Самое время оптимизировать скорость загрузки. Этот процесс начинается с оптимизации серверной структуры, так как она сразу дает краткосрочный результат. После этого оптимизируются запросы на стороне сайта. К этой процедуре нам еще придется вернуться, когда количество пользователей снова увеличится в разы. Тут можно говорить о нагрузочном тестировании, но из практики “ложка дорога к обеду”, поэтому работы по оптимизации, обычно, проводятся тогда, когда для этого есть объективные предпосылки.

Свет мой зеркальце скажи

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

Позвони мне, позвони

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

Мухи отдельно, котлеты отдельно

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

В проектной документации такого не было

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

А напоследок я скажу

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

Надеюсь, будет полезно. Спасибо всем, кто дочитал!

Буду благодарен за ваш конструктивный комментарий.

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