Как отличить разгильдяя от... ?
От: Constructor  
Дата: 16.11.04 07:37
Оценка:
Здравствуйте!
В конторе складывается такая ситуация.
Составляется квартальный план, с учетом мнения разработчика. Т.е., по общему мнению руководителя и разработчика плотный, но выполнимый график.
Далее, по прошествии некоторого времени, руководитель выдает разработчику дополнительное срочное, жизненно важное задание. Обычно не надолго, на 2-3 недели. За квартал так может быть 1-2 раза. Такие задания обычно не вносятся в план.
По прошествии квартала разработчик отчитывается за свой первоначальный план, а дополнительные задания упускаются из рассмотрения. Чаще всего, естественно, разработчик свой план выполнить неуспевает.
Поднимается вопрос о том, что разработчик — разгильдяй.

Это с одной стороны. Я сам часто бываю таким разработчиком.

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

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

Всх ровнять под одну гребенку нехорошо... Хотелось бы научиться ненавязчиво контролировать, кто чем занимается, кто сталкивается с какими трудностями. Научиться достоверно определять: если человек не справился с работой, то это из-за 1) разгильдяейства или 2) его еще слабой подготовки или 3) недооценки сложности задачи.
Причем чтобы свои оценки можно было четко обосновать. И руководителю, и подчиненному.

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


28.11.04 14:24: Перенесено из 'О работе'
Re: Как отличить разгильдяя от... ?
От: AleXXus Россия  
Дата: 16.11.04 07:57
Оценка:
Здравствуйте, Constructor, Вы писали:

C>Здравствуйте!

C>В конторе складывается такая ситуация.
C>Составляется квартальный план, с учетом мнения разработчика. Т.е., по общему мнению руководителя и разработчика плотный, но выполнимый график.

<<< skipped >>>

C>Вот такая у вот проблема... Поделитесь опытом, пожалуйста!


Присоединяюсь, тоже очень хотелось бы узнать, кто что мыслит и делает по этому поводу!
________________________________
When in Rome, do as the Romans do...
Re: Как отличить разгильдяя от... ?
От: kittown  
Дата: 16.11.04 08:01
Оценка: 14 (3) +3
Constructor wrote:
>
> С другой стороны, было уже несколько раз, что я выступал в роли
> руководителя.
> Я предлагал человеку сделать определенную работу. Вместе мы обсуждали
> объем и сроки. Вроде бы было полное согласие. И после этого план свой он
> не выполнял. Я вроде следил, чтобы никаких других работ у него не было.

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

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

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

Mikhail
Posted via RSDN NNTP Server 1.9 gamma
Re: Как отличить разгильдяя от... ?
От: bisrek  
Дата: 16.11.04 08:24
Оценка:
1. Отчеты должны быть не раз в квартал, а раз в неделю (вообще периодичность зависит от конкретного разработчика)

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

3. Если ставиться срочное задание — оно вноситься в план — план сдвигается.
Re: Как отличить разгильдяя от... ?
От: bkat  
Дата: 16.11.04 08:31
Оценка:
Здравствуйте, Constructor, Вы писали:


C>Далее, по прошествии некоторого времени, руководитель выдает разработчику дополнительное срочное, жизненно важное задание. Обычно не надолго, на 2-3 недели. За квартал так может быть 1-2 раза. Такие задания обычно не вносятся в план.


Квартал — 4 месяца (около 19 недель).
2 раза срочные задания на 3 недели — это 6 недель.
Т.е. человек перегружается где-то на треть. На самом деле даже больше.
Если хорошо загруженную лошадь загрузить еще на треть от уже существующего,
то она какое-то время конечно протянет, но вероятность того, что она сдохнет — велика.

В общем начальство, давая дополнительные задания, должно это учитывать
и не очень верить программеру, который говорит, что все ОК и он справится...
Re[2]: Как отличить разгильдяя от... ?
От: kochmin_alexandr Россия  
Дата: 16.11.04 08:36
Оценка: +2 -11
A> Присоединяюсь, тоже очень хотелось бы узнать, кто что мыслит и делает по
A> этому поводу!

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

С уважением
Кочмин Александр
Posted via RSDN NNTP Server 1.9 gamma
Re: Как отличить разгильдяя от... ?
От: BalTun Россия  
Дата: 16.11.04 08:47
Оценка: 5 (1) +2 -2
А может, г-н Конструктор, причина в вашей некомпетентности как управленца ?
Может Вы вовсе не то контроллируете и Вам стоит подтянуть свой профессиональный уровень, а не искать причину в подчиненных ?
С уважением,
Илья Колесников
Re: Как отличить разгильдяя от... ?
От: StanislavK Великобритания  
Дата: 16.11.04 08:50
Оценка:
Здравствуйте, Constructor, Вы писали:

C>Здравствуйте!

C>В конторе складывается такая ситуация.

Если имеется грамотное планирование, то всем известно, чем человек занимается сейчас. А при повялении дополнительных тасков их надо вставлять в общий план, пусть даже и в виде пустых мест. Раз в неделю проводить синхронизацию плана и результатов.
В общем, мне не совсем понятно в чем проблема
Re[3]: Как отличить разгильдяя от... ?
От: Дед Пихто  
Дата: 16.11.04 09:10
Оценка: +1
Здравствуйте, kochmin_alexandr, Вы писали:
_>Ежедневный отчет о проделанной работе.
Ага, с обязательным указанием чего полезного ты сделал для фирмы за этот день. Извини, не удержался.
Возможно для кодера, воплощающего конретное задание в конкретный код, ежедневный (само)отчет будет полезен. Но когда ты ищешь решение, создаешь каркас, читаешь справочную литературу, обдумываешь детали... Imho, отчеты должны отражать этапы выполнения работ, их результат. Ежедневно — это слишком часто.
Re[3]: Как отличить разгильдяя от... ?
От: SergeySPb Россия  
Дата: 16.11.04 10:33
Оценка: 80 (15) +4 :))) :))) :))) :))) :))) :)))
Здравствуйте, kochmin_alexandr, Вы писали:

_>Ежедневный отчет о проделанной работе. И желательно в письменном (электронном) виде.


Всегда хотел узнать: почему руководство предпочитает задания раздавать в устной форме,
а отчёты получать в письменной.
Re[4]: Как отличить разгильдяя от... ?
От: Tan4ik Россия  
Дата: 16.11.04 10:36
Оценка: +1
Здравствуйте, Дед Пихто, Вы писали:

ДП>Здравствуйте, kochmin_alexandr, Вы писали:

_>>Ежедневный отчет о проделанной работе.
ДП>Ага, с обязательным указанием чего полезного ты сделал для фирмы за этот день. Извини, не удержался.
ДП>Возможно для кодера, воплощающего конретное задание в конкретный код, ежедневный (само)отчет будет полезен. Но когда ты ищешь решение, создаешь каркас, читаешь справочную литературу, обдумываешь детали... Imho, отчеты должны отражать этапы выполнения работ, их результат. Ежедневно — это слишком часто.

Ежедневно — нормально. Только не надо требовать от ежедневного отчета сильной детализации. В 3-4 предложения свою работу за день можно упихнуть.
---
С уважением,
Лазарев Андрей
Re[4]: Как отличить разгильдяя от... ?
От: olegkr  
Дата: 16.11.04 10:44
Оценка:
Здравствуйте, SergeySPb, Вы писали:

SSP>Всегда хотел узнать: почему руководство предпочитает задания раздавать в устной форме,

SSP>а отчёты получать в письменной.

Не всегда. У нас таски раздаются через трэкер. В конце дня отчет о том, какие таски закрыл, какие подвисли. Если таска большая (это редкость) — сколько % по ней сделано.
Re: Как отличить разгильдяя от... ?
От: Dimonka Верблюд  
Дата: 16.11.04 11:06
Оценка: 1 (1)
Здравствуйте, Constructor, Вы писали:

[skip]

C>Вот такая у вот проблема... Поделитесь опытом, пожалуйста!


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

И ещё о квартальных планах..
Вы бы ещё пятилетками мерить начали
У нас каждую неделю обсуждаются все проекты и каждый месяц готовится финансовый отчёт по всем проектам.
И то проблемы бывают..
Re[2]: Как отличить разгильдяя от... ?
От: Дарней Россия  
Дата: 16.11.04 11:14
Оценка: :))) :))
Здравствуйте, BalTun, Вы писали:

BT>А может, г-н Конструктор, причина в вашей некомпетентности как управленца ?

BT>Может Вы вовсе не то контроллируете и Вам стоит подтянуть свой профессиональный уровень, а не искать причину в подчиненных ?

Как известно, карьерный рост продолжается, пока работник не достиг своего уровня некомпетентности. А когда достигнет, тогда он остается работать на текущей должности
(C) законы Мерфи
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[5]: Как отличить разгильдяя от... ?
От: SergeySPb Россия  
Дата: 16.11.04 12:23
Оценка:
Здравствуйте, olegkr, Вы писали:

O>Здравствуйте, SergeySPb, Вы писали:


SSP>>Всегда хотел узнать: почему руководство предпочитает задания раздавать в устной форме,

SSP>>а отчёты получать в письменной.

O>Не всегда. У нас таски раздаются через трэкер. В конце дня отчет о том, какие таски закрыл, какие подвисли. Если таска большая (это редкость) — сколько % по ней сделано.


Во! В итоге надо поставить 3-4 галочки и 2-3 раза написать 50%

А как вы называетесь?
И что за трэкер? В смысле — ваш внутренний продукт или нет.
Re[2]: Как отличить разгильдяя от... ?
От: Constructor  
Дата: 16.11.04 12:40
Оценка: :))) :)
Здравствуйте, bkat, Вы писали:

B>Здравствуйте, Constructor, Вы писали:



C>>Далее, по прошествии некоторого времени, руководитель выдает разработчику дополнительное срочное, жизненно важное задание. Обычно не надолго, на 2-3 недели. За квартал так может быть 1-2 раза. Такие задания обычно не вносятся в план.


B>Квартал — 4 месяца (около 19 недель).

Квартал — 3 месяца. Год разбивается на 4 части, отсюда — название
Re: Как отличить разгильдяя от... ?
От: mihhon  
Дата: 16.11.04 12:47
Оценка:
очень просто, каждый человек ведёт ежедневные записи — что делал и сделал за день. 3-4-... (смотря сколько сделал) фразы, тратишь на это пару минут в день. очень удобно. в любой момент можешь ответить, что делал в конкретный день пару месяцев назад. или год назад.
я делаю для себя в Excel табличке и параллельно в MSProject (MSProject не только для этого, конечно, используется) для точных отчётов по команде (кто, сколько, когда на какую задачу потратил)

Excel, колонки:
Дата    Задачи    Выполнено    Потеряно(часы)    Комментарий


Потом по такой табличке очень удобно делать оценки и планы на похожие проекты.
Re[3]: Как отличить разгильдяя от... ?
От: bkat  
Дата: 16.11.04 13:04
Оценка: :)))
Здравствуйте, Constructor, Вы писали:

C>Здравствуйте, bkat, Вы писали:


B>>Здравствуйте, Constructor, Вы писали:



C>>>Далее, по прошествии некоторого времени, руководитель выдает разработчику дополнительное срочное, жизненно важное задание. Обычно не надолго, на 2-3 недели. За квартал так может быть 1-2 раза. Такие задания обычно не вносятся в план.


B>>Квартал — 4 месяца (около 19 недель).

C>Квартал — 3 месяца. Год разбивается на 4 части, отсюда — название

Как, в году разве не 16 месяцев?
Ну блин вообще заработался
Мне как раз подкинули срочное задание...
Так что тема жизненная
Re: Как отличить разгильдяя от... ?
От: Constructor  
Дата: 16.11.04 13:29
Оценка:
Здравствуйте, Constructor, Вы писали:

Ситуация у нас намного хуже идеальной

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

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

Не спрашивайте, почему так. Не ругайтесь на такое положение дел. Я ситуацию изменить не могу, в том числе и уволиться. Моя задача сейчас — адаптироваться к такой системе.


Теперь по поводу предложений и замечаний:

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

Складывается впечатление о некоторых людях, что пол-дня сидит в инете, а пол-дня в развалочку что-то делает. И думает, что так и надо.
Мне приходило в голову ходить несколько раз в день и спрашивать, чем занимаешься. Подозреваю, что это не лучший вариант...

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

Да еще часто есть задачи, трудоемкость которых трудновато оценить...

Наверное, нужно сделать так:

Ввести планирование по неделям
Заставить людей писать ежедневный краткий отчет.
В принципе, можно еще еженедельные коллективные обсуждения устраивать...

Я почему озадачился этим вопросом.
Я вроде себя разгильдяем не считаю. С другой стороны, со мной работает человек, про которого все отзываются, что отдачи от него мало. С третьей стороны, начальник меня часто пытается убедить, что я разгильдяй (см. первое сообщение про квартальный план).
Вроде бы, с одной стороны, можно четко определить, кто разгильдяй, а кто — нет, а с другой — все разгильдяи.
И вот вчера приходит ко мне коллега (новенький) и жалуется, мол дал задание: разобраться с задачей автоматизированного тестирования и освоить одно из средств. Называет того разгильдяем. Вот я и задумался, как мне определить, это разгильдяй или слабенький сотрудник или его действительно отвлекали другими работами.

Re[2]: Как отличить разгильдяя от... ?
От: kittown  
Дата: 16.11.04 13:50
Оценка: 4 (1)
Constructor wrote:
>
> И вот вчера приходит ко мне коллега (новенький) и жалуется, мол дал
> задание: разобраться с задачей автоматизированного тестирования и
> освоить одно из средств. Называет того разгильдяем. Вот я и задумался,
> как мне определить, это разгильдяй или слабенький сотрудник или его
> действительно отвлекали другими работами.

Думать, наблюдать, его спросить, универсальных ответов нет.

На самом деле его может что-то сильно не устраивать и он может торчать
в том же инете на нервной почве.

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

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

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

Даже не знаю, как различить эти варианты со стороны.

Mikhail
Posted via RSDN NNTP Server 1.9 gamma
Re: Как отличить разгильдяя от... ?
От: Spidola Россия http://www.usametrics.ru
Дата: 16.11.04 13:54
Оценка: 74 (14) +1
Отчёты за каждый день — это фигня, поскольку если есть чего сделанного, то это и так видно и на отчёт время жалко тратить, а если ничего не сделано, то грамотный косильщик всегда правдоподобное объяснение придумает...

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

Как вы будете планировать — это ваше дело. Можете конспектировать беседу с разработчиками, можете вести свой Project в каком-нибудь тулзе — это ваши проблемы. Главное, что ведение проекта в части соответствия факта плану — это работа ваша, а не разработчика, и заставлять его писать отчёты о проделанной работе — это вредная видимость управления.

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

Примерно так вкратце...
... << RSDN@Home 1.1.4 @@subversion >>
Re[2]: Как отличить разгильдяя от... ?
От: GUID Россия  
Дата: 16.11.04 13:58
Оценка:
Здравствуйте, kittown, Вы писали:

А техника изготовления за пару недель прототипа, моделирующего всю сложную систему, Вам не известна. Если Вы не занимались областью — берете время на ее изучение (две недели, месяц, полгода — сколько надо) — пишете тестовые примеры и т.п. Потом Вы сможете точно расписать девелопмент план на полгода, поскольку для Вас уже не будет неизвестных мест.
Re[6]: Как отличить разгильдяя от... ?
От: olegkr  
Дата: 16.11.04 14:07
Оценка:
Здравствуйте, SergeySPb, Вы писали:

SSP>А как вы называетесь?

SSP>И что за трэкер? В смысле — ваш внутренний продукт или нет.

Практически тот же самый, что на source-forge.net Не особо навороченный, но хватает.
Re[3]: Как отличить разгильдяя от... ?
От: kittown  
Дата: 16.11.04 14:19
Оценка: 1 (1) +1
GUID wrote:
>
> Здравствуйте, kittown, Вы писали:
>
> А техника изготовления за пару недель прототипа, моделирующего всю
> сложную систему, Вам не известна. Если Вы не занимались областью —
> берете время на ее изучение (две недели, месяц, полгода — сколько надо)
> — пишете тестовые примеры и т.п. Потом Вы сможете точно расписать
> девелопмент план на полгода, поскольку для Вас уже не будет неизвестных
> мест.

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

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

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

Hint: нельзя выкладываться на 100% постоянно, наступает burnout.

Mikhail
Posted via RSDN NNTP Server 1.9 gamma
Re[4]: Как отличить разгильдяя от... ?
От: BacCM Россия  
Дата: 16.11.04 17:03
Оценка:
Здравствуйте, bkat, Вы писали:


B>Как, в году разве не 16 месяцев?

Да а в месяце разве не 32 дня?
Ндя упущение
... Люди делятся на 10 категорий: те кто понимают двоичное исчисление и тех кто не понимает
Re: Как отличить разгильдяя от... ?
От: Уважаемый товарищ Аноним  
Дата: 17.11.04 04:52
Оценка:
Здравствуйте, Constructor, Вы писали:

C>Здравствуйте!

C>В конторе складывается такая ситуация.

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

C>Поднимается вопрос о том, что разработчик — разгильдяй.

C>Всх ровнять под одну гребенку нехорошо... Хотелось бы научиться ненавязчиво контролировать, кто чем занимается, кто сталкивается с какими трудностями. Научиться достоверно определять: если человек не справился с работой, то это из-за 1) разгильдяейства или 2) его еще слабой подготовки или 3) недооценки сложности задачи.

C>Причем чтобы свои оценки можно было четко обосновать. И руководителю, и подчиненному.

C>Вот такая у вот проблема... Поделитесь опытом, пожалуйста!


A> Похоже на то, что такая ситуация больше зависит от конторы. В некоторых,

насколько мне известно, она возникает постоянно. И проблема, насколько мне известно,
не в разработчике. Боюсь, что такой контроль осуществлять очень сложно.
И ежеXXX- ые отчеты тут не очень помогут. Вообще это интересная ситуация — когда
есть один программист, у него есть, как минимум один, начальник, и т.д. А Вы не пробовали
изменить структуру? В некоторых из серьёзных софт — контор большинство вопросов решается
исключительно людьми, сведущими в разработке.
Re[5]: Как отличить разгильдяя от... ?
От: hrg Россия  
Дата: 17.11.04 06:30
Оценка: 3 (1) +1
BacCM -> "Re[4]: Как отличить разгильдяя от... ?"

B>>Как, в году разве не 16 месяцев?

B> Да а в месяце разве не 32 дня?
B> Ндя упущение

Это непередовые, непродвинутые конторы. В правильных конторах в сутках 25-26
часов. А под конец месяца/года/проекта их число возрастает до 30.

Yury Kopyl aka hrg | Гордость мешает доходам!
Posted via RSDN NNTP Server 1.9 gamma
Re: Как отличить разгильдяя от... ?
От: Yury_R Россия  
Дата: 17.11.04 07:29
Оценка:
Здравствуйте, Constructor, Вы писали:

C>Здравствуйте!

C>В конторе складывается такая ситуация.
.....
C>Вот такая у вот проблема... Поделитесь опытом, пожалуйста!
Отличить действительно нелегко, но вот несколько замечаний из моего личного опыта:
1. Планируется только обозримый период — месяц, в крайнем случае квартал;
2. Этот месяц заполняется плотно, т.е. если работа больше месяца, выделяется ее часть, оценочно по длительности на месяц, если короче — ставится еще одна задача;
3. Все постановки письменно за подписями как руководителя так и исполнителя;
4. Отчет по каждой задаче. Если задача закончена, отчетом является документация к программе(задаче), если нет — пояснительная записка с описанием завершенной части.
И еще. Ни в коем случае нельзя требовать отчета ежедневного, еженедельного и пр.Со временем поймешь, что это дискредитирует в первую очередь тебя, как руководителя, а исполнитель очень быстро научится баки забивать, и только.
Отчеты же о сделанных задачах вкупе с постановками — есть объективное подтверждение квалификации исполнителя.
Главное — научись планировать, остальное приложится.
Re: Как отличить разгильдяя от... ?
От: Dyusha  
Дата: 17.11.04 07:51
Оценка: +3
Здравствуйте, Constructor, Вы писали:


Можно я выскажусь с точки зрения разработчика. Ненавижу планы!!! Ладно еще, когда тебе говорят — вот тебе два месяца — напиши за это время программу, но когда заставляют расписывать планы по дням, а то и по часам, то это КОШМАР. Честное слово, это блокирует всю работу. Это еще можно делать, когда работа тупая, механическая, но когда работа творческая........ И вместо того, чтобы спокойно окунуться в процесс разработки ты решаешь ребусы: как составить эти планы, чтобы начальник не придрался, как отчитываться по ним. Например, неделя ушла на отлавливание какого-нибудь злостного глюка в программе. И что писать в отчете? Напишешь как есть, начальник точно разгильдяем посчитает, приходится что-то придумывать, выкручиваться. Как можно разделить задачу?
У нас принято делить по формам. Но разве можно сделать сначала одну форму от начала до конца, потом другую. Все же взаимосвязано. Да и не в формах дело, вначале какие-то общие принципы придумываешь, стиль программы в конуе концов. И как это все в планах учитывать???
В общем, КОШМАР!!!
Жизнь — это сражение, которое ты всегда проигрываешь.
Re[3]: Как отличить разгильдяя от... ?
От: kbasil Россия  
Дата: 17.11.04 07:53
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, BalTun, Вы писали:


BT>>А может, г-н Конструктор, причина в вашей некомпетентности как управленца ?

BT>>Может Вы вовсе не то контроллируете и Вам стоит подтянуть свой профессиональный уровень, а не искать причину в подчиненных ?

Д>Как известно, карьерный рост продолжается, пока работник не достиг своего уровня некомпетентности. А когда достигнет, тогда он остается работать на текущей должности

Д>(C) законы Мерфи

Это один из законов Паркинсона
Re[2]: Как отличить разгильдяя от... ?
От: minorlogic Украина  
Дата: 17.11.04 08:15
Оценка:
Я только вот чего не понимаю, какая разница "разгильдяй" человек или нет ? Если это трудолюбивое ничтожество то он лучше талантдивого разгильдяя ?
Какая разница ?
Надо смотреть на работу которую они выполняют, и ВСЕ.

То есть оценивать ПРОДУКТИВНОСТЬ а не СТАРАНИЯ.

Я при поступлении на работу СРАЗУ оговариваю что 8 часов в сутки я не могу продуктивно работать , только 3-4 часа. Остальное время я трачу на обсуждение самообучение исследования отдых и т.д. (на порно сайты не хожу).
Если меня кто то назовет разгильляем , я обижусь. Это просто мой ВЫСОКО ПРОДУКТИВНЫЙ режим работы.
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[3]: Как отличить разгильдяя от... ?
От: Anatolix Россия https://www.linkedin.com/in/anatolix/
Дата: 17.11.04 10:25
Оценка: 1 (1) +1
Здравствуйте, minorlogic, Вы писали:

M>Я только вот чего не понимаю, какая разница "разгильдяй" человек или нет ? Если это трудолюбивое ничтожество то он лучше талантдивого разгильдяя ?

M>Какая разница ?
M>Надо смотреть на работу которую они выполняют, и ВСЕ.

Я ничего против не имел бы против талантливого разгильдяя чье разильдяйство выражается в том что он работает 2 часа в день, но когда разгильдяйство проявляется в том что человек в принипе не способен самостоятельно работать и выливается это в то что за ним нужно код читать то нафиг-нафиг. Пусть хоть таланливей Энштейна будет — пусть хоть в дворники хоть в ученые идет, лишь бы подальше.

M> То есть оценивать ПРОДУКТИВНОСТЬ а не СТАРАНИЯ.


Это точно.

M>Я при поступлении на работу СРАЗУ оговариваю что 8 часов в сутки я не могу продуктивно работать , только 3-4 часа. Остальное время я трачу на обсуждение самообучение исследования отдых и т.д. (на порно сайты не хожу).

M>Если меня кто то назовет разгильляем , я обижусь. Это просто мой ВЫСОКО ПРОДУКТИВНЫЙ режим работы.

Он у всех такой. Brain Time vs Body Time по книжке Peopleware 50% почти никогда не превышает. Обычно он меньше. Так что можешь не оговаривать — все и так знают.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Re[2]: Как отличить разгильдяя от... ?
От: Spidola Россия http://www.usametrics.ru
Дата: 17.11.04 10:39
Оценка: 1 (1)
Здравствуйте, Dyusha, Вы писали:

D>Здравствуйте, Constructor, Вы писали:



D>Можно я выскажусь с точки зрения разработчика. Ненавижу планы!!! Ладно еще, когда тебе говорят — вот тебе два месяца — напиши за это время программу, но когда заставляют расписывать планы по дням, а то и по часам, то это КОШМАР. Честное слово, это блокирует всю работу. Это еще можно делать, когда работа тупая, механическая, но когда работа творческая........ И вместо того, чтобы спокойно окунуться в процесс разработки ты решаешь ребусы: как составить эти планы, чтобы начальник не придрался, как отчитываться по ним. Например, неделя ушла на отлавливание какого-нибудь злостного глюка в программе. И что писать в отчете? Напишешь как есть, начальник точно разгильдяем посчитает, приходится что-то придумывать, выкручиваться. Как можно разделить задачу?

D>У нас принято делить по формам. Но разве можно сделать сначала одну форму от начала до конца, потом другую. Все же взаимосвязано. Да и не в формах дело, вначале какие-то общие принципы придумываешь, стиль программы в конуе концов. И как это все в планах учитывать???
D>В общем, КОШМАР!!!

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

Прикиньте, насколько отличается у вас планирование работ от, например, рекомендаций классиков (например, Брукса). Если отличается сильно — есть повод задуматься и поговорить с теми, кто такие планы составляет.


- проектирование — 1/3,
— написание команд -1/6,
— отладка компонент и отдельных подсистем — 1/4,
— системная (комплексная) отладка всех компонент — 1/4.

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

... << RSDN@Home 1.1.4 @@subversion >>
Re[3]: Как отличить разгильдяя от... ?
От: SergeySPb Россия  
Дата: 17.11.04 12:55
Оценка:
Здравствуйте, Spidola, Вы писали:

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

S>(имеется ввиду бизнес-составляющая IT проекта). Нужно просто составлять их правильно.

А вот кто их должен правильно составлять?
Если я нанятый разработчик — я готов в конце дня вот в таком вот тракере
Автор: olegkr
Дата: 16.11.04
отметить что было сделано за день.
Заполнить этот тракер заданиями, расставить их приоритеты — разве этим разработчик должен заниматься?
Re[3]: Как отличить разгильдяя от... ?
От: postmaster  
Дата: 17.11.04 13:13
Оценка:
Здравствуйте, GUID, Вы писали:

GUI>Здравствуйте, kittown, Вы писали:


GUI>А техника изготовления за пару недель прототипа, моделирующего всю сложную систему, Вам не известна. Если Вы не занимались областью — берете время на ее изучение (две недели, месяц, полгода — сколько надо) — пишете тестовые примеры и т.п. Потом Вы сможете точно расписать девелопмент план на полгода, поскольку для Вас уже не будет неизвестных мест.


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

Здоровый авантюризм порой лучше тщательной длительной подготовки.
Re[5]: Как отличить разгильдяя от... ?
От: action_jackson711 Россия http://jacksonviiii.livejournal.com
Дата: 17.11.04 13:21
Оценка:
Здравствуйте, olegkr, Вы писали:

O>Здравствуйте, SergeySPb, Вы писали:


SSP>>Всегда хотел узнать: почему руководство предпочитает задания раздавать в устной форме,

SSP>>а отчёты получать в письменной.

O>Не всегда. У нас таски раздаются через трэкер. В конце дня отчет о том, какие таски закрыл, какие подвисли. Если таска большая (это редкость) — сколько % по ней сделано.


Надо нанимать тогда еще специально обученный персонал, который эти самые таски будет составлять Галочку-то поставим, вопрос- на что. Что значит таск? Детальное ТЗ? А кто его составляет? project manager у которого и так дел по горло?

На самом деле специфика везде разная. Смотря что за контора, чем занимаются, что за отдел и проч...
Re: Как отличить разгильдяя от... ?
От: action_jackson711 Россия http://jacksonviiii.livejournal.com
Дата: 17.11.04 13:28
Оценка:
Почитал советы. Долго думал Роботизм какой-то советуют
А ведь грамотный начальник д.б. а) грамотным программистом, проектировщиком, девелопером и б) грамотным управленцем. ВСЁ!
п. а) позволяет начальнику самому поставить срок, а не обсуждать его с сотрудником
п. б) позволяет адекватно оценивать возможности сотрудника для применения предыдушего шага.
Re[4]: Как отличить разгильдяя от... ?
От: kittown  
Дата: 17.11.04 13:29
Оценка:
postmaster wrote:
>
> GUI>А техника изготовления за пару недель прототипа, моделирующего всю
> сложную систему, Вам не известна. Если Вы не занимались областью —
> берете время на ее изучение (две недели, месяц, полгода — сколько надо)
> — пишете тестовые примеры и т.п. Потом Вы сможете точно расписать
> девелопмент план на полгода, поскольку для Вас уже не будет неизвестных
> мест.
>
> Нередко вопрос "сколько на это потребуется времени" задаётся потому, что
> хочется понять, насколько будет выгодно делать данный проект (успеем по
> срокам, уложимся в бюджет и т.п.).

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

Хороший менеджер всегда следит, где сегодня находится золотая середина,
и действует соответственно. Завтра будет смотреть, где она будет завтра.

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

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

Были проекты именно с такими временными характеристиками, вот только
изучение совмещается с прототипированием и проектированием.

> Здоровый авантюризм порой лучше тщательной длительной подготовки.


Если только стоимость ошибки не превышает возможную прибыль. Бывает
как в случае порчи репутации фирмы, так и в случае нестабильности
продута при обновлении. Начиная с АЭС и заканчивая банкоматами.

Mikhail
Posted via RSDN NNTP Server 1.9 gamma
Re[4]: Как отличить разгильдяя от... ?
От: Spidola Россия http://www.usametrics.ru
Дата: 17.11.04 13:35
Оценка:
Здравствуйте, SergeySPb, Вы писали:

SSP>Здравствуйте, Spidola, Вы писали:


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

S>>(имеется ввиду бизнес-составляющая IT проекта). Нужно просто составлять их правильно.

SSP>А вот кто их должен правильно составлять?

SSP>Если я нанятый разработчик — я готов в конце дня вот в таком вот тракере
Автор: olegkr
Дата: 16.11.04
отметить что было сделано за день.

SSP>Заполнить этот тракер заданиями, расставить их приоритеты — разве этим разработчик должен заниматься?

Таски должны акцептироваться разработчиком либо отклоняться с указанием причин. Если этого не делается, то есть несколько вариантов исхода:
1) Время на таски выделяется правильно, но разработчик не соответствует принятому в компании уровню. BAD DEVELOPER
2) Время на таски занижается, разработчик заведомо не успевает. BAD MANAGER
3) Все таски типичные и время выделяется правильно, разработчик учпевает. GOOD BOTH
... << RSDN@Home 1.1.4 @@subversion >>
Re[5]: Как отличить разгильдяя от... ?
От: Flamer Кипр http://users.livejournal.com/_flamer_/
Дата: 17.11.04 13:40
Оценка: :))) :))) :))
Здравствуйте, Spidola, Вы писали:

[]

S>Таски должны акцептироваться разработчиком либо отклоняться с указанием причин. Если этого не делается, то есть несколько вариантов исхода:

S>1) Время на таски выделяется правильно, но разработчик не соответствует принятому в компании уровню. BAD DEVELOPER
S>2) Время на таски занижается, разработчик заведомо не успевает. BAD MANAGER
S>3) Все таски типичные и время выделяется правильно, разработчик учпевает. GOOD BOTH

Есть еще как минимум один вариант:

4) Все таски типичные и время выделяется правильно, но маленькая зарплата. ШЕФ ЖМОТ.
... << RSDN@Home 1.1.3 stable >>
Re[2]: Как отличить разгильдяя от... ?
От: Spidola Россия http://www.usametrics.ru
Дата: 17.11.04 13:43
Оценка: 1 (1) +2 -1
Здравствуйте, action_jackson711, Вы писали:

_>Почитал советы. Долго думал Роботизм какой-то советуют

_>А ведь грамотный начальник д.б. а) грамотным программистом, проектировщиком, девелопером и б) грамотным управленцем. ВСЁ!
_>п. а) позволяет начальнику самому поставить срок, а не обсуждать его с сотрудником
_>п. б) позволяет адекватно оценивать возможности сотрудника для применения предыдушего шага.

Не согласен.

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

Адекватно оценивать начальник может либо на основании устоявшихся правил и норм, либо путём аудита решения разработчика. Что позволяет начальнику опять таки не быть разработчиком.

Насчёт управленца — это TO BE, а не AS IS. Все начальники на N% грамотные управленцы... К сожалению диапазон N великоват...

P.S. Начальник, который одновременно и разработчик, это, простите, "попа", поскольку редко кто из таких начальников удерживается от давания ненужных и бенстолковых советов, чувствуя себя "старым морским волком", или не лезет "внутрь решения" вместо оценки его работспособности в контексте задачи.
... << RSDN@Home 1.1.4 @@subversion >>
Re[6]: Как отличить разгильдяя от... ?
От: olegkr  
Дата: 17.11.04 13:46
Оценка: :))) :)
Здравствуйте, action_jackson711, Вы писали:

_>Надо нанимать тогда еще специально обученный персонал, который эти самые таски будет составлять Галочку-то поставим, вопрос- на что. Что значит таск? Детальное ТЗ? А кто его составляет? project manager у которого и так дел по горло?


Пример таски от PM: Я говорил с клиентом, он хочет что бы эта кнопка была круглой, а надпись на ней желтого цвета
Пример таски от архитектора: Я обнаружил, что при перерисовке грида постоянно дергается сервак. Надо делать кэш.
Пример таски от девелопера: Какой урод писал этот кусок программы???? Валиться с NullPointerException каждый раз, как пытаюсь закрыть окно!!!
Re[3]: Как отличить разгильдяя от... ?
От: action_jackson711 Россия http://jacksonviiii.livejournal.com
Дата: 17.11.04 13:55
Оценка: 3 (1) +1 -1
Здравствуйте, Spidola, Вы писали:

S>Здравствуйте, action_jackson711, Вы писали:


_>>Почитал советы. Долго думал Роботизм какой-то советуют

_>>А ведь грамотный начальник д.б. а) грамотным программистом, проектировщиком, девелопером и б) грамотным управленцем. ВСЁ!
_>>п. а) позволяет начальнику самому поставить срок, а не обсуждать его с сотрудником
_>>п. б) позволяет адекватно оценивать возможности сотрудника для применения предыдушего шага.

S>Не согласен.


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


Лишний человек. Хорошо или плохо- но факт.

S>Адекватно оценивать начальник может либо на основании устоявшихся правил и норм, либо путём аудита решения разработчика. Что позволяет начальнику опять таки не быть разработчиком.


S>Насчёт управленца — это TO BE, а не AS IS. Все начальники на N% грамотные управленцы... К сожалению диапазон N великоват...


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


с PS: не согласен. Детский сад с его сказками про "старого морского волка" отметаем Грамотный начальник не будет приставать к тебе (у него и так дел по горло), если твой модуль, юнит, программа работает нормально. Зато если возникнет такая ситуация, что реально необходимо что-то подправить в модуле, а ты в командировке (в другом часовом поясе и без мобильника), а остальные сотрудники загружены по полной. То начальник-девелопер абсолютно без зазрения совести и брезгливости лезет в твой код и правит баг. Заметим, баг по дефолту не может быть серьезным раз его до этого не заметили
Re[5]: Как отличить разгильдяя от... ?
От: SergeySPb Россия  
Дата: 17.11.04 14:06
Оценка:
Здравствуйте, Spidola, Вы писали:

S>Таски должны акцептироваться разработчиком либо отклоняться с указанием причин. Если этого не делается, то есть несколько вариантов исхода:

S>1) Время на таски выделяется правильно, но разработчик не соответствует принятому в компании уровню. BAD DEVELOPER
S>2) Время на таски занижается, разработчик заведомо не успевает. BAD MANAGER
S>3) Все таски типичные и время выделяется правильно, разработчик учпевает. GOOD BOTH

Уточните: Поставленные кем "Таски должны акцептироваться разработчиком либо отклоняться с указанием причин" ?
Ведь одно дело расписать по таскам "кому что делать", и совсем другое — написать "это буду делать я", "я этого делать не буду, потому что ...".

Ну ещё соглашусь написать так: "это буду делать я и сделаю за 8 часов, если с другими task-ами дёргать не будут".

Уважаемый Dyusha — он же ведь разработчик, а его "заставляют расписывать планы по дням, а то и по часам". И таких как он очень много.
Re[3]: Как отличить разгильдяя от... ?
От: Spaider Верблюд  
Дата: 17.11.04 14:09
Оценка:
Здравствуйте, minorlogic, Вы писали:

M> То есть оценивать ПРОДУКТИВНОСТЬ а не СТАРАНИЯ.


Ну, если у человек старание стремиться к нулю, то его продуктивность в лучше случае будет невозрастающей.
Под старанием я понимание в т.ч. и способность к (само)обучению.

Я, конечно, как руководитель не копенгаген, но IMHO взять человека, который мало знает, но старается узнать что-то новое -- это лучше, чем взять кренделя, который что-то да знает, но ничего другого знать не хочет. В первом варианте отдача в конечном итого поболе будет.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
--
К вашим услугам,
Re[6]: Как отличить разгильдяя от... ?
От: Spidola Россия http://www.usametrics.ru
Дата: 17.11.04 14:23
Оценка:
Здравствуйте, SergeySPb, Вы писали:

SSP>Здравствуйте, Spidola, Вы писали:


S>>Таски должны акцептироваться разработчиком либо отклоняться с указанием причин. Если этого не делается, то есть несколько вариантов исхода:

S>>1) Время на таски выделяется правильно, но разработчик не соответствует принятому в компании уровню. BAD DEVELOPER
S>>2) Время на таски занижается, разработчик заведомо не успевает. BAD MANAGER
S>>3) Все таски типичные и время выделяется правильно, разработчик учпевает. GOOD BOTH

SSP>Уточните: Поставленные кем "Таски должны акцептироваться разработчиком либо отклоняться с указанием причин" ?

SSP>Ведь одно дело расписать по таскам "кому что делать", и совсем другое — написать "это буду делать я", "я этого делать не буду, потому что ...".

SSP>Ну ещё соглашусь написать так: "это буду делать я и сделаю за 8 часов, если с другими task-ами дёргать не будут".


