[Видео] «Пиэмы не нужны» и ещё три идеи по управлению проектами


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


    Со всей страны собрались любители внедрить эджайл, а за ним канбан; они на кухнях обычно делятся сакральным знаньем по вечерам. Вы догадались уже, наверное, к чему до ката весь этот текст. В Яндекс.Деньгах провели «Пиэмную», где не осталось свободных мест.


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


    Продакт vs проджект: как мы подружили интересы бизнеса и разработки (Дмитрий Волков, Яндекс.Деньги)


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



    OKR & Scrum. Взболтать, но не смешивать (Наталья Антипова, Wrike)


    Я не раз видела, как в компаниях принимают решение внедрить популярный Scrum, считая, что найдена «серебряная пуля» для достижения успеха. В реальности в компаниях с крупной разработкой на длинной дистанции Scrum недостаточно. Команды бегут в разные стороны, и результат перестает удовлетворять бизнес. Я расскажу, как в Wrike, оставаясь гибкими к изменениям, мы используем инструмент стратегического планирования OKR (Objective and Key Results) в сочетании с тактическим фреймворком Scrum, и какие произошли изменения.



    Канбан-метод и управление проектами в команде на 30 человек (Игорь Филипьев, ScrumTrek)


    В докладе я расскажу об опыте применения Канбан-метода в команде разработки сервиса онлайн-кредитования. Как мы управляли потоком работы, договаривались с бизнесом о квартальных целях и по ходу меняли планы. С какими проблемами масштабирования при переходе от Scrum к Канбану столкнулись и как их решали. Также я расскажу о точках контакта и трении между звеньями в цепочке создания конечного продукта и поделюсь выученными уроками. Доклад будет интересен в первую очередь руководителям проектов со стороны IT и менеджерам продуктов со стороны бизнеса.



    Почему современной разработке не нужны ПМы (Дмитрий Круглов, Arrival)


    ПМы пали жертвой развития процессов разработки и вышли из моды? Современные опытные команды одна за одной отказываются от этой должности? Product Owner-ы стали современными ПМами? Так ли это и что делать всем, кто связал свою карьеру с этой профессией?




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

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Нужны ли пиэмы разработке?

    • +16
    • 8,7k
    • 4
    Яндекс.Деньги
    172,00
    Как мы делаем Деньги
    Поддержать автора
    Поделиться публикацией

    Комментарии 4

      +2
      Как я понял, взяли PM-а, разобрали на роли и раздали эти роли разработчикам, мол, вы умные сами самоорганизуйтесь. Плюс ещё из разных моделей управления терминологию взяли. В итоге получились team-lead, tech-lead, product owner, product manager, project manager, scrum master, архитектор и др.
      Пару лет назад я писал в резюме, что team-lead, думая, что это переводится как «ведущий разработчик», который раздаёт задачи, мерджит пул-реквесты, учит уму-разуму джунов, ресёрчит как прикрутить очередную либу и решает архитектурные задачи. Но теперь я уже ни в чём не уверен и корректирую резюме в соответствии с терминологией в вакансии.
      Есть чувство, что через несколько лет индустрия вспомнит, что занимается development'ом и придумает должность прораба/бригадира.
        +1

        Все развивается по спирали, поэтому сейчас нужно убрать ПМов, чтобы потом придумать программистов-бригадиров). Хорошо придумано!

        0
        Было бы смешно, если бы не было так грустно.
          0
          Автор прав в том, что роль PM можно разложить на некий набор и раздать его другим участникам команды, так же роли участников команды в некоторых случаях можно делегировать PM, это удобно, так как достигается некий уровень устойчивости команды к потерям людей. Да, в случаях, когда бизнес готов нести риски и потери за неправильные решения или их величина мала роль можно убрать. Точно так же можно убрать роль руководителя разработки в маленьком проекте, потому что он маленький. Автор не заметил, но все озвученные примеры мест, в которых PM был нужен, они про наличие ответственности. В случаях, когда продукт влияет на работоспособность больших систем, на жизнь и здоровье людей вот тут появляется PM.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое