Здравствуйте, bkat, Вы писали:
M>>Если руководитель не знает что делает в данную минуту каждый член его команды , он группой не руководит.
B>Хм... B>То, что о чем ты говоришь — это не эффективное управление, B>а тотальный контроль. Нафиг нафиг такие методы .
согласен, это совковые методы...
M>Я имею ввиду "управление == координация" а не "управление == контроль". M>Попробуйте вспомнить наиболее продуктивные моменты своей лучшей командной работы , скорее всего работа велась малой группой.
если работа продуктивно ведется только в малой группе — это явный признак что менеджер никуда не годный, гнать таких в шею надо...
а если в моде еще и тотальная слежка, тотальный контроль, а в качестве стимулов — шантаж, угрозы и т.п. — это уж вообще признак типичного совкового психа, от таких бежать надо...
кровавая гебня вобщем
Тот кто говорит не знает, тот кто знает не говорит.
Здравствуйте, Soon in Europe, Вы писали:
M_E>>4. Предоставлять планы и их выполнение руководству кампании SIE>И гордиться этим безумно! Пионерия какая-то...
"план выполнен на 190%"
"в следующем месяце планирую удвоить план"
"изделие успешно поразило цель"
"служу совецкому союзу"
совок, однозначно совок...
Тот кто говорит не знает, тот кто знает не говорит.
M_E>Отвечу и на это — врать им резона нет никакого. И возможности тоже нет никакой — все люди сидят в одной очень большой комнате, M_E>так что я всегда вижу и знаю кто чем занимается. Кроме того, я очень хорошо знаю каждого из них, знаю их индивидуальные особенности,
ууууу... вы случаем при советах не на оборонку работали?
не удивлюсь если у вас есть "полезная" привычка каждые 5 минут ходить за спинами у сотрудников и заглядывать в дисплей из-за спины...
P.S.: имхо в вашем коллективе похоже идеальные условия стимулирования вранья...
Тот кто говорит не знает, тот кто знает не говорит.
SM>1. Большое количество багов раз все сидят в одной комнате. Не верите поинтересуйтесь, как работают корректоры. Работа программистов во многом на эту работу похоже. Поэтому одна большая комната тождественна много багов.
согласен, много народу в комнате == низкая производительность (реальная)
SM>2. Исходя из того что сказано скорее всего большая проблема с повышением квалификации, скорее всего люди ощущают дискомфорт, что то же приводит к увеличению багов.
100% ощущают дискомфорт, это однозначно наследие совка...
сюда добавить явное осознание каждым сотрудником что за ним постоянно следят -> психологический климат в глубокой ....
Тот кто говорит не знает, тот кто знает не говорит.
Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>2. (более серъезная) в нашем городе почти все разработчики либо занимаются 1С, либо уже работают у нас, либо уехали в Москву; так что предложение о том, чтобы сразу нанять профессионалов неприменимо.
потому и уехали что условия такие, щас не совок и под пушкой у виска работать не заставишь...
Тот кто говорит не знает, тот кто знает не говорит.
Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>2. Давно работающие люди, которые со скрипом привыкают к изменениям в их обычной работе. M_E>Они думают, что им стали меньше доверять, иногда что за ними хотят следить и т.п.
Да они не думают что им стали меньше доверять, они просто ОКОНЧАТЕЛЬНО ПОНЯЛИ ЧТО ИМ НЕ ДОВЕРЯЮТ! и не доверяют не из-за ошибочного шага, а не доверяют просто безосновательно!
окончательно поняли что следят за ними отнюдь не случайно... Причем заметье они делают совершенно
правильные выводы — вы действительно им не доверяете (судя по вашим постам) и следите за ними...
M_E>Или даже разработчики — они могут писать по строке в день, а на следующий день написать 1000 строк, но ведь это не значит что предыдущий день они не работали. Мне пока как-то более привычно оперировать трудозатратами выраженными в человеко-часах.
как все запущено...
человекочасы в области разработки ПО это миф, почитайте литературу...
предлагаю такие подходы:
1. Строить открытые отношения — без обмана, без хитростей, без лукавства, как бы это не скрывалось — всеравно хорошо чувствуется и настраивает людей против вас
2. Ни в коем случае не шпионить за людьми, не ходить "за чаем" мимо людей, попутно "незаметно" заглядывая через спину — это опятьже остро негативно воспринимается, но врядли вам об этом скажут...
3. Доверять людям, в том числе и доверять ответственность за выполнение какойто части работы — это хороший стимул...
Осмелюсь предположить что вы плохо разбираетесь в области программирования и часто возникает ситуация, когда вы боитесь признать что чегото не знаете, упорно скрывая это психологическим давлением и увиливанием, отсюда и все беды...
Тот кто говорит не знает, тот кто знает не говорит.
Здравствуйте, Streamer1, Вы писали:
S>предлагаю такие подходы:
S>1. Строить открытые отношения — без обмана, без хитростей, без лукавства, как бы это не скрывалось — всеравно хорошо чувствуется и настраивает людей против вас S>2. Ни в коем случае не шпионить за людьми, не ходить "за чаем" мимо людей, попутно "незаметно" заглядывая через спину — это опятьже остро негативно воспринимается, но врядли вам об этом скажут... S>3. Доверять людям, в том числе и доверять ответственность за выполнение какойто части работы — это хороший стимул...
S>Осмелюсь предположить что вы плохо разбираетесь в области программирования и часто возникает ситуация, когда вы боитесь признать что чегото не знаете, упорно скрывая это психологическим давлением и увиливанием, отсюда и все беды...
Мил человек, ты не занимайся подменой предмета дискусии.
Речь идет о методиках мониторинга состояния выполнения по некому текущенму проекту.
Предложенные тобой тезисы — мало того, что напрочь лишены конкретики, так еще и совершенно не относятся к теме.
Нежные отношения между менеджментом и исполнителями, хоть и являются приятным бенефитом, тем не менее совершенно не нужны для внедрения четкой и эффективной системы мониторинга статуса работ.
Вот давай по сути.
Человек предложил схему решения задачи: еждневные отчеты участников комманды о времени затраченныом в течение дня на те или иные задачи. Эта тривиальная методика, при всем ее несовершенстве, достаточно эффективно используется в индустрии, и неплохо работает, особенно на небольших проектах. Она проста как льдинка, и дешева с точки срения затрачиваемых ресурсов. Да, при усложнении проектов, увеличении числа вовлеченного персонала и схем взаимодействия внтури проектов рекоммендуется применять более мощные методики и схемы конторля, но на средних проектов — то что надо.
Что ты имеешь против? Почему такого рода отчестность должна каким-то образом ограничивать совбоды и творческий порыв участников комманды? Как ты предлагаешь осуществлять контороль за выполнением? Или ты полагаешь что контороль и мониторинг вообще не нужен и водоворот анархии внутри проекта сам вынесет на поверхность готовое решение, при чем в срок?
Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>На счет оценки строк кода — мне это кажется довольно спорным
Опять же оценка в человеко-часах — крайне субъективна, зависима от осуществляющего оценку участника проекта, сильно подвержена ошибкам.
Несмотря на некую неочевидность на первый взгляд этого факта — с объемом работать удобнее и надежнее чем со временем. Оснаовые причины:
1. планирование на основе объема — достовернее (я объясню почему)
2. мониторинг выходного объема — дает более ясную картину чем мониторинг затраченных часов.
Что касается планирования на основе объема.
Как бы удивительно это не звучало, но средняя по индустрии производительность, измеряемая как количество строк кода написанных разработчиком за единицу времени — величина удивительно стабильная. Это подтверждают исследования, проводимые как SEI так и у нас в компании(речь о CQG).
Таким образом, имея достаточно достоверную величину производительности, и оценив объем некой задачи в строках кода (путем итерационной декомпозиции: задача -> классы -> методы -> строки) вы можете получить удивительно точный прогноз по времени выполнения.
Если же подсчет выходного объема в строках вызывает стойкое отвращение — попробуйте воспользоваться более высокоуровневыми инженерными абстракциями, такими как функциональные элементы. Прогнозируйте количество классов, методов, етк...
Ну а если есть необходимость оставаться в рамках классического субъективного планирования "на глаз", то могу порекомендовать увеличить количество этих самых глаз. Например, пусть оценку задачи делают два-три независимых участника, и уже на основе нескольких независимых оценок — выводите среднюю.
M_E>Или даже разработчики — они могут писать по строке в день, а на следующий день написать 1000 строк, но ведь это не значит что предыдущий день они не работали.
Повторюсь — производительность разработчика — величина удивительно стабильная в штатной ситуации. Если же у вас возникают подобные скачки — от 1 строки до 1000 — то это говорит о том что разработка носит непредсказуемый характер, о том что существуют неучтенные риски и отсутствует активность по управлению этими рисками. По ходу — это еще один бенефит от оценки объема работ — вы можете строить производную процента выполнения, оценивая скорость прироста функционала, и таким образом совевременно инициировать активность по стабилизации ситуации в случае, когда характер этой производной неадекватен.
Здравствуйте, Slick, Вы писали:
S>Вот давай по сути. S>Человек предложил схему решения задачи: еждневные отчеты участников комманды о времени затраченныом в течение дня на те или иные задачи. Эта тривиальная методика, при всем ее несовершенстве, достаточно эффективно используется в индустрии, и неплохо работает, особенно на небольших проектах. Она проста как льдинка, и дешева с точки срения затрачиваемых ресурсов. Да, при усложнении проектов, увеличении числа вовлеченного персонала и схем взаимодействия внтури проектов рекоммендуется применять более мощные методики и схемы конторля, но на средних проектов — то что надо.
ежедневные отчеты — это признак "полного завала проекта"
S>Что ты имеешь против? Почему такого рода отчестность должна каким-то образом ограничивать совбоды и творческий порыв участников комманды? Как ты предлагаешь осуществлять контороль за выполнением? Или ты полагаешь что контороль и мониторинг вообще не нужен и водоворот анархии внутри проекта сам вынесет на поверхность готовое решение, при чем в срок?
Вот основные негодные способы наведения порядка, с которыми сталкивался практически всякий, кто работал в неудачных проектах или несчастливых компаниях.
Контроль посещаемости
Первое, что приходит в голову боссу при личном обдумывании причин торможения или провала — что работники просто бездельничают.
— Менеджер проекта сам программист (вариант — сам не программист), вот и распустил их. Ясно, что нужно их просто тщательнее контролировать. Я сам этим займусь.
Начинаются мероприятия по контролю посещаемости. Охранник на входе получает приказ всех записывать, сисадминам чрез голову технического директора дают команду подобрать и установить систему контроля рабочих мест. Появляется предписанный шаблон объяснительной записки, босс или кадровик грозно встречает всех поутру при входе, проводится промывание мозгов опоздавшим и т. п.
Персонал ропщет в столовой, самые отчаянные угрожают в курилке увольнением. Ползут слухи об увольнениях. Программисты начинают демонстративно уходить домой в шесть вечера. Научиться приходить в десять утра у многих так и не получается.
Волна контроля посещаемости иссякает примерно через одну-две недели, максимум месяц.
Контроль количества работы
Далее светлая мысль начальства достигает самой сути: нужно контролировать даже не рабочее время, а количество работы! Возникает смелый план заставить программистов вечером каждого дня (вариант — по пятницам) записывать, что сделано, и тут же "одной кнопкой" отправлять запись в некую общую систему.
Обычно, к счастью, этот ежедневный вариант контроля не удается даже внедрить. Сопротивление разумной части коллектива оказывается слишком велико.
Пятничные отчеты начинают писаться (руководитель проекта упросил всех поддаться), но их перестают читать наверху через пару недель, а писать внизу — через месяц-полтора.
....
Приведу бородатый анекдот на эту тему:
PM сказал: Хватит разврата! С завтрашнего дня все приходят на работу в 9 и уходят в 6.
Программеры начали дико возмущаться, по конторе поползли слухи об увольнениях, начали разрабатыватся планы бойкота, самые активные начали увольняться.
Тогда PM сказал: Хватит разврата! Можете приходить когда угодно, но чтобы проект был сдан в срок.
Программеры вздохнули с облегчением и стали приходить на работу в обед и уходить с рассветом.
Тот кто говорит не знает, тот кто знает не говорит.
Здравствуйте, Slick, Вы писали:
S>Опять же оценка в человеко-часах — крайне субъективна, зависима от осуществляющего оценку участника проекта, сильно подвержена ошибкам.
S>Несмотря на некую неочевидность на первый взгляд этого факта — с объемом работать удобнее и надежнее чем со временем. Оснаовые причины: S>1. планирование на основе объема — достовернее (я объясню почему) S>2. мониторинг выходного объема — дает более ясную картину чем мониторинг затраченных часов.
уж сколько на эту тему бумаги на литературу изведено, так нет же, все равно находятся люди которые считают что умнее всех...
читайте Эдвард Йордан "«Смертельный марш» Полное руководство для разработчика программного обеспечения по выживанию в безнадежных проектах"
Prentice Hall, 1997, ISBN 0-13-748310-4, есть русский перевод
цитата:
Если контрпредложение со стороны высшего руководства или заказчика содержит только одну «переменную», менеджер проекта может оценить влияние остальных переменных. Например, если первоначальная оценка менеджера проекта заключается в том, что проект потребует 12 месяцев на реализацию, трех разработчиков и бюджет 200.000$, вполне вероятно, что первой реакцией руководства будет: «Вздор! Нам нужно, чтобы система была готова и работала через шесть месяцев!» На первый взгляд, очевидный способ сделать это заключается в увеличении штата и/или бюджета (например, увеличить зарплату, чтобы привлечь более продуктивных программистов).
С другой стороны, Фред Брукс уже более 20 лет назад отмечал, что зависимость между количеством разработчиков и временем разработки носит нелинейный характер; поэтому термин «человеко-месяц» был объявлен мифом. Разумеется, практически все зависимости между ключевыми переменными проекта являются нелинейными и зависящими от времени. Вследствие эффекта «обратной связи», возникающего в результате многих решений руководства, изменение одной переменной (например, увеличение штата) повлияет со временем не только на другие переменные (такие, как продуктивность), но и на собственное первоначальное значение — например, увеличение штата может отрицательно повлиять на моральное состояние команды, что, в свою очередь, может увеличить текучесть рабочей силы в проекте и в конечном счете снизить численность персонала.
Тот кто говорит не знает, тот кто знает не говорит.
Здравствуйте, Streamer1, Вы писали:
S>Здравствуйте, bkat, Вы писали:
M>>>Если руководитель не знает что делает в данную минуту каждый член его команды , он группой не руководит.
B>>Хм... B>>То, что о чем ты говоришь — это не эффективное управление, B>>а тотальный контроль. Нафиг нафиг такие методы .
S>согласен, это совковые методы...
M>>Я имею ввиду "управление == координация" а не "управление == контроль". M>>Попробуйте вспомнить наиболее продуктивные моменты своей лучшей командной работы , скорее всего работа велась малой группой.
S>если работа продуктивно ведется только в малой группе — это явный признак что менеджер никуда не годный, гнать таких в шею надо...
S>а если в моде еще и тотальная слежка, тотальный контроль, а в качестве стимулов — шантаж, угрозы и т.п. — это уж вообще признак типичного совкового психа, от таких бежать надо...
S>кровавая гебня вобщем
Какоето жестокое непонимание , я говорю о структкризации об эфективности взаимодействия , а вы мне про тотальную слежку ??? какое одно имеет к другому отношение ?
Могу привести как пример ситуацию когда врывается с криком руководитель не мледшего звена с криками , да вы чем тут 2 недели занимались , да это все нафик не надо , надо делать другое и т.п.
Вот об этом я и говорю , руководитель этот предстает как нгекомпетентный , так как у него 2 недели люди занимались тем что не стоило делать , а он даже не пытался выяснить так ли это или нет.
M>Какоето жестокое непонимание , я говорю о структкризации об эфективности взаимодействия , а вы мне про тотальную слежку ??? какое одно имеет к другому отношение ?
почитайте другие посты этого человека, там явно просматривается гебистские наклонности этого человека, в сочетании с непониманием "почему же они думают что за ними хотят следить и ограничивать?"...
M>Могу привести как пример ситуацию когда врывается с криком руководитель не мледшего звена с криками , да вы чем тут 2 недели занимались , да это все нафик не надо , надо делать другое и т.п.
M>Вот об этом я и говорю , руководитель этот предстает как нгекомпетентный , так как у него 2 недели люди занимались тем что не стоило делать , а он даже не пытался выяснить так ли это или нет.
ктож ему виноват что он не пытался выяснить так ли это или нет, другое дело что выяснять можно достойными методами, а методами не шпионством, угрозами и т.п.
я полностью согласен с тем что менеджер должен быть в курсе того в каком направлении двигается коллектив, но (!) профессионализм менеджера в том и заключается чтобы быть в курсе без использования гнилых методов, нарушающих этические нормы, за которые принято просто "мочить в сортире"
Тот кто говорит не знает, тот кто знает не говорит.
Здравствуйте, minorlogic, Вы писали:
M>Вы мне опять про "гнилые методы" и т.п. ... Вероятно у Вас какието проблемы были с этим связанные , хотите поговорить об этом ?
у моего знакомого нечто подобное... я про методы угнетения и подавления, а не про структуризацию...
Тот кто говорит не знает, тот кто знает не говорит.
По поводу работы по ночам — лично я считаю это более вредным, чем полезным.
Разработчик может сидеть до середины ночи и зачекинить такое, что не будет правильно работать.
Тогда команде с утра придется либо ждать его прихода, пока он выспится, либо самим разбираться в том, что он ночью написал и
пытаться устранить ошибку.
Второй момент (более общего плана) — нарушение взаимодействий в команде. Если один человек пришел с утра, а второго нет, и работа первого зависит от второго, то получаем потерю времени.
В общем я против этого и мне пришлось прекратить такую практику более года назад
Ну по поводу 1-1000 строк — это я утрировал, конечно
Но ведь действительно, многие члены команды вообще не пишут код.
Их работу как-то надо планировать и отслеживать
Можно, конечно, использовать кол-во найденных ошибок для тестировщиков.
Надо подумать об этом, я пока не пришел к конечному мнению.