SSP>Уважаемый Dyusha — он же ведь разработчик, а его "заставляют расписывать планы по дням, а то и по часам". И таких как он очень много.


Если это работа по найму, то весь процесс можно кратко расписать так:
1. Менеджер (или руководитель проекта, или ведущий разработчик... начальник, в общем) расписывает задачи/сроки и раздаёт их разработчикам.
2. Разработчики рассматривают задачи и ставят пометку: "принято к исполнению" или "не принято к исполнению".
3.1. Если принято, то всё нормально. Таск должен быть выполнен в срок.
3.2. Если не принято, то должна указываться причина, почему не принято и проводиться обсуждение, которое приводит либо к увеличению срока, либо к уменьшению объёма таска. (Ну, либо, к смене разработчика в более жёстком варианте). Иначе срок будет гарантированно сорван.

Расписывать разработчику свой план самому имеет смысл, если начальников несколько (т.е. несколько работ, которые нужно приоретизировать).
... << RSDN@Home 1.1.4 @@subversion >>
Re: Как отличить разгильдяя от... ?
От: LaptevVV Россия  
Дата: 17.11.04 14:36
Оценка: 16 (2) +2
Здравствуйте, Constructor, Вы писали:

C>Здравствуйте!

C>В конторе складывается такая ситуация.
C>Составляется квартальный план, с учетом мнения разработчика.
C>Т.е., по общему мнению руководителя и разработчика плотный, но выполнимый график.
Вот именно — по мнению!
Нет объективной оценки времени выполнения работы. По собственному опыту и руководителя и разработчика знаю, что программисты — оптимисты по натуре своей, поэтому подсознательно сроки ставят меньше. чем потребуется реально. Это связано еще и с тем, что человек как правило, не учитывает ни собственную накапливающуюся усталость, ни возможные недомогания, ни тем более форс — мажорные обстоятельства (дополнительную не предусмотренную работу, о которой вы написали).
По многолетнему опыту могу сказаить: после всех договоренностей и согласий можно смело умножать сроки на 2 (а лучше — на Пи ) — тогда это будет похоже на реальный срок выполнения. И это при добросовестном отношении к работе.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[4]: Как отличить разгильдяя от... ?
От: Spidola Россия http://www.usametrics.ru
Дата: 17.11.04 14:54
Оценка: 1 (1)
Здравствуйте, action_jackson711, Вы писали:

_>Здравствуйте, Spidola, Вы писали:


S>>Здравствуйте, action_jackson711, Вы писали:


_>>>Почитал советы. Долго думал Роботизм какой-то советуют

_>>>А ведь грамотный начальник д.б. а) грамотным программистом, проектировщиком, девелопером и б) грамотным управленцем. ВСЁ!
_>>>п. а) позволяет начальнику самому поставить срок, а не обсуждать его с сотрудником
_>>>п. б) позволяет адекватно оценивать возможности сотрудника для применения предыдушего шага.

S>>Не согласен.


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


_>Лишний человек. Хорошо или плохо- но факт.


Кто из них?

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


_>с PS: не согласен. Детский сад с его сказками про "старого морского волка" отметаем Грамотный начальник не будет приставать к тебе (у него и так дел по горло), если твой модуль, юнит, программа работает нормально. Зато если возникнет такая ситуация, что реально необходимо что-то подправить в модуле, а ты в командировке (в другом часовом поясе и без мобильника), а остальные сотрудники загружены по полной. То начальник-девелопер абсолютно без зазрения совести и брезгливости лезет в твой код и правит баг. Заметим, баг по дефолту не может быть серьезным раз его до этого не заметили


"Детский сад" рекомендую не отметать. Если вы с таким детским садом не сталкивались, это не значит, что таких ситуаций нет.

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

И, даже если возникает описанная вами ситуация, то при чём здесь начальник? Вы описали роль девелопера, в которой в вашем случае выступил начальник. Можно взять любого девелопера, который залезет в код с разрешения начальника и "без зазрения совести" всё там поправит...
... << RSDN@Home 1.1.4 @@subversion >>
Re[4]: Как отличить разгильдяя от... ?
От: newuser2  
Дата: 17.11.04 14:58
Оценка:
Здравствуйте, action_jackson711, Вы писали:

_>Здравствуйте, Spidola, Вы писали:


S>>Здравствуйте, action_jackson711, Вы писали:


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

НАЧАЛЬНИК НЕ ДОЛЖЕН ЛАЗИТЬ В КОД!!! ЧТО ЗА ДЕТСКИЙ САД!!!
Если возникает острая нехватка кадров (описанный вами случай) значит надо нанимать ещё одного работника. Если контора не может этого сделать — значит экономит на сотрудниках. Хотя, возможно, вы путаете начальника с тимлидом.
Re[7]: Как отличить разгильдяя от... ?
От: Spidola Россия http://www.usametrics.ru
Дата: 17.11.04 15:06
Оценка:
Здравствуйте, olegkr, Вы писали:

O>Здравствуйте, action_jackson711, Вы писали:


_>>Надо нанимать тогда еще специально обученный персонал, который эти самые таски будет составлять Галочку-то поставим, вопрос- на что. Что значит таск? Детальное ТЗ? А кто его составляет? project manager у которого и так дел по горло?


O>Пример таски от PM: Я говорил с клиентом, он хочет что бы эта кнопка была круглой, а надпись на ней желтого цвета

O>Пример таски от архитектора: Я обнаружил, что при перерисовке грида постоянно дергается сервак. Надо делать кэш.
O>Пример таски от девелопера: Какой урод писал этот кусок программы???? Валиться с NullPointerException каждый раз, как пытаюсь закрыть окно!!!

Типичный таск от пользователя: поменяйте надпись на кнопке с "Add" на "New", а то никому не понятно, что это кнопка...
... << RSDN@Home 1.1.4 @@subversion >>
Re[2]: Как отличить разгильдяя от... ?
От: Anatolix Россия https://www.linkedin.com/in/anatolix/
Дата: 17.11.04 15:13
Оценка: 4 (2)
Здравствуйте, Dyusha, Вы писали:

D>Можно я выскажусь с точки зрения разработчика. Ненавижу планы!!! Ладно еще, когда тебе говорят — вот тебе два месяца — напиши за это время программу, но когда заставляют расписывать планы по дням, а то и по часам, то это КОШМАР. Честное слово, это блокирует всю работу. Это еще можно делать, когда работа тупая, механическая, но когда работа творческая........ И вместо того, чтобы спокойно окунуться в процесс разработки ты решаешь ребусы: как составить эти планы, чтобы начальник не придрался, как отчитываться по ним. Например, неделя ушла на отлавливание какого-нибудь злостного глюка в программе. И что писать в отчете? Напишешь как есть, начальник точно разгильдяем посчитает, приходится что-то придумывать, выкручиваться. Как можно разделить задачу?

D>У нас принято делить по формам. Но разве можно сделать сначала одну форму от начала до конца, потом другую. Все же взаимосвязано. Да и не в формах дело, вначале какие-то общие принципы придумываешь, стиль программы в конуе концов. И как это все в планах учитывать???
D>В общем, КОШМАР!!!

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

Пример
1) Продажники начинают продавать продукт до его готовности т.к. цикл продаж долог но им нужно знать когда будет готово.
2) Заказчик знает когда нужно будет показывать систему конечным пользователям т.к. их нужно собирать со всей страны.
3) Клиент знает когда можно нанимать персонал для внедренного под ключ Call Центра.

Бить разработчиков это вовсе не цель планов, а просто средство соблюдения планов. Притом не самое эффективное. Просто многие об этом забывают.

А конкретно к тебе — со своей ненавистью к планам справиться очень просто. Ты же любишь сложные задания? Воспринимай сроки как дополнительный фактор влияющий на сложность. В смысле что любые идиоты могут заменить декорации на сцене за пол года, но научиться это делать за 30 секунд в перерыве между действиями это исскуство, и уметь это исполнять это некоторый fun.

А руководство которое требует все прямо сейчас покажи что это оценить с большой точностью нельзя. Сошлись что это не умеет делать никто и для примера приведи например Microsoft. У них хорошая картинка есть которую я всегда в таком случае всем показываю.
http://www.microsoft.com/technet/images/itsolutions/techguide/innsol/images/msfpmd07_big.gif
Где сразу видно что на начальном этапе оценки различаются в 16 раз.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Re: Как отличить разгильдяя от... ?
От: xtile  
Дата: 18.11.04 17:04
Оценка:
C>Вот такая у вот проблема... Поделитесь опытом, пожалуйста!

Каждую неделю минисовещание с тимлидом и pm. (обсуждаются задачи на неделю, прикидываются сроки на каждую. Если задача большая — разбивается на части, для выполнения которых нужно 1-2 дня).

Ежедневно — отчеты о проделанной работе (контроль соблюдения сроков). В отчете должно быть зафиксировано все, что отняло более получаса времени.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Re[2]: Как отличить разгильдяя от... ?
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 20.11.04 06:12
Оценка:
Здравствуйте, xtile, Вы писали:

X>Ежедневно — отчеты о проделанной работе (контроль соблюдения сроков). В отчете должно быть зафиксировано все, что отняло более получаса времени.

А крышу не оторвёт?
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[2]: Как отличить разгильдяя от... ?
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 20.11.04 06:50
Оценка: 10 (1) +3
Здравствуйте, Constructor, Вы писали:

C>Я почему озадачился этим вопросом.

Известно, почему. Потому что мозги тебе закомпостировали.

C>Я вроде себя разгильдяем не считаю. С другой стороны, со мной работает человек, про которого все отзываются, что отдачи от него мало. С третьей стороны, начальник меня часто пытается убедить, что я разгильдяй (см. первое сообщение про квартальный план).

C>Вроде бы, с одной стороны, можно четко определить, кто разгильдяй, а кто — нет, а с другой — все разгильдяи.
C>И вот вчера приходит ко мне коллега (новенький) и жалуется, мол дал задание: разобраться с задачей автоматизированного тестирования и освоить одно из средств. Называет того разгильдяем. Вот я и задумался, как мне определить, это разгильдяй или слабенький сотрудник или его действительно отвлекали другими работами.
Да, точно мозги тебе запудрили...

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

Схема такого воздействия очень простая. Объективно твою "вину" можно будет пронаблюдать. Например, сорвал внутренний срок: вместо 5 дней потратил 6. Дальше начальник выключает из рассмотрения все параллельные факторы — что ты чем-то занимался, что были ещё нагрузки, и т.д. и т.п. То есть, вместо анализа работы он концентрируется на личности. И всё, привет. Ты, кстати, сейчас делаешь то же самое.

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

Или у вас такой внутрифирменный стиль "чморения"...

В хороших коллективах не принято называть работников дураками (или разгильдяями). Ну разве что в порядке ответа в стиле "сам дурак". Потому что тот, кто работает с дураками — сам дурак. Улавливаешь? А посему выбрось из головы вопросы личностной оценки сотрудников по шкале "разгильдяй-трудяга". И вообще бинарную схему оценки выбрось. А то получается, что хоть ты сам и обижаешься на своего шефа за то, что он называет тебя "разгильдяем", но уже почти совсем готов пойти по его стопам. Ай-яй-яй. Прям в точности по принципу: "меня чморили, его тоже надо почморить".



По моему скромному опыту больше всего неприятностей вызывает честный и исполнительный трудяга. Почему так получается, не знаю. Но подозреваю, что здесь задействован принцип "несдвигания сроков во что бы то ни стало". Во всяком случае, от тех, кто строг и исполнителен в административном смысле проблемы в архитектуре или кривой API получить удавалось чаще, чем от лентяев, к которым как ни зайдёшь, так они либо в инете сидят, либо музыку слушают, либо ещё чем-то занимаются.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re: Как отличить разгильдяя от... ?
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 20.11.04 07:14
Оценка: 15 (2) +2 :)
Здравствуйте, Constructor, Вы писали:

Написал тебе это
Автор: Геннадий Васильев
Дата: 20.11.04
и вдруг понял, что ты, хулиган, ищешь способ обосновать оскорбление. Ну ни фига себе заявочки! Да мало того, что ищешь, так ещё и считаешь, что к тебе сие справедливо применили. Ну ваще дела...

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

C>Поднимается вопрос о том, что разработчик — разгильдяй.
А по мне так руководство страдает хронической олигофренией. И что? До много так можно договориться?

C>Это с одной стороны. Я сам часто бываю таким разработчиком.

Угу, комплекс неполноценности начинает развиваться.

C>С другой стороны, было уже несколько раз, что я выступал в роли руководителя.

Ой, беда...

C>Я предлагал человеку сделать определенную работу. Вместе мы обсуждали объем и сроки. Вроде бы было полное согласие. И после этого план свой он не выполнял. Я вроде следил, чтобы никаких других работ у него не было.

Вспомни, не задавал ли ты ему вопросов: "Назвови минимальный срок, за который ты управишься", "А нельзя ли побыстрее?", "Почему так долго?". Как ты обосновывал подобные пожелания?

C>Складывается такая ситуация: практически не отслеживается, кто, когда и чем занимался. Точно могу сказать, что разные люди у нас выполняют совершенно разный объем работ. Разные люди разное время проводят в инете. Разные люди проявляют разный интерес к освоению новых технологий и разную степень стремления к повышению своей квалификации.

"Узнаю тип и узнаю калибр" (c) Луи Буссенар. А з/п у всех примерно одинаковая.

C>Всх ровнять под одну гребенку нехорошо... Хотелось бы научиться ненавязчиво контролировать, кто чем занимается, кто сталкивается с какими трудностями. Научиться достоверно определять: если человек не справился с работой, то это из-за 1) разгильдяейства или 2) его еще слабой подготовки или 3) недооценки сложности задачи.

Первую причину убираем до точного определения понятия "разгильдяй". Вторая требует определения критериев достаточной подготовленности. Относительно третьей можно ответить вопросом на вопрос: а сам-то ты часто сходу определял сложность задачи? Ну хотя бы контекстные факторы удавалось учесть все без исключения? Кстати, все три названные тобой причины можно свести к недостаточной добросовестности сотрудника. Почему? Оставляю это тебе в качестве домашнего задания. Ответишь на этот вопрос — ответишь и на другие, связанные с выявлением реальных факторов.

C>Причем чтобы свои оценки можно было четко обосновать. И руководителю, и подчиненному.

Ну суперская задача! Обосновать титул "разгильдяй". Ага, и шкалу разработать: "разгильдяй — рсп%$дяй — гуру".
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re: Как отличить разгильдяя от... ?
От: Gaperton http://gaperton.livejournal.com
Дата: 21.11.04 15:18
Оценка: 17 (2)
Здравствуйте, Constructor, Вы писали:

C>Всх ровнять под одну гребенку нехорошо... Хотелось бы научиться ненавязчиво контролировать, кто чем занимается, кто сталкивается с какими трудностями. Научиться достоверно определять: если человек не справился с работой, то это из-за 1) разгильдяейства или 2) его еще слабой подготовки или 3) недооценки сложности задачи.

4) Из-за отсутствия у руководителя элементарных знаний в project management, управлении рисками и планировании. Критерий прост. Если программисты у такого руководителя систематически срывают план (и/или работают сверхурочно), то его надо снимать с должности по несоответствию. Это — инструкция для руководителя руководителя. А по другому ответить нельзя — ответ из специализированной литературы чрезвычайно развернут.
Re[3]: Как отличить разгильдяя от... ?
От: xtile  
Дата: 21.11.04 15:29
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, xtile, Вы писали:


X>>Ежедневно — отчеты о проделанной работе (контроль соблюдения сроков). В отчете должно быть зафиксировано все, что отняло более получаса времени.

ГВ>А крышу не оторвёт?

Вам как отвечать, абстрактно, в вашем же тоне, или конкретно ?

Конкретно: конторе 6 лет, текучка очень маленькая.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Re: Как отличить разгильдяя от... ?
От: cencio Украина http://ua-coder.blogspot.com
Дата: 21.11.04 15:41
Оценка:
Здравствуйте, Constructor, Вы писали:

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

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

C>Складывается такая ситуация: практически не отслеживается, кто, когда и чем занимался....

<skipped>
C>Поднимается вопрос о том, что разработчик — разгильдяй.

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

наверное в сабже спрашивается опознать разгильдяя начальника, а ответ на это дается уже в самом месадже
Re[4]: Как отличить разгильдяя от... ?
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 21.11.04 17:19
Оценка: +2
Здравствуйте, xtile, Вы писали:

X>>>Ежедневно — отчеты о проделанной работе (контроль соблюдения сроков). В отчете должно быть зафиксировано все, что отняло более получаса времени.

ГВ>>А крышу не оторвёт?
X>Вам как отвечать, абстрактно, в вашем же тоне, или конкретно ?
Да будет этот выбор только Вашим.

X>Конкретно: конторе 6 лет, текучка очень маленькая.

Ага, уже выбрали, значит... Только мимо. Каким образом это связано с моим комментарием?

Поясню, что я имел ввиду под "крышу не оторвёт".

Получасовых дел при 9-10-часовом рабочем дне (чаще всего он именно такой) может быть около 20 (не ловите меня на арифметике). В том числе и "ходил, искал, не нашёл...", позвали, спросили, огадывали", так что, попытка написать "дневник" такого рода будет сопряжена с определёнными трудностями.

А именно.

При плотной загрузке разнородными делами (хаосе) для их перечисления потребуется минимум 40 минут. Кстати, n+1-м пунктом войдёт само составление отчёта (уж я бы вписал обязательно, и ещё вычел бы это время из общего рабочего). Кроме того, на самом деле, из таких отчётов потом очень трудно составить некую цельную картину процесса — все пишут разным языком и называют одни и те же вещи разными именами. Разумеется, лучше всего об этом будет знать тот, кто соответствующее поручение выдаёт. Так что, пусть он и пишет — кто и на какое время был загружен. Так что, следует признать критерий "всё что боле получаса" — неадекватным.

При небольшом же разнообразии нужно ориентироваться на те дела, котрые соответствуют поставленным задачам. Тогда справедливость предложенного критерия вызывает ещё большие сомнения — гораздо проще отмечаться в каком-нибудь Planner-е, или просто отмечать достигнутый прогресс.

То есть, при обоих случаях критерий "всё, что более получаса" — неадекватен. Ergo, вызывает сначала насмешку, потом раздражение, потом — депрессию ("Отрыв крыши").

Вопрос, который я люблю задавать любителям отчётности (простите за ёрничающий тон): как нужно отображать в отчёте процесс размышлений над некоторой задачей? А спонтанные микросовещания, которые могут длиться по полтора-два часа?
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[2]: Как отличить разгильдяя от... ?
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 21.11.04 18:02
Оценка: 1 (1)
Здравствуйте, LaptevVV, Вы писали:

C>>Здравствуйте!

C>>В конторе складывается такая ситуация.
C>>Составляется квартальный план, с учетом мнения разработчика.
C>>Т.е., по общему мнению руководителя и разработчика плотный, но выполнимый график.
LVV>Вот именно — по мнению!
Да, верно. Притом один обычно смущается, а другой этим пользуется.

LVV>Нет объективной оценки времени выполнения работы. По собственному опыту и руководителя и разработчика знаю, что программисты — оптимисты по натуре своей, поэтому подсознательно сроки ставят меньше. чем потребуется реально. Это связано еще и с тем, что человек как правило, не учитывает ни собственную накапливающуюся усталость, ни возможные недомогания, ни тем более форс — мажорные обстоятельства (дополнительную не предусмотренную работу, о которой вы написали).


