вторник, 7 февраля 2012 г.

[work] Ознакомился с докладом “Переключатель: в какой момент инженер начинает думать как менеджер?”

Когда я увидел доклад с таким названием, то подумал о том, что бы включить ссылку на него в серию “Быть начальником”, особенно в виде дополнения к последней на данный момент заметке “Самомаштабирование”. Но затем я передумал. И вот почему.

На сайте конференции EXPERT Labs доступен сделанный в прошлом году доклад Славы Панкратова “Переключатель: в какой момент инженер начинает думать как менеджер?” Я его увидел только сегодня.

Просмотрел сначала слайды к докладу. Зародилось какое-то неосознанное чувство “Не верю!”

Затем просмотрел видео. И ближе к концу понял, что меня напрягало по ходу всего доклада. Докладчик не знает, что такое инженер, о чем думает инженер, что инженером руководит. Те образцы поведения “тонкой натуры”, которые приводит в своем докладе Панкратов, лично мне кажутся специально надуманными и притянутыми за уши.

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

Так что доклад могу охарактеризовать всего двумя словами: херня полная. Ну либо я по критериям Панкратова уже не инженер и какой-то переключатель во мне уже щелкнул :)

PS. А первая мысль, когда я начал смотреть слайды и на первых страницах увидел перечень “достижений” докладчика была: “А почему подобные доклады читают специалисты по тренингам, а не менеджеры, отвечавшие за разработку, скажем IDEA или Visual Studio? Нет ли здесь повторения принципа: кто не может делать, тот учит?”

68 комментариев:

Сергей комментирует...

Выходит не у меня одного такое же чувство :-)

eao197 комментирует...

@Sergey Nikulov:

Ну дык получается, что и не одного меня такое же чувство ;)

имя комментирует...

вообще в менеджеры надо ставить девочек и платить им, конечно, побольше чем секретаршам, но не так, как разработчикам

eao197 комментирует...

@имя:

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

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

Ну а уж выражение "успешный менеджер" -- это как красная тряпка. Особенно когда такие ярлыки менеджеры сами себе навешивают. Вроде создания клуба успешных менеджеров.

имя комментирует...

> Их работа потяжелее работы разработчиков будет

а в чем проявляется ее тяжесть?

а так же есть ли там творческий характер, или это просто следование чуть более сложному алгоримту, чем у секретарши?

имя комментирует...

> Мол, сначала успешный инженер, затем успешный менеджер. Как будто "менеджер" -- это уже человек совсем другого сорта, более высокого качества, чем инженер.

может менеджеры так и думают, не знаю

у меня мотивация слегка другого плана -- научившись что-то делать, мне это делать уже не интересно

думаю и у многих так

хочется перейти к более объемной вещи

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

eao197 комментирует...

@имя:

а в чем проявляется ее тяжесть?

Ну сразу в голову приходят две вещи:

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

Во-вторых, менеджерам ебут мозг с двух сторон -- начальство со сроками, бюджетами и ответственностью с одной стороны, ну и разработчики (которые себе на уме и которых мало чего заботит кроме кода и собственного творчества) с другой. Разработчиков же ебут только с одной стороны ;)

а так же есть ли там творческий характер, или это просто следование чуть более сложному алгоримту, чем у секретарши?

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

eao197 комментирует...

@имя:

у меня мотивация слегка другого плана -- научившись что-то делать, мне это делать уже не интересно

думаю и у многих так


У многих. Но для технических спецов в крупных компаниях есть возможности для технического роста. Скажем, Джеймс Гослинг в Sun-е имел какую-то хитрую должность, вовсе не менеджерскую. Как и Страуструп в Bell Labs.

Пусть в менеджеры у нас, к сожалению, считается (а может и является) единственной возможностью карьерного роста.

имя комментирует...

вот уж не думаю, что менеджер виноват за срыв сроков

есть две разные профессии -- скажем, врачи и полководцы

врачи должны работать по алгоритму; если пациент умер -- они не виноваты, если работали правильно

