🖥Друзья, у Альфа-Банка сегодня начался набор на бесплатное обучение. Заявку можно оставить до 29 сентября, обучение начнётся 31 октября. Знаю, что среди подписчиков, есть ребята, кому интересны бизнес- и системный анализ, оба направления есть!

Остальные направления:
🟣тестирование (для специалистов с опытом работы);
🟣alfa factory — Pega-разработка;
🟣прикладной Data Science в финтехе (для специалистов с опытом работы);
🟣проектирование учебного контента.

Все вопросы об обучении вы можете задать в чате альфа-кампуса🙂

@CSBM

Пет-проекты

В этом году особую популярность в ИТ-кругах набирает понятие «пет-проекты». Хотя само слово существует уже несколько лет, я об этом слове узнала примерно месяц назад, но как оказалось, такие проекты у меня есть👍

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

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

Изначально данное понятие ограничивалось разработчиками, но в наше время оно имеет более широкий смысл. Пет-проект – это любой проект, которым занимается человек с целью получения профита в будущем (это может быть финансовый доход, повышение узнаваемости себя в профессиональных кругах, развитие в отличном от работы направлении).

Сегодня мы ограничимся сферой ИТ, т.е. пет-проектами, которые связаны с будущей или текущей профессией в сфере ИТ.

Плюсы наличия пет-проекта:
🟣применение на практике полученных знаний;
🟣возможность реализации своих личных идей;
🟣контроль времени, т.е. в зависимости от конечной цели можно самостоятельно решать, сколько уделять проекту времени;
🟣отличная строка в резюме, на которую всё чаще смотрят.

Сложности при ведении пет-проекта:
🟣занимает свободное от работы время;
🟣нужны постоянные мотивация и понимание, для чего этот проект создаётся;
🟣для некоторых ИТ-направлений крайне сложно найти идею для такого проекта.

Как начать свой пет-проект?
1️⃣Понять, для чего нужен проект: для портфолио, реализации своей идеи и пр.
2️⃣Найти идею: это может быть как своя личная идея, так и доработка учебного проекта, а также поиск идей в профессиональных сообществах.
3️⃣Оценить сложность выбранной идеи. Здесь потребуется консультация со специалистом из отрасли. Если проект требует разработки, то лучше спросить у опытного разработчика, насколько реально сделать это самому на старте.
4️⃣Построить примерный план и начать реализацию.

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

P.S. Некоторые пет-проекты отличаются от стартапов только тем, что живут за счёт неоплачиваемого человеческого ресурса и с минимальными расходами.

@CSBM

Что даёт работа в пет-проекте?😑

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

Как я писала в понедельник, есть ещё один способ получения нужного опыта – это работа в пет-проекте. И здесь появляются другие трудности – как найти такие вакансии? Я знаю о таких вариантах:
🟣основной – это поиск в профессиональных каналах, сообществах и чатах (например, если вы изучаете Python, то и искать вакансии для пет проектов стоит в группах, направленных на изучение Python);
🟣долгий - поиск на различных конференция и мероприятиях (онлайн и оффлайн);
🟣неочевидный – подписка на личные тг-каналы людей, уже работающих по профессии.

Здесь сразу хочу рассказать 2 #истории , чтобы возникла картинка в голове, как всё может происходить.

История 1

Пару месяцев назад я подписалась на тг-канал, в котором парень делится своими результатами, как он вкатывается в ИТ. Он погрузился в разработку и решил сделать свой пет-проект (сайт), о котором ничего не рассказывал до прошлой недели. Проект стал близиться к логическому завершению, и автор решил о нём рассказать, так как проект будет публичным. Наполнение сайта будет содержать информацию о разных ИТ направлениях, но т.к. создатель не является экспертом во всех областях, он на своём канале попросил о помощи. Я на прошлой неделе делала две задачи по бизнес- и системному-анализу, и за время работы обратила внимание на отсутствие нужной информации для начинающих БА и СА в некоторых вопросах (не критичных, но очень ценных), и у меня возникли варианты для дальнейшего развития сайта (этот вопрос уже обсудили с автором, но пока на уровне идеи). Для меня в этой истории пока что нет ничего ценного с точки зрения полученного опыта, но есть информация, которую можно использовать в будущих проектах и возможно даже сделать востребованный продукт. Время покажет, получится или нет, пока что надо приземлить идеи и понять, как их можно реализовать.

История 2

