Стандарты управления проектами

polyphage

Позвали на должность менеджера проектов IT. На собеседовании нужно будет рассказать, какие мне знакомы стандарты управления проектами.
Объсните плз, чайнику :(

mayuka

их до жопы:
Материал предоставлен сайтом http://www.adj.ru
B настоящее время в мире существует большое количество стандартов и методологий управления проектами, которые имеют распространение как на международном, так и на национальном уровнях.
Перечислим основные стандарты:
1.PMBOKR Guide (PMI, 1996 г.) является ISO 9001-совместимым. Кроме того, он имеет международное распространение и поддержку.
2.ISO 10006 (Guidelines to Quality in Project Management) (ISO, 1997 г.).
3.BS 6079 (British Standards Board, 1996 г.).
4.DIN 69 900 series x-50-100 series (German standards DIN 69 900 to 69 903 and 69 905).
5.APM BOK (версия. 3.0) (APM Association for Project Managers: Body of Knowledge, пересм. март 1996 г. (версия 3), High Wycombe, 1996 г.).
6.ICB IPMA Competence Baseline (IPMA, 1999 г.).
7.Australian National Competency Standards for Project Management (AIPM (Sponsor), 1996 г.).
8.Prince 2 (PRojects IN Controlled Environments).
9.ANSI/EIA-748-98 Earned Value Management Systems (EVMS), Июль 1998 г.
10.DSDM (Dynamic Systems Development Method).
Источник: http://www.google.ru/search?hl=ru&q=%D1%81%D1%82%D0%B0%D...

serengeti

Позвали на должность менеджера проектов IT
Объсните плз, чайнику
как тебя позвали, интересно :)

feo1978

Запомнилась одна фраза : менеджеры проектов чайниками не могут быть, иначе это не менеджер , а просто название должности )
Менеджер проектов - нужно дорасти, не в плане сколько лет, а в плане жизненого опыта, профессионализма. Это примерно тоже самое спросить - предлагают стать отцом объясните что делать. Если не знаешь и у самого до этого желания не возникло - скорее всего рано им быть.

Ktitiss

Что вы пугаете человека? Ничего такого сложного в работе менеджера ИТ проектов нет. В сущности, если ты умеешь пользоваться кнопкой forward в каком-нибудь почтовом клиенте, то уже будешь вполне сносным менеджером.

lordkay

>>В сущности, если ты умеешь пользоваться кнопкой forward в каком-нибудь почтовом клиенте, то уже будешь вполне сносным менеджером.
ты так на новую работу и устроился? :)

serengeti

Ничего такого сложного в работе менеджера ИТ проектов нет.
бред написал
толи у тебя какое-то наивное представление об управлении проектами, либо наивное представление об ит

h_alishov

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

polyphage

НУ позвали думаю потому что сейчас работаю на подобной должности. Просто как пришел в компанию, так и начал работать, опыта набираться (в общении слюдьми, в решении всевозможных проблем) так сказать, но никогда не задумывался о том, что есть еще какие то СТАНДАРТЫ.

serengeti

какие то СТАНДАРТЫ
т.е. в новую компанию ты придёшь работать методами предыдущего места работы? :)
это не всегда продуктивно ;)

mayuka

>Просто как пришел в компанию, так и начал работать, опыта набираться <....> так сказать, но >никогда не задумывался о том, что есть >еще какие то СТАНДАРТЫ
ну тогда будь уверен, что ты работал не по стандартам, а по наитию, по методу "как получится".
И если контора серьезная, то она будет общаться с другими конторами на языке принятых стандартов.

polyphage

спасибо всем ометившимся :)

kairat

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

redtress

а ты кем работаешь, прости?
Судя по предыдущему посту: менеджером емейлов

kairat

даже не менеджер, а "диспетчер емэйлов"

polyphage

Ладно, посмотрим, что получится.
Я не стал освещать все свои рабочие задачи, сказал лишь кратко (общение с людьми, решение проблем).

geva

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

e_490107

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

kairat

всё - аха, но одно без другого в обоих случаях (практика без знания стандартов, стандарты без практики) - не рулит, для руководителя уж точно :)

