Mainframe_старыйПавел, поясните, т.е. Вы создаете не проекты, а команду, которая создает проекты ? Т.е. Ваше главная забота (как лидера) - команда. А главная забота команды - проекты?
Формально, моя работа заключается в выполнении проектов. Наличие команды, которая способна выполнять проекты на сверхскорости, существенно облегчает мою работу в ее формальной формулировке. Такая команда не появляется из ниоткуда, ее нужно создавать, чем я и занимаюсь.

Вот так я выполняю свою работу.

Mainframe_старыйи еще один момент - Ваша цель - беспрецендентные результаты ? (достаточно часто повторяете, поэтому такое впечатление). Т.е. главное результат, который ранее никем не был достигнут? Это главный признак успешности руководителя проекта с вашей точки зрения?

Достижение таких результатов - это то, что отличает меня от других менеджеров. Я не стремлюсь, напримеру, к управлению гигантскими командами в 100+ человек, для меня, чем меньше, тем лучше. Главное - чтобы команда была гибкой и проворной. Тогда возможно все.

Кстати, я тут все рассказываю и рассказываю о себе. Но мне же интересно, с кем я общаюсь. Назовите плз, кто вы, что делали-делаете, какие ценности разделяете, как находите мотивацию для себя и для команды. Мне очень интересно

Mainframe_старыйТогда главным критерием беспрецендетности Вы считаете сверхскорость?
Это может быть все, что угодно. Это может быть выполнение работы, за которую никто не решался браться, это может быть достижение сверхскорости, это может быть проявление гибкости в работе с продуктом и/или заказчиком - то, что требуется в текущий момент. Главный критерий беспрецендентности - до меня так никто и никогда не делал

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

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

Попытаюсь помочь Вам. Ответ на вопрос "чем отличается команда Дрим-Тим от обычной команды" когда речь идет о классификации, звучит примерно так: "у членов команды Дрим-Тим зеленые глаза и они светятся, а у членов обычной команды - глаза серые и они тусклые". Хотелось бы услышать четкую классификацию - уверен, что она, если имеется, уложится в 4-6 пунктов.

Павел АфанасенкоДавайте, я и отвечу. Dream team - это команда, которая добивается сверхрезультатов по сравнению с обычными командами. Результаты могут быть какие угодно, но когда их видишь, то понимаешь, что обычная команда их достичь не могла. Я тут уже приводил пример такого результата в одном из предыдущих постах. Вот еще один: у моих заокеанских заказчиков была мечта - обновить платформу, на которой основана линейка продуктов. Они 7 (семь!) лет не могли найти команду, которая бы это сделала. Мы это сделали за год.
Пять баллов! Т.е. гордым именем "Дрим-Тим" награждается команда, выполнившая проект, а аутсайдеры - автоматически разжалуются в "обычные команды"

Еще раз отвечаю: dream team - это команда, которая добивается беспрецендентных результатов по сравнению с обычными командами. Это такие результаты, которых никто и никогда (в определенном контексте) не достигал. Примеры таких результатов я приводил ранее. В последнем примере речь шла о том, что никто не был готов взять на себя ответственность за выполнение этого проекта в течение семи лет. Мы взяли. И сделали.

iscrafm Павел АфанасенкоГлавный критерий беспрецендентности - до меня так никто и никогда не делал
тогда можете с чистой совестью успокоится. До Вас все это сделано-переделано. Или делайте ориентир на конкретный проект. Тогда можно конечно сказать, что до Вас его никто не делал или, что + в Вашу пользу, делал, но не смог.
Ну что я могу на это ответить? :)
Отвечу, пожалуй вот этой цитатой:
«Все, что можно изобрести, уже изобретено» (Чарльз Х. Дуэлл, уполномоченный Патентного бюро США, 1899).

Mainframe_старыйне знаю, что даст мое описание. Личная страница - http://www.vvsu.ru/teachers/show.asp?TID=1463. Информатизация университета. Руководитель отдела, по совместительству и рукводитель проектов и архитектор.
Ну почему же ничего не говорит. Я прекрасно помню, что когда я преподавал вот здесь в конце прошлого столетия, мне было очень интересно смотреть, как у Вас сделан курс по ООП.

Mainframe_старыйПо поводу убеждений. Что такое Agile только сейчас прочитала. Экстремальное программирование никогда не приветствовала для себя (и своего отдела). Выполнение сроков хорошая вещь, но не считала ее признаком успешного проекта (как и выполнение бюджета). Просто всегда ставлю такие сроки и такой бюджет, который реальный, а не желаемый. Если как сейчас у нас прроект внедрения в другмо вузе и мы ограничены в сроках - выкладываемся по полной.
К нам народ приезжает все время учиться. Они говорят, что то, что мы сделали - беспрецендетно (для вузов с точки зрения действующих проектов). Сама я так не считаю, не задумываюсь об этом. О своей роли иногда задумываюсь, уверена, что многое делаю не так. Возводить патетику о команде мечте - не хочется. В тоже время, кое что меня в Ваших постах интересует (не экстремальнео программирование). Что именно пока не поняла. Поэтому задаю вопросы.
Про Ваше отношение к Agile/XP понимаю - это обычная реакция на то, что ново и необычно. Собственно говоря, я ничего про Agile/XP в этом топике и не писал :) Только упоминал. Но тем не менее, с удовольствием отвечу на Ваши вопросы.

Обращаюсь ко всем участникам обсуждения. Господа, уже пора открывать свои лица :) А то как-то некрасиво получается. Напишите о себе