В сентябре 2022 г. два опытных разработчика решили создать свой продукт с минимальными финансовыми вложениями. Я об этом проекте узнала в августе этого года на мероприятии. Проект существует год, имеет свою полноценную команду (17 человек), успешно тестирует гипотезы и развивается. Когда основатели поняли, что им нужно увеличивать штат, но они не готовы платить заработную плату, потому что стадия проекта не позволяет определить, будет ли проект успешен, ребята решили нанимать в штат на джуниорские позиции. Для начинающего специалиста это отличная возможность, так как полученный опыт в таком проекте будет ценнее, чем работа в компании, где все процессы отлажены. Не всем подойдёт такой формат, но это отличная возможность получить практический опыт и возможно даже реализовать какие-то свои идеи внутри проекта, потому что, как правило, у таких проектов есть гибкость в принятии решений😏

@CSBM

Роль и должность

При выборе специальности в ИТ у людей часто возникают трудности из-за «размытости» требований в вакансиях. На одну и ту же должность 5 разных компаний могут предъявлять абсолютно разные обязанности с небольшим общим пересечением. Такие вакансии не являются единичными и создают хаус на старте. Почему же так происходит?

Сначала надо разобраться с определениями слов «роль» и «должность». Роль – это специальность, регламентированная профстандартом. В России есть общероссийский классификатор занятий (ОКЗ), в котором перечислены все актуальные профессии и их обязанности. Однако наличие ОКЗ не обязывает компании придерживаться строгого следования описанным профессиям и их обязанностям, поэтому обязанности, не попадающие под соответствие ОКЗ принято относить к должности. Должность – это специальность с определёнными обязанностями. Каждая компания вправе сама определять список обязанностей.

Причины, по которым возникают такие существенные отличия:
🟣компания небольшая и недавно на рынке. Для минимизации расходов руководители таких компаний ищут работника-универсала;
🟣компания давно на рынке, функционал к конкретной профессии внутри такой компании существует достаточно давно и зарекомендовал себя;
🟣компании, которые не понимают, чем занимаются некоторые специалисты. За свою практику я видела немного таких компаний, но они есть. Как правило, у таких компаний специфичный продукт и из-за этого требуются очень специфичные специалисты. Работодатели не понимают, как назвать человека, которого они ищут и поэтому называют должность так, как им кажется правильным. С этим ничего не сделать, но такие вакансии сразу бросаются в глаза.

Есть компании со скрытыми обязанностями (об этом я напишу отдельный пост):
🟣компания указывает стандартное описание профессии, но во время работы выясняется, что функционал значительно шире. Эта распространённая практика, особенно в крупных компаниях, где много бюрократии, и чтобы уменьшить неожиданное разрастание обязанностей, которые не обговаривались, необходимо задавать вопросы на собеседовании (интересоваться, какими задачами занимаются сотрудники на аналогичной должности в проекте, какой опыт выстраивания работы для каждого сотрудника и т.п.).

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

@CSBM

Горизонтальный рост специалиста

Во время работы у специалиста есть два варианта, как расти – это горизонтальный или вертикальный рост. По моему наблюдению, сейчас большинство сотрудников в ИТ спустя несколько лет работы выбирают горизонтальный рост, но этот выбор происходит уже после вертикального роста. То есть сначала специалист получает опыт и расширяет навыки внутри своей профессии, а уже потом решает, куда ему расти дальше.

Для справки:
Горизонтальный рост – это расширение профессиональных навыков, навыки не обязательно принадлежат своей профессии.

Вертикальный рост – это рост внутри профессии с дальнейшим переходом на руководящие должности.

В каждом посте, где я рассказываю о специальностях в ИТ, я указываю, куда может расти этот специалист. Вертикальный рост внутри профессии сопровождается грейдами. Дальнейший рост зависит от самого человека. Часто, когда специалист 2-3 года поработает, начинает думать, а куда ему расти дальше. И вот здесь у меня есть интересное наблюдение – большинство выбирает горизонтальный рост. Например, есть бизнес-аналитики, которые наращивают свою экспертизу в продакт-менеджменте или наоборот, либо есть менеджеры проектов, которые имеют навыки продакт-менеджера. О программистах так сказать не могу, недостаточно данных.

Почему специалисты выбирают горизонтальный рост?
1️⃣Поработав с разными людьми и в разных компаниях, человек начинает лучше понимать, чем бы хотелось заниматься именно ему. Не всем подходит управление людьми, и многие это понимают, поэтому начинают наращивать свою экспертность вширь.
2️⃣Как я писала в предыдущем посте, есть компании, где обязанности между конкретными профессиями размыты. В начале карьеры это создаёт сложности и непонимание, но со временем это даёт возможность большего выбора, так как у специалиста шире функционал.

