Менеджмент

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

Ранее мы уже выпустили фундаментальный разбор Disaster Recovery (DR): что это такое, чем RTO отличается от RPO и какие стратегии защиты существуют. Если вы еще не посчитали, во сколько миллионов обойдется вашей компании день простоя — рекомендуем начать с первой части.

Вам наверняка попадался тот самый мем: «Как видит проект заказчик / как видит разработчик / как видит пользователь». Так вот, я — тот парень, который рисует четвертую картинку: «Как это должно работать на самом деле» и «как сделать продукт, который устроит всех». 

Меня зовут  Ярослав, я data pre-sale в MWS. За долгие годы работы я совершил массу ошибок и однажды чуть не похоронил проект, потому что послушал заказчика и не поговорил с бухгалтером, которому в итоге предстояло пользоваться продуктом. Оказалось, их боли — две огромные разницы. В итоге я вывел для себя два главных правила:

— Не бойся ошибаться, бойся ошибаться медленно. Чем раньше ты получишь фидбэк от реального пользователя, тем дешевле и быстрее все исправишь.

— Твоя главная суперсила — не техстек, а синергия. Умение переводить с языка бизнес-хотелок на язык Python и обратно, а потом и на диалект «бухгалтера Галины Ивановны» — вот что определяет успех твоего проекта. 

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

Если вы до сих пор пытаетесь выстроить нормальную работу в таск-трекере — расслабьтесь. Это скучно и неблагодарно. Гораздо интереснее использовать эти 11 вредных советов.

Работаю в ИТ с 2004 года. Пришёл осознанно в индустрию не за деньгами - по любви к технологиям и тишине, когда можно заставить машину делать нужные вещи. Начинал с настольных приложений на Delphi, бэкенд на Python, немного React. Сейчас Финтех.

История о том, как, работая тимлидом Python-команды, решился принять вызов на переход в сферу 1С и что из этого вышло.

Недавно я тут на Хабре написал цикл статей про «Запрещенные фразы для ИТ-менеджера». Это фразы которыми неопытные менеджеры пытаются отбиться от неожиданных задач, и это же фразы, от которых почему то плохо заказчикам, бизнесу и начальству.

Там я разбирался почему плохо, и почему фразы:

— Этого нет в ТЗ!

— Этого нет в должностной инструкции!

— У меня нет на это ресурсов!

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

Каждая статья собрала больше 10 000 прочтений, и в каментах к каждой был вопрос: «Окей, чел, если так говорить нельзя, то как можно? Расскажи и покажи на примерах, раз такой умный!»

Это — мой ответ на вопрос, а заодно — легкая шпаргалка, которую можно сохранить и применять постоянно, отправляя тем, кто этого подхода еще не знает.

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

Основана она на моем личном опыте (см профиль), на опыте менеджеров, у которых я этому учился и на опыте менеджеров, которых я этому учил сам, как РПО и ментор.

Статья написана по мотивам публикаций в моем ТГ канале «Морковка спереди, морковка сзади», который полностью посвящен управлению в IT, а особенно той его части, которой толком никто не учит: софтскиллам. Если вам это интересно, заходите, читайте и подписывайтесь, там уже почти 4000 манагеров, также читайте мои статьи тут, на Хабре.

Итак, поехали.

Сравниваю, что изменилось в генерации изображений с выходом Nano Banana 2

Полгода назад OpenAI выкатил прорывную генеративную модель. Но она страдала от 5 больших проблем: консистентность, кириллица, сложные сцены, мелкие доработки и кадрирование.

С тех пор вышли два релиза, которые наконец-то решают эти проблемы: Nano Banana в августе и Nano Banana 2 в ноябре.

Сравниваю на реальных примерах — что изменилось и что теперь можно пускать в продакшен ⤵️

Привет, Хабр! Меня зовут Евгений Морогов, я руководитель центра продуктовой акселерации в «Газпром ЦПС». Я работаю в проекте по внедрению VR-технологий, и сегодня я расскажу о том, как мы создавали VR-тренажер по ликвидации инцидента газоводонефтепроявления (ГПНВ) на буровой.

ГНВП — один из самых опасных инцидентов на буровой. Отработка подобных ситуаций на полигонах и на физических тренажерах «вживую» осложняется рядом факторов, которые не позволяют закрыть все потребности в практической подготовке cпециалистов. Среди них высокая стоимость, сложное масштабирование, отсутствие обновлений и возможностей для совместной подготовки, высокие логистические затраты и ограниченность сценариев. Мы решили эти проблемы с помощью VR-тренажера, создав детальную цифровую копию буровой установки.

Если у вас есть похожие задачи, вам интересно, как VR-технологии могут помочь бизнесу или в обучении — этот материал для вас. В статье подробно расскажу, как устроен наш VR-тренажер, как он создавался, какие технические решения мы использовали и как работает наша математическая модель. А также поделюсь, какими были наши первые успехи «в полях».

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

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

Эта статья написана в попытке собрать в одном месте материал о появлении и эволюции взглядов на First-mover Advantage (FMA) и разложить разницу между первопроходцами, ранними последователями и поздними входящими.

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