Согласен. Могу добавить, что подобный сверхоптимизм связан с тем, что программист нередко предлагает интересный ему способ решения задачи. Но при этом, к сожалнию, боится, что руководство его заставит идти более короткой, но туповатой дорогой, если не будет удовлетворено сроками. Это его психологическая защита от возможного распада личности под влиянием требования творить глупости. Соответственно, он вынужденно идёт на подмену понятий, например, объявляет сроки готовности основных фич сроками общей готовности продукта и так далее. Другая причина подобных подмен — перманентный риск нарваться на обвинения в "разгильдяйстве". То есть, руководство само создаёт атмосферу напряжённости, а валит снова всё на программистов. Третья причина связана с контекстными факторами — прибежали, приволокли срочное задание, которое нужно сделать "вчера" и т.п. (здесь у нас, похоже, консенсус )

LVV>По многолетнему опыту могу сказаить: после всех договоренностей и согласий можно смело умножать сроки на 2 (а лучше — на Пи ) — тогда это будет похоже на реальный срок выполнения. И это при добросовестном отношении к работе.


Да, согласен. Хотя можно и попадать с высокой точностью. Для этого, прежде всего, нужно обеспечить стабильность и предсказуемость действий руководства.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re: Как отличить разгильдяя от... ?
От: Dimentiy Россия  
Дата: 21.11.04 22:28
Оценка: +1
Я так думаю.

1) Первичен всегда здравый смысл.
1.1) Все принимаемые организационные решения в идеале должны исходить из здравого смысла.

2) Когда люди уже не способны (по объективным/субъективным причинам) исходить из голого здравого смысла, начинается формализация.
[OFF: Отсюда кстати растёт т.н. "делегирование полномочий" — это совершенно верная попытка как можно дольше оставлять ситуацию на условно идеальном уровне "здравого смысла"]

3) Формализация может мешать или не мешать работе. Сделать так, чтобы формализация не мешала работе — задача менеджмента, включая и тимлида.

4) Если принятая формализация не помогает различить раздолбая от хорошего работника — она никакая. Виноваты те, кто ввёл такую систему.


Отсюда два варианта:
— Если текущая ситуация не очень парит, то и фиг с ней.
— Если текущая ситуация сильно мешает работать — надо отвечать себе сосем на другие вопросы(типа "to be or not to be") — и форум rsdn-а тут не помощник


Вот такие вот ночные размышления...

--
Диментий, "раздолбай" со стажем.
Re[3]: Как отличить разгильдяя от... ?
От: DemAS http://demas.me
Дата: 22.11.04 07:36
Оценка: 1 (1)
Здравствуйте, kochmin_alexandr, Вы писали:

_>Ежедневный отчет о проделанной работе. И желательно в письменном (электронном) виде. Пусть даже на это уйдет час времени.


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

Да, еще — один из моих учителей однажды сказал мне на подобный вопрос:

Если ты не можешь доверять своей команде — ты плохой руководитель.

... << RSDN@Home 1.1.4 beta 3 rev. 220>>
Re[2]: Как отличить разгильдяя от... ?
От: Dimonka Верблюд  
Дата: 22.11.04 09:58
Оценка:
Здравствуйте, xtile, Вы писали:

X>Каждую неделю минисовещание с тимлидом и pm. (обсуждаются задачи на неделю, прикидываются сроки на каждую. Если задача большая — разбивается на части, для выполнения которых нужно 1-2 дня).


У нас прoхoдят сoвeщания каждую нeдeлю всeм пoдoтдeлoм (у нас нe сoфт-oриeнтирoванная фирма) и oбсуждаются ВСE тeкущиe прoeкты (пoрядка 30-ти — 40-а). Начальник пoдoтдeла пoлучаeт инфoрмацию o тoм, какиe прoeкты нe укладываются в срoки или у кogo нeт рабoты. Пишeтся прoтoкoл измeнeния прoeктoв за нeдeлю.

X>Ежедневно — отчеты о проделанной работе (контроль соблюдения сроков). В отчете должно быть зафиксировано все, что отняло более получаса времени.


Практичeски тoжe самoe, тoлькo у нас всё этo oрганизoванo как oтдeльная систeма а-ля "Timesheets". Eсть списoк прoeктoв (кoтoрый автoматичeски закрeпляeтся за рабoтникoм), eсть дни мeсяца и надo прoстo в кoнцe дня затрачeныe часы раскидать пo таскам прoeктoв. На этoй oснoвe фoрмируются различныe oтчёты o затрачeнoм врeмeни/финансах итд.
Впoлнe удoбнo и нe трeбуeт мнoгo врeмeни.
Re: Как отличить разгильдяя от... ?
От: AndreyFedotov Россия  
Дата: 22.11.04 13:07
Оценка: 17 (2) +3
Здравствуйте, Constructor, Вы писали:

C>Здравствуйте!

C>В конторе складывается такая ситуация.
C>Составляется квартальный план, с учетом мнения разработчика. Т.е., по общему мнению руководителя и разработчика плотный, но выполнимый график.
Если вы будете составлять план на пятилетку, то его вообще никто кроме редких бездельников, которые изначально утроили сроки выполянть не будет.
И не означает ли "выполнимый" в данном случае — "можно успеть, если поднапрячься и не отвлекться ни на что другое"? Если да — а судя по письму в целом это так, то чего же вы хотите? Намечаете план на длительный срок — изначально закладывая в условия его выполнения мину в виде очень жёсткого условия, которое почти наверняка окажется нарушенным, не даёте запас на ошибки и потом удивляетесь — почему ничего не вышло?

C>Далее, по прошествии некоторого времени, руководитель выдает разработчику дополнительное срочное, жизненно важное задание. Обычно не надолго, на 2-3 недели. За квартал так может быть 1-2 раза. Такие задания обычно не вносятся в план.

C>По прошествии квартала разработчик отчитывается за свой первоначальный план, а дополнительные задания упускаются из рассмотрения. Чаще всего, естественно, разработчик свой план выполнить неуспевает.
Ну так сами себе злобные бакланы! То есть из 14 недель в квартал человек 4-6 недель т.е. 30-45% времени человек занимается "срочными заданиями" — которые вообще не учитываются в плане — и как следует из письма вообще нигде не учитываются, а потом с него требуют план в полном объёме? Что бы понять что вы делаете — поездите на работу с месяц из соседненго города за 200-300 км от Вашего. Получите весьма наглядное представление о требованиях, которые предявляете к другим...
Кстати учтите — что после занятия 2, а тем более 3 недели "каким-нибудь срочным заданием" человеку потребуется 3-5 дней, что бы полностью восстановить в голове тот уровень понимания и видения задач изначального плана, который у него был до прерывания. Это время следует прибавить ко времени задания, при оценки времени, которое будет затрачено на его исполнения — на этапах планирования и приёмки работ.
Если следовать ЛЮБОЙ методологии — то при внесении подобного "задания" — весть план должен пересматриваться и корректироваться. А после его завершения — должен пересматриваться и корректироваться ещё раз. Судя по всему — у Вас этого не делается, по причине лени и раздолбайства менеджеров, а так же по причине не желания менеджеров выслушивать от руководства ласковые слова по поводу изменения сроков — этим же руководством и заказанные. Гораздо проще сослаться на то, что "неизвестно кто у нас в конторе и чем занимается" и "разработчики разгильдяи"

C>Поднимается вопрос о том, что разработчик — разгильдяй.

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


C>Это с одной стороны. Я сам часто бываю таким разработчиком.


C>С другой стороны, было уже несколько раз, что я выступал в роли руководителя.

Похвально.

C>Я предлагал человеку сделать определенную работу. Вместе мы обсуждали объем и сроки. Вроде бы было полное согласие. И после этого план свой он не выполнял. Я вроде следил, чтобы никаких других работ у него не было.


- Вась, а Вась — скока тебе времени надо что бы этот XML файл прочитать?
— Ну дня 3-4
— Да ты что?! Лох что ли — тут же работы дня два от силы!
— М..мм..мм... Ну наверное да....
— Вот! Это уже лучше! Что там у нас следующее?


C>Складывается такая ситуация: практически не отслеживается, кто, когда и чем занимался. Точно могу сказать, что разные люди у нас выполняют совершенно разный объем работ. Разные люди разное время проводят в инете. Разные люди проявляют разный интерес к освоению новых технологий и разную степень стремления к повышению своей квалификации.

Это факт. С которым приходится иметь дело как с рассветом и закатом.

C>Всх ровнять под одну гребенку нехорошо... Хотелось бы научиться ненавязчиво контролировать, кто чем занимается, кто сталкивается с какими трудностями. Научиться достоверно определять: если человек не справился с работой, то это из-за 1) разгильдяейства или 2) его еще слабой подготовки или 3) недооценки сложности задачи.

C>Причем чтобы свои оценки можно было четко обосновать. И руководителю, и подчиненному.
"Контролировать" это всего лишь средство. А какова цель?

C>Вот такая у вот проблема... Поделитесь опытом, пожалуйста!
Re[2]: Как отличить разгильдяя от... ?
От: Gaperton http://gaperton.livejournal.com
Дата: 22.11.04 16:52
Оценка: 19 (3)
Здравствуйте, LaptevVV, Вы писали:

LVV>По многолетнему опыту могу сказаить: после всех договоренностей и согласий можно смело умножать сроки на 2 (а лучше — на Пи ) — тогда это будет похоже на реальный срок выполнения. И это при добросовестном отношении к работе.


"На пи". Для того, чтобы проверить реалистичность плана, достаточно делать прогноз не только времени, но и объема (в любой метрике. Строки кода — адекватная и одна из самых стабильных метрик, как показывает практика, что-бы там про них не говорили). И держать "продуктивность" труда в коридоре 80-160 строк кода без комментариев день (а лучше взять средние значения продуктивности с завершенных проектов — это совсем не сложно). И все.

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

А поправочные коэффициенты, если уж человек у человека есть постоянная тенденция к недооценке/переоценке (что элементарно определется по истории закрытых задач), берутся из исторических данных.

И все, совсем не надо быть семи пядей во лбу. Это азы проектного менеджмента, а не ноу-хау Gaperton-а. И изложены в любой толковой книге по вопросу.
Re[3]: Как отличить разгильдяя от... ?
От: LaptevVV Россия  
Дата: 22.11.04 17:06
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, LaptevVV, Вы писали:


LVV>>По многолетнему опыту могу сказаить: после всех договоренностей и согласий можно смело умножать сроки на 2 (а лучше — на Пи ) — тогда это будет похоже на реальный срок выполнения. И это при добросовестном отношении к работе.


G>"На пи". Для того, чтобы проверить реалистичность плана, достаточно делать прогноз не только времени, но и объема (в любой метрике. Строки кода — адекватная и одна из самых стабильных метрик, как показывает практика, что-бы там про них не говорили). И держать "продуктивность" труда в коридоре 80-160 строк кода без комментариев день (а лучше взять средние значения продуктивности с завершенных проектов — это совсем не сложно). И все.


G>Еще лучше вместо чесания репы при составлении прогноза применять хотя-бы элементарный PERT Estimation, который доступен каждому человеку без какого-либо специального образования в силу своей простоты, и позволяет количественно учесть в плане риски. И тогда на продолжительных проектах все будет иметь реальные шансы сойтись день в день (при большом количестве задач погрешность планирования, при отсутствии выраженной тенденции к переоценке/недооценке, как ни странно, уменьшается).


G>А поправочные коэффициенты, если уж человек у человека есть постоянная тенденция к недооценке/переоценке (что элементарно определется по истории закрытых задач), берутся из исторических данных.


G>И все, совсем не надо быть семи пядей во лбу. Это азы проектного менеджмента, а не ноу-хау Gaperton-а. И изложены в любой толковой книге по вопросу.

Кактта рахмат за разъяснения. Не знал, что у нас так все классно! — давно не являюсь руководителем разработок...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[3]: Как отличить разгильдяя от... ?
От: Spidola Россия http://www.usametrics.ru
Дата: 22.11.04 17:13
Оценка: 10 (1)
Здравствуйте, Gaperton, Вы писали:

G>И все, совсем не надо быть семи пядей во лбу. Это азы проектного менеджмента, а не ноу-хау Gaperton-а. И изложены в любой толковой книге по вопросу.


Всё указанное работает в идеальном контексте. Под идеальным контекстом понимаю наличие идеального ТЗ. Если же работа с нечётким ТЗ (а бывают и нечёткие Requirements), то расчёт строк кода никак не поможет. К сожалению, слишком часто приходится работать с такими нечёткими исходными требованиями. И в данном случае, возвращаясь к теме вопроса, отличить разгильдяя от нормального исполнительного специалиста по такому критерию, как "выполнение плана" невозможно, поскольку сам план грешит.

Так что ИМХО отличить разгильдяя можно только по косвенным признакам...

И ещё... Есть разница между разгильдяем и некачественным специалистом. Оба, в общем, не самый удачный вариант, но второй всё же лучше. Объясню. Некачественный программист постепенно растёт и, при достаточно стабильном использовании в проекте определённых технологий такой программист постепенно растёт (меньше копается в документации, быстрее работает засчёт наработок и т.п.), выходя на свою предельную мощность. Разгильдяй же постоянно показывает низкий результат, обосновывая это различными проблемами, а то и просто никак не объясняя. Так же сроки некачественного программиста всё же поддаются прогнозированию. С разгильдяем же можно всевозможных сюрпризов ожидать.
... << RSDN@Home 1.1.4 @@subversion >>
Re[4]: Как отличить разгильдяя от... ?
От: Gaperton http://gaperton.livejournal.com
Дата: 22.11.04 19:37
Оценка: 1 (1) +2
Здравствуйте, Spidola, Вы писали:

S>Здравствуйте, Gaperton, Вы писали:


G>>И все, совсем не надо быть семи пядей во лбу. Это азы проектного менеджмента, а не ноу-хау Gaperton-а. И изложены в любой толковой книге по вопросу.


S>Всё указанное работает в идеальном контексте. Под идеальным контекстом понимаю наличие идеального ТЗ.

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

S>Если же работа с нечётким ТЗ (а бывают и нечёткие Requirements), то расчёт строк кода никак не поможет. К сожалению, слишком часто приходится работать с такими нечёткими исходными требованиями. И в данном случае, возвращаясь к теме вопроса, отличить разгильдяя от нормального исполнительного специалиста по такому критерию, как "выполнение плана" невозможно, поскольку сам план грешит.

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

В любом деле нужны профессионалы. Руководить командой разработчиков (а не "управлять ресурсами" в Microsoft Project) — это специальная работа, и ее тоже нужно учится делать, чтобы делать ее хорошо. Хотите в этом убедится? Попробуйте пройти PM тест на brainbench. В первый год, когда он появился, его по их статистике провалило 98% людей, попытавшихся его пройти. Сравните со статистикой по С++.

S>Так что ИМХО отличить разгильдяя можно только по косвенным признакам...

Желание "отличить разгильдяя" — симптом, о чем здесь уже писали, и я полностью с этим согласен.
Re[5]: Как отличить разгильдяя от... ?
От: Dimonka Верблюд  
Дата: 23.11.04 08:36
Оценка: 5 (1)
Здравствуйте, Gaperton, Вы писали:

G>Нечеткие? Так уточняйте их (или организуйте этот процесс), это ваша работа. Если вы проработав по первоначальному плану 10%-20% времени не в состоянии сделать реалистичный план, это признак отсутствия управления рисками (а в вашем случае — еще и управления требованиями). Решение — (угадайте что?) — снятие руководителя проекта с должности по несоответствию, и назначение компетентного менеджера, который не будет обосновывать свои провалы нечеткими требованиями, или чем-то еще.


У нас частo пoлучаeтся, чтo заказчик сам нe сoвсeм увeрeн в тoм, чтo хoчeт. Сoздаёт брeйн-стoрминг сoвeщания с участиeм экспeртoв ужe в прoцeссe разрабoтки. Чтoбы на oснoвe прoтoтипoв ужe рeшать куда двигаться дальшe. Плюс кo всeму из-за спeцифичнoсти разрабoтки мнoгиe вeщи прoвeряются при участии юристoв. Так чтo каким кoмпeтeнтным бы нe был мeнeджeр, зараниe никакoгo чёткoгo ТЗ и быть у нас oбычнo нe мoжeт.

Кoнeчнo, oплата прoeкта нe фиксирoванным бюджeтoм, а пo врeмeни разрабoтки мoжeт стимулирoвать разгильдяйствo прoграммистoв. Нo на тo и eсть ПМ-ы, кoтoрыe рабoтают как с клиeнтами, так и с прoграммистами
Re[6]: Как отличить разгильдяя от... ?
От: Gaperton http://gaperton.livejournal.com
Дата: 23.11.04 10:54
Оценка: +2
Здравствуйте, Dimonka, Вы писали:

D>Здравствуйте, Gaperton, Вы писали:


G>>Нечеткие? Так уточняйте их (или организуйте этот процесс), это ваша работа. Если вы проработав по первоначальному плану 10%-20% времени не в состоянии сделать реалистичный план, это признак отсутствия управления рисками (а в вашем случае — еще и управления требованиями). Решение — (угадайте что?) — снятие руководителя проекта с должности по несоответствию, и назначение компетентного менеджера, который не будет обосновывать свои провалы нечеткими требованиями, или чем-то еще.


D>У нас частo пoлучаeтся, чтo заказчик сам нe сoвсeм увeрeн в тoм, чтo хoчeт. Сoздаёт брeйн-стoрминг сoвeщания с участиeм экспeртoв ужe в прoцeссe разрабoтки. Чтoбы на oснoвe прoтoтипoв ужe рeшать куда двигаться дальшe. Плюс кo всeму из-за спeцифичнoсти разрабoтки мнoгиe вeщи прoвeряются при участии юристoв. Так чтo каким кoмпeтeнтным бы нe был мeнeджeр, зараниe никакoгo чёткoгo ТЗ и быть у нас oбычнo нe мoжeт.


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

Если заказчик проявляет самостоятельную активность (думает, брейнстормит и обсуждает) и меняет постановку по ходу — ничего страшного. В таких условиях разумно применять XP, IBM Rad Cycle, или что-то подобное. Двигаетесь вперед через серию прототипов, каждый из которых делается, допустим, с интервалом в неделю, и обсуждается с заказчиком. Конечный срок не лимитируется, деньги берутся за время работы — хозяин барин.

D>Кoнeчнo, oплата прoeкта нe фиксирoванным бюджeтoм, а пo врeмeни разрабoтки мoжeт стимулирoвать разгильдяйствo прoграммистoв. Нo на тo и eсть ПМ-ы, кoтoрыe рабoтают как с клиeнтами, так и с прoграммистами

Проверь их продуктивность (строки кода/время), и вопиющее "разгильдяйство" сразу вылезет наружу. Всякое конечно бывает, но в массе своей программисты хорошо мотивированны (если им не портить удовольствие от работы и адекватно платить) и любят свою работу, что подверждается статистикой De Marco/Lister ("Peopleware"). Так что вопрос "разгильдяйства" программистов — совсем не тот вопрос, который должен обсуждаться в контексте проектного менеджмента. Это, еще раз, симптом, позволяющий отличить "разгильдяя" менеджера. Удобно, кстати
Re[4]: Как отличить разгильдяя от... ?
От: kirban Россия  
Дата: 23.11.04 11:24
Оценка:
Здравствуйте, SergeySPb, Вы писали:

SSP>Всегда хотел узнать: почему руководство предпочитает задания раздавать в устной форме,

SSP>а отчёты получать в письменной.

Может писать не умеют ?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Re[5]: Как отличить разгильдяя от... ?
От: Spidola Россия http://www.usametrics.ru
Дата: 23.11.04 15:37
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, Spidola, Вы писали:


S>>Здравствуйте, Gaperton, Вы писали:


G>>>И все, совсем не надо быть семи пядей во лбу. Это азы проектного менеджмента, а не ноу-хау Gaperton-а. И изложены в любой толковой книге по вопросу.


S>>Всё указанное работает в идеальном контексте. Под идеальным контекстом понимаю наличие идеального ТЗ.

G>Можно, конечно, считать свои условия работы уникальными. А если так не считать, и уметь перечисленное применять — то вся уникальность волшебным образом куда-то уйдет.

Уникальные условия — это как раз "идеальные". Реальные обычно отличаются. Где сильнее, где слабее...

S>>Если же работа с нечётким ТЗ (а бывают и нечёткие Requirements), то расчёт строк кода никак не поможет. К сожалению, слишком часто приходится работать с такими нечёткими исходными требованиями. И в данном случае, возвращаясь к теме вопроса, отличить разгильдяя от нормального исполнительного специалиста по такому критерию, как "выполнение плана" невозможно, поскольку сам план грешит.

G>Нечеткие? Так уточняйте их (или организуйте этот процесс), это ваша работа. Если вы проработав по первоначальному плану 10%-20% времени не в состоянии сделать реалистичный план, это признак отсутствия управления рисками (а в вашем случае — еще и управления требованиями). Решение — (угадайте что?) — снятие руководителя проекта с должности по несоответствию, и назначение компетентного менеджера, который не будет обосновывать свои провалы нечеткими требованиями, или чем-то еще.

G>В любом деле нужны профессионалы. Руководить командой разработчиков (а не "управлять ресурсами" в Microsoft Project) — это специальная работа, и ее тоже нужно учится делать, чтобы делать ее хорошо. Хотите в этом убедится? Попробуйте пройти PM тест на brainbench. В первый год, когда он появился, его по их статистике провалило 98% людей, попытавшихся его пройти. Сравните со статистикой по С++.


Всё это громкие слова, не более (особенно начало второго абзаца) . Про уточнение требований — это понятно. Как это соотносится с количеством строк кода — непонятно. Тем более непонятно, как вы будете "отличать разгильдяя" среди проектировщиков и других ролей, которые кода-то не пишут? По количеству строк обычного написанного ими текста в документе?
Ладно, согласен, передёргиваю слегка... Разговор шёл про разработчиков... С разработчиками самые богатые будут те, кто на Ассемблере пишут — у них строк больше

А если не глумиться, то количеством строк кода можно оценивать только те задачи, на которые заведомо известен объём необходимого кода. Т.е. те задачи, которые имеют типовые решения. Другими словами, данную технологию оценки можно применять в тех случаях, где она применима. А где неприменима, там бесполезно и даже вредно.

По поводу "управления ресурсами в Project" — здесь желательно отделить мух от котлет. Project даёт весьма неплохое визуальное представление проекта (редко видел, чтобы кто-то использовал прожект для моделирования проекта, например). Управление ресурсами в scope MS Project не попадает, поскольку учёта материальных ресурсов там нет. Кстати, вот вам выдержка из рекламного буклета:

"Project 2003 предлагает разнообразные эффективные способы работы над календарным планом проекта."

Вот для этого он и нужен, чобственно.

По поводу Брэйнбенча — терпеть не могу этот сервер. Мало того, что половина тестов там исскусственные, так и сертификаты их ничего не говорят о человеке... Ну и что вам даст тест на PM??? Узнаете, что нужно риски просчитывать? Это каждому мало мальски сообразительному человеку понятно... Вопрос как их считать. А ещё точнее, знать, как их в Москве считать, как в Казани, а как в Германии... Об этом в книжках тоже написано?
... << RSDN@Home 1.1.4 @@subversion >>
Re[4]: Как отличить разгильдяя от... ?
От: 0rc Украина  
Дата: 23.11.04 17:59
Оценка: +1
Здравствуйте, SergeySPb, Вы писали:

SSP>Всегда хотел узнать: почему руководство предпочитает задания раздавать в устной форме,

SSP>а отчёты получать в письменной.

Тому есть ряд причин:
1) Не может сформулировать свои мысли.
2) Жопу (Простите за франц.) прикрывает — ибо корпоративное письмо при обвинении вдруг может снять само обвинение.
3) Боиться менеджеров старшего звена. Не путать со вторым пунктом. Ибо, этот пункт касаеться ситуации когда данный менеджер боиться продвинуть инициативу по улучшению общения между подчиненными, которая обычно приходит от подчененных.
4) Свои собственные ошибки. Например, — "Болезнь? Какая болезнь? Мы это не предусматривали!" Дальше все в устной форме...
... << RSDN@Home 1.1.4 beta 3 rev. 205>>
Re[6]: Как отличить разгильдяя от... ?
От: Gaperton http://gaperton.livejournal.com
Дата: 23.11.04 18:43
Оценка: 15 (1)
Здравствуйте, Spidola, Вы писали:

S>Уникальные условия — это как раз "идеальные". Реальные обычно отличаются. Где сильнее, где слабее...

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

G>>В любом деле нужны профессионалы. Руководить командой разработчиков (а не "управлять ресурсами" в Microsoft Project) — это специальная работа, и ее тоже нужно учится делать, чтобы делать ее хорошо. Хотите в этом убедится? Попробуйте пройти PM тест на brainbench. В первый год, когда он появился, его по их статистике провалило 98% людей, попытавшихся его пройти. Сравните со статистикой по С++.


S>Ладно, согласен, передёргиваю слегка... Разговор шёл про разработчиков... С разработчиками самые богатые будут те, кто на Ассемблере пишут — у них строк больше

Да не слегка. Кстати, сразу видно, что вы не считаете строки кода. Сколько именно строк кода конкретный программист колбасит в день — совершенно пофигу, лишь бы сильно не выбивалось за коридор средних (в обе стороны), это говорит о проблемах. Кстати, продуктивность в строках не так сильно зависит от языка. Речь идет о строках отлаженного кода без комментариев.

S>А если не глумиться, то количеством строк кода можно оценивать только те задачи, на которые заведомо известен объём необходимого кода. Т.е. те задачи, которые имеют типовые решения. Другими словами, данную технологию оценки можно применять в тех случаях, где она применима. А где неприменима, там бесполезно и даже вредно.

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

Так что именно эта метрика применялась, применяется и будет применяться в будущем в софтверном ptoject management как основная. Если же вы не в состоянии сделать прогноз объема, это значит что весь ваш план взят с потолка. Как следствие, вы автоматически проиграете любой тендер министерства обороны США, да и вообще не сможете написать толковый SDP (что это такое, да? RTFM), т. е. проиграете практически любой серьезный тендер. А будете им объяснять, что де "она здесь не применима", вас 1) поднимут на смех 2) скажут досвиданья.

S>

S>"Project 2003 предлагает разнообразные эффективные способы работы над календарным планом проекта."

S>Вот для этого он и нужен, чобственно.
Использовать его для составления календарного плана для разработки софта — самоубийство для проекта. А если не пользоваться его генератором schedule, то он вообще нафиг не нужен. Нельзя позволять машине раскидывать задачи на разработчиков, если вы, конечно, хоть как-то озабочены управлением рисками. Почему? Программисты не взаимозаменяемы, учитывать их индивидуальность необходимо для успеха проекта. В этом ключ к успешной командной работе.

S>По поводу Брэйнбенча — терпеть не могу этот сервер. Мало того, что половина тестов там исскусственные, так и сертификаты их ничего не говорят о человеке...

А я вам не тыкаю своими сертефикатами, у меня их нет. Эти тесты позволяют довольно надежно и объективно отсеять людей, ну совсем нихрена не разбирающихся в вопросе.

S> Ну и что вам даст тест на PM??? Узнаете, что нужно риски просчитывать?

По моему я ясно выразился — по их статистике в PM не разбирается 98% людей, на это претендующих. Что имхо весьма правдоподобно. Причем им часто даже чтение литературы не помогает. Мне он в свое время (5 лет назад) дал понимание того, что я ничего не понимаю в PM. Что стимулировало меня к чтению факен мануалов. С тех пор его не проходил, как то уже и не надо стало .

S>Это каждому мало мальски сообразительному человеку понятно... Вопрос как их считать. А ещё точнее, знать, как их в Москве считать, как в Казани, а как в Германии... Об этом в книжках тоже написано?

Вопрос не в том, как их считать. Вопрос, как их корректно учесть при планировании времени задачи . А вот об этом в книжках написано. Впрочем, в военное время в какой-нибудь Казани может перестать работать не только проектный менеджмент, но и теория вероятностей, я уж не говорю о значении синуса. А у нас в Москве — все перечисленное работает без сбоев, риски исправно учитываются в планах, которые привычно выходят на deadline. В Германии я слыхал тоже. Чего и вам желаю.
Re: Как отличить разгильдяя от... ?
От: Бусел Беларусь  
Дата: 24.11.04 01:33
Оценка: 5 (1) +2
Здравствуйте, Constructor, Вы писали:

C>Всх ровнять под одну гребенку нехорошо... Хотелось бы научиться ненавязчиво контролировать, кто чем занимается, кто сталкивается с какими трудностями. Научиться достоверно определять: если человек не справился с работой, то это из-за 1) разгильдяейства или 2) его еще слабой подготовки или 3) недооценки сложности задачи.

C>Причем чтобы свои оценки можно было четко обосновать. И руководителю, и подчиненному.

У всех программеров есть плюсы и минусы.
Зачем тебе определять степень разгильдяйства каждого из них?
Что за мания гнобить программеров?
Тебе же нужно, чтобы проект был сделан этими разгильдяями в срок.

Из любого разгильдяя можно сделать работягу в поте лица, если:
1. Дать ему четкий объем работ и сроки (ТЗ + Планирование).
2. Дать ему почувствовать, что его контролируют (Ежедневная отчетность, именно ежедневная).
Над какими работами из плана работал, сколько часов в день, каков результат (кратенько).
Занимает это не более 15 мин/день, вырабатывает чувство самоконтроля и ответственности.
3. Собрания по мере надобности и раз в неделю по пятницам (постыдить шалопаев и похвалить).

Труднее именно предоставить в нормальном виде объем работ!!!
Если ты знаешь что именно нужно делать, то у тебя нет проблем.
ИМХО, вся проблема в проектировании системы и формировании конкретных заданий.
Сроки срываются из-за того, что проектировщик что-то там не учел.
Решается путем поэтапной сдачи проекта и накидывания времени прозапас на каждый этап.

Дополнительную работу, данную в устной форме, следует оформить в письменной и занести в план.
Жестко ставить вопрос перед уже твоим начальством по поводу возможных срывов сроков и на сколько.
Пусть знаю, что они виноваты!!!

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

И бревно, бревно должен нести ты тоже, чтобы был пример.
Вспомни Вождя!
Re[7]: Как отличить разгильдяя от... ?
От: Spidola Россия http://www.usametrics.ru
Дата: 24.11.04 23:26
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, Spidola, Вы писали:


S>>Уникальные условия — это как раз "идеальные". Реальные обычно отличаются. Где сильнее, где слабее...

G>Мы так работаем последние четыре года. И никаких проблем с идеальными условиями не испытываем. Это все отмазки.

Без комментариев. Не знаком с вашей компанией...

G>>>В любом деле нужны профессионалы. Руководить командой разработчиков (а не "управлять ресурсами" в Microsoft Project) — это специальная работа, и ее тоже нужно учится делать, чтобы делать ее хорошо. Хотите в этом убедится? Попробуйте пройти PM тест на brainbench. В первый год, когда он появился, его по их статистике провалило 98% людей, попытавшихся его пройти. Сравните со статистикой по С++.


S>>Ладно, согласен, передёргиваю слегка... Разговор шёл про разработчиков... С разработчиками самые богатые будут те, кто на Ассемблере пишут — у них строк больше

G>Да не слегка. Кстати, сразу видно, что вы не считаете строки кода. Сколько именно строк кода конкретный программист колбасит в день — совершенно пофигу, лишь бы сильно не выбивалось за коридор средних (в обе стороны), это говорит о проблемах. Кстати, продуктивность в строках не так сильно зависит от языка. Речь идет о строках отлаженного кода без комментариев.

Не сильно я, конечно, разбираюсь в проджект менеджменте, однако, не помню, чтобы где-нибудь в COCOMO II или FPA учитывались строки кода без учёта языка, а точнее средств разработки. Не дадите ссылку?

S>>А если не глумиться, то количеством строк кода можно оценивать только те задачи, на которые заведомо известен объём необходимого кода. Т.е. те задачи, которые имеют типовые решения. Другими словами, данную технологию оценки можно применять в тех случаях, где она применима. А где неприменима, там бесполезно и даже вредно.

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

G>Так что именно эта метрика применялась, применяется и будет применяться в будущем в софтверном ptoject management как основная. Если же вы не в состоянии сделать прогноз объема, это значит что весь ваш план взят с потолка. Как следствие, вы автоматически проиграете любой тендер министерства обороны США, да и вообще не сможете написать толковый SDP (что это такое, да? RTFM), т. е. проиграете практически любой серьезный тендер. А будете им объяснять, что де "она здесь не применима", вас 1) поднимут на смех 2) скажут досвиданья.


По существу: когда вы говорите про "прогноз объёма" в строках кода — вы говорите серьёзно? И про то, что без этого прогноза ни один серьёзный заказчик не будет разговаривать и тем более тендер заключать?

И вы действительно считаете указанную вами метрику "основной"?

Надеюсь про тендеры — это шутка?.. Про минобороны США не знаю — не участвовал в тендерах. Американцы — они вообще народ интересный... Про минобороны наше (да и про наши центральные органы власти) — уж поверьте — там никого не интересует "объём кода" при анализе тендерных предложений.

S>>

S>>"Project 2003 предлагает разнообразные эффективные способы работы над календарным планом проекта."

S>>Вот для этого он и нужен, чобственно.
G>Использовать его для составления календарного плана для разработки софта — самоубийство для проекта. А если не пользоваться его генератором schedule, то он вообще нафиг не нужен. Нельзя позволять машине раскидывать задачи на разработчиков, если вы, конечно, хоть как-то озабочены управлением рисками. Почему? Программисты не взаимозаменяемы, учитывать их индивидуальность необходимо для успеха проекта. В этом ключ к успешной командной работе.

Не вижу, честно говоря, "самоубийства". "Раскидывать задачи" в Project Central действительно не удобно, также как неудобно осуществлять там трекинг задач. Думаю, что существуют более удобные и интегрирующиеся в среды разработки инструменты, применяемые в конкретных командах. Что касается использования Project для расписывания общего календарного плана — пока проблем не видно.

S>>По поводу Брэйнбенча — терпеть не могу этот сервер. Мало того, что половина тестов там исскусственные, так и сертификаты их ничего не говорят о человеке...

G>А я вам не тыкаю своими сертефикатами, у меня их нет. Эти тесты позволяют довольно надежно и объективно отсеять людей, ну совсем нихрена не разбирающихся в вопросе.

Не согласен. Можно заодно отсеить и часть людей, которые вам очень могут пригодиться. Тесты брэйна довольно синтетические, на мой взгляд, и только формально проверяют вас на знание вопросов, также формально изложенных в теории. В конкретных практических вопросах часть элементов теории может не применяться и знание этих элементов может не требоваться. Тем более на большинство вопросов брэйнбенча можно ответить, прочитав одну две книги. А вы сами утверждали выше, что прочитывание книг не даёт уверенности в знании вопроса. У самого была несколько лет назад мысль по поводу использования брэйна при приёме на работу новых сотрудников. Эта модель была опробована и быстро отброшена, как бесполезная и даже вредная.

S>> Ну и что вам даст тест на PM??? Узнаете, что нужно риски просчитывать?

G>По моему я ясно выразился — по их статистике в PM не разбирается 98% людей, на это претендующих. Что имхо весьма правдоподобно. Причем им часто даже чтение литературы не помогает. Мне он в свое время (5 лет назад) дал понимание того, что я ничего не понимаю в PM. Что стимулировало меня к чтению факен мануалов. С тех пор его не проходил, как то уже и не надо стало .

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

S>>Это каждому мало мальски сообразительному человеку понятно... Вопрос как их считать. А ещё точнее, знать, как их в Москве считать, как в Казани, а как в Германии... Об этом в книжках тоже написано?

G> Вопрос не в том, как их считать. Вопрос, как их корректно учесть при планировании времени задачи . А вот об этом в книжках написано.

Не понял. Как их можно учитывать не считая??? В процентах? Т.е. время на набор 20 программистов в Москве и в Усть-Урюпинске одинаково? И не зависит от среды разработки и платформы?

G>Впрочем, в военное время в какой-нибудь Казани может перестать работать не только проектный менеджмент, но и теория вероятностей, я уж не говорю о значении синуса. А у нас в Москве — все перечисленное работает без сбоев, риски исправно учитываются в планах, которые привычно выходят на deadline. В Германии я слыхал тоже. Чего и вам желаю.


Мои вам поздравления. Вы, видимо, достигли нирваны. Далеко не каждый может этим похвастаться (и я в том числе, к сожалению).
... << RSDN@Home 1.1.4 @@subversion >> Home
Re[3]: Как отличить разгильдяя от... ?
От: Spidola Россия http://www.usametrics.ru
Дата: 24.11.04 23:34
Оценка: :))) :))
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>

ГВ>По моему скромному опыту больше всего неприятностей вызывает честный и исполнительный трудяга. Почему так получается, не знаю. Но подозреваю, что здесь задействован принцип "несдвигания сроков во что бы то ни стало". Во всяком случае, от тех, кто строг и исполнителен в административном смысле проблемы в архитектуре или кривой API получить удавалось чаще, чем от лентяев, к которым как ни зайдёшь, так они либо в инете сидят, либо музыку слушают, либо ещё чем-то занимаются.

Это вы путаете разгильдяев и раздолбаев. Разгильдяи — это такие мужики, которые всё что надо пытаются делать, но в какой-то момент тупят или ленятся и ничего хорошего в результате не получается. А раздолбаи — это такие талантливые ребята, которые всякой, пардон, хернёй, занимаются, но дело знают.
... << RSDN@Home 1.1.4 @@subversion >> Home
Re[4]: Как отличить разгильдяя от... ?
От: minorlogic Украина  
Дата: 25.11.04 07:40
Оценка:
Здравствуйте, Spidola, Вы писали:


как отличить разгильдяя от раздолбая или расп.. дяя !
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[4]: Как отличить разгильдяя от... ?
От: kliff Россия http://www.esignal.ru
Дата: 25.11.04 08:27
Оценка: :)
Здравствуйте, Spidola, Вы писали:

S>Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>>

ГВ>>По моему скромному опыту больше всего неприятностей вызывает честный и исполнительный трудяга. Почему так получается, не знаю. Но подозреваю, что здесь задействован принцип "несдвигания сроков во что бы то ни стало". Во всяком случае, от тех, кто строг и исполнителен в административном смысле проблемы в архитектуре или кривой API получить удавалось чаще, чем от лентяев, к которым как ни зайдёшь, так они либо в инете сидят, либо музыку слушают, либо ещё чем-то занимаются.