В ИТ-сообществе нет строгих правил, какого роста должен придерживаться специалист. Главное – это его навыки и возможность внести ценный вклад. С одной стороны это даёт свободу выбора, а с другой – муки этого самого выбора👀

@CSBM

Когда хочешь сменить компанию, но не готов к этому

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

Есть компании, которые очень сильно ограничивают обязанности специалиста по каким-то своим причинам. В августе ко мне на собеседование попала девушка, которая работала уже около 2-х лет бизнес-аналитиком. Стоит сразу сказать, что по непонятным мне причинам мой руководитель после ознакомления с резюме решил, что собеседованию быть, однако для меня там было всё понятно😐

Два года работы профессии в ИТ позволяют практически любому специалисту вплотную приблизиться к среднему рангу специалистов (middle), или же им стать. Если кто-то выбивается из общего числа и задерживается в джунах, то тут, как правило, такие причины: человек выбрал не ту профессию и ему тяжело вкатываться или же ему просто лень работать на полную. Я писала, что ИТ – это постоянное развитие.

🔭Итак, дано: бизнес-аналитик с опытом работы около 2-х лет, умеет использовать в работе несколько диаграмм (в одной из таких диаграмм даже я не особо разбираюсь), тестовое задание выполнил на троечку. Обязанности на текущем месте работы сильно ограничены, и это ограничение не разрешает оценить специалиста выше, чем джун.

Во время общения БА рассказывает о том, что ему хочется развития, которое компания ему не даёт, и что у него так много энтузиазма для этого самого развития. Это очень распространённая ситуация. Можно на собеседовании рассказать, какие трудности есть на текущем месте работы, но, чтобы заявлять о том, что вы ценнейший сотрудник, который жаждет развития, грех такое говорить, если вы не можете как-то подкрепить свои слова. Словами результат не покажешь🤷‍♀️ Конечно же, данное интервью закончилось отказом.

Как избегать такие ситуации:
1️⃣Определите, каких навыков вам не хватает.
2️⃣Самостоятельно их получите, причём практически – ищите курсы, тестовые задания в разные компании и прорешивайте.
3️⃣При решении тестового задания старайтесь использовать ту механику, которая лучше всего подходит для выполнения задания.

Вы потратите некоторое время перед поиском работы, но результаты будут намного лучше🚀

@CSBM

Успеть всё за неделю

В ИТ практически всегда всё нужно было сделать ещё вчера. И не важно, что проект стартует только сегодня.

В пятницу мне направили два проекта с одинаковыми сроками, точнее, проектов ещё никаких нет, а есть заказчик, которому нужны две готовые системы прямо здесь и сейчас, и у которого «крыша» сверху. Из короткой встречи с заказчиком мне было мало, что понятно, кроме как «купи, мам». Только я осознанная мама и не могу купить вот так сразу, мне надо произвести анализ. На анализ мне выделили аж целую неделю, за которую надо выяснить все бизнес, функциональные и нефункциональные требования, а также определиться с архитектурой! Для понимания ситуации, такой объём работы обычно выполняется несколько месяцев в зависимости от размера проекта. С большой вероятностью, мне бы дали ещё неделю, но там я буду уже в отпуске, поэтому на этой неделе я, видимо, устану уже сегодня🤡 Конечно, надо было уже вчера.

Интересно посмотреть, чем закончится эта история и будет ли у неё счастливый конец.

На сегодняшний день план очень простой – выяснить у заказчика, как покупка готовой системы закроет те боли, что есть сейчас, и на сколько % заказчик готов к внедрению системы. Если не на 100%, то я не вижу смысла бежать вперёд паровоза.

Пойду составлять огромный список вопросов ко встрече. Будет жарко🔥

P.S. Второй проект мне удалось передать другому аналитику.

@CSBM

Продукт, который нужен уже вчера. Часть 1

Друзья, прошло две с половиной недели с того момента, как работа стала забирать у меня очень много времени и сил. Пришлось отложить посты в канале на некоторое время😱

Настало время подвести промежуточный итог о проделанной работе. Сегодня будут только результаты, а в ближайшие дни я расскажу, как так получается, что в ИТ можно легко создать хаос из ниоткуда и как с ним работать.

Что от нас ожидал заказчик и что мы не сделали:
🟣внедрили готовое ПО за пару недель;
🟣собрали всю необходимую информацию по двум (!) проектам за одну неделю.

Что от нас ожидал заказчик и мы сделали – познакомились😐 Без шуток. К цели заказчика нам приблизиться в первую неделю не удалось.