и есть полководцы -- где победителей не судят, а проигравшие почти всегда идут на понижение (за исключением случая нас "10, их 30")

так вот, менеджеры -- врачи; но еще должен быть главный менеджер-полководец

имя комментирует...

менеджер-полководец -- это либо собственник, либо че-то типа гендира

имя комментирует...

ну, точнее говоря, "врачи" это "врачи в понимании современной западной медицины", где можно подать на врача в суд (и подают)

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

eao197 комментирует...

@имя:

>вот уж не думаю, что менеджер виноват за срыв сроков

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

имя комментирует...

да, все эти мои разговоры про профессии это предположения, естественно

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

а как бы ты смотрел на набор штук^W человек 3, которые грубо говоря знают только if-for-while, а какие классы сделать, какой алгоритм выбрать, и что прочесть -- это им надо объяснять?

eao197 комментирует...

Опечатка. Вместо Либо подстраховавшись хотел написать либо не подстраховавшись.

имя комментирует...

> Виноват. Устанавливают сроки менеджеры. Либо

дальше в основном идет перечисление нарушений алгоритма (про что я и говорил)

а ведь сроки могут сорваться по более-менее объективной причине

имя комментирует...

а еще сроки могут сорваться и по субъективной, от менеджера не зависящей

имя комментирует...

и сроки по-хорошему должен устанавливать специально обученный оценщик сроков -- тут извините нужна совсем *иная* квалификация, чем для "внезапным вбрасываниям, разборкам, жалобам, капризам", и важность (прибыль/убытки) от такой работы для компании повыше будет, чем разруливать капризы

eao197 комментирует...

@имя:

>а как бы ты смотрел на набор штук^W человек 3, которые грубо говоря знают только if-for-while, а какие классы сделать, какой алгоритм выбрать, и что прочесть -- это им надо объяснять?

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

eao197 комментирует...

@имя:

>и сроки по-хорошему должен устанавливать специально обученный оценщик сроков

Во-первых, это фантастика.

Во-вторых, не суть важно, какими источниками пользуется менеджер для оценки сроков (сам их придумывает, делает интегральную оценку, держит для этого отдельного человека или еще что-то). Он их озвучивает, утвержает и далее несет ответственность. Такова ноша менеджера.

имя комментирует...

все это больше санта-барбару напоминает, чем производство

возьми опять же человека со знанием while-if-for и пусть он возьмется за написание большой проги чисто самостоятельно

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

т.е. ответственность и "взятие" квалификацию не заменят

а у того, у кого квалификация есть -- тому вряд ли интересно разруливать капризы

имя комментирует...

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

eao197 комментирует...

@имя:

>все это больше санта-барбару напоминает, чем производство

При чем здесь Санта-Барбара? Работа менеджера заключается в общении с людьми, а люди -- это не винтики в шестеренках, они внимания и участия требуют. И уважения, и признания. И много еще чего.

>а у того, у кого квалификация есть -- тому вряд ли интересно разруливать капризы

Вот!!! В самую точку. В этом и суть перехода из инженера в менеджеры. Как инженер ты занимаешься кодом, отвечаешь за код, работаешь с кодом. А когда ты менеджер, ты уже не кодом занимаешься, а людьми. И если тебе не интересно заниматься капризами, то ты инженер и в менеджмент лучше не соваться.

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

eao197 комментирует...

@имя:

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

Тут много моментов. Есть, конечно, задачи, когда отдельные люди разрабатывают алгоритмы и матмодель. Сталкивался с таким, когда за основные вычисления отвечали профессиональные математики, некоторые из которых даже программировать не умели.

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

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

имя комментирует...

я вот че не понимаю:

с чего менеджер должен нести ответственность за сроки, если он не обладает достаточной квалификацией их рассчитать?

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

eao197 комментирует...

@имя:

Ну, во-первых, нет выбора "или-или". Менеджер занимается и тем, и другим :)

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

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

Все это делает менеджер, поскольку руководство и заказчика конкретные конечные исполнители не интересуют.

