Сергей Васкецов Павел АфанасенкоОобенно там, где разработка громадная, медленная, где изменения происходят небыстро.
Опять же не понятно, откуда информация про "скорость изменений"? Я где-то писал, сколько максимально версий одного и того же ПО может так разрабатываться? Что мешает иметь как минимум current/release/stable и при необходимости выполнять изменения не только в current? Впрочем, логика версионной разработки лежит немного в другой плоскости, нежели измерение гениталий.

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

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

Про гениталии не понял.

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

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

Вобщем-то анонимность анонимности рознь ... вот например анонимность мсье Gaperton на форуме RSDN даже интриговала, хотя он назвал организацию в которой работает :-) ... Но в любом случае для меня лично анонимность является критерием того, что человек явно чего-то боится (Gaperton, к вам это не относится :-)). Толи того, что начальник увидит кол-во сообщений и спросит потом о том как рабочее время тратится :-), толи просто неуверенность человека в собственных знаниях -- и отсюда скрытость, чтобы если вдруг чего не в попад сказал, чтобы стыдно не было :-). И анонимность позволяет быть БЕЗОТВЕТСТВЕННЫМ за свои высказывания ... а следовательно ценность их (за редким исключением) подвергается сомнению.
Глупость не перестает быть глупостью... кто бы ее не изрекал.

Несомненно. Сравните нашу дискуссию вот с этим обсуждением . Почему же такое различие? А потому что люди не скрываются за безличными никами и понимают, что если они будут нести чушь, это скажется на их репутации в важной для них референтной группе людей. Потому что людям важно создать в дискуссии нечто ценное. чем они потом будут пользоваться в своей жизни. Именно поэтому участники вкладываются в дискуссию, потому что они получают от дискуссии гораздо больше, чем привносят. Но это возможно только в том случае, когда вклад осуществляют все

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

Вы считаете главным в нашей индустрии архитектуру, технологии, интеграцию, процесс, управление качеством, а я считаю главным - людей, которые все это создают. Это не значит, что я отрицаю важность архитектуры, технологий, интеграции, процесса, управления качеством. Мало того, у меня в жизни был период когда я сам тоже так считал. С тех пор я вырос. И такие вещи, как архитектура, технологии, интеграция, процесс, управление качеством перешли в разряд "must have". Теперь для меня это как умение писать "Hello, world". А самым важным я считаю людей.

И вам желаю поскорее перейти на новый уровень!

iscrafm Павел АфанасенкоЯ хочу сказать, что в проекте, на мой взгляд, нужно самое большое внимание обращать на людей, которые рядом, а не на архитектуру, интеграцию и т.п.

хорошо слаженный, "спитый" коллектив, практически друзья, выдающий на гора вещи сомнительного качества... мда. Вершина проектного менеджмента.
Главное в нашей отрасли - архитектура, технологии, интеграция, процесс, управление качеством... как бонус - неплохая команда.
В принципе я уже упоминал зачем нужны подобные PM-уловки. Есть категории людей которые легко поддаются влиянию слова, и можно несколько ослабить влияние денег. Сам не применяю подобное, но видел много живых примеров.
Уважаемый, Вы же признались в начале топика в том, что не работаете руководителем проекта :) Как же Вы тогда можете судить о том, что является вершиной проектного менеджмента, а что нет? Предлагаю Вам сначала поработать руководителем. Хотя бы немного.

Практика отличается от теории наличием опыта.

Сергей Васкецов Павел АфанасенкоНапример, в тех ситуациях, когда цена ошибки очень высока, этот метод позволяет сделать сверхнадежные системы. Например, если бы мне пришлось софт для бортовой ЭВМ космического корабля, я бы документировал каждый чих. Но только делать приходится что-то попроще и задача обеспечения сверхнадежности не стоит. Поэтому можно ускоряться, что я и делаю.
Вы упоминаете о своем "суперпроекте", в рамках которого "ускорялись", но при этом пишете, что требования "обеспечения сверхнадежности" не было. Я правильно понимаю, что ускорение было достигнуто в том числе за счет того, что многие ценные знания не были документированы и остались в головах сотрудников? А как же тот факт, что человек "внезапно смертен"?
Уровень документированности проекта зависит от многих факторов, в частности от корпоративной культуры, сложности проекта. Agile не отрицает наличие документации, только мы работу над документами не выделяем среди всех работ. Для нас документация - это такой же артефакт, как и рабочий код. Если заказчик требует, мы делаем, если не требует, то не делаем.

Просто мы в Agile умеем работать и без документации. Она нам не нужна

