Менеджмент

Жизненный цикл любого проекта включает в себя этапы инициации, планирования, исполнения, контроля и завершения. Гибкие методологии и итерационный подход используют в проектах по разработке программного обеспечения всё чаще. С ними этапы проекта повторяются несколько раз для каждой итерации, а перечень инструментов аналитика максимально упрощается и сводится до написания user story. 

Этой статьёй я открою серию материалов про управление требованиями на разных этапах проекта.  Уже больше 10 лет я работаю в IT и успела побывать бизнес аналитиком, системным аналитиком и руководителем проектов. Также я выступаю в роли ревьюера на курсе «Системный аналитик». 

Начинающим аналитикам бывает не просто разобраться в разных подходах к документированию  требований и множестве нотаций моделирования. У кого-то даже проскальзывают сомнения, а нужно ли все это знать или можно просто изучить формат описания user story? Я попробую развеять эти сомнения на примере учебного проекта.

Мне было лет 11-12, моему братишке на год меньше. Мы решили открыть небольшой бизнес по продаже газет, первоначальный капитал накопили, собирая и сдавая бутылки в пункт приема. Газета представляла собой аналог из “Рук в руки” - бесплатные объявления, телепрограмма и анекдоты.

Бизнес на первый взгляд довольно простой...

Уже традиционно для этого года подводим итоги месяца в гейм-индустрии. Март не стал исключением, поскольку несколько десятков компаний уволили более 600 человек. И хотя число уже не кажется таким большим на фоне 8 000 уволенных сотрудников за январь и февраль, ещё рано говорить об улучшении ситуации.

Немного первоАпрельских рассуждений на Ленту ;) Скучно мы живем, господа. Жизнь стала суровая и к шуткам не располагает. Или не так?

Предлагаю вашему вниманию небольшое эссе-экспромт о природе смеха.

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

Удобная дата - первое апреля. Именно в этот день можно браться за любую ерунду. Не выйдет - можно свести всё к шутке. А если выйдет... то получится любопытная статья.

Вы когда-нибудь думали, можно ли найти месторождение золота (или ещё какого-нибудь полезного ископаемого) по спутниковым снимкам Гугла, Яндекса или по другим подобным сайтам? Кажется, это малоперспективное занятие. Но давайте попробуем.

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

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

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

На самом деле, не открою какой-то космос – техника очень хорошо описана в BABOK (10.38 - Risk Analysis and Management). Но на практике вижу, что не только менеджеры, но даже аналитики (для которых это стандарт - как учебник) не используют технику. Многие ошибочно считают управление рисками чем-то скучным, рутинным, бесполезным, формальным. Хотя на деле это очень эффективный и вовсе не сложный инструмент.

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

Привет, Хабр.

