Моя производительность в написании программ

[arseniiv]

(Оффтоп)

creative в сообщении #357922 писал(а):

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

Я вот сейчас как раз таким способом (правда, не разные программки, а одну модифицирую) учусь засовывать Lua в Delphi правильно.

[brimal]

Норматив для профессионала: 120-150 строк отлаженного кода в день.

[мат-ламер]

brimal в сообщении #358062 писал(а):

Норматив для профессионала: 120-150 строк отлаженного кода в день.

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

[Maslov]

brimal в сообщении #358062 писал(а):

Норматив для профессионала: 120-150 строк отлаженного кода в день.

Откуда взялся этот "норматив", как он рассчитывается, кем используется и для чего?

[brimal]

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

-- Пт окт 01, 2010 21:24:40 --

Более точно, рассчитываются на основе измерений.

-- Пт окт 01, 2010 21:43:31 --

В результате возможна такая организация работы программистов.
Фирма. Швеция. Штат: около 70 программистов со всего мира.
Вы приезжаете на работу и можете сразу идти в бар. Вас никто не контролирует.
Делайте, что хотите в течение рабочего дня. Но к заданной дате Вы обязаны сдать
свой участок кода, полностью удовлетворяющий ТЗ.
Предваряю вопрос. Чистую науку пока и они нормировать не могут.

-- Пт окт 01, 2010 21:59:40 --

Уточнение. Данные на 90е годы. Видимо сейчас другие.

[Maslov]

brimal в сообщении #358092 писал(а):

Взято из западных источников и усреднено.(Источники, признаюсь, практически единичные. )

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

brimal в сообщении #358092 писал(а):

В результате возможна такая организация работы программистов.
Фирма. Швеция. Штат: около 70 программистов со всего мира.
Вы приезжаете на работу и можете сразу идти в бар. Вас никто не контролирует.
Делайте, что хотите в течение рабочего дня.

Такая система труда программистов невозможна: разработка ПО -- это командная работа, и попытка организовать её описанным Вами способом -- это верный способ завалить любой проект.

[brimal]

1.Не тешьте себя иллюзиями. После того как сформировано ТЗ (т.е. оформлена идея),
далее все остальные исполнители с точки зрения экономики принципиально не отличаются от простого рабочего. Что значит решить задачу, если есть ТЗ на модуль?
Основное все решено. А далее обычная рутина с производительностью труда, планированием сроков и т.п. И в основе этого нормирование труда. Вполне естественно, что ни
в отечественных ни западных фирмах, но работающих у нас с нашим персоналом,
этого нет. Я потвторяю не доросли. (Прочтите первый пост. 20 строк в день. Да он бездельник или малоопытен). Но предполагать, что на западе с его жесточайшим детализированным бюджетированием может существовать вольница подобной нашей
не рекомендую. Впрочем, можете писать по 20 строк и считать себя профессионалом.
Для нас это типично.
2. Обращаю внимание, что это на уровень 90х. Более того, начало 90х (Я наткнулся на эти цифры в середине 90х в переведенной литературе). С новыми редакторами, критерии видимо другие. Но то, что они существуют в этом я абсолютно убежден.
На западе вы ни цента задаром не получите. Многолетний опыт банкротств хороший учитель. Мы только учимся.
3. Насчет ПО и команды. Всегда есть выражаясь по нашему постановщик, по ихнему менеджер проекта. Он распределяет задания между членами команды, определяя
ТЗ и СРОК исполнения. (У них это обязательно, а у нас довольно необязательная вещь). Конечно, я несколько утрировал постановку организации в этой фирме. Есть и промежуточный контроль по этапам, есть и кое что иное. Но мелочного контроля нет.
"Время -деньги". Это не просто красививая фраза, это руководство к действию.
4.Вероятно я не прав. Охотно соглашусь. Но по роду своей работы я часто вынужден
давать задания другим людям. И всегда после обсуждения я задаю последним вопрос:
"Когда?". После получения ответа , квадратик блок схемы проекта, сразу превращается в кружочек сетевого графика. И мне легко далее, и людям легко.
Конечно, если они выполняют свои обязательства.

[Maslov]

brimal в сообщении #358130 писал(а):

1.Не тешьте себя иллюзиями. После того как сформировано ТЗ (т.е. оформлена идея),
далее все остальные исполнители с точки зрения экономики принципиально не отличаются от простого рабочего. Что значит решить задачу, если есть ТЗ на модуль?
Основное все решено. А далее обычная рутина с производительностью труда, планированием сроков и т.п. И в основе этого нормирование труда.

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

brimal в сообщении #358130 писал(а):

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

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

