Comments 8
UFO just landed and posted this here
Возникает вопрос, откуда она взялась и кто ее нанял.
Имхо, в данном случае главный вопрос не «кто виноват?» а «что делать?».
В больших проектах работают сильные и компетентные специалисты. И в этих проектах больше уже зависит от истории этого проекта, ограничений, договоренностей и обязательств ПМ и многого другого. Поэтому первая задача в подобных ситуациях обнаружить первопричины текущей ситуации на проекте.
Да, самое интересное, что необходимые действия могут и должны находится за рамками мышления проектной команды)
Например, есть проект состоящий из 8 специалистов. Каждый специалист имеет отличный практический опыт. Процессы налажены согласно последним трендам. Тимлид этой команды матерый технический разработчик с широким кругозором. Однако, объем поставляемых фич хотелось бы улучшить и опытный ПМ полагает, что это осуществимо. Прилагаемые им корректирующие действия не приносят ожидаемых результатов.
В чем на ваш взгляд может быть причина и как ее устранить?
Да, самое интересное, что необходимые действия могут и должны находится за рамками мышления проектной команды)
Например, есть проект состоящий из 8 специалистов. Каждый специалист имеет отличный практический опыт. Процессы налажены согласно последним трендам. Тимлид этой команды матерый технический разработчик с широким кругозором. Однако, объем поставляемых фич хотелось бы улучшить и опытный ПМ полагает, что это осуществимо. Прилагаемые им корректирующие действия не приносят ожидаемых результатов.
В чем на ваш взгляд может быть причина и как ее устранить?
Приятно видеть, что в век agile помнят про такую замечательную книгу. Вы правы про усиление в последние моменты. В статье идёт речь о том, что руководство таких проектов во время задумывается о расширении, то есть, когда дедлайн уже виден на горизонте и есть достаточно времени для корректировки, не смотря на чувство команды, что все пропало.
Задачи для новой команды должны быть подробно детализированы. К каждой из них можно приступить без ожидания — нет зависимости от текущих или будущих задач.
То есть для новой команды задач почти не будет.
Наша практика показала, что эффективным с точки зрения денег является первоначальное подключение небольшой команды. Таким образом, она погружается в контекст проекта, разрешая различные грабли, встретившиеся на своем пути и уже выходит на более крупные задачи. Затем более безболезненно происходят подключения оставшихся специалистов. Очевидно, что обратной стороной этого подхода будет более длительное по срокам расширение. В случае, если приоритетным являются именно выполнение взятых обязательств, нежели бюджет, второй вариант будет более правильным.
Количество выполняемых задач увеличилось в 1,9 раз.
КВЗ можно увеличить еще больше, если дробить входящие крупные задачи на более мелкие или, как сказно выше, игнорить серьезные большие задачи и клепать приятные мелкие…
Стоит учитывать, что на практике после дробления задач на мелкие и передачу их выполнения различным специалистам увеличатся накладные расходы на взаимодействие между собой разработчиков и другие активности. Конечно если мы не говорим про крупные фичи, например, от 1-3 человеко\месяцев, которые хорошо параллелятся между собой.
Согласно нашему опыту задачи лучше всего передавать в разработку в перемешку, если брать этот критерий. Это хорошо сказывается на балансе. Не всегда разработчик получает удовлетворение от совсем небольших простых задач, но и если постоянно решать только сложные (зубодробительные) задачи, то есть вероятность, что специалист перегорит.
Согласно нашему опыту задачи лучше всего передавать в разработку в перемешку, если брать этот критерий. Это хорошо сказывается на балансе. Не всегда разработчик получает удовлетворение от совсем небольших простых задач, но и если постоянно решать только сложные (зубодробительные) задачи, то есть вероятность, что специалист перегорит.
Sign up to leave a comment.
Ускоряем процесс разработки сложных проектов. Без хаоса и нервов