Выдался вечер, в который я всё-таки дозрел поделиться с вами небольшой рефлексией. Я на Хабре уже три года и три месяца, почти всё это время мне удаётся публиковать примерно по 4 лонгрида в месяц, а с некоторого времени — и по паре переводов в месяц (в этом блоге встречаются научно-популярные переводы, а под технические переводы у меня существует второй блог @Sivchenko_translate большинство из публикаций в котором сделаны по заказу редакции Хабра, а именно — уважаемого @atomlib Тематика у моих лонгридов разнообразная, но в основном это Geektimes, а не чистый Habr — то есть, естественнонаучные сюжеты, попадающие в хаб «Научно-популярное», ещё минимум один другой хаб, никак не относящиеся к хабам по языкам
программирования, менеджмент-хабам и практически не попадающие в хабы «Научная фантастика» и «Читальный зал».

На Хабре неоднократно в комментариях звучало мнение, что Россия впереди планеты всей по онлайн‑сервисам. Мол, у нас и госуслуги, и финтех, и такси, и доставки — все на высочайшем уровне, а в остальных странах, а особенно в отсталой Европе бедные бюргеры до сих пор стоят в многочасовых очередях, заполняют вручную тонны бумажек и ждут в очередях на кассах чтобы сделать банковский перевод, а курьер не привезет им ночью смузи в течении получаса после заказа. Давайте разбираться, так это или нет.

За МКАДом зарплаты в несколько раз меньше, чем в ДС. Это правда. Но нужно учитывать, что у каждого жителя замкадья есть огород и приусадебное хозяйство. Жители замкадья питаются с огородов, выращивают птицу и скот. Поэтому деньги им нужны только на одежду и коммунальные платежи. А значит вполне справедливо было установить им меньшие зарплаты, чем в Столице, где приходится покупать в том числе и продукты питания.
Как я вижу, эта паста из как минимум 2018 года не утратила силы, только стала звучать короче – «Для замкадья ЗП озвученную ранее считаю нормальной».
Для лиги лени: HR копируют друг у друга статьи «вода жидкая» и «На рынке дефицит высококвалифицированных низкооплачиваемых кадров». Иных изменений нет.
Сама статья - низкокачественное нытье, можно не читать.

Хочу представить вашему вниманию бесплатный курс Java Тренажер, который недавно опубликовал на платформе Stepik.

Java — это объектно-ориентированный язык программирования, разработанный компанией Sun Microsystems (позднее приобретённой компанией Oracle). Он был выпущен в 1995 году и с тех пор стал одним из наиболее популярных языков программирования благодаря своей платформенной независимости, простоте использования, масштабируемости и широкому спектру применения.

Наша команда Mobile Doc&Loc «Лаборатории Касперского» занимается подготовкой документации и локализации B2C-продуктов компании для мобильных устройств. Основная сложность (и одновременно фишка) нашей работы заключается в том, что необходимо регулярно подготавливать переводы на 34 языка в крайне сжатые сроки.

Меня зовут Юлиана Соломатина, я — Doc&Loc-инженер, и в этой статье я расскажу про инструменты-автоматизации, которые помогают нам справляться с наплывом задач и укладываться в дедлайны, не жертвуя при этом качеством. Кстати, многие из этих инструментов мы разработали сами.

Помните те времена, когда компания Electronic Arts ещё пыталась делать какие-то классные проекты, которые, помимо интересного геймплея, могли предложить наикрутейшую лицензированную музыку? Уверен, многие из вас хранят в памяти различные части серии Need For Speed, FIFA и NHL, но лично у меня та эпоха ассоциируется прежде всего с NFS Underground и Burnout 3: Takedown. И если про первую я уже делал небольшой рассказ, то про вторую… расскажу сегодня. В своё время она взрывала мой мозг уникальным, не похожим ни на что драйвовым геймплеем, а также красивой графикой и добротной музыкой. Пожалуй, именно благодаря играм от EA тех лет в моих плейлистах оказалось множество классных музыкальных групп, которых при ином раскладе я так никогда бы и не услышал.

Что же из себя представляла Burnout Revenge? Она была тем, о чём мечтал каждый, кто играл в Need For Speed – аркадные гонки на огромных скоростях с красивой графикой и собственным физическим движком, позволяющим с хорошей детализацией разбивать как машины соперников, так и свою (в наличии особые режимы игры, целью которых является создание как можно большего количества разрушений за секунду времени)! Под крутой музон вы управляли красивыми тачках на дичайших скоростях, достигаемых благодаря легко восстанавливаемому нитро! Как такое могло не понравиться? И несмотря на то, что игре скоро исполнится 20 лет, она и сейчас выглядит довольно приятно, а что уж говорить про впечатление геймера, запустившего её в те годы на пузатом телевизоре...

Сегодня хочу поговорить про баги на ПРОДе и о том как защитить команду от этого, ведь для реализации необходима помощь всей команды в выстраивании процессов разработки ПО. Прекрасное название этой статьи говорит само за себя - если не получается защитить команду от багов, то точно получиться защитить себя от стресса, ведь не все зависит от QA.

Важно подсветить, что под багом подразумевается отличие ожидаемого результата от фактического. Мы ожидали, что при нажатии кнопки А будет окно В, но происходит совершенно другое. На схеме выше отображаются риски не только появления бага, но и не предусмотренных ошибок в виде программа не делает лучше, а только затрудняет использование.

Первый риск: Идея попадает к аналитику

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

Второй риск: разработка по тех. требованиям

Frontend и Backend разработчики берут задачи из бэклога в спринт, но в задаче может быть прикреплена устаревшая документация, ее может и вовсе не быть.

Мысли о персональных проектах и стартапах, которые никогда не взлетели. О том значении, которое они имеют для самого автора этих проектов. Об интересных концепциях из области психологии и психотерапии, которые могут помочь посмотреть на эту проблематику под другим углом.

Все настоящие программисты делают свои проекты.

Когда-то давно, ещё до массового появления мобильных телефонов, было модно делать shareware-проекты. По-нашему, значит, пилить стартапы. Просто слова «стартап» тогда ещё не было. Зато ещё был жив и отлично себя чувствовал Delphi, а линукс оставался диковинкой для гиков. Хотя нет, слова «гик» тогда ещё тоже не было.

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

А по-другому просто  и быть не могло. Потому что красивый дизайн, как мы теперь знаем, — это забота дизайнеров. А дизайнеров интерфейса, как специалистов отдельного вида, тогда ещё тоже не было. Много ещё чего не было. Веб-сайты отличались от настольных приложений далеко не в лучшую сторону. Правильно верстать DIV’ами ещё никто не умел, а про книгу «Веб-дизайн» Якоба Нильсена ходили лишь смутные слухи.

Немного позднее появилась книга «Интерфейс: Новые направления в проектировании компьютерных систем» Джефа Раскина. Не знаю как вы, а я за 20 лет так и не встретил ни одного программиста, который бы её прочитал. А жаль. Про то, что есть такой компьютер, как Mac от Apple, знают многие. Про Билла Гейтса, отца Windows, наверное, знает ещё большее число людей. Но как-то так вышло, что никто не слышал про Джефа Раскина, который проектировал интерфейс для Apple Macintosh. Ну да ладно, что-то я отвлёкся…

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

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

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