Ну вот и началось приблежение к реальности...

> Проект как правило не точный,

Это, простите, как? Клиент не знает чего он хочет? Разработайте и
предложите.


> требования заказчиков изменяются уже в момент реализации.

Суешь им контракт под нос, где данный пункт оговорен отдельно и
переделываешь проект.


> Кодеры лажают и плодят ошибки.

Каждому модюлю соответствует набор тестов, подготовленный постановщиком.
Ошибка модуля прошедшего все тесты — ошибка постановщика. Ошибка модуля
не прошедшего тест — ошибка кодера. Лишите зарплаты + неустойки в
соответствии с контрактом (его иногда еще называют трудовым договором) и
такое положение дел быстро прекратиться.


> Заказчики требуют завершать этапы раньше срока (чтобы им отчитаться).

Согласно ТЗ.


> Людей не хватает.

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


> Тестирование поверхностное.

Все этапы тестирования проходят согласно проектной документации.


> Сроки затягиваются.

Оговорено в контракте с клиентом — платишь неустойку...


> Тестовых примеров — не сформулировано.

То же самое, что "поверхностное тестирование".


> Этап приема проекта не оговорен.

Ошибка менеджера. (см. выше)


> Кадры заказчика не обучены...

Согласно контракта.


> Продолжать можно много.

Консультация у юриста стоит 300 руб в час. Квалификации подобного юриста
хватит, чтобы в течении 2-4 часов оговорить все детали всех договоров.


> Литература, корорая попадалась мне на глаза была двух типов:

Edward Yourdon. "Death March". The Complete Software Developer's Guide
to Surviving "Mission Impossible" Projects
Prentice Hall, 1997, ISBN 0-13-748310-4

Эдвард Йордан. "Смертельный марш". Полное руководство для разработчика
программного обеспечения по выживанию в безнадежных проектах
Перевод с англ. А.М. Вендрова

(180Kb RAR) Мне в свое время ее оказалось достаточно.


> 2. Описывается идеализированный подход к созданию систем. Учебники по
менеджменту, пособия по планированию и.т.д. Вот только 80% факторов,
влияющих на проект там не рассматривались...

По причине их отсутствия.


> Короче, ты вообще работал где нибудь?

А сюда просто так на огонек заглядывают?

> AB>Проект должен соответствовать
> AB>СТАНДАРТИЗИРОВАННОЙ документации, чтобы подправить его мог любой
> AB>человек, знакомый с языком и общими принципами работы этого
проекта
> AB>(которые он может узнать из документации).
> Другими словами проект должен быть очень маленьким и простым.

Критерии "маленького и простого"?
Вы видели когда-нибудь настоящую проектную документацию?


> AB>И жаль, что не выгнали его раньше...
> Точно жаль, и что он делал в такой отстойной конторе, непонятно.

Ну вот, может нашел место по своему вкусу.


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

А надо браться с самого начала, а дальше или играть в смертельный марш и
не жаловаться, или делать свою работу.


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

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

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

Нет, бываю и кодером и "засланцем за пивом"... Если я могу что-то
сделать, для выполнения проекта — я не брезгую и за пивом сходить и
винды настроить. Хотя не совсем понял, чем вас обидело сравнение. Был
бы я сантехником — меня бы обидела ваша фраза — "все профессии важны". А
про конвеер — я вообще не понял. Чем плохи вещи с конвеера? ФОРД, ИМХО,
никогда не славился плохим качеством (хотя в авто я не сильно
разбираюсь).

> >> AB>линейку от Радио-86РК до P-VI на различных языках включая С++???
> >> Ух ты, уже и до P-VI дошел?
> AB>А расшифровать?
> Pentium-6 — это наверное, круто

А... банальная очепятка... Никогда не видел программку "Соло на
клавиатуре"? Забавная такая... Попробуй пройти заданий 50-70... После
этого мир видится через другие очки ) Серьезно!!! Всем рекомендую!!!

Сэи прав — иногда надо заткнуться и просто делать дело, а не вставать в позу "все тупые кроме я".

С>>И авторы инструкций и ТЗ доросли и заслужили делать это (неважно, хорошая она или плохая). И судить его могут только равные и выше стоящие.

А>Ни фига они никуда не доросли. И маразм я буду называть маразмом, от кого бы он не исходил.
А>А твой подход вообще напоминает тоталитарное сектанство. Ты из секты какой-нибудь?

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

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

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

IT>>>По твоим словам получается что C++ без STL — это не C++

A>>Угу. STL это одно из самых сильных преимуществ языка.

