Для начала вопрос: а много ли кто использует знания, полученные в умных книгах по управлению на практике? Почему-то сильно сомневаюсь (разубедите меня, буду только рад!). Уж по крайней мере таких людей будет меньше (в процентом отношении, конечно), чем тех, кто прочитав Страуструпа использует его на практике. Почему так происходит – вопрос отдельный, но рискну предположить, что во многом это происходит из-за того, что руководство, в первую очередь, это общение (взаимодействие) с другими людьми, а людей, которые могут под воздействием умных книжек изменить свой стиль общения с другими – единицы (если таковые вообще имеются; для ответа на этот вопрос отсылаю к трудам Фрейда, Юнга, Хелингера и т.д.). И возникает вопрос – а нужно ли вообще учиться управлять и управлять кем-то? Нет, я не хочу доводить до абсурда и не имею ввиду, что не нужно раздавать задания и как-то контролировать результаты. Под управлением сейчас я имею ввиду какие-то специальные мероприятия для повышения производительности и улучшения качества. И рискну высказать предположение, что управлять то особо и не надо. Большая часть мотивировки людей – это восполнение скрытых потребностей. Не денег, не славы, а чего-то такого, что неумолимо диктует подсознание (а диктует оно, обычно, вещи вроде родительской любви или неудовлетворённой сексуальной жизни ). Как результат люди прибиваются к той иерархии в которой им по той или иной причине комфортно. Кому-то «нравится» деспотизм, кому-то – демократия. Вот вы посмотрите – все ругают CBOSS…Но при этом сколько народу там работает и компания то процветает! Та же Евросеть – тоже отличный пример (да и вообще все конторы с herovajob). Как бы сотрудники CBOSS и иже с ними не говорили как им плохо – они там продолжают работать находя для себя какие-то причины. А теперь, вдумаемся, в чём смысл управления людьми. В том, что бы они были счастливы? Возможно, для кого-то это и так, но для работодателя этого руководителя, всё-таки, первичная цель – это получение прибыли. А прибыль можно получать при совершенно разном стиле управления и Евросеть тому пример. Отсюда и вытекает, что для получения прибыли управление не так важно, раз прибыль можно делать и без всего этого. Далее, я думаю не открою Америку, если скажу что большая (ударение ставьте куда хотите) управленцев в софтверных компаниях – это бывшие программисты или другие компьютерные специалисты, которые склонны к шизоидному типу личности и, как следствие, вообще предпочитают (как минимум – предпочитали) ни с кем особо кроме компьютера не общаться. О каком же управлении может идти речь? Как ни странно – о самом обыкновенном – о политике невмешательства, т.е. как раз о том, о чём, в частности, говорится в Peopleware — программистам надо дать задания и не мешать, а они всё сделают. И наверняка это правильно для тех иерархий, в котором руководитель придерживается такой стратегии управления, т.к. к нему прибились именно те люди, которые нуждаются именно в таком стиле руководства. И я сам и мой непосредственный начальник, и мой коллега в той же должности, что и я придерживаемся преимущественно (каждый, наверное, силу своих внутренних причин) именно такого поведения (странное совпадение, правда?). Но посмотрим на соседний отдел (в моей же компании). Там дисциплина, штрафы и т.д. А результат точно такой же. Продукты выпускаются, с тем же качеством, с теми же задержками что и у нас, текучка тоже не выше (в моей компании она вообще достаточно низкая). И это отлично вписывается в сказанное выше — в каждом из этих отделов работают люди которые нуждаются именно в таком стиле управления. Те, кто по каким-то причинам попадают не в свою иерархию увольняются и как раз и составляют текучку кадров.
Какие выводы из этого можно сделать? Как минимум — не получится изменить стиль руководства под воздействием книг о том, как «надо» руководить. Нужны инструменты посерьезнее (психоаналитик, видимо). Но, второй вывод – не нужно менять стиль, это не изменит ровным счётом ничего. Более того, последствия могут быть произвольными, вплоть до того, что разбежится вся команда, т.к. скрытые потребности этих людей перестанут удовлетворяться. Придут другие, может быть лучше (а может и нет).
Поэтому, коли уж занесло на руководящую должность (тоже не просто так, кстати), то можно сидеть, особо не рыпаться и рулить так, как «подсказывает сердце». Можно, конечно, внедрять разные технические новинки или какие-то методологии вроде XP – в общем продолжать искать разного рода серебренные пули. Но что это даст? Видимо ничего, кроме удовлетворения потребностей. Мне, например, просто иногда приятно козырнуть цитатой кого-то из великих. Каждый из нас, наверняка, сам сможет привести не один пример провалившихся проектов в которых использовались самые модные технологии и наоборот, успешные проекты в котором ничего подобного не было (например, давайте посмотрим на Линукс). Одни и те же методы в разных руках дают совершенно разные результаты. Это не мой тезис, кстати, а Ларри Константина . Кстати, тот же Константин писал что в MS (по крайней мере на тот момент – девяностые годы) в управлении был приличный бардак. И ничего, выжили.
Такие мысли посещают людей, которые сидят в конторах, где всё более менее благополучно и процессы устоялись — притом плюс-минус работают и их результаты устараивают руководство и владельцев.
Книги же пишут для тех ситуаций — когда эти процессы нужно организовавать или реорганизовавать. В эпоху перемен естественно может наблюдаться повышенная текучка кадров, да и вообще перемены могут обойтись дорого и не всегда себя оправдывают, что впрочем с лихвой окупается теми случаями, когда они таки приводят к лучшим результатам, чем были бы без них.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Такие мысли посещают людей, которые сидят в конторах, где всё более менее благополучно и процессы устоялись — притом плюс-минус работают и их результаты устараивают руководство и владельцев. AF>Книги же пишут для тех ситуаций — когда эти процессы нужно организовавать или реорганизовавать. В эпоху перемен естественно может наблюдаться повышенная текучка кадров, да и вообще перемены могут обойтись дорого и не всегда себя оправдывают, что впрочем с лихвой окупается теми случаями, когда они таки приводят к лучшим результатам, чем были бы без них.
Ну, тогда можно переформулировать первое предложение — кто использовал эти знания при организации/реорганизации . Остальной текст оставить можно оставить тем же.
Да и я сам тут не вечно работал....Сравнительно недавно я работал в конторе где уууххххх как всё было, процессом каким-то и не пахло....И ничего — работали. Гораздо веселее было, чем там, где я сейчас
Здравствуйте, trial, Вы писали:
T>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Такие мысли посещают людей, которые сидят в конторах, где всё более менее благополучно и процессы устоялись — притом плюс-минус работают и их результаты устараивают руководство и владельцев.
Хотя, конечно, что-то (какая-то истина) в этом есть....
Здравствуйте, trial, Вы писали:
T>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Такие мысли посещают людей, которые сидят в конторах, где всё более менее благополучно и процессы устоялись — притом плюс-минус работают и их результаты устараивают руководство и владельцев. AF>>Книги же пишут для тех ситуаций — когда эти процессы нужно организовавать или реорганизовавать. В эпоху перемен естественно может наблюдаться повышенная текучка кадров, да и вообще перемены могут обойтись дорого и не всегда себя оправдывают, что впрочем с лихвой окупается теми случаями, когда они таки приводят к лучшим результатам, чем были бы без них.
T>Ну, тогда можно переформулировать первое предложение — кто использовал эти знания при организации/реорганизации . Остальной текст оставить можно оставить тем же.
Использовал. И пока все живы, всё работает и проекты идут.
T>Да и я сам тут не вечно работал....Сравнительно недавно я работал в конторе где уууххххх как всё было, процессом каким-то и не пахло....И ничего — работали. Гораздо веселее было, чем там, где я сейчас
Веселее кому — вам или владельцу бизнеса?
[...] T>Вот такие мысли меня посетили в понедельник.
ИМХО менять иногда нужно. Если возникает проблема — вы её пытаетесь решить. Одна половина решения — локализовать проблему. Вторая — найти решение. Так вот литература может в первую очередь помочь понять, в чём проблема и каковы принципиальные пути решения.
Например, система начала расширяться и команда перестала успевать реализовывать новые пожелания заказчика. В данном случае, на основании прочитанной литературы об ИТ проектах, можно предположить, что, с большой долей вероятности, возникла проблема с управлением требованиями. Предположить можно по тем ситуациям, которые описаны в литературе. Далее из той же литературы можно почерпнуть теоретические пути решения данной проблемы. А вот само решение уже подбирается "по месту".
А то, что команда может развалится — это, конечно, проблема (в конце концов, правда, решаемая), но если команда всё равно в текущем состоянии не справляется с задачей, то зачем она тогда нужна?
Другой вопрос, что КПД данной литературы, к сожалению, оставляет желать лучшего из-за слишком высокого уровня абстракции.
Здравствуйте, AndreyFedotov, Вы писали:
T>>Да и я сам тут не вечно работал....Сравнительно недавно я работал в конторе где уууххххх как всё было, процессом каким-то и не пахло....И ничего — работали. Гораздо веселее было, чем там, где я сейчас AF> Веселее кому — вам или владельцу бизнеса?
Естественно нам
Я, кстати, отчасти это в хорошем смысле. Да, бардак был приличный, зато и бюрократии минимум....
Здравствуйте, Spidola, Вы писали:
S>Например, система начала расширяться и команда перестала успевать реализовывать новые пожелания заказчика. В данном случае, на основании прочитанной литературы об ИТ проектах, можно предположить, что, с большой долей вероятности, возникла проблема с управлением требованиями. Предположить можно по тем ситуациям, которые описаны в литературе. Далее из той же литературы можно почерпнуть теоретические пути решения данной проблемы. А вот само решение уже подбирается "по месту".
А вот не уверен, что соглашусь. Как раз в случае управления требованиями — литература не нужна (имхо, естественно) — в смысле, можно и так понять, что происходит, если посмотреть на происходящее....Но мне кажется, что большая (ударение по вкусу) часть проблем с требованиями происходит не из-за того, что нет соответствующей методологии, а из-за того, что человек общающийся с заказчиком недостаточно уверен в себе и боится отказа, что бы настаивать на своём...Когда заказчик (от которого зависит очень многое!) начинает давить, ему ооочень трудно объяснить, что это невозможно сделать, особенно когда тот уверен в обратном. К сожалению, оценка сроков в IT отличается изрядной примерностью, и поэтому аргумент "это не сделать, потому что на это надо 6 месяцев" может не прокатить; скажут просто — "не гони, на это хватит пары месяцев". И нужно обладать достаточно крепкими нервами, что бы с таком споре устоять....Но это умной книжкой точно не воспитать...
S>А то, что команда может развалится — это, конечно, проблема (в конце концов, правда, решаемая), но если команда всё равно в текущем состоянии не справляется с задачей, то зачем она тогда нужна?
Кстати, как вариант — можно уволить руководителя. В футболе, например, я никогда не слышал, что бы разгоняли всю команду — всегда меняют тренера, когда что-то идёт не так.
S>Другой вопрос, что КПД данной литературы, к сожалению, оставляет желать лучшего из-за слишком высокого уровня абстракции.
Зато иногда её интерестно почитать . Просто как беллетристику.
Здравствуйте, trial, Вы писали:
T>Здравствуйте, Spidola, Вы писали:
S>>Например, система начала расширяться и команда перестала успевать реализовывать новые пожелания заказчика. В данном случае, на основании прочитанной литературы об ИТ проектах, можно предположить, что, с большой долей вероятности, возникла проблема с управлением требованиями. Предположить можно по тем ситуациям, которые описаны в литературе. Далее из той же литературы можно почерпнуть теоретические пути решения данной проблемы. А вот само решение уже подбирается "по месту".
T>А вот не уверен, что соглашусь. Как раз в случае управления требованиями — литература не нужна (имхо, естественно) — в смысле, можно и так понять, что происходит, если посмотреть на происходящее....Но мне кажется, что большая (ударение по вкусу) часть проблем с требованиями происходит не из-за того, что нет соответствующей методологии, а из-за того, что человек общающийся с заказчиком недостаточно уверен в себе и боится отказа, что бы настаивать на своём...Когда заказчик (от которого зависит очень многое!) начинает давить, ему ооочень трудно объяснить, что это невозможно сделать, особенно когда тот уверен в обратном. К сожалению, оценка сроков в IT отличается изрядной примерностью, и поэтому аргумент "это не сделать, потому что на это надо 6 месяцев" может не прокатить; скажут просто — "не гони, на это хватит пары месяцев". И нужно обладать достаточно крепкими нервами, что бы с таком споре устоять....Но это умной книжкой точно не воспитать...
О! А вот давление заказчика нивелировать очень помогает литература, когда говоришь ему, что вот там-то и там-то уважаемые люди и солидные компании пишут, что ваша задача не сделается за одну неделю, а потребуется месяца два... Типа, можете сами посмотреть
S>>А то, что команда может развалится — это, конечно, проблема (в конце концов, правда, решаемая), но если команда всё равно в текущем состоянии не справляется с задачей, то зачем она тогда нужна?
T>Кстати, как вариант — можно уволить руководителя. В футболе, например, я никогда не слышал, что бы разгоняли всю команду — всегда меняют тренера, когда что-то идёт не так.
Ох — аналогии такая непрочная штука ... Например, думу принято разгонять... Импичмент президенту я в России не помню, хотя теоретически возможен...
T>PS: в общем, человеческий фактор рулит!!
Ну, без него, естественно, никуда..
Здравствуйте, Spidola, Вы писали:
S>Другой вопрос, что КПД данной литературы, к сожалению, оставляет желать лучшего из-за слишком высокого уровня абстракции.
Описывать каждый конкретный случай -- тоже не пойдет -- по 2-м причинам -- случаев разных много. книги получаться толстыми очень ... и все равно можно не найти там своего случая .
T>А вот не уверен, что соглашусь. Как раз в случае управления требованиями — литература не нужна (имхо, естественно) — в смысле, можно и так понять, что происходит, если посмотреть на происходящее....Но мне кажется, что большая (ударение по вкусу) часть проблем с требованиями происходит не из-за того, что нет соответствующей методологии, а из-за того, что человек общающийся с заказчиком недостаточно уверен в себе и боится отказа, что бы настаивать на своём...Когда заказчик (от которого зависит очень многое!) начинает давить, ему ооочень трудно объяснить, что это невозможно сделать, особенно когда тот уверен в обратном. К сожалению, оценка сроков в IT отличается изрядной примерностью, и поэтому аргумент "это не сделать, потому что на это надо 6 месяцев" может не прокатить; скажут просто — "не гони, на это хватит пары месяцев". И нужно обладать достаточно крепкими нервами, что бы с таком споре устоять....Но это умной книжкой точно не воспитать...
Тут есть один момент, связанный с тем, что для того чтобы сказать что на "это нужно 6 месяцев" нужно это чем-то аргуменировать ... иначе нечем возразить тем, кто говорит, "что пару месяцев достаточно". Иначе это будет спор ощущений а не фактов . А факты как раз можно брать из статистики (метрик) работы, которые без управления (их же нужно получить!) врядли нарисуются ...
Здравствуйте, trial, Вы писали:
T>Здравствуйте, AndreyFedotov, Вы писали:
T>>>Да и я сам тут не вечно работал....Сравнительно недавно я работал в конторе где уууххххх как всё было, процессом каким-то и не пахло....И ничего — работали. Гораздо веселее было, чем там, где я сейчас AF>> Веселее кому — вам или владельцу бизнеса?
T>Естественно нам
T>Я, кстати, отчасти это в хорошем смысле. Да, бардак был приличный, зато и бюрократии минимум....
Работал я как то в подобной фирме. Через пару месяцов, как я оттуда ушёл — они таки развалились.
Вообще моё личное мнение, женьщина крайне вменяемая, и дельные статьи пишет.
У каждого есть свои заскоки, если не считать меня и тебя, Читатель. Хотя насчет тебя я уже не так уверен.
— Фуллер Томас, 1608-1661, английский богослов и историк
> Под управлением сейчас я имею ввиду какие-то специальные мероприятия для повышения производительности и улучшения качества. И рискну высказать предположение, что управлять то особо и не надо. Большая часть мотивировки людей – это восполнение скрытых потребностей.
Управлять надо проектами. Управление людьми на 90% сводится к тому чтобы
1) Самому не мешать тем кто может работать, и убирать другие препятствия которые могут мешать.
2) Увольнять(в идеале отсеивать еще на собеседовании) тех кто не может(и таким образом сам является препятствием для других).
3) Помогать определиться тем кто еще не понял может он или нет.
Это все касается IT где люди по дизайну вменяемые. В макдональдсе совершенно нормальная ситуация когда когда менеджер зала пальцем показывает уборщице где мыть.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, byur, Вы писали:
B>Здравствуйте, trial, Вы писали:
T>>А вот не уверен, что соглашусь. Как раз в случае управления требованиями — литература не нужна (имхо, естественно) — в смысле, можно и так понять, что происходит, если посмотреть на происходящее....Но мне кажется, что большая (ударение по вкусу) часть проблем с
B>Тут есть один момент, связанный с тем, что для того чтобы сказать что на "это нужно 6 месяцев" нужно это чем-то аргуменировать ... иначе нечем возразить тем, кто говорит, "что пару месяцев достаточно". Иначе это будет спор ощущений а не фактов . А факты как раз можно брать из статистики (метрик) работы, которые без управления (их же нужно получить!) врядли нарисуются ...
Это конечно да. Но как быть, если задача сравнительно уникальна? Статистики не будет в этом случае.
Здравствуйте, Spidola, Вы писали:
S>О! А вот давление заказчика нивелировать очень помогает литература, когда говоришь ему, что вот там-то и там-то уважаемые люди и солидные компании пишут, что ваша задача не сделается за одну неделю, а потребуется месяца два... Типа, можете сами посмотреть
Это так, для типовых задач....А для достаточно уникальных — возникнут проблемы.
T>>Кстати, как вариант — можно уволить руководителя. В футболе, например, я никогда не слышал, что бы разгоняли всю команду — всегда меняют тренера, когда что-то идёт не так.
S>Ох — аналогии такая непрочная штука ... Например, думу принято разгонять... Импичмент президенту я в России не помню, хотя теоретически возможен...
>> Под управлением сейчас я имею ввиду какие-то специальные мероприятия для повышения производительности и улучшения качества. И рискну высказать предположение, что управлять то особо и не надо. Большая часть мотивировки людей – это восполнение скрытых потребностей.
A>Управлять надо проектами. Управление людьми на 90% сводится к тому чтобы A>1) Самому не мешать тем кто может работать, и убирать другие препятствия которые могут мешать. A>2) Увольнять(в идеале отсеивать еще на собеседовании) тех кто не может(и таким образом сам является препятствием для других). A>3) Помогать определиться тем кто еще не понял может он или нет.
A>Это все касается IT где люди по дизайну вменяемые. В макдональдсе совершенно нормальная ситуация когда когда менеджер зала пальцем показывает уборщице где мыть.
В IT тоже ничего не мешает так делать. Я сам видел такое не раз, когда тимлид или даже ПМ указывает что, где и как писать. И ничего особо страшного не происходило.
T>Это конечно да. Но как быть, если задача сравнительно уникальна? Статистики не будет в этом случае.
Проект пилотируемого полете на Марс ? ... По части уникальных проектов в СССР был большой опыт (сказано без тени иронии) ... правда в основном они делались истинными энтузиастами своего дела. Если у вас случай -- когда люди присполнены энтузиазма и проект имеет сильную идею ... то это в совокупности может может служить причиной успеха проекта без всякого управляющего воздействия . Но таких проектов -- очеееень мало ...
Однозначно могу сказать, что управлять нужно.
Нужно изучать модели производственных процессов и менять стихийно сложившийся процесс в компании.
По своему опыту управления могу сказать, что отказ от стихийного процесса и внедрение
процессов, почерпнутых из литературы, делает прозводство намного более предсказуемым и управляемым.
Дело это, конечно, не быстрое. Самое главное препятствие на пути внедрения новых
производственных процессов — это люди, которые привыкли работать по старинке, которым кажется,
что за ними будет слишком много контроля, которым спокойней, когда ничего не меняется.
Но если подходить к вопросу с точки зрения бизнес-приоритетов (а именно так и нужно делать), то становиться ясно,
что важнее не спокойствие сотрудников, а качество продукта.
Для примера приведу несколько, что называется, "земных" примеров, что лично мы сделали в нашей кампании,
как обстояли дела при стихийном процессе, и как они обстоят сейчас —
1. Итерирование
Раньше разработка продукта шла постоянно, непрерывно, не разбиваясь на этапы, в течении нескольких лет (специфика проектов такова, что мы не никогда не закрываем их, а работаем над их расширением и улучшением).
Соответственно, невозможно было спланировать сколько-нибудь осмысленные логические этапы разработки.
Теперь этого нет. Длительность итерации не превышает 4-х недель. В конце итерации мы имеем новую версию нашей системы.
Мы знаем, сколько продлится итерация и какие работы мы выполним.
2. Управление ошибками
Полностью автоматизарован рабочий цикл управления ошибками:
Обнаружение — Приоретизация — Назначение ответственного — Устранение — Верификация
Раньше об ошибках сообщалось устно, по мере их возникновения. Теперь, благодаря автоматизированному тестированию,
множество ошибок обнаруживается автоматически. Ни одна из ошибок не устраняется, не попав в базу ошибок.
Всегда можно посмотреть сколько ошибок у нас возникает, кто за них ответственнен и т.п.
3. Управление требованиями.
Раньше как такого управления требованиями не существовало — в любой момент мог поступить запрос, который кто-то бросался
устранять. Теперь все требования проходят приоретизацию, заносятся в базу, разбиваются по итерациям. Мы всегда знаем, какой набор требованяй мы реализуем в текущей итерации и какие у нас запланирваны на последующие.
4. TimeTracking
Контроль времени, затраченный разработчиками на решение любых задач позволил решить несколько проблем —
— Проблема планирования — теперь, давая оценку времени в момент планирования итерации, сотрудники подходят к этому более ответственно, так как знают, что потом будет подсчитано, сколько они времени прогнозировали на решение каждой задачи и сколько в действительности пришлось им потратить. Таким образом, с опытом, повышается качество прогнозов.
— Проблема контроля — теперь известно, кто чем занимался в течении дня и сколько времени на это потратил.
— Проблема оценок — теперь мы можем оценить, сколько времени и денег мы потратили на различные задачи, подсистемы, требования и ошибки в пределах каждой итерации.
— Проблема рабочего времени — удалось избавиться из ситуации, когда кто-то работает днем, кто-то с обеда и до полуночи.
Эта ситуация существенно снижала эффективность работы.
5. Ежедневные билды.
Замечательная идея, позволяющая нам теперь оперативно находить ошибки и оценивать ход работ.
Прекрасное письмо!
M_E>Однозначно могу сказать, что управлять нужно. M_E>Нужно изучать модели производственных процессов и менять стихийно сложившийся процесс в компании.
M_E>По своему опыту управления могу сказать, что отказ от стихийного процесса и внедрение M_E>процессов, почерпнутых из литературы, делает прозводство намного более предсказуемым и управляемым.
M_E>Дело это, конечно, не быстрое. Самое главное препятствие на пути внедрения новых M_E>производственных процессов — это люди, которые привыкли работать по старинке, которым кажется, M_E>что за ними будет слишком много контроля, которым спокойней, когда ничего не меняется.
M_E>Но если подходить к вопросу с точки зрения бизнес-приоритетов (а именно так и нужно делать), то становиться ясно, M_E>что важнее не спокойствие сотрудников, а качество продукта.
Полностью согласен. Есть правда одно существенное дополнение.
Процессы, описанные выше, можно вводить искуссно — тогда это действительно приводит к прекрасным результатам. Но бывает ситуация, когда эти процессы вводятся неумело, для галочки. То есть во главу угла ставится не суть процессов — более эффективная организация работы, а внешняя форма. Или другой вариант — реальные процессы подменяются жёстким, авторитарным стилем управления. Оба этих подхода приводят к идеентичным результатам — обычно даже худшим чем тот стихийный порядок который был до них. Вот так действительно врядли стоит управлять.
Однако если процессы организовавать умело, вводить их поэтапно, с постепенной подготовкой людей к их применению — то это может не только принести бизнесу пользу (так как вы это описали), но и поднять активность людей, участвующих в них.
Потому, главным препятствием являются не столько люди, работающие по старинке (их можно рассматривать как часть задачи), а мастерство управляющих, организующих данные процессы.
Здравствуйте, trial, Вы писали:
T>Здравствуйте, Spidola, Вы писали:
S>>О! А вот давление заказчика нивелировать очень помогает литература, когда говоришь ему, что вот там-то и там-то уважаемые люди и солидные компании пишут, что ваша задача не сделается за одну неделю, а потребуется месяца два... Типа, можете сами посмотреть
T>Это так, для типовых задач....А для достаточно уникальных — возникнут проблемы.
Нет уникальных задач, назовите хотя бы одну уникальную, я вам разложу её на несколько типичных.
Анализировать надо.
У каждого есть свои заскоки, если не считать меня и тебя, Читатель. Хотя насчет тебя я уже не так уверен.
— Фуллер Томас, 1608-1661, английский богослов и историк
Здравствуйте, barmaleyka, Вы писали:
B>Нет уникальных задач, назовите хотя бы одну уникальную, я вам разложу её на несколько типичных. B>Анализировать надо.
Пожалуйста: понимание смысла текста написанного на естественном языке
Здравствуйте, trial, Вы писали:
A>>Управлять надо проектами. Управление людьми на 90% сводится к тому чтобы A>>1) Самому не мешать тем кто может работать, и убирать другие препятствия которые могут мешать. A>>2) Увольнять(в идеале отсеивать еще на собеседовании) тех кто не может(и таким образом сам является препятствием для других). A>>3) Помогать определиться тем кто еще не понял может он или нет.
A>>Это все касается IT где люди по дизайну вменяемые. В макдональдсе совершенно нормальная ситуация когда когда менеджер зала пальцем показывает уборщице где мыть.
T>В IT тоже ничего не мешает так делать. Я сам видел такое не раз, когда тимлид или даже ПМ указывает что, где и как писать. И ничего особо страшного не происходило.
Есть и такие компании. Плохое получается в том что размер команды ограничен способностью одного тимлида читать код.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, Anatolix, Вы писали:
A>>>Это все касается IT где люди по дизайну вменяемые. В макдональдсе совершенно нормальная ситуация когда когда менеджер зала пальцем показывает уборщице где мыть.
T>>В IT тоже ничего не мешает так делать. Я сам видел такое не раз, когда тимлид или даже ПМ указывает что, где и как писать. И ничего особо страшного не происходило.
A>Есть и такие компании. Плохое получается в том что размер команды ограничен способностью одного тимлида читать код.
Дык размер команды и так ограничен
У одного то лида...Если команда растёт её надо пилить на части.
Любой руководитель, прочитавший одну или несколько книг по методологии, и решивший сразу реализовать все принципы, не совсем понимая, зачем он это делает, обречен на неудачу.
Всегда любое изменение процессов должно происходить только после выяснения узких мест в проекте и должно преследовать конкретные ясные цели. Ибо не ради манервов воюем, а на победу. Так постепенно вы выясните, какие методики вам подходят, а от каких лучше отказаться. И создадите свою собственную методологию...
Здравствуйте, AndreyFedotov, Вы писали:
AF>Здравствуйте, barmaleyka, Вы писали:
B>>Нет уникальных задач, назовите хотя бы одну уникальную, я вам разложу её на несколько типичных. B>>Анализировать надо.
AF>Пожалуйста: понимание смысла текста написанного на естественном языке
Пожалуйста.
1) Синтаксический анализ.
2) Преобразование текста в семантическую сеть.
3) Поиск аналогов в базе знаний
4) Продукция выводов
Примерно так.
У каждого есть свои заскоки, если не считать меня и тебя, Читатель. Хотя насчет тебя я уже не так уверен.
— Фуллер Томас, 1608-1661, английский богослов и историк
Здравствуйте, barmaleyka, Вы писали:
B>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Здравствуйте, barmaleyka, Вы писали:
B>>>Нет уникальных задач, назовите хотя бы одну уникальную, я вам разложу её на несколько типичных. B>>>Анализировать надо.
AF>>Пожалуйста: понимание смысла текста написанного на естественном языке
B>Пожалуйста.
B>1) Синтаксический анализ. B>2) Преобразование текста в семантическую сеть. B>3) Поиск аналогов в базе знаний B>4) Продукция выводов
B>Примерно так.
Это если используются семантические сети. А вот эффективность их использования ещё надо оценить. Кроме того, в известном мне и довольно успешном проекте как раз таки семантические сети и не использовались
Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>Однозначно могу сказать, что управлять нужно.
То, что вы вишете замечательно соотносится со сказанным Anatolix-ом >>Управлять надо проектами.
M_E>1. Итерирование M_E>2. Управление ошибками M_E>3. Управление требованиями. M_E>4. TimeTracking M_E>5. Ежедневные билды.
Среди этого всего нет ни одного пункта касающегося управления именно персоналом (кроме, частично, TimeTracking). Это осознанно принятое решение? Или вы считаете, что это всё не важно?
Здравствуйте, Патрик, Вы писали:
П>Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>>Однозначно могу сказать, что управлять нужно.
П>То, что вы вишете замечательно соотносится со сказанным Anatolix-ом >>>Управлять надо проектами.
А вот мне так не показалось.
M_E>>1. Итерирование M_E>>2. Управление ошибками M_E>>3. Управление требованиями. M_E>>4. TimeTracking M_E>>5. Ежедневные билды.
Всё вышеперечисленное с моей точки зрения как раз связано с управлением людьми.
Например ежедневные билды — позволяют вовремя выявлять ошибки и принимать меры, что как раз к управлению людьми и относится.
П>Среди этого всего нет ни одного пункта касающегося управления именно персоналом (кроме, частично, TimeTracking).
Есть подозрение, что мы по разному понимаем, что такое "управление именно персоналом".
Что бы разговор был предметным, не могли бы вы привести примеры того, что именно вы рассматриваете как примеры такого управления и/или определить как вы это понимаете?
Вы имеете в виду непосредственное общение с людьми?
П>Это осознанно принятое решение? Или вы считаете, что это всё не важно?
После того, как мы определимся кто и что имел в виду — на эти вопросы можно будет предметно ответить.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Здравствуйте, Патрик, Вы писали:
П>>Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>>>Однозначно могу сказать, что управлять нужно.
П>>То, что вы вишете замечательно соотносится со сказанным Anatolix-ом >>>>Управлять надо проектами. AF>А вот мне так не показалось.
M_E>>>1. Итерирование M_E>>>2. Управление ошибками M_E>>>3. Управление требованиями. M_E>>>4. TimeTracking M_E>>>5. Ежедневные билды.
AF>Всё вышеперечисленное с моей точки зрения как раз связано с управлением людьми. AF>Например ежедневные билды — позволяют вовремя выявлять ошибки и принимать меры, что как раз к управлению людьми и относится.
Scope, scope и scope. Опять мимо. Эх...
Продажа билетов на транспорт тоже по вашему относиться к управлению людьми?
Ведь люди покупают эти билеты, правильно?
П>>Среди этого всего нет ни одного пункта касающегося управления именно персоналом (кроме, частично, TimeTracking).
AF>Есть подозрение, что мы по разному понимаем, что такое "управление именно персоналом".
Да, у меня тоже такое впечатление складывается.
AF>Что бы разговор был предметным, не могли бы вы привести примеры того, что именно вы рассматриваете как примеры такого управления и/или определить как вы это понимаете?
Ну, как бы вам объяснить, если вы не знаете арифметику, как вам объяснить, что такое корень, и почему он квадратный.
AF>Вы имеете в виду непосредственное общение с людьми?
Я думаю автор имелл ввиду непосредственное управление людьми.
П>>Это осознанно принятое решение? Или вы считаете, что это всё не важно?
AF>После того, как мы определимся кто и что имел в виду — на эти вопросы можно будет предметно ответить.
Долго это придётся выяснять...
У каждого есть свои заскоки, если не считать меня и тебя, Читатель. Хотя насчет тебя я уже не так уверен.
— Фуллер Томас, 1608-1661, английский богослов и историк
Здравствуйте, Патрик, Вы писали:
П>Среди этого всего нет ни одного пункта касающегося управления именно персоналом (кроме, частично, TimeTracking). Это осознанно принятое решение? Или вы считаете, что это всё не важно?
А что конкретно вы имеете в виду? Кадровую политику?
Здравствуйте, barmaleyka, Вы писали:
B>1) Синтаксический анализ. B>2) Преобразование текста в семантическую сеть. B>3) Поиск аналогов в базе знаний B>4) Продукция выводов
А теперь, внимание вопрос: неужели для этих задач найдётся статистика по тому, сколько они занимают ресурсов?
Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>Здравствуйте, Патрик, Вы писали:
П>>Среди этого всего нет ни одного пункта касающегося управления именно персоналом (кроме, частично, TimeTracking). Это осознанно принятое решение? Или вы считаете, что это всё не важно?
M_E>А что конкретно вы имеете в виду? Кадровую политику?
Ну, можно и так сказать
Я имел ввиду:
а) То, о чём писали Демарко и Листер в Peopleware
— Управление овертаймами
— Управление внутренней конкуренцей
— Управление обучением
— Управление потоком
— Управление наймом
— etc
б) То, о чём писал Ларри Константин в Constantine on Peopleware
— Поиски консенсусов и компромиссов при проектировке и кодировании
— Работа с непризнаными гениями и им подобным "ковбоям"
— Организация работ (пирамида, хаос, открытая архитекрута...)
— etc
в) То, о чём писал Джоэл Сполски в своих статьях здесь
— Премирование, ранжирование, аттестация etc
— Доверие сотрудникам и их ответственность
— etc
г) И всё другое, что базируется на понимании того, что люди не роботы, и вместо того, что бы работать они будут сидеть и писать всякую чушь на RSDN (это я про себя исключительно )
Здравствуйте, AndreyFedotov, Вы писали:
AF>Здравствуйте, Патрик, Вы писали: П>>Здравствуйте, Michael_E_Smrinov, Вы писали:
AF>Есть подозрение, что мы по разному понимаем, что такое "управление именно персоналом".
AF>Что бы разговор был предметным, не могли бы вы привести примеры того, что именно вы рассматриваете как примеры такого управления и/или определить как вы это понимаете?
Здравствуйте, Патрик, Вы писали:
П>Здравствуйте, barmaleyka, Вы писали:
B>>1) Синтаксический анализ. B>>2) Преобразование текста в семантическую сеть. B>>3) Поиск аналогов в базе знаний B>>4) Продукция выводов
П>А теперь, внимание вопрос: неужели для этих задач найдётся статистика по тому, сколько они занимают ресурсов?
П>Что то слабо верится...
Дело в том, что и эти задачи раскладываются на более простые, для которых есть статистика.
У каждого есть свои заскоки, если не считать меня и тебя, Читатель. Хотя насчет тебя я уже не так уверен.
— Фуллер Томас, 1608-1661, английский богослов и историк
Здравствуйте, Патрик, Вы писали:
П>Здравствуйте, barmaleyka, Вы писали:
B>>1) Синтаксический анализ. B>>2) Преобразование текста в семантическую сеть. B>>3) Поиск аналогов в базе знаний B>>4) Продукция выводов
П>А теперь, внимание вопрос: неужели для этих задач найдётся статистика по тому, сколько они занимают ресурсов?
П>Что то слабо верится...
Нет конечно. То есть она есть для тех случаев, когда требуется повторить нечто уже существующее — но это как правило никому не нужно. Задача — типично исследовательская, и статистики для неё нет.
Эту статистику можно собрать, но обычно это требует выполнения от черверти до трети от общего объёма работ.
Здравствуйте, Патрик, Вы писали:
П>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Здравствуйте, Патрик, Вы писали: П>>>Здравствуйте, Michael_E_Smrinov, Вы писали:
AF>>Есть подозрение, что мы по разному понимаем, что такое "управление именно персоналом".
AF>>Что бы разговор был предметным, не могли бы вы привести примеры того, что именно вы рассматриваете как примеры такого управления и/или определить как вы это понимаете?
П>Я вот тут — Re[4]: А нужно ли кем-то управлять?
Здравствуйте, barmaleyka, Вы писали:
B>Здравствуйте, Патрик, Вы писали:
П>>Здравствуйте, barmaleyka, Вы писали:
B>>>1) Синтаксический анализ. B>>>2) Преобразование текста в семантическую сеть. B>>>3) Поиск аналогов в базе знаний B>>>4) Продукция выводов
П>>А теперь, внимание вопрос: неужели для этих задач найдётся статистика по тому, сколько они занимают ресурсов?
П>>Что то слабо верится...
B>Дело в том, что и эти задачи раскладываются на более простые, для которых есть статистика.
Её можно где-то увидеть? Не потребуется ли на поиски времени больше, чем на саму реализацию?
Здравствуйте, barmaleyka, Вы писали:
S>>>О! А вот давление заказчика нивелировать очень помогает литература, когда говоришь ему, что вот там-то и там-то уважаемые люди и солидные компании пишут, что ваша задача не сделается за одну неделю, а потребуется месяца два... Типа, можете сами посмотреть
T>>Это так, для типовых задач....А для достаточно уникальных — возникнут проблемы.
B>Нет уникальных задач, назовите хотя бы одну уникальную, я вам разложу её на несколько типичных. B>Анализировать надо.
Да и мне вообще непонятно где брать статистику по использованию ресурсов типичными задачами. Есть какие-то "статистические сборники"? Если да, то где?
NB: это не издёвка, ни в коем случае, мне в самом деле интересно. Что ещё за уважаемые люди и солидные компании?
Здравствуйте, Патрик, Вы писали:
П>Да и мне вообще непонятно где брать статистику по использованию ресурсов типичными задачами. Есть какие-то "статистические сборники"? Если да, то где?
П>NB: это не издёвка, ни в коем случае, мне в самом деле интересно. Что ещё за уважаемые люди и солидные компании?
На самом деле всё просто. От статистики общеотраслевой толку вообще мало — ведь совершенно не ясно кто, как и в каких условиях решал задачу, а потому совершенно не ясно — можно ли применять цифры этой статистики в данных конкретных условиях. Потому методологии или стандарты, которые пользуются подобной статистикой (CMM, CoCoMo 1/2, PSP, RUP, XP...) исходят из того, что организация начинает с того, что собирает данную статистику у себя сама.
Например так: задачи дробятся достаточно мелко для того, что бы их можно было поручить конкретным исполнителям и оценивать с достаточной точностью (от нескольких часов до нескольких дней), проводятся первичная оценка — сколько это должно занять (иногда по нескольким точкам — например сколько это должно занять минимум, максимум и наиболее вероятно). По завершению задачи проставляется — сколько реально заняла задача. Пару десятков таких задач на каждого (то есть примерно 2-6 месяцев — обычно стараются пронаблюдать хотя бы один цикл разработки ПО целиком) и получается довольно хорошая статистика на основе которой можно уже делать какие-то выводы и оценки — более менее точно.
То есть переход от оценки методом умножения на пи, к более точным статистическим оценкам — с высокой степенью достоверности занимает около года. Вроде бы говорят, что кому то удавалось это сделать быстрее, но я такого сам не видел.
Здравствуйте, AndreyFedotov, Вы писали:
П>>Да и мне вообще непонятно где брать статистику по использованию ресурсов типичными задачами. Есть какие-то "статистические сборники"? Если да, то где? П>>NB: это не издёвка, ни в коем случае, мне в самом деле интересно. Что ещё за уважаемые люди и солидные компании?
AF> На самом деле всё просто....организация начинает с того, что собирает данную статистику у себя сама
<skip>
Неее...! Так не пойдёт . В исходном предложении (от Spidola) было написано следующее: >>О! А вот давление заказчика нивелировать очень помогает литература, когда говоришь ему, что вот там-то и там-то уважаемые люди и солидные компании пишут, что ваша задача не сделается за одну неделю, а потребуется месяца два... Типа, можете сами посмотреть
А теперь выходит, что наша компания и я сам (т.е. те, кто в данный момент общается с заказчиком) и является тем самым авторитетом?
Не думаю, что заказчика это убедит
AF>Например так:
<skip>
Здравствуйте, Патрик, Вы писали:
П>Здравствуйте, AndreyFedotov, Вы писали:
П>>>Да и мне вообще непонятно где брать статистику по использованию ресурсов типичными задачами. Есть какие-то "статистические сборники"? Если да, то где? П>>>NB: это не издёвка, ни в коем случае, мне в самом деле интересно. Что ещё за уважаемые люди и солидные компании?
AF>> На самом деле всё просто....организация начинает с того, что собирает данную статистику у себя сама П><skip>
П>Неее...! Так не пойдёт . В исходном предложении (от Spidola) было написано следующее: >>>О! А вот давление заказчика нивелировать очень помогает литература, когда говоришь ему, что вот там-то и там-то уважаемые люди и солидные компании пишут, что ваша задача не сделается за одну неделю, а потребуется месяца два... Типа, можете сами посмотреть
П>А теперь выходит, что наша компания и я сам (т.е. те, кто в данный момент общается с заказчиком) и является тем самым авторитетом? П>Не думаю, что заказчика это убедит
Так и тут всё просто. Сначала оцениываются сроки исходя из внутренней статисики, а потом под это подгоняется статистика индустриальная...
). Как результат люди прибиваются к той иерархии в которой им по той или иной причине комфортно. Кому-то «нравится» деспотизм, кому-то – демократия. Вот вы посмотрите – все ругают CBOSS…Но при этом сколько народу там работает и компания то процветает! Та же Евросеть – тоже отличный пример (да и вообще все конторы с herovajob). Как бы сотрудники CBOSS и иже с ними не говорили как им плохо – они там продолжают работать находя для себя какие-то причины. А теперь, вдумаемся, в чём смысл управления людьми. В том, что бы они были счастливы? Возможно, для кого-то это и так, но для работодателя этого руководителя, всё-таки, первичная цель – это получение прибыли. А прибыль можно получать при совершенно разном стиле управления и Евросеть тому пример. Отсюда и вытекает, что для получения прибыли управление не так важно, раз прибыль можно делать и без всего этого. Далее, я думаю не открою Америку, если скажу что большая (ударение ставьте куда хотите) управленцев в софтверных компаниях – это бывшие программисты или другие компьютерные специалисты, которые склонны к шизоидному типу личности и, как следствие, вообще предпочитают (как минимум – предпочитали) ни с кем особо кроме компьютера не общаться. О каком же управлении может идти речь? Как ни странно – о самом обыкновенном – о политике невмешательства, т.е. как раз о том, о чём, в частности, говорится в Peopleware — программистам надо дать задания и не мешать, а они всё сделают. И наверняка это правильно для тех иерархий, в котором руководитель придерживается такой стратегии управления, т.к. к нему прибились именно те люди, которые нуждаются именно в таком стиле руководства. И я сам и мой непосредственный начальник, и мой коллега в той же должности, что и я придерживаемся преимущественно (каждый, наверное, силу своих внутренних причин) именно такого поведения (странное совпадение, правда?). Но посмотрим на соседний отдел (в моей же компании). Там дисциплина, штрафы и т.д. А результат точно такой же. Продукты выпускаются, с тем же качеством, с теми же задержками что и у нас, текучка тоже не выше (в моей компании она вообще достаточно низкая). И это отлично вписывается в сказанное выше — в каждом из этих отделов работают люди которые нуждаются именно в таком стиле управления. Те, кто по каким-то причинам попадают не в свою иерархию увольняются и как раз и составляют текучку кадров.
. Кстати, тот же Константин писал что в MS (по крайней мере на тот момент – девяностые годы) в управлении был приличный бардак. И ничего, выжили. 
