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

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

В финале вы тестируете все внутренние системы дома, чтобы они работали исправно. Принимаете помещение, документируете всё, что в нем есть, и подписываете акт приемки.

И наконец, происходит внедрение нового продукта в вашу жизнь: в случае с домом вы въезжаете в него, осваиваетесь в новом пространстве и начинаете там счастливо жить.

Разработка ПО происходит по тому же принципу: от проектирования через создание к внедрению и сопровождению. Давайте детально рассмотрим все этапы, которые возникают на каждой ступени развития событий.

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

Сбор и обработка требований бывает двух типов: внутренняя — для разработки продукта, который та или иная IT-компания собирается самостоятельно выпустить на рынок, или внешняя — когда IT-компания принимает заказ от сторонней организации, которой требуется какой-то программный продукт.

Какие специалисты будут участвовать в работе на этом этапе?

• Product-/Project-менеджеры, как говорилось выше, это специалисты, которые отвечают за административную часть. Повторюсь: проджект-менеджер отвечает за успешное выполнение проекта в установленные сроки и бюджет, а продакт-менеджер — за продукт в целом, от идеи до потенциального развития после выхода. Подробнее о том, как именно осуществляется управление проектом и кто еще будет в нем задействован, мы поговорим в отдельной главе.
• Системный аналитик формирует стандарты разработки, пишет техническое задание программистам, планирует бизнес-процессы. Это специалист, который достаточно точно видит, что мы должны получить в результате разработки, и может структурированно донести это до всех участников процесса. Всю эту стратегию он выстраивает на основе требований, полученных от заказчика (менеджмента компании, которая заказала ПО, или пользователей).
• Аккаунт-менеджер подключается в том случае, если разработка заказная. Он осуществляет общение с клиентом и зачастую выступает своеобразным «переводчиком» между заказчиком и исполнителем.

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

Кроме того, на данном этапе выбирается методология разработки: каскадная (Waterfall) или Agile (Scrum, Kanban). О том, что это такое, мы также поговорим чуть позже.

3-й этап. Создание продукта. Этот этап, в свою очередь, включает в себя несколько частей: непосредственно разработка, тестирование, поддержка, доработка.

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

Разработка продукта, в зависимости от требований, может происходить с помощью следующих специалистов:

• Full-stack-разработчик — это специалист, который разрабатывает и интерфейсы, и внутреннюю логику продукта. Интерфейс — это, грубо говоря, то, что видит пользователь: например, заходя на веб-сайт, мы будем наблюдать разнообразные элементы, которые реагируют на нажатие, или просто мигают, или выскакивают нам навстречу в неожиданный момент. Внутренняя же логика — это код, который скрывается за этим фасадом и обеспечивает внутреннюю работу всей системы: пользователь эту «подводную утробу парохода» не видит. Например, нажав на эту или иную кнопку, мы видим всплывающую форму, но не видим, как это произошло: как система обратилась к базе данных, нашла нужную информацию и показала ее нам. Чаще всего фронтендом и бэкендом занимаются разные люди, но случается и так, что один или несколько универсальных специалистов делают всё.
• Frontend-разработчики — специалисты, которые создают клиентскую часть продукта, то есть то, что мы, пользователи, видим на веб-странице или в приложении.
• Backend-разработчики, соответственно, работают только над внутренней логикой.

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

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

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

Обычно процесс внедрения происходит следующим образом:

1. Документирование информации о софте — написание инструкций, которые помогут пользователям и другим разработчикам эффективно общаться с этой новой «сущностью».
2. Непосредственно внедрение системы: та самая интеграция нового ПО в уже существующее.
3. Анализ состояния ПО в новой инфраструктуре: вдруг что-то работает не так, как задумано.
4. Если ошибки выявлены, то специалист по внедрению привлекает разработчиков, чтобы те всё исправили.
5. Обучение сотрудников новой системе или объяснение конечным пользователям, какие изменения произошли и как это может улучшить их работу.

Внедрение нового ПО — важнейший и во многом стрессовый этап для пользователей. Без грамотного проводника в новые возможности софта такое обновление может стать шок-контентом для всех сотрудников компании. Просто представьте: к вам приходит некто, сообщает, что теперь вместо 1С у вас установлен, скажем, 2С, который вы никогда в глаза не видели, — и гордо удаляется. Ситуация жуткая! На этом этапе пользователям необходима грамотная помощь и регулярное взаимодействие со специалистом.

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

• Первая линия (или HelpDesk) — решают самые простые задачи пользователей: выключите и включите компьютер — заработало? Поздравляю!
• Вторая линия — здесь в работу включаются системные администраторы. Они решают вопросы управления доступом и могут корректировать настройки системы.
• Третья линия — специалисты, решающие сервисные вопросы. Они могут поправить ошибку в коде.

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

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