Кто что забыл в 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 - удачи и роль по душе!