имя комментирует...

> Ну, во-первых, нет выбора "или-или". Менеджер занимается и тем, и другим :)

вот я и говорю -- санта-барбара

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

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

имя комментирует...

а еще пусть программист-уборщик программировать не умеет или умеет, но плохо

но ему и не надо уметь программировать -- программу пишут другие, и ему дают уже готовую

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

eao197 комментирует...

@имя:

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

имя комментирует...

> Я не понял, как этот поток сарказма соотносится с кругом задач

что же, придется выступить в роли К.О.

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

круг задач при исполнении проекта широк, и включает в т.ч., да, влажную уборку помещений

и человек, ответственный за проект вовсе не обязан исполнять все эти задачи самостоятельно

дальше уже не речь К.О.

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

единственное, что у меня получилось -- так это вариант "сроки состовляются исходя из не полностью записанных представлений о том, чем является задача; разруливание капризов является явным выражением этой не полностью записанной части"

но мне это кажется неубедительным; я по-прежнему придерживаюсь мнения, что ответственность менеджера за сроки это санта-барбара, если не сказать цирк

однако, есть один момент -- критиковать имеющееся часто проще, чем предложить лучший вариант

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

имя комментирует...

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

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

eao197 комментирует...

@имя:

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

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

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

И таки если вспомнить Ашманова и его советы менеджерам проектов -- кто там отвечает и контролирует сроки?

имя комментирует...

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

он обрисовал себя как нормального разработчика, оказавшегося в ситуации цирка, а не какого-то дартаньяна на белом коне

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

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

имя комментирует...

> На мой взгляд, факт "каприза" здесь на лицо. Не важно, каприза заказчика (хочу!) или разработчика (не хочу!).

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

2. разработчик может упираться даже и по делу -- костыль может реально мешать; тут должна быть проведена высококвалифицированная оценка костыльности, потерь от костыля и от спора с заказчиком

имя комментирует...

относительно того что "не предусмотрено" -- это большой вопрос

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

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

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

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

имя комментирует...

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

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

имя комментирует...

причем сразу видно, что эти правила это краткий, утрированный пересказ истории с рамблером

при этом оттуда выкинуты неудобные для менеджеров моменты :-)

eao197 комментирует...

@имя:

>разработчик не должен капризничать; если же он правда капризничает, должна быть специальная девочка по работе с капризами

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

Ну и кроме того, у меня диаметрально противоположное мнение по поводу правил Ашманова для менеджеров (правда, читал я их лет 7 назад, тогда показались мне очень четкими и здравыми, нужно еще раз перечитать).

имя комментирует...

вот, например, одно из правил ашманова

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

зашибись высказывание

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

воздушная кукуруза называемая windows стоит денег, а вот воздушная кукуруза называемая linux продается полностью бесплатно

реально покупаются оба сорта; вдобавок, воздушную кукурузу сорта linux покупают не нищеброды, а весьма обеспеченные люди, в то время как платную воздушную кукурузу сорта windows покупают также (если не сказать в основном) люди с достаточно небольшими доходами

да, у софта уникальной специфики нет, совсем нет...

eao197 комментирует...

@имя:

Ты путаешь производство со способами распространения. Уверяю тебя, что коммерческая разработка софта под Windows принципиально ничем не отличается от таковой под Linux. Это по первому пункту.

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

По крайней мере я понимаю слова Ашманова так. И не вижу в них признаков бреда.

имя комментирует...

> Уверяю тебя, что коммерческая разработка софта под Windows принципиально ничем не отличается от таковой под Linux.

я не сказал "под"

я рассматриваю ОC как софт, и процесс разработки ОС как процесс разработки софта

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

eao197 комментирует...

@имя:

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

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

Не нужно приписывать Ашманову аналогий, которые он не приводит.

имя комментирует...

или ситуация с фаерфоксом

приходит покупатель в автомагазин

-- вот эта машина сколько стоит?

-- бесплатно! оформляем?