❗️Сразу хочу отметить, что заказчик (человек или группа лиц) в большинстве случаев не понимает (или не хочет понимать), как устроена техническая сторона вопроса (и в целом, как выстраивается работа на проекте) и поэтому могут возникнуть следующие ситуации:
🟣завышенные ожидания со стороны заказчика типа «мы же просим готовый продукт, почему им нельзя начать пользоваться уже завтра?», «мы же попросили одну кнопку, почему разработка займёт так много времени?» и т.п.;
🟣давление со стороны заказчика, когда заказчик начинает угрожать привлечением лиц, принимающих решения или законами и нормативными актами.

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

Что удалось сделать за первую неделю:
🟣провести огромное количество встреч с разными специалистами, заинтересованными лицами и потенциальными вендорами: с одной стороны, большое количество встреч больше мешает работе, чем помогает, потому что тяжело обрабатывать бесконечный поток информации, а с другой – хорошо видна слаженная работа команды, когда каждый участник знает о высокой важности проекта. Для работы аналитика это плюс, так как мы быстрее закрываем свои вопросы, а для коллег других ИТ специальностей это минус – так как им приходится откладывать другие задачи в сторону;
🟣составить сырой документ, в котором описано, какой продукт нужен, кому и для чего, без технической информации.

Вторая неделя прошла без меня, так как у меня был отпуск. Оба проекта легли на плечи одного аналитика. Что же удалось сделать:
🟣привести оба документа в полноценную концепцию, в которой расписано, что за продукт, какие цели должны быть достигнуты и пр.

Технические вопросы проработаны не были, но даже с имеющейся информацией уже стало понятно, что необходимо сделать и с какими сложностями придётся столкнуться. Сейчас мы упёрлись в бюрократические моменты, которые дали нам немного выдохнуть. Но уже совсем скоро придётся вернуться к высокому темпу работы.

Продолжение следует⭕️

Хард и софт скиллы

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

Хард скиллы (hard skills) – навыки и знания, необходимые для выполнения конкретной работы. Как правило, такие навыки являются техническими. Например, написание кода на Java, C++. Для нетехнических специалистов – это навыки, благодаря которым работа может быть выполнена: например, для HR – это умение находить релевантных кандидатов и проводить интервью.

Сотф скиллы (soft skills) – личные навыки, которые у человека уже есть и которым он может научиться. В этом понятии классифицируют более 50 различных навыков. Для нетехнических специалистов эти навыки очень важны. Для специальности Менеджер проекта в ИТ эти навыки намного важнее хард скиллов.Ниже рассмотрим те, которые чаще всего выделяют. Деление идёт по четырём категориям:

🟣навыки коммуникации: командная работа, ведение деловой переписки, умение слушать, ведение переговоров, публичные выступления;
🟣личностные навыки: самомотивация, эмоциональный интеллект, быстрая обучаемость, самоорганизация и тай-менеджмент;
🟣лидерские навыки: разрешение конфликтов, расстановка приоритетов, наставничество, принятие решений;
🟣развитие мышления: креатив, умение мыслить нестандартно, системное мышление, логическое мышление.

На протяжении последних десяти лет, если не дольше, в ИТ ведутся споры, каких сотрудников лучше нанимать, у которых слабая техническая база, но хорошо развиты софт скиллы, или наоборот. За столько лет так и не сложилось единого мнения: у каждой компании свой личный опыт и свой взгляд на ситуацию. Сейчас вопрос в этом споре больше звучит так: «Как нанять мотивированного сотрудника?», потому что такой сотрудник сможет прокачать практически любой навык.

На старте карьеры, конечно, хард скиллы являются более важными, чем софт (для технических специалистов). Без них просто не имеет смысла искать работу. Наличие софт скиллов сильно упрощает жизнь даже джуну, потому что такие навыки помогают закрывать массу вопросов, возникающих практически каждый день: отстаивание своей точки зрения в переговорах, предоставление развёрнутых ответов на вопросы, предложение новых подходов в решении задач и др. Именно софт навыки двигают проект вперёд. Отсутствие таких навыков у членов команды может порождать хаос и тормозить проект.

Как именно софт скиллы влияют на проект, и как их прокачивать, разберём в следующих постах👀

@CSBM

⌨️VK Education анонсировал 3 новых бесплатных курса по следующим направлениям:

🟣Базовый Python ознакомиться с программой и записаться;
🟣Алгоритмы и структуры данных ознакомиться с программой и записаться;
🟣Введение в анализ данных ознакомиться с программой и записаться.

❗️В рамках обучения студенты смогут также консультироваться с кураторами и участвовать в Q&A-сессиях с экспертами VK в онлайн-формате.

Всем, кто хотел попробовать, уже пора начать🚀

@CSBM