Здравствуйте, Garrrrr, Вы писали:
G>Сразу оговорюсь, в данном сообщение слово "раздолбай" надо мысленно подменять синонимичным, но более выпуклым неполиткорректным аналогом, начинающимся на букву "распи" и кончающееся буквой "здяй".
Все нижеследующее, ИМХО, разумеется. Проблема «раздолбайства» заключается в отсутствии у исполнителя хотя бы одного из необходимых и достаточных условий для успешной работы:
1. Понимание целей работы. => Руководитель обязан четко задачу формулировать.
2. Желание ее сделать. => Руководитель должен суметь мотивировать работника на решение данной задачи. Не может — поменять задачу или расстаться с сотрудником.
3. Умение ее делать. => Руководитель должен организовать обучение работника.
4. Возможность ее сделать. => Руководитель обязан обеспечить необходимые условия
Не стоит людей пытаться переделать. Не бывает идеальных солдат. Недостатки – это, как правило, оборотная сторона достоинств. Следует их (достоинства) разглядеть и постараться использовать с максимальной отдачей для общего дела. Судя по Вашему описанию недостатков, коллега в Вашей команде играет роль "генератора идей" и/или "исследователь ресурсов".
У подобных работников имеются следующие недостатки: "парит в облаках", не склонен акцентировать внимание на практических деталях, склонен терять интерес, как только первоначальное очарование проходит, может быть слишком оптимистичен и некритичен. Но нам с ними (недостатками) приходится мириться, поскольку их (работников) несомненными достоинствами является: развитое воображение, интеллект, знания, способность решать трудные проблемы, способность устанавливать контакты с нужными людьми и выявлять новые возможности, способность реагировать на возникающие трудные задачи.
Кратко, суть в том, что, если мы хотим эффективно решать нетривиальную задачу, то нам необходима сбалансированная команда проекта, в которой правильно подобранные «лебедь», «рак» и «щука» могут оказаться гораздо успешнее «родственных душ».
Когда человек не отвечает ни за что — ему не остается ничего другого как быть рас-ем или играть в серьезного товарища самому с собой (зависит от хар-ра воспитания и т.п.)
Но если Антуан Сент-Экзюпери прав — стоит дать рас-ю почувствовать ответственность, внушить ему что он приручил нечто, вполне может быть что он осознает ее в достаточной мере и метаморфоза случится.
Вопрос только в том что и как ему дать: если ресурсы позволяют — вплоть до отдельного "учебного" R&D проекта.
Если важным куском реального проекта рисковать страшно, следует придумать как преподнести кусок, которым рисковать не страшно — суметь представить его жизненно необходимым (т.е. чтобы подопытный поверил). И пусть трудится.
При этом ИМХО стоит начистоту сказать, что мол так и так — будем посмотреть. Чтобы человек понял что расп-во это конечно хорошо, но сейчас не тот случай: мол вся страна за тобой наблюдает, покажи на что способен. Родина не забудет.
Если человек четко видит цель, четко знает что ему за это будет и ему дают возможность справиться (т.е. начальство действительно а не на словах заинтересовано и помогает. или хотя бы не мешает) — то шансы на успех при умении и желании (которые подразумеваются вообще говоря иначе говорить не о чем) будут хорошими.
PS В психологов как панацею особо не верится. Хотя с их мнением несомненно ознакомиться при случае не помешает.
... << RSDN@Home 1.2.0 alpha rev. 648>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Hello Garrrrr,
G> Вообще, по моим наблюдениям, из бывших раздолбаев получаются отличные G> руководятлы. Но вот документальных фактов, подтверждающих это, у мя G> нету, акромя личных наблюдений.
Не факт что это пройдет с этим работником.
Но есть у него несомненная плохая черта — неорганизован и безответственен,
к тому же к работе относится больше как к игре, которая рано или поздно наскучит.
...
иногда по раздолбайской своей натуре напрочь заваливает сроки или случайно
пишет не то
Руководитель должен уметь жестко пресекать на корню не относящуюся к делу
работу. Кто за нее будет платить? Кто будет отвечать за сорванные сроки выполнения
этапов проекта?
Фактически поставив у руля такого человека вы создадите "инкубатор" раздолбаев.
Если не хочется потерять опыт данного специалиста, тогда ему нужно поставить
в нянки хорошего начальника, который будет использовать его хорошие стороны
и вовремя нивелировать "помутнения".
Здравствуйте, Garrrrr, Вы писали:
G>Хотелось спросить людей с опытом — как кто и что в такой ситуации предпринимает (с точки зрения менеджерских решений).
По опыту. Сначала нужно понять, предлагают ли эти люди что-то реально полезное, оценить степень маниловщины и прикинуть, справедлива ли первоначальная оценка их, как разгильдяев. Для этого надо много разговаривать и стараться быть терпеливым (не доставать из кармана свой официальный статус при каждом удобном случае). Неожиданно может оказаться, что они кругом правы.
Далее убрать с критических путей, после чего четко понять, в чем их интерес. Если таковой имеется, постараться найти или придумать полностью автономный "перспективный" проект, отвечающий их интересам, и распределить роли согласно их стремлениям (таким проектом может быть, скажем, что-то полезное для остальных разработчиков типа кастомизации используемой IDE под нужды процесса и пр). Есть ненулевая вероятность, что такой ход откроет их лучшие стороны, и при этом будет польза для остальных. Если не сделают, все равно будет польза от неучастия в основных проектах. Если потери на финансирование этой деятельности навскидку ниже, чем компенсация возможных потерь от участия в основных проектах, то все в порядке. Наконец, постараться посадить их отдельно от основных разработчиков, чтобы свести к минимуму разлагающее влияние.
Подчеркиваю, речь идет именно о гениальных разгильдяях, которых пока не хочется терять, а не о раз****ях-пустышках.
Сразу оговорюсь, в данном сообщение слово "раздолбай" надо мысленно подменять синонимичным, но более выпуклым неполиткорректным аналогом, начинающимся на букву "распи" и кончающееся буквой "здяй".
Рассмотрим проблему сферического раздолбая в программном бизнесе. Он несомненно талантлив, удачлив, быстро сечет в новых и старых фишках, является возможно самым продвинутым в тех. плане человеком в коллективе. Но есть у него несомненная плохая черта — неорганизован и безответственен, к тому же к работе относится больше как к игре, которая рано или поздно наскучит. На своем программистком месте он вполне уместен — иногда пишет ненужный "продвинутый" код, который вызывает смущенные недоуменные улыбки коллег, иногда по раздолбайской своей натуре напрочь заваливает сроки или случайно пишет не то, но добрым советом и пространными дискуссиями в курилке обогащает кругозор коллег и помогает выработать грамотные решения каких-то сферических программистких задач. В общем, человек на своем месте, пользы от него явно больше чем вреда, если бы не эта раздолбайская черточка — разговаривать бы не о чем было.
Но суть была преамбула. А амбула в следующем — приходит этому человечку мысль, что все есть суета сует и вообще надоело. Денег — почти потолок по рынку, авторитет — вроде есть в узких кругах, хочется понимаешь в руксостав как то пробиться. Читает он книжечки по менеджменту, начинает проводить прилюдный анализ рукрешений с исполнительским составом, причем нет бы он на личностях останавливался — типа директор мудаг, а я в белоснежной манишке — нет, он понимаешь своим анализом и ссылками на классиков невзначай, исподтишка _доказывает_, что директор — мудаг, а белоснежные манишки сняли с производства. Короче, тут уже минусы начинают как минимум плюсы уравновешивать. Мало того — на работу то он все больше забивает, а все думает, как бы ему руководятлом заделаться. В ситуация — человек вроде нужный, терять жалко, а продвигать — страшно, потому как цукко раздолбай и смотри выше, проще дятла, но исполнительного и предсказуемого.
Хотелось спросить людей с опытом — как кто и что в такой ситуации предпринимает (с точки зрения менеджерских решений).
ЗЫ: если отвлечься от теоретического базиса и рассмотреть 2 конкретных подопытных — оба устали маяться фигней и ушли сами, не дожидаясь решения руководства. И что характерно — перескочив на желаемую ступеньку показали себя уже отнюдь не раздолбаями с низкими моральными устоями, а вполне инициативными, ответственными и _компетентными_ работниками, пользующимися уважением в руководимых ими коллективами. Метаморфоза, блин.
ЗЗЫ: тока не надо говорить — я бы посмотрел как бы он... Люди неординарные, не так то просто их просчитать.
kittown wrote: > > Мои рекомендации ? Каждый случай слишком индивидуален, смотреть по > ситуации. Смена работы — весьма неплохой выход. Разбивается гордиев > узел накопившихся непростых отношений.
Да, несколько важных пойнтов забыл указать.
Во-1, реальными причинами т.н. разгильдяйства может быть
что угодно — фрустрация, недоверие начальству, недоверие
планам проекта, нереальные сроки.
Плюс недопонимание. Пример: начальник говорит, что проект
надо сделать до даты X, дальше — поздно. У работника помимо
проекта X есть еще и проект Y, и он достоверно знает,
что проект X своевременно сделать нельзя, и если на него
забить и все время потратить на менее приоритетный
проект Y, то он будет выполнен идеально.
Теперь философский вопрос. Нужно ли забить на более
приоритетный проект X, или не нужно ? Если верить словам
менеджмента буквально, то сроки подвинуть нельзя. Что
это значит — что проект в любом случае сдохнет, или
что менеджмент распространяет заведомую дезу и на самом
деле сроки может подвинуть ? Если проект в любом случае
сдохнет, будет ли для работника приемлемым тратить на
него время ?
Допустим, работник поверил словам менеджмента, что после
такой-то даты проект X будет неактуален, и пользуясь
здравым смыслом, решил добить проект Y. А менеджмент
на самом деле "соврал", и проект X мог продолжаться еще
хоть полгода. Раздолбай сотрудник в этом случае или нет ?
Или еще пример. Сотрудник заранее знает, что предлагаемое
решение не подойдет и будет переделано (по техническим или
политическим причинам), но его аргументы не убеждают
начальство. Не в смысле что решение спорное, а в смысле
что оно будет выкинуто целиком со 100% вероятностью.
Сотрудник тратит значительную часть времени на поиск
альтернатив, чтобы предложить их вовремя. Он раздолбай ?
Вообще-то раздолбай. Раздолбай, поскольку не научился
искать общий язык с менеджментом, раздолбай,
потому что занимает не соответствующую своим интересам
должность, и раздолбай, потому что не доволит собственных
навыков до нужного уровня, чтобы подняться в должности.
И еще много раз раздолбай, поскольку своим видимым
хреновым исполнительством портит себе весь фидбек,
раздолбай, поскольку не понимает, что все сотрудники
в одной лодке, и топить начальство — просто глупо.
Пока он с этим всем не разребется так или иначе (или
хотя бы не осознает), то повышать, наверно, не стоит.
K>>Если не хочется потерять опыт данного специалиста, тогда ему нужно поставить K>>в нянки хорошего начальника, который будет использовать его хорошие стороны K>>и вовремя нивелировать "помутнения". G>Сотрудник, действия которого нуждаются в постоянном контроле, плохой сотрудник, и от него надо избавляться.
Не согласен! Еще в советские времена были кураторы, которые помогали встать на ноги.
А что такое куратор, если не контроллер? Очень редко может человек сам пройти все ступеньки карьеры без
посторонней помощи. И если на первых порах ему требуется некоторый присмотр — это далеко не всегда
является признаком плохого сотрудника... "Первая пора" причем всегда разная. Одним нужно сделать один проект
и все — он самостоятельный, а другим — долго надо избавляться от неких страхов.
А как Вы предлагаете — не понравился — на помойку — по-моему это не способ построения команды.
Здравствуйте, kittown, Вы писали:
K>savaDAN wrote: >> >> G>Ок, считаем. 1 программист выдает в среднем 20К строк отлаженного кода >> в год. >> Прошу прощения, что столь наглым образом влезаю в разговор по совсем >> другому вопросу... >> Откуда такая статистика? >> 20 000 строк в год это — 20 000 / ( 11(месяцев) * 22(рабочих дня в >> месяц) * 8(часов в дне) ) = ~10 LOC/H, не слишком ли мало?
K>Я бы сказал, очень неплохо. Там же написано "отлаженного кода". K>Неотлаженного можно написать хоть пару сотен "вроде работающего", K>хоть все четыре "может быть, работающего".
Печатаю слепым методом со скоростью 700 знаков в минуту.
Правда такая чушь получается...
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Но проблема в том, что прграммисты эгоистичны по своей натуре. И человек с большим сердцем рискует тем, что программисты сядут ему на шею. А чуть он начнет закручивать гайки — будут роптать, что он деспот и искать новую работ
А еще программисты любят впадать в крайности хотя не только они.
Здравствуйте, savaDAN, Вы писали:
G>>Ок, считаем. 1 программист выдает в среднем 20К строк отлаженного кода в год. DAN>Прошу прощения, что столь наглым образом влезаю в разговор по совсем другому вопросу... DAN>Откуда такая статистика?
Из проектов CQG + средняя по индустрии по данным Carnegie-Mellon. Они неплохо согласуются.
DAN>20 000 строк в год это — 20 000 / ( 11(месяцев) * 22(рабочих дня в месяц) * 8(часов в дне) ) = ~10 LOC/H, не слишком ли мало?
Во-первых, не на 8, а максимум на 4 (больше программист на непосредственную работу тратить в день не может, если на год усреднить).
Во-вторых, под отлаженным кодом понимается качество кода не хуже "бета" (пригодно к массовому тестированию), что в моем понимании составляет не более 6 оставшихся ошибок на тысячу строк кода. Примерно так.
Здравствуйте, baddev, Вы писали:
B>Дать челу серьёзную задачу за которую он и только он будет в ответе.
И что потом делать, если он с ней случайно справится?
Или тем лучше не справится?
Организуйте скрытое тестирование психологом. На выходе психолог даст вам его сильные стороны. И вот если там будут все или почти все сильные стороны хорошего начальника — попробуйте. Дайте маленькую группу и вперед. Иначе — увольнять. Так такой баламут еще натворит дел
On Wed, 10 May 2006 22:39:39 +0300, Garrrrr <20164@users.rsdn.ru> wrote:
а может раздолбайское отношение ето результат того, щто человек не чутсвует
доверия со сорони руководства, его наверное постоянно пытаютса контролировать,
и он просто не хочет их (вас) "разочаровать" — когож ви тогда бедете
контролировать. если онправильним, станет... или обещания дание руководством
ему не были исполнени, или исполянютса на собственную интерпретацию
руководством, тогода почему вы щитаете што он должен чествовать какуюту
ответственность ?
а уйти — ето наверное вариант ...
кому достанетса талантливый работник, и ответственный, при соответственном
отношении.
Здравствуйте, craft-brother, Вы писали:
CB> CB>1. Понимание целей работы. => Руководитель обязан четко задачу формулировать. CB>2. Желание ее сделать. => Руководитель должен суметь мотивировать работника на решение данной задачи. Не может — поменять задачу или расстаться с сотрудником. CB>3. Умение ее делать. => Руководитель должен организовать обучение работника. CB>4. Возможность ее сделать. => Руководитель обязан обеспечить необходимые условия CB>
+1. Наш человек! .
CB>Рекомендую: Типы ролей в командах менеджеров: Пер. с англ. Белбин Р.М
Здравствуйте, khap, Вы писали:
G>> Вообще, по моим наблюдениям, из бывших раздолбаев получаются отличные K>Руководитель должен уметь жестко пресекать на корню не относящуюся к делу K>работу. Кто за нее будет платить? Кто будет отвечать за сорванные сроки выполнения K>этапов проекта?
K>Фактически поставив у руля такого человека вы создадите "инкубатор" раздолбаев.
Хочется процитировать одного из подопытных — "я сам 5 лет всех нае..л, меня не нае..шь". И в общем, спустя полгода, слова с делом не расходятся т.ч. вопрос весьма спорный.
K>Если не хочется потерять опыт данного специалиста, тогда ему нужно поставить K>в нянки хорошего начальника, который будет использовать его хорошие стороны K>и вовремя нивелировать "помутнения".
Сотрудник, действия которого нуждаются в постоянном контроле, плохой сотрудник, и от него надо избавляться.
Здравствуйте, A.Lokotkov, Вы писали:
AL>Здравствуйте, malkolinge, Вы писали:
M>>... Люди тянутся к тем у кого больше сердце. Если ваш расдолбай более направлен на работу людьми то вполне очевидно что программист из него посредственный. а вот начальник великолепный. Кстати случаи выдвижения на руководящую додлжность ХОРОШОИХ программисто часто оборачивалась крахом
AL>Некоторые люди действительно тянутся к тем, у кого большое сердце. Однако, по моему опыту, плохой специалист, руководящий разработкой, никогда не мог стать настоящим лидером команды хороших специалистов. Даже если при этом у него было "большое средце" и умение руководить процессами в других областях.
Не буду спорить но давайте учтонить в какой именно сфере должен быть руоковдитель компетентен ? разрабатывать лучше разработчиков ? аналтизировать лучше аналитиков ? Или тестировать лучше тестировщиков ?
Здравствуйте, A.Lokotkov, Вы писали:
AL>Здравствуйте, Mikhail Polykovsky, Вы писали:
MP>>А кто в данной схеме принимает решения типа "это мы сделаем сейчас, а это — потом" и "ты иди сделай вот это к этому сроку"?
AL>В контексте руководства проектом -- руководитель проекта или "главный инженер" компании.
Ну вот. А вы ему предлагаете чай программерам подносить
Garrrrr wrote: > > ЗЫ: если отвлечься от теоретического базиса и рассмотреть 2 конкретных > подопытных — оба устали маяться фигней и ушли сами, не дожидаясь решения > руководства. И что характерно — перескочив на желаемую ступеньку > показали себя уже отнюдь не раздолбаями с низкими моральными устоями, а > вполне инициативными, ответственными и _компетентными_ работниками, > пользующимися уважением в руководимых ими коллективами. Метаморфоза, блин.
Третьим буду. За исключением завершающей части фразы — в чем-то лучше,
в чем-то так же. Но в целом с серьезным прогрессом. Возможно, дело все
же в том, что на старом месте прежняя манера работать вошла в привычку,
от которой трудно отказаться без смены места. Кроме того, если столько
времени критиковал людей из руководящего состава, то несколько трудно
представить себя работающим с ними потом рука об руку. Больше того,
с самого начала не было желания с ними вместе работать, поэтому все
возможности роста как-то автоматически неосознанно саботировались,
несмотря на желание вырасти.
Мои рекомендации ? Каждый случай слишком индивидуален, смотреть по
ситуации. Смена работы — весьма неплохой выход. Разбивается гордиев
узел накопившихся непростых отношений.
Здравствуйте, Valery A. Boronin, Вы писали:
VAB>Когда человек не отвечает ни за что — ему не остается ничего другого как быть рас-ем или играть в серьезного товарища самому с собой (зависит от хар-ра воспитания и т.п.)
VAB>Но если Антуан Сент-Экзюпери прав — стоит дать рас-ю почувствовать ответственность, внушить ему что он приручил нечто, вполне может быть что он осознает ее в достаточной мере и метаморфоза случится.
ИМХО — самая краткая и емкая характеристика механизма рас-ва в нашем деле. Великолепно.
VAB>Если важным куском реального проекта рисковать страшно, следует придумать как преподнести кусок, которым рисковать не страшно — суметь представить его жизненно необходимым (т.е. чтобы подопытный поверил). И пусть трудится.
Ну, не вижу ничего страшного в том, чтобы дать реально критичный кусок. Это здорово мотивирует. Ну и в добавок, менеджер — это все-таки не архитектор. А способности последнего (для тим-лида) довольно просто выявляется собеседованием и тестовым заданием. Человек должен видеть, что вы его не обманываете, доверяете ему — по настоящему, без обмана. И никто не мешает взять ситуацию на регулярный контроль — на первое время.
BK>А с другой стороны. Я не могу себе представить экспертов-технарей, архитекторов и программистов, решающих оргвопросы. Особенно на этапе начала проекта. Потом, принцип единоначалия тоже никто не отменял. См. те же правила Ашманова.
Я не предлагаю технарям-экспертам решать оргвопросы. Мне думается, для успеха наверху должен быть аналог Королева, Фон Брауна и т.п. Хотя допускаю, что проекты типа автоматизации бухгалтерии или банковской деятельности можно делать иначе.
G>Вообще, по моим наблюдениям, из бывших раздолбаев получаются отличные руководятлы. Но вот документальных фактов, подтверждающих это, у мя нету, акромя личных наблюдений.
Раздолбай раздолбаю рознь. По моему опыту, существует определенный тип раздолбаев, раздолбайство которых происходит от того, что они не умеют / не любят заниматься рутиной, которой в программистском деле не избежать. Симптомы очень похожи на те, что вы описали. Это, как правило, люди технически подкованные выше среднего, даже в некотором смысле "гуру". Обычно активно генерят идеи, с удовольствием берутся за нестандартные задачи, увлекаются, но быстро остывают — что, собственно, и влечет за собой ненадлежащее выполнение своих обязанностей, которое со стороны выглядит как раздолбайство. Если речь идет о подобном человеке, то не все потеряно. Из таких довольно часто получаются неплохие руководители, во всяком случае, я лично такие истории знаю. В чем тут секрет — хрен знает. Возможно, управление/менеджмент это просто менее рутинная работа и она больше подходит таким людям. Короче говоря, можно попробовать дать такому человеку немного "порулить". Для начала в небольшом и некритичном проекте / участке проекта. Ну и посмотреть что из этого получится.
Здравствуйте, Garrrrr, Вы писали:
G>Хотелось спросить людей с опытом — как кто и что в такой ситуации предпринимает (с точки зрения менеджерских решений).
Либо пригласить в руководство, либо гнать поганой метлой не глядя на все плюсы. Выбор по вкусу и ситуации.
Здравствуйте, SEDEGOFF, Вы писали:
SED>Организуйте скрытое тестирование психологом. На выходе психолог даст вам его сильные стороны. И вот если там будут все или почти все сильные стороны хорошего начальника — попробуйте. Дайте маленькую группу и вперед. Иначе — увольнять. Так такой баламут еще натворит дел
Во-первых, скрытое тестирование одного человека достаточно сложно организовать, не говоря уже о том, что это как бы немного не принято. В нашей стране каждый сам — психолог с мировым уровнем Но даже если оно покажет — вот они, качества, то все равно остается открытым вопрос ярко выраженного раздолбайства, а на вопрос — останется ли эта черта и далее доминирующей — ни один психолог ответа не даст
Вообще, по моим наблюдениям, из бывших раздолбаев получаются отличные руководятлы. Но вот документальных фактов, подтверждающих это, у мя нету, акромя личных наблюдений.
Здравствуйте, Nikolay_Ch, Вы писали:
K>>>Если не хочется потерять опыт данного специалиста, тогда ему нужно поставить K>>>в нянки хорошего начальника, который будет использовать его хорошие стороны K>>>и вовремя нивелировать "помутнения". G>>Сотрудник, действия которого нуждаются в постоянном контроле, плохой сотрудник, и от него надо избавляться. N_C>Не согласен! Еще в советские времена были кураторы, которые помогали встать на ноги. N_C>А что такое куратор, если не контроллер? Очень редко может человек сам пройти все ступеньки карьеры без N_C>посторонней помощи. И если на первых порах ему требуется некоторый присмотр — это далеко не всегда N_C>является признаком плохого сотрудника... "Первая пора" причем всегда разная. Одним нужно сделать один проект N_C>и все — он самостоятельный, а другим — долго надо избавляться от неких страхов. N_C>А как Вы предлагаете — не понравился — на помойку — по-моему это не способ построения команды.
Молодой человек, "няньки" и "первая пора" — немного разные понятия. Помощь советом на первой поре необходима всем, но ежели человек нуждается в няньке, а именно — в постоянном, неусыпном контроле — то тогда фтопку иго!
G>Молодой человек, "няньки" и "первая пора" — немного разные понятия. Помощь советом на первой поре необходима всем, но ежели человек нуждается в няньке, а именно — в постоянном, неусыпном контроле — то тогда фтопку иго!
Интересно, насколько Вы "старый" , что я для Вас — "молодой"?
А если по теме, то тут говорилось о том, что дать проект ему и проверить выполнение.
По необходимости прописать "куратора" — по-моему нормальный подход.
Думаю, что его пропагандируют именно те, кто сам прошел через школу кураторства.
А вот те, кого просто бросали как котят в воду и которые сами выплывали, видимо
считают, что человек сам кузнец своего счастья и должен всего добиваться сам.
Какой подход лучше — не мне решать.
А высказывание khap'а мне кажется больше походит на то, что для любого сотрудника
начальник является в некотором роде нянькой. И пресекания некоторых действий
подчиненных со стороны начальника — входит в круг его (начальника) обязанностей.
Здравствуйте, malkolinge, Вы писали:
M>Люди просто наши себя. Видите ли. Никто и никогда не будет следовать за Вами только потому .. что вы умнее или сильнее. Люди тянутся к тем у кого больше сердце.
еще вспомните про большие почки без которых в России на руководящих постах никуда
M>Если ваш расдолбай более направлен на работу людьми то вполне очевидно что программист из него посредственный. а вот начальник великолепный.
по-моему не очевидно. если бы Вы написали возможно или может быть не согласиться было бы трудно
M>Кстати случаи выдвижения на руководящую додлжность ХОРОШОИХ программисто часто оборачивалась крахом
несомненно. равно как и случаи выдвижения не ХОРОШИХ. это всего лишь вопрос к психологам, почему человеку запоминается плохое в первую очередь. впрочем можно и самому догадаться без психологов. нужно не вспоминать случаи (которые как всегда найдутся по любому поводу — было б желание), а приводить тогда уж статистику по идее...
... << RSDN@Home 1.2.0 alpha rev. 648>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, malkolinge, Вы писали:
M>Не буду спорить но давайте учтонить в какой именно сфере должен быть руоковдитель компетентен ? разрабатывать лучше разработчиков ? аналтизировать лучше аналитиков ? Или тестировать лучше тестировщиков ?
Я не говорил, что он должен быть лучше. Задачи руководителя разработки (среди прочего): подобрать команду, спланировать и распределить работу, контролировать выполнение и, главное, принимать решения.
По-моему мнению, руководитель, не являющийся техническим специалистом, не сможет выполнить вышеназванные задачи. Причины:
1. Для подбора команды руководитель должен знать и уметь оценивать людей с психологической и технической точек зрения. Оценка с технической точки зрения предполагает наличие у руководителя некоторого технического уровня. В противном случае он должен полагаться на т.н. "экспертов".
2. Для планирования необходимо понимать, что и как нужно делать. Грамотный руководитель-неспециалист вынужден отдавать планирование в команду, т.е. опять положиться на экспертов.
3. Контроль выполнения предполагает понимание того, что делается, в чем суть возникающих проблем и каким техническим решениям нужно отдавать предпочтение при разногласиях в команде. Руководитель, не вкуривающий в происходящее, не сможет ничего контролировать.
С принятием решений совсем беда, поскольку руководитель-неспециалист по сути только утверждает то или иное решение тех самых экспертов, на которых ему приходится полагаться во всех технических вопросах. При этом случаются весьма экзотические критерии, по которым отдается предпочтение тому или иному решению.
Фактически концептуальную целостность и результат разработки обеспечивает "инженер проекта" или "главный архитектор", который является специалистом широкого профиля по определению.
Здравствуйте, malkolinge, Вы писали:
M>Вы назвали много правильных вещей но вывод не правильный
Не вижу ни одного аргумента против, одна лирика.
M>Руководитель дейсвительно набирает команду. Для этого у него должно быть определнное чутье.Зверинное чутье. И хорошие експерты. (тут правда возникает задача по типу курицы и яйца, а именно что было раньше)
Ну? И как решить проблему курицы и яйца? Как пеньку-манагеру понять, хорошие у него эксперты или нет? Звериннным чутьем и наукой доверять?
M>Согласитесь набрать команду, чтобы потом ей не доверять ? назвать своих ребят "эксперами", причем в кавычках ? В общем есть у вас тяга к садомазохизму. На самом деле все просто, нужно уметь доверять. Это наука а определить что проект движется не туда куда надо можно без всякого технического опыта
В кавычках про экспертов сказано по причине того, что обозначена вспомогательная роль, придуманная господами-идеологами от науки "управления чем-угодно". А своих ребят я тут не упомянал.
Здравствуйте, Max.Subpixel, Вы писали:
MS>Здравствуйте, Garrrrr, Вы писали:
G>>Хотелось спросить людей с опытом — как кто и что в такой ситуации предпринимает (с точки зрения менеджерских решений).
MS>Либо пригласить в руководство, либо гнать поганой метлой не глядя на все плюсы. Выбор по вкусу и ситуации.
Казнить нельзя помиловать
запятые по вкусу
G>СВ ситуация — человек вроде нужный, терять жалко, а продвигать — страшно, потому как цукко раздолбай и смотри выше, проще дятла, но исполнительного и предсказуемого.
Продвигать можно и нужно, но обычно бывает некуда, поскольку места уже заняты дятлами. Поэтому конфликт разрастается вплоть до логической развязки.
Garrrrr wrote: > > Молодой человек, "няньки" и "первая пора" — немного разные понятия. > Помощь советом на первой поре необходима всем, но ежели человек > нуждается в няньке, а именно — в постоянном, неусыпном контроле — то > тогда фтопку иго!
По-моему, вы обсуждаете слишком абстрактного кадра. А что если этот
кадр с приставленной нянькой будет давать эффективность за пятерых ?
Что, если у него с нервами бардак, но благодаря своей нервозности под
руководством няньки он найдет тучу недостатков в процессе и продукте,
которые иначе потребовали бы многих недель тестирования ? Которые
без няньки просто всех взбесили бы, а с нянькой были бы представлены
в виде приличных баг-репортов и прочих отчетов ?
Ясно, что это нетипичные случаи, но с категоричностью вы погорячились.
Mikhail
Posted via RSDN NNTP Server 2.1 beta
Re[3]: Проблема карьерного роста раздолбаев
От:
Аноним
Дата:
12.05.06 08:19
Оценка:
G>Во-первых, скрытое тестирование одного человека достаточно сложно организовать
Тебе ж не скрытую диспансеризацию с обязательной ректоскопией предлагают провести... А тестирование психологом! Это ж совсем другое!
Hello Garrrrr,
K>>>> Если не хочется потерять опыт данного специалиста, тогда ему нужно K>>>> поставить в нянки хорошего начальника, который будет использовать K>>>> его хорошие стороны и вовремя нивелировать "помутнения".
G>>> Сотрудник, действия которого нуждаются в постоянном контроле, G>>> плохой сотрудник, и от него надо избавляться.
N_C>>Не согласен! Еще в советские времена были кураторы, которые помогали
встать на ноги. N_C>>А что такое куратор, если не контроллер? Очень редко может человек сам
пройти все ступеньки карьеры без N_C>>посторонней помощи. И если на первых порах ему требуется некоторый присмотр
— это далеко не всегда N_C>>является признаком плохого сотрудника... "Первая пора" причем всегда
разная. Одним нужно сделать один проект N_C>>и все — он самостоятельный, а другим — долго надо избавляться от неких
страхов. N_C>>А как Вы предлагаете — не понравился — на помойку — по-моему
это не способ построения команды.
G> Молодой человек, "няньки" и "первая пора" — немного разные понятия. G> Помощь советом на первой поре необходима всем, но ежели человек G> нуждается в няньке, а именно — в постоянном, неусыпном контроле — то G> тогда фтопку иго!
Я не зря отметил
вовремя нивелировать
. Предполагается не ставить
его на "премодерирование", а выразить доверие в руководстве. Но с некоторым
контролем "как дела", "какие проблемы" и т.п. Если вдруг оказывается что
он отклонился от "генеральной линии партии", только тогда необходимо
дать совет (рекоменадцию) или отдать распоряжение о том как нужно правильно
поступить, в зависимости от отклонения, частоты таких советов и т.п.
Интересно, а вопрос управления проектом с личной финансовой ответственностью бюджета/сроков не решит проблемы. Классическая менеджеровская практика. Небольшой зарплат + проектный бонус. Т.наз. проценты от продаж.
Согласится взять на себя ответственность (если ему дадут право рулить в пределах бюджета) — молодец. Не согласится — ну извини мужик....
Re[9]: Проблема карьерного роста раздолбаев
От:
Аноним
Дата:
23.05.06 06:40
Оценка:
Здравствуйте, Bor-ka, Вы писали:
BK>Интересно, а вопрос управления проектом с личной финансовой ответственностью бюджета/сроков не решит проблемы. Классическая менеджеровская практика. Небольшой зарплат + проектный бонус. Т.наз. проценты от продаж.
BK>Согласится взять на себя ответственность (если ему дадут право рулить в пределах бюджета) — молодец. Не согласится — ну извини мужик....
А мне кажется,что таких людей лучше выставить в качестве эксперта. Первым делом на большом собрании похвалить, сказать при всем коллективе, что у нас есть весьма заслуженный коллега, которому присуждается звание эксперта. После чего объявить, что все решения (архитектурные, программерские) будут проходить экспертную оценку. Во-первых, тем самым простимулируете человека и поставите его на ступеньку выше остальных !!!
Я думаю — это нужно сделать из-за того, что если уж таким людям в голову пришла мысль по управлять и что они практически снизошли до господа-бога, то нужно дать им эту возможность поуправлять! а в друг у них все качественно получится.
Еще одним психологическим барьером является сам менеджер, которому данный человек подчиняется. Каждый хочет сохранить свое насиженное место, но реально посмотрите правде в глаза — Есть и всегда будут люди лучше Вас!! Никогда не нужно забывать такую простую истину и всегда нужно уступать и признавать свои ошибки и некомпетентность, но не задывать, что люди которые против Вас настроены и живут в коллективе в конечном итоге настроят весь коллектив против Вас.
Эксперт это хорошо. Только чтобы не получилось, что это номинальный эксперт, типа нашей "общественной палаты", которые дают экспертные заключения, но ни за что не отвечают.
Ещё раз подчеркну свою мысль. Полномочия (в том числе и "порулить") должны быть очень жёстко завязаны с ответственностью. Для обучения рулить можно чем-то игрушечным (внутренний проект компании), и с игрушечной ответственностью (твоя личная премия, испытательный срок для повышения и т.п.).
Люди просто наши себя. Видите ли. Никто и никогда не будет следовать за Вами только потому .. что вы умнее или сильнее. Люди тянутся к тем у кого больше сердце. Если ваш расдолбай более направлен на работу людьми то вполне очевидно что программист из него посредственный. а вот начальник великолепный. Кстати случаи выдвижения на руководящую додлжность ХОРОШОИХ программисто часто оборачивалась крахом
M>Люди просто наши себя. Видите ли. Никто и никогда не будет следовать за Вами только потому .. что вы умнее или сильнее. Люди тянутся к тем у кого больше сердце. Если ваш расдолбай более направлен на работу людьми то вполне очевидно что программист из него посредственный. а вот начальник великолепный.
Но проблема в том, что прграммисты эгоистичны по своей натуре. И человек с большим сердцем рискует тем, что программисты сядут ему на шею. А чуть он начнет закручивать гайки — будут роптать, что он деспот и искать новую работу.
Здравствуйте, malkolinge, Вы писали:
M>... Люди тянутся к тем у кого больше сердце. Если ваш расдолбай более направлен на работу людьми то вполне очевидно что программист из него посредственный. а вот начальник великолепный. Кстати случаи выдвижения на руководящую додлжность ХОРОШОИХ программисто часто оборачивалась крахом
Некоторые люди действительно тянутся к тем, у кого большое сердце. Однако, по моему опыту, плохой специалист, руководящий разработкой, никогда не мог стать настоящим лидером команды хороших специалистов. Даже если при этом у него было "большое средце" и умение руководить процессами в других областях.
Здравствуйте, Valery A. Boronin, Вы писали:
VAB>Здравствуйте, malkolinge, Вы писали:
M>>Люди просто наши себя. Видите ли. Никто и никогда не будет следовать за Вами только потому .. что вы умнее или сильнее. Люди тянутся к тем у кого больше сердце. VAB>еще вспомните про большие почки без которых в России на руководящих постах никуда
Намека не понял, намекайте дальше
M>>Если ваш расдолбай более направлен на работу людьми то вполне очевидно что программист из него посредственный. а вот начальник великолепный. VAB>по-моему не очевидно. если бы Вы написали возможно или может быть не согласиться было бы трудно
виноват именно так и хотел сказать
M>>Кстати случаи выдвижения на руководящую додлжность ХОРОШОИХ программисто часто оборачивалась крахом VAB>несомненно. равно как и случаи выдвижения не ХОРОШИХ. это всего лишь вопрос к психологам, почему человеку запоминается плохое в первую очередь. впрочем можно и самому догадаться без психологов. нужно не вспоминать случаи (которые как всегда найдутся по любому поводу — было б желание), а приводить тогда уж статистику по идее...
Кстати если уж об этом говорить..ТО человек как раз запоминает лучше хорошее или только я такой
Да и еще. учитывая специфику ПМства каким бы крутым девелоперов вы бы не были..квалификацию как разработчика вы потеряете ( кроме случаев когда на проекте аж 1-3 человека)
Здравствуйте, malkolinge, Вы писали:
M>>>Люди просто наши себя. Видите ли. Никто и никогда не будет следовать за Вами только потому .. что вы умнее или сильнее. Люди тянутся к тем у кого больше сердце. VAB>>еще вспомните про большие почки без которых в России на руководящих постах никуда M>Намека не понял, намекайте дальше
не обращайте внимания, была попытка убавить серьезность сообщения и не более
M>>>Если ваш расдолбай более направлен на работу людьми то вполне очевидно что программист из него посредственный. а вот начальник великолепный. VAB>>по-моему не очевидно. если бы Вы написали возможно или может быть не согласиться было бы трудно M>виноват именно так и хотел сказать
ok, просто как программисту нравится точность в формулировках
M>>>Кстати случаи выдвижения на руководящую додлжность ХОРОШОИХ программисто часто оборачивалась крахом VAB>>несомненно. равно как и случаи выдвижения не ХОРОШИХ. это всего лишь вопрос к психологам, почему человеку запоминается плохое в первую очередь. впрочем можно и самому догадаться без психологов. нужно не вспоминать случаи (которые как всегда найдутся по любому поводу — было б желание), а приводить тогда уж статистику по идее...
M>Кстати если уж об этом говорить..ТО человек как раз запоминает лучше хорошее или только я такой
похоже Вы такой
просто посмотрите что происходит в СМИ: давят именно на плохое (достаточно пробежать глазами горячие новости — убийства, захваты, аферы, террористы и т.п.), а не на хорошее и этому есть вполне серьезные основания подтвержденные сотнями диссертаций в соответствующих областях, насколько я знаю... так что именно что плохое человеку в память откладывается лучше — природой так устроено, инстинкты самосохранения вероятно учавствует или еще что-то похожее
M>Да и еще. учитывая специфику ПМства каким бы крутым девелоперов вы бы не были..квалификацию как разработчика вы потеряете ( кроме случаев когда на проекте аж 1-3 человека)
я бы сказал что до 5-6 скажем еще можно справиться попытаться.
просто потому что седьмым делом будет собственная деятельность, а человек как известно редко в памяти в кэше может держать более чем 7 каких-то вещей\дел одновременно.
... << RSDN@Home 1.2.0 alpha rev. 648>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Вы назвали много правильных вещей но вывод не правильный
Руководитель дейсвительно набирает команду. Для этого у него должно быть определнное чутье.Зверинное чутье. И хорошие експерты. (тут правда возникает задача по типу курицы и яйца, а именно что было раньше)
Согласитесь набрать команду, чтобы потом ей не доверять ? назвать своих ребят "эксперами", причем в кавычках ? В общем есть у вас тяга к садомазохизму. На самом деле все просто, нужно уметь доверять. Это наука а определить что проект движется не туда куда надо можно без всякого технического опыта
НО технический бекграунд конечно же очень хорошое подспорье. Очень.
Что же касается принятия решений то это из опереры разрешения конфликтов. Но это другая песня, заведите отдельную ветку подискуссируем
CB>Мне кажется из студента-недоучки Билли Г. получился даже очень не плохой руководитель.
Кто сказал, что БГ не был специалистом в области программирования? Кто сказал, что он когда-либо непосредственно руководил процессом разработки и программистами? Лу Герстнер, вообще не имел никакого отношения к информационным технологиям, когда заступил на пост главы IBM, но это не помешало ему вытащить компанию из ж. При этом он вообще не занимался руководством разработкой. А вот, к примеру, Стив Джобс и другие менеджеры из Епыл постоянно совали свой нос в дела разработчиков и пытались руководить процессом. В результате компания несколько раз была на грани развала.
У меня есть некая аксиома и я буду её думать. А аксиома такая: основные добродетели менеджера — это правильно передать задачу (из этого следует подбор команды, управление) и вовремя решить т.наз. политический вопрос, который все боятся трогать (то есть в нужный момент прервать демократию и сказать "будет так то", с полной ответственностью за решение).
Менеджер, делающий оценку проекта... Ааа... Для этого есть аналитики, архитекторы. COCOMO, опять-таки. Вот из оценки сделать бюджет, понять, будем ли мы играть по-максимуму или по-минимуму, это уже его дело. Но делать оценку — увольте.
У "играющего" менеджера есть один очень большой соблаз, прогнать всех нафиг и сделать самому трудную часть. При этом управление проектом собственно откладывается, и проект летит кувырком. К сожалению, я такое видел на предыдущей работе у субконтракторов. 3 аналитика + 5 программистов + 2 тестера + техписатель. И вот менеджер взял на себя роль архитектора сложной части. Брр...
А то, что все описывали, это роль тим-лидера. Стопроцентная.
Другое дело, что в маленьком проекте очень часто менеджер == тим-лидер == архитектор. Иногда ещё и аналитик. И это, возможно, правильно, если его может сверху подстраховать топ-менеджер именно в административных вопросах. Но не надо всё это смешивать.
P.S. А Билл Гейтс — гениальный менеджер. И то, что он, возможно, никакой программист (не держал свечку, не знаю), ничуть ему не мешает в этом.
A.Lokotkov wrote: > > M>Вы назвали много правильных вещей но вывод не правильный > > Не вижу ни одного аргумента против, одна лирика.
У вас действительно имеет место аксиома, что менеджер должен
разбираться в деталях проекта. На самом деле вовсе нет. Он
может быть вынужден разбираться, если не может положиться
на экспертов, или если кастомерами проекта являются
технари (менеджер должен разговаривать на языке
кастомеров и их потребностей).
В общем, за минимальную необходимую техническую компетенцию
менеджера при наличии хороших экспертов можно взять
предполагаемую техническую же компетенцию кастомера.
> M>Руководитель дейсвительно набирает команду. Для этого у него должно > быть определнное чутье.Зверинное чутье. И хорошие експерты. (тут правда > возникает задача по типу курицы и яйца, а именно что было раньше) > > Ну? И как решить проблему курицы и яйца? Как пеньку-манагеру понять, > хорошие у него эксперты или нет? Звериннным чутьем и наукой доверять?
По результатам их работы (сбываемость оценок), по отзывам, по
бекграунду. Если менеджер-технарь, то ему оценить адекватность
экспертов ничуть не легче, а может быть даже труднее, т.к.
легко спутать компетентность исполнителя-программиста,
способного написать код, с компетентностью эксперта,
способного код оценить.
Для примера. Глядя на один старый участок кода программист
скажет, что данный участок системы очень крив и его надо
переписать.
Эксперт скажет, что участок может быть улучшен с примерно
такими-то плюсами, а в текущем состоянии будет вполне
приемлем тогда-то и тогда-то и если этого достаточно,
то ее переписывать не надо (мысль, совершенно чуждая
простым программистам). В то же время, если потребуется
регулярно вносить изменения в данный участок, то все
же порекомендует его переписать для снижения
трудоемкости изменений и тестирования.
> В кавычках про экспертов сказано по причине того, что обозначена > вспомогательная роль, придуманная господами-идеологами от науки > "управления чем-угодно". А *своих* ребят я тут не упомянал.
В реальных проектах, где есть и эксперты, и менеджеры-бывшие
эксперты, наблюдал полную загрузку и тех, и других. Причем
квалификация "бывшего эксперта" на задачи менеджера влияла
мало. Помогать — помогала, но только ввиду недостаточности
штата экспертов (которых регулярно теребят "обычные"
разработчики по техническим вопросам).
Ваше сообщение оставляет впечатление, что вы описываете
ситуацию, когда работы на их всех не хватит. Могу успокоить,
с лихвой хватит и еще останется.
Мы несколько отклонились от изначальной темы разговора "что делать с гениальными раздолбаями?", поскольку сей вопрос делится на два:
1. Как отличить просто раздолбая от раздолбая гениального?
2. Какие действия предпринять в отношении гениального раздолбая?
Главный вопрос здесь первый, и решить его в состоянии менеджер, который может объективно понять, гениален ли раздолбай.
В своих сообщениях в этом топике я вел речь о роли руководителя разработки (тимлиде, инженере проекта, главном архитекторе... как угодно).
По моим наблюдениям роль руководителя или администратора проекта сводится только к обеспечению внешнего интерфейса проекта (общение с заказчиками, верхним менеджментом компании и менеджерами смежных проектов), а также к логистике (грубо говоря, распорядиться починить кондиционер, сбегать за пивом для разработчиков и т.п). Т.е. в отношении команды разработчиков он никаких действий предпринимать не может и не должен. С другой стороны, сами разработчики не считают менеджера проекта своим руководителем, поскольку он фактически не руководит их повседневной деятельностью в проекте.
A.Lokotkov wrote: > > В своих сообщениях в этом топике я вел речь о роли руководителя > разработки (тимлиде, инженере проекта, главном архитекторе... как угодно).
Тимлид и главный архитектор — разные люди.
Серху имеет место менеджер проекта. Занимается вопросами, касающимися
всего проекта вообще.
Под ним — менеджеры подпроектов, несколько десятков целовек на каждый.
Занимаются вопросами, специфичными для проектов, организацией работы
каждого подпроекта.
Под ними — на одном уровне — эксперты, архитекторы, и тимлидеры.
Под тимлидерами уже сидят программисты (3-10 человек на тимлида).
> По моим наблюдениям роль руководителя или администратора проекта > сводится только к обеспечению внешнего интерфейса проекта (общение с > заказчиками, верхним менеджментом компании и менеджерами смежных > проектов),
Безусловно. Но только руководителя, а не администратора.
> а также к логистике (грубо говоря, распорядиться починить > кондиционер, сбегать за пивом для разработчиков и т.п). Т.е. в отношении
А вот это уже администратор.
> команды *разработчиков* он никаких действий предпринимать не может и не > должен. С другой стороны, сами разработчики не считают менеджера проекта
Он должен предпринимать действия в отношении своих непосредственных
подчиненных.
> своим руководителем, поскольку он фактически не руководит их > повседневной деятельностью в проекте.
Вы о проектах какого размера говорите ? Если там полсотни человек
нет, то да, многие роли совмещаются одними и теми же людьми. Если
же проект большой, то все разносится по отдельным человекам, и
никакого "просто руководителя" нет. Есть глава проекта, есть
непосредственный начальник, есть много других людей.
Здравствуйте, Mikhail Polykovsky, Вы писали:
AL>>По моим наблюдениям роль руководителя или администратора проекта сводится только к обеспечению внешнего интерфейса проекта
MP>А кто в данной схеме принимает решения типа "это мы сделаем сейчас, а это — потом" и "ты иди сделай вот это к этому сроку"?
Зависит от самого вопроса. Если это вопрос по порядку кодирования классов — то тимлид, или даже сам программист. Если же это относится к функциональности или не дай бог к срокам — то только вместе с менеджером проекта (который отвечает за проект, за бюджет и за принятие проекта заказчиком).
Здравствуйте, Mikhail Polykovsky, Вы писали:
MP>А кто в данной схеме принимает решения типа "это мы сделаем сейчас, а это — потом" и "ты иди сделай вот это к этому сроку"?
В контексте руководства разработкой -- технический руководитель. В контексте руководства проектом -- руководитель проекта или "главный инженер" компании. На уровне руководства компанией -- технический или генеральный директор.
Здравствуйте, A.Lokotkov, Вы писали:
AL>Мы несколько отклонились от изначальной темы разговора "что делать с гениальными раздолбаями?", поскольку сей вопрос делится на два:
AL>1. Как отличить просто раздолбая от раздолбая гениального?
Может вспомнить старые "идеологические правила", что критерием теории является практика. И вот просто сесть и спокойно попробовать выписать на бумажку, мол этот раздолбай придумал раз-два-три решения, которые сэкономили XXX сумму, а вот здесь ликвидировал отставание в проекте на две недели и обеспечил его принятие заказчиком. А по результатам бумажки и думать.
Есть ещё опция, некоторые люди являются как бы катализаторми жизни команды, прямых "бонусов" от них нет. Но в данном случае, похоже, это не так.
AL>2. Какие действия предпринять в отношении гениального раздолбая?
Зависит от п.1. Назначить главным архитектором, или наоборот экспертом (это для катализатора, который может разрулить сложные вещи, но не может чётко структурировать в голове картину). Или выгнать.
Здравствуйте, kittown, Вы писали:
K>Вы о проектах какого размера говорите ? Если там полсотни человек K>нет, то да, многие роли совмещаются одними и теми же людьми. Если K>же проект большой, то все разносится по отдельным человекам, и K>никакого "просто руководителя" нет. Есть глава проекта, есть K>непосредственный начальник, есть много других людей.
То, о чем Вы говорите, примерно теми же словами излагается в многочисленной матчасти (Рассел Арчибальд с его "Управлением высокотехнологичными проектами..." -- один из примеров). Основная мысль: создание иерархии команд, в которой менеджер проекта руководит не разработкой, а командой менеджеров, руководящих разработкой по направлениям.
Я говорю о проектах, с которыми сталкивался -- суммарно не более 20-ти исполнителей из разных областей (программирование, железо, тестирование, испытания и пр.). Проекты бОльшего размера мне изначально подозрительны. Кроме того, моя критика прежде всего нацелена на попытки верхнего руководства компаний сразу строить иерархию команд и делать проект большим искусственно независимо от его реального размера. Например, сразу назначается менеджер-пенёк, который собирает кучу экспертов из разных областей и т.д. В результате оказывается, что количество народа в проекте выросло до немыслимых размеров, а людей, реально занимающихся делом, "полтора калеки".
AL>..... Например, сразу назначается менеджер-пенёк, который собирает кучу экспертов из разных областей и т.д. В результате оказывается, что количество народа в проекте выросло до немыслимых размеров, а людей, реально занимающихся делом, "полтора калеки".
А с другой стороны. Я не могу себе представить экспертов-технарей, архитекторов и программистов, решающих оргвопросы. Особенно на этапе начала проекта. Потом, принцип единоначалия тоже никто не отменял. См. те же правила Ашманова.
Здравствуйте, A.Lokotkov, Вы писали:
BK>>А с другой стороны. Я не могу себе представить экспертов-технарей, архитекторов и программистов, решающих оргвопросы. Особенно на этапе начала проекта. Потом, принцип единоначалия тоже никто не отменял. См. те же правила Ашманова.
AL>Я не предлагаю технарям-экспертам решать оргвопросы. Мне думается, для успеха наверху должен быть аналог Королева, Фон Брауна и т.п. Хотя допускаю, что проекты типа автоматизации бухгалтерии или банковской деятельности можно делать иначе.
Для успеха должна быть пара. Генератор "безумной идеи" плюс менеджер "ноги и локти для этой идеи". А они уже раскрутят всё дело. Если не будет кого-то одного, то перекос :/
Да, кстати, разработка коробочного продукта и заказная разработка систем несколько разные направления. Может в этом и дело. Для заказной разработки, особенно корпоративных систем, особые "прорывы" не нужны, а местами даже вредны. И наоборот.
A.Lokotkov wrote: > > Здравствуйте, kittown, Вы писали: > > То, о чем Вы говорите, примерно теми же словами излагается в > многочисленной матчасти (Рассел Арчибальд с его "Управлением > высокотехнологичными проектами..." -- один из примеров). Основная мысль: > создание иерархии команд, в которой менеджер проекта руководит не > разработкой, а командой менеджеров, руководящих разработкой по направлениям.
Именно.
> Я говорю о проектах, с которыми сталкивался -- суммарно не более 20-ти > исполнителей из разных областей (программирование, железо, тестирование, > испытания и пр.). Проекты бОльшего размера мне изначально подозрительны.
С моей стороны — 20 исполнителей в одной области на одном мини-проекте,
рядом еще 20 в той же области, но на другом. Плюс балласт в виде совсем
зеленых ньюкамеров.
Возьмите всех ваших исполнителей и добавьте каждому еще пяток
специалистов в той же области и найдите достаточно работы для
всех. Тогда будет похоже.
Это все из серии "промышленное программирование" — когда нет одного,
тем более прикладного, приложения, а есть здоровенный
аппаратно-программный комплекс. В случае application development-а
в команду из 20 человек я поверить могу, но случае аппаратно-программных
монстров — могу поверить только в разработку первых версий. Долгосрочная
рутинная поддержка и развитие требуют существенно большего количества рук.
> Кроме того, моя критика прежде всего нацелена на попытки верхнего > руководства компаний сразу строить иерархию команд и делать проект > большим искусственно независимо от его реального размера. Например, > сразу назначается менеджер-пенёк, который собирает кучу экспертов из > разных областей и т.д. В результате оказывается, что количество народа в > проекте выросло до немыслимых размеров, а людей, реально занимающихся > делом, "полтора калеки".
Осмысленность такого мероприятия зависит от компетенции всех участвующих
сторон и от того, чем собралась управлять вся эта толпа. Если внешними
связями, то смысл может быть (или не быть), а если теми самыми
"полтора калеки", то я с вами согласен.
Здравствуйте, Bor-ka, Вы писали:
BK>Здравствуйте, Mikhail Polykovsky, Вы писали:
AL>>>По моим наблюдениям роль руководителя или администратора проекта сводится только к обеспечению внешнего интерфейса проекта
MP>>А кто в данной схеме принимает решения типа "это мы сделаем сейчас, а это — потом" и "ты иди сделай вот это к этому сроку"?
BK>Зависит от самого вопроса. Если это вопрос по порядку кодирования классов — то тимлид, или даже сам программист. Если же это относится к функциональности или не дай бог к срокам — то только вместе с менеджером проекта (который отвечает за проект, за бюджет и за принятие проекта заказчиком).
Ну вот. Я к тому и веду, что проектом руководит (решает, что собственно делать) менеджер проекта. А чай пусть секретарша носит.
А ещё есть такое слово. Продукт = программа (30%) + ещё-что-то (70%). Догадайтесь, что
И вот руководить разработкой программы может (и должен, наверное) тимлид. А вот проектом в целом (то есть продуктом) именно менеджер. И для него совершенно необязательно быть высококлассным девелопером.
Ибо у микрософта отличные продукты (чего не всегда скажешь о программах). А в юникс-мире чаще всего только программы, местами отличные. Но очень мало продуктов.
Наверное я сам когда-то был таким ра...ем. Сейчас уже точно могу сказать — по неграмотности. Скажу больше неграмотно был организован процесс в 3х!!! конторах + отсутствие авторитетов. Точнее процесса этого почти и не было. Как только я попал в сильную команду (с авторитетными людьми) и отработал в небольшом XP проекте от начала до конца (2 мес.), рас...яй сразу кончился... Не хватало какого-то небольшого, но важного опыта, а как только показали как надо работать — дела резко пошли в гору.
Здравствуйте, Joker6413, Вы писали:
J>Здравствуйте, Garrrrr, Вы писали:
J>Наверное я сам когда-то был таким ра...ем. Сейчас уже точно могу сказать — по неграмотности. Скажу больше неграмотно был организован процесс в 3х!!! конторах + отсутствие авторитетов. Точнее процесса этого почти и не было. Как только я попал в сильную команду (с авторитетными людьми) и отработал в небольшом XP проекте от начала до конца (2 мес.), рас...яй сразу кончился... Не хватало какого-то небольшого, но важного опыта, а как только показали как надо работать — дела резко пошли в гору.
"Тут зритель воскликнет: "Здесь вся в чярном свете.
Ведь есть у тузов и молодцы сыновья".
Дружок, я вся знаю.
Я сам, брат, из зтих"
Абсолютно с вами согласен... Та же ситуация + отсутствие объединяющей идеи и _ответсвтвенности_ за свои действия.
Здравствуйте, A.Lokotkov, Вы писали:
AL>То, о чем Вы говорите, примерно теми же словами излагается в многочисленной матчасти (Рассел Арчибальд с его "Управлением высокотехнологичными проектами..." -- один из примеров). Основная мысль: создание иерархии команд, в которой менеджер проекта руководит не разработкой, а командой менеджеров, руководящих разработкой по направлениям.
Давненько я не читал свежей матчасти . Не дадите полноценных ссылок — по высокотехнологичным проектам?
AL>Я говорю о проектах, с которыми сталкивался -- суммарно не более 20-ти исполнителей из разных областей (программирование, железо, тестирование, испытания и пр.). Проекты бОльшего размера мне изначально подозрительны.
Ок, считаем. 1 программист выдает в среднем 20К строк отлаженного кода в год. 20 исполнителей — 400К строк кода в год. Имеем — проект в 3 миллиона строк кода (бывают такие, не такая уж большая редкость) мы делаем примерно 7 лет. Что неприемлемо. Что делать будем? Т.е. в чем именно вы подозреваете проекты большего размера?
AL> Кроме того, моя критика прежде всего нацелена на попытки верхнего руководства компаний сразу строить иерархию команд и делать проект большим искусственно независимо от его реального размера.
Да бог с ним, с верхним руководством. Оно подвергается негативному естественному отбору, вместе со своими компаниями и продуктами. Давайте лучше я, как положено тупому менеджеру-пеньку, немного потуплю и позанудствую. Вы уверены, что знаете, как правильно подходить к разработке проекта размером миллина эдак в три срок кода? Когда этакое чудо в голове одного человека уместится в принципе не может? Возьмете на себя смелость определить "реальный размер" подобных проектов?
AL> Например, сразу назначается менеджер-пенёк, который собирает кучу экспертов из разных областей и т.д. В результате оказывается, что количество народа в проекте выросло до немыслимых размеров, а людей, реально занимающихся делом, "полтора калеки".
Особенно прикольно наблюдать, как в таких же пеньков превращаются вполне толковые программисты, когда им проектами управлять дают.
G>Ок, считаем. 1 программист выдает в среднем 20К строк отлаженного кода в год.
Прошу прощения, что столь наглым образом влезаю в разговор по совсем другому вопросу...
Откуда такая статистика?
20 000 строк в год это — 20 000 / ( 11(месяцев) * 22(рабочих дня в месяц) * 8(часов в дне) ) = ~10 LOC/H, не слишком ли мало?
Здравствуйте, Gaperton, Вы писали:
G>Давненько я не читал свежей матчасти . Не дадите полноценных ссылок — по высокотехнологичным проектам?
Управление высокотехнологичными программами и проектами
AL>>Я говорю о проектах, с которыми сталкивался -- суммарно не более 20-ти исполнителей из разных областей (программирование, железо, тестирование, испытания и пр.). Проекты бОльшего размера мне изначально подозрительны.
G>Ок, считаем. 1 программист выдает в среднем 20К строк отлаженного кода в год. 20 исполнителей — 400К строк кода в год. Имеем — проект в 3 миллиона строк кода (бывают такие, не такая уж большая редкость) мы делаем примерно 7 лет. Что неприемлемо. Что делать будем? Т.е. в чем именно вы подозреваете проекты большего размера?
Я сказал 20 из разных областей, не только программистов. Подозрения возникают в случае, если проект бОльшего размера не разбивается на подпроекты мЕньшего размера. Проект в миллионы строк, которые нужно написать с нуля, не пользуясь ранее имеющимися наработками, в области встраиваемых систем -- редкость и, на мой взгляд, заведомый провал.
Статистика проектов, в которых я участвовал, и которые успешно завершились: 25 SLOC/день "системного" кода на Си, 150-200 SLOC/день фронт-энд средств на Java при общем объеме около 60000 SLOC/год на Си и 180000-220000 SLOC/год на Java.
G>Да бог с ним, с верхним руководством. Оно подвергается негативному естественному отбору, вместе со своими компаниями и продуктами. Давайте лучше я, как положено тупому менеджеру-пеньку, немного потуплю и позанудствую. Вы уверены, что знаете, как правильно подходить к разработке проекта размером миллина эдак в три срок кода? Когда этакое чудо в голове одного человека уместится в принципе не может? Возьмете на себя смелость определить "реальный размер" подобных проектов?
Я точно знаю, что близко не подойду к проекту в 3 MSLOC, ибо, если оценка верна, это не проект, а мешок проектов. Либо кто-то кого-то пытается развести на деньги.
savaDAN wrote: > > G>Ок, считаем. 1 программист выдает в среднем 20К строк отлаженного кода > в год. > Прошу прощения, что столь наглым образом влезаю в разговор по совсем > другому вопросу... > Откуда такая статистика? > 20 000 строк в год это — 20 000 / ( 11(месяцев) * 22(рабочих дня в > месяц) * 8(часов в дне) ) = ~10 LOC/H, не слишком ли мало?
Я бы сказал, очень неплохо. Там же написано "отлаженного кода".
Неотлаженного можно написать хоть пару сотен "вроде работающего",
хоть все четыре "может быть, работающего".
ps. Шаблонный код, для которого можно в принципе написать
кодогенератор, считаем за пару строк в час вне зависимости
от реального обьема.
Mikhail
Posted via RSDN NNTP Server 2.1 beta
Re[3]: Проблема карьерного роста раздолбаев
От:
Аноним
Дата:
03.06.06 12:13
Оценка:
Здравствуйте, Garrrrr, Вы писали:
G>Здравствуйте, Joker6413, Вы писали:
J>>Здравствуйте, Garrrrr, Вы писали:
J>>Наверное я сам когда-то был таким ра...ем. Сейчас уже точно могу сказать — по неграмотности. Скажу больше неграмотно был организован процесс в 3х!!! конторах + отсутствие авторитетов. Точнее процесса этого почти и не было. Как только я попал в сильную команду (с авторитетными людьми) и отработал в небольшом XP проекте от начала до конца (2 мес.), рас...яй сразу кончился... Не хватало какого-то небольшого, но важного опыта, а как только показали как надо работать — дела резко пошли в гору. G>"Тут зритель воскликнет: "Здесь вся в чярном свете. G>Ведь есть у тузов и молодцы сыновья". G>Дружок, я вся знаю. G>Я сам, брат, из зтих" G>Абсолютно с вами согласен... Та же ситуация + отсутствие объединяющей идеи и _ответсвтвенности_ за свои действия.
Коллеги, я чуть не утонул в ваших обсуждениях. А не пробовали учить пипл, в том числе и процесным вещам. Вон на главной странице и банер SEP крутится и инфа по проге есть. Можно долго "жевать" про начальство, но где же "учиться, учиться, учитья"?! Лично я знаю тех ребят, которые делают эту программу — есть резон в том, что они предлагают. Хотя, многие не созрели платить за знания.
Здравствуйте, Garrrrr, Вы писали:
G>Сразу оговорюсь, в данном сообщение слово "раздолбай" надо мысленно подменять синонимичным, но более выпуклым неполиткорректным аналогом, начинающимся на букву "распи" и кончающееся буквой "здяй".
Дать челу серьёзную задачу за которую он и только он будет в ответе.
Что мне понравилось в этом посте , так это ориентированеи на здоровое выполнение довольно ясной цели.
А именно эффективной работы колектива для выполнения некоей поставленной зада (технической в данном случае)
В изначальном же посте подтекст можно было прочесть примерно такой .
"как бы мне приструнить этого выскочку который может еще и на мое место метит" , я специально не стал коментировать первоначальный пост, дабы не вдаваться в конфронтации.
Я не скажу сказать что это недостойная задача (в целом довольно творческая), я к тому чтобы четко формулировать задачи.
Здравствуйте, Joker6413, Вы писали:
J>Здравствуйте, Garrrrr, Вы писали:
J>Наверное я сам когда-то был таким ра...ем. Сейчас уже точно могу сказать — по неграмотности. Скажу больше неграмотно был организован процесс в 3х!!! конторах + отсутствие авторитетов. Точнее процесса этого почти и не было. Как только я попал в сильную команду (с авторитетными людьми) и отработал в небольшом XP проекте от начала до конца (2 мес.), рас...яй сразу кончился... Не хватало какого-то небольшого, но важного опыта, а как только показали как надо работать — дела резко пошли в гору.
Так поделитесь плиз ! что делать ? (кто виноват , интересует меньше)
— по-моему это не способ построения команды.
.
без которых в России на руководящих постах никуда 