Сергей Васкецов Павел АфанасенкоА самым важным я считаю людей
Пример. В Вашем проекте в качестве, например, архитектора (или любого другого существенного персонажа), участвует женщина. Она забеременела и собирается рожать, соответственно, уйти в декрет, причем, годика этак на 2-3, а не на месяц. Ваши действия как руководителя проекта?
В Agile есть практики, которые позволяют осуществить распространение знаний о проекте среди всех его участников. Таким образом, мы застрахованы от выпадения отдельного человека из процесса. Кроме того, этими же практиками мы нивелируем такую штуку, как критический путь. У нас он просто отсутствует.

iscrafm Павел АфанасенкоУважаемый, Вы же признались в начале топика в том, что не работаете руководителем проекта :) Как же Вы тогда можете судить о том, что является вершиной проектного менеджмента, а что нет? Предлагаю Вам сначала поработать руководителем. Хотя бы немного.
Практика отличается от теории наличием опыта.
Павел, я действительно не работаю руководителем проекта, у меня несколько другая "должность". Назовите это CEO, владелец... как угодно. Мне больше нравится конструктор, ближе как-то. Но поруководил достаточно, и маленькими и огромными. Или Вы думаете я Вам вопросы с потолка задаю? Видел и то, что Вы проповедуете. Кстати не нужно переводить на меряния, лучше на вопросы отвечайте, Вы же грозились в начале дискуссии.
Вот так, не мытьем, так катаньем, люди начинают открываться. Задавайте вопросы, уважаемый конструктор, я отвечу.

AlexTheRaven...
К вопросу о том, почему все рвутся в ПМы: кроме всего прочего, у ПМов, по крайней мере присутствующих на этом форуме, огромное количество свободного времени. Больше 100 Кб текста на 6 листах форума за 3 рабочих дня! Причём добрую половину написал Павел Афанасенко, одновременно готовясь к семинару. Не подумайте, Павел, я не критикую, просто факт констатирую.
Мое участие в топике есть часть подготовки к семинару. Таким образом я проверяю воспринимаемость аудиторией моих тезисов. Свободное время приходится занимать у сна. Ничего, на пенсии отосплюсь :)

AlexTheRavenЧто до вторичности документации и первичности людей - недавно увидел негативный пример. Работали люди по SCRUM (разновидности выше упомянутой наживульки, если кто не знает). В некоторый момент на них, мимо отсутствующих согласно методологии ПМа и аналитиков, навалили столько требований и запросов на изменение, что проектировать, документировать и вникать во что-либо, что не относится непосредственно к выполняемым задачам, стало некогда. Потом один за другим, не выдержав такого напора, ушли: ведущий разработчик сервера обработки (извините за тавтологию), бывший ПМ, по совместительству ведущий "базданщик" , и ведущий разработчик GUI.
И всё. Разработка встала, оставшиеся занимаются обратным проектированием, исследуют, учатся, приходят к просветлению :) . Ушедших зовут обратно почти на любые деньги, но они не идут. А команда была всего-то 10 человек, и проект - всего-то на год.
Вообще-то Agile подразумевает постоянство скорости разработки. От команды нельзя требовать большего, чем она потенциально может сделать. Иначе случается то, что случилось с вашей знакомой командой - команда ломается.

Очень многие команды декларируют, что они работают по Agile, но когда смотришь, как у них устроен процесс, то выясняется, что от Agile там только одно название. Мы называем такой процесс "типа Agile" или "Agile "на коленках" . Приведу одну цитату из статьи по ссылке:

Вот и получаются такие Agile проекты, которые я про себя зову Agile "на коленках". Из основных принципов в них воплощен в лучшем случае второй (сборки). Вторичных признаков (тестов, скрамов) тоже может не быть. Зато присутствует много "НЕ", якобы диктуемых методологией Agile: мы НЕ пишем требования, тест-кейсы и любую другу документацию, мы НЕ планируем проект, мы НЕ отслеживаем никаких метрик, мы НЕ можем ничего оценить заранее, и т.д. По количеству частиц "не" в ответах на наводящие вопросы можно определить maturity level.

iscrafm Павел АфанасенкоВот так, не мытьем, так катаньем, люди начинают открываться. Задавайте вопросы, уважаемый конструктор, я отвечу.
начнем с того, что я и не прятался :)
вопросы закончились. Меня сейчас больше интересует технологичность и рентабельность процесса, игры в зарницу - пройденный этап, возвращаться нет никакого желания. Спасибо.
Удачи!