grs>С тем, что STL — одно из ключевых приемуществ С++ не спорю, но извини, если ты считаешь, что C++ без STL — это не C++, то ты просто не вполне представляешь себе, что такое С++.

Я то представляю. Давай скажем так рассуждать математически. Есть некий X (множество) и в этом X есть подмножество Y. Ты же не станешь утверждать что X-Y=X при непустом множестве Y? А если множество Y еще и значительное.

A>>Да блин не собираюсь, я никого ни в чем уличать. Мне просто не понятно чем человек занимался свои 12 лет суммарного опыта. И стоит ли его брать если студенты больше знают.

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

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

grs>От нас уходил парень в MS году в 2000. Программистом на С++ уходил. Работает там кстати до сих пор. Так ему на их собеседовании не задали НИ ОДНОГО вопроса по технологиям и продуктам MS. НИ СЛОВА не было о Visual C++. А знаешь почему? Потому что у рекрутеров MS задача была подобрать нужного человека, а не показать свою крутизну. Чем они выгодно и отличаются от большинства наших рекрутеров.

А какие ему вопросы задавали? Ты знаешь рекомендация писать код на собеседовании принадлежит товарищу Joel-у(см Test Joel). Который как раз в MS этого нахватался. Это как раз помогает от людей защищаться которые умеют хорошо разговариать, а делать не умеют.

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

AB>Чем плохи вещи с конвеера? ФОРД, ИМХО,
AB>никогда не славился плохим качеством (хотя в авто я не сильно
AB>разбираюсь).

Есть проектирование. А есть конструирование.
Проектированием Форда занимаются не на коквейере, а в КБ высокооплачиваемые профессионалы.
Проектирование -- творческий, нерегламентированный до конца процесс.

Распросранено ошибочное мнение, что в программировании кодирование -- это конструирование.
На самом деле конструирование в программировании сводится к работе компилятора и
выполняется без участия человека.
Все остальное -- это проектирование. Файл исходного кода -- это проект, который компилятор
конструирует в исполняемый файл.
Если в других областях деятельности на проектирование тратися 10% времени и ресурсов, то в
программировании на проетирование тратится 90%.

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

NF>Сэи прав — иногда надо заткнуться и просто делать дело, а не вставать в позу "все тупые кроме я".

Сэма сам стоит в этой позе.

По его ответам напрашивается вывод, что он сам вообще не занимался программированием.

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

>> Вообщем, не согласен я что все люди способны работать в равной степени
AB>или
>> близко к ней, разница обычно на порядок, а то и просто качественная -
AB>не
>> больше не меньше, а либо может выполнить задание либо не может.

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

И вы одновременно удтвержаете, что

AB>По этому, в области ИТ — все же главное — машины... А людей можно и других AB>нанять — незаменимых не бывает...

Мало того что гениев мало и их надо еще найти, они еще и разные один в одном другой в другом.

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

Найти, мотивировать, организовать взаимодействие — ключевые моменты менеджмента в ИТ. А вот машины действительно легко можно купить и другие.

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

A>>Блин не говори. В Екатеринбурге уже почти 3 месяца уже ищем вменяемого плюсового программиста. Приходят люди, всем за 30 лет. В резюме опыт работы с C++ под 10 лет у всех. STL не знает никто, до сих пор еще не услышал правильного ответа как посортировать массив. И даже когда пишешь решение народ не может объяснить как это работать может.

A>>Ну ладно блин студенты были бы, дак ведь здоровенные дяденьки на 8-10 лет меня старше.

M>Ну и как, нашли? Может, я подойду?

Я тебе написал письмо на rsdn@asp.ur.ru

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

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

J>Насчет того что судить их могут равные — я согласен, конституцией декларировано что все равны. Чем они равнее меня?
J>А насчет "заслужить делать это" вообще комедь — тетка на рынке тебя обвесила (неважно, хорошая она или плохая), и что ты будешь заслуживать возможность сказать ей что она в конец оборзела?

J>Не думал я такие настроения среди программеров найти... Ты на чем и под что вообще пишешь?

J>Игорь

Здравствуйте, Аноним, Вы писали:

А>>Попросите помошь и она будет. Многие не просят.

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

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

Мораль: очень важно, в какой момент человек просит помощи.
Если он сразу подходит спросить то, что он мог бы выяснить самостоятельно и продолжает это делать — в сад. Я не визард вести его за ручку через весь процесс разработки.
Если он не делает этого никогда и продолжает биться лбом о стену там, где ему не хватает информации — в сад. Я не могу бегать за каждым и следить, не встрял ли он во что-то. И компания не готова платить за 40 часов борьбы с проблемой, которой нет.
А вот если он собрал всю информацию, убедился, что ему нужно задать конкретный набор вопросов, вовремя их задал и продолжил работу — вот тогда он молодец. Разумный баланс, естественно, дотигается не сразу. Но крайние случаи — в сад однозначно.

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

