Войтивайти.
Думаю, что не расскажу ничего нового, но для себя сохраню, вдруг забуду, будет где подсмотреть.
По слухам, все деньги получают чиновники и айтишники (IT-ишники). Поэтому, если не можешь стать чиновником иди в IT. При этом все понимают, что сфера IT сложная и без хорошего образования научиться премудростям программирования не получится. Какой из этого вывод? Надо создать курсы, где за месяц-три-шесть можно выпускать готовых специалистов. И готово, курсы окупаются, специалистов прибывает, все довольны. Тогда почему до сих пор не закрыты все вакансии? Почему стоимость избыточных специалистов не обесценилась? Может все не так просто, давайте разбираться.
Команда: для разработки проекта нужна команда специалистов, а вернее большой и дружный коллектив. Насколько он большой зависит от сложности проекта (проектов).
IT проект: это совокупность целей и задач, после выполнения которых мы получим продукт, который можно будет продать. А раз он “IT”, то это продукт связанный с вычислительными задачами и вычислительной техникой.
Раз у нас IT проект, нам нужны программисты. Но не только, программисты могут писать код, т.е. переводить с человеческого на машинный, а переводить пока нечего.
Нужен постановщик задач - это может быть проект-менеджер (Project manager). Это специалист, цель которого выпустить продукт точно в срок и соответствующий неким условиям, назовем их требованиями. Что такое требования? Это набор условностей для работы над проектом. Где их берут? В простом случае их берут у заказчика продукта. Есть еще продуктовая разработка, в этом случае требования собираются с целевой группы клиентов, универсализируются или расширяются для разумной свободы, накладывают на требования нормативную базу. Цель создать продукт, который соответствует требованиям, но и предоставляет возможность расширения и улучшения в дальнейшем. Пример со строителями: вы сделали лифт? А чего он только вертикально двигается? Сделайте, чтобы и горизонтально тоже двигался. Итак, задачи собираются от заказчика, если он есть, но с учетом нормативных и законодательных документов, чтобы одно другому не противоречило. И заниматься этим будет менеджер проекта или аналитик, все зависит от объема, если у нас один единственный заказчик - справится и менеджер проекта, а если у нас 100 только нормативных документов - мы потеряем менеджера проекта, поэтому тут нужны будут отдельные 2-3 аналитика.
Процесс адаптации требования для программистов. Эти специалисты любят задавать вопросы характера: Вам просто print написать или в for его заключить? Поэтому процесс адаптации требований проводит еще один отдельно выделенный специалист - это архитектор. Этот специалист реализует первоначальную архитектуру проекта, а именно: на каком языке программирования вести разработку, какие библиотеки используем, состав этого всего вплоть до версий и ревизий. Далее, он расписывает спринты (периоды разработки) на 3-6 месяцев вперед для тимлида программистов. В спринтах расписано в какие сроки какая функциональность должна быть готова. Исходные данные берутся из требований. После чего совместно с тимлидом согласовывают график работ. Тут задача, чтобы тимлид согласился с этим графиком, т.к. выполнение работ будут требовать с него. Для примера спринт - это две недели. В 3-х месяцах грубо 6 спринтов, расписываем 4 спринта, 2 спринта отдаем для долгов (50% от запланированных это резерв), когда не уложатся, не подойдет выбранная библиотека и т.д. - в результате архитектор постоянно нужен и должен “держать руку на пульсе” всего проекта. Примерно в середине разработки проекта функции архитектора сокращаются и от отдельно выделенного специалиста можно отказаться. Основные проблемы на проекте решены, архитектура устоялась идет плановый процесс разработки. В маленьком проекте функцию архитектора может выполнять тимлид. Программистами дело не ограничивается, если большой объем работ ожидается от других специалистов то ПМ и архитектор должны согласовать с ними график. Если на первоначальном этапе график не согласован вероятность неудачи 101%.
Тимлид расписывает задачи каждому программисту на спринт. Тут все понятно, программировай давай! На первое время задача тимлида получить собранный продукт, который ничего делать не будет. Пример: продукт можно установить, его можно запустить, получить главное окно программы, получить сообщения-закрывашки при нажатии на кнопки и пункты меню. После чего это уже можно показывать архитектору и менеджеру проекта как основу продукта.
Тестировщики - еще специалисты, обойтись без которых можно, но будет больно и возможно безрезультатно. Цель у тестировщиков - выпустить продукт, который соответствует требованиям. Как у менеджера проекта. В чем состоит работа тестировщиков - они выполняют процесс проверки соответствия поведения продукта с его требованиями. Если есть расхождение (несоответствие) - это баг (жук). Главное - процесс тестирования начинается с момента сбора требований (тестирование требований) и продолжается до момента передачи продукта в продажу и фиксация багов, которые попали таки в релиз.
Кто еще из специалистов нужен? Это дизайнер интерфейсов, сисадмин, специалист отдела информационных технологий для закупок техники, софта и прочего (сисадмин с этим тоже может справиться). Эти специалисты нужны не на 100%, поэтому их работа размазывается между несколькими проектами.
Менеджер проекта (ПМ) - если он не собирает требования, то ему и заняться нечем. Это только с одной стороны. ПМ как раз собирает всю команду, является их начальником и идеологом. Решает вопросы с вышестоящим руководством, а главное не дает вышестоящему руководству отвлекать членов команды от работы. Решает вопросы о принятии на работу сотрудника, увольнении, регулирует отпуска сотрудников и их материальное вознаграждение (далеко не везде так). Т.е. является альфой и омегой всех проблем на проекте. А для вышестоящего руководства это интерфейс взаимодействия с командой и с результатами по проекту.
Есть еще один важный специалист - это менеджер продукта. Это специалист, который взаимодействует с заказчиком напрямую, чтобы аналитика или ПМа не связывать с заказчиками. Чаще всего роль эту выполняет продажник, который заинтересован в продаже продукта и выполнении требований заказчика.
- менеджер проекта
- менеджер продукта
- архитектор
- аналитик
- тимлид программистов
- программист
- тестировщик (тимлид тестировщиков, тест-дизайнер, менеджер по тестированию)
- сисадмин (devops)
- дизайнер элементов интерфейса
- специалист отдела информационных технологий
Итого 10 специалистов разных направлений, без подсчета количества на проекте, допустим программистов может быть 3-5. Это все грубо и в вакууме, по итогу все будет зависеть от специфики проекта. Допустим разрабатываем компьютерную игру с открытым миром - нам понадобятся сценаристы или нарративные дизайнеры и много 3d художников и аниматоров.
Для войтивайти нужно определиться на какую специальность можно претендовать. На мой взгляд это: аналитик, программист и тестировщик.
Почему только три, менеджеров откидываю сразу, менеджер проектов по строительству не заменит менеджера IT проекта. Специалисты должны быть с опытом. Должности предполагают быть начальником, далеко не каждый согласится стать начальником, вернее не просто стать, а работать начальником.
Последние три специалиста распределены между несколькими проектами, им некогда учиться надо сразу работу работать, иначе они завалят сразу несколько проектов. Архитектор и тимлид - это должны быть грамотные специалисты, т.к. работа у них связана с богатым внутренним бэкграундом по технологиям, библиотекам и т.д.
Выбрали три специальности куда можно прийти начинающему специалисту. Как это сделать? Есть масса курсов, их я сразу не рекомендую. Насмотрелся я на таких специалистов, после курсов все в голове перепутано, не знают чему учили, а главное зачем. Толку мало. Реальным вариантом - попасть на стажировку в компанию с дальнейшим трудоустройством, т.к. за время стажировки к вам привыкнут и заниматься будете уже рабочими задачами, т.е. это такой длительный испытательный срок получится. При этом учеба на стажировке может оплачиваться. Главное зацепиться в компании.
Считается, что самое легкое это устроиться тестировщиком. Это далеко не так. Частенько тестировщику приходится применять знания и навыки и программиста и дизайнера и даже архитектора. А развернуть тестовый стенд сетевого проекта с шифрованием трафика это вообще не каждому дано. Поэтому здесь только смотреть от проекта, если проект простенький и понятный - то будет попроще. Но богатый внутренний бэкграунд лишним никогда не будет.