По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В сегодняшней статье расскажем о том, как проверить скачанные или добавленные модули в графическом интерфейсе FreePBX 13.
/p>
C недавних пор FreePBX имеет встроенную систему проверки подписи для всех официальных модулей. Это было сделано для того, чтобы конечный пользователь или администратор системы могли без проблем определить, подвергался ли модуль изменениям (например, из-за уязвимости системы безопасности, или же модуль вовсе вредоносный).
Неподписанные модули после обновления
Если после обновления с FreePBX 2.11 до FreePBX версии 12 или 13, на главной странице появляются информационные сообщения о неподписанных модулях (Unsigned Modules) это может означать, что Вы не завершили последнюю часть обновления. Для того, чтобы её корректно завершить требуется подключиться к вашей IP-АТС по ssh или через консоль и ввести следующий ряд команд:
amportal chown
amportal a ma refreshsignatures
amportal a reload
Эти команды запустят внутреннюю проверку модулей, а также проверку того, что все файлы имеют правильные разрешения. Если будут обнаружены модули, которые не имеют подписи, то система загрузит их заново и перезапустится. После этого, все предупреждения и ошибки должны исчезнуть.
Сообщения о неподписанных модулях на главной странице
Уведомления о подписи модулей были введены в FreePBX 12 как сообщения, которые появляются на главной панели (Dashboard) при обнаружении каких-либо проблем. Выглядит это примерно так:
Вы можете детально узнать подробности этих информационных уведомлений, нажав кнопку Details. Откроется анализ того, что не удалось корректно выполнить в процессе проверки целостности.
В качестве альтернативы можно также скрыть эти сообщения безопасности, нажав X в правом верхнем углу. Таким образом, уведомления будут скрыты до тех пор, пока не появится новый неподписанный модуль. Эти уведомления будут также отображаться на панели управления, в разделе System Overview и приходить по электронной почте в следующем виде:
Желтые уведомления безопасности являются общими предупреждениями. В то время как красные сообщения, означают, что файл был изменен по сравнению с тем, каким он первоначально был во FreePBX. Например:
Вы можете отключить все уведомления о недействительной подписи в меню Advanced Settings, установив Enable Module Signature Checking в положение False.
Настоятельно не рекомендуем выставлять флаг Enable Module Signature Checking в положение False в системах, которые работают в продакшене, поскольку данное действие отключает несколько уровней системной защиты.
Типы предупреждений
Существует два типа предупреждений о подписи модуля, их описание ниже:
Unsigned - неподписанные модули. Это модули, которые не были санкционированы командой разработчиков FreePBX. Они потенциально могут иметь вредоносный код, который может угрожать вашей системе. Установка этих модулей на свой страх и риск.
Altered - изменённые модули. Это модули, имеющие файлы, которые были модифицированы по сравнению с их первоначальной версией. Рекомендуется повторно загрузить эти модули, чтобы предотвратить возможные проблемы с вашей АТС.
Система контроля версий (Version Control System) – это инструмент, который используется для отслеживания, внесения и управления изменениями в программном коде. Это также можно назвать просто контролем версий.
Системы контроля версий помогает разработчикам сохранять изменения, внесенные в файл, на разных этапах, чтобы и они сами, и их коллеги могли их увидеть позже.
Существует три типа систем контроля версий:
Локальные системы контроля версий
Централизованные системы контроля версий
Распределенные системы контроля версий
Что такое локальная система контроля версий (LVCS)?
Этот тип системы контроля версий очень распространен и прост в использовании. Однако этот метод может выдавать ошибки и подвержен атакам, потому что файлы хранятся в вашей локальной системе.
Это означает, что вы можете потерять системный файл или случайно забыть каталог, с которым вы работаете (и затем записать в другой каталог).
Что такое централизованная система контроля версий (CVCS)?
В этом типе контроля версий сервер работает как общее хранилище, в котором находятся все версии кода. CVCS помогает разработчикам работать совместно.
Однако, несмотря на то, что такой метод позволяет разработчикам сотрудничать, если сервер отключится на несколько секунд или будет поврежден, то есть шанс, что вы потеряете все файлы. Это является серьезной проблемой при работе с CVCS.
В CVCS только несколько разработчиков могут работать совместно над проектом.
Что такое распределенная система контроля версий (DVCS)?
В настоящее время это новый и наиболее часто используемый тип системы контроля версий.
В DVCS у каждого разработчика есть полная резервная копия всех данных на сервере. Это означает, что всякий раз, когда сервер не будет работать или будет неисправен, то вы все равно сможете работать над своим проектом, а также копировать или создавать резервные копии своих хранилищ на сервере, чтобы восстановить их.
При работе с DVCS над одним проектом может работать много разработчиков. Одной из популярнейших DVCS является Git, о которой мы сейчас будем говорить подробнее.
Что такое Git?
Git – это бесплатная распределенная система контроля версий с открытым исходным кодом, которую можно использовать для отслеживания изменений в ваших файлах. В Git можно работать над всеми типами и размерами проектов.
С помощью Git вы можете добавлять изменения в свой код, а затем фиксировать их (или сохранять), когда это необходимо. Это означает, что у вас есть возможность вернуться к ранее внесенным изменениям. Git работает рука об руку с GitHub. А что же такое GitHub?
Что такое GitHub?
GitHub – это веб-интерфейс, в котором можно хранить свои репозитории Git, а также эффективно отслеживать и управлять своими изменениями. С его помощью разные разработчики имеют доступ к коду одного проекта. У вас есть возможность вносить свои собственные изменения в проект одновременно с другими разработчиками.
Например, если вы вдруг допустили какую-то ошибку во время внесения изменений, вы можете легко вернуться к предыдущему этапу, где ошибки еще нет.
Для чего нужно использовать GitHub?
Есть множество причин для использования GitHub. Давайте рассмотрим некоторые из них.
Эффективное управление проектами
GitHub – это своего рода хранилище ваших репозиториев. GitHub позволяет разработчикам работать над одним проектом, находясь в разных местах.
С помощью GitHub вы можете легко отслеживать внесенные вами изменения и управлять ими, а также проверять ход вашей работы над проектом.
Простое сотрудничество
С GitHub разработчики со всего мира могут работать вместе на одним проектом без каких-либо проблем.
Команды разработчиков могут оставаться на одной странице во время совместной работы над проектом и могут легко организовывать и эффективно управлять проектом.
Открытый исходный код
GitHub – это бесплатная система с открытым исходным кодом. Это означает, что разработчики могут легко получить доступ к различным типам кода/проектов, которые они могут использовать для обучения и развития своих навыков.
Универсальность
Это свойство GitHub очень важно. GitHub – это веб-интерфейс не только для разработчиков. Его также могут использовать дизайнеры, писатели и все, кто хочет отслеживать историю своих проектов.
Как настроить Git?
Чтобы использовать Git, его необходимо загрузить на свой компьютер. Сделать это можно, зайдя на официальный сайт.
Когда сайт откроется, прокрутите страницу вниз, и вы увидите кнопку загрузки. Нажмите на нее.
Выберите свою операционную систему: Windows, MacOS, Linux/Unix. В моем случае я выбираю Windows, потому что я использую компьютер именно с этой операционной системой.
Нажмите на первую ссылку в самом верху страницы, чтобы загрузить последнюю версию Git.
Когда загрузка будет завершена, установите Git на свой компьютер. Для этого вам нужно будет перейти в папку, куда был загружен файл, и установить его.
После завершения установки, необходимо убедиться, что Git успешно установлен в вашей системе. Откройте командную строку или Git bash (в зависимости от того, что вы решили использовать) и выполните команду:
git --version
Если Git был успешно установлен на вашем компьютере, то он должен отобразить текущую версию Git под командой, которую вы только что выполнили. Если отображается, то мои поздравления!
Как настроить Git?
Теперь, когда мы установили Git на компьютер, нам нужно его настроить. Мы делаем это для того, чтобы каждый раз, когда мы работаем в команде над проектом, мы могли бы легко идентифицировать сделанные нами коммиты в репозитории.
Чтобы настроить Git, нам нужно указать имя, адрес электронной почты и ветку с помощью команды git config --global. Например:
На изображении выше мы использовали git config --global user.name для настройки имени пользователя. То же самое относится и к конфигурации git config --global user.email.
Git имеет ветку по умолчанию master, можно поменять называние, чтобы она называлась main, с помощью команды git config --global init.default branch main.
Теперь вы готовы начать использовать Git.
Чтобы настроить учетную запись GitHub, зайдите на их официальный сайт. Нажмите на кнопку регистрации в правом верхнем углу:
Когда откроется форма регистрации, введите свой адрес электронной почты, создайте пароль, введите свое имя пользователя, а затем проверьте все, прежде чем нажимать кнопку создания учетной записи.
Популярные команды Git
Есть несколько основных команд Git, которые должен знать каждый разработчик:
git config
git init
git remote add origin
git add
git commit
git clone
git push
git rm
git branch
git diff
git log
git checkout
git merge
Давайте кратко рассмотрим каждую из них, чтобы вы понимали, как их использовать.
Как использовать команду git config
Эта команда используется для того, чтобы установить имя пользователя, адрес электронной почты и ветку пользователя, чтобы определить, кто зафиксировал изменения при работе над проектом. Эта команда используется, когда вы загрузили Git на свой компьютер и хотите настроить его для своего использования.
Например:
git config --global user.name “[username]”
git config --global user.email [email address]
Как использовать команду git init
Эта команда используется для того, чтобы запустить Git в своем проекте для отслеживания изменений, внесенных в проект.
git init
Когда вы запускаете эту команду, вы должны увидеть, что папка с названием .git автоматически создалась в текущей папке, над которой вы работаете.
Как использовать команду git remote add origin
Теперь мы укажем нашей кодовой базе (папке, в которой находится наш код), где хранить наш код в облаке. Мы введем git remote add origin [your-repo-url], который установит источник для нашего репозитория. Теперь мы можем заливать (пушить) код в наш источник (origin), чтобы сохранить его на наше облако в GitHub.
Как использовать команду git add
Эта команда добавляет ваш файл в промежуточную область (staging area). Промежуточная область – это та область, в которую добавляются файлы, в которые мы вносим изменения, и где они ждут следующего коммита.
Чтобы добавить файл в промежуточную область, нужно воспользоваться командой git add. Она добавляет все файлы в папке в промежуточную область.
git add (file name) добавляет имя конкретного файла, который вы хотите зафиксировать в промежуточной области.
Эту команду нужно использовать тогда, когда вы внесли изменения в файл и хотите зафиксировать их в своем проекте.
Как использовать команду git commit
Эта команда фиксирует любой файл, который был добавлен с помощью команды git add, а также все файлы в промежуточной области.
git commit –m “first commit”
Эта команда навсегда сохраняет файл в репозиторий Git. Ее необходимо использовать каждый раз, когда вы добавляете файл в промежуточную область с помощью команды git add.
-m называется «флагом» и сигнализирует о том, что есть необязательные действия, которые мы хотели бы выполнить с этим комитом. Флаг m означает, что впоследствии мы предоставим сообщение, которое является в нашем случае - «first commit».
Как использовать команду git clone
Эта команда используется для того, чтобы скопировать существующий репозиторий в другую область из одного места в другое.
git clone (repository name)
Эта команда используется, когда вы хотите продублировать репозиторий Git из GitHub в локальное хранилище.
Как использовать команду git push
Эта команда используется для того, чтобы загрузить/отправить файлы из локального репозитория/хранилища в другое хранилище, например, в удаленное, такое как GitHub.
git push (remote storage name)
Эта команда используется только тогда, когда вы довольны всеми изменениями и комитами, которые были сделаны в проекте, и, наконец, хотите отправить их в репозиторий Git на GitHub.
Как использовать команду git rm
Эта команда используется для того, чтобы удалить файл из рабочего репозитория.
git rm (filename)
Эта команда используется только тогда, когда вам необходимо избавиться от нежелательных изменений или файлов из репозитория Git.
Как использовать команду git branch
Эта команда используется для того, чтобы проверить текущую ветку, над который вы работаете, main или master.
git branch
Эта команда поможет вам узнать имя текущей ветки, над которой вы работаете.
Как использовать команду git diff
Git покажет вам разницу между кодом, который у вас есть сейчас, и кодом, когда он был сохранен в последний раз.
Немного сложно понять, что здесь происходит, но - — это удаления, а + — вставки. Мы удалили текст Hello, this is a git example и добавили текст Now I have changed the first line. Так Git отслеживает, что изменилось между версиями.
diff --git a/git.js b/git.js
index eb0f1d1..8dbf769 100644
--- a/git.js
+++ b/git.js
@@ -1,3 +1,3 @@
+console.log('Now I have changed the first line.')
-console.log('Hello, this is a git example!')
console.log('And here is another!')
console.log('And yet a third')
Как использовать команду git log
Мы можем просмотреть сделанные нами коммиты с помощью команды git log. Это может выглядеть так:
commit 67627dd44e84a3106a18a19e94cf9f3723e59b3c (HEAD -> master)
Author: amberwilkie amber@amberwilkie.com
Date: Wed Apr 22 16:55:39 2020 -0400
Update first console log
commit 49fe4152f474a9674a83e2b014a08828209d2690
Author: amberwilkie amber@amberwilkie.com
Date: Wed Apr 22 16:54:59 2020 -0400
Initial commit
Мы видим наши сообщения комиты, время, в которое мы их совершили, и уникальный идентификатор для нашго комита, который мы можем использовать для ссылки на коммиты в будущем.
Как использовать команду git checkout
Если мы хотим вернуться и увидеть изменения в нашем коде из предыдущего коммита, мы сделаем это с помощью:
git checkout 49fe4152f474a9674a83e2b014a08828209d2690
Git поместит наш код во временное состояние, чтобы мы могли посмотреть, как код выглядел на этом снимке во времени. Тут мы использовали идентификатор комитаю
Чтобы вернуться к нашей ветке, введите git checkout [branch_name].
Как использовать команду git merge
git merge возьмет все коммиты, которые вы сделали в этой ветке, и вставит их в основную ветку, сохранив вашу работу.
Ветки
Git полагается на ветвление для поддержки нашего кода. Вы можете считать главной веткой (обычно это master или main) ствол вашего дерева кода. Вы можете отпочковаться от нее и внести некоторые изменения, но конечная цель всегда состоит в том, чтобы вернуть их в ствол, в основную ветку.
Вы можете использовать git checkout для создания новой ветки, а не только для проверки предыдущих версий вашего кода. Попробуйте использовать git checkout -b new-branch. Флаг -b используется, когда мы создаем новую ветку, и после флага мы пишем имя нашей новой ветки. Мы можем сделать много коммитов в этой ветке, а затем вернуть их в master с помощью процесса, называемого слиянием (merging), используя для этого команду git merge.
На диаграмме ниже точки обозначают коммиты. Две ветки были сделаны от мастера. В разработке программного обеспечения мы часто называем эти «функциональные» (feature) ветки, в отличие от основной главной ветки. Синяя ветвь была объединена с мастером, а желтая ветвь все еще находится в разработке.
Обратите внимание, что несмотря на то, что желтая ветка была создана после синей ветки, в этой ветке будут видны только изменения из мастера. Если мы создадим третью ветку когда-нибудь в будущем, изменения как из master, так и из синей ветки будут присутствовать в новой, третьей ветке.
Просмотр кода в GitHub
Теперь ваш код находится GitHub!
Вы можете щелкать по файлам и папкам вашего репозитория, просматривая текущее состояние кода. Вы также можете просмотреть предыдущие версии кода. Вы увидите список коммитов, сделанных в репо, и если вы нажмете на них, вы сможете просмотреть файлы вашего проекта в том виде, в каком они существовали в этот период времени.
Пулл-реквесты
Есть много других возможностей GitHub, но самая важная в совместной работе с коллегами — это пулл реквесты (pull request). Пулл реквест (очень часто сокращается до PR или ПР) — это способ управления входящими изменениями в базе кода. По сути это событие, когда один участник просит влить свои изменения в ветку.
Чтобы сделать это, вы создадите новую ветку на своем локальном компьютере, создадите хотя бы один комит в этой ветке, а затем сделайте git push origin head отправите эту ветку на GitHub. (Вы можете указать имя своей ветки вместо заголовка, но это полезно для точного соответствия всех элементов).
Теперь, когда вы вернетесь на GitHub, вы увидите, что ваша ветка доступна для создания PR.
Если вы нажмете кнопку Compare & pull request, вы сможете изменить многие настройки для своего PR. Наиболее важными, как правило, являются заголовок и описание. Если вы работаете в команде, вы можете пометить коллег, чтобы попросить их просмотреть ваш код, добавить в проекты и использовать многие другие функции.
Обратите внимание, что мы сравниваем ветки. Здесь мы просим добавить изменения из этой ветки (pr-пример) в основную ветку. Но мы могли бы ориентироваться на любую другую ветку в нашем репо. А пока просто помните, что master — не единственная ветка, с которой вы можете сделать ПР.
Когда вы нажмете Create Pull Request, вы увидите этот экран:
Вы можете посмотреть все коммиты в этой ветке, а также можете слить свой пулреквест.
Помните, как мы могли объединить наш код локально при помощи merge, когда говорили о Git? Мы можем выполнить то же действие с нашим облачным кодом на GitHub. Если вы нажмете зеленую кнопку Merge pull request, ваши изменения будут объединены в мастер.
Заключение
Благодаря этому руководству, вы узнали, что такое системы контроля версий. Также вы узнали, как установить и настроить Git на своем компьютере и настроить учетную запись GitHub. И, наконец, мы рассмотрели некоторые популярные команды Git.
О переходе в IT профессию не думал разве только тот, кто в IT сфере уже работает. Высокие зарплаты, постоянная удаленка, куча плюшек и битвы HR-ов за самый оригинальный подкат к айтишнику на LinkedIn. Насмотревшись на фотографии и рассказы друзей айтишников, все это заставляет многих подумать: а не пора ли сменить профессию? Если задумались - значит пора. А мы, в свою очередь, поможем разобраться, какие бывают айтишники и как вам войти в айти.
Говоря про айтишников, многие представляют себе программистов, их еще называют девелоперы (от английского developer) или разработчики. Но поверьте, айти не заканчивается на них, а скорее только начинается. Разновидностей программистов - как товаров на Amazon: frontend, backend, full-stack, веб-программисты, мобильные и десктоп разработчики, DevOps программисты и прочие.
Особенно важно разобраться с тремя первыми - фронт, бэк, и фуллстэк.
Понять разницу между фронтэнд и бэкэнд девелопером - ну очень просто. Фронтенд пишет все, что происходит в видимой зоне, а бэкенд - за видимой зоной. Сейчас разберемся на конкретных примерах:
Netflix: красивую картинку с палитрой интересных киношек, кнопки, слайдеры и все, что вы видите в видимой зоне - сделали фронты. Алгоритмы рекомендаций, авторизацию, списание денег с вашей карты, то есть биллинг, и другие компоненты на фоне - сделали бэкенд девелоперы. Когда в следующий раз будете реветь от рекомендаций мелодрамы, которая ранила вас прямо в сердечко - это бэки постарались.
Amazon: карточки товаров, категории, навигация, отзывы и прочая визуальщина - фронты. Передача на на фронт актуальных цен товаров, калькуляция условий доставки в ваш регион мешка с леденцами со вкусом корицы, механизм умного поиска - бэки.
А еще есть фуллстэк программисты - это те, кто умеют и бэк и фронт.
В среднем, чтобы стать фронтом, надо поучить HTML, CSS, JavaScript - это база, с которой уже можно верстать сайты. Но технологии не стоят на месте и сейчас зачастую обычного знания JavaScript бывает недостаточно, поскольку во многих местах используются различные фреймворки расширяющие функционал языка, такие как React, Angular или Vue.
Ну а поскольку разработчик всегда работает с командой, то нужно знать как работать с системами управления версиями, зачастую это Git и уметь работать с API, чтобы найти общий язык с бэкэнд.
Бэкенд девелоперу, очевидно, нужно знать один из языков программирования для бэка. Какой? Вам нужно определиться самому. Посмотрите вакансии, которые вас интересуют и поймите, что нужно в компании вашей мечты.
Самые известные и популярные языки это Java, Python, PHP, С, С#, С++, Ruby и Go. Их очень много, но не стоит отчаиваться глядя на их количество - изучив один язык и поняв принципы программирования, вы сможете легко перейти на другой язык.
Еще можно выделить мобильных разработчиков, которые делают приложения для iOS и Android - им нужно подучить Objective-C и Swift для iOS и Kotlin или Java для андроида.
Поскольку разработчики пишут код не в вакууме, а взаимодействуют с различными системами, то вам нужно знать про SQL и принципы работы с базами данных. И очень важно уметь работать с NoSQL - нереляционными базами. Если хочешь заниматься только базами то для этого даже есть отдельная профессия - администратор баз данных (DBA).
Если вы будете заниматься веб разработкой, то нужно знать про принципы работы HTTP и про модель OSI, про веб сервера, как минимум Apache и Nginx, как работают API, аутентификация, основы безопасности. Уф, ну кажется этого должно хватить для начала.
Идем дальше - тестировщики, а они же QA (Quality Assurance). Тестирование бывает ручное, а бывает автоматическое. Автоматизаторы, безусловно, ближе к программистам - им нужно разрабатывать алгоритмы, знать процессы разработки ПО и его тестирования.
В ручном тестировании - все немного попроще. Зачастую тестирование становится отправной точкой для карьеры будущего айтишника. Входной билет сюда чуть ниже, войти проще. Нужно знать классификацию тестирования, методы и инструменты, уметь создавать сценарии тестирования. Нужно базово понимать протокол HTTP и модель OSI, немного HTML и CSS. Хорошо бы уметь работать с командной строкой, знать SQL, принципы API чтобы гонять запросы в каком-нибудь клиенте типа Postman, знать инструменты автоматического тестирования, такие как Selenium или Sahi.
Уф, кажется, основные профессии, связанные напрямую с разработкой софта мы проговорили. Теперь, друг, давай разберемся с не менее крутой частью IT, где ощущается острейший дефицит кадров - это инфраструктурные айтишники.
Итак, сетевые инженеры - без них не “взлетит” ни одно приложение, сервис, сайт, платформа, да что угодно! Сетевики настраивают маршрутизацию трафика, управляют сетью и гарантируют взаимодействие айти - инфраструктуры с внешними сетями. Открывая Tinder, каждый свайп вправо генерирует запрос к серверам, который прилетает в дата - центр тиндера и маршрутизируется на нужный сервер - это как раз сетевик постарался.
Сетевик должен знать основы сетевых технологий - классической школой в этом плане являются технологии Cisco (а также Huawei, Juniper и Mikrotik), надо знать технологии виртуализации, уметь работать с операционными системами Linux и Windows Server, иметь представления о кибербезопасности и уметь читать и базово говорить по английски.
И конечно безопасники - про их востребованность сейчас, вы наверняка догадываетесь. Среди них выделяют:
Инженеров - эти ребята делают безопасной сеть, настраивают фаерволы, антивирусы, анти-DDoS, прокси и прочие средства защиты
Аналитиков - которые выявляют инциденты, мониторят и находят вредоносную активность, расследуют взломы, утечки и другие неприятные моменты
Пентестеров - это HackerMan’ы по найму. Ага, эти ребята занимаются легитимным взломом, чтобы потом вы могли закрыть все дырки обнаруженные ими и не стать жертвой настоящих хакеров
Консультантов - знают все законы и требования в ИБ, помогут в получении нужных бумаг, чтобы не попасть на штрафники от всяких регуляторов
Appsec, Cloudsec - занимаются безопасностью приложений и облачной инфраструктуры
В компаниях постоянно идут эпические битвы между айтишниками и ИБшниками, потому что последние, довольно параноидальные ребята. Они стараются максимально обезопасить инфраструктуру и её активы, вводя для этого различные правила. Например - хочешь подключиться к корпоративному VPN? Сначала пройди двухфакторную аутентификацию! Долго? Зато безопасно.
Для безопасника будет полезно понимать основы сетевой безопасности, а также операционных систем, знать что такое триада CIA и принцип Defense in Depth, ну и конечно же - знать какие существуют методы атак, вредоносного ПО и прочих ИБ угроз.
Так же есть более узкопрофильные направления - Linux или Windows администратор, специалист по IP - телефонии, администратор баз данных, SRE инженер и многие другие! Ну и конечно можно наоборот выделить широкопрофильного системного администратора - специалиста, который настраивает и поддерживает ИТ инфраструктуру компании и должен знать много вещей из разных областей.
Так, кажется большинство популярных технических направлений мы проговорили. Теперь давайте прыгнем к менеджерам, тем, кто управляет ИТ проектами и продуктами с точки зрения бизнеса. Вообще, скажем так, быть техно - коммерческим специалистом в айти отрасли ну крайне выгодно: комбинируя хороший технический бэкграунд, знание бизнес специфики, добавив высокие коммуникативные навыки и надев белую рубашку вы автоматически получаете высочайшую зарплату, корпоративную тачку и прочие радости. Ладно, шутка, давайте разбираться.
Продакт менеджеры (они же продакты) - эти ребята отвечают за коммерческий успех продукта и реализацию бизнес требований. Продакт знает такие фреймворки как Scrum и Agile, должен знать цикл разработки программного обеспечения, отвечать за список задач на разработку, который также называют “бэклог” и обязательно уметь говорить на одном языке с разработчиками, топ-менеджментом, продавцами, маркетингом и другими подразделениями компании. Пожалуй, продакт должен знать такие инструменты как JIRA, Trello, Miro, Slack и Wrike, и уметь анализировать метрики успеха продукта.
Если хотите двигаться в это направление, рекомендуем получить интересующие вас технические навыки, а потом двигать в бизнес плоскость - почитать Lean Startup, “Спросите маму” Роберта Фитцпатрика и про Scrum у Джеффа Сазерленда. Эти книги помогут вам базово сориентироваться в пространстве и получить базовое представление.
Проектные менеджеры, они же delivery менеджеры - они отвечают за реализацию проекта - контроль сроков, доставку функций продукта в продакшн, то есть в реальную среду работы продукта, отвечают за организацию человеческих ресурсов и планирование, в том числе релизов. Из хард скиллов вам надо знать что такое "Диаграмма Ганта", изучите свод знаний по управлению проектами PMBOK, который разработан американским Институтом управления проектами (PMI), знать гибкие методологии и уметь работать с теми же инструментами, что и продакту (JIRA, Trello, Miro, Slack и Wrike).
А еще есть UX - дизайнеры, продуктовые дизайнеры, аналитики, но они имеют менее технический уклон, чем продакты и проджекты.
Познать востреброванные айти профессии, получая знания в легкой и дружелюбной форме можно с помощью нашей платформы доступного айти образования Merion Academy: ознакомиться со списком курсов и пройти бесплатные вводные уроки можно по этой ссылке.