информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Атака на InternetГде водятся OGRыSpanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Бэкдор в xz/liblzma, предназначенный... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / theory
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Ну если хочешь в гамаке и стоя - кто ж тебе запретит :-) 24.03.06 12:41  Число просмотров: 2998
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
Как по мне тут либо сдельная система. На каждый модуль выделяется бюджет: вносится аванс, остаток - после окончания. Модификации: вместо аванса - выдавать траншами каждый месяц или еще чего нить. Тут вообще лучше не нанимать никого на фултайм, а положиться на фриланс-биржи.

Либо повременка. Как я ее себе представляю, я описал выше.

Не вижу иных способов эффективно управлять работой сотен программистов.
<theory>
Выношу на обсуждение вопрос оплаты труда программистов и дизайнеров... 23.03.06 15:33  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
Итак, предположим, имеется БОЛЬШОЙ проект, в котором трудятся сотни разработчиков кода и дизайнеров морды.

Вопрос: как сделать так, чтобы никто не был в обиде по баппкам?
Это я понимаю, нереально, но может есть у кого-нить примеры или идеи?
Желательно чтобы процесс максимально возможно поддавался автоматизации :-)

Заранее всем огромное спасибо за ответы.
Спасибо всем за информацию, в целом тенденции понятны. Но есть одно маленькое уточнение по поводу автоматизации… :) 24.03.06 06:36  
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 24.03.06 06:47  Количество правок: 2
<"чистая" ссылка>
Тут много говорилось про человеко-часы... Не пойдёт... Проект предполагается быть распределённым и удалённым, конечно, предполагается координатор, но могут быть и альтернативные ветви кода в проекте, ибо несколько разработчиков могут ухватится за кусок "мяса" и запостить изменения. Т.е. в конце концов на первое место становится юзабилити кода, а не часы. И обижаться в принципе, не на кого, ибо не ты виноват, что твой код не взяли, а сообщество.

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

У кого какие идеи? Спасибо.
Программизм - процессс творческий, это не гайки на конвеере... 24.03.06 10:42  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
Программизм - процессс творческий, это не гайки на конвеере крутить. Можно за час что-то приличное наваять, когда прет, а можно день ошибку искать. За что платить - за строчку или за день труда. По хорошему надо учесть все. Погрешность допустима, это все понимают. Поэтому оценивать объем труда должен толковый человек, который и учтет байты/строки/операторы кода, и их сложность. А термин "человекочасы" употреблялся как "трудоемкость".

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

Кгда-то давно знакомый профессор-экономист умудрился раздобыть какие-то нормативы для расчета трудоемкости написания программы. На мой взгляд они были слишком виртуальные.

> У кого какие идеи? Спасибо.
Все ниокры уже давно застандартизированы до немогу, одни лишь программисты хватаются за "творческий процесс" 24.03.06 11:37  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Программизм - процессс творческий, это не гайки на конвеере
> крутить. Можно за час что-то приличное наваять, когда прет,

Знакомая отмазка, я и сам ее часто применяю :-)
Прикол в том, что в зависимости от того, насколько часто тебя "прет" и какого качества код выходит из под твоих пальцев, можно примерно оценить стоимость СРЕДНЕГО часа твоей работы. Думаешь у фармацевтов не творческая работа? А у конструкторов авиадвигателей? А у генных инженеров? Открою секрет полишинеля: практически вся работа в ПОСТиндустриальном обществе творческая. А люди справляются и даже умудряются создавать корпорации (которые просто невозможны без формализации практически всего производственного процесса).

Гм. Даже гугль в АВТОМАТИЧЕСКОМ режиме определяет релевантность страницы какому либо запросу (фактически тоже творческая работа), а мне тут говорят, что нельзя определить релевантность программиста проекту.

Еще пример: посмотри на стратегии (лучше RTS) и на RPG. Чаще всего имеются несколько рас с совершенно разными характеристиками. Как сделать так, чтобы между ними соблюдался баланс? Правильно - выпускать патчи в которых попускать или усиливать ту или иную расу до тех пор, пока на первых местах в BattleNet-е не будут представлены примерно поровну все расы.

> а можно день ошибку искать. За что платить - за строчку или
> за день труда. По хорошему надо учесть все. Погрешность

Платить за час. Но периодически (стандартно - раз в полгода, но можно чаще или реже в зависимости от специфики) проводить ревью. Итерационный процесс в конце концов сходится на оптимальном (для данного коллектива) распределении ресурсов. Для ревью ОБЯЗАТЕЛЬНО опрашивать всех участников процесса, но лучше к нему привлекать и экспертов - людей, разбирающихся в программировании, но не имеющих никакого отношения к данному процессу (или даже коллективу).

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

> допустима, это все понимают. Поэтому оценивать объем труда
> должен толковый человек, который и учтет
> байты/строки/операторы кода, и их сложность. А термин
> "человекочасы" употреблялся как "трудоемкость".

Нет. Один человек ТОЧНО не сможет быть объективным. Например я хоть и довольно опытный разработчик, но дельфисты у меня получили бы ОЧЕНЬ мало независимо от количества строк и пр.. Другое дело если ВЕСЬ коллектив считает, что дельфистам в этом проекте не место. И наоборот, если дельфисты считают, что сишники только тянут за собой ворох проблем по стыковке кода - ради бога: в ДАННОМ проекте сишникам не место.