e_490107

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

kairat

ты говоришь про специалистов, а я про руководителей
а так - все правильно говоришь :)

e_490107

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

h_alishov

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

Evgeniy57

я знаю только одного неспециалиста
компания ляляля и партнеры ?

h_alishov

ляляля не был хорошим руководителем.

Evgeniy57

я знаю я пересекался с одной командой из ляляля и партнеры, очень негативное впечатление так как делали с ними один совместный проект и команда прогеров, которая делала их часть была из ярославля ;) я порой новых релизов ждал по неделе, а от них требовалось винсервис
в общем проект сделали, а продать не смогли :grin: , а потом фирма развалилась ;)

kairat

а чего ты всю тему свел к проектам РАЗРАБОТКИ и к руководству программистами, то есть область взял сильно Уже, чем был поставлен изначально вопрос. Поэтому я тут с тобой даже спорить не буду - ты спецтерминами кидаешься, если я начну из своей области примеры приводить и кидаться терминами - мы друг друга не поймем вообще, ибо разговор будет о теплом и о мягком.
я в общем говорила, о том, что хороший руководитель ЛЮБОГО (так стоял вопрос) проекта - это сильная теория+обязательно хотя бы некоторая практика (дабы головой быть возвышенно, но ногами стоять все таки на земле), и вот тут к слову разделения понятий "специалист-руководитель" отличный специалист особенно в среде программистов как правило не очень хороший руководитель, ибо ему как правило интересны сугубо специфические вопросы и от этого смотреть на ситуацию (проект) "сверху" он просто скорее всего не сможет, ИМХО :)
вообще, лучшие руководители получаются как правило из аналитиков, а не из "сугуботехнарей", прошу прощения, если кого обидела.

e_490107

Я ее "свел" только потому, что эту область я знаю. И точно так же, как поступаешь ты, я эту область могу аналитически продолжить на все АйТи, хотя и ты и я ничего доказать не сможем. Моя точка зрения здесь - самый обычный противовес "ржачу" над автором в связи с незнанием "стандартов".
И в общем я говорю, что хороший руководитель ЛЮБОГО проекта - это сильная практика+обязательно хотя бы некоторая теория (дабы и проект не завалить и развитием заниматься). :p Смешно?
и вот тут к слову разделения понятий "специалист-руководитель" отличный специалист особенно в среде программистов как правило не очень хороший руководитель, ибо ему как правило интересны сугубо специфические вопросы и от этого смотреть на ситуацию (проект) "сверху" он просто скорее всего не сможет, ИМХО
Узко мыслишь, это, как правило, как раз общее свойство ВСЕХ очень сильных специалистов.
вообще, лучшие руководители получаются как правило из аналитиков, а не из "сугуботехнарей", прошу прощения, если кого обидела
кулик и болото? ;)
ЗЫ За термины - извини. Раз ты отвечала на мои посты, я сделал глупый вывод о том, что ты их полностью поняла. Без сарказма или иронии.

e_490107

Узко мыслишь, это, как правило, как раз общее свойство ВСЕХ очень сильных специалистов
Пока не заклевали (а в аське уже начали) - ИМХО :)

serengeti

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

serengeti

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

feo1978

 
Что вы пугаете человека? Ничего такого сложного в работе менеджера ИТ проектов нет. В сущности, если ты умеешь пользоваться кнопкой forward в каком-нибудь почтовом клиенте, то уже будешь вполне сносным менеджером.
Вообще-то это не менеджер проекта, а передаст называется ( от слова передавать ).
Если вам приходилось работать с такими людьми и они назывались менеджерами проекта - не стоит сопоставлять. Скорее от нехватки кадров.

knigi123

Согласен с midget в плане недоумения по поводу неуместных деталей ведения проектов в IT. Стандарты - это не более чем референсы. А если человек собрался вести проекты, то перед тем как читать пиэмбук или рьяно изучать тонкости методологий начиная с ватерфола, ему следует понять более глобальные аспекты управления проектами. Начиная с определения deliverable, flow-charts, gannt chart etc. И разумно вообще сначала посидеть за рутинной работой с тем microsoft project под присмотром человека, который имеет за плечами опыт и на вышеназванные вопросы знает четкий ответ. Не стоит забывать, что вся заваруха с проектами началась с дюпона и локхида, а они были далеко не IT.
Моё сугубое имхо, пытаться попасть на позицию менеджера проектов без какого-либо понимания, что такое проект вообще, а вместо этого изучать методологии - случай нередкий для нашего времени, что не есть гуд.