S> Это вы путаете разгильдяев и раздолбаев. Разгильдяи — это такие мужики, которые всё что надо пытаются делать, но в какой-то момент тупят или ленятся и ничего хорошего в результате не получается. А раздолбаи — это такие талантливые ребята, которые всякой, пардон, хернёй, занимаются, но дело знают.


хм. а более подробной классификации нет? если можно огласите весь список )))
Re[8]: Как отличить разгильдяя от... ?
От: Gaperton http://gaperton.livejournal.com
Дата: 25.11.04 09:28
Оценка: 3 (1)
Здравствуйте, Spidola, Вы писали:

S>Не сильно я, конечно, разбираюсь в проджект менеджменте, однако, не помню, чтобы где-нибудь в COCOMO II или FPA учитывались строки кода без учёта языка, а точнее средств разработки. Не дадите ссылку?

Не дам . В СOCOMO II язык учитывается. Я кстати, не говорил, что от языка продуктивность не зависит. Я говорил, что она зависит не сильно. У программиста на ассемблере не будет на порядок выше продуктивность в строках отлаженного кода в час (генеренные строки и комментарии не считать). Хотите — проведите межязыковое сравнение по своей компании — это не сложно. Готов заключить пари, что средняя продуктивность программиста за год по вашей компании уложтся в коридор 20-60 строк строк в час независимо от языка. Мы сравнивали С++ и С#, В Ericsson сравнивали 5 непохожих друг на друга языков.

S>По существу: когда вы говорите про "прогноз объёма" в строках кода — вы говорите серьёзно? И про то, что без этого прогноза ни один серьёзный заказчик не будет разговаривать и тем более тендер заключать?

Да, я говорю серьезно. Почитайте Хамфри, автора модели CMM, он тоже говорит серьезно.

S>И вы действительно считаете указанную вами метрику "основной"?

Я дал повод в этом сомневаться? По-моему, я объяснил почему я считаю ее основной и в чем конкретно ее преимущества перед остальными метриками.

S>Надеюсь про тендеры — это шутка?.. Про минобороны США не знаю — не участвовал в тендерах. Американцы — они вообще народ интересный... Про минобороны наше (да и про наши центральные органы власти) — уж поверьте — там никого не интересует "объём кода" при анализе тендерных предложений.

Конечно. Там их интересует объем откатов. Как и в большинстве тендеров в России. Я надеюсь, вы привели этот пример в шутку?

S>Не согласен. Можно заодно отсеить и часть людей, которые вам очень могут пригодиться. Тесты брэйна довольно синтетические, на мой взгляд, и только формально проверяют вас на знание вопросов, также формально изложенных в теории. В конкретных практических вопросах часть элементов теории может не применяться и знание этих элементов может не требоваться. Тем более на большинство вопросов брэйнбенча можно ответить, прочитав одну две книги. А вы сами утверждали выше, что прочитывание книг не даёт уверенности в знании вопроса. У самого была несколько лет назад мысль по поводу использования брэйна при приёме на работу новых сотрудников. Эта модель была опробована и быстро отброшена, как бесполезная и даже вредная.


Тест брейна на PM (я говорю только о нем, и не хочу обсуждать brainbench) проверяет знакомство со специализированной литературой по PM и элементарное понимание базовый понятий PM. Менеджер, который не может его пройти — профнепригоден. Так же как и программист на С++, который ни разу за не читал книг по своей специальности.

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

Не понимаю, что вы хотите доказать.

S>Не понял. Как их можно учитывать не считая??? В процентах? Т.е. время на набор 20 программистов в Москве и в Усть-Урюпинске одинаково? И не зависит от среды разработки и платформы?

Вы вот тут COCOMO упоминали. Неужели вы не знаете две элементарных формулы PERT, и не понимаете, как именно он помогает количественно учесть риски?

G>>Впрочем, в военное время в какой-нибудь Казани может перестать работать не только проектный менеджмент, но и теория вероятностей, я уж не говорю о значении синуса. А у нас в Москве — все перечисленное работает без сбоев, риски исправно учитываются в планах, которые привычно выходят на deadline. В Германии я слыхал тоже. Чего и вам желаю.

S>Мои вам поздравления. Вы, видимо, достигли нирваны. Далеко не каждый может этим похвастаться (и я в том числе, к сожалению).
Нет, я применяю базовые вещи из project management. Согласен, далеко не кадждый может этим похвастаться.
Re[4]: Как отличить разгильдяя от... ?
От: g_i  
Дата: 25.11.04 19:38
Оценка: 1 (1) +1
Здравствуйте, SergeySPb, Вы писали:

SSP>Здравствуйте, kochmin_alexandr, Вы писали:


_>>Ежедневный отчет о проделанной работе. И желательно в письменном (электронном) виде.


SSP>Всегда хотел узнать: почему руководство предпочитает задания раздавать в устной форме,

SSP>а отчёты получать в письменной.
Это способ уйти от ответственности. Наряду с требованиями с разработчикам существуют требования к заказчику — четкие и однозначно трактуемые требования. Начальство, выступая в роли заказчика, этим заниматься не любит . Поэтому процесс разработки должен начанаться с анализа, выполняемого вовсе и не разработчиками, а системными и бизнес-аналитиками.
... << RSDN@Home 1.1.3 stable >>
Re: Как отличить разгильдяя от... ?
От: g_i  
Дата: 25.11.04 19:38
Оценка: 1 (1)
Здравствуйте, Constructor, Вы писали:

C>Здравствуйте!

C>В конторе складывается такая ситуация.
C>Составляется квартальный план, с учетом мнения разработчика. Т.е., по общему мнению руководителя и разработчика плотный, но выполнимый график.
C>Далее, по прошествии некоторого времени, руководитель выдает разработчику дополнительное срочное, жизненно важное задание. Обычно не надолго, на 2-3 недели. За квартал так может быть 1-2 раза. Такие задания обычно не вносятся в план.
C>По прошествии квартала разработчик отчитывается за свой первоначальный план, а дополнительные задания упускаются из рассмотрения. Чаще всего, естественно, разработчик свой план выполнить неуспевает.
C>Поднимается вопрос о том, что разработчик — разгильдяй.

Часто разработчик внутренне не готов признать необходимость пересмотреть сроки готовности — во многих организациях (особенно не софтверных) это не приветствуется, вследствие чего развивается синдром хронического срыва сроков (хвосты "наезжают" один на другой, задачи откладываются и все это тянется бесконечно). Мне кажется, в поставленном вопросе ключевой фрагмент — "Такие задания обычно не вносятся в план.". Не внося в план и не предостовляя текущей отчетности по продвижению текущей задачи человек часто сам себя загоняет в цейтнот — откладывая реализацию дополнительной задачи на потом и даже приступая к ней время от времени — и внезапно возвращаясь к основной работе. На таких неконтролируемых переходах теряется очень много времени.
... << RSDN@Home 1.1.3 stable >>
Re: Как отличить разгильдяя от... ?
От: mihhon  
Дата: 25.11.04 22:46
Оценка: 32 (4) +3
Тут кто-то упомянул о числе пи, вспомнилось
Один кадр на проекте писал процедуру инициализации базы в течение года (и сейчас продолжает). То ошибки, то клиент вспомнит какую-нибудь забытую деталь, то полбазы попросит переделать и всё такое, классика. Авангард в том, что на днях его процедура доросла до 314 скриптов . Адская неподъёмная смесь perl, shell, PL/SQL и Java. Единственная и любимая методология — copy-paste. Поэтому когда клиент просит добавить пробел в одно поле, это может потребовать пары дней

Вот это настоящий раздолба-разгильдяй. Причина всех остальных бедствий, описанных Constructor-ом — НУЛЁВЫЙ МЕНЕДЖМЕНТ. Да и авангардиста можно туда же. Не было вовремя подходящих ресурсов, поставили такого, вроде не дебютант. А потом шеф вовремя его не заменил.

Кто становится шефами проектов ? Вчерашние программисты с техническим образованием ? Зачатки менеджмента, преподаваемые в институте, благополучно забИвались. Бывшие студенты-управленцы без представления об ИТ ? Если им не дают нормальных ресурсов — заваленные проекты

Отдельная категория — ставшие умственными инвалидами-параноиками. Дебютанты, решившие, что они способны. И попросившие (или согласившиеся принять) ответственность. А по ним проехались катком их оппоненты-клиенты с 20..30 летним опытом. А собственное начальство сделало их козлами отпущения. Жалкое зрелище

Моё мнение, что человек без 4..6 лет опыта в ИТ, из них 2..3 шефом команды или проекта, мало чего стоит с т.з. менеджмента и не автономен. И неплохо в начале поучаствовать шефом команды в немаленьком проекте (человек 30..50) под управлением реального профессионала. Хороший размер проекта, на котором присутствуют очень много профилей: от дебютантов до профессионалов, от клёвых перцев до полных моральных уродов. И интересоваться не только RUP и CMM, а расширять кругозор психологией, управлением, политикой, ... иначе вас съедят

сколько написал
Re[9]: Как отличить разгильдяя от... ?
От: Spidola Россия http://www.usametrics.ru
Дата: 26.11.04 00:40
Оценка: 5 (1)
PreScriptum: всё нижесказанное исключительно для повышения интереса беседы и выяснения истин в части нашего их понимания.


Здравствуйте, Gaperton, Вы писали:

S>>Не сильно я, конечно, разбираюсь в проджект менеджменте, однако, не помню, чтобы где-нибудь в COCOMO II или FPA учитывались строки кода без учёта языка, а точнее средств разработки. Не дадите ссылку?

G>Не дам . В СOCOMO II язык учитывается. Я кстати, не говорил, что от языка продуктивность не зависит. Я говорил, что она зависит не сильно. У программиста на ассемблере не будет на порядок выше продуктивность в строках отлаженного кода в час (генеренные строки и комментарии не считать). Хотите — проведите межязыковое сравнение по своей компании — это не сложно. Готов заключить пари, что средняя продуктивность программиста за год по вашей компании уложтся в коридор 20-60 строк строк в час независимо от языка. Мы сравнивали С++ и С#, В Ericsson сравнивали 5 непохожих друг на друга языков.

Во-первых разброс продуктивности по вашему коридору как минимум в три раза, что нехило (как при таком разбросе планировать, не очень понятно). Во-вторых, сравниваемые вами языки достаточно близки (если бы вы сравнили хотя бы классический C++ и VB, у вас бы была разница где-то раза в 2. Не знаю, что там сравнивали в Ericsson, но я видел описанные в методиках conversion ratio для различных языков, предназначенные для анализа объёма кода, решающего одинаковые задачи, где даже C++ и Visual C++ отличаются в 1,5 раза.

S>>По существу: когда вы говорите про "прогноз объёма" в строках кода — вы говорите серьёзно? И про то, что без этого прогноза ни один серьёзный заказчик не будет разговаривать и тем более тендер заключать?

G>Да, я говорю серьезно. Почитайте Хамфри, автора модели CMM, он тоже говорит серьезно.

Вы имеете ввиду того Хамфри, который Уотс? К сожалению, пока не нашёл материалов с его авторством по поводу объёма в строках (может ссылочку какую подкините?), хотя человек, безусловно, незаурядный, хотя ИМХО слегка консервативный.

S>>И вы действительно считаете указанную вами метрику "основной"?

G>Я дал повод в этом сомневаться? По-моему, я объяснил почему я считаю ее основной и в чем конкретно ее преимущества перед остальными метриками.

В общем дали повод.

Объяснения по поводу простоты метрики не совсем меня убедили, а вот стабильность — это уже лучше. Когда посмотрю индустриальную статистику — может быть мнение опять таки изменится. Кстати, если уж зашла речь о данной статистике, то откуда вы её брали? Что-нибудь вроде документов Gartner Group или ещё где-то? Или основываетесь на EFP методе и подсчёте SLOC? Если последнее, то учёт SLOC требует глубокой проработки проекта на стадии проектирования, что не всегда возможно. Мне больше импонирует, например, оценка по метрикам, основанным на анализе компонентов и их применимости. Потому что такие оценки дают достаточное понимание общего объёма работы, а дальнейшие уточнения можно проводить в рамках итерационного процесса параллельно с изменением и коррекцией требований. Я уж не говорю о том, что SLOC даёт объективную оценку, а некоторые методы разработки (например XP) подразумевают исключительно субъективную оценку теми, кто, собственно и будет разрабатывать ту или иную часть системы.

Кстати, начинаю понимать, откуда растут примеры про минобороны США. Вы, наверное, имели ввиду заключение контрактов данного министерства на разработку ПО с компаниями, имеющими CMM не ниже третьего уровня...

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

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

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

Предполагаю, что если вы посмотрите, например, на компании, работающие на рынке недорогих систем и разовых заказов (коим по моему текущему убеждения является, к примеру, Rentacoder), то вряд ли вы найдёте там компании, использующие метрику "объём в строках кода". Поскольку там больше используется не расчёты SLOC, а расчёт возможности применения повторно используемого кода. Если есть люди с RAC — прошу подтвердить или опровергнуть моё предположение — было бы интересено узнать.

S>>Надеюсь про тендеры — это шутка?.. Про минобороны США не знаю — не участвовал в тендерах. Американцы — они вообще народ интересный... Про минобороны наше (да и про наши центральные органы власти) — уж поверьте — там никого не интересует "объём кода" при анализе тендерных предложений.

G>Конечно. Там их интересует объем откатов. Как и в большинстве тендеров в России. Я надеюсь, вы привели этот пример в шутку?

Нет, не в шутку. Объём откатов уже мало кого интересует, поскольку люди поумнели. Это лет 10 назат откаты решали всё... Сейчас уже людям нужен результат (что радует — за державу приятно). Скорее не откаты, а надёжность исполнителя (подтверждённая успешными проектами в конкретных бизнес-областях, а не по каким-нибудь CMM) + контакты исполнителя с представителями силовых структур (имеется ввиду их инженерная часть) и других аналогичных ведомств...

G>Тест брейна на PM (я говорю только о нем, и не хочу обсуждать brainbench) проверяет знакомство со специализированной литературой по PM и элементарное понимание базовый понятий PM. Менеджер, который не может его пройти — профнепригоден. Так же как и программист на С++, который ни разу за не читал книг по своей специальности.


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

S>>Не понял. Как их можно учитывать не считая??? В процентах? Т.е. время на набор 20 программистов в Москве и в Усть-Урюпинске одинаково? И не зависит от среды разработки и платформы?

G> Вы вот тут COCOMO упоминали. Неужели вы не знаете две элементарных формулы PERT, и не понимаете, как именно он помогает количественно учесть риски?

2 формулы PERT действительно не знаю... было бы интересно узнать, что вы имеете ввиду.
... << RSDN@Home 1.1.4 @@subversion >> Home
Re[5]: Как отличить разгильдяя от... ?
От: mihhon  
Дата: 26.11.04 00:56
Оценка: 5 (1)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Вопрос, который я люблю задавать любителям отчётности (простите за ёрничающий тон): как нужно отображать в отчёте процесс размышлений над некоторой задачей? А спонтанные микросовещания, которые могут длиться по полтора-два часа?


1. почитай вот эту статью
http://www.joelonsoftware.com/global/Russian/Articles/PainlessSoftwareSchedules.html
2. любая мало-мальски серьёзная система стоит денег. чтоб инвестор или клиент дал денег, ему нужен план: что, когда и сколько будет стоить. все серьёзные системы написаны по планам. отчётность служит для оценки и корректировки планов.

если хочешь, можешь "всё" умножить на 0,999. всегда бывают исключения
Re[7]: Как отличить разгильдяя от... ?
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.11.04 03:16
Оценка:
Здравствуйте, Gaperton, Вы писали:

S>>Ладно, согласен, передёргиваю слегка... Разговор шёл про разработчиков... С разработчиками самые богатые будут те, кто на Ассемблере пишут — у них строк больше

G>Да не слегка. Кстати, сразу видно, что вы не считаете строки кода. Сколько именно строк кода конкретный программист колбасит в день — совершенно пофигу, лишь бы сильно не выбивалось за коридор средних (в обе стороны), это говорит о проблемах. Кстати, продуктивность в строках не так сильно зависит от языка. Речь идет о строках отлаженного кода без комментариев.

Кстати, подтверждаю. Когда-то занимался анализом продуктивности по этой метрике. Действительно, всё так и есть. Во всяком случае, если речь идёт об одной и той же команде. Структурные метрики плавают в десятки раз (в особенности — Effort по Холстеду). Видимо, это как-то связано с манерой мышления и интуитивным выбором баланса между мышлением и воплощением.

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

Ну хоть кто-то думающий есть!
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[2]: Как отличить разгильдяя от... ?
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.11.04 03:16
Оценка: 1 (1)
Здравствуйте, Бусел,

В целом согласен. Понятно, что менеджеру нужно знать о происходящем в команде — кто над чем работает и т.п. Пусть даже это и каждодневная отчётность. Лишь бы только форма не начинала превалировать над содержанием.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[2]: Как отличить разгильдяя от... ?
От: g_i  
Дата: 26.11.04 06:42
Оценка:
Здравствуйте, Бусел, Вы писали:

[..]

Б>2. Дать ему почувствовать, что его контролируют (Ежедневная отчетность, именно ежедневная).

Б> Над какими работами из плана работал, сколько часов в день, каков результат (кратенько).
Б> Занимает это не более 15 мин/день, вырабатывает чувство самоконтроля и ответственности.
...
Вот все-таки если текущие работа достаточно объемные.. несовсем понятен смысл ежедневной отчетности. Ну занимаюсь я дизайном нового модуля. Или реализую сложный гуй. Что писать — задизайнил 2 класса? Добавил 2 вкладки с четырьмя сплиттерами и датагрид? :)) В таких случаях разработчик тупо поднимает процент готовности для текущей работы и все. Совершенно неинформативно и напряжно для разработчика. Мы давно перешли к понедельной отчетности и вполне довольны.
PS. Возможно для больших команд ежедневная отчетность и необходима, не знаю.
Re[10]: Как отличить разгильдяя от... ?
От: AndreyFedotov Россия  
Дата: 26.11.04 08:09
Оценка: +1
Вот об этом и речь. Тут поминаются методы — которые применяются методы, используемые компаниями где сотрудников более 1000 (или нескольких сотен), причём для проектов стоимостями в сотни мегабаксов — причём над постановкой и контролем за выполнением процессов там работают целые команды.
В такой орде сотрудников индивидуальные особенности разработчиков частенько просто не заметны на общем уровне. И там легко вести расчёты на основе статистики...
А потом местные мудрецы с умным видом советуют применять те же методы в командах из 3-10 человек, да ещё над проектами, где заказчик с трудом готов оплачивать зарплату девелоперам... Сама мысль о дополнительных тратах приведёт заказчика в ярость — ему не нужен "процесс" — ему нужен результат. И если вы попросите денег на процесс — он уйдёт в другую фирму. И это реальность с которой приходится считаться...
Re[11]: Как отличить разгильдяя от... ?
От: Constructor  
Дата: 26.11.04 08:16
Оценка:
Здравствуйте, AndreyFedotov, Вы писали:

[...]
Во:!

ему не нужен "процесс" — ему нужен результат.


