Кто что забыл в IT⁠⁠

Предисловие

Попросили меня в комментариях рассказать, с чего начать путь в IT непрограммисту. «С понимания того, что IT это не только программирование,» - тут же нашлась я. И вот плавно комментарий перерос в пост.

Дисклаймер

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

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

Текст мой, фото из интернета.

Кто есть кто в процессе разработки

1. Приходит заказчик, у которого ферма по производству сферических коней в вакууме. С ним заключают договор «на автоматизацию производства сферических коней в вакууме». Эти услуги продают сейлзы.

Для сейлза важно:

- понимать предметную область, в которой работает компания (в нашем случае это автоматизация производства);

- понимать, что может сделать компания и примерно представлять, что нужно клиенту.

Кроме того, тут важны «софт скилы»:

- умение презентовать продукт;

- объяснять, как все работает;

- уточнять, что в общих чертах нужно клиенту.

2. Когда документы подписаны, начинается этап анализа. Бизнес-аналитик приходит к заказчику и начинает задавать каверзные вопросы:

- А как вы коней создаёте?

- А что вы при создании задаёте? Только радиус? Или ещё цвет?

- А кто вообще коней создать может?

- А кто должен знать, что коня создали?

Потом аналитик идёт, выписывает в деталях, что нужно сделать, и согласует это с заказчиком.

Бизнес-аналитику нужно:

- уметь вгрызаться в заказчика и вытаскивать все детали того, как люди работают;

- хорошо структурировать мысли (хорошо бы знать про требования, критерии приемки и т.д.);

- уметь описывать процессы и согласовывать с заказчиком. Для этого есть разные нотации: UML, BPMN;

- быть стрессоустойчивым;

- для этапа дизайна (ниже) нужно уметь описывать модели данных, взаимодействие систем (для этого тоже есть диаграммы, например UML);

Рядом с бизнес-аналитиком на этапе анализа работает системный аналитик. Этот человек смотрит, что есть в системе сейчас (как устроены базы данных, с какими системами нужно настроить взаимодействие и т.д)

Системный аналитик должен:

- умеешь формулировать свои мысли;

- понимать, как устроены системы;

- понимать, как устроено взаимодействие систем (тут стоит почитать про API);

3. После анализа идёт этап дизайна. Здесь участвуют аналитики и архитектор. На данном этапе, после того как понятно, что есть, придумывают, как сделать заказчика счастливым.

В нашем примере команда решает, как будет в системе представлен сферический конь, какие будут механизмы создания, как будут уведомлять заинтересованных лиц.

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

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

Дизайнер должен:

- разбираться в том, как строятся пользовательские интерфейсы;

- разбираться в UX;

- иметь чувство прекрасного.

4. Как только все задизайнено, начинается разработка. Тут пишут код, создают базы данных и таблицы, настраивают интеграции. Все в соответствии с дизайном.

Разработчики бывают совершенно разные. Есть те, кто делают красивые формы (фронтенд), есть те, кто пишут логику (бэкенд), есть те, кто делает и то, и другое (фулстек). Кроме того, есть спецы по БД, по интеграциям (API). Если интересна работа разработчика, то нужно вначале понять, к чему именно душа лежит.

5. Когда весь код написан, надо тестировать. Тут у нас тестировщик. Он проверяет, что все соответствует дизайну, работает корректно. Если что-то пошло не так, тестировщик заставляет программиста переделать.

Тестировщик должен:

- понимать, как должна работать система

- иметь воображение, чтобы понять, что можно сломать

- быть усидчивым

- понимать, как строятся тесткейсы и тестовые сценарии

- уметь воспроизводить найденные проблемы и описывать их для разработки.

Тестировать можно ручками либо при помощи автотестов. Во втором случае нужно уметь кодить.

6. Пока все тестировали и правили, документатор поговорил с аналитиками и описал поведение системы понятным пользователю языком.

Документатор молодец, если:

- понимает, как будет работать пользователь;

- понятно рассказывает;

- умеет грамотно выражать свои мысли.

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

7. Если все работает корректно, можно поставлять систему заказчику. Тут активно работает DevOps. DevOps - это стильно, модно, молодёжно.

DevOps может в:

- Git;

- процессы сборки (CI/CD);

- методы сборки;

- умеет писать конфиги (так что да, тут надо кодить);

- умеет настраивать интеграции;

- понимать, как устроена инфраструктура заказчика (какие системы, где, что и т.д.).

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

9. Когда все обучены, начинается приемочное тестирование. Аналитики и руководители проектов сидят и с потными ладошками молятся, чтобы ничего у заказчика не отвалилось. Если что-то отвалится, что команда переделывает. Если все хорошо, новая система вместе с документацией переходит заказчику. Этап проекта (а то и весь проект) заканчивается.

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

Саппорт должен:

- быть стрессоустойчивым;

- уметь выпытывать и понятно описывать, что пользователь сделал;

- помнить (хотя бы самые часто встречающиеся) проблемы, с которыми сталкивались пользователи, и их решения.

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

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

P.S.: Всем желающим влиться в IT - удачи и роль по душе!