Методики разработки в условиях нехватки ресурсов.

← →
Petr V. Abramov © (2006-11-12 00:06) [40]

просто там люди до сих пор живут в 90-х, когда можно было прогрммера с опытом по цене грузчика нанять. Это лучшие годы их руководства :)
Хотя есть и трезвеющие потихоньку люди

← →
Piter © (2006-11-12 00:11) [41]

Sergey Masloff (11.11.06 22:05) [31]
Тех кто такие деньги стоит в Москве единицы и они уже работают

ты не прав, Сергей. Единицы - это те, кто достоин $4000 - $5000. И таких вакансий УЖЕ не мало.

Sergey Masloff (11.11.06 22:30) [33]
Идея создать компактное ядро вокруг которого студенты за 400 у.е будут рисовать рюшечки

не смеши людей. За $400 никто не пойдет, только если люди, которые ВООБЩЕ НИЧЕГО НЕ ПОНИМАЮТ. Вам выйдет это все дороже в результате.

Я получаю $400, бываю на работе пару раз в неделю.
О чем ты? Рынок за последний год СИЛЬНО изменился...
Судя по всему, в вашей фирме это еще не поняли. Ну тут два варианта: или таки поймут, или дождутся, когда рынок рухнет (если он рухнет). А пока спрос превышает предложение.

← →
Piter © (2006-11-12 00:14) [42]

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

← →
Dok_3D © (2006-11-12 00:22) [43]

2 Sergey Masloff (11.11.06 13:27)

Значит, о методике в условиях нехватки ресурсов, говоришь ...
Хочешь поговорить об этом ? :)

Сразу скажу, то, что ты написал, - это полнейшая чушь. Дороже выйдет.

1. "Кодеры, которые не умеют программировать" - этого не бывает. Если и бывает, то сие явление кратковременное, потому что человеку свойственно обучатся.
2. "они отдают на причесывание и проверку прежде чем это включается в проект" - это вообще нонсенс. Отдавать на причесывание ведущим высокопроизводительным девелоперам чужой код - это ОЧЕНЬ дорогое удовольствие. Очевидно, что они быстрее напишут его сами. Причем, качественнее.

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

И последнее. Самым правильным решением в условиях настоящей нехватки ресурсов - это сокращение работ по менее приоритетному функционалу.

И распоследнее. Возможно, лучше подождать, пока продуктивный программист станет доступным, чем ждать пока первый доступный программист станет продуктивным.
Это я о кадровой политике.

← →
Petr V. Abramov © (2006-11-12 00:29) [44]

> $400 никто не пойдет,
это понятно
только если люди, которые ВООБЩЕ НИЧЕГО НЕ ПОНИМАЮТ.
речь идет о:
1. ~15-20 т.р
2. большого понимания по большому счету не требуется. требуется аккуратность. при этом будут требования "владение дизайнером форм Delphi (VS Studio) в совершенстве, не путаться в синтаксисе языка, справка, что не дебил". А дальше чел либо в кадровом резерве на архитектора, либо через полгода овладевает программированием и уходит на другую зп с хорошими рекомендациями, либо (ну его проблемы) сидит всю жизнь на этой работе (работодатель рад :)

а в идеале этих же на аутсорс по 100 баксов :)

← →
Petr V. Abramov © (2006-11-12 00:30) [45]

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

← →
Eraser © (2006-11-12 00:32) [46]

Каким требованиям должен соответствовать работник, который получает (или расчитывает получать) $1000 ?

← →
Sergey Masloff (2006-11-12 00:32) [47]

Dok_3D © (12.11.06 00:22) [43]
Могу поспорить
>1. "Кодеры, которые не умеют программировать" - этого не бывает. Если и >бывает, то сие явление кратковременное, потому что человеку свойственно >обучатся.
Да я это и написал. Будет школа кадров поработал полгодика - и вперед к новым достижениям на новом месте. Как раз я и хочу попробовать наладить систему когда на включение в работу такого человека уходило бы дня три.

>2. "они отдают на причесывание и проверку прежде чем это включается в >проект" - это вообще нонсенс. Отдавать на причесывание ведущим >высокопроизводительным девелоперам чужой код
Что значит высокопроизводительным? Быстро код набивающим? Я спокойно уже несколько лет проверяю код как минимум двоих человек. Это занимает у меня 10% времени максимум. А что я быстрее напишу - это распространенное заблуждение. Все равно рутины много и интегрально не так быстро получается. Так что я быстрее напишу (а чаще не напишу а расскажу как написать) какой-то затруднительный кусочек и все. С этим-то проблем нет говорю ж - уже годами так работаю.

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

> это сокращение работ по менее приоритетному функционалу
Такого нет. Я его просто не начинаю делать ;-)

>Это я о кадровой политике.
А вот это определяем не ты и не я ;-)))

← →
Dok_3D © (2006-11-12 01:08) [48]