> > в справедливости, одна строка кода может быть
> "золотой" и
> > коренным образом повлиять на продажи и юзабелити (ну
> это я

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

> Кгда-то давно знакомый профессор-экономист умудрился
> раздобыть какие-то нормативы для расчета трудоемкости
> написания программы. На мой взгляд они были слишком
> виртуальные.

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

> > У кого какие идеи? Спасибо.

Учись у гугля :-)
Повторяю — повремёнки не будет. Только код и статистика его использования. 24.03.06 12:15  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
Ну если хочешь в гамаке и стоя - кто ж тебе запретит :-) 24.03.06 12:41  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
Как по мне тут либо сдельная система. На каждый модуль выделяется бюджет: вносится аванс, остаток - после окончания. Модификации: вместо аванса - выдавать траншами каждый месяц или еще чего нить. Тут вообще лучше не нанимать никого на фултайм, а положиться на фриланс-биржи.

Либо повременка. Как я ее себе представляю, я описал выше.

Не вижу иных способов эффективно управлять работой сотен программистов.
Согласен 24.03.06 15:01  
Автор: whiletrue <Роман> Статус: Elderman
<"чистая" ссылка>
> Как по мне тут либо сдельная система. На каждый модуль
> выделяется бюджет: вносится аванс, остаток - после
> окончания. Модификации: вместо аванса - выдавать траншами
> каждый месяц или еще чего нить.

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

HandleX, все таки в чем по-твоему принципиальное различие между коэффициентом сложности кода и часами? Такая же абстрактная цифирь - просто привязать к часам - как-то нагляднее, чем, к примеру, число от 0 до 1 =)

> Тут вообще лучше не
> нанимать никого на фултайм, а положиться на фриланс-биржи.

Да можно и нанимать - принципиальной разницы нет, имхо... Просто если чел на окладе, то он должен выполнять не меньше чем... а за перевыполнение - премия.

> Либо повременка. Как я ее себе представляю, я описал выше.
> Не вижу иных способов эффективно управлять работой сотен
> программистов.

Согласен, способ обкатанный - остальное изобретение велосипеда, имхо
Со всеми ниже согласен 24.03.06 04:38  
Автор: whiletrue <Роман> Статус: Elderman
Отредактировано 24.03.06 05:06  Количество правок: 4
<"чистая" ссылка>
Однако, всякие МСПрожект и прочие рисования квадратиков и кружочков - не люблю - это нужно только чтобы клиенту или большому боссу пыль в глаза пустить.... на этом должен сидеть отдельный человек и к реальным задачам оно никак не должно относиться - мое сугубо личное имхо =)

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

На 1С 7.7 есть такая конфа - Автоматизация работы франчайзи (АРФ). Вышеизложенная идея взята оттуда (хотя, к примеру, у голландцев - какая-то похожая система). Мне довелось буквально месяц назад переписать это все на 8.0 и сделать Веб-интерфейс к этой байде на си шарпе (юзая одноэсную веб-компоненту)... Была учтена специфика, что контора не только на 1С пишет, а еще работает с иностранцами, и выкинуто много лишнего (специфичного) =), т.е. уже ни чистый АРФ, а достаточно универсальная прога... Если интерсно - пиши в личку и/или в мыло
"Желательно чтобы процесс максимально возможно поддавался автоматизации" - здесь несколько уровней автоматизации 23.03.06 18:05  
Автор: Garick <Yuriy> Статус: Elderman
Отредактировано 23.03.06 18:09  Количество правок: 1
<"чистая" ссылка>
Управление проектом - проектный менеджмент по PMI (Project Managenent Institute). Здесь и бюджет проекта расчитывается.
Если продукт под МС платформу - MSF (Microsoft Solution Framework).

Управление разработкой - team frameworkи, CVSки подбираются под конкретную среду разработки.
Управление тестированием.

Ну и автоматизация других процессов, начисления и выдачи ЗП, например.

Самое сложное - бюджетирование. Для этого надо знать нормы выработки и ее стоимость. В советское время можно было найти справочники по нормам строительным, например. По софт девелоперским - не встречал. Это експаренс, который у топеров проекта и редко когда им деляться:-)
Сначала сметная стоимость прикидывается. Приблизительный... 23.03.06 15:56  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
> Итак, предположим, имеется БОЛЬШОЙ проект, в котором
> трудятся сотни разработчиков кода и дизайнеров морды.

Сначала сметная стоимость прикидывается. Приблизительный объем работы в человекочасах умножается на стоимость человекочаса. Потом это еще на 2-3 надо умножить :-).

> Вопрос: как сделать так, чтобы никто не был в обиде по
> баппкам?

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

> Это я понимаю, нереально, но может есть у кого-нить примеры
> или идеи?

Лучше обратится в действующую контору и аккуратно заинтересовать их, чтоб они часть своих "человекочасов" кинули на новый проект.

> Желательно чтобы процесс максимально возможно поддавался
> автоматизации :-)

Координатор нужен. Люди должны быть опытные и сплоченые в команде.

> Заранее всем огромное спасибо за ответы.
Оффтоп 23.03.06 17:03  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Сначала сметная стоимость прикидывается. Приблизительный
> объем работы в человекочасах умножается на стоимость
> человекочаса. Потом это еще на 2-3 надо умножить :-).

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




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach