Здравствуйте, Vzhyk, Вы писали:
V>genre пишет: V>Вот именно. И здесь мы можем предполагать все что угодно. Лично я видел V>много и того и другого и наличие вполне объективных и разумных причин и V>банальную глупость с ленью.
Основной мой concern в той ситуации был даже не в том, что решения/процессы, принятые в проекте, были неэффективны, а в том, что обсуждать, как их улучшить, не получалось — люди, отвечающие за решения не обладали достаточной технической компетенцией. В итоге более/менее высокоуровевые проектные решения оказывались результатами интриг, а не здравого смысла.
>> >> D>улучшить >> а кто сказал, что это плохо? возможно процессы выполняют свою задачу и >> не требуют вмешательства V>Да. Известная поговорка "лучшее — враг хорошего".
Задача здесь понять самое больное место в проекте и пытаться улучшать его, не хватаясь за все сразу.
>> >> D>(внедрить новый вид тестирования, >> см. выше. нужно ли оно? откуда у только пришедшего человека знание, что >> здесь это будет эффективно?
Знание взялось из предыдущего опыта и из понимания проблем проекта. Если участник проекта шел на обсуждение моей точки зрения, обычно удавалось показать, что то, что я предлагаю, будет эффективно. Часто в процессе обсуждений выплывали факты, которые я не учитывал, тогда предложения корректировались.
Ненормально — когда все говорят, что надо что-то делать, а конкретные предложения игнорируются, действий не происходит.
>> >> D>сделать и задокументировать нормальный дизайн в подсистеме, >> D>переписать другую подсистему так, чтобы она работала, и т.д.) >> ага. за аргументацию "все взять и переписать" вообще линейкой по пальцам.
Для каждой подсистемы рассматривались варианты "затычки" дырок, рефакторинга и переписывания с нуля. Для некоторых выходило, что переписать с нуля — выгодней (если конечно мы хотим видеть эти подсистемы более-менее работающими рано или поздно).
Честно говоря, мне больше совсем не хочеться обсуждать здесь дальше свою личную ситуацию из прошлого, потому что не хочу распространяться дальше, что у нас конкретно было и как.
>компания будет как в басне, где все тянут воз в разные стороны
При хорошей настройке процесса в плане областей ответственности и интересов строгой вертикали власти может не быть вообще.
Тот же MSF построен именно на взаимодействии равных (в определённых пределах)
Здравствуйте, VGn, Вы писали:
>>компания будет как в басне, где все тянут воз в разные стороны VGn>При хорошей настройке процесса в плане областей ответственности и интересов строгой вертикали власти может не быть вообще.
In theory theory and practice are the same. In practice they are not.
VGn>Тот же MSF построен именно на взаимодействии равных (в определённых пределах)
Поподробнее пожалуста. Любая компания построена по принципам взаимодействия равных в "определенных" пределах.
senglory пишет: > >> > V>профессиональные в первую очередь, материальные во >> > V>вторую >> > >> > Я не ослышался? Последовательность именно такая??? > V>Да. > > Жены нет рядом с детьми?
Есть.
TT>In theory theory and practice are the same. In practice they are not.
Процессы вообще к теории мало относятся. Имхо империческая шняга.
TT>Поподробнее пожалуста. Любая компания построена по принципам взаимодействия равных в "определенных" пределах.
Так называемая матричная схема.
Здравствуйте, VGn, Вы писали:
TT>>In theory theory and practice are the same. In practice they are not. VGn>Процессы вообще к теории мало относятся. Имхо империческая шняга.
Построение хороших, сбалансированных процессов это штуковина в теории выполнимая и в теории призванная достичь целей компании. На практике — как повезет. Лично был свидетелем когда построение процессов стало самоцелью а цели бизнеса отошли на 3-й план. (На второй план поставили качество продукта)
TT>>Поподробнее пожалуста. Любая компания построена по принципам взаимодействия равных в "определенных" пределах. VGn>Так называемая матричная схема.
К счастью не работал в компании с матричным менеджмнетом. Но ситуация в которой на каждый ресурс (инженер) может иметь несколько менеджеров одновременно просто обязана продить интриги ибо все менеджеры становятся взяимо-зависимы и взяимо-исключаемы (дать 5 программистов манагеру Васе значит дать всего 1-го программиста манагеру Коле). А соответственно без единой головы и с таким количеством проектов как в МС — врятли эти манагеры сами договорятся.
ЗЫ: Интересно было бы услышать как на самом деле обстоят дела в матричных компаниях в среде манагеров.
