Всем привет!

Меня зовут Рыловникова Татьяна. Я ведущий аналитик в компании Ви.Тех, а еще идейный вдохновитель клуба Питерских одинэсников, ведущая и автор подкаста «Аналитики у микрофона», докладчик и модератор на конференции АиУП.

Уже несколько лет для профессионального развития мне не хватает только курсов, аттестаций, видео и книг, я бы хотела поделиться с вами моими способами развития, расскажу на своем примере 5 способов, как еще может развиваться аналитик:

1. Обратиться к ментору

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

2. Самому стать ментором

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

3. Книжный клуб

Я столкнулась с тем, что чем более я погружаюсь в профессию, тем более объемной становится литература. Так, например, долго ходила вокруг книги Карла Вигерса «Разработка требований к программному обеспечению». Даже купила ее, начала читать, но, учитывая объем материала, я в нем терялась. Тогда я подумала, чтобы было бы классно читать книгу с коллегами. Сделала на работе книжный клуб для аналитиков, мы читаем по 2 главы раз в 2 недели и обсуждаем их. Главный профит: ребята рассказывают то, что пробовали или хотели бы попробовать и как на самом деле это выглядит на практике. Материал воспринимается намного лучше. А еще у меня прокачиваются организационные навыки.

О том, как очищается вода на пути в частные квартиры, на Хабре писали уже довольно много. Эта вода приходит в водопровод уже частично очищенной местным поставщиком. А потом дополнительно фильтруется системами фильтрации на вход, стоящими в квартире, — и становится питьевой. 

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

Мы в БАРЬЕР много лет изучаем этот путь воды и стараемся его облегчить, совершенствуя собственные системы фильтрации для коттеджей. Под катом мы проследим путь воды из скважины к потребителю в частном доме на примере нашей коттеджной системы очистки, покажем состав воды из скважины до и после фильтрации, и подробно расскажем про каждый этап. 

Привет! Меня зовут Екатерина Никишина, и я занимаюсь HR-проектами в ИТ-компании CUSTIS. Каждый год перед нами, как и перед тысячами компаний, вставал вопрос, как праздновать 23 февраля и 8 марта? Делать ли это в привычном формате отдельно мальчики, отдельно девочки или что-то менять? Как вовлекать сотрудников, когда многие работают в гибридном или удалённом формате? А главное — как сделать праздник, соответствующий ценностям и корпоративной культуре компании?

В этой статье я расскажу о нашем опыте: как мы пришли к традиции отмечать общий праздник «23 + 8», а со временем сделали из него серию полезных и интересных мероприятий под названием «Инженерная весна».

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

Перед вами перевод статьи автора Doug Bridgens, в которой он рефлексирует свой опыт и критически отзывается о Agile. В его статье совсем нет анализа и аргументации, это личные размышления на тему конкретного разработчика.

Это мой второй перевод и я позволю себе в этом предисловии пару предложений о том, зачем я потратил свое время на этот перевод:

Всем привет! В этой статье я поделюсь нашим первым выпуском второго сезона рубрики "Открытый микрофон", в котором Николай Мухранов, старший системный аналитик в "Спортмастер Лаб" рассказал о менторстве в IT.

Коля - преподаватель курсов для системных аналитиков, ментор и наставник для студентов, проводит технические собеседования системных аналитиков, так что знает о менторстве не понаслышке!

Публикую расшифровку доклада и саму запись трансляции.

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

Эта публикация вдохновлена одной из многочисленных презентаций о том, как планировать спринт в разработке, коих за свою жизнь я видел очень немало. И все они похожи одна на другую, как однояйцевые близнецы - всегда очень красивые рисунки и выверенный текст типа «тут у нас аналитика, вот разработка и тестирование, двухнедельный спринт, в конце спринта все задачи закрыты, руководство в восторге, заказчик счастлив». Я же хотел бы показать реальность такой, какая она есть.

«Я хочу творить, а не быть следствием чужого творчества. Я хочу принадлежать к тем, кто создает смыслы, а не быть плодом этого смысла».

Представьте себе ситуацию. Скоро истекут сроки подачи документов в колледж. Очередная партия новичков изберет профессию, адепты которой постоянно задаются вопросом: «А нужны ли будут программисты через год... через пять лет... или через десять лет?». И хотя горячие дебаты на этот счет уже улеглись, в воздухе висит немой вопрос: не настанет ли час, когда крупные языковые модели, такие как ChatGPT, заменят нас на поприще написания кода. Неважно, кто ты — абитуриент, зависший в нерешительности перед выбором ВУЗа, или матерый кодер, я предлагаю тебе остановиться и кое-что переосмыслить. А поможет нам в этом деле... кукла Барби.

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

1. Выбираем книгу.
2. Определяем часть, которую необходимо прочитать за неделю. Выбираем небольшой объем.
3. В пятницу обсуждаем прочитанное.
4. Читаем в нерабочее время, обсуждаем в рабочее.
5. После окончания книги совместно выбираем следующую.

1. Мотивация на чтение и дочитывание.
2. Развитие скиллов (в том числе на будущее).
3. Выравнивание майндсета и терминологии в команде.
4. Рост доверия.
5. Лишний повод пообщаться.

Привет, Хабр! Меня зовут Настя Рыбкина, я бизнес-аналитик в Спортмастер Лаб.

В бизнес-анализ я пришла около 1,5 года назад со сменой профессии, и, честно скажу, было нелегко разобраться поначалу, с чего стоит начать обучение, да просто чем вообще занимается бизнес-аналитик, чем он отличается от системного, потому что многие интерпретируют эти роли по-своему, и как ворваться в эту профессию.

