Таск-трекер без бизнес-процессов ― деньги на ветер! Самая частая ошибка ― пытаться заводить задачи, не продумав сам процесс. В этом тексте показываем 6 универсальных процессов, которые можно внедрить буквально за 10 минут: от онбординга до работы с подрядчиками.
Сейчас все топят быть продуктивным, эффективным. Я тоже адепт эффективности.
Как сделать еще больше, как иметь больше энергии?
Я пробовал Яндекс.Календарь, потому что я всегда пытаюсь пользоваться чем-то отечественным. Искренне хочу, чтобы у нас были классные вещи, но я не знаю, по какой причине Яндекс.Календарь — это пока что дно.
Что общего у руководителей, которые говорят:
– На рынке слишком много кандидатов-фродеров, которые вписывают фейковый опыт в резюме, обманывают меня на интервью и в итоге на синьорских позициях в моей команде работают джуны?
– Мне досталась слабая команда, я ни на кого не могу положиться и целыми днями тону в рутине, а сам не расту?
– Меня постоянно подводят смежники, факапят каждый инициированный мной проект?
– У нас в компании слишком размытые цели, я не понимаю, чего хотят от меня и моей команды?
Нет, не невезение.
Общее у них – непринятие ответственности и недостаточная зрелость.
Привет! Меня зовут Гульдар Ахунзянова, и я тестировщик в Яндекс Смене. В статье хочу рассказать о теме, которая может показаться банальной: как превратить рабочий хаос в управляемый порядок. Но за этой банальностью скрывается важная мысль: если вы тестировщик, у вас есть реальный инструмент, чтобы сделать жизнь (и свою, и команды) проще, понятнее и предсказуемее. И этот инструмент — процессы.
«Оформим позже», «ты в команде», «все всë понимают» — такие фразы часто звучат в мире стартапов. Особенно, если речь идёт о привлечении разработчиков, дизайнеров или консультантов на этапе «до юрлица».
Работа кипит: фичи разрабатываются, MVP собирается, первые пользователи тестируют продукт. А вот документы — остаются на потом.
Как показывает наша юридическая практика, именно это «потом» и становится отправной точкой для конфликтов. Особенно — если проект оказывается успешным, поднимает раунд или выходит на сделку с инвестором.
Чем лучше разработчик, тем хуже он делает аналитику. Просто потому, что для этого требуется разный технологический стек.
Системы, которые пишут разрабы, шикарно записывают и хранят данные. Но попытка прочесть большой объём данных сразу роняет всю систему, так как она плохо для этого предназначена.
В этой статье я расскажу про 2 ключевых подхода к хранению и обработке данных, какой мы выбрали для аналитики в Saas-платформе и к чему это привело.
Рассказываем про индивидуальный подход как основу успешного проекта DWH и делимся реальными кейсами внедрения:
✔️ Кейс 1. Свой коннектор к Oracle: когда Debezium подвел
✔️ Кейс 2. Миграция с Qlik: DWH между командами (в условиях командной фрагментации)
✔️ Кейс 3. Бюрократия против DWH: проект в около-госсекторе
«Наташа, мы всё уронили», — таких историй за мой восьмилетний рабочий стаж в продакт-менеджменте хватит с лихвой. Особенно когда ты имеешь дело не просто с понятным продуктом для конечного потребителя, а со сложным софтом, где даже секундное падение серверов или спорное цветовое решение админской стойки может привести к факапу.
Поэтому, когда я перешла в ISPsystem из ИТ-аудита в банке, мне казалось, что я сменила не только работу, но и Вселенную. Вместо проверок — мегаответственность за развитие продукта, вместо готовых регламентов — постоянные эксперименты. Часто — весьма рискованные.
Сейчас, как директор по продуктам, я понимаю: этот путь был не про везение, а про осознанные шаги, ошибки и умение учиться на них.
В этой статье — мой путь до СРО: практический опыт для тех, кто хочет вырасти, но не знает, с чего начать.
Управление IT-командой — это не только решение технических задач и координация рабочих процессов. Часто реальная боль заключается в том, что команда не чувствует вовлеченности, мотивация уходит, а конфликты остаются без решения. К тому же, удержание талантов становится всё более сложной задачей на фоне конкуренции. Но что, если ключом к решению этих проблем окажется эмпатия? В статье мы разберем, почему этот навык стал необходимым для успешного ИТ-лидера, и как он может стать вашим главным инструментом для улучшения атмосферы в команде, повышения её эффективности и минимизации конфликтов.
Почему даже сильные разработчики делают на авось?
Команда вроде опытная, но в проде — баги, архитектура — костыль на костыле, а фичи заливаются «на нервах»?
Технологии сейчас слишком стремительно развиваются и оказывают влияние на многие профессии. Я — системный аналитик, и искусственный интеллект всё плотнее проникает в мою профессиональную жизнь. Сначала это даже вызывало опасения. Что ждёт меня в будущем? Сможет ли ИИ заменить меня в профессиональном плане? Можно ли этого избежать и какие новые навыки будут нужны специалистам, чтобы оставаться востребованными? Попробую ответить на эти и другие вопросы.
Термин «artificial intelligence» в английском языке означает не столько «интеллект», сколько «умение логически мыслить». Это значит, что ИИ — это не аналог человеческого интеллекта, способного познавать мир и понимать суть вещей (согласно определению Линды Готтфредсон), а лишь система, которая способна делать выводы, решать задачи, понимать сложные концепции, быстро осваивать новое и учиться на основе полученного опыта.
Несмотря на впечатляющие возможности искусственного интеллекта в области логического мышления и решения задач, его функционал пока существенно отличается от способностей человеческого интеллекта. Полноценное познание мира и понимание его сути остаются за пределами возможностей ИИ. Однако развитие технологий происходит с невероятной скоростью, и в будущем все может измениться. А чтобы лучше понимать как и что менялось в этом направлении, давайте оглянемся в прошлое.
Всем привет! С вами Леша Жиряков, и сегодня я затрону тему планирования и Agile. Недавно кластер/трайб/холдинг, в котором я работаю, проходил трансформацию методов работы, все началось с идеи: а давайте сделаем продукт более открытым. С одной стороны, бизнес требует предсказуемости и возможности строить долгосрочные стратегии, с другой — рыночная турбулентность и подводные камни в IT диктуют необходимость быстрой адаптации к меняющимся условиям.
Это противоречие особенно остро проявляется при столкновении традиционного многолетнего планирования с гибкими Agile-методологиями, призывающими «реагировать на изменения важнее, чем следовать плану». Открытость, гибкость, скорость, эффективность, надежность — вот критерии успешного продукта. Но, развивая надежность, сложно оставаться гибким, повышая эффективность, рискуешь потерять в скорости, а стремление к открытости может снижать безопасность.
Классическое долгосрочное планирование на год и более даёт стратегическую перспективу, но часто оторвано от реальности быстро меняющегося рынка и технологий. Двухнедельные спринты позволяют гибко адаптироваться к изменениям, но затрудняют видение большой картины и координацию масштабных инициатив. Где же золотая середина?
Квартальное планирование становится компромиссным решением, позволяющим синхронизировать циклы бизнеса с работой IT-команд. Квартал как временной интервал достаточно короток для маневренности, но при этом дает необходимую устойчивость для реализации значимых инициатив. В умелых руках оно способствует Agile-трансформации, усиливает прозрачность и повышает эффективность команд. При неправильном внедрении может превратиться в бюрократический ритуал, возвращающий организацию к каскадным методологиям под видом прогрессивного подхода.
Мы живём в мире, где очень многое можно автоматизировать: так, разработчики пишут чистый код и разворачивают его нажатием одной кнопки, а следить за метриками можно в real-time. Казалось бы, идеально… Тем не менее иногда проекты рушатся, продукты буксуют, но никто не понимает почему… Или почти никто.
Меня зовут Сергей Синяков, я руковожу продуктом PT Application Inspector. За 15 лет опыта, от стартапов до финтеха, я усвоил главное — часто проблемы возникают не из-за технологий, а из-за человеческого фактора. Именно поэтому чуть ли не основные инструменты менеджера в ИТ — это разговоры, эмпатия и поддержка, а не только технические навыки и трекеры задач. Просто раздавая таски, вы ничем не управляете.
Чтобы наглядно убедиться, что софт-скилы для лидера — это база, а не дополнение, предлагаю погрузиться в мини-историю на основе реальных событий под названием «Soft Skills: Manager Mode». Вас ждут пять кейсов из моей практики, настоящих, жёстких, иногда неловких, в которых главный персонаж, вооружившись эмпатией и супергеройским замыслом, борется не против людей, но против проблем.
* В статье фигурирует персонаж по имени Вася. Мы заранее приносим извинения всем Васям, Василисам и Василиям. Мы их любим и ни в коем случае не хотим как-то обидеть. В статье мы не имеем в виду какого-то конкретного Васю. Все Васи прекрасны. Это красивое царское (!) имя носили великие люди – Суриков, Кандинский, Тропинин, Жуковский, Поленов и много других достойных представителей общества.
От хаоса в Markdown-файлах до стильного, быстрого сайта с поиском, темами и мультиязычностью за один вечер.
В жизни почти каждого IT-проекта наступает момент, когда количество файлов README.md, GUIDE.md, docs.txt и заметок в Confluence достигает критической массы. Документация становится фрагментированной, поиск нужной информации превращается в квест, а новые члены команды тратят часы на то, чтобы просто понять, "что где лежит".
Вы когда-нибудь хотели построить замок? Не знаю, как с замком, но я, как предприниматель, всегда хотел создать ров, который сможет защитить компанию от конкурентов. Ведь замок без рва и крепкой стены, это не твой замок.
С каждым годом создавать продукты становится все проще и проще. Иногда я узнаю о совершенно новой, революционной технологии или стартапе, но чуть стоит копнуть, как оказывается, что еще пять-шесть стартапов делают примерно то же. А в мире, где много компаний делает примерно одинаковый продукт, примерно одинакового качества, и всего несколько месяцев отделяет первопроходца от последователей, компании должны существовать на грани рентабельности, но это не всегда так. И возникает вопрос, что же отделяет победителей от проигравших.
Сегодня я попробую разобраться в этом на конкретных примерах технологических компаний и приемов, которые они используют. А именно в том, как создаются “рвы”, которые в мире называются устоявшимся термином moat.
Как устроена наша система на практике: от первого звонка и сметы до актов, допников и еженедельных отчётов. Подойдёт студиям, разработчикам и продактам
Как предпринимательница из небольшого городка в Ямало-Ненецком автономном округе шесть лет назад открыла школу программирования для детей, а сегодня вывела её на международный уровень и вошла в ТОП-3 выдающихся людей Ямала.
Проведя множество собеседований на позицию продакт-менеджера и ежедневно общаясь с большим количеством продактов, я понял, что у большинства моих коллег сейчас в голове полная каша и неразбериха. Со всех сторон сыплются новомодные словечки, пестрятся фреймворки, все используют agile и делат growth hacking, даже не понимая, что это такое, как это варить и есть ли это у них на самом деле.
В этой статье я попробовал проанализировать инструменты, которые используют продакт-менеджеры, разобрать, что они из себя представляют, а также ответить на ключевые вопросы: Что это? Для чего это нужно? Когда это применять?
Диаграмма потоков данных (DFD) — схема, которая показывает, где информация застревает, дублируется или исчезает в никуда. Со стороны такая схема может казаться архаикой — зачем рисовать стрелочки, если можно сразу писать код? Ответ прост: исправлять проблемы в уже написанном коде дороже, чем на этапе проектирования.
В статье собрали основу про DFD для тех, кто с ней не сталкивался: зачем ее используют и как изображают.
Давайте начистоту. Когда вы слышите «самоуправляемая команда» или «бирюзовая организация», что вы представляете?
Скорее всего, идиллическую картину: офис с пуфиками вместо стульев, где счастливые люди в тапочках пьют смузи, у них нет начальников, все друг друга любят, а прибыль растет сама собой, просто потому что все «в потоке», все в идиллии, решения принимаются в легкость и дружно, все друг друга любят, никаких споров, никаких конфликтов, никаких недопониманий.
А потом вы просыпаетесь. И видите, как в реальности попытка «внедрить бирюзу» превращается в ад: бесконечные совещания, где все имеют право голоса, но никто не берет на себя ответственность. Решения, которые должны приниматься за час, тонут в неделях согласований. А самые инициативные сотрудники либо выгорают, либо уходят, потому что устали от этого «конструктивного диалога».
Так что же такое самоуправление на самом деле? Реальный инструмент для роста бизнеса в сложном мире или просто красивая идеологическая обертка для хаоса, которую продают консультанты уставшим собственникам?
Давайте разбираться. Без булшита и розовых очков.