Это мне шеф постоянно и твердит, когда я ему пытаюсь объяснить, что сроки ставит нереальные...
А на мой взгляд, мы подошли к рубежу, когда маленькие программки разрослись, многое нужно модернезировать, чтобы развивать дальше...
Re[12]: Как отличить разгильдяя от... ?
От: AndreyFedotov Россия  
Дата: 26.11.04 08:40
Оценка:
Вот-вот. А понять Шефу, что результат — следствие правильно организованного процесса (не важно откуда он взялся — из собственной интуиции или мудрх книг) — кажется что может помочь только лоботомия...
Тут может помочь статистика — т.е. аккуратный и пунктуальный подстчёт времени, потраченного каждым разработчиком на те или иные задачи — представленный шефу в таком виде — что бы хорошо была видна цена тех срочных задач, которые ставятся перед разработчиками. Голословно утверждать можно что угодно. С фактами спорить сложнее. Если же он и это не воспримет — то, наверное, стоит задуматься о смене работы.
Re[13]: Как отличить разгильдяя от... ?
От: Spidola Россия http://www.usametrics.ru
Дата: 26.11.04 11:43
Оценка: 1 (1)
Здравствуйте, AndreyFedotov, Вы писали:

AF> Вот-вот. А понять Шефу, что результат — следствие правильно организованного процесса (не важно откуда он взялся — из собственной интуиции или мудрх книг) — кажется что может помочь только лоботомия...

AF> Тут может помочь статистика — т.е. аккуратный и пунктуальный подстчёт времени, потраченного каждым разработчиком на те или иные задачи — представленный шефу в таком виде — что бы хорошо была видна цена тех срочных задач, которые ставятся перед разработчиками. Голословно утверждать можно что угодно. С фактами спорить сложнее. Если же он и это не воспримет — то, наверное, стоит задуматься о смене работы.

Вообще-то в своё время в одной из компаний помогло следующее...
Ситуация была примерно такая, как здесь описывается ("Надо деньги зарабатывать, продукт продавать, а не всякие картинки рисовать!"), с попыткой силового давления на сроки Через некоторое время шефу попалась на глаза (а точнее была подсунута) парочка популярных книг типа "Как заработать деньги в ИТ" или "Правильная организация ИТ бизнеса" (сейчас уже не помню точно). Причём в контексте, мол, кто эту книжку не читал, тот лох позорный и всё такое...
Шеф почитал, понял мало чего (поскольку в ИТ специалистом никогда не был), но, будучи человеком прогрессивным и науки не чуждым (Оксфорд, всё таки) понял, что и ИТ бизнес имеет свои законы и правила. Поэтому на последующие замечания со стороны ИТ менеджмента о необходимости проектирования, прототипирования и прочих "ненужных" действиях уже реагировал вполне адекватно и специалистам начал доверять.
... << RSDN@Home 1.1.4 @@subversion >>
Re[14]: Как отличить разгильдяя от... ?
От: AndreyFedotov Россия  
Дата: 26.11.04 12:09
Оценка:
Здравствуйте, Spidola, Вы писали:

S>Вообще-то в своё время в одной из компаний помогло следующее...

S>Ситуация была примерно такая, как здесь описывается ("Надо деньги зарабатывать, продукт продавать, а не всякие картинки рисовать!"), с попыткой силового давления на сроки Через некоторое время шефу попалась на глаза (а точнее была подсунута) парочка популярных книг типа "Как заработать деньги в ИТ" или "Правильная организация ИТ бизнеса" (сейчас уже не помню точно). Причём в контексте, мол, кто эту книжку не читал, тот лох позорный и всё такое...
Хороший, умный и ловкий ход.
S>Шеф почитал, понял мало чего (поскольку в ИТ специалистом никогда не был), но, будучи человеком прогрессивным и науки не чуждым (Оксфорд, всё таки) понял, что и ИТ бизнес имеет свои законы и правила. Поэтому на последующие замечания со стороны ИТ менеджмента о необходимости проектирования, прототипирования и прочих "ненужных" действиях уже реагировал вполне адекватно и специалистам начал доверять.
Хорошо, что удачно сложилось. Чаще увы бывает, что пока речь идёт в общем — шеф доверяет, а когда дело доходит до реального проекта и сроков — 1-2-3-4-5 начинаем всё опять...
Re[8]: Как отличить разгильдяя от... ?
От: Spidola Россия http://www.usametrics.ru
Дата: 26.11.04 12:17
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

G>>Сколько именно строк кода конкретный программист колбасит в день — совершенно пофигу, лишь бы сильно не выбивалось за коридор средних (в обе стороны), это говорит о проблемах. Кстати, продуктивность в строках не так сильно зависит от языка. Речь идет о строках отлаженного кода без комментариев.


ГВ>Кстати, подтверждаю. Когда-то занимался анализом продуктивности по этой метрике. Действительно, всё так и есть. Во всяком случае, если речь идёт об одной и той же команде. Структурные метрики плавают в десятки раз (в особенности — Effort по Холстеду). Видимо, это как-то связано с манерой мышления и интуитивным выбором баланса между мышлением и воплощением.


Кстати, а по каким метрикам осуществлялось планирование объёма проектирования, тестирования и т.п. составляющих проекта в вашей конкретной ситуации? Вопрос навеян воспоминанием о схеме из RUP-а, где утверждалось, что непосредственно кодирование — это только около 30% проекта...
... << RSDN@Home 1.1.4 @@subversion >>
Re[9]: Как отличить разгильдяя от... ?
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.11.04 18:43
Оценка: 5 (1)
Здравствуйте, Spidola, Вы писали:

ГВ>>Кстати, подтверждаю. Когда-то занимался анализом продуктивности по этой метрике. Действительно, всё так и есть. Во всяком случае, если речь идёт об одной и той же команде. Структурные метрики плавают в десятки раз (в особенности — Effort по Холстеду). Видимо, это как-то связано с манерой мышления и интуитивным выбором баланса между мышлением и воплощением.

S>Кстати, а по каким метрикам осуществлялось планирование объёма проектирования, тестирования и т.п. составляющих проекта в вашей конкретной ситуации? Вопрос навеян воспоминанием о схеме из RUP-а, где утверждалось, что непосредственно кодирование — это только около 30% проекта...

Это были усреднённые показатели: берём общее количество строк кода (Logical Lines Of Code, не просто по счётчику), вычитаем сгенерированные и делим на продолжительность разработки — от постановки задачи до момента сдачи модуля. Разбор сделал где-то за полгода нашей деятельности, язык — C++. Производительность колебалась в пределах 70-180 строк/день по команде, по одному человеку разброс был где-то в пределах 10%, если приводить к месяцу.

S>а по каким метрикам осуществлялось планирование объёма проектирования

Ты неправильно понял. Метрики снимаются с готового проекта. До проведения некоторой фазы метрики её результата можно назвать только приблизительно. Хотя, можно набросать некоторые ожидаемые значения метрик после первоначального проектирования. В конце концов, взять число классов, число методов и помножить на некоторый коэффициент, вычисляемый в зависимости от языка програмимрования и дисциплины реализаторов. Но вот предсказать, сколько именно будет классов, каков коэффициент повторного использования... Мне тогда (1999-2000 гг.) это не удалось.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[10]: Как отличить разгильдяя от... ?
От: Gaperton http://gaperton.livejournal.com
Дата: 26.11.04 20:01
Оценка: 9 (2)
Здравствуйте, Spidola, Вы писали:

S>Во-первых разброс продуктивности по вашему коридору как минимум в три раза, что нехило (как при таком разбросе планировать, не очень понятно).

Это примерный коридор средних по индустрии. В рамках одной команды и одного языка разброс будет меньше (примерно десятка). У одного человека на одном языке средняя метрика на большом объеме кода вообще стабильна, и индивидуальна для человека. Поэтому я и говорю, что ее надо брать из завершенных проектов. Она в большей степени определяется стилем этого человека, нельзя судить о его профессионализме программеров сравнивая их продуктивность. Подробнее об этом здесь
Автор: Gaperton
Дата: 10.08.04
.

Но эта метрика отличается от задачи к задаче, даже у одного человека в рамках одного языка. Почему так? Потому, что колебания продуктивности отражают риски, учтенные в плане и фактически "сыгравшие" при решении задачи. Или степень компетентности конкретного программера в предметной области — да много чего. При планировании времени/объема вы фактически планируете продуктивность, и ее колебания вокруг среднего отражают ваше представление о рисках и прочих факторах, влияющих на продуктивность. Но вы делаете это опосредованно, прогнозируя объем и время. При этом, чрезмерное колебание продуктивности, выходящее за коридор разумного для конкретного программера/команды и/или не соответствующее вашему представлению о риске, сразу укажет вам на ошибку планирования. Вот вам и все "пи".