Если лонгрид не близок по формату, ниже есть блок с кратким содержанием.

Краткий PMBoK, возможности Ганта, STATIK, контрольная диаграмма, диаграмма сгорания задач, топ таск‑трекеров, ошибки делегирования, манипуляции на проекте, синдром спасателя и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

Вы платите за контекстную рекламу более 100.000 рублей в месяц, заявки дорожают, конкуренты поднимают ставки, рентабельность падает. Кто-то говорит: «Попробуй SEO», другой советует: «Запусти таргет», третий: «Делай email-рассылки». А вы думаете: «А вдруг не сработает? Вдруг солью бюджет впустую?» И продолжаете платить всё больше за то, что работает всё хуже.

Знакомо? Сегодня разберём, почему страх попробовать что-то новое обходится дороже, чем сам эксперимент. И как тестировать новые каналы без риска потерять всё.

Привет, Хабр! На связи Лера, технический писатель в Авито. Сегодня разбираем научный бестселлер «Зачем мы спим» Мэттью Уолкера — профессора нейробиологии, одного из ведущих исследователей сна и основателя Центра изучения сна при Беркли.

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

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

Необходимы широкий инструментарий для разных процессов, отраслевые модули и практики, а также возможность дополнить их кастомом с помощью low-code.

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

Оценить уровень с точки зрения функциональной готовности помогут: 1. Функциональные, 2. Технологические и 3. Организационные критерии.

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

1.    Функциональные критерии.

1.1. Мастер-данные 

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

Эта статья — про то, как перестать саботировать самого себя и научиться р��ссказывать о своей работе так, чтобы ее оценили по достоинству.

Бизнес Додо активно масштабируется. Уже сейчас Dodo IS круглосуточно работает в двух облаках, более чем в 25 странах и практически во всех часовых поясах. В таких условиях важно знать, что вся система действительно работает хорошо, а не просто «не горит» прямо сейчас.

Чтобы это знание обрести, мы привезли в нашу инженерную савану SLO'на — неповоротливое, но умное существо. Он наводит порядок в хаосе метрик и алёртов, и отличает реальную проблему от мнимой. А ещё он требует внимания, точных чисел и ясных целей. Поначалу мы его боялись, но позже поняли: если его приручить, он защитит нас от ночных звонков и научит бизнес говорить на языке надёжности.

Сегодня мы расскажем, как приручили своего SLO'на и прошли путь от первых экспериментов с нагрузочным тестированием до построения культуры надёжности.

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

Упрощение процесса разработки за счет No-code и Low-code платформ, стремительное развитие технологий, кардинальным образом меняющих бизнес-процессы и программное обеспечение, покрывающее их, повсеместная автоматизация и возведение софтверных продуктов в ранг цифровых активов, привели к частым проектам перевнедрения. Если раньше предполагалась, что жизненный цикл программного обеспечения завершается его утилизацией, то сейчас об этом не может быть и речи. Отказ от приложений трансформировался в их замену на новые образцы, жизненный цикл же из линейного превратился в спиралевидный, то есть возвращающийся на начальный этап.

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

Позвольте представить: это Федор. Он — настоящий профессионал своего дела, мощный, как Минотавр. Только вот его личный лабиринт — это бесконечное выгорание на работе, а его рога упираются в потолок от постоянных попыток изменить жизнь.

Федор, как и многие из нас, часто решает: «С понедельника бегаю, прохожу курсы, правильно питаюсь!» Но запала хватает лишь на пару недель, а потом — откат. Почему? Все просто: Минотавр Федор пытается втиснуть новое в старый, тесный распорядок, вытесняя то, что и так еле держится.

Чтобы выбраться из этого лабиринта, нужна не сила, а система.

Когда‑то Федор, оправдываясь работой, забивал на семью, друзей, спорт и здоровье. Итог предсказуем: полное выгорание и бунт организма. Это стало его переломным моментом: он понял, что пора перестать быть жертвой обстоятельств и пересмотреть подходы к организации времени и пространства.

В этой статье хочу поделиться системой, которая позволит не откладывать дела, найти свой work‑life balance и достигнуть гармонии.

Уже год тестирую этот подход — работает! Теперь есть время для спорта, семьи, обучения и творчества — без ущерба для его карьеры. Качество жизни выросло, и я чувствует себя живым.

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

Приглашаю и вас к его костру: давайте поговорим о том, как навести порядок и превратить его в образ жизни, а не во временное, бессмысленное метание по лабиринту!

Как нейросети помогают ускорить создание плана проекта

Александр Михайлов

Портфельный менеджер Проектного офиса ИТ, «Норникель»

Привет! Меня зовут Михаил Остапинский, я Старший QA Engineer в KTS, где занимаюсь не только тестированием, но и менторством младших специалистов.

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

В этой статье я хочу поговорить о том, что обычно остаётся «за кадром» в работе ментора — о мотивации. Как понять, когда менти теряет интерес? Как вовремя заметить первые сигналы выгорания? И главное — как ментору поддерживать «силу команды», сохраняя баланс между результатами и состоянием людей?

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