2 Sergey Masloff (12.11.06 00:32) [47]

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

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

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

← →
Petr V. Abramov © (2006-11-12 01:10) [49]

> Первый - заведомо более ресурсоемкий в сумме. Второй - нет.
времени - столько же. поверьте на слово. пока человек осознает, что он не прав, можно 10 раз самому написать

← →
Dok_3D © (2006-11-12 01:11) [50]

2 Sergey Masloff (12.11.06 00:32) [47]

>Это я о кадровой политике.
А вот это определяем не ты и не я ;-)))

Менеджер проекта должен уметь влиять на кадровую политику. Это одна из сфер его полномочий при разработке проекта.

← →
Dok_3D © (2006-11-12 01:15) [51]

2 Petr V. Abramov © (12.11.06 01:10) [49]

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

← →
Petr V. Abramov © (2006-11-12 01:23) [52]

> После инспекции кода человеку не нужно осознавать
теоретически - да. если смириться с громким шепотом "начальник - мудак" :)

← →
Piter © (2006-11-12 02:08) [53]

Eraser © (12.11.06 0:32) [46]
Каким требованиям должен соответствовать работник, который получает (или расчитывает получать) $1000 ?

башка на плечах должна быть. Знать, в чем здесь косяк:

procedure TForm1.On_blabla(bla: bla); begin Form1.Caption := "test"; end

знать, что такое CTRL+SHIFT+C :)

Да вообще ничего такого. Просто нормально уметь программировать. Знать среду, методы отладки, watch list, брекпоины, понимать структуру VCL, понимать почему у многих компонент есть свойство типа TStrings, хотя реально экземпляр этого класса никогда не создают. Уметь вызывать WinApi-функции (да и вообще, функции из внешних DLL). Понимать, что делает:

var s: string; begin P := PChar(s);

а что делает:

var p: pchar; begin s := p;

Знать, что написать вместо:

Labell.Enabled := false; Laber2.Enabled := false; Laber3.Enabled := false; Laber4.Enabled := false; Laber5.Enabled := false;

Плюс знание БД, хотя бы сносное знание чистого SQL.
Если еще и английский неплохо - вообще щоколад.

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

← →
Petr V. Abramov © (2006-11-12 02:18) [54]

> Уметь вызывать WinApi-функции
во-во, с этого момента про 1000 и разговаривать
> Если еще и английский неплохо
если его чел не может читать документацию - 0$ плюс его доплата за обучение англ. техническому. Ибо его незнание говорит о НЕЖЕЛАНИИ что-то понимать. А такие не нужны даже батонокидателями

← →
Ketmar © (2006-11-12 02:25) [55]

>[54] Petr V. Abramov(c) 12-Nov-2006, 02:18
>> Уметь вызывать WinApi-функции
> во-во, с этого момента про 1000 и разговаривать
"дипломированый чернокнижник вызовет любую winapi-функцию. владеет умением строить защитные пентаграммы" (ц) Нота

← →
Eraser © (2006-11-12 03:08) [56]

> [53] Piter © (12.11.06 02:08)

ну что ж.. хорошо если так ) летом скорее всего предстоит поиск работы в столице )

← →
Германн © (2006-11-12 03:18) [57]

> Ketmar © (12.11.06 02:25) [55]
>
> >[54] Petr V. Abramov(c) 12-Nov-2006, 02:18
> >> Уметь вызывать WinApi-функции
> > во-во, с этого момента про 1000 и разговаривать
> "дипломированый чернокнижник вызовет любую winapi-функцию.
> владеет умением строить защитные пентаграммы" (ц) Нота

Я бы тебя принял на работу, если б я был ДИРЕКТОРОМ!

← →
Ketmar © (2006-11-12 03:24) [58]

>[57] Германн(c) 12-Nov-2006, 03:18
>Я бы тебя принял на работу, если б я был ДИРЕКТОРОМ!
можешь не принимать. достаточно просто платить 1000 буказоидов.
%-)

← →
Германн © (2006-11-12 03:34) [59]

> Ketmar © (12.11.06 03:24) [58]
>
> >[57] Германн(c) 12-Nov-2006, 03:18
> >Я бы тебя принял на работу, если б я был ДИРЕКТОРОМ!
> можешь не принимать. достаточно просто платить 1000 буказоидов.
>
> %-)
>

Согласен. С сегодняшнего дня будешь получать 10000 фигазоидов! Но только учти - по серой схеме! :-)

← →
Ketmar © (2006-11-12 03:38) [60]

серая не катит. нужна subsilver.

← →
Германн © (2006-11-12 03:49) [61]

> Ketmar © (12.11.06 03:38) [60]
>
> серая не катит. нужна subsilver.
>

Тогда останемся друзьями. Ты мне ничем, а я тебе никогда! :-)

← →
Piter © (2006-11-12 13:02) [62]

