Внутренняя кухня разработчика IT-продуктов многогранна и всегда переполнена разными задачами. В каждом проекте находят себе применение люди с разными обязанностями.
На примере одного проекта мы поглубже рассмотрим процесс разработки. Перед этим я опишу все этапы этого процесса и функциональные обязанности сотрудников в нем.
Жизненный цикл разработки IT-продукта
Ниже описаны этапы цикла, начиная с момента, когда заказчик сформулировал свои идеи исполнителю.
- Планирование
Грамотное планирование функциональности будущего продукта и анализ требований играют ключевую роль для всего проекта. За этот этап несет ответственность менеджер проекта, так как именно он отвечает за успех всего процесса разработки.
До проектирования продукта планирование носит “грубый” характер, так как точный ход разработки на этом этапе узнать невозможно.
После того, как UX/UI проектирование выполнено, можно составить точный план, как будет идти разработка, и какая функциональность будет в продукте.
- Дизайн
После планирования наступает черед UX/UI дизайнеров — специалистов, которые проектируют пользовательские интерфейсы. Дизайнеры занимаются изучением поведения пользователей и выстраиванием понятного человеку интерфейса. Визуальный вид продукта — также результат работы дизайнеров.
Вместе с ними работают системные архитекторы, которые решают, какую структуру будет иметь готовый продукт, и как он должен себя вести.
- Разработка
Разработчики следуют одной из методологий — для компании это в основном Agile. Эта методология предполагает гибкий итеративный подход — то есть разработчики действуют последовательно, разделяя проект на более мелкие задачи.
Итерации в Agile называются спринтами, и в один спринт входят работы по всем направлениям: планирование, дизайн, разработка, тестирование.
- Тестирование
Специалисты по тестированию выполняют разные виды тестирования: модульное, интеграционное, тестирование интерфейса и другие виды в зависимости от цели. Эта категория специалистов должна прийти к конечному выводу, что в продукте нет ошибок и он готов к релизу.
После этого продукт можно внедрять и интегрировать со сторонним программным обеспечением. Процесс разработки на этом не заканчивается — он продолжается, пока не будут внесены доработки.
- Поддержка
Готовый продукт может нуждаться в дополнительной поддержке, будь то дополнительные вопросы по поводу работы продукта от клиентов, или необходимость внести изменения в уже заложенные функции, — специалисты службы поддержки всегда готовы прийти на помощь.
Большинство проектов по разработке проходят все этапы вышеописанного жизненного цикла.
Для примера мы подробнее рассмотрим процесс разработки продукта на текущем проекте компании.
Этап 1: Идея
Заказчик — печатная компания из штатов. По всему миру эта индустрия переживает не лучшие времена, но в США печатные компании остаются на плаву благодаря инновационным технологиям. Печатная компания обратилась к нам с просьбой разработать приложение для дополненной реальности — Augmented Reality, AR.
Почтовая служба США, рассылающая печатные отчеты о сделках, предоставляет скидки тем партнерским компаниям, которые уменьшают потребление бумаги за счет технологий. Наш клиент стал одной из таких компаний.
Этап 2: Контакт
Представители компании связались с нами, чтобы представить свою идею. Они хотели получить приложение для маркетинга на базе дополненной реальности. До нас они пользовались системой распознавания изображений Catchoom, у них же хотели лицензировать как отдельный продукт систему управления контентом, но компания отказала. К тому же, клиент хотел добавить уникальные функции, чего в решении от Catchoom не подразумевалось. Поэтому нашей задачей стало разработать подходящую систему взамен.
Этап 3: Планирование
Заказчик описал основную функциональность продукта перед тем, как обратиться к нам. Команда разработчиков должна была изучить идею проекта и собрать все необходимые требования, выявить узкие места, и всё задокументировать. Подробности проекта и технические детали уточняли внутри каждого спринта.
Команда, которая занимается сбором требований, оценивает полученную информацию, предложение, затраты на разработку и цену, называется RFx. Обычно такая команда состоит из технических специалистов, менеджера проектов и менеджера по продажам. Действует RFx до начала проекта.
Заказчик изучает оценку проекта, чтобы получить базовое понимание того, как будет выглядеть проект и как будет вестись разработка. Она также определяет время и стоимость.
После того, как заказчик утвердил план и бюджет разработки, проект можно начинать.
Комментарий менеджера проекта Александра:
«Я отвечаю за непрерывный ход проекта. Я выбрал Scrum-методологию, чтобы быстро реагировать на запросы заказчика и рынка. Scrum помогает нам развивать продукт, учитывать потребности пользователей в каждом релизе продукта, и использовать в разработке самые современные технологии».
Этап 4: Дизайн
Заказчик был открыт к любым идеям наших дизайнеров и доверял видению специалистов. UX/UI дизайнер описал своё представление будущей системы, основываясь на общепринятых UX практиках, заказчик согласился, и началась реализация дизайна.
Этап 5: Разработка и тестирование
Заказчик лично посетил офис компании, чтобы встретиться с командой разработчиков и познакомиться с руководством компании. В первые полгода заказчик приезжал раз в месяц, чтобы наладить коммуникацию, ближе познакомиться с командой, и наработать доверие между сторонами.
На первом этапе разработки команда состояла из:
- Менеджера проектов, который также выполнял задачи бизнес-аналитика;
- UX/UI дизайнера;
- команды разработчиков.
На начальной стадии разработчики проводили тестирование своими силами, без участия QA-специалистов. Задача заключалась в том, чтобы создать набор прототипов для демонстрации на конференциях и привлечения потенциальных клиентов. Тогда детальное тестирование не понадобилось.
Когда процесс разработки дошел до работы над основными функциональными возможностям, команду нужно было расширить. В результате она выглядела так:
- Менеджер проектов;
- Бизнес-аналитик с более широким кругом задач, чем были у менеджера до этого;
- UX/UI дизайнер;
- разработчики;
- руководитель команды разработчиков (Team Lead);
- Системный архитектор, разработавший структуру продукта;
- Специалист по тестированию;
- DevOps — связующее звено между разработкой и эксплуатацией, работал с сетью и развертыванием продукта.
Руководитель команды разработчиков Игорь внес свои нововведения:
«В этом проекте я отвечаю за выполнение задач проекта, провожу рецензию кода, планирую спринты (итерации в разработке), ввожу новые задачи. Я предложил проводить юнит-тесты с помощью GitFlow и создавать код при помощи AWS Lambda. Я также ввожу в курс дела новых членов команды, отвечаю за их адаптацию”.
Присоединение Team Lead было важным решением, так как он помог скоординировать разработку версий приложения под iOS и Android и веб-версию так, чтобы все двигалось в одном направлении.
Бизнес-аналитик Флор рассказывает:
“Благодаря организации проекта, моя работа была предельно ясной и эффективной. Я обрабатывал запросы клиентов и в понятном и технически точном виде передавал их команде разработчиков. Я работал в тандеме с UX/UI дизайнером, а наш проект менеджер был ответственным за переговоры, что дало мне возможность сфокусироваться на моих основных задачах»,
Как видно, команде нужны были дополнительные специалисты, чтобы решать добавившиеся задачи. Такой состав команды может обеспечить грамотную разработку системы без ошибок.
Этап 6: Поддержка
Поддержка обычно осуществляется на 3 уровнях:
- Первый уровень. Базовая помощь, на этом уровне обрабатываются несложные вопросы, которые не требуют много внимания.
- Второй уровень. Расширенная помощь от персонала с более глубокими знаниями о продукте. Это не обязательно технические специалисты, но они точно отлично знают продукт.
- Третий уровень. Экспертный уровень, осуществляется опытными специалистами: менеджерами продукта, инженерами.
Существует также нулевой уровень поддержки через брошюры и руководства по эксплуатации.
На деле не бывает момента, когда работа над ПО считается полностью завершенной. Поступают либо новые пожелания от заказчика о расширении функциональных возможностей, либо требуется поддержка пользователям продукта. Например, у пользователей клиента возникали пожелания по обновлению приложения и расширению его функциональных возможностей.
Этот проект хорошо представляет все этапы жизненного цикла разработки. Если рассматривать детально, работа над любым ПО выглядит примерно одинаково и часто соответствует вышеописанной схеме.
Автор: HQS
