Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
|
Спасибо всем за информацию, в целом тенденции понятны. Но есть одно маленькое уточнение по поводу автоматизации… :) 24.03.06 06:36 Число просмотров: 3157
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 24.03.06 06:47 Количество правок: 2
|
Тут много говорилось про человеко-часы... Не пойдёт... Проект предполагается быть распределённым и удалённым, конечно, предполагается координатор, но могут быть и альтернативные ветви кода в проекте, ибо несколько разработчиков могут ухватится за кусок "мяса" и запостить изменения. Т.е. в конце концов на первое место становится юзабилити кода, а не часы. И обижаться в принципе, не на кого, ибо не ты виноват, что твой код не взяли, а сообщество.
Дык вот и вопрос: как мерять?!! Строчки кода, что ли? Или кол-во символов? Начнут тогда битмэпы в константные массивы кидать, бугага... Да и не в корысти дело, в конце концов, а в справедливости, одна строка кода может быть "золотой" и коренным образом повлиять на продажи и юзабелити (ну это я так утрирую). И юзеров не заставишь "фтыкать" в код (для голосования, к примеру), ибо тесто, и не шарит в высоких материях :) И кодеры мнят только о своём, а не о чужом, и вообще, могут не разбираться в тех вещах, к которым другой руку приложил...
У кого какие идеи? Спасибо.
|
|
<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 надо умножить :-).
Есть эмпирическое правило: эстимейты, которые дают программисты в подавляющем большинстве случаев надо умножать на пи. Во всех остальных случаях надо делить на пи
|
|
|
подробно о проекте
Анализ криптографических сетевых...
