Пользователь пока ничего не рассказал о себе

Достижения

Все достижения (6)

Наибольший вклад в теги

Все теги (24)

Лучшие ответы пользователя

Все ответы (24)
  • Объясните цикл разработки веб-фронтенда?

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

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

    Если просто то так.
    Ответ написан
  • Какой материал выбрать для изучения основ управления проектами?

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

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

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

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

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

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

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

    Дальше только опыт.
    Вы сами поймете какие колонки вам нужны, какие нет, что в карточках не хватает в описании, а что лишнее, сколько планировать и как, и так далее
    Ответ написан
  • Где найти бесплатные PSD для обучения верстке?

    dyfran
    @dyfran
    Как вариант подписаться на рассылку HTML Academy, они хорошие макеты присылают
    Ответ написан
  • Где почитать про Управление IT проектов?

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

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

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

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

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

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


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

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

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

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

Лучшие вопросы пользователя

Все вопросы (36)