-- ой, а тут на дверях реклама, можно я ее потом закрашу?

-- можно!

-- а можно я свою повешу?

-- можно!

-- а можно я эту машину со своей рекламой продам?

-- можно, но тогда сначала уберите нашу лисичку, и еще снимите фирменные надписи Mozilla Firefox; ну так как, оформляем?

имя комментирует...

> Не нужно приписывать Ашманову аналогий, которые он не приводит.

я ему не приписываю аналогий

*он* сказал -- специфики нет -- так что дудки, получите софтовую специфику и распишитесь

как я уже и говорил, его правила годятся только для тупых менеджеров, которым надо объяснять как в детском саду

имя комментирует...

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

но та формулировка, которая на сайте -- это просто детский сад

имя комментирует...

и обсуждать эти "правила ашманова" иначе, как языком сарказма, мне очень трудно

будет человеческая формулировка, а не для детсадовцев -- тогда я по-человечески и обсужу

eao197 комментирует...

@имя:

>*он* сказал -- специфики нет -- так что дудки, получите софтовую специфику и распишитесь

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

И как раз то, что ты не хочешь принять то, что видно с точки зрения бизнеса, как раз очень точно попадает под "что бы там ни говорили сами разработчики".

имя комментирует...

хех :-)

ты типа хочешь сказать, что я смотрю слишком с точки зрения разработчика?

имя комментирует...

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

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

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

eao197 комментирует...

@имя:

>именно, приведи пример отрасли с такой же бизнес-специфичностью, как возможность регулярно выполнять 50% работы бесплатными волонтерами

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

Во-вторых, в той же науке можно наблюдать картину, похожую на Linux: пожертвования крупным исследовательским центрам со временем окупаются сделанными этими центрами открытиями, которые "бесплатно" доступны всему миру.

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

имя комментирует...

2. (будет 1 и 3) наука это совсем другое дело, и, надеюсь, никто не всерьез не заявит что-то вроде "R&D не более особенное, чем пищевая промышленность или косметология"

или мы всерьез хотим обсудить и такой бред?

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

кстати, в его тексте плохо раскрыт один момент -- это физики

они вообще-то, должны были делать R&D на тему поисковых технологий, но вместо этого занялись "общей шиной" (в то время как яндекс похоже как раз успешно делал еще и R&D); если в рамблере был цирк в отношении программеров, то в отношении R&D, похоже, и подавно

eao197 комментирует...

@имя:

>или мы всерьез хотим обсудить и такой бред?

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

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

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

Так что не нужно мне про производством. Ашманов дает советы управленцам.

имя комментирует...

> газеты бесплатных объявлений. Редакции этих газет ничего не платят "поставщикам контента".

стандартно контент для газет поставляют журналисты

журналистика -- это не вообще не отрасль промышленности

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

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

ты привел пример, но он не может быть продолжен до доказательства правоты ашманова, и вот почему:

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

2. допустим даже ты показываешь, что программирование меньше отличается от пищевой промышленности, чем отрасль Х отличается от пищевой промышленности

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

имя комментирует...

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

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

разница в управлении заключена допускаемой управлением степени следования технологическому процессу

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

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

3. в институте... смотря каком и кому

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

R&D где-то между 2 и 3, и политика выбирается руководством

имя комментирует...

насчет линукса -- я почему-то не могу найти источников, и вижу сейчас цифру 30% от не-корпораций

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

имя комментирует...

также есть один существенный момент в разнице руководством творожным заводом и журналистами:

соблюдение технологии на творожном заводе гарантирует правильный результат (творог),

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

имя комментирует...

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

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

имя комментирует...

кандидатский диссер, если утрированно -- это примерно такое доказательство "я сам могу находить че-то-новое в науке, так что все отвалите и перестаньте мной управлять"

так что разница в управлении есть, и еще какая

имя комментирует...

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

прикладных программистов надо было держать в узде (т.е. разрешать микроинструменты, в крайнем случае капризов заказывать мини-инструменты у фрилансеров), а R&D (то бишь физиков) естественно в бОльшей свободе, но требовать от них не "общую шину", а поисковые технологии; общую шину пресекать