brimal в сообщении #358130 писал(а):

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

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

[brimal]

на цифру я то наткнулся, но как она получена сам гадаю.

-- Сб окт 02, 2010 15:50:50 --

Когда работал программистом на себе проверил. Конечно это не мой уровень, но что то в ней есть.

[vek88]

Уже давно, если и программирую, то "для себя". В том смысле, что я и постановщик задачи, и приемщик задачи. Но вот в конце 80-х - начале 90-х у меня была команда 5 - 10 программистов. Так вот:

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

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

А дальше все просто - распределил работу на порядка 5 программистов. Подчеркиваю - сколько строк получится у каждого, не знал. Но у меня было четкое интуитивное ощущение о трудоемкости всего проекта и отдельных модулей. Очень помогла книга Донована Системное программирование. Ранее хорошо изучил ее - там была глава о разработке ассемблеров - и использовал теперь в качестве подсказки к проектированию конкретного кроссассемблера.

Сделали на C и сдали смежникам кроссассемблер в срок.

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

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

ЗЫ. Все что я сказал, впрочем, это ИМХО стандартные приемы руководства любым проектом в любой области. Конечно, если есть методики нормирования работ, то все упрощается. Это имеет место, например, в производстве типовых строительных работ. Но в программировании ... это вряд ли возможно, во всяком случае в нестандартных задачах.

[brimal]

Время выполнения=трудоемкость задания/производительность
Попробуйте дать определения

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

-- Вс окт 03, 2010 10:31:12 --

С этого момента все можно переносить в раздел экономики.

[Maslov]

brimal в сообщении #358510 писал(а):

Итак, в каких единицах измеряем трудоемкость?

В человеко-часах.

[Zealint]

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

[Maslov]

Zealint в сообщении #358559 писал(а):

В таком случае производительность должна измеряться в человеко-часах / час.

А зачем она должна измеряться? Для достижения какой практической цели?

[brimal]

В этой отрасли реальной экономики не работал экономистом.
Однако попробую смоделировать.
ИТак, крупная компьютерная фирма (несколько десятков рабочих). Доопределение:профиль действия -программирование
Профиль фирмы задан определенным кругом задач (очевидная предпосылка,т.к.
фирмы с неопределенным (широким) кругом задач нежизнеспособны)
Задача: оценить штатное расписание. Естественно обращаемся к нормированию труда.
Другого метода нет.
1.Отбрасываем новичков (метод-стаж. На основе опыта-не менее 3х лет. Вопрос для доработки-стаж в этой фирме или вообще. На других не известно чем они там занимались. Желательно на этой фирме. Тогда можно оценить возможность понижения планки до 2х лет). Получаю данные от отдела кадров.
2. Труд интеллектуальный, поэтому надо учитывать
- необходимость перерывов (операционное время даже для трудоголиков интеллектульного труда не превышает 6 час в сутки). Остальное обсуждения,писанина все чего может быть, отдых и т.п.
- возможность итальянить (сидеть, имитируя проиводственную деятельность)
Уменьшим выборку до среднестатистической по времени фактической работы (операционное время). Метод: моментные наблюдения
3. Определяем количество (столь обруганных) строк кода (операторов)) за определенный период. Данные: доступ к продуктам(не обязательно законченных),которые создали рабочие из выборки.
4.Определяем размер и количество типовых модулей в задачах решаемых фирмой.
Метод: анализ сданных проектов с привлечением постановщиков.
Далее все остальное:
анализ имеющихся рабочих
на основе бюджетирования определение штатного расписания и ФЗП
многое другое. (На каждом этапе обязательна статистическая обработка)
Замечание.Желательно провести работу также по выборке составленной из сильнейших
Метод создания выборки: сарафанное радио (иначе, общественное мнение).
По конечным результатам оценить разницу по первой выборке и этой.
Модифицировать нормативы, создавая стимулирующие. Использовать в этой связи
премиальную систему оплаты труда.
5. Создание соответствующего регламента.
6. Не реже 1 раза в год повторять данную работу, модифицируя нормативы.
(это важно в начале. Обычно, применение таких методов управления приводит к серьезной перестройке в деятельности любой фирмы. Потом можно делать реже, но для спокойствия не реже, чем раз в 2 года.).
К деталям можете не цепляться. Нормирование труда это очень серьезная вещь, не уступающая по своей сложности разработке методик в экспериментальной физике.
Думаю, что я лучше вас представляю, насколько все это сыро. Но для начала разработки вполне.

-- Вс окт 03, 2010 13:38:15 --

MASLOV
Что будет в основании норматива в человек/час?