Ktitiss

> что опыт заруливает знание стандартов, а стандарт читается за пять минут и
> либо применяется тут же, либо отбрасывается, как неподходящей в данной ситуации
Не, стандарты все-таки лучше заботать и не отбрасывать без крайней нужды. Тут +1 к Миджет. А то приходит такой мега-креативный менеджер, кладет на все стандарты, выполняет хорошо свой проект и уходит. Его команда достается другому менеджеру, и вот попробуй потом им объясни, что в компании есть правила, что у все сотрудники должны отчитываться за затраченное время, что надо комментировать свой код, и т.п.

feo1978

При использовании стандартов и методологий необходимо не забывать что :
 - любой стандарт или методология устаревают на момент их принятия ( особенно IT )
 - проект по определению - уникальное мероприятие, с уникальной внешней средой , соответсвенно должен быть уникальный подход.
 - есть фундаментальные истины, которые не изменны ( некое противоречие первого утверждения, хотя скорее дополнение - как исключение из правил ) , такие как - 9 женщин за 1 месяц не родят и т.п.

e_490107

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

e_490107

Не, стандарты все-таки лучше заботать и не отбрасывать без крайней нужды. Тут +1 к Миджет. А то приходит такой мега-креативный менеджер, кладет на все стандарты, выполняет хорошо свой проект и уходит. Его команда достается другому менеджеру, и вот попробуй потом им объясни, что в компании есть правила, что у все сотрудники должны отчитываться за затраченное время, что надо комментировать свой код, и т.п.
1)Как ты узнаешь, где эффективней применить процесс по стандарту Икс, где по стандарту Игрек, а где лучше всего подойдет гибрид без большого опыта-то?
2)Если менеджер хорошо выполнил проект, никаких проблем с передачей не будет - ты чего-то не договариваешь.

feo1978

В процессе познания чего либо есть 4 этапа :
1. Не знаю сути, Не знаю слово
2. Не знаю сути, Знаю слово.
3. Знаю суть, Не знаю слово.
4. Знаю суть, Знаю слово.
Собственно чтобы успешно управлять проектами нужно находится как минимум на 3-й стадии ( хотя это исключение, для особых проектов ). В целом требуется 4-й уровень.
С первого уровня на 2-й можно перейти общаясь в профессиональной среде , грубо говоря услышать слово. Также можно это считать чтением теории.
На уровень 3 как правило сразу попадают практики без теории, они все понимают, делают правильно, но не могут это выразить профессиональными словами.
4-й уровень обеспечивается только при наличии опыта и знания теории, а точнее профессионального языка.

e_490107

Это не этапы и не стадии, так как не происходит передачи данных с уровня на уровень (хинт: например, со второго на третий).

lordkay

дамы и господа, давайте более предметно меряться пиписьками, или что там у вас!
типа - у меня опыт работы такой, клал на всю теорию, сделал такой, такой и такой проект
а то скучно читать теоритические споры :)

solomon1308

В процессе познания чего либо есть 4 этапа :
1. Не знаю сути, Не знаю слово
2. Не знаю сути, Знаю слово.
3. Знаю суть, Не знаю слово.
4. Знаю суть, Знаю слово.
товарищ Склифасовский, не еби моск пжлста

feo1978