S>Во-вторых, сравниваемые вами языки достаточно близки (если бы вы сравнили хотя бы классический C++ и VB, у вас бы была разница где-то раза в 2. Не знаю, что там сравнивали в Ericsson, но я видел описанные в методиках conversion ratio для различных языков, предназначенные для анализа объёма кода, решающего одинаковые задачи, где даже C++ и Visual C++ отличаются в 1,5 раза.

Это мне, с моим основным средством Visual C++ непонятно. Скорее всего это потому, что в этих методиках прогноз делается через функциональные точки. В Visual C++ часть кода, относящегося к GUI, генерируется визардами. Автогенеренный код не должен участвовать в рассчете продуктивности, и этот коэффициент вычитает автогенеренный код. Время разработки также будет отличаться, а вот продуктивность в LOC в вашем примере не должна отличаться вовсе. Не с чего. Кстати замечу, что по приведенным вами данным ее вообще посчитать нельзя, я уж за вас додумываю, на что вы намекаете.

S>Вы имеете ввиду того Хамфри, который Уотс? К сожалению, пока не нашёл материалов с его авторством по поводу объёма в строках (может ссылочку какую подкините?), хотя человек, безусловно, незаурядный, хотя ИМХО слегка консервативный.

Он автор PSP, там все планирование делается формально через SLOC.


S>Объяснения по поводу простоты метрики не совсем меня убедили, а вот стабильность — это уже лучше.

LOC интуитивно понятна, ее легко прогнозировать. Спросите программера о длине функции. Он скажет — да фигня — пол экрана кода. Или, например, — "да он вообще офигел, у него один метод десять экранов кода занимает! Ужас". Хотите перевести это в строки кода? Умножте на размер "экрана". Об этом и речь.

А вы пробовали научится прогнозировать метрику Cyclomatic Complexity? Это не так просто (на самом деле — no way), плюс ко всему она скачет как черт знает что. Например, вы сделали небольшой рефакторинг, и видите, что кол. строк кода уменьшилось на 20%. Что это означает — ну можно предположить, что мы убрали копипейст и выделили общий функционал, правильно? А вот метрика cyclomatic complexity при этом скакнула на 15% вверх (из примера с сайта Carnegie-Mellon SEI, привожу по памяти). Сюрприз. Нового функционала вы не добавили — попробуйте как-нибудь это объяснить, и главное, спрогнозировать. Подобного рода сюрпризы вас будут ждать со всеми метриками, которые не вычисляются простым суммированием видимых глазом объектов.

Кстати еще насчет стабильности. Еще одна чрезвычайно стабильная метрика, основанная на LOC — это плотность дефектов штук/1000 строк. Вот она — нереально стабильна для одного человека — проверяли. Удивительно, но факт.

S>Когда посмотрю индустриальную статистику — может быть мнение опять таки изменится. Кстати, если уж зашла речь о данной статистике, то откуда вы её брали? Что-нибудь вроде документов Gartner Group или ещё где-то?

Я взял ее из статистики, собранной в рамках работ по PSP. Эта статистика собирается и обрабатывается Carnegie-Mellon SEI. Она сильно зависит от методики замера, естественно. Плюс, за последние несколько лет у нас накопилась статистика по нашей компании, которая укладывается в индустриальную. Имейте в виду, что продуктивность основанная на LOC зависит от методики измерения этих самых LOC, так что сравнивать замеры в разных компаниях надо осторожно. В общем, сходите на их сайт, там очень много есть про метрики.

S>Или основываетесь на EFP методе и подсчёте SLOC? Если последнее, то учёт SLOC требует глубокой проработки проекта на стадии проектирования, что не всегда возможно.

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

S>Мне больше импонирует, например, оценка по метрикам, основанным на анализе компонентов и их применимости. Потому что такие оценки дают достаточное понимание общего объёма работы, а дальнейшие уточнения можно проводить в рамках итерационного процесса параллельно с изменением и коррекцией требований. Я уж не говорю о том, что SLOC даёт объективную оценку, а некоторые методы разработки (например XP) подразумевают исключительно субъективную оценку теми, кто, собственно и будет разрабатывать ту или иную часть системы.

Так ваш прогноз SLOC и будет субъективен, и, кстати, не очень точен. В принципе, его можно сделать и точным до процентов, как это сделано в PSP (основываясь на данных по закрытым задачам + спец. схема обработки экспертных оценок), но не думаю, что это целесообразно. Геморроя много, а польза не очевидна.

S>Здесь, кстати, вижу в нашей дискуссии уход в разные плоскости. Когда я говорил о неприменимости отдельных метрик (в том числе и метрики по строкам кода), то не имел ввиду компании, которые могут себе позволить хотя бы приблизиться к возможности сертификации по CMM, по крайней мере по финансовым возможностям. Да и необходимости в этом нет, поскольку далеко не все компании работают на поле заказчиков, выдвигающих столь серьёзные требования к качеству процесса и, что немаловажно, готовых за это платить. А отслеживание любых метрик требует существенных ресурсов. Т.е. есть некоторый почти замкнутый круг.

В принципе, высокие уровни СММ не является необъходимостью для использования метрик при планировании и контроле. Это гораздо проще и дешевле, чем многие думают (и чем я думал раньше), к этому надо просто привыкнуть, и потом будешь удивляться, как обходился без метрик раньше. Надо всего-то вести статистику по чекинам — сколько строк кода удалено/изменено/добавлено (может считаться автомат. скриптом), да (если хочется) сделать привязку модулей и чекинов к базе данным по дефектам. И вы всю статистику получите почти автоматически. Чтобы потом поюзать несколько средних величин и коридоры значений в Excel, где будете делать прогноз.

S>>>Не понял. Как их можно учитывать не считая??? В процентах? Т.е. время на набор 20 программистов в Москве и в Усть-Урюпинске одинаково? И не зависит от среды разработки и платформы?

G>> Вы вот тут COCOMO упоминали. Неужели вы не знаете две элементарных формулы PERT, и не понимаете, как именно он помогает количественно учесть риски?
S>2 формулы PERT действительно не знаю... было бы интересно узнать, что вы имеете ввиду.
Освой PERT за 5 минут! Мастер-класс от Гапертона на rsdn.ru
Автор: Gaperton
Дата: 17.07.03

Это и на самом деле штука настолько простая, что говорить о ней смешно, а не использовать глупо. Там и магии-то нет почти никакой. Пользуйтесь на здоровье.
Re[11]: Как отличить разгильдяя от... ?
От: Spidola Россия http://www.usametrics.ru
Дата: 27.11.04 01:28
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, Spidola, Вы писали:


S>>Во-первых разброс продуктивности по вашему коридору как минимум в три раза, что нехило (как при таком разбросе планировать, не очень понятно).

G>Это примерный коридор средних по индустрии. В рамках одной команды и одного языка разброс будет меньше (примерно десятка). У одного человека на одном языке средняя метрика на большом объеме кода вообще стабильна, и индивидуальна для человека. Поэтому я и говорю, что ее надо брать из завершенных проектов. Она в большей степени определяется стилем этого человека, нельзя судить о его профессионализме программеров сравнивая их продуктивность. Подробнее об этом здесь
Автор: Gaperton
Дата: 10.08.04
.

G>Но эта метрика отличается от задачи к задаче, даже у одного человека в рамках одного языка. Почему так? Потому, что колебания продуктивности отражают риски, учтенные в плане и фактически "сыгравшие" при решении задачи. Или степень компетентности конкретного программера в предметной области — да много чего. При планировании времени/объема вы фактически планируете продуктивность, и ее колебания вокруг среднего отражают ваше представление о рисках и прочих факторах, влияющих на продуктивность. Но вы делаете это опосредованно, прогнозируя объем и время.

С этим согласен. Неясно только следующее... Если на коридор так существенно влияют дополнительные факторы предметной области, среды разработки и т.п., то в чём смысл наличия индустриальных средних? Т.е. я ещё могу доверительно относиться к исследованиям, утверждающим, что на один примитивный вывод информации в диалоговое окно уходит в среднем какое-то количество строк кода в зависимости от языка и среды разработки. Это звучит правдоподобно, потому что понятен базис расчёта — задача исключительно типовая (GUI). Что же касается, например, запросов к базе данных (так называемых Request-ов), то здесь совершенно неясно, как считается средний по индустрии LOC для SQL, поскольку запросы ОЧЕНЬ сильно отличаются в зависимости от структуры БД, СУБД, необходимости оптимизации и кучи дополнительных условий. Думаю, что похожая ситуация и с написанием классов предметной области.

Есть, конечно, разные корректирующие коэффициенты... Может в них дело?
Кстати, лучший коэффициент в планировании, который я встречал в своей жизни, был произнесён 15 лет назад моим первым шефом. Звучал примерно так: "хорошая система получается только с третьего раза". Очень стабильный коэффициент оказался.

G>При этом, чрезмерное колебание продуктивности, выходящее за коридор разумного для конкретного программера/команды и/или не соответствующее вашему представлению о риске, сразу укажет вам на ошибку планирования. Вот вам и все "пи".


Говоря проще, если вы сделали план, который не выполняется, то это означает, что вы ошиблись в планировании. Ну да, факт. Согласен.

S>>Во-вторых, сравниваемые вами языки достаточно близки (если бы вы сравнили хотя бы классический C++ и VB, у вас бы была разница где-то раза в 2. Не знаю, что там сравнивали в Ericsson, но я видел описанные в методиках conversion ratio для различных языков, предназначенные для анализа объёма кода, решающего одинаковые задачи, где даже C++ и Visual C++ отличаются в 1,5 раза.

G>Это мне, с моим основным средством Visual C++ непонятно. Скорее всего это потому, что в этих методиках прогноз делается через функциональные точки.

Да, совершенно верно. Это взято из описания метода Early Function Points.

G>В Visual C++ часть кода, относящегося к GUI, генерируется визардами. Автогенеренный код не должен участвовать в рассчете продуктивности, и этот коэффициент вычитает автогенеренный код. Время разработки также будет отличаться, а вот продуктивность в LOC в вашем примере не должна отличаться вовсе. Не с чего. Кстати замечу, что по приведенным вами данным ее вообще посчитать нельзя, я уж за вас додумываю, на что вы намекаете.


А что всё-таки понимается под "продуктивностью"?

G>Кстати еще насчет стабильности. Еще одна чрезвычайно стабильная метрика, основанная на LOC — это плотность дефектов штук/1000 строк. Вот она — нереально стабильна для одного человека — проверяли. Удивительно, но факт.


Попробую оценить. А как проверяли, если не секрет?

S>>Когда посмотрю индустриальную статистику — может быть мнение опять таки изменится. Кстати, если уж зашла речь о данной статистике, то откуда вы её брали? Что-нибудь вроде документов Gartner Group или ещё где-то?

G>Я взял ее из статистики, собранной в рамках работ по PSP. Эта статистика собирается и обрабатывается Carnegie-Mellon SEI. Она сильно зависит от методики замера, естественно. Плюс, за последние несколько лет у нас накопилась статистика по нашей компании, которая укладывается в индустриальную. Имейте в виду, что продуктивность основанная на LOC зависит от методики измерения этих самых LOC, так что сравнивать замеры в разных компаниях надо осторожно. В общем, сходите на их сайт, там очень много есть про метрики.

Уже там пасусь вовсю Правда объём информации великоват и есть предположение, что работает принцип 20/80 (т.е. 20% информации может действительно понадобиться), но, возможно, основные теоретические моменты удастся выцепить за достаточно разумное время.

S>>Или основываетесь на EFP методе и подсчёте SLOC? Если последнее, то учёт SLOC требует глубокой проработки проекта на стадии проектирования, что не всегда возможно.

G>Примерно прикидывается через функциональные точки, например. Или просто "из головы", но через PERT. Это можно сделать довольно рано. При большом количестве единиц планирования погрешность должна уйти до разумных пределов, и будет вполне адекватно. Точные значения на начальной фазе планирования все равно никого не интересуют, очевидно, что это невозможно в принципе.
Попробую проверить на следующем проекте. Посмотрим. Здесь же как — пока сам не убедишься — можно и теории верить, но осадочек остаётся...

S>>>>Не понял. Как их можно учитывать не считая??? В процентах? Т.е. время на набор 20 программистов в Москве и в Усть-Урюпинске одинаково? И не зависит от среды разработки и платформы?

G>>> Вы вот тут COCOMO упоминали. Неужели вы не знаете две элементарных формулы PERT, и не понимаете, как именно он помогает количественно учесть риски?
S>>2 формулы PERT действительно не знаю... было бы интересно узнать, что вы имеете ввиду.
G>Освой PERT за 5 минут! Мастер-класс от Гапертона на rsdn.ru
Автор: Gaperton
Дата: 17.07.03

G>Это и на самом деле штука настолько простая, что говорить о ней смешно, а не использовать глупо. Там и магии-то нет почти никакой. Пользуйтесь на здоровье.

Сенкс. Формулы простые и понятные. Непонятно только, как расчитывать переменные в этих формулах с наименьшей погрешностью.

P.S. Думаю, нужно будет вернуться к данной беседе где-то после нового года, поскольку в текущий момент чувствую некоторую нехватку информации, которая не даёт в некоторых случаях аргументировать интуитивные догадки. Интуиция — она вещь хорошая (мне за неё как раз деньги и платят ), но в контексте данной беседы всё же хочется аргументировать собственные мысли на том же языке, которым вы привыкли оперировать.
... << RSDN@Home 1.1.4 @@subversion >> Home
Re[11]: Как отличить разгильдяя от... ?
От: Gaperton http://gaperton.livejournal.com
Дата: 27.11.04 16:36
Оценка:
Здравствуйте, AndreyFedotov, Вы писали:

AF> Вот об этом и речь. Тут поминаются методы — которые применяются методы, используемые компаниями где сотрудников более 1000 (или нескольких сотен), причём для проектов стоимостями в сотни мегабаксов — причём над постановкой и контролем за выполнением процессов там работают целые команды.

Чепуха. Не знаю кто поминает такие методы, но мне кажется, вы на меня намекаете, да?

Вы хоть знаете, как расшифровывается PSP, помянутый здесь? Personal Software Process. Я надеюсь, вы знаете, что означает слово "personal"? Что касательно сотен мегабаксов и тысяч сотрудников... Ну в самом деле, ну должна же быть объективная причина, что вы этими методами не пользуетесь, а то ведь получится, что вы не разбираетесь в PM, так?

AF> А потом местные мудрецы с умным видом советуют применять те же методы в командах из 3-10 человек, да ещё над проектами, где заказчик с трудом готов оплачивать зарплату девелоперам...

Да где уж нам, мудрецам, до гуру, умножающих свои пророчества сроков на пи.
Re[2]: Как отличить разгильдяя от... ?
От: Леон Казахстан  
Дата: 30.11.04 11:03
Оценка:
Здравствуйте, mihhon, Вы писали:

M>Тут кто-то упомянул о числе пи, вспомнилось

M>Один кадр на проекте писал процедуру инициализации базы в течение года (и сейчас продолжает). То ошибки, то клиент вспомнит какую-нибудь забытую деталь, то полбазы попросит переделать и всё такое, классика. Авангард в том, что на днях его процедура доросла до 314 скриптов . Адская неподъёмная смесь perl, shell, PL/SQL и Java. Единственная и любимая методология — copy-paste. Поэтому когда клиент просит добавить пробел в одно поле, это может потребовать пары дней
Так это-же не столько проблемы управления, сколько оценка способностей человека ...

M>Вот это настоящий раздолба-разгильдяй. Причина всех остальных бедствий, описанных Constructor-ом — НУЛЁВЫЙ МЕНЕДЖМЕНТ. Да и авангардиста можно туда же. Не было вовремя подходящих ресурсов, поставили такого, вроде не дебютант. А потом шеф вовремя его не заменил.

Не совсем согласен что это менеджмент, это как раз проектирование ...

M>Кто становится шефами проектов ? Вчерашние программисты с техническим образованием ? Зачатки менеджмента, преподаваемые в институте, благополучно забИвались. Бывшие студенты-управленцы без представления об ИТ ? Если им не дают нормальных ресурсов — заваленные проекты

Кстати, интересное наблюдение, по окружающей обстановке. Заметил тенденцию что менеджерский состав в больше половины проектов компании (обращаю внимание что это imho) описать так, женщина, желательно за 40 и желательно без сильных семейных привязаностей. И что самое интересное это эффект — менеджмент превращается в ежечастное — "ну как у нас дела?", "успеваем ли в сроки?" и т.д. и т.п., причём ставка явно сделана именно на женский пол Мы с нетерпением ожидаем окончания эксперимента ....


M>Отдельная категория — ставшие умственными инвалидами-параноиками. Дебютанты, решившие, что они способны. И попросившие (или согласившиеся принять) ответственность. А по ним проехались катком их оппоненты-клиенты с 20..30 летним опытом. А собственное начальство сделало их козлами отпущения. Жалкое зрелище

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

M>Моё мнение, что человек без 4..6 лет опыта в ИТ, из них 2..3 шефом команды или проекта, мало чего стоит с т.з. менеджмента и не автономен. И неплохо в начале поучаствовать шефом команды в немаленьком проекте (человек 30..50) под управлением реального профессионала. Хороший размер проекта, на котором присутствуют очень много профилей: от дебютантов до профессионалов, от клёвых перцев до полных моральных уродов. И интересоваться не только RUP и CMM, а расширять кругозор психологией, управлением, политикой, ... иначе вас съедят

Как таковой (imho), методология это не закон, это рекомендация, а уж как ты работаешь и тем более как управляешь проектом, это твой личный опыт, который ты применяешь и развиваешь соответсвенно.
Никакая методология не научит человека, правильно вести себя в стресовой ситуации, например когда понимаешь что была допушена ошибка в планировании, а сроки уже поджимают. Каждый будет вести себя так, как умеет, может где-то видел, но всё равно это будет индивидуально.
И (imho) управление как таковое представляется именно твоим взглядом на ситуацию (проект, сроки, планы и т.п.) и то как ты будешь решать проблемы. А научиться видить, умеет ли человек решать проблему и доводить задачу до конца, с приемлемым или хорошим качеством, это уже дело опыта.
... << RSDN@Home 1.1.4 @@subversion >>
Re[12]: Как отличить разгильдяя от... ?
От: AndreyFedotov Россия  
Дата: 30.11.04 13:50
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, AndreyFedotov, Вы писали:


AF>> Вот об этом и речь. Тут поминаются методы — которые применяются методы, используемые компаниями где сотрудников более 1000 (или нескольких сотен), причём для проектов стоимостями в сотни мегабаксов — причём над постановкой и контролем за выполнением процессов там работают целые команды.

G>Чепуха. Не знаю кто поминает такие методы, но мне кажется, вы на меня намекаете, да?
Мания величия в активной фазе...

G>Вы хоть знаете, как расшифровывается PSP, помянутый здесь? Personal Software Process. Я надеюсь, вы знаете, что означает слово "personal"? Что касательно сотен мегабаксов и тысяч сотрудников... Ну в самом деле, ну должна же быть объективная причина, что вы этими методами не пользуетесь, а то ведь получится, что вы не разбираетесь в PM, так?

Personal Computer применяется отдельными персонами — как в компании из 1-2-3 человек так и в мегакорпорациях с сотнями тысяч сотрудников. Вот и PSP применяется каждым персонально но в рамках компании практически любого масштаба. А вот позволить себе нанять людей которые будут толком ставить процесс — на практике как правило могут себе позволить лишь достаточно большие компании.

AF>> А потом местные мудрецы с умным видом советуют применять те же методы в командах из 3-10 человек, да ещё над проектами, где заказчик с трудом готов оплачивать зарплату девелоперам...

G>Да где уж нам, мудрецам, до гуру, умножающих свои пророчества сроков на пи.
Естественно — вы же и до ПИ пока не доросли...
Re[13]: Как отличить разгильдяя от... ?
От: Gaperton http://gaperton.livejournal.com
Дата: 30.11.04 16:59
Оценка:
Здравствуйте, AndreyFedotov, Вы писали:

AF>Здравствуйте, Gaperton, Вы писали:


G>>Здравствуйте, AndreyFedotov, Вы писали:


AF>>> Вот об этом и речь. Тут поминаются методы — которые применяются методы, используемые компаниями где сотрудников более 1000 (или нескольких сотен), причём для проектов стоимостями в сотни мегабаксов — причём над постановкой и контролем за выполнением процессов там работают целые команды.

G>>Чепуха. Не знаю кто поминает такие методы, но мне кажется, вы на меня намекаете, да?
AF> Мания величия в активной фазе...
Ой прости, это было так самонадеянно с моей стороны подумать, что сам ТЫ имел в виду мои посты, отвечая в ветке, где их половина. Мания величия, не иначе. А ты, оказывается, в очередной раз говоришь непонятно о чем имея в виду непонятно кого, и всего то. Учту на будущее.
Re[4]: Как отличить разгильдяя от... ?
От: Softwarer http://softwarer.ru
Дата: 01.12.04 11:02
Оценка:
Здравствуйте, kbasil, Вы писали:

Д>>(C) законы Мерфи

K>Это один из законов Паркинсона

Если еще точнее — это так называемый "Принцип Питера" одноименного автора, получивший известность во многом благодаря критике этого принципа в "Законах Паркинсона"
Re[3]: Как отличить разгильдяя от... ?
От: mihhon  
Дата: 01.12.04 12:10
Оценка: 7 (2)
Л>Так это-же не столько проблемы управления, сколько оценка способностей человека ...
почему? выбивание нормальных ресурсов (а такие ресурcы, как правило, всегда заняты) на проект — дело шефа проекта.

Л>Кстати, интересное наблюдение, по окружающей обстановке. Заметил тенденцию что менеджерский состав в больше половины проектов компании (обращаю внимание что это imho) описать так, женщина, желательно за 40 и желательно без сильных семейных привязаностей. И что самое интересное это эффект — менеджмент превращается в ежечастное — "ну как у нас дела?", "успеваем ли в сроки?" и т.д. и т.п., причём ставка явно сделана именно на женский пол Мы с нетерпением ожидаем окончания эксперимента ....

"ну как у нас дела?", "успеваем ли в сроки?" — это профессиональные слова-паразиты шефов, вне зависимости от пола

M>>Отдельная категория — ставшие умственными инвалидами-параноиками. Дебютанты, решившие, что они способны. И попросившие (или согласившиеся принять) ответственность. А по ним проехались катком их оппоненты-клиенты с 20..30 летним опытом. А собственное начальство сделало их козлами отпущения. Жалкое зрелище

Л>Ну это уже клиника, подобные вещи можно сразу определить на глаз
Помимо паранои они ещё обычно лицемерят , т.е. это уже шизофрения — раздвоение личности: с подчинёнными один человек, с начальством другой. Так что клинику с первого дня можно не заметить. Хо злелище всё равно жалкое. Ну и типичные приёмы таких инвалидов — защищаться повсюду подписями/мэйлами ответственных людей, самому ничего документально не подтверждать, перепоручать всё подчинённым, не давая чётких заданий, валить, не стесняясь выражений, все промахи на подчинённых. Понятно, что это список скиллов, необходимых любому начальнику , но у инвалидов это доведено до маниакально-паранойного-шизофренического уровня.

если кому интересны другие приёмы начальства, настоятельно рекомендую вот эту книжку — супер:
http://www.ozon.ru/context/detail/id/1207987/
настолько живописно и доходчиво расписаны все клише и нелепости, которыми начальство пытается кормить подчнённых, что придя на работу на следующий день у вас будет впечатление, что ваше начальство училось по этой книжке
Re[4]: Как отличить разгильдяя от... ?
От: AndreyFedotov Россия  
Дата: 01.12.04 12:25
Оценка:
Спасибо.
Re[3]: Как отличить разгильдяя от... ?
От: Spidola Россия http://www.usametrics.ru
Дата: 01.12.04 22:55
Оценка: +1
Здравствуйте, Леон, Вы писали:

Л>Кстати, интересное наблюдение, по окружающей обстановке. Заметил тенденцию что менеджерский состав в больше половины проектов компании (обращаю внимание что это imho) описать так, женщина, желательно за 40 и желательно без сильных семейных привязаностей. И что самое интересное это эффект — менеджмент превращается в ежечастное — "ну как у нас дела?", "успеваем ли в сроки?" и т.д. и т.п., причём ставка явно сделана именно на женский пол Мы с нетерпением ожидаем окончания эксперимента ....


Если такое положение дел раздражает, то могу дать дельный совет:

— на вопрос "ну как у нас дела?" нужно давать развёрнутый ответ — как у вас дела. Чем развёрнутей, тем лучше. Если в ответе повторяется всё то же самое, что и в прошлом ответе на такой же вопрос — это вообще супер. Практика показывает, что выдержки у спрашивающего хватает на 6-8 раз. Особо занудливые могут, правда, дотянуть до 15-ти.

— на вопрос "успеваем ли мы в сроки" просить таймаут на 15 минут, потом срываться бегом за свой стол, распечатывать кучу бумаги с диаграммами Ганта и другими сопутствующими документами, всю эту кипу приносить обратно и, начиная водить пальцем по графикам, нудным голосом пояснять, где, что и как происходит. Желательно как можно более детально и громко, чтобы как можно больше народу вокруг слышало. После нескольких раз вопрос исчезает, посколько мало кому из руководящего персонала хочется выглядеть идиотом перед окружающими, или вы наконец приходите к нормальным взаимоотношениям с начальником.

Кстати, приведённый пример очень характерен в компаниях, где путают понятие "менеджер" и "администратор". В качестве администраторов описанные типажи вполне нормально работают.
... << RSDN@Home 1.1.4 @@subversion >> Home
Re[6]: Как отличить разгильдяя от... ?
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 02.12.04 02:44
Оценка:
Здравствуйте, mihhon, Вы писали:

ГВ>>Вопрос, который я люблю задавать любителям отчётности (простите за ёрничающий тон): как нужно отображать в отчёте процесс размышлений над некоторой задачей? А спонтанные микросовещания, которые могут длиться по полтора-два часа?

M>1. почитай вот эту статью
M>http://www.joelonsoftware.com/global/Russian/Articles/PainlessSoftwareSchedules.html
M>2. любая мало-мальски серьёзная система стоит денег. чтоб инвестор или клиент дал денег, ему нужен план: что, когда и сколько будет стоить. все серьёзные системы написаны по планам. отчётность служит для оценки и корректировки планов.

Давай не путать калий с кальцием? План разработки продукта — это одно, а ежедневная по-получасовая отчётность — совсем другое.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[7]: Как отличить разгильдяя от... ?
От: mihhon  
Дата: 05.12.04 02:00
Оценка:
M>>2. любая мало-мальски серьёзная система стоит денег. чтоб инвестор или клиент дал денег, ему нужен план: что, когда и сколько будет стоить. все серьёзные системы написаны по планам. отчётность служит для оценки и корректировки планов.

ГВ>Давай не путать калий с кальцием? План разработки продукта — это одно, а ежедневная по-получасовая отчётность — совсем другое.


Мало какой проект следует точно исходному плану. Меняются требования, уточняются оценки.

Ещё раз прочитай вот эту фразу: "отчётность служит для оценки и корректировки планов". Затем выбери уровень грануляции, с которой ты должен посчитать свой план. Конкетный пример: директор проекта размером в 6000 человекодней считает с погрешнотью в 100..200..500..1000 дней (15% вполне допустимый риск). С шефов команд он спрашивает планнинг отдельных задач с точностью до недель. Если шеф команды не лопух, то с разработчиков он спросит еждневную отчётность, либо сам будет вести эту отчётность, чтоб не напрягать разработчиков.

Имея на руках ежедневную отчётность разработчиков составить оценку будущей подобной задачи не составляет большого труда. Это дело техники. Достаточно попросить разработчиков потратить 10 минут в неделю на то, чтоб описать то, что они сделали. Или самому записать.
Re[5]: Как отличить разгильдяя от... ?
От: Павел Дмитриев Россия  
Дата: 11.12.04 13:29
Оценка: 26 (3)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Вопрос, который я люблю задавать любителям отчётности (простите за ёрничающий тон): как нужно отображать в отчёте процесс размышлений над некоторой задачей? А спонтанные микросовещания, которые могут длиться по полтора-два часа?


Попробуйте почитать о системе А.А.Любищева. http://www.improvement.ru/bibliot/altshull.shtm

Она правда не для программистов А для творческих работников Которые всю жизнь проводит в
"процессе размышления над некоторой задачей".

--- Цитата ---
...он (Любищев) ЕЖЕДНЕВНО записывал: сколько времени потрачено на основную научную работу, сколько времени – на дополнительную, какие были ещё работы, сколько времени потеряно и почему. Каждый месяц составлялась сводка, каждый год проводился годовой баланс. Учитывалось только «чистое» время – без потерь на организацию, пустые заседания, пустые разговоры, ожидания и пр. Точность учёта – 10 минут. Следует ещё раз подчеркнуть: учёт вёлся ежедневно на протяжении 56 лет.

Но система действительно жестока. Она неизбежно показывает человеку уровень его работы. Достичь 7-8 часов чистого времени творческой работы в день достаточно трудно, не время от времени, а стабильно каждый день. Это мощный удар по самолюбию. Некоторые предпочитают отвернуться от этого жестокого зеркала и по-прежнему считать себя трудягой и ломовой лошадью, если нарабатывают, как все нормальные люди, 3-4 часа чистого времени творческой работы. Но когда видишь эти цифры, то обманывать себя становится трудно, и люди прекращают вести учет времени. Так спокойнее, и всегда можно пожаловаться самому себе и окружающим, что ты очень занятый человек.
--- Конец цитаты ---

Кстати, советую заглянуть на сайт "Органицация времени"
Краткий каталог материалов сайта «Организация времени»
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Re[4]: Как отличить разгильдяя от... ?
От: minorlogic Украина  
Дата: 13.12.04 08:38
Оценка:
Думаю это глубокое заблуждение , человек или УЧИТСЯ И УМЕЕТ или НЕУЧИТСЯ И НЕУМЕЕТ .

Как он может быть продуктивным если не учится и не страется ? Опишите такую ситуацию, если я ошибаюсь.
Ищу работу, 3D, SLAM, computer graphics/vision.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.