Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×
Head of development services, Senior Project Manager в KeyUA
  • To Be Agile Or Not To Be Agile?

    Тогда если можно, дайте формулы по которым Вы оцениваете риски для проекта/итерации/задачи? Не проще ли пользоваться готовыми решениями того же pmbok или prince2?

  • To Be Agile Or Not To Be Agile?

    Ну так при грамотном применении правил Вы и с Waterfall покорите мир :)

  • To Be Agile Or Not To Be Agile?

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

  • To Be Agile Or Not To Be Agile?

    «ватерфол гауно»

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

  • To Be Agile Or Not To Be Agile?

    Кстати, по поводу Agile... Сравните Agile, который пропогандирует популярный Scrum Alliance и Agile под эгидой PMI и увидите, как говорят в Одессе, 2 большие разницы. PMI-евский Agile больше защищает Agile команду и за основу берет многое из PMBOK, что, откровенно говоря, приятно удивило.

  • To Be Agile Or Not To Be Agile?

    Как fixed-price, так и agile-проекты имеют право на жизнь.
    Качественно управляйте проектом, умейте доказать правоту ссылаясь на документацию, change requests и ситуаций

    После очередной волны оплат за изменения клиент потерял веру, что когда либо увидит рабочий продукт, и пересмотрел свои приоритеты в финансировании.

    не возникнет.
    В каждой методологии есть свои плюсы и минусы. Тот же agile не покрывает качественно управление бюджетами, тайм менеджмент или управление рисками. Те же «толстые методологии» не дают гибкости, удобной командам разработчиков без ПМ (вариант с наймом команд под заказчика).

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

  • Asp.Net Mvc обиженная команда из Cikluma (для HRов)

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

    б) наталкивают на логичный вопрос о уровне своей компетентности

    Підтримали: Anatoliy Sova, Andrusenko Dmytro
  • «Недокоммуникация» как один из признаков украинского аутсорсинга

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

    CMMI — это не только модель, но еще и признак зрелости компании, что является преимуществом при участие в тендере на проект. Я это к тому, что проект — это не только его разработка, но и множество другой операционной деятельности связанной с ним.

  • «Недокоммуникация» как один из признаков украинского аутсорсинга

    Недельные итерации оптимальны в двух случаях:
    — в случае если проект зашел в кризисную фазу (пролет по срокам, например)
    — на начальной фазе, если проект переводится с другой методологии управления (например с waterfall) с целью показать заказчику выгоду в увеличении контроля над деливери.
    В любом случае, недельные итерации достаточно некомфортны и не являются полноценными — нет фазы нормальной стабилизации и времени для ретроспективы.

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

    Підтримав: anonymous
  • «Недокоммуникация» как один из признаков украинского аутсорсинга

    Евгений, маленькие проекты тоже нуждаются в документах. Процедурные доки, спецификации, планы итераций, тест кейсы, запросы на изменения, риск логи и т.д. — это все то, что плотно защищает команду. Элементарное увольнение сотрудника не должно превращаться в длительный хендовер и бессоные ночи для нового человека в команде (другой вопрос, что не каждый прочтет эти доки досконально).
    Опять таки, есть понятие получения инвестиций под проект (многие задумывались о том, что за те продукты, которые мы разрабатываем, клиент должен платить деньги и брать их откуда-то?). На этапах получения новых инвестиций проект обычно проходит экспертизу через технических и нетехнических консультантов и, как я уже писал ранее, отсутствие документации посчитают «минусом».
    В проекте с 10 человеками все проще — есть ПМ или ТЛ, который может взять эту часть работы команды на себя. В маленьких проектах не всегда есть фуллтаймовый менеджер, поэтому эта функция должна ложиться на плечи разработчиков.

    Підтримав: Jack Spektor
  • Снова о менеджерах

    1. Клиенты, бывают истеричными, которым еще надо объяснить и дать нужных пруфсов, увы, без этого никуда :(

    2. Да, не подвиг, а работа, я вроде о подвигах и не писал нигде.

  • Снова о менеджерах

    В настройках уведомлений:)))

  • Снова о менеджерах

    Откуда Вы знаете о стабильности API или политике крупных компаний, с которыми Вы делаете интеграции? Facebook, в свое время, «убил» возможность добавлять приложения себе во вкладки, поставив крест на бизнесе тысяч компаний. Вы знаете хоть одного менеджера, который предсказал этот риск и описал решение, если он превратится в проблему? Я лично не знаю.

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

    Підтримав: Вадим Издебский
  • Снова о менеджерах

    Ну конечно С++ разработчикам виднее, я в этом, почему-то, даже не сомневался. Но есть такие ситуации, где можно только предусмотреть, а предотвратить никак нельзя, т.к. на некоторые риски повлиять невозможно (это из риск-менеджмента — Вы о таком слыхали?). Так вот, в таких ситуациях (когда начинается «кипяток» с разборками) менеджеру лучше взять «огонь» на себя и дать команде продолжить спокойно работать. Я всегда привожу самый обычный пример — Вы интегрируете свою систему с внешними API, Вы всегда уверены в их стабильности? Так вот с т.з. заказчика это будет выглядеть как именно Ваш факап и время на пруфсы прийдется потратить иногда немало, пока не докажешь обратное.

    Підтримав: Вадим Издебский
  • Снова о менеджерах

    Грамотный менеджер всегда в состоянии прикрать и с вои факапы, и факапы программиста. Глупый будет искать виноватых.

  • Снова о менеджерах

    Грамотный менеджер всегда сможет прикрыть и свои факапы и факапы программиста, глупый будет искать виноватых ;)

  • Москва is a lost city, и что это значит для других городов

    Сейчас многие мидлы переходят на ЗП сениоров. Это финансово удобно для них, но обосновано ли для компаний? По поводу 2к — согласен, народ побежит (лично знаю даже пример, где взяли джуниора на такую ЗП — madness!), но готовы ли компании с грамотным менеджментом, зашедшие в Украину для использования украинских ресурсов в своем долгосрочном бизнесе, пойти на такие затраты? ЗП могут рости до тех пор, пока хозяева будут иметь профит, ведь стоимость затрат никак не влияет на стоимость услуги. Сейлсы все равно не смогут продать услугу дороже, чем она стоит. Рост среднего уровня ЗП на рынке может привести разве что к уходу средних игроков с рынка и поиска ресурсов в более дешевых местах.

  • Москва is a lost city, и что это значит для других городов

    а) Реальная нехватка даже мидлов. Не даром сейчас все топовые компании открывают учебные центры и набирают туда студентов.
    г) Фотки того, что выше Комсомольской стоит выложить, чтобы видели реальный город.
    д) Купид — это проект с британскими инвестициями, которому уже лет 5-6.

  • Снова о менеджерах

    Уважаемый Леонид,

    1. Менеджер нужен для организации ЭФФЕКТИВНОЙ работы проектной команды.
    2. Харизматичные менеджеры ищут интересные и большие проекты. Управление процессами — это работа програм менеджера, который уже прошел через все ступени ПМа и набил себе целую кучу шишек.

    3. Касаемо работы на себя — иногда стоит отказаться от чего-то, включая финансовые прелести, чтобы достугнуть большего с т.з. профессионализма.

    С ув.

    Андрей

    Підтримали: satellite, Commandor
  • Снова о менеджерах

    И все чтоли?

← Сtrl 123456 Ctrl →