Это не этапы и не стадии, так как не происходит передачи данных с уровня на уровень (хинт: например, со второго на третий).
Согласен, формулировка не точна. Вообще картинка в оригинале выглядит как :
-
1 2
3 4
и пути развития 1->2->4 или 1->3->4, второй путь считается наиболее эффективным, т.к. вероятность перехода 2->4 существенно ниже чем 3->4.
Т.е. знание слова с меньшей долей вероятности приведет к пониманию смысла. А понимание смысла с высокой долей вероятности обеспечивает запоминание слова.
Как пример , следующая ситуация :
втречаются два товарища, один говорит :
- Давай общаться прозой
- Это как ?
- Ну как мы обычно с тобой раньше общались....
- Надо же - всю жизнь c тобой общаюсь , но не знал что это называется прозой.
Т.е. перейти из 3->4 достаточно легко.
Как пример первой ситуации , многие знают словоcочетание "квантовая механика", но мало кто понимает сути. И понять очень сложно, а соотвественно и перейти из 2->4

liliya63

Судя по вот этим твоим двум постам, ты как раз на стадии 2 где-то. :lol:

Evgeniy57

его не трожь у него особая карма ;)

liliya63

Денис, мы же в интернет-форуме, тут нельзя трогать других людей!

Evgeniy57

ага иначе на тебя гредет проклятие :grin:

Ktitiss

дамы и господа, давайте более предметно меряться пиписьками, или что там у вас!
типа - у меня опыт работы такой, клал на всю теорию, сделал такой, такой и такой проект
а то скучно читать теоритические споры
Блин, весь кайф обломал.

feo1978

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

kinglion

Это пиздец. Врагу но пожелаешь руководителя, которые так будет ебать мозги.

feo1978

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

serengeti

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

serengeti

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

serengeti

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

lordkay

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

e_490107

Причем тут строительство вообще? Тред идет строго про АйТи. Рассуждать про "PM в общем" мне неинтересно, сразу скажу. Более того, я считаю "generic" PM'ов без сильной специализации страшно малоэффективными (за редкими исключениями) в около технических областях.
Далее, другие направления требуют другой опыт, обратного я и не утверждал. Я указывал какой именно опыт желателен именно в сфере разработки-поддержки автоматизаций и просто ПО. Естественно, чистым внедренцам требуется уже что-то свое. А уж строителям и подавно.
Good practice - это замечательно, но слишком неконкретно.
В общем я продолжаю утверждать, что опыт из набора _определенных_ областей порулит и без сильной теории для руководителя в _определенной_ области, а наоборот - нет.

e_490107

дамы и господа, давайте более предметно меряться пиписьками, или что там у вас!
типа - у меня опыт работы такой, клал на всю теорию, сделал такой, такой и такой проект
Не знаю-не знаю, я пиписькой не мерялся, а рассказал о своем мнении :p
К тому же, ну скажу я внутрикорпоративные проекты автоматизации такие-то, например, что тебе это скажет? :)

lordkay

>>Не знаю-не знаю, я пиписькой не мерялся, а рассказал о своем мнении
теоритическом мнении или основанном на практике?
если на практике, то вот и интересно услышать практику, а не абстрактные рассуждения о нужности/ненужности стандартов

serengeti

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

serengeti

да я вообще не понимаю, чего мы тут спорим :grin: все работают, все при деле
автор давно уже на собеседование сходил и его взяли :)

e_490107

По большей части на практике. А что ты хочешь услышать?
Что вот пришел клевый чел при мне ПМом. Со стандартами - лады, в теории вроде как разбирается замечательно. Начал в своем проекте налаживать нормальный процесс. Цикл разработки, так сказать. Тестирование, систему релизов. Месяц проработал. К концу месяца оказалось нихрена не изменилось. Лезем смотреть - опа авто тесты, смотрим покрытие - процентов 10. Круууто. Смотрим код - функционал написан, ни хера не работает. Потом оказалось что и система релизов через ж*пу, потому что разрабы его спрашивают, ну а в таких ситуациях как делать, а он детали прояснить не может. Типа "в целом" все знает, а на практике что с ньюансами делать не понимает. При этом он убил время выделенного тестировщика, потому что тестовый сервер из-за этих ньюансов нормально заморожен не был, а другого выделенного предпродакшна не было вообще. Потом еще выяснилось, что тимлид им практически вертел, потому что тот не мог даже понять, что ему впаривают, и половина реализованного сделана неправильно, так как нагрузку не держит в принципе.
Другой пример. Очередной "теоретик". Делают проект. Сроки срываются, смотрят, что там. А там красота, тестирование всего чего нужно, а в основном того, что не нужно. Тесты, как самоцель. А где остановиться, человек не понимает. И вроде грамотно все, замечательно, тесты-рефакторинг, тесты-рефакторинг, а сроки сорваны нахрен и наиболее важные части удовлетворительно не работают до сих пор.
Это про увлеченных теоретиков с малым опытом. Это тебе нужно или что?

