На меня нахлынуло вдохновение и я решила разбавить волны про мигрантов, короновирус и старые ПК.
Столкнулась с тем, что и сама после Вуза, и мои одногруппники мало понимали, как происходит работа в ИТ-компаниях и кем можно там работать. Учить-учили, корочки «Инженера информационных технологий» получили. Ну разработчики, это понятно. И… и все, дальше обычно понимание заканчивается.
А сейчас, кстати, впрыгнуть в ИТ проще, чем когда-либо.
Итак, в компании, которые сейчас есть на рынке РФ (про иностранный не скажу, но, думаю, также):
1) делают свои продукты (один или несколько)
2) делают чужие продукты по договорам (или контрактам)
В чем основная разница? В первом случае заказчик – внутренний, скорее всего конкретное подразделение, с ним проще договориться о сдвиге сроков и пр. Во втором случае заказчик внешний, ответственность за срыв сроков и/или серьезные косяки может повлечь штрафы и пени по договору. Дедлайны жёстче, согласований дохрена.
Под каждый продукт (упрощенно ПО – программное обеспечение) выделяется команда внутри компании. Проект длится обычно в среднем от полугода до вечности. Бывает как создание нового ПО, добавление фич в текущее ПО и тех.поддержка старого ПО
Основной состав идеальной команды:
- менеджер проекта – в курсе контракта, договоренностей, распределяет работы по тех.лидерам, бдит за сроками проекта, подпинывает все согласования как со стороны Заказчика, так и со стороны компании
- тим-лидер – вообще должен сплачивать команду и разруливать психологические моменты, иногда выполняет роль менеджера проектов (а в некоторых компаниях и роль разработчика)
- ведущий бизнес-аналитик – распределяет работу на бизнес-аналитиков, делает то, что не смогли сделать его бойцы
- бизнес-аналитик – строит детальные бизнес-процессы на основе ТЗ, ставит задания системным аналитикам, пишет документацию, принимает выполнение работы разработчика (если нет тестировщика), общается с представителями заказчика письменно и устно по поводу доработок (тут главный вопрос: их что, много? Ох, я была на проекте, где один вопрос мы обсуждали с около 30! разными людьми в видеоконференции в Скайпе. И так раз в неделю.)
Реальность такова, что ПО включает в себя множество разных блоков и ответственность за них у заказчика разделена по разным людям. А если речь про взаимодействие этих блоков – то собирают всех людей сразу для общего решения.
- ведущий системный аналитик – распределяет работу по системным аналитикам, делает сложную работу. Ни разу не видела, но он наверняка существует)
- системный аналитик – обдумывает информацию от бизнес-аналитика на тему того как это реализовать технически (куда какие данные направить, как их обработать и куда передать) и ставит задачи разработчику
- технический лидер тестирования – распределяет работу по тестировщикам, пишет документацию по тестированию, делает то, что не смогли сделать его бойцы
- тестировщики – принимает работу разработчиков на основе требований, пишет документацию (тест-кейсы, приемочные документы, оформляет дефекты).
- технический лидер разработки – распределяет работу по разработчикам и…. я хз что он там еще должен делать, на проектах не видела ни разу (об этом ниже)
- разработчик – разрабатывает). Они делятся на фронтенд и бэкенд, бывают еще выделены отдельно на интеграцию (если ее много)
Дополнительные роли в команде:
- технический писатель. У каждого проекта есть свой пакет документов, обычно их около десятка. Какие? Описание приложения, Руководство пользователя, Руководство по безопасности и пр…. Все они должны быть написаны околоофициальным языком со ссылками друг на друга, скриншотами и техническими включениями. Если ПО дорабатывается (получает новый функционал), то его надо внести во все 10 документов с разных точек зрения (оператора, безопасности и т.д.)
- UI-дизайнер – разрабатывает интерфейс, кнопки и это вот все. В основном существует в команде только когда приложение только рождается или дорабатываются новые интерфейсы
- Scram-мастер – ооочень редкое явление. Специалист по технологии Scrum, проводит митинги (собрания), следит за соблюдением правил технологии.
- Devops – специалист по автоматизации сборки релизов и их непрерывной интеграции.
- Архитектор – нужен на начальном этапе разработки ПО, продумывает архитектуру ПО, и взаимодействие составляющих частей
Т.е. обобщенно процесс работы выглядит так:
Заказчик придумал требование – менеджер проектов оценил его, отдал в работу ведущему бизнес-аналитику – ВБА распределил работу между бизнес-аналитиками – бизнес-аналитик построил детальный бизнес процесс, передал системному аналитику – системный аналитик переложил бизнес-процесс на конкретные действия для тех.лидера разработки – тех.лидер разработки отдал задание разработчику - разработчик разработал – тех.лид по тестированию распределил работу по тестировщикам - тестировщик протестировал – Devops собрал релиз и установил его.
Ну, это утопия.
Часто всех ведущих и тех.лидеров в команде нет. Обязанности аналитиков объединяют. Devops тоже часто отсутствует и релиз собирается ручками кем-то из команды (тестировщиком, аналитиком или тех.лидом разработки, или тим-лидером даже). Если отсутствуют тех.писатели. то обязанности тоже ложатся на аналитиков. Также в неновых проектах отсутствуют UI-дизайнеры, их работу тоже выполняют аналитики. Иногда отсутствуют тестировщики – и опять обязанности выполняются аналитиками. Роль Scram-мастера ложится на менеджера проектов или тим-лида или еще на кого-то ведущего.
Так мы постепенно подобрались к тому, что внутри команды проекта дохрена людей (4-10 и больше) и действий. которые нужно согласовывать и отслеживать чтобы выпустить релиз (еще лучше – выпустить вовремя). Для наведения порядка в том хаосе используется технология Scrum и приложение для управления задачами и релизами (упрощенно) – Jira, например.
Конечно. это очень упрощенно. И, наверняка, я много еще разновидностей специальностей не встречала (или сознательно упустила - привет автоматизаторам тестирования, базистам и всем-всем-всем). Но проблема в том, что видение хотя бы такой общей картины у меня появилось только после работы, а до я и не знала какие существуют роли и кем вообще можно работать с дипломом и университетскими знаниями ИТ.
Что нужно для конкретной должности – зависит от компании. Требования, как и ЗП, могут отличаться очень сильно.
Но подготовиться реально примерно за неделю-две, к тому же многое (для Junior-вакансий) входит в программу ВУЗа.
И немного организационных моментов про собеседование.
Обязательно спросите:
1) Кто ваш непосредственный руководитель?
2) Где расположено ваше рабочее место? Если на удаленке – выдают ли технику?
Если в офисе – какой формат: опенспейс или что-то еще?
Сейчас многие компании осовремениваются и внедряют опенспейсы. Может не понравиться: скорей всего у вас есть немного интравертных качеств, раз вы можете долго сидеть, уткнувшись в монитор. Долго и тихо посидеть не получится – вас будут отвлекать все, кому не лень + шум от переговоров по видеочатам мешает сосредоточиться.
3) Какой соц.пакет? ДМС – это норма (если нет – надо насторожиться), бывает еще спорт, питание, такси и пр.
4) Какая зп в окладной части и что идет премиями? Ну это понятно.
5) Что это будет за проект в контексте: тех.поддержка старого, разработка нового ПО, поддержание текущего? Для новичка полезней всего будет поддержание текущего – так и база для опоры и изучения будет и можно будет себя попробовать в реализации новых фич.
6) Какова ваша роль на проекте, фактические обязанности? Работать чисто бизнес-аналитиком, конечно, хорошо… но совмещение нескольких персонажей в одном имеет свои плюсы:
- вы вникнете в разработку ПО со всех сторон и, возможно, вам захочется немного съехать в сторону тестирования или девопса или еще куда
и минусы:
- если в одной должности совмещают несколько – то тут либо мало работы, либо очень острая нехватка сотрудников, а, значит, и большая нагрузка. Будьте осторожнее, не выгорите.
Уф. Если будут еще какие-то вопросы – пишите, может, отвечу)
Да. я сознательно упустила такие моменты как дефекты, показы, митинги, кучу стендов и пр.
Можете заодно написать какие еще вопросы нужно задавать Джуниору на собеседовании работодателям.