AB>5 лет обучения по специальности 220200 (автоматизированные системы AB>обработки информации и управления) и после этого "творчество" AB>переименовывается в штатные методы (которые уже давно изобретены).
Вопрос всего лишь в том, чтобы правильно применить правильные для данной задачи методы. Из одних и тех же компонентов можно приготовить как рагу по французски, так и пойло для бомжей.
Кстати, тут почему-то никто не задавался вопросом "а кто такой гений", хотя многие склоняют это слово налево и направо Одно из определений — "человек, который находит связи между вещами, которые, как кажется большинству, не имеют никакого отношения друг к другу."
AB>что касается проектирования — есть стандартные операции и стадии AB>проектирования. Если ты считаешь, что придумал что-то новое — я буду AB>ждать момента, чтобы ознакомиться с этим и взять твой автограф на твоей AB>книге (это не издевка — я серьезно).
проектирование по стандарту — где-то здесь я в другой ответ тебе запостил ссылку на статью, там про это очень хорошо написано. Согласен практически с каждым словом
А что касается автографа, поживем — увидим )
Здравствуйте, joker6413, Вы писали...
С теткой на базаре несколько другие отношения. Т-Д-Т. Это несколько не в тему попал.
Конституция тоже хорошо так. По пионерски.
В настоящий момент пишу на SQL под Oracle + dbasic(Documentum) + VB6, хотя не обязан, т.к. занимаюсь внедрением программы. Но часто. Это у нас процесс внедрения такой... Так вот, когда необходимо систему подправить под нужды клиента уже на месте, в процессе я очень ласковыми, теплыми и добрыми словами гениев от программирования на вроде тебя, которые писали не по ТЗ, а как лучше им показалось...
Работа программиста в одиночку — искуство.
Работа в команде — заткнись и копай! В перерыв подойди и уточни направление копки!
В авральном режиме разбирать каракули гения самоучки или залезть в ТЗ? что проще?
Устал я от бестолковой гениальности и гениальной бестолковости.
> AB>Я полностью согласен и обратного не утверждал. Должен быть > AB>постановщик(и), взявший на себя все бремя алгоритмики и иже с ней. > AB>Должен быть кодер(ы), взявший на себя бремя (хочу заметить не самое > AB>легкое) кодировать все это и делать это "согласно написаному" и > AB>менеджер(ы), которые всем этим и заправляют по определению. > И вы одновременно удтвержаете, что > AB>По этому, в области ИТ — все же главное — машины... А людей можно и
других > AB>нанять — незаменимых не бывает...
Проект обычно работает дольше, чем его создают... Именно это я
подразумевал, говоря так.
> Мало того что гениев мало и их надо еще найти, > они еще и разные один в одном другой в другом.
Упаси боже их найти...
> Человек это главная ценность ИТ, если вы подобрали хорошие кадры > то сметете горы,
Полностью согласен.
> если выборка была средней — один гений и много > обычных, то и результаты будут средненькие,
Скорее всего на одного человека в команде станет меньше... Ну а на счет
результатов — это верено — придется начинать все сначала... или почти
сначала, потеряв уйму времени/сил/нервов, для того, чтобы
проанализировать и понять, почему проект "покатился" в какую-то другую
сторону от плана и вернуть его в нормальное русло.
> если выборка будет с отсеиванием гениев — результат > будет значительно ниже среднего.
В результате такого отсева, получится некая "однородная масса" (уж
простите за термин, тут он используется со знаком '+'). Которая легко
управляется, легко ладит друг с другом, друг-друга поддержит, поможет и
"прикроет", если что... Это "человеческие" качества, но тем не менее...
Подобный "коллективный разум" (опять со знаком '+') способен
проработать, как четко-отлаженный механизм долгие годы... итд итп.
Что касается результативности подобной работы — последовательность,
четкость и слаженность (а именно так должен работать этот "механизм" под
чутким управлением менеджера), ИМХО, залог общего успеха.
Гении — это одиночки. Потому что, много знают, много умеют, по этому в
большинстве случаев торопятся "впереди планеты всей", нервничают, когда
их отвлекают с "глупыми" (по их мнению) вопросами, пытаются что-то
улучшить (основываясь на собственный субъективно-объективный взгляд),
чаще всего небрежны в исходном коде и "внешнем виде" того, что они
пишут... В общем, не способствуют работе над проектом в целом — хотя сам
по себе проект может быть и будет завершен, дальнейшее его сопровождение
будет проблемным (здесь функция какая-то дополнительная, там вдруг
откуда-то параметр взялся по умолчанию, в третьем месте структура не
выровнена по нужной границе и т.д.). Но его такие "мелочи" не беспокоят,
потому что у него "все работает — ищите у себя ошибки"...
Вообще, посмотрев реакцию окружающих я придумал себе развлечение на
будущее: собрать 2-3х гениев вместе в пределах вдимости и заставить их
работать над одной задачей (разработать от начала и до конца небольшой
проектик на 3-5 месяцев, желательно с общими, ими же написаными,
исходниками). Знаете, забавно наблюдать за битвами "титанов"... А еще
забавней наблюдать, когда в финальном релизе начинаются AV, беспорядочно
скачущий по контролам фокус, потеря формой модальности и т.д.... "Но
ведь работает же!".
Конечно! Может, даже быстрее и памяти меньше использует... Но вот только
как клиенту объяснить, что для вызова нужной ему функции программы надо
прописать в реестрике HEX ключик, после чего нажать средней кнопкой мыши
по во-о-о-н той фигне с остаточной надписью "Static" (Label1, Edit и
т.д.) и подождать пока уберется переливающееся всеми цветами радуги
окошко с копирайтом Васи Пупкина и иконкой черепушки? А добавить новую
функцию в этот модуль мы не можем, потому что только Вася Пупкин сможет
в нем разобраться за то время, которое вы хотите... Да и то, только
после канистры пива... А он, понимаете ли, подался на вольные хлеба, и
сменил религию, которая, по его словам, ему теперь не позволяет писать
программы для "клиентов-ламеров"... (могу продолжить дальше, но смысл
ясен).
Пример про объяснения клиенту, конечно, утрирован, но точно отражает
суть гениев и последствий их работы.
> Найти, мотивировать, организовать взаимодействие — ключевые моменты > менеджмента в ИТ.
Совершенно верно!!! Так вот, этот менеджмент, про который я пытаюсь
рассказать, именно _находит_ то и тех, что дает максимальную отдачу при
минимальных затратах и _организовывает_!!! В итоге — все довольны.
> А вот машины действительно легко можно купить и другие.
Когда речь идет, например, о HP-шном серваке за N тысяч USD, или об
определенном типе какого-либо другого (возможно, что и специального)
оборудования, в то время, когда система разрабатывалась именно для
работы на _этом_ оборудовании, то клиенту, мягко говоря, не нравится
что-либо покупать еще...
З.Ы. И на последок анекдот в тему, чтобы улучшить ваше мрачное
настроение:
"Тунеядцы!!! Бездельники!!! Всех уволю!!!" — кричал начальник, все
боялись и дрожали... И только один программист ехидно улыбался...
З.Ы.Ы. Так вот, я не хочу быть ни на месте программиста ни на месте
начальника...
сообщил/сообщила в новостях следующее: news:287918@news.rsdn.ru... > Здравствуйте, Anton Batenev, Вы писали: > > AB>Чем плохи вещи с конвеера? ФОРД, ИМХО, > AB>никогда не славился плохим качеством (хотя в авто я не сильно > AB>разбираюсь). > > Есть проектирование. А есть конструирование. > Проектированием Форда занимаются не на коквейере, а в КБ
высокооплачиваемые профессионалы. > Проектирование -- творческий, нерегламентированный до конца процесс.
Не в тему. Речь была, если вы помните, о разнице в часах сошедших с
конвейера и ручной сборки а не о этапе их конструирования.
Что же касается проектирования автомобиля Форд — я так же считаю дизайн
автомобилей творческим и не регламентированным до конца процессом и,
даже в какой-то мере искусством. Что же касается их технических
показателей — тут все регламентировано — аэродинамика, физика, химия,
сопротивление материалов и т.д. и т.п. Вне всякого сомнения в КБ Форда
работают первоклассные инженеры и производимые ими рассчеты могут быть
неподвластны студенту Мех/Физ/ХимМата, но это еще не значит, что они там
занимаются творчеством. Иначе бы они давно отменили нютоновскую
динамику, силы трения и еще бог знает чего...
A>> Мало того что гениев мало и их надо еще найти, A>> они еще и разные один в одном другой в другом.
AB>Гении — это одиночки.... В общем, не способствуют работе над проектом в целом — хотя сам AB>по себе проект может быть и будет завершен, дальнейшее его сопровождение AB>будет проблемным ... Но его такие "мелочи" не беспокоят, AB>потому что у него "все работает — ищите у себя ошибки"... AB>...(могу продолжить дальше, но смыслясен).
У нас разные определения гениев), отсюда и весь спор. То что ты описываешь как гений, для меня не иначе как ламер крутиков — гнать таких в шею или держать но в черном теле.
>> если выборка будет с отсеиванием гениев — результат >> будет значительно ниже среднего.
AB>В результате такого отсева, получится некая "однородная масса" (уж AB>простите за термин, тут он используется со знаком '+'). Которая легко AB>управляется, легко ладит друг с другом, друг-друга поддержит, поможет и AB>"прикроет", если что... Это "человеческие" качества, но тем не менее... AB>Подобный "коллективный разум" (опять со знаком '+') способен AB>проработать, как четко-отлаженный механизм долгие годы... итд итп.
AB>Что касается результативности подобной работы — последовательность, AB>четкость и слаженность (а именно так должен работать этот "механизм" под AB>чутким управлением менеджера), ИМХО, залог общего успеха.
Нужна последовательность, механизм, слаженность — а кто все это будет делать на нужном уровне работоспособности и квалификации? Если речь идет о том что все вместе, а также каждый по отдельности и в паре с любым другим — то в моем понимании это и есть схема когда весь коллектив состоит из гениев. Если это возлагается на одного тим лидера то это будет схема с одним гением и кучкой обычных программистов. Абстракции конечно, но вы меня поняли. Ну а если никому не будет дела или не будет хватать таланта все это поддерживать то эта однородная масса негениев с результатами значительно ниже среднего.
Собственно спор, если он был, в том что я уверен что такой человек по определению требует уважения к себе и к своему труду. Пример что ты приводил это крайность ламера-белоручки, а в нормальной степени это просто необходимое качество. И вот не станет он работать в фирме с корпоративным отношением к нему как к малоквалифицрованному персоналу, со средним или ниже среднего приоритетом финансового, интелектуального внимания к стоящим перед ним проблемам и сложностям. И методы отбора персонала в которых заведомо это отношение проявляется — сама процедура приглашения на работу, явно издевательские тестовые задания, собеседования с не квалифицированными людьми и т.п. они таких людей от фирмы отсеят.
AB>Гении — это одиночки. Потому что, много знают, много умеют, по этому в AB>большинстве случаев торопятся "впереди планеты всей", нервничают, когда AB>их отвлекают с "глупыми" (по их мнению) вопросами, пытаются что-то AB>улучшить (основываясь на собственный субъективно-объективный взгляд), AB>чаще всего небрежны в исходном коде и "внешнем виде" того, что они AB>пишут... В общем, не способствуют работе над проектом в целом — хотя сам AB>по себе проект может быть и будет завершен, дальнейшее его сопровождение AB>будет проблемным (здесь функция какая-то дополнительная, там вдруг AB>откуда-то параметр взялся по умолчанию, в третьем месте структура не AB>выровнена по нужной границе и т.д.). Но его такие "мелочи" не беспокоят, AB>потому что у него "все работает — ищите у себя ошибки"...
Бывают и гении-профессионалы, которые действительно улучшают проект, генерят и реализуют реально работающие идеи, помогают и учат других. То, что вы описали, больше соответствует портрету хакера,
а не профессионала.
AB>Ну на счет чернорабочего ты конечно придумал — я бы себя так любимого ни AB>за что не назвал, но, что касается именно кодирования — уже придумано, AB>что касается проектирования — есть стандартные операции и стадии AB>проектирования. Если ты считаешь, что придумал что-то новое — я буду AB>ждать момента, чтобы ознакомиться с этим и взять твой автограф на твоей AB>книге (это не издевка — я серьезно).
Интересно, а каковы стандартные операции и стадии проектирование в случае разработки
нового CASE средства, подразумевающего использования новых, ранее не существоваших подходов и стадий проектирования
Здравствуйте, Anton Batenev, Вы писали:
AB>Ну вот и началось приблежение к реальности...
>> Проект как правило не точный,
AB>Это, простите, как? Клиент не знает чего он хочет? AB>Разработайте и предложите.
Так все веремя и бывает... Но проектная документация в результате написана тобой, а не заказчиком, и реализовывать ты начинаешь свой проект по мотивам заказчика.
Скажешь плохой проект они не подпишут? Конечно подпишут, они же в нем нифига не понимают, иначе сами бы сделали...
>> требования заказчиков изменяются уже в момент реализации.
AB>Суешь им контракт под нос, где данный пункт оговорен отдельно и AB>переделываешь проект.
Тебе говорят — дополнительных денег нет и не будет, на контракт они класть хотели т.к. по моим наблюдениям затягивать с оплатой заказчики могут неограничено. Плюс к тебе и твоей коноре сразу теряют интерес и ни одного заказа, я не говорю о поддержке ты от них не получишь. Тебя не будут рекомендовать другим потенциальным заказчикам, плюс будут отговаривать всех своих знакомых вести с тобой дела.
>> Кодеры лажают и плодят ошибки.
AB>Каждому модюлю соответствует набор тестов, подготовленный постановщиком. AB>Ошибка модуля прошедшего все тесты — ошибка постановщика. Ошибка модуля AB>не прошедшего тест — ошибка кодера. Лишите зарплаты + неустойки в AB>соответствии с контрактом (его иногда еще называют трудовым договором) и AB>такое положение дел быстро прекратиться.
И на следующий день ты остаешься в гордом одиночестве, а такое положение дел не прекратится т.к. возникновение ошибок — неразрывно связано с процессом разрабоки. Кстати в этом плане каждый сам себе пример, ошибки есть у всех!
>> Заказчики требуют завершать этапы раньше срока (чтобы им отчитаться).
AB>Согласно ТЗ.
См. результат сувания под нос проекта.
>> Людей не хватает.
AB>Объявление "Приму на работу", кадровые агенства... Людей не может не AB>хватать (если офис, конечно не находится посреди тайги). Вот ограниченый AB>бюджет, при котором нанять новых людей проблема — это да... Но это AB>ошибка менеджера (см через пункт выше).
А работать когда? Кто с людьми будет общаться, кто их будет тестировать? Или отдельного человека нанимать, это сразу доп. деньги?
>> Тестирование поверхностное.
AB>Все этапы тестирования проходят согласно проектной документации.
Проект изменяется даже без участия заказчика. Чтобы поддерживать проектную документацию тебе нужны доп. люди, которые к тому же ДОЛЖНЫ дергать программеров, чтобы вносить добавления и изменения в проект. Доп. деньги + время программеров расходуется впустую. Сами программеры серьзно документацию обновлять не будут — много работы, тут тоже каждый сам себе пример.
>> Сроки затягиваются.
AB>Оговорено в контракте с клиентом — платишь неустойку...
Вот тут как раз можно договориться, если ты не развлекался суванием контрактов под нос и подобными способами.
>> Тестовых примеров — не сформулировано. AB>То же самое, что "поверхностное тестирование".
Проект писал ты сам, помнишь? Бизнес тесты которые придумал ТЫ, не обязательно совпадают с РЕАЛЬНЫМИ бизнес тестами проекта. А в бизнесе заказчика ты досконально не разберешься, не хватит времени.
>> Этап приема проекта не оговорен.
AB>Ошибка менеджера. (см. выше)
Ты не можешь детально описать процедуру приема, во время выполнения проекта вы с заказчиком шли на взаимные уступки, так что на этом этапе будет полно сюрпризов...
>> Кадры заказчика не обучены...
AB>Согласно контракта.
Заказчик ведет свой бизнес как считает нужным он, а не ты. Что ты напишешь в контракте по поводу кадров заказчика? У него работают те кто нуже ему... Не думаю чтобы заказчик стал нанимать людей потому что тебе этого хочется...
>> Продолжать можно много.
AB>Консультация у юриста стоит 300 руб в час. Квалификации подобного юриста AB>хватит, чтобы в течении 2-4 часов оговорить все детали всех договоров.
Отлично, ты все юридически правильно описал, от всего застраховался... Но это все зря, т.к. такой контракт заказчик не подпишет. Он ничего не понимимает в IT, все что ты там написал про отладку, про тестирование — для него филькина грамота. Что ему нанимать человека, чтобы он все это растолковал? Тратить время и силы непонятно на что (другие IT конторы так клиентов не мучают)?
>> Литература, корорая попадалась мне на глаза была двух типов:
AB>Edward Yourdon. "Death March". The Complete Software Developer's Guide AB>to Surviving "Mission Impossible" Projects AB>Prentice Hall, 1997, ISBN 0-13-748310-4
AB>Эдвард Йордан. "Смертельный марш". Полное руководство для разработчика AB>программного обеспечения по выживанию в безнадежных проектах AB>Перевод с англ. А.М. Вендрова
AB>(180Kb RAR) Мне в свое время ее оказалось достаточно.
>> 2. Описывается идеализированный подход к созданию систем. Учебники по AB>менеджменту, пособия по планированию и.т.д. Вот только 80% факторов, AB>влияющих на проект там не рассматривались...
AB>По причине их отсутствия.
Учебников? Ну так в книжном магазине спроси, сейчас их много.
>> Короче, ты вообще работал где нибудь?
AB>А сюда просто так на огонек заглядывают?
Конечно, студенты код просят на курсовик, ну и так понтуются....
[]
AB>Вообще, посмотрев реакцию окружающих я придумал себе развлечение на AB>будущее: собрать 2-3х гениев вместе в пределах вдимости и заставить их AB>работать над одной задачей (разработать от начала и до конца небольшой AB>проектик на 3-5 месяцев, желательно с общими, ими же написаными, AB>исходниками). Знаете, забавно наблюдать за битвами "титанов"... А еще AB>забавней наблюдать, когда в финальном релизе начинаются AV, беспорядочно AB>скачущий по контролам фокус, потеря формой модальности и т.д.... "Но AB>ведь работает же!".
Забавно наблюдать, как Вы, придумав себе "развлечение на будущее",
говорите в далнейшем об этом как о свершившемся факте.
AB>Конечно! Может, даже быстрее и памяти меньше использует... Но вот только AB>как клиенту объяснить, что для вызова нужной ему функции программы надо AB>прописать в реестрике HEX ключик, после чего нажать средней кнопкой мыши AB>по во-о-о-н той фигне с остаточной надписью "Static" (Label1, Edit и AB>т.д.) и подождать пока уберется переливающееся всеми цветами радуги AB>окошко с копирайтом Васи Пупкина и иконкой черепушки? А добавить новую AB>функцию в этот модуль мы не можем, потому что только Вася Пупкин сможет AB>в нем разобраться за то время, которое вы хотите... Да и то, только AB>после канистры пива... А он, понимаете ли, подался на вольные хлеба, и AB>сменил религию, которая, по его словам, ему теперь не позволяет писать AB>программы для "клиентов-ламеров"... (могу продолжить дальше, но смысл AB>ясен).
AB>Пример про объяснения клиенту, конечно, утрирован, но точно отражает AB>суть гениев и последствий их работы.
Или Вам какие-то не правильные гении попадались, или Вы их готовить не умеете.
То что Вы написали выше больше подходит под описание малолетнего с00L xAkeR.
Очень много мыслий, свидетельствующих о полном бардаке с тех процессом.
Начните наводить порядок с себя, а потом посмотрите на улучшение мнения заказчика о вашей же работе.
J>Здравствуйте, Anton Batenev, Вы писали:
AB>>Ну вот и началось приблежение к реальности...
>>> Проект как правило не точный,
AB>>Это, простите, как? Клиент не знает чего он хочет? AB>>Разработайте и предложите.
J>Так все веремя и бывает... Но проектная документация в результате написана тобой, а не заказчиком, и реализовывать ты начинаешь свой проект по мотивам заказчика.
Замечания:
— Проектная документация пишется тобой, а не заказчиком.
— Заказчик, соместно с тобой, пишет ТЗ (которое, конечно, может оказаться хреновым и неотражающим реалии заказчика, но это уже твоя вина).
J>Скажешь плохой проект они не подпишут? Конечно подпишут, они же в нем нифига не понимают, иначе сами бы сделали...
Верно замечено. Поэтому ты со своей стороны должен подходить с повышенной ответственностью к разработке ТЗ.
>>> требования заказчиков изменяются уже в момент реализации.
AB>>Суешь им контракт под нос, где данный пункт оговорен отдельно и AB>>переделываешь проект.
J>Тебе говорят — дополнительных денег нет и не будет, на контракт они класть хотели т.к. по моим наблюдениям затягивать с оплатой заказчики могут неограничено. Плюс к тебе и твоей коноре сразу теряют интерес и ни одного заказа, я не говорю о поддержке ты от них не получишь. Тебя не будут рекомендовать другим потенциальным заказчикам, плюс будут отговаривать всех своих знакомых вести с тобой дела.
Вопрос сложный. Полностью зависит от того, у кого понтов больше.
К примеру, я в свое время встречал очень много людей из мелких компаний, ругающих компанию Рарус (самый крупный внедренец 1С). Только Рарус от этого заметно хуже жить не стал — понтов у них хватит, чтобы всех недовольных мелких клиентов заткнуть.
>>> Кодеры лажают и плодят ошибки.
AB>>Каждому модюлю соответствует набор тестов, подготовленный постановщиком. AB>>Ошибка модуля прошедшего все тесты — ошибка постановщика. Ошибка модуля AB>>не прошедшего тест — ошибка кодера. Лишите зарплаты + неустойки в AB>>соответствии с контрактом (его иногда еще называют трудовым договором) и AB>>такое положение дел быстро прекратиться.
J>И на следующий день ты остаешься в гордом одиночестве, а такое положение дел не прекратится т.к. возникновение ошибок — неразрывно связано с процессом разрабоки. Кстати в этом плане каждый сам себе пример, ошибки есть у всех!
Вы оба неправы. Нужно искать компромис. А вот если компромиса не находится, тогда уже увольнять и, соответственно, брать новых.
>>> Заказчики требуют завершать этапы раньше срока (чтобы им отчитаться).
AB>>Согласно ТЗ.
J>См. результат сувания под нос проекта.
Бред. То же самое, что требовать от супруги родить малыша не за 9 месяцав, а за 6. Типа по стахановски!
В таких ситуациях здравая аргументация охладит любого нормального заказчика. А если заказчик — псих, то это уже вопрос из другой области.
>>> Людей не хватает.
AB>>Объявление "Приму на работу", кадровые агенства... Людей не может не AB>>хватать (если офис, конечно не находится посреди тайги). Вот ограниченый AB>>бюджет, при котором нанять новых людей проблема — это да... Но это AB>>ошибка менеджера (см через пункт выше).
J>А работать когда? Кто с людьми будет общаться, кто их будет тестировать? Или отдельного человека нанимать, это сразу доп. деньги?
Верно. Увольнением все проблемы не решишь. Тем более, если у конторы большая текучка кадров, значит с ней есть проблемы. В такую компанию не любой человек захочет пойти работать.
>>> Тестирование поверхностное.
AB>>Все этапы тестирования проходят согласно проектной документации.
J>Проект изменяется даже без участия заказчика. Чтобы поддерживать проектную документацию тебе нужны доп. люди, которые к тому же ДОЛЖНЫ дергать программеров, чтобы вносить добавления и изменения в проект. Доп. деньги + время программеров расходуется впустую. Сами программеры серьзно документацию обновлять не будут — много работы, тут тоже каждый сам себе пример.
Опять же проблема с тех. процессом.
Т.е. ты все переворачиваешь с ног на голову. Такое себе могут позволить только XPисты, так как у них документации нет.
Тебе же, как приверженцу классического подхода, нужно сперва понять, что ты меняешь, потом зафиксировать это в ТЗ и/или обновить проектную документацию и только тогда менять код. Почитай про применение релизности в разработке, потом попробуй. Далее сам поймешь.
>>> Сроки затягиваются.
AB>>Оговорено в контракте с клиентом — платишь неустойку...
J>Вот тут как раз можно договориться, если ты не развлекался суванием контрактов под нос и подобными способами.
Договориться в любом случае можно, если заказчик не псих. Ему, как правило, твоя неустойка нафиг не нужна. Ему работающая система нужна. Например, можешь поставить часть системы, а остальное дописать с задержкой, пойти на какие-нибудь уступки. Кстати, если ты проект грамотно разбил на релизы, то такой путь тебе всегда доступен. А вот если твой код — настоящее месиво, промежуточную версию с неполной, но законченной функциональностью ты из него не вытащишь.
>>> Тестовых примеров — не сформулировано. AB>>То же самое, что "поверхностное тестирование".
J>Проект писал ты сам, помнишь? Бизнес тесты которые придумал ТЫ, не обязательно совпадают с РЕАЛЬНЫМИ бизнес тестами проекта. А в бизнесе заказчика ты досконально не разберешься, не хватит времени.
Опять же это твоя проблема. Раз ты взялся за проект, значит ты берешь на себя ответственность и обязанность досконально понять, что же хочет заказчик.
Раз ты еще не осознал этого, значит действительно провальных проектов у тебя еще не было.
Т.е. пока ты не уверен, что знаешь чего нужно делать, уходить дальше сбора и анализа требования с прототипированием нельзя в принципе!
>>> Этап приема проекта не оговорен.
AB>>Ошибка менеджера. (см. выше)
J>Ты не можешь детально описать процедуру приема, во время выполнения проекта вы с заказчиком шли на взаимные уступки, так что на этом этапе будет полно сюрпризов...
Возможно всякое. Опять же, если обе стороны вменяемые, то можно найти компромис. Что-то заказчик вам простит, что-то вы на халяву допишите.
Наличие детального описания процедуры приема системы в ТЗ только является для разработчика бонусом — можно показать заказчика, сколь серьезно ты относишься к его проекту и в какой степени берешь на себя ответственность за качество исполнения.
>>> Кадры заказчика не обучены...
AB>>Согласно контракта.
J>Заказчик ведет свой бизнес как считает нужным он, а не ты. Что ты напишешь в контракте по поводу кадров заказчика? У него работают те кто нуже ему... Не думаю чтобы заказчик стал нанимать людей потому что тебе этого хочется...
Верно. Поэтому в ТЗ должен входить пункт, детально описывающий кого, как и когда ты, как разработчик, будешь обучать.
>>> Продолжать можно много.
AB>>Консультация у юриста стоит 300 руб в час. Квалификации подобного юриста AB>>хватит, чтобы в течении 2-4 часов оговорить все детали всех договоров.
J>Отлично, ты все юридически правильно описал, от всего застраховался... Но это все зря, т.к. такой контракт заказчик не подпишет. Он ничего не понимимает в IT, все что ты там написал про отладку, про тестирование — для него филькина грамота. Что ему нанимать человека, чтобы он все это растолковал? Тратить время и силы непонятно на что (другие IT конторы так клиентов не мучают)?
Проблема не в тупом заказчике, а в тебе. Если ты не можешь объяснить заказчику все преимущества подробно составленного ТЗ, то ты сам виноват.
К примеру, если закачик спросит, почему у тебя договор и прилагаемое ТЗ в 5 раз длинее, чем у конкурента, ты объясни, как конкурент может уехать в ту или иную сторону ущемив интересы заказчика. После чего скажи, что ты такое не практикуешь, что и желаешь подтвердить подробно составленным ТЗ.
Со многим согласен, но разговор тут был не о "тупом и глупом заказчике" и о проблемах в "моей организации", а о налаживании процесса работы. Было высказано мнение что так как все проекты реализуются по простой схеме:
Создать проект (в котором расписаны все детали, кстати не было сказано кто именно этот проект создает?).
Подписать проект у заказчика (прописаны все сроки, описана надежность системы, производительность, требования к оборудованию и персоналу, а кроме того ответсвенность (финансовая) сторон за отступление от данного проекта.
Юридическими и административными мерами (выплата разработчиками неустоек) заставить разработчиков тщательно и аккуратно следовать проектной документации (причем инициатива наказывается — "у нас не место гениям"), от них требуется писать эффективный код не содержащий ошибок. Кроме того разработчики должны в процессе разработки обновлять проектную документацию, а кто-то должен за этими обновлениями следить чтобы пресекать "проектные ошибки и конфликты".
Закончить проект в срок (а с чего ему задерживаться? все же прописано в проекте), согласно процедуре приемки (описанной в проекте) сдать готовый продукт заказчику.
Благополучно закончить проект (а с чего это он может не удастся). Получить деньги.
Я усомнился в реальности данной схемы, т.к. с жизнью она соотносится примерно "как море к траве хотя и то и другое зеленое".
Конечно проектная документация и формальный подход хорошие вещи, но без талантливых людей все это хлам. И не надо из "гения от IT" лепить карикатурный пример капризной принцессы — это не так.
В результате всего этого общения мы выяснили что IT профессионал очень важен, он заслуживает уважения (даже на собеседовании) и самое главное IT proff всегда нужный и всегда найдет себе работу...
Здравствуйте, Anton Batenev, Вы писали:
AB>Вольно перефразировав теорему Тьюринга — "любая проблема AB>программирования если может быть решена в принципе, то решаема AB>посредством чтения и экспериментов". Т.е. другими словами твое AB>утверждение не доказано, как впрочем и мое, однако, мой тезис AB>подтверждается экспериментально.
Слушай, а кем твой знакомый работает? 45*8*20 = 7200$ в месяц. Для наемного работника дофига, можно сказать
V>Он в Германии. Software Developer в самом общем смысле, что конкретно — не знаю, но дядька башковитый до жути.
Дык даже для Германии круто. Я бы сказал даже $90К в год это и для штатов немало.
Здравствуйте, WinCE, Вы писали:
WCE>Здравствуйте, Аноним, Вы писали:
А>>Собеседование — это исскуство, и его цель — дать комплексную оценку человека, а не посмотреть как он программирует на C++. Известно, что человек расскрывается в экстремальных ситуациях намного быстрее. WCE>И ты с создания экстремальной ситуации начинаешь интервью ? Тебе кто прежде всего нужен: человек, умеющий в спокойной обстановке решать задачи создания приложений или программист-экстремал ? Если последнее, то кандидат должен понимать на какую работу его приглашают. А так получается некоректно — ты хочешь увидеть героя, а ситуация к героическому поступку не подталкивает.
ОБЪЯВЛЕНИЕ
Играем на похоронах.
Квартет преферансистов-экстремалов.
[skip]
J>Я усомнился в реальности данной схемы, т.к. с жизнью она соотносится примерно "как море к траве хотя и то и другое зеленое".
Не так уж и далеки они друг от друга.
Если процесс хорошо налажен и все качественно и своевременно выполняют свою работу, то реальная жизнь будет очень близка к описываемой в теории.
А что бы подводные камни не топили команду, нужно чтобы менеджер проекта всерьез занимался оценкой рисков и борьбой за уменьшение их влияния.
J>Конечно проектная документация и формальный подход хорошие вещи, но без талантливых людей все это хлам.
Скорее согласен, чем нет. В разработке ПО хоть кто-нибудь должен быть способен к генерации новых идей и прочей высокоинтеллектуальной деятельности.
J>И не надо из "гения от IT" лепить карикатурный пример капризной принцессы — это не так.
Угу. Как говорилось выше, бывают кул хацкеры и высокопрофессиональные специалисты. Разница в их мотивации, способности к продуктивной командной работе, а не в объеме знаний и опыте.
J>В результате всего этого общения мы выяснили что IT профессионал очень важен, он заслуживает уважения (даже на собеседовании) и самое главное IT proff всегда нужный и всегда найдет себе работу...
Здравствуйте, Anatolix, Вы писали:
A>Это сложный вопрос. Скажем так зачем тебе знать начальный уровень если он все равно ничего не значит. Зарплату тебе дадут в зависимости от того как ты себя покажешь на собеседовании. Нас сейчас устроил бы и вменяемый студент и профи. Понятно что для того чтобы их привлечь нужно указывать разные уровни зарплат. Что прикажешь 5 объявлений на сайте вывесить с одинаковым текстом и разными цифрами?
Именно 5 объявлений, только текст разный. Сам понимаешь — требования к профи и студенту разные. А в тексте как я понимаю пишут прежде всего требования.
Здравствуйте, AntZ, Вы писали:
AZ>Здравствуйте, joker6413, Вы писали:
AZ>Пожалуйста не делайте поспешных выводов. Очень большая ошибка, думать что другие дураки. Уровень действительно слабый, здесь ничего не поделаешь. Как мне кажется, Вы слишком молоды, горячи. Я тоже был таким в 20 лет. Научитесь не держать пальцы веером и не судить других. И не стоит идти против Системы, надо играть по правилам Cистемы. Я, кстати, не в России и такого насмотрелся...
Здравствуйте, Anton Batenev, Вы писали:
>> >> AB>линейку от Радио-86РК до P-VI на различных языках включая С++??? >> >> Ух ты, уже и до P-VI дошел? >> AB>А расшифровать? >> Pentium-6 — это наверное, круто
AB>А... банальная очепятка... Никогда не видел программку "Соло на AB>клавиатуре"? Забавная такая... Попробуй пройти заданий 50-70... После AB>этого мир видится через другие очки ) Серьезно!!! Всем рекомендую!!!
Помню, помню я эту программу. После первых двух дней я чуть из-за нее экран монитора не пробил — так сильно она меня достала! Но все-таки научился. Помнится, пришлось даже ее раскурочить, чтобы регистрационный ключ узнать
Я читал много севых книг и по нескольку раз, но до stl добрался только раз.
З.Ы. stl использую часто, но на зубок нифига не знаю. Исходники никогда не смотрел, стандарт тоже. Только msdn. И это не мешает мне разбираться в коде MaximaE и Wolfhound'а.
Одно из определений — "человек, который находит связи между вещами, которые, как кажется большинству, не имеют никакого отношения друг к другу."
http://russian.joelonsoftware.com/Articles/BigMacsvs.TheNakedChef.html
Забавно наблюдать, как Вы, придумав себе "развлечение на будущее", 
Перекуём баги на фичи!