короче, мозги нужны, а не советы ашманова

имя комментирует...

"советы ашманова" это цирк, а вот книжка, в которой рассказывается об истории рамблера мне весьма понравилась

еще одна феерическая чушь из советов:

> Программист всегда всеми силами стремится сделать работу наиболее общим способом... Если дать разработчику волю, разработка общей платформы отнимет 100% времени и денег, и продукт никогда не выйдет на рынок.

"в наиболее общем" виде пишут не все и не всегда, бывает как раз наоборот, люди пишут слишком частно

вопрос, в какой степени общности надо писать решается языком программирования -- т.е. именно в той общности, в которой язык это без напрягов поддерживает

ашманов был бы прав, указав, что один из способов провалить проект -- это писать в наиболее общем виде

но его потянуло на неоправданные обобщения -- "всегда всеми силами"

у меня просто нет цензурных слов

Rustam комментирует...

Согласен с тем что Панкратов несет чушь.
Ну вот с тем что программист именно инженер тоже можно поспорить, он скорее среднее между инженером и писателем, вот тут http://rsdn.ru/forum/job/4621613.1.aspx человек в правильном направлении мыслит. Я кстати тоже замечал что мышление при программировании очень похоже на мышление при решении именно геометрических задач.

имя комментирует...

@Rustam насчет писательского укона в программировании полностью согласен, причем и евгений охотников емнип в своих размышлизмах что-то такое писал

имя комментирует...

@eao197

хорошо бы разобраться, что такое управление

если это сидеть в кресле, а иногда выходить на телевидение и рапортовать "идем от победы к победе", то и в самом деле нет разницы, чем и кем руководить

правда, тут есть одна особенность -- у такого руководится все будет падать -- фобос-грунт, белорусский рубль, и т.д.

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

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

имя комментирует...

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

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

можно ли сказать, что такой будильник является твоим руководителем?

и можно ли сказать, что аналогичная будильнику чисто алгоритмическая работа менеджера является руководством?

имя комментирует...

@eao197 (хотя конечно мнение остальных тоже интересно)

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

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

eao197 комментирует...

@имя:

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

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

Не менеджер определяет, какая технология будет использоваться для реализации проекта (хотя может влиять на этот выбор исходя, опять же, из бюджетов). Поэтому не надо вновь и вновь повторять тезисы про разницу технологических процессов в разных областях. Это очевидно. Как очевидно и то, что технические вопросы находятся (должны находиться) в ведении технических специалистов, а не управленцев.

Менеджер отвечает за достижение цели и за обеспечение ее достижения путем обеспечения этого процесса нужными ресурсами.

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

Про роль менеджера в производстве ПО в следующем комментарии.

eao197 комментирует...

Так вот про роль менеджера в производстве ПО.

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

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

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

Скажем, если выбор стоит между техническим решением A (теряем неделю сейчас, потом за три часа долетаем, потом теряем по одному дню в месяц на сопровождение) или B (долетаем сейчас за три дня, потом будем терять по неделе в месяц на сопровождение или две недели на переписывание, но уже после внедрения) менеджер должен обозначить техническому специалисту сроки, риски и приоритеты так, чтобы какой-то из вариантов стал однозначно невыгодным. Ну и только в крайнем случае менеджер может директивно сказать A или B. Но, опять таки, исходя из бизнес-интересов, а не технологических.

eao197 комментирует...

Надеюсь, из этих комментариев становится понятно, почему я разделяю точку зрения Ашманова. И почему считаю, что нельзя на роль менеджера назначить "девочку", которая будет следовать каким-то алгоритмам.

Ну а что до будильника, то временами да -- вот такой вот дотошный будильник и будет лучшей стратегией управления конкретным коллективом в конкретной ситуации. А временами совсем не будет.

eao197 комментирует...

@Rustam:

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

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

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

Тогда как неработающая программа вообще никому не нужна.