Спасибо.

http://www.rsdn.ru/Forum/Message.aspx?mid=285074&only=1

Автор:
Дата: 03.06.03

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

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

N>>Брейбенч, боейбенч... дайте ссылку

B>http://brainbench.com
B>Но ты опоздал. Теперь он хорошоооо платный.

75$ за три месяца — хоть обздавайся. Я без всякого читерства: первый раз 4.53, через 3 минуты — 4.6, пятнадцать минут передохнул — 4.66. Top List for Russia

P.S. Типа похвастался

Здравствуйте, <Аноним>, Вы писали:

А>Здравствуйте, Night Flier, Вы писали:

NF>>Если брали личного шофёра, то правильно сделали, что не взяли.

А>Не-а, не правильно. Шофер водить должен. Колесо заменить он еще может. А такую фигню пусть
А>специалисты чинят.

Водитель — это тот, кто только водит.
Шофер — это водитель + тот, кто чинит.

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

AB>Ну вот и началось приблежение к реальности...

>> Проект как правило не точный,

AB>Это, простите, как? Клиент не знает чего он хочет? Разработайте и
AB>предложите.

Он имеет общее понятие — чтобы бизнес был автоматизирован, стал проще.

AB>
>> требования заказчиков изменяются уже в момент реализации.

AB>Суешь им контракт под нос, где данный пункт оговорен отдельно и
AB>переделываешь проект.

Так ты контракт не получишь. Они такой просто не подпишут.

AB>
>> Кодеры лажают и плодят ошибки.

AB>Каждому модюлю соответствует набор тестов, подготовленный постановщиком.
AB>Ошибка модуля прошедшего все тесты — ошибка постановщика. Ошибка модуля
AB>не прошедшего тест — ошибка кодера. Лишите зарплаты + неустойки в
AB>соответствии с контрактом (его иногда еще называют трудовым договором) и
AB>такое положение дел быстро прекратиться.

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

AB>Объявление "Приму на работу", кадровые агенства... Людей не может не
AB>хватать (если офис, конечно не находится посреди тайги). Вот ограниченый
AB>бюджет, при котором нанять новых людей проблема — это да... Но это
AB>ошибка менеджера (см через пункт выше).

Найти стоящего программиста — большая проблема.

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

>> А если система тормозит на самом быстром железе, доступном в данный
>> момент? Если взять большую кучу кодировщиков, которые механически
>> решают свои задачи — такую систему можно оччень даже просто получить.
>> Свою задачу система может быть и решает. Только что дальше то?

AB>И
AB>вообще, что входит в понятие "тормозит"? У меня вот Win98 на Athlon XP
AB>2000+ тормозит при загрузке — загружается 7 секунд...

Ставь DOS — как раз для нее Athlon и проектировался

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


J>Литература, корорая попадалась мне на глаза была двух типов:
J>1. Описывается реальный опыт создания систем. Байки программеров, Брукс (Мифический человеко-месяц), Йордан (Марш камикадзе), Якобсон, Буч и Румбах...
J>2. Описывается идеализированный подход к созданию систем. Учебники по менеджменту, пособия по планированию и.т.д. Вот только 80% факторов, влияющих на проект там не рассматривались...

Идеализированный подход, как ты его называешь, может быть просто не применим в текущей ситуации по причине отсутствия проектов подобного уровня.
Как пример — http://www.bolero.ru/index.php?level=4&amp;pid=2491022
Хорошая книга. Для автоматизаторов атомных станций. В таких проектах факторы совсем другие.

Павел

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

AB>Вы видели когда-нибудь настоящую проектную документацию?

Я видел и сам такую писал, пишу и буду писать
Если кто-то не делает, это не означает, что не делает никто.

Павел

NF>К вопросу об эффективности — недавно меня поучали, что нехорошо объявлять переменные в цикле — типа как же так, неэффективно! А "эффективно" — это когда функция на 300 строк и 20 переменных объявляется в начале, a la Pascal (и ещё несколько таких копи-пастом).

Как всегда, нужно решать баланс между удобством для программиста и скоростью в работе. За все надо платить.

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

Только вот временами "переделать так, чтобы не тормозила" — это значит "стереть исходники из VCS и написать всё заново".