Washington Post рекомендует

[t.t]

Шаблонно мыслите, ув. YUKLA. (; Среди тех 10-15 компаний, о которых речь выше, чуть более половины западных. Перечень из нескольких конкретных примеров направляю Вам в личку.

На рынке программного аутсорса в СНГ "чисто национальных" компаний, почитай, что и нету. А те, что есть уже обзавелись офисами в Европе или в США. Но это ничего не меняет. Ровным счетом.
Даже если мы ведем речь о крупной западной компании с офисом разработчиков в России/Украине/Белоруссии - все равно на местах рулит "русский" менеджмент. А то и хуже - "русскоязычный" менеджмент, из эмигрантов. Которые при приеме на работу указали в резюме хорошее владение русским языком. При приеме на работу "там".

Я, конечно, понимаю, что Вам хочется подвести базу под свою теорию "во всём виноваты русские", но -- опять мимо. Могли бы и догадаться, т.к. у двух из названных мною компаний нет представительств в эсэнговьи, а у двух других российские и украинские представительства не занимаются разработкой. Речь была об офисах в Евросоюзе, Великобритании и Штатах. И проблема эта -- не проблема "бизнеса по-русски": это свойственно почти любому бизнесу, в той или иной мере.

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

Ещё мне вот что интересно, если позволите.. Называли себя "выросшим из программиста", а рассуждаете действительно как чистый теоретик; прямо сферические кони в вакууме какие-то.. Позвольте полюбопытствовать: Вы в разработке (именно разработке, а не управении) крупных проектов участвовали? Хотя бы в качестве рядового разработчика? Крупных не в смысле строк кода, а в смысле количества установок (для энд-юзерских) или часов наработки на отказ комплекса хотя бы из пары десятков машин (для корпоративных)?

[diesel]

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

Вы полагаете - в разработке софта нету конвейера? И нету даже распараллеливания, разборки на простые кубики с последующей финальной сборкой?

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

В случае применения того же набора абстракций к программированию, вы фактически выдаете время на "ты сядешь, подумаешь, придумаешь хорошее решение, и закодируешь его, хорошее решение должно прийти к тебе до среды, 13 марта, 12-ти часов 45-ти минут дня, потому что на 12.50 у нас совещание с другими девелоперскими группами". В указанные сроки можно сгенерировать решение задачи "в лоб", поскольку "не осенило", поставив себе на полях пометку "надо бы сделать правильно, но не сейчас". Но появляются новые задачи, и приходится дальше генерировать решения "в лоб". Пожалуйте быдлокод сошел со стапелей, в свободное плавание.

"Чистое" разделение труда к конвейеру никакого отношения не имеет, конвейер - это как раз таки когда все вместе.

[sash-kan]

Почитайте вот, про бот-нет на gninx. Статья свежайшая, не 2002 года.

учитывая, что именно ваш покорный слуга постил эту новость на этот форум, можно сделать вывод, что он про неё уже слышал.
ещё есть что почитать, про оставшиеся «50% ботнетов минус 1 ботнет»?
или вас в дальнейшем можно именовать «господин соврамши»? на основании сказанного вами, но так и не подтверждённого:

Да будет вам известно - примерно 50% ботнетов составляют Linux и BSD сервера с необновленными ядрами.

p.s. предлагаю мировую: признайтесь, что просто «завернули ради красного словца», да на том и покончим.

[Ali1]

//offtop

конвейер предусматривает выполнение одной и той же работы, физически одной и той же работы над каждым выпускаемым продуктом. в этом случае применение указанных вами "общих принципов управления всем" дает результаты которым можно верить.

Вы видимо никогда не видели, как на сборочном конвейере завода ЗИЛ забивают болты.
Даже рассмотрение такого "простого" случая управления производством. Демонстрирует, что теоретическое бизнеспроцессирование, не отягощенное знанием реального разброса диаметров отверстий, порождает неадекватную модель. При более детальном рассмотрении "возмущающих факторов" выясняется:

• Необходимо глубокое, практическое знание предметной области
• Решение неустойчиво
• Решение может лежать вне зоны вашей компетенции или ответственности

О кибернетике как лженауке
Кибернетика в СССР. История одной лженауки
///endofftop

[YUKLA]

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

Системный архитектор задает общую (или частную, в зависимости от позиции) архитектуру решения. Вот - почитайте о нем в квалификационных требованиях (профессиональном стандарте) МинСвязи:

Профессиональный стандарт по профессии «Системный архитектор»
Направление деятельности работников: Разработка архитектуры, требований и спецификаций на уровне отдельных компонент или небольших приложений; ответственность в пределах рабочего задания; требуется сотрудничество с другими работниками; возложена определенная ответственность и автономность в принятии решений
Требования к практическому опыту работы: 2 года от 2 квалификационного уровня профессии «Программист»

Вы полагаете - людей с таким опытом "не хватает как воздух"?

Ну а ваши "безработные управленцы" - кто они? Найдите их, пожалуйста, в означенном стандарте. Кого вы имеете в виду? Руководитель проекта не должен "оценивать красоту кода" - ему вообще говоря, кода лучше не видеть вовсе. И даже, вовсе не требуется его понимать.

ЗЫ: Сдаётся мне - в дискуссии не поучаствовало ни одного профессионального программиста и ни одного (это 100%) профессионального руководителя проектов. Вы, дамы и господа, порой, говорите такие вещи, что диву даешься. Одного взгляда достаточно, чтобы понять, что от сферы коммерческого программирования вы, гм, далеки. Не возможно не знать, что такое CMMI , Scrum или "Водопадная модель", к примеру - и работать в IT-аутсорсе...

Без обид и ничего личного.

[YUKLA]

Да будет вам известно - примерно 50% ботнетов составляют Linux и BSD сервера с необновленными ядрами.

p.s. предлагаю мировую: признайтесь, что просто «завернули ради красного словца», да на том и покончим.

Сейчас документально подтвердить, увы, не могу. Но. оставляю за собой право напомнить вам об этом, если таковые публикации появятся.

[vinny]

ЗЫ: Сдаётся мне - в дискуссии не поучаствовало ни одного профессионального программиста и ни одного (это 100%) профессионального руководителя проектов.

конечно. совершенно не пононятно, что вы... такой умный и несомненно талантливый упрвавленец, делаете на форуме, в компании дворников?

[YUKLA]

конечно. совершенно не пононятно, что вы... такой умный и несомненно талантливый упрвавленец, делаете на форуме, в компании дворников?

Я никого не хотел обидеть. И не собираюсь заниматься самоутверждением. Делать мне нечего.

Просто если вопрос поднимается, и начинает обсуждаться, то нужно СНАЧАЛА договориться о терминах. К тому же, простите великодушно, но я никому не давал еще ЛИЧНЫХ оценок.

[t.t]

ЗЫ: Сдаётся мне - в дискуссии не поучаствовало ни одного профессионального программиста и ни одного (это 100%) профессионального руководителя проектов.

Когда кажется, креститься надо, профессиональный Вы наш. Мне достоверно известно, что в дискуссии участвовало как минимум пять профессиональных программистов и как минимум три опытных руководителя проектов. Это только те, о ком мне это достоверно известно.

В частности, прошу ответить на мои последние вопросы, либо продемонстрировать, в чём именно они некомпетентны.

конечно. совершенно не пононятно, что вы... такой умный и несомненно талантливый упрвавленец, делаете на форуме, в компании дворников?

Я никого не хотел обидеть. И не собираюсь заниматься самоутверждением. Делать мне нечего.

Просто если вопрос поднимается, и начинает обсуждаться, то нужно СНАЧАЛА договориться о терминах. К тому же, простите великодушно, но я никому не давал еще ЛИЧНЫХ оценок.

Вы не раз давали оценки _всем сразу_. Это похлеще личных оценок.

Да будет вам известно - примерно 50% ботнетов составляют Linux и BSD сервера с необновленными ядрами.

p.s. предлагаю мировую: признайтесь, что просто «завернули ради красного словца», да на том и покончим.

Сейчас документально подтвердить, увы, не могу. Но. оставляю за собой право напомнить вам об этом, если таковые публикации появятся.

Т.е. до тех пор Вы согласны, чтобы Вас тут считали вралём?

[vinny]

конечно. совершенно не пононятно, что вы... такой умный и несомненно талантливый упрвавленец, делаете на форуме, в компании дворников?

Я никого не хотел обидеть. И не собираюсь заниматься самоутверждением. Делать мне нечего.

Просто если вопрос поднимается, и начинает обсуждаться, то нужно СНАЧАЛА договориться о терминах. К тому же, простите великодушно, но я никому не давал еще ЛИЧНЫХ оценок.

слушайте... вот мой опыт управления: 20 лет по трудовой книжке и 38 по жизни, подсказывает мне, что программерами руководить невозможно. в принципе. лучше даже не пытаться, целее будете (:
upd если вы не звезда на данном небосклоне...

[vinny]

Т.е. до тех пор Вы согласны, чтобы Вас тут считали вралём?

думаю, что нам докажут, что в рунете всего два ботнета. тогда высказывание по 50% "зомбисетей состоящих из линуксовых серверов" может оставаться в силе.

[YUKLA]

Ещё мне вот что интересно, если позволите.. Называли себя "выросшим из программиста", а рассуждаете действительно как чистый теоретик; прямо сферические кони в вакууме какие-то.. Позвольте полюбопытствовать: Вы в разработке (именно разработке, а не управении) крупных проектов участвовали? Хотя бы в качестве рядового разработчика? Крупных не в смысле строк кода, а в смысле количества установок (для энд-юзерских) или часов наработки на отказ комплекса хотя бы из пары десятков машин (для корпоративных)?

Да. Участвовал, и как ведущий исполнитель и как руководитель проекта. Проекты для госструктур. По ГОСТам. 1500+ установок. Достаточно? Вы ведь читали мою страничку - там все написано.

Что касается офисов в "Европах и Штатах" - то, простите великодушно, но я позволю себе усомниться в том, что вы или ваши друзья ДЕЙСТВИТЕЛЬНО смогли до конца разобраться в бизнес-процессах, который там происходят. Без обид и ничего личного. Как минимум, уровень допуска должен быть весьма и весьма приличный. Думаю - где-то порядка главы представительства Microsoft в СНГ, не меньше. Это я в качестве примера.

А бардак в "отдельно взятом проекте", да еще, судя по всем, исполняемом совместно с теми или иными аутсорсерами в СНГ - это явление рядовое и говорит более о личности менеджера проекта. Или о его (проекта) приоритете.

ЗЫ: Еще раз повторяю. Есть некоторые реперы - стандартные термины, знание которых определяет принадлежность того или иного человека к той или иной профессиональной группе. Менеджер программного проекта не может не знать, что такое PMBOK/PMI, PRINCE2 или Microsoft Solutions Framework. Программист - что такое MCAD/MCSD.
ЗЗЫ: Я не навязывал данную дискуссию. И готов выйти из нее с огромной радостью.

[YUKLA]

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

В случае применения того же набора абстракций к программированию, вы фактически выдаете время на "ты сядешь, подумаешь, придумаешь хорошее решение, и закодируешь его, хорошее решение должно прийти к тебе до среды, 13 марта, 12-ти часов 45-ти минут дня, потому что на 12.50 у нас совещание с другими девелоперскими группами". В указанные сроки можно сгенерировать решение задачи "в лоб", поскольку "не осенило", поставив себе на полях пометку "надо бы сделать правильно, но не сейчас". Но появляются новые задачи, и приходится дальше генерировать решения "в лоб". Пожалуйте быдлокод сошел со стапелей, в свободное плавание.

"Чистое" разделение труда к конвейеру никакого отношения не имеет, конвейер - это как раз таки когда все вместе.

Конвейер предусматривает разделение работы на последовательные этапы, каждый из которых не может начаться раньше предыдущего. Смотрим:

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

Видите - нет ни слова про обязательное принятие решения до 12:50 13 марта. Это - вопросы, решаемые на этапе проектирования. И определяются майлстонами, которые расставляет руководитель проекта, а далее - в частных задачах - тим-лидеры, руководители групп и так далее.
Майлстоны, разумеется, могут не выполняться в срок. О чем упомянутый вами Фредерик П.Брукс очень подробно и пишет. Реакция на это событие тоже описана, и заключается в тех или иных приемах, которые зачастую ведут или к удлинению времени исполнения задачи, или к урезанию функционала/качества результата.

Однако. Бывают и проекты, которые спроектированы ОПТИМАЛЬНО. И в этом случае времени хватает.

Более того - "водопадная модель" не является единственной. И не является самой оптимальной. Под каждый конкретный проект выбирается та модель его разработки и управления, которая даст наибольший выигрыш в ДАННОМ конкретном случае.

[t.t]

Ещё мне вот что интересно, если позволите.. Называли себя "выросшим из программиста", а рассуждаете действительно как чистый теоретик; прямо сферические кони в вакууме какие-то.. Позвольте полюбопытствовать: Вы в разработке (именно разработке, а не управении) крупных проектов участвовали? Хотя бы в качестве рядового разработчика? Крупных не в смысле строк кода, а в смысле количества установок (для энд-юзерских) или часов наработки на отказ комплекса хотя бы из пары десятков машин (для корпоративных)?

Да. Участвовал, и как ведущий исполнитель и как руководитель проекта. Проекты для госструктур. По ГОСТам. 1500+ установок. Достаточно? Вы ведь читали мою страничку - там все написано.

Признаться, не помню, читал ли.. Но тогда мне тем более странно, что Ваши рассуждения настолько оторваны от земли.

Что касается офисов в "Европах и Штатах" - то, простите великодушно, но я позволю себе усомниться в том, что вы или ваши друзья ДЕЙСТВИТЕЛЬНО смогли до конца разобраться в бизнес-процессах, который там происходят. Без обид и ничего личного. Как минимум, уровень допуска должен быть весьма и весьма приличный. Думаю - где-то порядка главы представительства Microsoft в СНГ, не меньше. Это я в качестве примера.

А бардак в "отдельно взятом проекте", да еще, судя по всем, исполняемом совместно с теми или иными аутсорсерами в СНГ - это явление рядовое и говорит более о личности менеджера проекта. Или о его (проекта) приоритете.

Ваши "судя по всему" мне откровенно надоели. Люди, по мнениям которых я составил своё обобщение, -- штатные сотрудники (в разное время разработчики, ведущие разработчики и руководители проектов) в упомянутых офисах. И участвовали далеко не в одном "отдельно взятом проекте" в этом офисе. Что касается "разобраться в бизнес процессах"... Это лишь ещё раз показывает Ваше непонимание сути проблемы: Вы считаете бизнес-процессы важнее реальных людей, на которых эти процессы держатся. Типичная ошибка "менеджера-теоретика".

ЗЫ: Еще раз повторяю. Есть некоторые реперы - стандартные термины, знание которых определяет принадлежность того или иного человека к той или иной профессиональной группе. Менеджер программного проекта не может не знать, что такое PMBOK/PMI, PRINCE2 или Microsoft Solutions Framework. Программист - что такое MCAD/MCSD.
ЗЗЫ: Я не навязывал данную дискуссию. И готов выйти из нее с огромной радостью.

Что за ахинею Вы несёте? Или Вы не понимаете, что в мире существуют программные проекты, никак не связанные с microsoft? Зачем руководителям или разработчикам таких проектов "знать, что такое MSF, MCAD/MCSD"?

P.S. Не хотел я "меряться статусом", но Вы, судя по всему, из тех людей, что и общаются со статусом, а не с человеком... Мой опыт разработки -- более 15 лет. Из них опыт работы в крупных коммерческих проектах -- почти 6 лет. Из этих шести лет более двух лет в качестве архитектора проектов, три -- руководителя направлеиня и руководителя проектов; параллельно продолжая заниматься разработкой (разработчик / ведущий разработчик) и проектированием. И про сертификаты мне не надо рассказывать: я сам писал сертификационные курсы, преподавал по ним и принимал сертификационные экзамены в общей сложности в течении почти трёх лет.

[YUKLA]

Что за ахинею Вы несёте? Или Вы не понимаете, что в мире существуют программные проекты, никак не связанные с microsoft? Зачем руководителям или разработчикам таких проектов "знать, что такое MSF, MCAD/MCSD"?

Послушайте, уважаемый t.t!
Во-первых, следите, пожалуйста, за языком.
Во-вторых. В приведённом мною списке терминов нет и половины, "завязанных на Microsoft".
В третьих. Microsoft Solutions Framework это методология разработки программного обеспечения. Универсальная. Ага. И не привязанная НИ К ОДНОМУ продукту M$.
И последнее.

Что касается "разобраться в бизнес процессах"... Это лишь ещё раз показывает Ваше непонимание сути проблемы: Вы считаете бизнес-процессы важнее реальных людей, на которых эти процессы держатся. Типичная ошибка "менеджера-теоретика".

Данная цитата говорит о том, что вы совершенно не понимаете суть понятия "бизнес-процесс". Ибо - бизнес-процесс есть отвязанное от исполнителя стандартное, формализованное действие. Бизнес-процессы "держаться" на людях на нулевом уровне "зрелости" процессов на предприятии. Когда никакая методология и не нужна. Во всех остальных случаях они отвязаны от конкретного исполнителя. Есть "собственник" бизнес-процесса. Но это - не конкретный человек, а "позиция". Т.е. - должность.

На этой ноте позвольте мне выйти из дискуссии в виду ее полнейшей бесперспективности. Ибо объяснять азы управления мне надоело. Удачи.

[vinny]

На этой ноте позвольте мне выйти из дискуссии в виду ее полнейшей бесперспективности. Удачи.

ну, вот... заставили человека сомневаться в том, что он может управлять людьми.
в принципе, он сам виноват. если бы ему хотелось с нами справится, в чём-то нас убедить, то он бы не вёл себя как ребёнок. это основная ошибка начинающих управленцев -- залезать на стульчик и плакать: "мне подсунули плохих сотрудников/собеседников/партнёров они терминологии не знают".

[Boboms]

Давайте не будем {волноваться} && {кипятиться} && {нервничать} Неадекватный эмоциональный фон дискуссии не помогает, знаете ли
В наш жестокий век надо быть эмоционально устойчивым.

Интересно, а вы сами свои статьи читаете?

Современный бизнес – очень динамичная среда. Чтобы быть успешными, компании должны
подстраиваться под постоянно меняющиеся условия ведения бизнеса,
рыночную ситуацию и так далее. В результате, те или иные организационные
изменения происходят в каждой компании достаточно регулярно.

Подскажите, пожалуйста, какой можно сделать вывод из приведенного выше текста? Ну, правда!

[diesel]

Видите - нет ни слова про обязательное принятие решения до 12:50 13 марта.

для того чтобы это получить, надо взять:

Смотрим:

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

и добавить к этому:

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

не забывая о том что:

Руководитель проекта не должен "оценивать красоту кода" - ему вообще говоря, кода лучше не видеть вовсе. И даже, вовсе не требуется его понимать.

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

[YUKLA]

Подскажите, пожалуйста, какой можно сделать вывод из приведенного выше текста? Ну, правда!

Что это вступление. Вы дальше то читали?

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

А я и не спорю.
Скажите - вы не представляете себе конвейер, который может простаивать? Из-за поломки инструментария, из-за болезни того или иного ключевого мастера, из-за недостатка деталей?

[vinny]

Подскажите, пожалуйста, какой можно сделать вывод из приведенного выше текста? Ну, правда!

Что это вступление. Вы дальше то читали?

http://www.beneffy.com.ua/career.php#03 а вы давно ищите этих людей? я боюсь, что будете искать годами... с людям у которых бизнес-процесс выше человека, никто работать не хочет.

Скажите - вы не представляете себе конвейер, который может простаивать? Из-за поломки инструментария, из-за болезни того или иного ключевого мастера, из-за недостатка деталей?

боже, какая прелесть! я так давно не видела слесарей от управления, что радуюсь каждому вашему посту (:

[diesel]

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

А я и не спорю.
Скажите - вы не представляете себе конвейер, который может простаивать? Из-за поломки инструментария, из-за болезни того или иного ключевого мастера, из-за недостатка деталей?

как раз из того что я писал выше и вытекает что "простаивающий конвейер - это плохой конвейер", ключевого мастера в идеале нет, и не должно быть в принципе, каждый элемент участвующий в работе должен быть легко заменяем, и предсказуем, но даже в этом варианте на практике всплывают нюансы: см. пост уважаемого Ali1 выше. А теперь давайте возьмем методологию разработанную для идеальной модели конвейера и втюхаем ее в разработку ПО, где не каждый элемент _легко_ заменяем, и каждый элемент непредсказуем. И получается. что если в случае конвейера мы могли предполагать что "если все будет хорошо мы выпустим 100 машин за смену", в случае IT-проекта получается "мы тут посчитали, вы можете уложиться за месяц, удачи".

[t.t]

Во-первых, следите, пожалуйста, за языком.

Я гораздо лучше слежу за языком в этой теме, чем это делаете Вы. Привести цитаты?

Во-вторых. В приведённом мною списке терминов нет и половины, "завязанных на Microsoft".

Ну да.. Microsoft Solution Framework, Microsoft Certified Appliaction Developer, Microsoft Certified Solution Developer.. Термины, не имеющие ну никакого отношения к Microsoft... (улыбка ©sash-kan).

В третьих. Microsoft Solutions Framework это методология разработки программного обеспечения. Универсальная. Ага. И не привязанная НИ К ОДНОМУ продукту M$.

Открою Вам страшную тайну: мир не ограничивается не только корпорацией майкрософт, но даже теми людьми, которые считают её разработки универсальными решениями.

И последнее.

Что касается "разобраться в бизнес процессах"... Это лишь ещё раз показывает Ваше непонимание сути проблемы: Вы считаете бизнес-процессы важнее реальных людей, на которых эти процессы держатся. Типичная ошибка "менеджера-теоретика".

Данная цитата говорит о том, что вы совершенно не понимаете суть понятия "бизнес-процесс". Ибо - бизнес-процесс есть отвязанное от исполнителя стандартное, формализованное действие. Бизнес-процессы "держаться" на людях на нулевом уровне "зрелости" процессов на предприятии. Когда никакая методология и не нужна. Во всех остальных случаях они отвязаны от конкретного исполнителя. Есть "собственник" бизнес-процесса. Но это - не конкретный человек, а "позиция". Т.е. - должность.

Вы снова говорите, как заправский теоретик, да ещё и с глубоко въевшимся американским уклоном. Это там приняты люди-функции: "человек ушёл, человек пришёл -- процесс не изменился". На практике так не бывает. Даже в штатах. Во всём остальном мире -- тем более. Человек -- не функция, не автомат, не робот. Успешный бизнес можно построить только базируясь на личных качествах сотрудников. "Корпоратократы" этого не понимают -- да и не хотят понимать: им так удобнее. В итоге и получается блестящий фасад, а внутри всё наспех слеплено, работает кое-как и развалится при неосторожном вздохе. "Это всё плавали-знаем". Продолжайте свою карьеру успешного менеджера, и не забывайте обновлять страничку с резюме: чтобы мы знали, с какими компаниями точно не надо иметь дела.

[Boboms]

Подскажите, пожалуйста, какой можно сделать вывод из приведенного выше текста? Ну, правда!

Что это вступление. Вы дальше то читали?

Ну, не трудно догадаться цель (назначение) данной рекламной статьи. Но не об этом речь В той избито-очевидной фразе, которую вы использовали в качестве вступления заключен определённый смысл. Так вот если вдуматься ...

[t.t]

боже, какая прелесть! я так давно не видела слесарей от управления, что радуюсь каждому вашему посту (:

Соня, твоя способность искренне радоваться таким вещам не перестаёт меня удивлять. (: И после этого ты будешь говорить, что тебе надо у меня учиться общению.. Это мне у тебя надо учиться: посмотри, какой я здесь всё время мрачный. (:

[Boboms]

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

А я и не спорю.
Скажите - вы не представляете себе конвейер, который может простаивать? Из-за поломки инструментария, из-за болезни того или иного ключевого мастера, из-за недостатка деталей?

как раз из того что я писал выше и вытекает что "простаивающий конвейер - это плохой конвейер", ключевого мастера в идеале нет, и не должно быть в принципе, каждый элемент участвующий в работе должен быть легко заменяем, и предсказуем, но даже в этом варианте на практике всплывают нюансы: см. пост уважаемого Ali1 выше. А теперь давайте возьмем методологию разработанную для идеальной модели конвейера и втюхаем ее в разработку ПО, где не каждый элемент _легко_ заменяем, и каждый элемент непредсказуем. И получается. что если в случае конвейера мы могли предполагать что "если все будет хорошо мы выпустим 100 машин за смену", в случае IT-проекта получается "мы тут посчитали, вы можете уложиться за месяц, удачи".

„Кадры решают всё“ И.В.Сталин

[YUKLA]

А теперь давайте возьмем методологию разработанную для идеальной модели конвейера и втюхаем ее в разработку ПО, где не каждый элемент _легко_ заменяем, и каждый элемент непредсказуем. И получается. что если в случае конвейера мы могли предполагать что "если все будет хорошо мы выпустим 100 машин за смену", в случае IT-проекта получается "мы тут посчитали, вы можете уложиться за месяц, удачи".

1. Читаем первоисточник. Модели жизненного цикла программного обеспечения.
2. Вспоминаем, что моделей такового цикла много, Выбираем подходящую.
3. Разумно тратим выделенные 1/3 от общего времени проекта на планирование. Не экономим на менеджерах и архитекторах. Берем лучших и успешных.
4. Тщательно подбираем ведущих разработчиков.
5. Смотрим в сторону альтернативных методик - например Scrum, DSDM или XP.

И видим - конвейер в чистом виде - не единственный вариант реализации. Их много есть. Впрочем, я это уже писал.

[Boboms]

...
Вы снова говорите, как заправский теоретик, да ещё и с глубоко въевшимся американским уклоном. Это там приняты люди-функции: "человек ушёл, человек пришёл -- процесс не изменился". На практике так не бывает. Даже в штатах. Во всём остальном мире -- тем более. Человек -- не функция, не автомат, не робот. Успешный бизнес можно построить только базируясь на личных качествах сотрудников. "Корпоратократы" этого не понимают -- да и не хотят понимать: им так удобнее. В итоге и получается блестящий фасад, а внутри всё наспех слеплено, работает кое-как и развалится при неосторожном вздохе. "Это всё плавали-знаем". Продолжайте свою карьеру успешного менеджера, и не забывайте обновлять страничку с резюме: чтобы мы знали, с какими компаниями точно не надо иметь дела.

Для проверки данной цитаты см. "Финансовый кризис 2008".

А теперь давайте возьмем методологию разработанную для идеальной модели конвейера и втюхаем ее в разработку ПО, где не каждый элемент _легко_ заменяем, и каждый элемент непредсказуем. И получается. что если в случае конвейера мы могли предполагать что "если все будет хорошо мы выпустим 100 машин за смену", в случае IT-проекта получается "мы тут посчитали, вы можете уложиться за месяц, удачи".

1. Читаем первоисточник. Модели жизненного цикла программного обеспечения.
2. Вспоминаем, что моделей такового цикла много, Выбираем подходящую.
3. Разумно тратим выделенные 1/3 от общего времени проекта на планирование. Не экономим на менеджерах и архитекторах. Берем лучших и успешных.
4. Тщательно подбираем ведущих разработчиков.
5. Смотрим в сторону альтернативных методик - например Scrum, DSDM или XP.

И видим - конвейер в чистом виде - не единственный вариант реализации. Их много есть. Впрочем, я это уже писал.

Так, ну и вывод какой???

[arkhnchul]

главное, чтобы тролль не ушел) Дико надеюсь на долгое существование треда...

YUKLA,

1. Читаем первоисточник. Модели жизненного цикла программного обеспечения.
2. Вспоминаем, что моделей такового цикла много, Выбираем подходящую.
3. Разумно тратим выделенные 1/3 от общего времени проекта на планирование. Не экономим на менеджерах и архитекторах. Берем лучших и успешных.
4. Тщательно подбираем ведущих разработчиков.
5. Смотрим в сторону альтернативных методик - например Scrum, DSDM или XP.

ниже имхо из небольшого опыта...
1. думаю, это тут и так все помнят)
2. реально их пара-тройка. Остальные - лишь они же по-другому расписанные, со стрелочками выгнутыми в другую сторону.
3. треть времени мы планируем, а не занимаемся делом (==разработка)?! Нет, я понимаю, что менеджер в данном случае умеет кроме планирования чуть более, чем ничего - но все же...
4. sic! Менеджер - не кодер, он знать ничего не знает и особо не отличит одного разработчика от другого по степени прямой профессиональной пригодности разработчика - т.е. того, насколько оный разработчик врубается в тему того, что будет разраатывать, а не рисовать графики.
5. см. п.2

[t.t]

Кстати о птичках.. Вы хоть ссылки, которые приводите, читаете? Выделение моё:

В третьих. Microsoft Solutions Framework это методология разработки программного обеспечения. Универсальная. Ага. И не привязанная НИ К ОДНОМУ продукту M$.

В 1994 году, стремясь достичь максимальной отдачи от IT-проектов, Майкрософт выпустила в свет пакет руководств по эффективному проектированию, разработке, внедрению и сопровождению решений, построенных на основе своих технологий.

[sash-kan]

не может не знать … Программист - что такое MCAD/MCSD.

нет бога, кроме аллаха…
это мне что-то жутко напоминает.
вспомнил: «божественная винда»…

p.s. уважаемый YUKLA, вы на том сайте под каким логином зарегистрированы?
p.p.s. ушёл подыхать от смеха.