Petr V. Abramov © (12.11.06 2:18) [54]
если его чел не может читать документацию - 0$ плюс его доплата за обучение англ. техническому

ну кое-как понимать MSDN - надо, конечно. Но это частично входит в понятие уметь вызывать WinApi :)

А я говорил "Если еще и английский неплохо" - это значит уметь говорить, а если еще и писать грамотно - вообще здорово, во многих фирмах сильно ценится.

← →
Sergey Masloff (2006-11-12 13:09) [63]

Piter © (12.11.06 13:02) [62]
>во многих фирмах сильно ценится.
Ага. У меня дама одна знакомая есть когда устраивалась на работу так на английский напирали она в принципе очень даже неплохо владеет и то нелегко было. Ну проработала там года два с половиной потом ушла. Я в разговоре обмолвился - говорю ну как английский-то пригодился? Она ответила что за все время работы не произнесла и не написала ни одной фразы на английском ;-)

← →
Ketmar © (2006-11-12 13:10) [64]

>[63] Sergey Masloff 12-Nov-2006, 13:09
>говорю ну как английский-то пригодился?
что-то напомнило: "знаю английский в объёме кобола" (ц)...

← →
Piter © (2006-11-12 13:37) [65]

Sergey Masloff (12.11.06 13:09) [63]

возможно. А разве про это речь?

Факт в том, что за доп. знание английского фирмы платят доп. деньги (неплохие). А нужна ли эта доп. оплата или фирма фигней страдает - это проблемы фирмы, верно? :)

← →
Sergey Masloff (2006-11-12 13:42) [66]

Piter © (12.11.06 13:37) [65]
Да не про это просто вспомнилось к слову.

← →
Piter © (2006-11-12 13:56) [67]

Да и вообще английский рулит. Я вот хочу как-нибудь по Европе попутешествовать, нужно английский учить :(

← →
Petr V. Abramov © (2006-11-12 14:05) [68]

> Piter © (12.11.06 13:56) [67]
возьми симпатичную переводчицу :)

>[68] Petr V. Abramov(c) 12-Nov-2006, 14:05
>возьми симпатичную переводчицу :)
и нафига тогда та европа?

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

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

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

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

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

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

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

Petr V. Abramov © (12.11.06 14:05) [68]
возьми симпатичную переводчицу :)

это, конечно, враиант. Но хочется и самому понимать :)

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

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

Petr V. Abramov © (12.11.06 18:28) [72]
тогда английского мало будет. придется учить все, включая албанский :)

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

Petr V. Abramov © (12.11.06 18:28) [73]
может, сей важный вопрос в отдельную ветку? :)

да а смысл? Ты не продолжай тему и все :)

> у которых в загранке 150 печатей - английского вполне достаточно.
чтоб спросить дорогу в аэропорт. а чтоб понять, что кругом говорят - не верю. Либо знакомые 150 раз ездили на англоязычные переговоры
> да а смысл? Ты не продолжай тему и все :)
тогда ветка тонет :)

Petr V. Abramov © (13.11.06 0:36) [75]

ну а зачем тебе знать, что именно вокруг говорят?

Я имел в виду, когда говорят как бы тебе, а ты не понимаешь. А если ты мимоходом шел и услышал незнакомое слово - да и фиг с ним.

И никакие не переговоры, просто они часто выбираются в Европу (4-5 раз в год) на всякие спортивные состязания.

Если уметь - вполне достаточно $300-$400 чтобы 2 недели кататься по европе.

> Я имел в виду, когда говорят как бы тебе, а ты не понимаешь.
а вот тут и переводчица самое оно. переводит: "этот пэр обозвал Вас козлом, потому его грязная нога была там, куда Вы наступили"
> на всякие спортивные состязания.
ну там понятно, трех слов хватит. "лыжи" и мата :)

Petr V. Abramov © (13.11.06 1:38) [77]

спортивный матч это считай повод. Там еще культурная программа на неделю, две :)

← →
Sergey Masloff (2006-11-21 20:43) [79]

Вобщем возвращаясь к теме. Ничего не получается, на контроль уходит действительно намного больше времени. Сегодня над одним модулем сидел с полдевятого утра до семи вечера. Пока процентов на 40 переработал. Год назад составил список типичных примеров явно плохого кода (которые я при подготовке к переходу на D7 вычистил) и разослал всем разработчикам. Потом я от дельфийских проектов далек был некоторое время сейчас опять вернулся - ну все по старому. Неинициированные локальные переменные, неправильное применение try...finally и try...except ну и все-все-все. Ну и для кого писал - х.з.

Sergey Masloff (21.11.06 20:43) [79]
Неинициированные локальные переменные

так ведь об этом комилятор предупреждает?!

Sergey Masloff (21.11.06 20:43) [79]
неправильное применение try...finally и try...except

можно пример?

Методики разработки в условиях нехватки ресурсов. Найти похожие ветки