Сергей Васкецов Павел АфанасенкоЯ вообще ничего не писал про проектную документацию. Поясните, пожалуйста.
Поясняю. Формальное распределение ролей в проекте - часть проектной документации (в принципе, вся история жизни проекта суть проектная документация, потому что немаловажно не только ЧТО и КАК сделано, но и ПОЧЕМУ так сделано). Если что-то не формализовано, значит эта часть отсутствует. Пример. Если все знают, что надо обратиться к Васе, если возникает ошибка, то это плохо. Хорошо, когда все знают, что надо обратиться в службу поддержки, где работает Вася. А Вася может не только саппортить, но и админом быть, или заболеть, или умереть, или уволиться. Равно как и плохо, когда новый сотрудник приходит и не знает, к кому обратиться по какому-либо поводу. Тогда как формализация распределения ролей, в общем-то, дело несложное.
Павел АфанасенкоНу то, что руководители ответственные, это понятно. А остальные программисты и тестировщики? Они, что, бамбук курят?
Отнюдь. Просто всегда понятно, к кому обратиться, где задержка по срокам, кто в чем виноват или чей это успех. Равно как и не удастся сказать что-то типа "так и былО до меня".
Сергей я понимаю Вашу позицию и Ваше представление о том, как должна быть устроена разработка софта. Да, такой подход существуют, им пользуются и достигают результатов. Ообенно там, где разработка громадная, медленная, где изменения происходят небыстро. И всегда можно найти конкретного человека, который за отвечает за выделенную ему грядочку и указать на его косяк.

Я предпочитаю другой метод, когда скорость максимальна, изменения максимальны, ответственность за результат командная. И выигрыш от того, что есть команда, а не совокупность отдельных людей, существенный .

Сергей Васкецов[ Павел АфанасенкоЯ писал про то, что личностные качества формализовать трудно (я например не знаю как). Но зато если они есть, то проявляются очень ярко.
По-Вашему, если не проявляется "очень ярко", то этого нет?
Не знаю. Я писал не про видимость, а про сложность формализации личностных качеств.

Сергей Васкецов Павел АфанасенкоDream team - это команда, которая добивается сверхрезультатов по сравнению с обычными командами. Результаты могут быть какие угодно, но когда их видишь, то понимаешь, что обычная команда их достичь не могла.
Весьма субъективное определение. Кто должен это понимать? Сверхчеловек? На старте было 2 команды в равных условиях и одна "пришла к финишу первой"?
Все субъективно :) Не ждите от меня формализации.

Сергей Васкецов Павел АфанасенкоОни 7 (семь!) лет не могли найти команду, которая бы это сделала. Мы это сделали за год.
Мысли вслух:
1. Может быть вы просто сошлись в цене, что они не могли сделать 7 лет?
2. Если IT-проект не выполняется 7 лет, вряд ли он так уж сильно нужен.
3. За 7 лет в IT столько меняется, что многое просто в принципе невозможно было сделать за разумные деньги независимо от команды.
В любом случае, обсуждение вопросов типа "как выиграть тендер" или "как заполучить заказ" мне неинтересно, тем более в рамках данного топика.
Хотите обесценить? :) Я не дам Вам такой возможности.
Важность того проекта никуда не девалась за 7 лет. Просто продукты линейки старели и не собирали тех денег, которые могли бы собрать. И в какой-то момент вопрос о замены платформы встал ребром, потому что поддерживать старую становилось все дороже и дороже. Мы этот проект сделали. По оценкам продуктоводов компании, замена платформы позволила увеличить жизненный цикл линейки продуктов на несколько лет. Все продукты линейки собирают по $20-25М в год. Выгоды от реализации этого проекта можете посчитать сами.

Да, заказчик внутренний, так что это не про тендер и не про заказ. А про то, чтобы сделать то, что никто до этого не решался сделать

Mainframe_старыйXP уже нельзя назвать новым и необычным. Я даже затрудняюсь назвать век, когда впервые прочитала о нем. ЧТо же до создание команды .. тут меня действительно гложат некоторые противоречия, потому что я сосредоточена на создании проекта. Вы как, мне показалось, хотите сказать, что главное создать команду, которая уже создаст проект. Подход к руководству ориентированный на людей, а не на проекты, как я понимаю .. Мне нравится (как руководителя проекта) именно архитектура, интеграция и т.п.... а вот другая часть - психологическая обработка команды - нет..(хотя конечно без этого не обойтись, но это второстепенно). Пока не пойму, стоит ли думать в эту сторону.
Я хочу сказать, что в проекте, на мой взгляд, нужно самое большое внимание обращать на людей, которые рядом, а не на архитектуру, интеграцию и т.п. Потому что архитектуру, интеграцию и т.п. создают люди, а не биороботы.

психологическая обработка команды - это конечно сильно :) Я ж не зомби воспитываю :) Я помогаю людям стать больше, чем они были до сих пор

nibbles Павел АфанасенкоОбращаюсь ко всем участникам обсуждения. Господа, уже пора открывать свои лица :) А то как-то некрасиво получается. Напишите о себе
Вы себя неуютно чувствуете из-за этого?
Да нет, мне как раз нормально.
В создании успешных команд есть несколько принципов. Два из них - это открытость и отдавание. Что я сейчас и демонстрирую. Но это должно быть обоюдным. Только в этом случае возможен рост. Если этого происходить не будет, то мне скоро станет неинтересно, и я больше не буду сюда писать. Кто от этого выиграет?