Эта тема всегда актуальна, особенно для тех, кто на пороге смены карьеры или в поиске себя, поэтому мы с коллегами решили провести прямой эфир в "Со-обществе" Спортмастера на тему образования и карьеры для бизнес- и системных аналитиков, куда в качестве гостей позвали наших друзей, основателя STENET school Егора Марюшко и автора и лектора курсов для системных аналитиков Иннокентия Бодрова. Оба наших гостя помимо преподавательской деятельности несут миссию по созданию комьюнити для бизнес-, системных аналитиков, архитекторов и не только, где создают ламповую атмосферу, делятся своим опытом, рекомендуют книги, ресурсы и отвечают на любые вопросы подписчиков.

Это объект Pizza, там хранится инфа о латте, а заказали его в Restaurant или в Pizzeria? Неудобно? Максимально. Мы читаем код существенно больше, чем пишем. И хочется сразу понимать, что происходит, не играя в квесты «что имел в виду автор», «да как это работает» и «я снова ничего не понял». Без навыка давать хороший нейминг невозможно писать качественный и поддерживаемый код. Про нейминг говорят заодно, в рамках архитектуры и общих инженерных практик. В статье поговорим про него отдельно.

Как получается, что код становится мало понятным даже для его авторов? Почему нейминг так важен? Как придумывать названия, не применяя целые теории нейминга? Как лёгким процессом организовать работу с неймингом в команде? На все эти вопросы мы ответим в статье.

Не ходите, девки, замуж! 
Ничего хорошего!..

Ребята, вы серьёзно? Хотите в ИТ? Извините, но вам тут не место…

Нет, мне не жалко вакансий для кого-то со стороны, благо их до боли много. Перманентно нахожусь в состоянии поиска специалистов, но их НЕТ!!! И проблема не в отсутствии желающих занять тёпленькое местечко, а в катастрофической нестыковке желаний с возможностями. И знаете что самое ужасное? Люди, порой, даже не осознают, что ИТ-специальность им не подходит от слова “совсем”. И для этого есть ряд причин, давайте разложим всё по пунктам: во-первых, отсутствие хард-скилов, во-вторых, отсутствие софт-скилов, и наконец, отсутствие врожденных способностей. Да, да, последняя фраза именно о главном - о том, что люди не равны с рождения. И да, в ИТ не может попасть каждый желающий, а причина этому - вы не так устроены с рождения. Уж простите! Но тут совершенно не на что обижаться! Я объясню…

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

Любите Захер? Я люблю. Но испытываю на этот счет смешанные чувства. Если бы Франц Захер запускал производство своего торта в сегодняшней России, добрые люди посоветовали бы ему подумать над сменой названия. Так же, как подсказали в свое время сменить фамилию первому болгарскому космонавту Георгию Какалову.

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

1. Спать регулярно, ложиться и вставать в одно и то же время — самое важное. 
2. Биоритмы — частично наследуются, частично регулируются стилем жизни. На них можно влиять самому.
3. Нормальное время отхода ко сну около 22:00. Сова и жаворонок — это отклонение на ±1-2 часа. Больше — это нарушение и сдвиг фазы сна, чаще из-за внешних раздражителей.
4. Самая частая причина плохого сна и тяжелого засыпания — неправильный свет.
5. Для сдвига режима на 1 час организму нужен 1 день на адаптацию.
6. Невозможно «доспать» бессонную ночь. Досыпание устраняет только 30% последствий недосыпа.
7. Прежде, чем искать причины плохого сна, исключите психологические проблемы (тревожность, депрессию), нарушения щитовидки, дефицит железа, диабеты, сердечно-сосудистые заболевания и патологию почек и мочеполовой системы.
8. Водителям и пассажирам: 17 часов без сна равны 0,5 промилле, 21 час без сна — 0,8 промилле.
9. В постели без сна больше 15 минут не находиться — совет при бессоннице. 
10. Самые физиологичные будильники — те, что светятся. 

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

Если вы занимаетесь программированием на vue.js, то вот вам ссылка на компонент, который включает различные input поля в том числе для номеров телефонов. Мне кажется данный компонент может сильно облегчить вам жизнь, ниже ссылка на github и гифка как работает одно из полей. На этом по вступлению все, дальше только по теме.

https://github.com/fakt309/inputv

Уверен, вы слышали, что требования к разрабатываемому ПО должны быть S.M.A.R.T. - Specific (конкретные), Measurable (измеримые), Attainable (достижимые), Relevant (значимые) и Time-bound (своевременные). Слышали это правило все, но часто ли мы соблюдаем его? Часто ли проверяем требования по этим критериям? Если нет – мало обжигались. Давайте пофантазируем с примерами: «Что, если…»

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

Вместо предисловия

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

Но, как известно, есть некоторые особенные люди, которые могут попытаться проверить, ошибаются ли мухи верно ли то, что делают все? Приятно, черт возьми, ощущать себя особенным!

Для начала попробуем подсчитать стоимость ритуалов SCRUM

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

- дейли митинг, он же стендап митинг. Вообще-то он должен занимать до 15 минут, но моя команда обычно хорошо если укладывается в 30 минут. Каждый день.

- планирование работ на будущий спринт. Тот самый процесс, где мы всей командой весело играем в карты. Обычно это занимает минимум 2 часа в спринт. Включает в себя декомпозицию задач из беклога, оценку и распределение. Да, в моей команде распределение проводится на планировании, нет такого, что на доске висят задачи, и сотрудники берут какую хотят.

Эта статья помогает понять, как команды в Scrum и agile могут давать гарантии и сроки, сохраняя гибкость в планировании. Она будет полезна тем, кто заинтересован в четких сроках реализации доработок: заказчикам, пользователям, владельцам продукта, другим командам и отделам. А также разработчикам — для понимания, почему сроки так важны стейкхолдерам и как можно вести диалог о сроках, сохраняя при этом гибкость.

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