kairat

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

Mike3

полуоффтоп: вспомнил пост с joelonsoftware, где он рассказывал, как БГ его талмуд по разработке Excel читал.
про вопросы до первого затруднения в ответе.

e_490107

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

e_490107

Я, вроде, этого перца иногда почитывал, но этого не видел :)
It was a good point. Bill Gates was amazingly technical. He understood Variants, and COM objects, and IDispatch and why Automation is different than vtables and why this might lead to dual interfaces. He worried about date functions. He didn't meddle in software if he trusted the people who were working on it, but you couldn't bullshit him for a minute because he was a programmer. A real, actual, programmer.
Watching non-programmers trying to run software companies is like watching someone who doesn't know how to surf trying to surf.
"It's ok! I have great advisors standing on the shore telling me what to do!" they say, and then fall off the board, again and again. The standard cry of the MBA who believes that management is a generic function. Is Ballmer going to be another John Sculley, who nearly drove Apple into extinction because the board of directors thought that selling Pepsi was good preparation for running a computer company? The cult of the MBA likes to believe that you can run organizations that do things that you don't understand.
:o

e_490107

Флудим помаленьку :D

kairat

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

e_490107

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

kairat

:grin: ты прав - по большей части сравнила по несравнивым условиям.
но первое - все таки не в тепличных условиях :o
но я правда еще ни разу не встречала идеальный вариант - хороший спец и при этом хороший рук :)

frostenrus

Joel конечно молодец, там еще было что-то про уровни менеджмента.
Мол, тогда когда MS что-то выпускала приличное, уровней было 2, а сейчас 5, и сквозь 5 уровней специалист в предметной области уже никак не разглядит что творится.
Про стандарты:
Стандарт — теоретическое руководство по уворачиванию от подводных камней. Польза от него соответственная.
Главное что из стандарта нужно узнать — какие бывают проблемы и какие бывают методы их решения. Следовать стандарту не нужно (тут оговорки опустим) — ни один стандарт все камни не описывает.
С другой стороны, если есть приличный опыт, человек уже сам придумал как обходить эти подводные камни. Сам научился думать и обходить новые.
Человек, который знает только стандарты, не сможет понять "зачем" предлагается делать "так". В итоге вляпается в еще не описанный камень. Непрочитанный стандарт, не описанный в любимом стандарте камень.
С некоторого уровня начальствования вникать в технические подробности уже не получается (некогда). Тут уже работа скорее в "управлении людьми", и Миджет, имхо, про такой случай. Не думаю что начальник управлял по "стандартам управления людьми".
Ну и я не видел [пока] хорошего начальника, не разбирающегося в предметной области.

kairat

а что значит "приличный опыт", по твоему?

frostenrus

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

Mike3

ну да, именно это я и хотел сказать. :)

e_490107

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

e_490107

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

frostenrus

начальника-не спеца
В чем не спеца?
Я говорю, что с некоторого уровня начальствования он должен быть скорее специалистом по управлению людьми. Если он не смог подобрать правильных людей — то он не спец.
Но технические знания ему практически не нужны. Тот же Билл Гейтс сейчас вряд ли вникает в детали работы продуктов MS — их слишком много. Его технические знания уже бесполезны — технические проблемы от него далеко.

e_490107

Ладно, ты, наверное, говоришь об очень высоком уровне в иерархии. Кстати, интересно будет спросить известных технарей Брина и Пейджа, нужны им тех навыки сейчас или нет :) Мэд, сгоняй :D

e_490107

некоторого уровня начальствования он должен быть скорее специалистом по управлению людьми
Таким-то спецом нужно быть на всех уровнях иерархии - это даже не обсуждается
Оставить комментарий
Имя или ник:
Комментарий: