Ответы пользователя по тегу Управление проектами
  • Как лучше организовать рабочий процесс в Jira Atlassian, Agile?

    dyfran
    @dyfran
    Вопрос конечно пальцем в небо, но расскажу как у нас

    У нас один проект на все направления.
    Есть минусы, воркфлоу получается жирный, так как охватывает всех и мне как РП мобилок зачастую нужны не все статусы и согласования. Но главный плюс в том, что если один воркфлоу, то можно и единые выгрузки делать по жире по проектам, иначе сравнивать задачи/деньги/сдвиги по срокам/инциденты в разных проектах с разным воркфлоу будет вообще нереально. Это то, что никогда не поймут разрабы, им подавай простые и прозрачные воркфлоу со статусами, так как 95% разрабов не понимают что происходит за границами их системы, но кричат конечно об обратном :) и на вопрос как считать глобальную доработку на 7 систем разводят руками. У нас из-за специфики это один из самых важных критериев, если вам не нужно, то лучше конечно отдельные проекты, но разбивать мобилы и веб в любом случае маразм, всем и так очевидно, что одна фича, это одна доработка на бэке и три на фронтах (веб и мобилы).

    У нас доски скрамбаны, формируем спринты по скраму, работает по канбану, с кучей мелких доработок для удобства - отображаем статус связанной QA задачи, отображаем оценку и оставшиеся время и тд

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

    У нас идет:
    1. Заявка на доработку ПО - где указывается аллокация, цели, бабло и тд
    2а. Далее Доработка системы - где бьем системы Процессинг, АБС, ДБО (мобилы и веб вместе)
    2б. Контроль качества - тут создаются задачи на тестирование и все баги
    3. Технические таски в каждой доработке системы.

    Тут главный критерий делать как удобнее и быстрее (с поправкой на хотелки начальства), а не как "правильнее". Наш пример только выглядит сложным, на деле это самая простая структура, которая выстроилась за несколько лет на глобальный проект в 450 человек.

    Эпики как хочешь так и именуй, правило тоже самое (удобно/быстро/понятно). Хочешь по фичам, хочешь по релизам, хочешь по план сметам, хочешь по фазам луны.

    Добавить задачу в эпик не проблема, добавить баг тоже. Мы для удобства баги добавляем с таким же эпиком ****_fix, т.е. эпик сам release_1, баги в release_1_fix. В задаче эпик будет только release_1, в баге будет два эпика release_1 и release_1_fix.
    Ответ написан
  • Мотивация программистов на удаленке. Что делать?

    dyfran
    @dyfran
    Назначить самого сильного и адекватного миддла экспертом группы, снизить нагрузку бизнесовыми задачами, взамен накинуть управленческой административки.

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

    В любом случае оценка будет и он с ней согласится. Далее ты по этим оценкам планируешь. Сдвиги и риски будут, но не такие как сейчас в 2 раза, а если же и будут, то встает вопрос о качестве работы этого сотрудника и дальнейшего сотрудничества с ним.
    Ответ написан
  • Где вести вики по проекту?

    dyfran
    @dyfran
    confl + jira
    Ответ написан
    Комментировать
  • Может ли middle разработчик быть тимлидом?

    dyfran
    @dyfran
    Лид команды в первую очередь хороший управленец, а не самый сильный коддер в команде, но конечно он как минимум должен уметь провести ревью и знать проект. Я не верю, что PM может быть лидом команды разработки.

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

    Лид же зачастую к коду почти не притрагивается. Либо критичные, либо мелкие правки + ревью. Даёт экспертные оценки на задачи (сам или с командой) и отвечает за качество попадания в эту оценку.
    Хороший лид в команде это когда отдел одинаково хорошо работает и с ним и без него в случае его отсутствия. Когда любые проблемы от покупки железок, конференций и повышений, до проблем с заказчиком, аналитиком и его ТЗ, сроками и так далее, решаются без дальнейшей эскалации.

    На моём опыте редкий senior в команде не имел чсв до небес и хоть какие-то более менее развитые коммуникативные навыки вместе с эмпатией и нормальной рефлексией, поэтому моё мнение, что только middle и может быть хорошим лидом
    Ответ написан
    2 комментария
  • Какой материал выбрать для изучения основ управления проектами?

    dyfran
    @dyfran
    Абстрактный вопрос, абстрактный ответ.

    Проблема в управлении или недостатке технических знаний?

    Если первое то всё просто.
    Все вместе регаетесь и создаете доску в trello, вам подойдет бесплатная версия с лихвой.

    Начинайте с 4 колонок - общая свалка задач (бэклог), запланировано(plan), в работе(progress), завершено(done). Потом по необходимости добавите другие колонки (анализ - ba, sa; тестирование - qa и какие в голову взбредет).

    Формируете бэклог/скоуп/свалку текущих задач, которые надо сделать, оцениваете их верхнеуровнего по времени (часы или дни) и делаете горизонт планирования неделя/две.

    По приоритетам (Критично/высокий/средний/низкий) вкидываете задачи с доски бэклога в план, назначая исполнителей и начинаете работать.
    Если задача по оценке больше одной/двух недель, дробите на более мелкие, чтобы попасть в ваш горизонт планирования (считай спринт).

    Дальше каждое утро 15 минутный статус, кто что сегодня делает с доски и какие проблемы.
    Задача закрыть весь ваш 1-2 недельный спринт со списком задач, который вы сформировали, если не закрыли, анализ причин и способы их исправления.

    Дальше только опыт.
    Вы сами поймете какие колонки вам нужны, какие нет, что в карточках не хватает в описании, а что лишнее, сколько планировать и как, и так далее
    Ответ написан
    Комментировать
  • Какие книги по Product Management порекомендуете?

    dyfran
    @dyfran
    Сломался гугл? Вопрос задан ну просто миллион раз.
    И да, читать про product management, тоже самое что читать про как водить автомобиль. Пока не сядешь и не поедешь, не поймешь
    Ответ написан
    Комментировать
  • Какие Вы используете решения по ведению документов (контрактов/договоров)?

    dyfran
    @dyfran
    Conf + Jira\trello ?
    Ответ написан
    Комментировать
  • С чего начать путь product owner'а?

    dyfran
    @dyfran
    Продакт растет из РП (pm), если вы не были рп, то перепрыгнуть сразу будет трудно. У них похожие роли, но кардинально разные функции.

    Как стать РП

    1. Технические компетенции, понимать инструменты разрабов, элементарные навыки работы с БД и опыт коддинга.
    2. Одна книжка по scrum и agile, глянуть по диагонали PMbok и читать ветку управления проектами на хабре.
    3. Элементарная психология, рефлексия, эмпатия, коммуникации.

    Это всё.

    Дальше только опыт.
    Подробнее отвечал тут Где почитать про Управление IT проектов?
    Ответ написан
    Комментировать
  • Какие курсы по управлению проектами пройти?

    dyfran
    @dyfran
    Технические компетенции у вас уже есть.

    Одна книжка по scrum и agile, глянуть по диагонали PMbok и читать ветку управления проектами на хабре.
    Затем элементарная психология, рефлексия, эмпатия, коммуникации.

    Это всё.

    Дальше только опыт.
    Подробнее отвечал тут Где почитать про Управление IT проектов?
    Ответ написан
    Комментировать
  • Как оценивать сроки?

    dyfran
    @dyfran
    Это боль, я лишь расскажу как делаем мы.

    1. Максимальная декомпозиция задач (кэп)
    2. Оцениваем фичи всем скоупом сравнивая между собой в размерах одежды (можно смеяться) S, M, L, XL, XXL
    3. После начала работ и примерного понимания скорости команды, а так же опыта аналогичных фич с одинаковой размерностью (сколько было потрачено времени на все предыдущие фичи L), получаем примерную, пальцем в небо оценку.

    Благо мой заказчик не идиот и понимает, что оценки на фичи с реализацией 160h+ становятся не актуальны через 2 дня работы, поэтому скрепя сердцем довольствуется такой примерной оценкой, и да, я также как и вы считаю, что мы не мосты и здания строим, наша задача не скрупулезное планирование, а качественный, эффективный и конкурентоспособный продукт.
    Ответ написан
    Комментировать
  • Как вы разделяете задачи фронта и бэка на проекте?

    dyfran
    @dyfran
    И, вдобавок, часто фронт включается, когда бэк сделал 60-80% своей работы.

    wtf?

    Вы реализуете конкретные фичи. Мне как заказчику было бы глубоко насрать, что фронты все сделали и молодцы, а бэки нет и фича по итогу не работает, де факто, простите, все мудаки)

    Нужен верхнеуровневый таск "фича такая-то", которая уже бьется на технические таски (BA, SA, Dev, QA) и только потом, когда все куски сделаны и протестированы (отдельно и вместе) - релизиться. Заодно в рамках одной задачи можно настроить элементарный sla в отчетах (у нас jira) и понимать где у вас в процессе узкие места, где боль, а где и почему задачи зависают в рамках конкретных фич и дальше от этого уже плясать. Может поменять рабочий воркфлоу, что-то убрать, что-то добавить, увеличить ресурсов бэков и так далее.

    У нас давно тоже был реализован такой подход и тоже бэки шли с отставанием, и бывали случаи когда фронт релизил часть не работающего функционала на бой в ожидании бэка, а бэков дёргали на более приоритетные проекты, потом опять, потом опять и по итогу фича становилась не актуальной и на неё забивали, а на бою плодились куски кода и формы (если знать как на них попасть), которые никому не нужны и не работают.
    Ответ написан
    Комментировать
  • Как правильно выставлять версии в тикетах в Jira?

    dyfran
    @dyfran
    Мы называем эпики по версии релиза и в задаче сразу видно в какой релиз она вошла.

    Отвечая на "Как вообще правильно должен выглядеть подобный процесс?".
    Как вам удобнее и как вы хотите чтоб он выглядел, так и делаете)
    Ответ написан
    Комментировать
  • Объясните цикл разработки веб-фронтенда?

    dyfran
    @dyfran
    Идея - Бизнес требования - далее параллельно пилится системный анализ и макеты - далее разбивается на две команды бэк и фронт - зачастую отдельно бэк протестить нельзя, тестируется при готовом фронте и заводят баги на каждое направление - исправления - ретест - релиз - профит

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

    Если просто то так.
    Ответ написан
    2 комментария
  • Где почитать про Управление IT проектов?

    dyfran
    @dyfran
    Не помню в какой книге прочел исследование, если найду то потом прикреплю, так вот там был доказанный рост скилла работника в отношении 100% и делился он так:

    10% Книги, статьи
    20% Общение с коллегами, форумы и прочее, перенятие опыта
    70% Опыт решения сложных задач.

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

    Я сам читал книжки, весь маст хэв для pm и мифический месяц, коты, dedline, все эти истории про управление качеством и прочее. Купил потом еще порядка 10 книг, прочел 3 и взял новый проект, в котором за 4 месяца апнулся как от 100 книжек.

    Поэтому как говорит мой начальник, который пришел из ВТБ, главное это:
    1. Совать свой нос везде куда можно и нельзя, искать узкие места рабочего воркфлоу и бизнес-процессов и исправлять их
    2. Общаться, много и со всеми. Не на тему хз чего, а конкретных болей конкретного человека и думать как их исправить
    3. Не тонуть в менеджерской рутине, которой всегда очень много на проектах. Выделять дни, записывать досконально что ты делаешь в течении дня и анализировать какие действия повторяются опять же в течении дня/недели и как этого избежать.
    4. Ну и самое главное, всегда думать как встать над процессом, а не тонуть в нём.

    Сказка про четыре типа менеджеров.
    Есть лодка, в ней дырка с полметра и лодка тонет.
    Дебил и ужасный менеджер разводит руками.
    Плохой менеджер начинает вычерпывать воду чайной ложкой.
    Нормальный менеджер думает как заменить ложку на ведро.
    Хороший менеджер думает как залатать дыру.


    Ну и болеть душой за проект. Программисты ваши друзья. Не подчиненные и не обычный ресурс.
    Хороший pm это всегда адвокат разработки, а не её прокурор)
    Ответ написан
    1 комментарий
  • Можно ли в Jira сделать поле "Автор последнего комментария в задаче" для сортировки?

    dyfran
    @dyfran
    Не совсем понимаю в чем проблема.
    Упорядочить список задач? Можно просто смотреть по последним обновлениям, это проще.
    Или понять в каких отделах подвисают задачи? Тогда сделать элементарный SLA на ответ, условно 1-2 дня и если обсуждение встало на Васе Пупкине и стоит неделю, карать)
    Ответ написан
  • Какие есть сложности в работе с Jira?

    dyfran
    @dyfran
    Не поддерживается трёхуровневая вложенность задач, только плагины или костыли.
    Я pm в банке и у нас своя история с согласованием заявок на доработку, бюджеты и прочие истории. То есть сделать историю где сначала пилятся бизнес требования, потом внутри пилится системный анализ и потом внутри уже идёт конкретная декомпозиция на технические задачи, мы не смогли. Сделали двойную вложенность и третью, где технические задачи, подзадачами (sub-task), но тут же столкнулись с другой проблемой, сабтаски не видны на досках и спринты по ним не сформировать, типа сами авторы жиры против этого.

    Это конкретно боли и особенности моего направления, а таких у нас в банке 11 и у каждого свои процессы и воркфлоу и особых проблем с ней больше не было. Это очень универсальный продукт в котором можно сделать всё что хочешь, зависит только от рук админов.
    Ответ написан
    Комментировать
  • Как правильно организовать планирование в игровой Компании PMO (project manager), методом Gantt и Milestones?

    dyfran
    @dyfran
    График gantt? Любой обязан знать, что такое диаграммы Ганта, тем более в разработке и управлении проектами.

    "Очень интересно как решить такую задачу" это мягкая формулировка, решите пожалуйста за меня? Проблема в чем?

    Задача тривиальная. Типичная работа пм'а. Тостер для помощи и решения возникших проблем в процессе решения задач, а не для их полного решения. Для решения есть специальные ресурсы на которых вам с радостью помогут за деньги.
    Ответ написан
    2 комментария
  • Как управлять мобильной разработкой?

    dyfran
    @dyfran
    команды не кроссфункциональна
    И это нормально, и даже хорошо. У нас в компании точно так же есть разделение back, front и мобильщики по 2-4 человека на ios и андроид.

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

    Не понял насчет на одного программиста приходится один менеджер. Имеется ввиду проектная группа? Когда у тебя своя команда?

    Наши мобильщики работают по scrum. Сначала собираются требования стейкхолдера, потом пм или аналитика (если сложная доработка) пишут тз на оценку, по этому ориентировочному тз мобильщики дают оценку, я накидываю время сверху на всякие неувязочки и выкатываю заказчику стоимость, если он согласен, то задача двигается либо в аналитику для полного тз, либо попадает в бэклог, если "тз на оценку" достаточно для работы. Ну а дальше как везде, митинг, по приоритетам формируется спринт, задача в него попадает или нет(так как крупных клиентов 30+), делается. Если задача сложная, уходит тестерам. Если простенькая, собирается тестовая сборка на тот же uber, которую тыкает саппорт (что-то элементарное типа передвинуть/убрать блок и/или тд), и если всё ок, даётся доступ клиенту, который тоже подтверждает что всё ок и тогда сборка выкладывается в стор или маркет. Если просто, то как-то так.
    Ответ написан
    2 комментария
  • Как сделать чтобы настраиваемое поле отображало данные работало сквозь несколько задач?

    dyfran
    @dyfran
    Не совсем понял вопроса. Зачем всё это? Для чего? Чтобы видеть процесс работы над большой задачей с закрытием более мелких? Если да, то чем эпики не подходят?
    Ответ написан
    Комментировать