В небольшой команде программистов (<10 человек) уже используется таск менеджмент система, позволяющая просто ставить задачки, асайнить их и т.п. (аля багзила). Однако хочется повысить уровень самоконтроля. Есть идея ввести следующую процедуру:
Каждый составляет свой план работ на месяц и неделю и каждую неделю записывает что он сделал за эту неделю, информацию можно для простоты хранить в wiki. Кроме того каждый будет видеть что делали другие, что является мотивирующим фактором.
Вот еще как вариант можно использовать XPlanner: Допустим каждый составляет себе на неделю собственную итерацию куда вписывает все стори которые будет делать и там же отмечает прогресс
Здравствуйте, Ed.Nixon, Вы писали:
EN>В небольшой команде программистов (<10 человек) уже используется таск менеджмент система, позволяющая просто ставить задачки, асайнить их и т.п. (аля багзила). Однако хочется повысить уровень самоконтроля. Есть идея ввести следующую процедуру: EN>Каждый составляет свой план работ на месяц и неделю и каждую неделю записывает что он сделал за эту неделю, информацию можно для простоты хранить в wiki. Кроме того каждый будет видеть что делали другие, что является мотивирующим фактором.
Не понял, что каждый девелопер сам на себя планы пишет?
А что PM тогда делает?
А вообще, переодическая отчестность вещь полезная.
Как вы ее техничести оформите (wiki/не wiki) вещь вообще десятая.
У нас к примеру раз в неделю проводится собрание команды,
на котором каждый должен рассказать что планировалось сделать, что сделано,
что еще предстоит и какие есть проблемы.
PM по ходу делает пометки, задает вопросы и делает свой отчет для начальства выше.
В общем форма такой отчетности вещь не принципиальная.
Важно, чтобы она была.
EN>Что думаете господа PMы?
Предлагаемое вами средство, надо сказать не популярное.
А вообще мой совет такой (мой, потому как использовал). Разбейтесь в группы по 3 человека. В каждой группе назначтьте ведущего программиста. РМ общается по планам только с ведущими и им задает направление работы. Так же от них получает план работы его группы. Что делает ведущий программист — он составляет план работы для своей команды. Плюсом является то, что исполнителю не нужно заморачиваться с этими планами — за него это делает другой. Ну а так как у ведущего программиста достаточно опыта, то он способен оценить временнные затраты на задачи. В результате исполнителю нужно проставлять только проценты выполнения. Плюс к этому, если ввести сохранение базового плана, то вы сможете оценивать способность к планировани ведущих спецов и их компетентность.
Конечно, это может показаться бюракратией. Но с другой стороны. Лучше научить 3 человек делать короткие планы и одного долгосрочные, чем всех 10 учить планировать.
Здравствуйте, Ed.Nixon, Вы писали:
EN>В небольшой команде программистов (<10 человек) уже используется таск менеджмент система, позволяющая просто ставить задачки, асайнить их и т.п. (аля багзила). Однако хочется повысить уровень самоконтроля. Есть идея ввести следующую процедуру: EN>Каждый составляет свой план работ на месяц и неделю и каждую неделю записывает что он сделал за эту неделю, информацию можно для простоты хранить в wiki. Кроме того каждый будет видеть что делали другие, что является мотивирующим фактором.
Как практику могу предложить несколько иной подход.
Задачи для разработчиком должен определять как раз PM (PM-ом в контексте данного вопроса называем совмещённую должность Project Manager-а и Lead Programmer-а, разбирающегося в технической части задачи). Непосредственно разработчики должны подтверждать планируемое время исполнения поставленных задач или устанавливать собственное время, согласуемое с PM. Т.е. задачи разработчику ставится PM-ом (такой подход позволяет поддерживать согласованность общего плана), а время согласуется с разработчиком (для увеличения реалистичности плана и увеличения ответственности разработчика за свою временную оценку). Тогда у вас согласованные и реалистичные планы.
Если хотите прозрачности — публикуйте для всех сводный календарный план.
Что касается отчётности, то в данном случае она заключается в ежедневной (или в выбранный в вашем конкретном случае периоде) публикации разработчиками факта выполнения планируемой задачи и отклонений от графика, при анализе которых вы сможете корректировать общий календарный план.
При этом необходимость в wiki отпадает. Самоконтроль появляется, когда разработчик публикует расхождение факта с планом (сообщая, фактически об этом PM-у).
Здравствуйте, Ed.Nixon, Вы писали:
EN>В небольшой команде программистов (<10 человек) уже используется таск менеджмент система, позволяющая просто ставить задачки, асайнить их и т.п. (аля багзила). Однако хочется повысить уровень самоконтроля. Есть идея ввести следующую процедуру: EN>Каждый составляет свой план работ на месяц и неделю
Фигасе, а менеджеры сидят и придумывают, какими отчетами еще программеров нагрузить EN>...каждый будет видеть что делали другие, что является мотивирующим фактором.
а простое собрание-пятиминутка не подойдет? в принципе, в таком-то огромном коллективе и так каждый знает, кто что сделал... если нет, наладьте нормальныю горизонтальные связи в коллективе
EN>Что думаете господа PMы?
Да ужжжж... Можно еще RUP внедрить в полном объеме. Для команды меньше 10 человек самое то!
EN>>Каждый составляет свой план работ на месяц и неделю B>Фигасе, а менеджеры сидят и придумывают, какими отчетами еще программеров нагрузить
Ах, ну да =) извините что потревожили. Вы там что-то программируете, ну не будем вам мешать, мы вам вот только денежек принесли, положим тут на стол....
Идея ввести планирование и отчетность нужна для того, чтобы повысить уровень самоконтроля и собранности программистов, помочь им рационально использовать свое время, а не просижывать по 15 часов непонятно ничего не делая. Прошу прощения что не уточнил, речь шла о ведущих программистах, тоесть потенциальных будущих PM-ов., конечно кому-то из них прийдется планировать не только свою рабоу но работу программиста низшего звена.
EN>>...каждый будет видеть что делали другие, что является мотивирующим фактором. B>а простое собрание-пятиминутка не подойдет? в принципе, в таком-то огромном коллективе и так каждый знает, кто что сделал... если нет, наладьте нормальныю горизонтальные связи в коллективе
В том то и загвоздка, что собраться вот так на 5 минут каждую неделю и обсудить план нет возможности физически.
Если можно, то напишите еще раз об существуещей схемы работы, а так же опишите места, которые вы считаете слабыми.
Теперь касаемо само контроля. Ведущий программист доводит план до членов свое группы. Если рядовой программист не согласен, со сроками исполнения, то он об этом сообщает ведущему. План, после совместного обсуждения корректируется. Если программист подписывается под этим планом, за частую молча соглашается, то он ОБЯЗАН его соблюдать. Это и есть самоконтроль. Если этого не происходит, то есть несколько причин:
1. Некомпетентность ведущего программиста
2. Боязь программиста (может и субъективно, но есть те, кто боятся возражать)
3. Ведущий не в авторитете (Как бы это не звучало, но программисты должны уважать ведущего или, тогда, бояться)
4. Осознание безнаказанности.
Проанализируйте — что у вас является стимулом к выполнению плана. И если этого стимула нет, то тут ни какие средства не помогут. Со своей стороны замечу, что лучшим стимулом является авторитетность ведущего программиста.
Здравствуйте, bralgin, Вы писали:
B>Здравствуйте, SEDEGOFF, Вы писали:
SED>>...что лучшим стимулом является авторитетность ведущего программиста.
B> B>чей-то авторитет — стимул? может быть, может быть... только не надолго.
B>перефразируем известное выражение: "авторитетность ведущего программиста в карман не положишь и шубу из него не сошьешь"
B>P.S. Ну почему все пытаются придумать велосипед?
Стимулирование в финансовом плане я специально не затронул. Только потому, что на этот счет у каждого свое мнение. Мое мнение таково, что деньгами стимулировать нужно в самом крайнем случае. Во первых программист должен получать хороший оклад, который обосновывается его знаниями и опытом, не зависиво от способности выполнять план. Во вторых введя финансовую составляющую в стимул, вам придется постоянно ее повышать. Если человеку повышают зарплату, то первые месяца два у него будет "много" денег, а вот на третий их уже будет не хватать. Поэтому, если следующий раз вы скажете что то типа "а вот сделаешь, дам премию $1000", программист скажет "И все? Только $1000 Да нафиг надо". И что бы простимулировать его, вам придеться дать $1100. Еще один минус финансовой стимуляции, это ее предсказуемость. То есть можно заложиться на эту премию, а можно и нет. Соответственно если программеру эти деньги не нужны сейчас, он отнесется к этому фмлосовски — "Нафига напрягать, получится — так получиться. Ну а нет, так ничего страшного.". Теперь касаемо авторитета. Надолго. Его нужно как минимум постоянно поддерживать на одном уровне, а лучше повышать. Человек так устроен. Он сделает все что может, лишь бы человек, чьим мнением он дорожит, отценил это при всех. И еще не маловажный факт — интерестность задачи. Если она программисту не интересна, то денег нужно выложить очень много. А вот по просьбе он это сделает точно в срок.
EN>>В небольшой команде программистов (<10 человек) уже используется таск менеджмент система, позволяющая просто ставить задачки, асайнить их и т.п. (аля багзила). Однако хочется повысить уровень самоконтроля. Есть идея ввести следующую процедуру: EN>>Каждый составляет свой план работ на месяц и неделю B>Фигасе, а менеджеры сидят и придумывают, какими отчетами еще программеров нагрузить
Работал я на шведов. Надо было составлять отчёт что сделано за ДЕНЬ и план что будешь делать ЗАВТРА, отчёт за ПРОШЛУЮ НЕДЕЛЮ и план на СЛЕДУЮЩУЮ, отчёт за МЕСЯЦ и план на СЛЕДУЮЩИЙ. Как же это всё задалбливало!
Увряю вас это лишь стимулирование фантазии и литературного таланта программистов. Выгоды от этого будет меньше чем проигрыша от потраченного на это времени.
B>а простое собрание-пятиминутка не подойдет? в принципе, в таком-то огромном коллективе и так каждый знает, кто что сделал... если нет, наладьте нормальныю горизонтальные связи в коллективе
А такае было на одной работе. Шефф очень увлекался всякими "методиками управления". То же мне, блин, теоретик...
Однажды (вспоминаю со смехом ) когда дальше проект "динамить" больше нельзя было все стали высказывать то что в душе накопилось. Короче когда все всё высказали там прям на месте порешалась половина проблем, а вторая половина обозначилась (раньше они были скрытыми). после этого шеф ВСЕ СВОИ ПРОШЛЫЕ СОВЕЩАНИЯ назвал "пионерскими утренниками"
Вы просто не сможете (по первости) организовать совещания чтобы они не были просто "пионерскими утренниками"...
Могу привести собственный процесс организации планирования и контроля в команде ~10 чел.
1. Раз в месяц я составляю план для всех членов команды на данный месяц. В нем я определяю содержание, объем и последовательность работ для каждого из них.
2. Членов команды оценивают трудозатраты (именно трудозатраты, а не длительность) по каждой задаче.
3. Таким образом, в результате составляется и согласовывается календарный план.
4. Каждый день перед уходом все члены команды отмечают кол-во времени, затраченное на каждую из текущих задач (а также сколько времени им необходимо до завершения данных задач, если они обнаружили что их первоначальная оценка была не совсем верной)
5. Таким образом я вижу ежедневный прогресс по всем задачам и направлениям.
Такая организация позволяет решать следующие задачи —
1. Составлять все более точные планы, так как со временем точность прогноза членов команды повышается.
2. Быстро реагировать на возникающие проблемы, влияющие на сроки выхода очередной версии.
3. Всегда быть в курсе текущего прогресса проекта
4. Предоставлять планы и их выполнение руководству кампании
5 И т.д.
В качестве инструментов используется MS Project Server
M_E>Могу привести собственный процесс организации планирования и контроля в команде ~10 чел.
И в какой книжке вы его прочитали? M_E>1. 2. 3. 4.
И с чего вы взяли что они всё не выдумывают? Они бы с удовольствием говорили правду, если они вкалывают "по полной", но программирование — не перетаскивание кирпичей и трудно оценить какую часть кучи ты сегодня перетащил, а те кто халявят, тянут время — те и просто врут...
M_E>5. Таким образом я вижу ежедневный прогресс по всем задачам и направлениям.
Виртуальный.
M_E>1. Составлять все более точные планы, так как со временем точность прогноза членов команды повышается.
А если сразу набрать профессиональных программистов то они более-менее точно будут оценивать объём работы. M_E>4. Предоставлять планы и их выполнение руководству кампании
И гордиться этим безумно! Пионерия какая-то... M_E>5 И т.д.
Всё так же плохо?
Вообщет довольно оптимальная структура это иерархия по 3 — 5 человека , 2-4 исполнителя + 1 руководитель/координатор.
Наблюдаю , если приходится писать отчет о том что делал особенно за неделю — это значит что руководитель/координатор не справляется с обязанностями. Т.е. он фактически не может сказать какую задачу делает в любой момент времени член его команды.
Это не означает что он плохой руководитель, возможно просто дали руководить группой из 6 человек, а это физически невозможно, ну и плюс он не разделил этих 6 человек на 2 группы и т.д.
Здравствуйте, Ed.Nixon, Вы писали:
EN>В небольшой команде программистов (<10 человек) уже используется таск менеджмент система, позволяющая просто ставить задачки, асайнить их и т.п. (аля багзила). Однако хочется повысить уровень самоконтроля. Есть идея ввести следующую процедуру: EN>Каждый составляет свой план работ на месяц и неделю и каждую неделю записывает что он сделал за эту неделю, информацию можно для простоты хранить в wiki. Кроме того каждый будет видеть что делали другие, что является мотивирующим фактором.
EN>Что думаете господа PMы?
Скажу крамолу.
Управлять группой из 10 человек — физически невозможно.
Максимум 3-5 (5 — потолок)
Начиная с 3 человек все усилия и время уходят на комуникацию, планирование и т.д.
В остальных случаях это только ВИДИМОСТЬ управления.
Здравствуйте, minorlogic, Вы писали:
M>Это не означает что он плохой руководитель, возможно просто дали руководить группой из 6 человек, а это физически невозможно, ну и плюс он не разделил этих 6 человек на 2 группы и т.д.
Почему невозможно управлять группой из 6 ти человек?
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, minorlogic, Вы писали:
M>>Скажу крамолу. M>>Управлять группой из 10 человек — физически невозможно. M>>Максимум 3-5 (5 — потолок)
B>Ну если подобрать неуправляемых, B>да поручить это дело начинаещему начальнику, B>то он и с одним не справится
Программисты по определению не управляемы . Читайте исследования. То есть навязать программистам, что-то очень сложно.
Здравствуйте, SteMage, Вы писали:
SM>Программисты по определению не управляемы . Читайте исследования. То есть навязать программистам, что-то очень сложно.
Ты хотел сказать русские программисты?
Ими да, управлять сложнее.
То ли дело немец. Ему сказал "делай так", он и будет "делать так"
А вообще, на мой взгляд, это больше миф, что программисты менее управляемы.
Тупо приказывать действительно сложнее,
а в целом больших проблем не вижу.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, minorlogic, Вы писали:
M>>Скажу крамолу. M>>Управлять группой из 10 человек — физически невозможно. M>>Максимум 3-5 (5 — потолок)
B>Ну если подобрать неуправляемых, B>да поручить это дело начинаещему начальнику, B>то он и с одним не справится
Могу сказать , что я говорю об эфективной работе, конечно не так много руководителей заинтересованны в этом.
А пример могу посоветовать брать с организации комуникаций в сетевом маркетинге (в успешных примерах).
Да и вообще поискать инфу про работу малыми группами.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, minorlogic, Вы писали:
M>>Могу сказать , что я говорю об эфективной работе, конечно не так много руководителей заинтересованны в этом.
B>Я может быть и поверил тебе, B>если бы не работал в маленькой команде (12 голов ), B>которая вполне нормально управляется одним руководителем.
Здравствуйте, webinc, Вы писали:
W>Здравствуйте, minorlogic, Вы писали:
M>>Это не означает что он плохой руководитель, возможно просто дали руководить группой из 6 человек, а это физически невозможно, ну и плюс он не разделил этих 6 человек на 2 группы и т.д.
W>Почему невозможно управлять группой из 6 ти человек?
Еще раз повторяю , можно создавать фикцию управления, хоть с 1000 человек. Достаточно объективным критерием тут можно использовать вот что :
Если руководитель не знает что делает в данную минуту каждый член его команды , он группой не руководит.
Здравствуйте, minorlogic, Вы писали:
M>Еще раз повторяю , можно создавать фикцию управления, хоть с 1000 человек. Достаточно объективным критерием тут можно использовать вот что : M>Если руководитель не знает что делает в данную минуту каждый член его команды , он группой не руководит.
Ты лучше книжку напиши: "Новое в менеджменте от Michael Norel"
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, SteMage, Вы писали:
SM>>Программисты по определению не управляемы . Читайте исследования. То есть навязать программистам, что-то очень сложно.
B>Ты хотел сказать русские программисты? B>Ими да, управлять сложнее. B>То ли дело немец. Ему сказал "делай так", он и будет "делать так"
B>А вообще, на мой взгляд, это больше миф, что программисты менее управляемы. B>Тупо приказывать действительно сложнее, B>а в целом больших проблем не вижу.
Я именно о тупо приказывать и говорил. А раз тупо приказывать нельзя, то приходится тратить время на коммуникации. То есть приходится объяснять, что зачем, почему из-за чего. На это уходит время. Да еще нужно убедится, что программист действительно согласился, а не сказал да-да и сделал по своему. А то знаете. У меня случай был, начальство очень хотело, чтобы я сделал интерфейс пользователя именно таким, как они хотели. Я взял и повесил на параметр, как должен выглядеть интерфейс пользователю. То есть начальство видело интерфейс пользователя таким как оно хотело и я таким каким его хотел .
Вообще-то это не миф. Но это не значит, что программисты не управляемы. Просто тупо навязать им что-то очень трудно. Вы это даже сами подтвердили. Как результат приходится тратить больше времени на коммуникации. Составлять дополнительные документы, проверять код и т.д.
Да кстати у вас начальник делает Code Review? Если нет то видимо он не управляет тем что происходит. То есть если совсем отдать техническую часть, то вполне возможно, что можно и 12 управлять.
Здравствуйте, SteMage, Вы писали:
SM>Вообще-то это не миф. Но это не значит, что программисты не управляемы. Просто тупо навязать им что-то очень трудно.
Ага, именно по этой причине в любой более менее серьезной
модели качества требуется чтобы все заинтересованные лица (не толко девелоперы)
поняли и приняли взятые на себя обязательства.
Это касается всего, от планов, до тестов...
Те из начальников, для которых это в обузу,
будут себя гораздо комфортнее чувствовать в армии
SM>Да кстати у вас начальник делает Code Review? Если нет то видимо он не управляет тем что происходит. То есть если совсем отдать техническую часть, то вполне возможно, что можно и 12 управлять.
Начальник не должен лично проводить code review.
Я бы даже сказал, что это очень плохая практика,
когда непосредственный начальник в этом принимает участие.
Его задача спланировать это мероприятие
и убедиться что оно прошло и проблемы, найденные на review
никуда не пропали и не забылись.
Должны проводиться так называемые peer review среди разработчиков,
которые не зависят друг от друга по иерархической лестнице.
Это, на мой взгляд, очень принципиально.
Основная задача начальника — руководить.
А это в первую очередь — планирование, контроль и координация.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, minorlogic, Вы писали:
M>>Если руководитель не знает что делает в данную минуту каждый член его команды , он группой не руководит.
B>Хм... B>То, что о чем ты говоришь — это не эффективное управление, B>а тотальный контроль. Нафиг нафиг такие методы .
B>Если не пытаться следить за всем и всеми, B>то управление 10-ю девелоперами вещь вполне реалистичная.
B>Ну а если управление — это когда без тебя и шагу ступить нельзя, B>то тогда ты и с одним не управишься.
Я имею ввиду "управление == координация" а не "управление == контроль".
Попробуйте вспомнить наиболее продуктивные моменты своей лучшей командной работы , скорее всего работа велась малой группой.
Здравствуйте, bralgin, Вы писали:
B>Здравствуйте, minorlogic, Вы писали:
M>>Еще раз повторяю , можно создавать фикцию управления, хоть с 1000 человек. Достаточно объективным критерием тут можно использовать вот что : M>>Если руководитель не знает что делает в данную минуту каждый член его команды , он группой не руководит.
B>Ты лучше книжку напиши: "Новое в менеджменте от Michael Norel"
Ты ошибаешься , если думаешь , что это я сам придумал.
Эх, не люблю я вступать в полемику, но все же отвечу
SIE>И в какой книжке вы его прочитали?
Книжек я чилал много разных — шкаф на работе и дома забит, так что список был бы очень большим.
А тот процесс, что у нас есть, это компиляция популярных методик и исторических реалий.
SIE>И с чего вы взяли что они всё не выдумывают? Они бы с удовольствием говорили правду, если они вкалывают "по полной", но программирование — не перетаскивание кирпичей и трудно оценить какую часть кучи ты сегодня перетащил, а те кто халявят, тянут время — те и просто врут...
Отвечу и на это — врать им резона нет никакого. И возможности тоже нет никакой — все люди сидят в одной очень большой комнате,
так что я всегда вижу и знаю кто чем занимается. Кроме того, я очень хорошо знаю каждого из них, знаю их индивидуальные особенности,
и знаю что сложившийся внутри коллектива климат не наводит их на мысли о вранье.
На самом деле мне уже не первый раз задают этот вопрос и я не первый раз ему удивляюсь — у меня в текущем коллективе, которым
я руковожу более 2-х лет ни разу не было такой проблемы. Ни одного раза. Это часть нашей внутренней культуры.
SIE>Виртуальный.
Нет не виртульный, а очень даже реальный. Я всегда вижу, что происходит с проектом — где мы отстаем, а где забегаем.
M_E>>1. Составлять все более точные планы, так как со временем точность прогноза членов команды повышается. SIE>А если сразу набрать профессиональных программистов то они более-менее точно будут оценивать объём работы.
Да, но вы же понимаете, что мы берем не только профессиональных программистов. Например, берем выпускников ВУЗов — обычно они
слишком оптимистичный оценки трудозатрат. Или людей, которые работали в ИТ-подразделениях, где планирование не требовалось.
SIE>И гордиться этим безумно! Пионерия какая-то...
Я вовсе не безумен (справки у меня, правда, нет ).
Вы видимо не вполне понимаете зачем требуется отчетность для руководства компании.
Она требуется для принятия решений и для отслеживание текущего состояния дел в проекте —
какие требования каких клиентов и когда будут выполнены, успеем мы выпустить новую версию к очередной выставке или нет и т.п.
SIE>Всё так же плохо?
да вроде ничего
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, SteMage, Вы писали:
B>Те из начальников, для которых это в обузу, B>будут себя гораздо комфортнее чувствовать в армии
А еще комфортней он будет себя чуствовать в женском коллективе. А самая некомфортная среда для таких начальников это среда технических специалистов. А на объяснение приказов надо время.
B>Основная задача начальника — руководить. B>А это в первую очередь — планирование, контроль и координация.
То есть собственно технической частью он совсем не занимается. Кстати с высокой долей вероятности часть управленческой работы проделывает ответственный за архитектуры. Тогда вполне реально.
Насколько я понял речь шла о Team Lead'ах. Так я думаю, что в такой ситуации 12 человек мало реально. ИМХО.
Здравствуйте, minorlogic, Вы писали:
M>>>Если руководитель не знает что делает в данную минуту каждый член его команды , он группой не руководит.
B>>Ты лучше книжку напиши: "Новое в менеджменте от Michael Norel"
M>Ты ошибаешься , если думаешь , что это я сам придумал.
Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>Отвечу и на это — врать им резона нет никакого. И возможности тоже нет никакой — все люди сидят в одной очень большой комнате, M_E>так что я всегда вижу и знаю кто чем занимается. Кроме того, я очень хорошо знаю каждого из них, знаю их индивидуальные особенности, M_E>и знаю что сложившийся внутри коллектива климат не наводит их на мысли о вранье. M_E>На самом деле мне уже не первый раз задают этот вопрос и я не первый раз ему удивляюсь — у меня в текущем коллективе, которым M_E>я руковожу более 2-х лет ни разу не было такой проблемы. Ни одного раза. Это часть нашей внутренней культуры.
А можно имя компании, чтобы знать, что продукты данной комапнии нельзя покупать, поскольку их цена явно не соответствует качеству.
1. Большое количество багов раз все сидят в одной комнате. Не верите поинтересуйтесь, как работают корректоры. Работа программистов во многом на эту работу похоже. Поэтому одна большая комната тождественна много багов.
2. Исходя из того что сказано скорее всего большая проблема с повышением квалификации, скорее всего люди ощущают дискомфорт, что то же приводит к увеличению багов.
Я прекрасно понимаю зачем и что нужно начальству. Вот только большинство из начальства не совсем понимает стоимость отчетности. То есть стоимость отчетности при разного рода процессах может быть в несколько раз выше стоимости разработки продукта и приводить к понижению качества конечного продукта. Вот этого почему то многие руководители не хотят видеть. И не хотят объективно оценивать стоимость такой отчетности. И соответственно с потребностями бизнеса или клиента выстраивать процесс разработки.
P.S. Да на всякий случай я не говорю, что управлять не надо и надо все пустить на самотек.
А можно имя компании, чтобы знать, что продукты данной комапнии нельзя покупать, поскольку их цена явно не соответствует качеству.
Имя компании ничего вам на скажем, а кроме того ее продукты отсутствуют в свободной продаже —
мы работаем для постоянных клиентов на длительных проектах.
SM>1. Большое количество багов раз все сидят в одной комнате. Не верите поинтересуйтесь, как работают корректоры. Работа программистов во многом на эту работу похоже. Поэтому одна большая комната тождественна много багов.
Действительно, при большом кол-ве разработчиков в одной комнате такая проблема может быть, но 10 человек в достаточно
большой комнате такую проблему не создают.
Я нахожусь здесь на месте и мне здесь лучше видна атмосфера внутри коллектива, нежели со стороны.
SM>2. Исходя из того что сказано скорее всего большая проблема с повышением квалификации, скорее всего люди ощущают дискомфорт, что то же приводит к увеличению багов.
По поводу этого — проблема состоит из двух частей —
1. сложности с повышением квалификации у тех, кто не стремится ее повышать.
2. (более серъезная) в нашем городе почти все разработчики либо занимаются 1С, либо уже работают у нас, либо уехали в Москву; так что предложение о том, чтобы сразу нанять профессионалов неприменимо.
Здравствуйте, Ed.Nixon, Вы писали:
EN>В небольшой команде программистов (<10 человек) уже используется таск менеджмент система, позволяющая просто ставить задачки, асайнить их и т.п. (аля багзила). Однако хочется повысить уровень самоконтроля. Есть идея ввести следующую процедуру: EN>Каждый составляет свой план работ на месяц и неделю и каждую неделю записывает что он сделал за эту неделю, информацию можно для простоты хранить в wiki. Кроме того каждый будет видеть что делали другие, что является мотивирующим фактором.
А почему бы не добавить сколько всего/сколько осталось к задачам в упоминавшейся системе?
План (на неделю, месяу, год) можно разбить на задачи и поприсваивать народу...
Здравствуйте, Michael_E_Smrinov, Вы писали:
SIE>>И с чего вы взяли что они всё не выдумывают? Они бы с удовольствием говорили правду, если они вкалывают "по полной", но программирование — не перетаскивание кирпичей и трудно оценить какую часть кучи ты сегодня перетащил, а те кто халявят, тянут время — те и просто врут...
M_E>Отвечу и на это — врать им резона нет никакого. И возможности тоже нет никакой — все люди сидят в одной очень большой комнате, M_E>так что я всегда вижу и знаю кто чем занимается. Кроме того, я очень хорошо знаю каждого из них, знаю их индивидуальные особенности, M_E>и знаю что сложившийся внутри коллектива климат не наводит их на мысли о вранье. M_E>На самом деле мне уже не первый раз задают этот вопрос и я не первый раз ему удивляюсь — у меня в текущем коллективе, которым M_E>я руковожу более 2-х лет ни разу не было такой проблемы. Ни одного раза. Это часть нашей внутренней культуры.
Смущает один момент.
Согласен с вашим утверждением относительно того, что, врать в отчетах — дело бессмысленное и довольно рискованное, но не согласен с его обоснванием.
Вы, фактически, утверждаете, что получаете дотоверные сведения от разработчиков, исключительно за счет хороших личных отношений, длительной совместной работы, етк.
По сути, это утверждение свидетельствует о сырости вашего процесса. Идеальный (и недостижимый) процесс должен исключать влияние человеческого фактора и человеческих отношений на качество и производительность работ. Хороший процесс — это процесс нечувствительный (ну или как минимум малочувствительный) к смене членов проектной комманды. В вашем же случае — наоборот, основа процесса — это личные отношения. Стало быть, если завтра на ваше место придет новый руководитель, вероятность провала проекта резко повысится...
Я не говорю о том, что пипл-фактор должен игнорироваться менеджментом. Безусловно, это важнейший элемент в управлении интеллектуальным трудом. Однако вектор продждект менеджмента (особенно в крупных проектах) должен быть направлен формализацию отношений и процессов.
SIE>>Виртуальный. M_E>Нет не виртульный, а очень даже реальный. Я всегда вижу, что происходит с проектом — где мы отстаем, а где забегаем.
Опять же — вы. Основываясь на личном опыте и сложившейся системе отношений в коллективе.
На вашем месте я бы ввел чуть больше формализма в процесс мониторинга текущего состояния работ.
Для этого есть ряд техник:
— это планирование не только времени но и ОБЪЕМА работ (строки кода, функциональные объекты) — это позволит получить, чистую, лишенную субъективизма метрику текущего статуса путем банального вычисления текущего объема от запланированногож
— это ежедневные билды с репортами о добавленной функциональности и результатми юнит тестирования этой функциональности
— это небольшие итерации разработки, с демкой в конце каждой итерации
— еще много чего — при желании можем обсудить подробнее...
Большое спасибо!
Отвечаю по пунктам.
S>По сути, это утверждение свидетельствует о сырости вашего процесса. Идеальный (и недостижимый) процесс должен исключать влияние человеческого фактора и человеческих отношений на качество и производительность работ. Хороший процесс — это процесс нечувствительный (ну или как минимум малочувствительный) к смене членов проектной комманды. В вашем же случае — наоборот, основа процесса — это личные отношения. Стало быть, если завтра на ваше место придет новый руководитель, вероятность провала проекта резко повысится...
Согласен, процесс еще далек от идеала. Многое из того, что мне бы хотелось внедрить, пока внедрить не получается.
Причин тому несколько (я уже писал как-то об этом ранее). Основные из них:
1. Очень тяжело внедряются изменения в процесс, если для них нет весомых предпосылок.
Согласен, что предпосылки нужно предвидеть и действовать заранее, что я и делаю, но некоторые вещи
(например, внедрить RequisitePro) сделать пока не получается.
2. Давно работающие люди, которые со скрипом привыкают к изменениям в их обычной работе.
Они думают, что им стали меньше доверять, иногда что за ними хотят следить и т.п.
S>Я не говорю о том, что пипл-фактор должен игнорироваться менеджментом. Безусловно, это важнейший элемент в управлении интеллектуальным трудом. Однако вектор продждект менеджмента (особенно в крупных проектах) должен быть направлен формализацию отношений и процессов.
Совершенно с вами согласен. По мере расширения проекта необходимость повышения формализации очевидна.
Стараюсь двигаться в эту сторону.
Опять же, повторюсь, пока не все удается, но сделано уже многое.
S>На вашем месте я бы ввел чуть больше формализма в процесс мониторинга текущего состояния работ.
Можете привести пример?
S>Для этого есть ряд техник: S>- это планирование не только времени но и ОБЪЕМА работ (строки кода, функциональные объекты) — это позволит получить, чистую, лишенную субъективизма метрику текущего статуса путем банального вычисления текущего объема от запланированногож
На счет оценки строк кода — мне это кажется довольно спорным — например, тестировщики и администраторы вообще не пишут код.
Или даже разработчики — они могут писать по строке в день, а на следующий день написать 1000 строк, но ведь это не значит что предыдущий день они не работали. Мне пока как-то более привычно оперировать трудозатратами выраженными в человеко-часах.
S>- это ежедневные билды с репортами о добавленной функциональности и результатми юнит тестирования этой функциональности
Ну это я уже давно внедрил — году два назад
Каждый день просходит сборка системы и выгрузка на тестовые сервера.
Затем тестировщики полностью проверяют все систему (в том числе с использованием автоматических средств)
Найденные ошибки заносятся в базу ошибок и направляются разработчикам.
Разработчики исправляют ошибки и помечают их как выолненные.
При последующем разверывании системы на тестовые сервера тестировщики верифицируют эти ошибки и либо закрывают, либо возвращают на доработку.
Разверывание на рабочие сервера происходит примерно раз в неделю при отсутствии серъезных проблем.
S>- это небольшие итерации разработки, с демкой в конце каждой итерации
Ну вот примерно так и получается — накопившыеся запросы от клиентов я стараюсь планировать примерно на 3 недели чистого времени.
Дальше я считаю, что разработчики работают примерно 6 часов чистого времени в день.
Изходя из этого, план рассчитывается на 4 недели, в конце которых мы имеем окончание очередной итерации.
Конечно, длительности итерации могут меняться. Кроме того, поскольку системы уже стала довольно большой, то
1. Границы между итерациями становяться все менее четкими.
2. Разные части системы начинают развиваться в обособленных итерациях.
S>- еще много чего — при желании можем обсудить подробнее...
Согласен обсудить и что потребуется применить.
В нашем городе я не знаю никого, с кем бы я мог посоветоваться по данным вопросам.
Здравствуйте, 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 строк — это я утрировал, конечно
Но ведь действительно, многие члены команды вообще не пишут код.
Их работу как-то надо планировать и отслеживать
Можно, конечно, использовать кол-во найденных ошибок для тестировщиков.
Надо подумать об этом, я пока не пришел к конечному мнению.
И вообще, для возмущающегося товарища — я не знаю, сколько у него человек в команде,
но у меня прогресса примерно был такой —
1. Когда у меня один человек, я помнил, что он делает
2. Когда у меня было 2-3 человека, я записывал в Word'е задачи и потом их вычеркивал.
3. Когда у меня было 5 человек, я распределял залачи через TestTrack, но уже тогда остро стояла необходимость
календарного планирования и отслеживания прогресса.
4. Сейчас у меня 12 человек я не представляю, как можно в голове удержать прогресс по всем направлениям.
Без MS Project (или аналога) просто не обойтись.
Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>По поводу работы по ночам — лично я считаю это более вредным, чем полезным.
M_E>Разработчик может сидеть до середины ночи и зачекинить такое, что не будет правильно работать.
M_E>Тогда команде с утра придется либо ждать его прихода, пока он выспится, либо самим разбираться в том, что он ночью написал и M_E>пытаться устранить ошибку.
M_E>Второй момент (более общего плана) — нарушение взаимодействий в команде. Если один человек пришел с утра, а второго нет, и работа первого зависит от второго, то получаем потерю времени.
M_E>В общем я против этого и мне пришлось прекратить такую практику более года назад
если команда построена так что вся работа стоит пока когото нет, значит чтото здесь неправильно — работа должна иметь возможность продолжаться, даже если неожиданно ктото ушел в отпуск...
Тот кто говорит не знает, тот кто знает не говорит.
Здравствуйте, Streamer1, Вы писали: S>>Вот давай по сути. S>>Человек предложил схему решения задачи: еждневные отчеты участников комманды о времени затраченныом в течение дня на те или иные задачи. Эта тривиальная методика, при всем ее несовершенстве, достаточно эффективно используется в индустрии, и неплохо работает, особенно на небольших проектах. Она проста как льдинка, и дешева с точки срения затрачиваемых ресурсов. Да, при усложнении проектов, увеличении числа вовлеченного персонала и схем взаимодействия внтури проектов рекоммендуется применять более мощные методики и схемы конторля, но на средних проектов — то что надо. S> ежедневные отчеты — это признак "полного завала проекта"
Где аргументация? Может мне привести вам примеры проектов, в которых разработчики писали ежедневные отчеты, и они были сданы в срок с необходимым качеством? А заодно примеры проектов которые провалились, потому что ПМ понятия не имел чем занимаются разработчики — они не вели такие ежедневные отчеты. В результате, разработчики тратили время на ненужные вещи, и всплывало это не сразу.
S>>Что ты имеешь против? Почему такого рода отчестность должна каким-то образом ограничивать совбоды и творческий порыв участников комманды? Как ты предлагаешь осуществлять контороль за выполнением? Или ты полагаешь что контороль и мониторинг вообще не нужен и водоворот анархии внутри проекта сам вынесет на поверхность готовое решение, при чем в срок?
S>читаем Ашманова: S>Контроль посещаемости
<skipped>
Кто-то говорил о контроле посещаемости?
S>Контроль количества работы S>Далее светлая мысль начальства достигает самой сути: нужно контролировать даже не рабочее время, а количество работы! Возникает смелый план заставить программистов вечером каждого дня (вариант — по пятницам) записывать, что сделано, и тут же "одной кнопкой" отправлять запись в некую общую систему. S>Обычно, к счастью, этот ежедневный вариант контроля не удается даже внедрить. Сопротивление разумной части коллектива оказывается слишком велико. S>Пятничные отчеты начинают писаться (руководитель проекта упросил всех поддаться), но их перестают читать наверху через пару недель, а писать внизу — через месяц-полтора.
Ашманов юморист. Заметьте как идут тезисы.
1. Пытаются внедрить ежедневные отчеты
2. "Обычно" их внедрить не удается, потому что разработчики сопротивляются. Не раскрыта тема — почему они сопротивляются? Может потому что они большую часть времени занимаются не тем что надо? (они при этом могут писать код и реализовывать фичи, но неизвестно ТЕ они делают фичи или нет, успевают они реализовывать фичи согласно плану или нет).
3. В качестве отчетов делаются отписки наверх. Поскольку они не отражают реальное положение дел — их перестают читать.
Теперь внимание вопрос. Что эти тезисы утверждают?
Ответ. На гнилых и провальных проектах внедрить ежедневные отчеты сотрудников о проделанной работе не удается! Это и есть признак плохого проекта . Так что этот аргумент не в пользу уважаемого Streamer1.
Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>Да, я с вами совершенно согласен.
M_E>И вообще, для возмущающегося товарища — я не знаю, сколько у него человек в команде,
Я вас умоляю...
Не относитесь к этому слишком серьезно. Готов поспорить, что товарищ не имеет ни грамма опыта в практическом менеджменте.
Здравствуйте, Streamer1, Вы писали:
S>ежедневные отчеты — это признак "полного завала проекта"
это лозунг?
если это твоя мысль — будь добр поподробнее...
потому, что у меня на этот счет совершенно противоположное мнение.
и это мнение подтверждается моим практическим опытом.
S>читаем Ашманова:
нда, авторитетный источник, чего и говорить...
когда говорит ашманов, остальной мир нервно курит в сторонке
одним словом, либо свернем дискуссию ввиду несостоятельности твоей аргументации, либо сформулируй четко что так сурово выводит тебя из равновесия?
методика мониторинга выполнения, основанная на ежедневных репортах?
предложи альтернативу. ты предлагаешь вообще не мониторить статус проекта? или делать это каким либо другим способом?
--
(ашманова смело в топку, ну ей-богу не трать время на подобный мусор)
Здравствуйте, RGB_Dart, Вы писали:
S>>>Человек предложил схему решения задачи: еждневные отчеты участников комманды о времени затраченныом в течение дня на те или иные задачи. Эта тривиальная методика, при всем ее несовершенстве, достаточно эффективно используется в индустрии, и неплохо работает, особенно на небольших проектах. Она проста как льдинка, и дешева с точки срения затрачиваемых ресурсов. Да, при усложнении проектов, увеличении числа вовлеченного персонала и схем взаимодействия внтури проектов рекоммендуется применять более мощные методики и схемы конторля, но на средних проектов — то что надо. S>> ежедневные отчеты — это признак "полного завала проекта" RGB>Где аргументация?
встречался с таким, видел чем заканчивалось
RGB>Может мне привести вам примеры проектов, в которых разработчики писали ежедневные отчеты, и они были сданы в срок с необходимым качеством? А заодно примеры проектов которые провалились, потому что ПМ понятия не имел чем занимаются разработчики — они не вели такие ежедневные отчеты. В результате, разработчики тратили время на ненужные вещи, и всплывало это не сразу.
приведите, желательно с описанием последствий и таких косвенных показателей как текучесть кадров, заинтересованность (не только денежная но и моральная) сотрудников в работе, атмосфера в коллективе... короче тех факторов которые отпугивают людей от работы...
Замечу, что по поводу отчетов я не утверждал что они совсем не нужны, все хорошо в меру, а когда превышают дозы то и лекарство становится сильным ядом
Имхо требование отчетов должно иметь хорошее обоснование, они должны требоваться не ради отчетов, а для обратной связи, и не должны сильно отвлекать человека от работы и не занимать значительную часть рабочего времени, не должны быть в тягость сотрудникам... а не так чтобы требовать отчет потому что мол так принято или может быть позволит избежать затруднительных ситуаций...
S>>>Что ты имеешь против? Почему такого рода отчестность должна каким-то образом ограничивать совбоды и творческий порыв участников комманды? Как ты предлагаешь осуществлять контороль за выполнением? Или ты полагаешь что контороль и мониторинг вообще не нужен и водоворот анархии внутри проекта сам вынесет на поверхность готовое решение, при чем в срок?
S>>читаем Ашманова: S>>Контроль посещаемости RGB><skipped> RGB>Кто-то говорил о контроле посещаемости?
ну я заметил, что когда чтото не так, то действительно возникают перечисленные Ашмановым ситуации
S>>Контроль количества работы S>>Далее светлая мысль начальства достигает самой сути: нужно контролировать даже не рабочее время, а количество работы! Возникает смелый план заставить программистов вечером каждого дня (вариант — по пятницам) записывать, что сделано, и тут же "одной кнопкой" отправлять запись в некую общую систему. S>>Обычно, к счастью, этот ежедневный вариант контроля не удается даже внедрить. Сопротивление разумной части коллектива оказывается слишком велико. S>>Пятничные отчеты начинают писаться (руководитель проекта упросил всех поддаться), но их перестают читать наверху через пару недель, а писать внизу — через месяц-полтора. RGB>Ашманов юморист. Заметьте как идут тезисы. RGB>1. Пытаются внедрить ежедневные отчеты RGB>2. "Обычно" их внедрить не удается, потому что разработчики сопротивляются. Не раскрыта тема — почему они сопротивляются?
потому что это серьезно отвлекает от работы и создает впечатление что человека загоняют в кабалу
RGB>Может потому что они большую часть времени занимаются не тем что надо? (они при этом могут писать код и реализовывать фичи, но неизвестно ТЕ они делают фичи или нет, успевают они реализовывать фичи согласно плану или нет).
я думаю что можно сделать совершенно другие выводы — разработчик обычно неплохо знает каким образом ему работается максимально эффективно, гораздо полезнее былобы задавать задачи и требовать их решения, вместо требования как и какими способами решать, и уж темболее ошибкой будет постоянно держать человека в напряжении в такие моменты когда он задачу выполнил, а следующая еще не подоспела, нагружая при этом его тупой работой в стиле "делай чтонибудь", вместо того чтобы дать отвлечься и передохнуть...
а если создается впечатление что сотрудники могут выполнить больше работы то можно попробовать поднять планку заданий — по реакции и результатам можно судить о том насколько это соответствует действительности, важно не вызывать чувство неудовлетворенности совмещая это с решением задач "требования" и "контроля", в этом и заключается профессионализм...
RGB>3. В качестве отчетов делаются отписки наверх. Поскольку они не отражают реальное положение дел — их перестают читать. RGB>Теперь внимание вопрос. Что эти тезисы утверждают? RGB>Ответ. На гнилых и провальных проектах внедрить ежедневные отчеты сотрудников о проделанной работе не удается! Это и есть признак плохого проекта . Так что этот аргумент не в пользу уважаемого Streamer1.
не совсем так, ответ: Люди которые доводят проекты до гнилого и провального состояния как правило склонны к внедрению ежедневных отчетов сотрудников о проделаной работе, что свидетельствет о серьезности некомпетентности в управлении, а не о случайных ошибках в планировании...
Тот кто говорит не знает, тот кто знает не говорит.
Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>Но ведь действительно, многие члены команды вообще не пишут код. M_E>Их работу как-то надо планировать и отслеживать
Впринципе, можно применять технику планирования/контороля объема работы только для разработчиков. Уже это немало, учитывая то, что это есть основной и наиболее массовый в ИТ компании ресурс.
M_E>Можно, конечно, использовать кол-во найденных ошибок для тестировщиков.
Да. Например, в CQG в числе прочих используется и эта метрика для оценки/контроля/планирования работы QA.
Здравствуйте, RGB_Dart, Вы писали:
S>>>Человек предложил схему решения задачи: еждневные отчеты участников комманды о времени затраченныом в течение дня на те или иные задачи. Эта тривиальная методика, при всем ее несовершенстве, достаточно эффективно используется в индустрии, и неплохо работает, особенно на небольших проектах. Она проста как льдинка, и дешева с точки срения затрачиваемых ресурсов. Да, при усложнении проектов, увеличении числа вовлеченного персонала и схем взаимодействия внтури проектов рекоммендуется применять более мощные методики и схемы конторля, но на средних проектов — то что надо. S>> ежедневные отчеты — это признак "полного завала проекта" RGB>Где аргументация?
встречался с таким, видел чем заканчивалось
RGB>Может мне привести вам примеры проектов, в которых разработчики писали ежедневные отчеты, и они были сданы в срок с необходимым качеством? А заодно примеры проектов которые провалились, потому что ПМ понятия не имел чем занимаются разработчики — они не вели такие ежедневные отчеты. В результате, разработчики тратили время на ненужные вещи, и всплывало это не сразу.
приведите, желательно с описанием последствий и таких косвенных показателей как текучесть кадров, заинтересованность (не только денежная но и моральная) сотрудников в работе, атмосфера в коллективе... короче тех факторов которые отпугивают людей от работы...
Замечу, что по поводу отчетов я не утверждал что они совсем не нужны, все хорошо в меру, а когда превышают дозы то и лекарство становится сильным ядом
Имхо требование отчетов должно иметь хорошее обоснование, они должны требоваться не ради отчетов, а для обратной связи, и не должны сильно отвлекать человека от работы и не занимать значительную часть рабочего времени, не должны быть в тягость сотрудникам... а не так чтобы требовать отчет потому что мол так принято или может быть позволит избежать затруднительных ситуаций...
S>>>Что ты имеешь против? Почему такого рода отчестность должна каким-то образом ограничивать совбоды и творческий порыв участников комманды? Как ты предлагаешь осуществлять контороль за выполнением? Или ты полагаешь что контороль и мониторинг вообще не нужен и водоворот анархии внутри проекта сам вынесет на поверхность готовое решение, при чем в срок?
S>>читаем Ашманова: S>>Контроль посещаемости RGB><skipped> RGB>Кто-то говорил о контроле посещаемости?
ну я заметил, что когда чтото не так, то действительно возникают перечисленные Ашмановым ситуации
S>>Контроль количества работы S>>Далее светлая мысль начальства достигает самой сути: нужно контролировать даже не рабочее время, а количество работы! Возникает смелый план заставить программистов вечером каждого дня (вариант — по пятницам) записывать, что сделано, и тут же "одной кнопкой" отправлять запись в некую общую систему. S>>Обычно, к счастью, этот ежедневный вариант контроля не удается даже внедрить. Сопротивление разумной части коллектива оказывается слишком велико. S>>Пятничные отчеты начинают писаться (руководитель проекта упросил всех поддаться), но их перестают читать наверху через пару недель, а писать внизу — через месяц-полтора. RGB>Ашманов юморист. Заметьте как идут тезисы. RGB>1. Пытаются внедрить ежедневные отчеты RGB>2. "Обычно" их внедрить не удается, потому что разработчики сопротивляются. Не раскрыта тема — почему они сопротивляются?
потому что это серьезно отвлекает от работы и создает впечатление что человека загоняют в кабалу
RGB>Может потому что они большую часть времени занимаются не тем что надо? (они при этом могут писать код и реализовывать фичи, но неизвестно ТЕ они делают фичи или нет, успевают они реализовывать фичи согласно плану или нет).
я думаю что можно сделать совершенно другие выводы — разработчик обычно неплохо знает каким образом ему работается максимально эффективно, гораздо полезнее былобы задавать задачи и требовать их решения, вместо требования как и какими способами решать, и уж темболее ошибкой будет постоянно держать человека в напряжении в такие моменты когда он задачу выполнил, а следующая еще не подоспела, нагружая при этом его тупой работой в стиле "делай чтонибудь", вместо того чтобы дать отвлечься и передохнуть...
а если создается впечатление что сотрудники могут выполнить больше работы то можно попробовать поднять планку заданий — по реакции и результатам можно судить о том насколько это соответствует действительности, важно не вызывать чувство неудовлетворенности совмещая это с решением задач "требования" и "контроля", в этом и заключается профессионализм...
RGB>3. В качестве отчетов делаются отписки наверх. Поскольку они не отражают реальное положение дел — их перестают читать. RGB>Теперь внимание вопрос. Что эти тезисы утверждают? RGB>Ответ. На гнилых и провальных проектах внедрить ежедневные отчеты сотрудников о проделанной работе не удается! Это и есть признак плохого проекта . Так что этот аргумент не в пользу уважаемого Streamer1.
не совсем так, ответ: Люди которые доводят проекты до гнилого и провального состояния как правило склонны к внедрению ежедневных отчетов сотрудников о проделаной работе, что свидетельствет о серьезности некомпетентности в управлении, а не о случайных ошибках в планировании...
Тот кто говорит не знает, тот кто знает не говорит.
Здравствуйте, Streamer1, Вы писали:
S>>> ежедневные отчеты — это признак "полного завала проекта" RGB>>Где аргументация?
Причин завала проекта может быть миллион и ежедневные отчеты здесь роли никакой не играют.
Рассматривайте их как следование поставленному с утра плану и контроля эффективности вашего планирования на заданный период времени.
Можно для развлечения вычислять коэффициент соответствия запланированного с утра и сделанного к вечеру.
Из своего опыта заметил, что планирование (как минимум на день) позволяет не только видеть актуальные задачи, но и сократить цикл разработки.
S>приведите, желательно с описанием последствий и таких косвенных показателей как текучесть кадров, заинтересованность (не только денежная но и моральная) сотрудников в работе, атмосфера в коллективе... короче тех факторов которые отпугивают людей от работы...
У нас принята ежедневная система отчетности. Из той части коллектива, которая относится к работе с заинтересованностью они не представляет неудобств (по сравнению с другими, бОльшими огрехами в организации проивзодства). Немного приврал, но в целом все так.
RGB>>1. Пытаются внедрить ежедневные отчеты RGB>>2. "Обычно" их внедрить не удается, потому что разработчики сопротивляются. Не раскрыта тема — почему они сопротивляются? S>потому что это серьезно отвлекает от работы и создает впечатление что человека загоняют в кабалу
Чем это фиксация сделанных изменений (достаточно 5 минут на каждую завершенную подзадачу) отвлекает от работы?
RGB>>3. В качестве отчетов делаются отписки наверх. Поскольку они не отражают реальное положение дел — их перестают читать.
Есть такой пунктик, но если проект разбит на подзадачи с интервалом в 4-40 часов, то даже отписки позволяют фиксировать направление, в котором идут работы. Тоесть здесь проблемы манагера, а не системы или девелопера.
S>не совсем так, ответ: Люди которые доводят проекты до гнилого и провального состояния как правило склонны к внедрению ежедневных отчетов сотрудников о проделаной работе, что свидетельствет о серьезности некомпетентности в управлении, а не о случайных ошибках в планировании...
"Люди которые доводят проекты до гнилого и провального состояния" — это какие люди имеются ввиду? Проект сам по себе не загнивает, он загнивает при неправильном планировании и отсутствии контроля. Уж этого я наелся :D
Здравствуйте, Slick, Вы писали:
S>>читаем Ашманова:
S>нда, авторитетный источник, чего и говорить... S>когда говорит ашманов, остальной мир нервно курит в сторонке
S>одним словом, либо свернем дискуссию ввиду несостоятельности твоей аргументации, либо сформулируй четко что так сурово выводит тебя из равновесия?
S>методика мониторинга выполнения, основанная на ежедневных репортах?
S>предложи альтернативу. ты предлагаешь вообще не мониторить статус проекта? или делать это каким либо другим способом?
альтернатива — тратить время на выполнение основной работы (за которую кстати и платятся деньги), а не разводить бюрократию, сжигая время на составление отчетов и пытаясь наладить испорченную атмосферу неадекватными методами...
Важно помнить что деньги платят не за попытки создания жизнеспособной системы с жесткой отчетностью, неадекватными попытками управления и несбалансированными отношениями, а за результаты выполнения работы. Под результатами работы понимается не гора отчетов, а программный продукт.
Тот кто говорит не знает, тот кто знает не говорит.
Здравствуйте, PVA, Вы писали:
PVA>Здравствуйте, Streamer1, Вы писали:
S>>приведите, желательно с описанием последствий и таких косвенных показателей как текучесть кадров, заинтересованность (не только денежная но и моральная) сотрудников в работе, атмосфера в коллективе... короче тех факторов которые отпугивают людей от работы... PVA>У нас принята ежедневная система отчетности. Из той части коллектива, которая относится к работе с заинтересованностью они не представляет неудобств (по сравнению с другими, бОльшими огрехами в организации проивзодства). Немного приврал, но в целом все так.
а часть эта состоит из одного человека — менеджера требующего ежедневные отчеты?
RGB>>>1. Пытаются внедрить ежедневные отчеты RGB>>>2. "Обычно" их внедрить не удается, потому что разработчики сопротивляются. Не раскрыта тема — почему они сопротивляются? S>>потому что это серьезно отвлекает от работы и создает впечатление что человека загоняют в кабалу PVA>Чем это фиксация сделанных изменений (достаточно 5 минут на каждую завершенную подзадачу) отвлекает от работы?
тем что человек будет думать о том что ему написать в отчете, а не о том как быстрее и качественнее решить задачу. Соответственно и результат будет ориентирован на отчет, а не на решение задачи.
S>>не совсем так, ответ: Люди которые доводят проекты до гнилого и провального состояния как правило склонны к внедрению ежедневных отчетов сотрудников о проделаной работе, что свидетельствет о серьезности некомпетентности в управлении, а не о случайных ошибках в планировании... PVA>"Люди которые доводят проекты до гнилого и провального состояния" — это какие люди имеются ввиду?
PM
PVA>Проект сам по себе не загнивает, он загнивает при неправильном планировании и отсутствии контроля. Уж этого я наелся :D
согласен, однако ежедневными отчетами хорошего контроля не добъешься, т.к. это стимул работать на отчеты, а не на решение задачи, а это несколько разные вещи...
Тот кто говорит не знает, тот кто знает не говорит.
Здравствуйте, Streamer1, Вы писали:
PVA>>У нас принята ежедневная система отчетности. Из той части коллектива, которая относится к работе с заинтересованностью они не представляет неудобств (по сравнению с другими, бОльшими огрехами в организации проивзодства). Немного приврал, но в целом все так. S>а часть эта состоит из одного человека — менеджера требующего ежедневные отчеты?
Это проблема заинтересованности. Давайте введем разницу между требовать и заинтересовать.
PVA>>Чем это фиксация сделанных изменений (достаточно 5 минут на каждую завершенную подзадачу) отвлекает от работы? S>тем что человек будет думать о том что ему написать в отчете, а не о том как быстрее и качественнее решить задачу. Соответственно и результат будет ориентирован на отчет, а не на решение задачи.
Отчет фиксироует сделанную работу — зачем там о чем-то думать? Достаточно написать, что сделал "то-то", потому что "как сделал" — видно из кода, а "почему так сделал" из комментариев к коду.
PVA>>"Люди которые доводят проекты до гнилого и провального состояния" — это какие люди имеются ввиду? S>PM
Тогда давайте вскроем причину довода до провального состояния. Опишете?
PVA>>Проект сам по себе не загнивает, он загнивает при неправильном планировании и отсутствии контроля. Уж этого я наелся :D S>согласен, однако ежедневными отчетами хорошего контроля не добъешься, т.к. это стимул работать на отчеты, а не на решение задачи, а это несколько разные вещи...
См. выше. Отчет только фиксирует выполненную задачу, но никак не дает волю фантазии — никто не требует трехстраничного описания о ходе выполнения работы.
Здравствуйте, Slick, Вы писали:
M_E>>Да, я с вами совершенно согласен.
M_E>>И вообще, для возмущающегося товарища — я не знаю, сколько у него человек в команде,
S>Я вас умоляю... S>Не относитесь к этому слишком серьезно. Готов поспорить, что товарищ не имеет ни грамма опыта в практическом менеджменте.
интересно а зачем ты пытаешься перейти на личности? неужели доводов нет?
опыт у меня пока действительно небольшой, но непрофессиональные менеджеры это отнюдь не редкость среди людей с большиииим опытом, я бы даже сказал что таких можно считать как уже привыкших и плохо подающхся исправлению...
поверхностно мыслите товарищь!
Тот кто говорит не знает, тот кто знает не говорит.
S>>одним словом, либо свернем дискуссию ввиду несостоятельности твоей аргументации, либо сформулируй четко что так сурово выводит тебя из равновесия? S>>методика мониторинга выполнения, основанная на ежедневных репортах? S>>предложи альтернативу. ты предлагаешь вообще не мониторить статус проекта? или делать это каким либо другим способом?
S>альтернатива — тратить время на выполнение основной работы (за которую кстати и платятся деньги), а не разводить бюрократию, сжигая время на составление отчетов и пытаясь наладить испорченную атмосферу неадекватными методами... S>Важно помнить что деньги платят не за попытки создания жизнеспособной системы с жесткой отчетностью, неадекватными попытками управления и несбалансированными отношениями, а за результаты выполнения работы. Под результатами работы понимается не гора отчетов, а программный продукт.
Streamer1, вам не надоело подменять понятия? Уже несколько раз в этом топике вам на это указывали.
Составление очтета в конце рабочего дня о проделаной работе занимает 5 минут и НЕ является разведением бюрократии, НЕ сжигает время, НЕ портит атмосферу и НЕ является целью работы программистов.
Важно помнить, что деньги платят не за деятельность разработчиков-"художников", которые не знают что они будут писать завтра, что они писали вчера. Разработчиков, которые работают по принципу "3 месяца рубаемся в кваку, а потом прибегает заказчик и говорит что надо было сделать вчера", словами имитирующие результаты работы, дающие устные оценки "да у меня почти все готово". Под результатами работы понимается программный продукт, сделанный В СРОК, а не гора обещаний заказчику что "вот еще чуть-чуть и оно заработает".
Пытался воспроизвести полемику автора .
А на вопрос ответа не получено. Повторю вопрос Slick'a:
"ты предлагаешь вообще не мониторить статус проекта?"
Варианты ответов — да \ нет. Дайте ответ и тогда будет иметь смысл дальше дискутировать.
S>>>одним словом, либо свернем дискуссию ввиду несостоятельности твоей аргументации, либо сформулируй четко что так сурово выводит тебя из равновесия? S>>>методика мониторинга выполнения, основанная на ежедневных репортах? S>>>предложи альтернативу. ты предлагаешь вообще не мониторить статус проекта? или делать это каким либо другим способом?
S>>альтернатива — тратить время на выполнение основной работы (за которую кстати и платятся деньги), а не разводить бюрократию, сжигая время на составление отчетов и пытаясь наладить испорченную атмосферу неадекватными методами... S>>Важно помнить что деньги платят не за попытки создания жизнеспособной системы с жесткой отчетностью, неадекватными попытками управления и несбалансированными отношениями, а за результаты выполнения работы. Под результатами работы понимается не гора отчетов, а программный продукт.
RGB>Streamer1, вам не надоело подменять понятия? Уже несколько раз в этом топике вам на это указывали.
RGB>Составление очтета в конце рабочего дня о проделаной работе занимает 5 минут и НЕ является разведением бюрократии, НЕ сжигает время, НЕ портит атмосферу и НЕ является целью работы программистов. RGB>Важно помнить, что деньги платят не за деятельность разработчиков-"художников", которые не знают что они будут писать завтра, что они писали вчера. Разработчиков, которые работают по принципу "3 месяца рубаемся в кваку, а потом прибегает заказчик и говорит что надо было сделать вчера", словами имитирующие результаты работы, дающие устные оценки "да у меня почти все готово". Под результатами работы понимается программный продукт, сделанный В СРОК, а не гора обещаний заказчику что "вот еще чуть-чуть и оно заработает". RGB>Пытался воспроизвести полемику автора .
RGB>А на вопрос ответа не получено. Повторю вопрос Slick'a: RGB>"ты предлагаешь вообще не мониторить статус проекта?" RGB>Варианты ответов — да \ нет. Дайте ответ и тогда будет иметь смысл дальше дискутировать.
нет, мониторить нужно, первый раз я этому уделял мало внимания что потом вылилось в глюки из-за небольших нестыковок и переносу сроков...
но, есть проблема что если сильно затягивать гайки то люди просто разбегутся и никаким калачом их не заманишь... так что палка тут о двух концах...
Тот кто говорит не знает, тот кто знает не говорит.
Здравствуйте, Streamer1, Вы писали:
S>кстати интересно, неужели есть компании, где практикуются ежедневные отчеты
Есть... и даже возвращаются квалифицированные кадры (гы)
Здравствуйте, Streamer1, Вы писали:
S>>Я вас умоляю... S>>Не относитесь к этому слишком серьезно. Готов поспорить, что товарищ не имеет ни грамма опыта в практическом менеджменте.
S>интересно а зачем ты пытаешься перейти на личности? неужели доводов нет?
что ты называешь переходом на личности, амиго?
заменть, я выразил свои предположение о твоем невысоком профессиональном уровне в области менеджмента.
ты, быть может, отличный дядька в личном плане, но в менеджменте — извини, далеко не пророк
да и все мы тут не боги...
начсет моих доводов — тут уж звиняйте, дорогая редакция, я их привел достаточно, в ответ от тебя получил скупое — "не верю!"
мне такой диалог не инетерсен, мил человек, это игра в одни ворота...
Здравствуйте, Streamer1, Вы писали:
M>>>Если руководитель не знает что делает в данную минуту каждый член его команды , он группой не руководит. B>>Хм... B>>То, что о чем ты говоришь — это не эффективное управление, B>>а тотальный контроль. Нафиг нафиг такие методы . S>согласен, это совковые методы...
Как раз именно не совковые.
Однако, товарищ ошибся в формулировке. Руководитель должен знать не кто что делает в данную минуту, а что _должен_ делать, и когда должен закончить.
Здравствуйте, bralgin, Вы писали:
B>Здравствуйте, minorlogic, Вы писали:
M>>>>Если руководитель не знает что делает в данную минуту каждый член его команды , он группой не руководит.
B>>>Ты лучше книжку напиши: "Новое в менеджменте от Michael Norel"
M>>Ты ошибаешься , если думаешь , что это я сам придумал.
B>Ссылки на первоисточник в студию, пжалуйста!!!
otkrivaem knigu po upravleniu v americanskih companija i vnimatelno chitaem ...
Re: планирование и отчеты сотрудников
От:
Аноним
Дата:
03.06.06 12:26
Оценка:
Здравствуйте, Ed.Nixon, Вы писали:
EN>В небольшой команде программистов (<10 человек) уже используется таск менеджмент система, позволяющая просто ставить задачки, асайнить их и т.п. (аля багзила). Однако хочется повысить уровень самоконтроля. Есть идея ввести следующую процедуру: EN>Каждый составляет свой план работ на месяц и неделю и каждую неделю записывает что он сделал за эту неделю, информацию можно для простоты хранить в wiki. Кроме того каждый будет видеть что делали другие, что является мотивирующим фактором.
EN>Что думаете господа PMы?
Не трать ресуры, а делай все правильно. Я бы посоветовал посетить каой-нибудь хороший трениг по этому поводу. В разных ветках вижу такую траблу. Советую "Человеческий фактор в разработке ПО" или "Управление командами разработчиков" на http://sep.russee.com. Думаю, это хорошее вложение + корка для солидности
) когда дальше проект "динамить" больше нельзя было все стали высказывать то что в душе накопилось. Короче когда все всё высказали там прям на месте порешалась половина проблем, а вторая половина обозначилась (раньше они были скрытыми). после этого шеф ВСЕ СВОИ ПРОШЛЫЕ СОВЕЩАНИЯ назвал "пионерскими утренниками"
