Head of development services, Senior Project Manager в KeyUA
  • To Be Agile Or Not To Be Agile?

    Софт без доки почти всегда несет какую-то ценность, а вот дока без софта — никогда.

    У меня к Вам вопрос: Вы когда-нибудь получали следующий этап инвестиций под проект без качественного дока? Фактически анриал? В случае с, например, gambeling apps, доки — это необходимость, за которой очень тщательно следят, чтобы получить лицензию под бизнес и обновить её без проблем. Ну это мы уже фактически уходим в сторону рисков программы, в которую входит этот проект.

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

  • To Be Agile Or Not To Be Agile?

    По поводу доков — я как раз в «недокоммуникации» писал зачем они нужны. Док — это качественный пруф, прикрывающий зад команды в критических ситуациях.

    P.S. Кстати я на одном из проектов (команда 4 человека + я парт-тайм) использую микс Prince2 (бюрократичный и ненавистный тем, кто не любит писать документацию) + Kanban, доки мне пишет PO и это required! Т.е. фактически PO сам нас подстраховывает, команда же пишет технический доки, касаемые проекта и я пишу общий док в конце итерации, описывающий то, что было сделано. Очень зачетненько работает.

  • To Be Agile Or Not To Be Agile?

    «Чувак, ты же сам такие приоритеты расставил, вот мы по ним и сделали, и ты получил и расписался.»

    Главное не нарваться на истерика, не понимающего что он делает)))
    Был у меня один проект года 2 назад, который был выполнен по спецификации 1 в 1. В результате перед официальным анонсированным ланчем, появляется список того, что было «mentioned before», но нигде не обсуждалось и не записывалось. Sign off проекта он не сделал, истерил почти неделю, в результате договорились за доп бюджет, т.к. и ему, и нам репутация важна.
    Потом узнали что было на самом деле. Проект был для правительственной организации и этот заказчик был посредником. Он контракт с нами и спецификацию подписал (фиксед прайс), а спецификацию его заказчик не подписывал и надавал кучу изменений (уже обсуждали о waterfall для крупных организаций), о которых нас никто не оповестил. В результате у нас была головомойка около недели с приходом домой в 11 вечера каждый день (само собой за хороший бонус), но все во время успели.

    Я это к тому, что не стоит упираться во что-то особенное и маркировать его как идеал и помнить, что заказчики бывают очень разными.

  • To Be Agile Or Not To Be Agile?

    1.

    Скажем так, если заказчик — большая неповоротливая корпоративная структура или бюджетная организация, то иначе, чем с waterfall, с ними просто нельзя.

    +100500

    2.

    если у заказчика восемь пятниц на неделю и он сам не знает, чего хочет, но готов за это платить

    + еще раз 100500, главное чтобы у него при этом бюджет был порезиновее, а то могут потом начаться истерики типа «Ребята я это хотел когда-то, а Вы не сделали, а для меня это очень важно» (ну не все понимают разницу между Agile, Waterfall и т.д. и всегда нужно быть готовым к тому, что надо ткнуть человека носом во все логи итераций, которые соответственно надо бережно хранить).

  • To Be Agile Or Not To Be Agile?

    Могу сказать следующее — если человек, будучи формальным/неформальным лидом проекта за пару лет не понимает, что Agile — это достаточно легкий, а также дырявенький фреймворк, и упорно доказывает, что только Agile и ничего кроме (кричит в рупор с заборов, набивает татуировки со словом Agile и т.д.:) ), то вышеруководящему начальству стоит задуматься о компетенции такого сотрудника. В strict-методологиях тоже есть свои плюшки, так чо принципиальная позиция по поводу того, что лучше, показывает лишь неопытность человека в подобных вопросах.

  • Некоторые правила улучшения временнóй оценки задачи

    Кстати, те, кто прочел PMBOK, знают что в ней по оценке материалов маловато. В основном «вода».

  • Некоторые правила улучшения временнóй оценки задачи

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

    Конечно, необходимо всегда советоваться с командой по эстимейтам.
    P.S. Все члены команды на проекте — это единый организм, который должен действовать очень слаженно. За такую самостоятельность, если она есть, нужно наказывать.

    P.P.S. Сейчас подтянется народ с ветки об agile и продолжат здесь срач расскажут о planning pocker.

    Підтримав: Олексій Мудрик
  • Некоторые правила улучшения временнóй оценки задачи

    В продактовых компаниях оценка времени очень важна. Это дает заранее понять какие фичи пойдут на живой в конце релиза и запланировать маркетинговую активность.

  • Некоторые правила улучшения временнóй оценки задачи

    А хороший менеджер от плохого как раз тем и отличается, что ведет риск лог, которым может удачно оперировать при планировании.
    30-40% — это то, что я получил за 6 лет опыта работы в должности ПМ, могу сказать, что эти цифры близки к идеальным.

  • To Be Agile Or Not To Be Agile?

    Я тоже такие команды знаю, но тем не менее не могу сказать что их процесс идеален для разработки.

  • To Be Agile Or Not To Be Agile?

    Это тот случай, когда у заказчика есть бюджет Х, который он использует чтобы построить то, что ему хочется в T&M стиле. Все классно до тех пор, пока бюджет на разработку исчерпывается, а к тому моменту кастомер имеет еще целую кучу идей и пытается втулить их в стиле «it was mentioned before» :)

  • Некоторые правила улучшения временнóй оценки задачи

    • Добавляйте к суммарным временным оценкам комплексных задач 20%-30% на риски. Это может быть риск того, что кто-то из исполнителей заболеет, или у него неожиданно (для вас) родится ребенок, или будет свадебное путешествие в Магадан. Так или иначе, что-то да обязательно сработает, особенно если сроки верхнеуровневых задач более двух недель.

    Ставлю всегда 30-40% к задачам, еще ни разу не прокалывался. Если остается время, мы всегда найдем куда его потратить на проекте.

    Вообще правильно эстимейтить используя PERT Formula (описание — www.pmhub.net/...-pert-formula/, пару раз пробовал, проколося на одной из задач с эстимейтом, так что тоже не всегда такой вариант «выстреливает».

  • To Be Agile Or Not To Be Agile?

    Сергей, Вам пора открывать свою контору с тренингами (как минимум продавать Вы их сможете) :)

    Но помните, на кроме Agile есть еще и другие формы жизни на проектах :))

  • To Be Agile Or Not To Be Agile?

    из 7 членов команды — 6 CSM

    Почему так мало? Надо хотя бы 7 CSM, все обязательно должны понимать почему именно выбран Scrum и свято верить в то, что это сделано правильно :)

  • To Be Agile Or Not To Be Agile?

    угу, а еще переписали PMBOK под Agile manifesto :))))))))))))))))))))))))))))))))))))

  • To Be Agile Or Not To Be Agile?

    Лучшее наказание в данном случае — это наказать заказчика через change request. А дальше уже все просто: хочешь — делаем, не хочешь — не делаем.
    ===

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

  • To Be Agile Or Not To Be Agile?

    Использовать agile manifesto в чистом виде в процессе — это все равно что пить чистый спирт :) Вы лично знаете тех, кто использует аджайл, но не имеет в процессе такой важной вещи как итерации?

  • To Be Agile Or Not To Be Agile?

    Самолеты уже пытались строить по agile, в результате сказали, что agile г***но. Но опять таки не стоит забывать, что есть проекты, на котором он применятеся «на ура», а есть такие, на которых о нем не стоит даже думать.

  • To Be Agile Or Not To Be Agile?

    :)

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

  • To Be Agile Or Not To Be Agile?

    Одна из «фишек» аджайла в том, что любая итерация может стать последней. На фиксед прайс аджайл используют для внутреннего удобства.

← Сtrl 123456 Ctrl →