Анти-советы для команды: как найти себя?

Всем привет!
Давненько не виделись и вот сегодня есть время немного пообщаться о методологиях разработки, кто они вообще такие есть…
Многие, прочитав предыдущий абзац, могут сказать, что все это глупость, есть только одна рабочая методология (!), которую они (а может быть и вы) применяете на практике. Однако спешу вас обрадовать.
Мы абстрагируемся от той или иной методологии, потому как есть несколько нюансов.



Итак… Какова цель любого проекта? Получить готовый продукт (решение), успешно осуществлять его продажи, выполнить контракт. Для того, чтобы это работало — нужна хорошая и квалифицированная команда.
Кроме того, очень немаловажный, чуть ли не самый главный, фактор — коммуникации в команде. Коммуникации в команде важны, потому что каждый участник команды должен чувствовать себя неотъемлемой частью команды, а команда в целом должна быть ориентирована на успех проекта. Но это все вода ;)

Итак, коммуникации, взаимодействие, knowledge transfer, ориентация на результат. Это является мета-целью любой методологии. Есть много противоречий у разных сторонников, например распределение по ролям (RUP), или многозадачность (XP)… В конечном итоге все сводится к повышению качества и увеличению производительности.
А это означает, что у всех методологий есть общий знаменатель, который позволяет говорить о чем то более общим, чем конкретизация.
Сразу оговорюсь, что я — сторонних eXtreme Programming, однако здесь специально не буду рассматривать преимущества или недостатки XP. Об этом были посты (http://netcoder.ru/blog/xp/60.html и http://netcoder.ru/blog/xp/27.html).

Здесь мы поговорим о том, что какая бы методология не применялась — конечная цель всегда одна.
Все методологии описывают набор взаимодействия ресурсов на проекте. Под ресурсами будем понимать время, а также участников команды. Как показывает опыт (в том числе и отрицательный), есть масса примеров удачного и неудачного использования методологий.
Например, команда, работающая по Agile с менеджером-теоретиком, который всегда старался делать все по книжке, не уложилась в срок и бюджет лишь из-за того, что он не смог дать адекватные оценки… Другой пример показывает, как некоторые команды пытались внедрить SCRUM, но в итоге все пошло совсем не так.

Проблема в этих примерах всегда одна. «Когда ты приложил лестницу, чтобы залезть наверх — подумай, у правильной ли стенки она поставлена?».
Управляя автомобилем, водитель редко (в идеале никогда) задумывается о том, как устроена система управления клапанами и зачем ей нужно регулировать высоту подъема каждого клапана, а также на каком такте хода двигателя какой клапан располагается на нужной высоте (но это меня что-то на лирику потянуло..)
Каждый менеджер/участник команды, применяющий методологию, не должен задумываться о теоретической составляющей этого. Методология — лишь инструмент, позволяющий осуществлять:
* тайм-менеджмент
* внутренние коммуникации
* оперативный контроль
* и тп.

В идеале, вы никогда не должны задумываться, КАК?
Вы вообще не должны задумываться :)

Удачное проектное решение — это успешное применение той или иной методологии для достижения оптимальных результатов в команде. В современном мире все применяемые решения смахивают на гибриды, потому что удачная практика рекомендует брать инструмент из XP и применять его в SCRUM, пользоваться шаблонами документов из RUP, использовать MS Project для учета и распределения времени…

Но все это полная фигня, которой забивают голову те, кому больше нечем заняться ;)
Я рекомендую несколько простых шагов для того, чтобы определить, как нужно строить управление проектом и работу команды (это касается каждого внутри команды), достаточно ответить на несколько вопросов:
1. Понимание — Что нам нужно делать? Зачем нам это нужно делать? Почему нам нужно делать это сейчас?
2. Концентрация — Как нам делать это? Какова последовательность действий? Какие действия нужно выполнить для конкретной цели?
3. Оценка — Сколько времени уйдет на это действие? Почему это действие должно быть раньше чем другое? Сколько времени уйдет у другого участника команды на то же действие и почему?
4. Результат — Что мы хотим получить? Что будет, когда мы это получим? Что мы будем делать дальше?

Возможно перечень вопросов неполный, однако это хороший старт. Особенно для тех, кто пока незнаком с некоторыми словами из моей статьи.
Итак, когда мы выбрали направление, разработали план, нужно незамедлительно приступать к реализации данного плана — обсуждать план после его принятия — означает создавать другой план. Разработайте план так, чтобы никогда (или по минимуму) его не корректировать.

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

Ну вот и все на сегодня. И помните: «Нет такого знания, которое не было бы силой» © Mortal Kombat The Game.
  • +8
  • 29 апреля 2010, 19:36
  • NetCoder

Комментарии (14)

RSS свернуть / развернуть
+
0
Что-то в этом есть, но вряд ли такой подход подойдет для команды более 3-5 человек.
avatar

robertino

  • 30 апреля 2010, 08:02
+
0
что ж. возможно…
от себя скажу: техника успешно применялась на команде в 6 человек.
однако никто не гарантирует что конкретная методология может быть успешна на конкретном проекте. все познается в сравнении.
avatar

NetCoder

  • 30 апреля 2010, 08:42
+
0
Уважаемый Netcoder!
Вы пишете слишком поверхностные рекомендации, вышеприведенный материал итак очевиден и интуитивно применяется большинством более-менее устоявшихся команд! Рекомендую Вам писать более конкретные обзоры :)
avatar

drugndrop

  • 4 мая 2010, 21:13
+
0
спаибо за критику. постараюсь учесть в будущих постах на тему тайм менеджмента…
хотя я стараюсь подчеркнуть здесь то что интуитивно применяется — для новичков может быть совсем не ясно, а следовательно требует разъяснений… стараюсь разжевать и разлоижть по пополчкам материал, который может быть описан в толстых книжках, чтобы народу можно \было сэкономить время. но спасибо за замечания, это очень полезно для меня и я постараюсь учесть в будущем
avatar

NetCoder

  • 4 мая 2010, 21:16
+
0
Велкам, как говорится ;)
avatar

drugndrop

  • 4 мая 2010, 21:16
+
0
А мне и нашей команде, а также нашему менеджеру Володе материал был довольно полезен и поучителен. Он даже после этого обещал зарегаттся на этом сайте ;)
avatar

AlexVoronin

  • 4 мая 2010, 21:18
+
0
ахаха!
не знал что у нас есть олд-скул поклонники ))))
avatar

NetCoder

  • 4 мая 2010, 21:19
+
0
сам ты пердун старый олдфаг;)
avatar

webdesigner

  • 4 мая 2010, 21:20
+
0
школота на ресурсе детектед…
avatar

NetCoder

  • 4 мая 2010, 21:21
+
0
)))))
avatar

AlexVoronin

  • 4 мая 2010, 21:24
+
0
БУГАГА
avatar

AlexVoronin

  • 4 мая 2010, 21:24
+
0
Мотивирует работать!
avatar

Botan

  • 4 мая 2010, 21:23
+
0
+100500
avatar

CrystalMan

  • 4 мая 2010, 21:35
+
0
хм… оказывается иногда полезно перечитывать то, что сам когда то написал ))))
avatar

NetCoder

  • 21 сентября 2011, 00:01

Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.